User Interviews 文章探讨 AI 工具引发的“第二层”运维债务问题

在 2026 年 3 月发表于《哈佛商业评论》（Harvard Business Review）的一篇文章中，¹（需付费阅读），Julie Bedard 及其同事提出了一个令人印象深刻的术语“AI brain fry”（AI 大脑过载），用以描述以特定方式使用 AI 可能导致的认知疲劳。他们调查了跨行业大型公司的 1,488 名美国全职员工（男性占 48%，女性占 51%；独立贡献者占 58%，领导者占 41%），发现 AI 使用中最耗费精力的部分是“监督”：即监控、编辑、事实核查和验证 AI 生成输出所带来的心理负担。

报告高监督需求的受访者比报告低 AI 监督需求的受访者多使用了 14% 的脑力，并经历了多 12% 的精神疲劳。他们还发现，“大脑过载”现象的发生率因职能而异，其中市场营销、人力资源和运营受影响最大（见图 1）。

经济格局的转变、裁员、对运营效率的关注以及 AI 的出现，意味着许多研究人员现在正式或非正式地承担着研究运营工作，并且他们正热情地构建 AI 系统以满足需求。在过去两年里，我就是这些研究人员中的一员。除了监督这些系统及其输出所产生的认知成本——即 Bedard 等人所描述的“监督”负担之外——自建和自管的 AI 工具还产生了另一种认知负荷：“第二层”编排、治理和维护工作；这是我目前主要处理的运营工作，而这些工作是通过提示词（prompting）来中介完成的。

我创建的每一个 AI 系统都帮助我解决了真实的研究问题——同时也制造了新问题。我将此称为第二层。其中一些挑战看起来像是老生常谈的研究运营问题，例如确定由谁来维护工具。作为一名现在也构建 AI 系统的独立研究人员，我比以往任何时候都更深刻地感受到“第二层”带来的负担。构建（和维护）AI 能力（如研究资料库或数据整理器）的认知负荷，与使用 LLM 撰写研究报告或制作招募筛选器的负荷不同，但它们都会产生令人大脑过载的心理负担。那么，解决方案是什么？

随着新技术的出现和构建新事物的能力，我逐渐意识到，前进的唯一途径是回答这些新问题：谁将管理我正在构建的这些新工具？我该如何调整以更好地管理“大脑过载”？如果我构建的工具列表不断增长，我的维护待办事项也随之增加，我何时才有时间做研究？

编者注：本文最初发表于 ResearchOps Review，您可在此阅读。

暂停“构建者思维”

两年前，我加入了保险公司 ERGO NEXT Insurance，担任唯一的 UX 研究员，负责全公司端到端的研究工作，涵盖从产品到营销的各个环节。自那以来，我利用 AI 创建了诸如批量转换文件格式的应用程序等简单工具，以及视频剪辑工具、转录处理流程和一个 Claude Code“活脑”系统——后者能交叉引用超过 100 份访谈转录稿及其他数据源中的发现。第一次，缺乏工具不再成为按我想要的方式进行研究的障碍。如果我需要调查工具，我可以自己构建。如果我需要知识管理系统，我也能实现它。这种 builder mindset² 正在改变研究专业人士所在的领域，正如它改变大多数职业一样。但你能 can 构建一个 AI 工具这一事实，并不意味着你 should 这样做，也不意味着它将易于维护或无限扩展。

An AI Pandora’s Box

不久前，我使用 Google 的检索增强生成（RAG）工具 NotebookLM 构建了一个研究资料库；此后，我又用 Claude Code 构建了一个更好的资料库。当我首次在产品 offsite 上展示 NotebookLM 时，来自公司各处的利益相关者希望立即获得访问权限，用于他们的细分市场、项目和用例。为了向所有人提供相关内容，我需要手动审查并添加元数据标签到另外 100 多份转录稿中，并将它们加入 NotebookLM。通常，这个过程需要数小时，但我借助 AI 编码工具 Cursor 和 Gemini 快速构建了一个自动化流程。现在，我可以将原始转录稿拖入文件夹，其中 Python 脚本会移除时间戳、标准化说话人姓名、去除填充词和个人身份信息（PII），并扫描访谈以添加结构化元数据标签：日期、用户细分、受访者角色和主题关键词。（这些元数据标签有助于 LLM 找到正确的资源而无需扫描整个文本，这也恰好节省了 token。）最后，脚本以标准格式重命名文件并将其移动到清理后的文件夹。唯一未自动化的步骤是将转录稿上传到 NotebookLM。

这个故事之所以重要，是因为单个工具很少能独立处理完整的工作流。构建一个工具往往意味着要构建其他工具以使系统运行，而且随着一项技术的发展，你可能希望退役某个实例及其所有相关工具，转而启动更强大的东西。教训是：尽管 AI 提供了从白板照片构建工具的能力，但在开始构建之前，暂停并考虑 the primary principles of system design³——可扩展性、可用性、可靠性、延迟、吞吐量、一致性和容错性——仍然是有用的。

AI Multiplies Throughput (and Operational Overhead)

AI 不仅改变了研究的可能性，也改变了研究的规模以及我收集的数据量。例如，以前不在范围内的研究访谈——如购后访谈和流失访谈——现在借助 AI 主持工具定期开展。因此，产生了更多的访谈记录，每一份在加入研究库之前都需要进行清洗、去标识化、标记和追踪。当然，我构建了处理这一清洗流程的工具，但维护该系统本身也是一项工作，而且没有它，研究库就无法完全运作。

当你构建一个工具时，必须问自己：这个系统需要处理多大的规模？例如，有多少份记录、查询或招募对象？它将依赖哪些其他系统，或与其他系统建立怎样的可靠性关系？它需要达到多高的可靠性？但系统并非纯粹的机械装置，因此你还应始终考虑它将启动并运行于其中的人和文化的更大生态系统。

警惕认知投降

一旦我开放了 Google NotebookLM 的访问权限，利益相关者就开始说类似这样的话：“我们做出这个决定是因为 Jordan 的 NotebookLM 这么建议。”但 NotebookLM 的功能是呈现研究成果，而不是做产品决策——这是沃顿商学院研究人员 Steven Shaw 和 Gideon Nave 提出的“认知投降”的一个绝佳例子。⁴ 诚然，其输出质量之高足以让人轻易将其视为权威，但作为这类“即时知识”系统的架构师，我现在是否应该负责管理和教育人们如何使用 AI 系统进行研究？看来确实如此。

构建任何工具都应考虑文化影响：谁将设计并提供培训、治理和护栏？你将如何引导人们上手，使他们具备负责任地使用工具的能力？你将如何监控正确使用？什么才是正确的使用方式？重要的是，你将如何评估输出结果？

正如任何精通 AI 的研究人员都会告诉你的那样，定期评估 AI 输出以确保可靠性至关重要（我也认同这一点），但作为一名独立研究人员，同时也是现在的 AI 工具构建者和维护者，我没有时间每次使用工具时都设计和运行一个全面的评估（或“eval”）流程。相反，我通常对单份记录运行十次评估，如果一切看起来不错，我就放心了。但教训是：当你构建一个 AI 系统时，要计划设计一个永久性的质量控制循环，并预留时间来管理它。当我有能力时，我计划采用 Lindsey DeWitt Prat 的五步评估蓝图来纳入更系统的审查流程，她在《Review》杂志的文章“赢得传话游戏：跨研究管线评估 AI 的蓝图”中分享了这一方法。⁵

升级编排能力

不久前，我的一位同事分享了 OpenAI 创始成员、知名 AI 研究员 Andrej Karpathy 发布的一条推文，其中提到了他所谓的“LLM wiki”概念。我把这条推文连同一些说明发给了 Claude Code，解释我想构建的内容：一个复利式知识系统，其中每一块新内容都会经过清洗、打标签、分析、总结，并与系统中已存储的所有内容进行交叉引用。我将这个系统称为研究大脑。利用研究大脑，我可以控制转录文本的分析方法、研究发现如何被交叉引用以及主题如何浮现。我可以向大脑提供业务背景的大纲，并要求它撰写文章——所有这些信息随着时间推移不断累积，使大脑变得更加相关。

两年前，构建这些能力需要一个专门的工程团队。如今我能独自实现这一点令人惊叹，但构建和维护如此复杂的系统需要大量的编排和详细的工作流映射。我甚至将整个工作流画在白板上，以便 Claude Code 能利用它来帮助改进（见图 2）。构建者正在构建应用，但应用也在自我构建。

回到 AI 大脑过载的概念，当你构建或使用像 NotebookLM 这样相对简单的工具时——你提出问题并获得带有引用的答案——监督成本相当低。如果你构建的是像“研究大脑”这样的代理系统，编排复杂度就会升级。你需要映射多步骤工作流、编写元数据模式、为管道的每个阶段创建 Claude Skills（Skill 是一组简单的指令，Claude 可用于处理可重复的工作流）、测试输出并评估可靠性。即使只针对单个用户管理这一切，更不用说组织中数十或数百人，也可能变得极其复杂，以至于很快你就需要定期记录整个工作流，以便向你的团队以及 Claude 本身进行解释。为了缓解部分大脑过载，我建议为每个步骤创建一个 Claude Skill。拥有一组 Skills 后，确保它们各自独立运行，然后将这些 Skills 串联起来以创建多步骤工作流。对系统进行逐部分的理解比一次性构建所有内容更易于管理。

可持续地构建 AI

2026 年 2 月，加州大学伯克利分校的 Aruna Ranganathan 和 Xingqi Maggie Ye 分享了一项为期八个月的研究成果，该研究探讨了某家拥有 200 名员工的科技公司中员工如何与 AI 协作。他们发现，AI 扩大了而非减少了员工的工作量，因为人们承担了更多任务、停止了休息，并与 AI 保持多条并行线索。欲了解更多关于这项工作的内容，请阅读他们在《哈佛商业评论》上发表的文章“AI Doesn’t Reduce Work—It Intensifies It”。⁶ 为了应对 AI 导致的“大脑过载”和不堪重负的问题，他们建议在重大决策前刻意安排暂停时间，将工作分阶段进行而不是对每一次 AI 输出都做出反应，并保护用于人际交流的时间。为什么不与同事见面，分享你正在做的工作并获得反馈呢？我也发现，人际交流有助于我放慢工作节奏——哪怕只是片刻，也能停下来思考。

我构建所有这些工具是因为我有需要解决的问题，但管理“大脑过载”和第二层复杂性对于维持运营越来越至关重要——这也包括 我 作为该系统一部分的运作方式。如果你是一名研究人员，请拥抱建设者思维，尽情玩耍和实验，紧跟 AI 工具的发展，不要因为阻碍而气馁。这些工具将赋予你创造能力，而这些能力即使在两年前也是不可想象的。但在采用这种新思维模式时，请找到主动管理倦怠的方法，这有时意味着少构建一些东西、放慢速度以考虑系统设计，或者淘汰那些不再有用的发明。

因此，在你通过“氛围编程”（vibe coding）让一个工具诞生之前，请问问这些古老的运营问题：

• 这个系统能扩展吗？它会保持可靠吗？维护它的财务成本和认知成本是多少？用系统术语来说：可扩展性、可用性、可靠性、延迟、吞吐量、一致性和容错性。
• 它将如何与你组织中的人员和文化相契合？
• 你需要做些什么来管理该工具的使用方式？

此外，要进行规划和记录。如果你想构建一个庞大的系统，请创建一个包含目标、时间表以及评估成功方法的项目计划，这样你就知道自己在朝着什么方向努力。记录或写日记你的每日进展，以便你可以反思并分享你的构建过程。我经常先构建某个东西，然后发现自己完全不知道是如何走到那一步的，这就是第二层复杂性悄然渗入的方式。

为了解决第二层复杂性，你需要明确命名它，我发现定期记录你的过程很有帮助。此外，通过创建文档，你需要手动写出希望 AI 复制的工作流程（你会停下来思考），这也将帮助你更准确地向 LLM 解释它。你可以通过创建可视化图表或书面文档来实现这一点。如果你在 Claude Code 中工作，可以要求它在构建会话期间按日期记录持续更新的决策和工作日志。通过让 Claude 维护决策日志，你将部分第二层编排开销卸载到系统本身，而不是由你自己承担。如果你不确定如何解决某个问题，Claude 很可能可以提供帮助！

避免迭代陷阱

2025 年的 用户访谈：用户研究现状⁷ 报告发现，80% 的 UX 研究人员使用 AI 来支持他们的工作，高于 2024 年的 56%。研究人员似乎更多地使用 AI，但同一份报告发现，情绪褒贬不一。41% 的 UX 研究人员表示对 AI 对用户研究的影响持负面看法，只有 32% 的人表示持正面看法。这一差距相当大。这些数字证实了我的感觉，即 AI 是一把双刃剑：它赋予人们力量，但同样容易让人感到被迫使用它以生存——以越来越快的速度前进。从同一份报告中，这段引言引人注目：

“AI 正成为焦点，盖过了更大的客户问题，这让我并不喜欢。虽然它有助于处理低门槛任务，但我感到压力重重，不得不使用它，否则就会被抛在后面。它加快了我的工作速度，但代价是我的留任率、理智和输出质量。我担心随着更多使用 AI，我正在失去自己的声音，但我出于必要性必须使用它，以便以预期的节奏完成任务。”

在构建 AI 系统时，我不断回到这些问题：我构建的东西何时才算真正完成？什么时候才算足够好？它是否曾经“完成”过？就像画家面对画布一样，很难知道何时停笔——何时放下画笔。Claude 随着每一次迭代变得更好，我可以不断添加步骤、改进和复杂性，却没有明确的“完成”基准。我也在尽可能快地构建，这很快。如今，快已经不够快了。解决方案的一部分是使用系统设计思维，更仔细地考虑你所构建内容的技术和认知影响——仅仅因为你能构建某样东西，并不意味着你应该这样做。

引用文献

1. Bedard, Julie, Matthew Kropp, Megan Hsu, Olivia T. Karaman, Jason Hawes, and Gabriella Rosen Kellerman. “When Using AI Leads to “Brain Fry”.” Harvard Business Review, March 5, 2026. https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry.

2. Dixit, Pranav. “Several Meta Employees Have Started Calling Themselves ‘AI Builders’.” Business Insider https://www.businessinsider.com/meta-pms-ai-builders-tech-industry-2026-2.

3. Haque, Faisal. "The Complete System Design Guide: From Zero to Production-Ready." Medium. April 19, 2026. https://aws.plainenglish.io/the-complete-system-design-guide-from-zero-to-production-ready-8fa98ec35fd5.

4. Shaw, Steven D., and Gideon Nave. “Thinking—Fast, Slow, and Artificial: How AI Is Reshaping Human Reasoning and the Rise of Cognitive Surrender.” The Wharton School Research Paper, (2026). Accessed April 21, 2026. https://doi.org/10.31234/osf.io/yk25n_v1.

5. DeWitt Prat, Lindsey. "Winning the Game of Broken Telephone: A Blueprint for Evaluating AI Across the Research Pipeline." The ResearchOps Review, May 6, 2026. https://www.theresearchopsreview.com/p/a-blueprint-for-evaluating-ai-across-the-research-pipeline.

6. Ranganathan, Aruna, and Xingqi Maggie Ye. “AI Doesn’t Reduce Work—It Intensifies It.” The Harvard Business Review, February 9, 2026. https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it.

7. "The State of User Research 2025." User Interviews. September 10, 2025. https://www.userinterviews.com/state-of-user-research-report.

‍