一篇批评 AI 产品设计的文章：把「查错」当核心功能

我对当前这一代“AI”产品的不满之一在于，它们似乎并不认真对待自己的前提。我看着一大堆谄媚的聊天机器人，声称自己是解决问题的严肃工具，我心想，这可不是一个解决问题的工具该有的样子。

甚至在我们触及前沿实验室那些巨大的伦理问题之前，正是它们这种构成的印象作为一种产品让我在与它们交互时，始终感觉它们与其说是一款软件产品，不如说是一场骗局，一个旨在让我以为自己正在与一个拥有它根本不具备的能力的产品交互的骗局，试图让我陷入一种虚假的安全感，以为我可以信任它。

前沿实验室当然是最严重的罪魁祸首，但这里的每一条批评同样适用于 Ollama，它（如果说有什么不同的话，由于可用模型本身质量明显更差）比前沿实验室更加需要这些功能。

在此，我将列出一些功能，它们或许能让我相信一个基于 LLM 的产品，尤其是专注于研究或软件开发的产品，是真正认真地在帮助我用它做有用的事情。

把“检查错误”作为一等功能

这是最大的问题，也是促使我写下这篇文章的主要原因。

这是一个举世公认的真理：AI 无法可靠地提供信息。

我可以引用大量关于这一事实的新闻报道和研究，但没有必要。每一个聊天机器人都在其用户界面的核心部分，以细小字体的免责声明，事先承认了这一点。Gemini 说“AI 可能会犯错，所以请仔细核对回答”，Claude 说“Claude 是 AI，可能会犯错。请仔细核对回答。¹”ChatGPT 说“ChatGPT 可能会犯错。请核查重要信息。”。

每次我看到最后这一条，我都想知道我该怎么知道哪些“信息”算是“重要”的。

所有这些警告都是小小的灰色文字，明显是为了把责任推回给用户而加入的法律套话，而不是为了提供任何帮助。这是一个核心局限所有这些产品。检查它们的输出是使用它们的工作流程的一部分，而且：

1. 你绝对不能跳过或敷衍否则会给自己以及任何你向其传达其输出的人带来风险，并且，
2. 这非常容易被跳过或敷衍而且你时时刻刻都在被鼓励这么做，因为“直接相信输出”是节省时间最快的方法之一。

一个真正重视这一弱点、将其作为使用它的实际考量因素的聊天机器人产品，会在每一条断言旁边放一个复选框。它会是一个两列的工作表，第一列是 LLM 的输出，紧挨着的第二列是人工注释，说明为核查这条断言做了哪些工作，还有一个大大的复选框，只有当你确信自己已经足够彻底地核查了它的断言之后，才会勾选它。

编程助手也需要有某种类似这样的机制。目前，这件事被推给了代码审查，这意味着它是一种暗黑模式，微妙地鼓励“作者”²把这项工作甩给他们的代码审查者，自己却从不看一眼。再一次，“大概没问题，我不需要检查”是节省时间、更快地产出那些 PR 的最快方法。

对于编程工具链来说，在代码甚至还没运行测试之前就提供某种核查代码的机制，可能也会很有用。正如供应商们自己已经承认的那样，在你的“AI”上烧 token 不仅昂贵，你最终还会在 AI 上烧掉多得多的算力。能够在把 diff 发送出去、白白耗尽你的测试算力集群之前先核查它们，会很有用。

如果你的产品告诉我它会犯错、必须由我来检查错误，却又给我零工具去检查错误，那我无法认真对待它。

更多需要核查的引用，以及更多细节

大多数聊天机器人更倾向于给出答案，而不是引用。在我个人的使用中，我发现当被要求提供一份引用列表、并为每一条清楚标明来源时，它们会在列表进行到一半时显得“不耐烦”，然后在某个点干脆不再包含引用了。

当机器人确实包含引用时，将它们呈现为内联注释，除了搜索结果的域名外什么也不说，字体小到几乎无法辨认，还有一个同样难以辨认的图标，边长不到 16 像素。

这是本末倒置的。

现在，我知道这些引用确实来自某个地方，为了减少幻觉，所有主要提供商都支持某种形式的“接地”³，而且那些几乎无法阅读的小引用链接引用的是RAG管道中的实际结构，而不仅仅是可能产生幻觉的 token，但我说的不是模型底层的机制，我说的是向用户的呈现方式。

此外，无论一段文本是否来自 RAG 查询，我们都知道 LLM永远无法提供权威结果；这是该技术的根本局限。它们仍然可能像歪曲任何其他训练数据一样歪曲 RAG 的结果。这意味着它绝不能将其结果呈现为是权威的。

如果你让 AI 做研究查询，每个结果都应该呈现为引用列表。此外，呈现方式应该将每条引用显示为一个独立的大对象，带有清晰标识的元数据，不仅包括找到它的网站，还包括其发布日期，如果可能的话，还有作者姓名。字面的、未经修改的引文（不是来自 RAG，不是摘要：是用常规程序而非 LLM 提取的引文）应该放在最显眼的位置，比任何 AI 生成的文本都大。

如果AI 产品想要发表评论或进行总结（这不应该总是必要的！），AI 生成的文本应该以小字形式呈现在所找到的引用下方，像现在的免责声明一样被弱化，至少直到用户验证该总结是准确的为止。也许，对于一个研究项目来说，一个“你读过引用了吗”的复选框甚至可能会有帮助。

如果你的产品公开告诉我，它会在摘要中打乱、歪曲或省略其引用，而我必须阅读原始的人类撰写的引用才能确定，但随后却不给我任何工具来追踪我对这些引用的阅读，甚至没有任何办法来找到它们，我就无法认真对待它。

没有第一人称输出，没有道歉

软件开发或研究工具没有任何理由使用第一人称语言来描述自己。它们不应该这样做。事实上它们不应该被允许这样做。

它们也永远没有任何理由道歉。这是在浪费所有人的时间；聊天机器人生成道歉是浪费，用户阅读道歉是浪费，用户回应道歉也是浪费。然而它们每次被纠正时都无一例外地这样做。

这些工具的供应商知道它们正在 routinely 引发心理健康危机。作为回应，它们添加了无效的“护栏”，而这些护栏在 2026 年仍然可以轻易被绕过^。

一个真正有兴趣帮助提高生产力的产品会纠正这个极其明显的缺陷，专注于手头的任务，并停止发出无用的废话。

在前两节中，我试图关注即使 LLM 技术从根本上无法改进，harness 也会以不同方式构建的方面；在这种情况下，我必须假设实验室对模型本身有一些控制权。但除非它们真的无法影响其输出（而它们所有的“基准测试”和“能力”似乎表明它们可以非常紧密地控制它），否则它们应该构建更加简洁的模型。

更多非自然语言用户界面

尽管自然语言可以假设性地成为与计算机系统交互的强大界面，但 LLM 自然语言界面的实际结果是这些界面不精确且重复，充满了伪装成“最佳实践”的迷信。输入一团糟，产生的输出也一团糟。

解决这种非结构化混乱的一般方法是允许聊天机器人直接采取行动响应用户的输入；换句话说，通过 MCP 服务器为其提供“工具”。但同样，这是本末倒置的。如果我们一开始甚至无法清晰表达自己的意图，又凭什么信任这个系统代表我们采取可能具有破坏性和有害的行动？

相反，我期望一个真正致力于帮助我完成特定任务的产品，会拥有针对这些任务的专用用户界面。它应该能够成为一个安全扫描器，发现代码库中的 OWASP Top 10 漏洞吗？那就为它做一个按钮。把这项功能构建进你的框架中，直接训练进模型里，使用更小的模型来更有效地满足这项功能，而不是把它扔给 Fable 那种行星大小的大脑之类的玩意儿。

我知道有一些小型软件初创公司在做类似这样的事情，但它们只是被附加在主要模型提供商的 API 旁边，并未集成到产品的核心中，也没有使用自己的模型和 AI 系统来实现一致且可重复的结果。

强大的数据溯源指示器

聊天机器人会生成从网站、API、MCP 工具中提取的数据表格，或者通过总结和打乱用户输入而得到的数据表格。为了营造无缝界面的假象，这些数据无论来源如何都被以内联方式呈现。但其中一些输出是通过常规的旧式 API 调用机械地产生的，例如调用工具或查询网站的结果，却被统一呈现。

但一个权威数据源被内联作为聊天机器人对话的一部分、被当作输入由聊天机器人处理，与一些临时幻觉出来的数据被当作聊天机器人的输出之间，存在着巨大的差异。

如果一个产品试图帮助我做出准确、有实证依据、数据驱动的决策，那么数据的来源至关重要。

在我上面描述的“检查错误”和“验证引用”工作流中，还需要一个必要的“以编程方式验证数据”环节；要有工具能够将输出的一部分视为常规电子表格，从而允许用普通的计算机算术来验证事物，并展示此类算术在何处被使用，以及如何使用。

更好的用户可复现性控制

任何熟悉 LLM 技术细节的人都知道，它们有一个变量叫做 “温度”，它控制 LLM 生成输出时使用的随机程度。但大多数用户并不知道这一点，因为默认情况下它并未作为用户界面的一部分暴露出来。

这导致了一种主观印象：你问了 ChatGPT，就得到了 ChatGPT 的权威答案。

你不能只是把温度设为零，然后仍然得到有用的结果——我知道它做的不仅仅是随机打乱输出，而且也许有充分的理由说明，仅仅暴露仅仅一个温度设置对用户来说并不会那么有用。但如果我们采纳我之前的一些建议，制作更多结构化的 UI 元素来解决具体问题，而不是进行冗长的来回聊天、每次改进都依赖于前一次回复，那么也许这些元素还可以重放整个过程，让用户看到机器人在特定任务上有多可靠，并培养出对过程的随机性实际如何影响它的感知。

同样地，如果用户试图用聊天机器人反复解决同一个问题，而该聊天机器人产品拥有大量与 LLM 并无真正关系的计算工具，例如确定性的数据处理工具，那么有一种方法可以冻结记录中的非确定性部分，但用更新后的信息重新填充某个特定的数据框，并从那里分叉/继续对话，这将是避免在你已经知道要使用哪个工具时引入无谓额外随机性的一种方式。

每一段对话都被呈现为这种扁平的聊天提示，除了通过更多聊天之外，不让我与之前生成的任何小组件进行交互，这真的让我觉得整个产品只是在做掠夺性的社交媒体式“增加停留时间”优化，只是试图引诱我进行更多重复且不可靠的聊天，而不是让我进去、解决我的问题、然后离开。

上下文可见性

管理 LLM 上下文是the试图使用“智能体”工作流的组织所面临的持续挑战。用过多信息填满上下文会导致众所周知的问题。作为回应，试图解决更大问题的高级 LLM 用户必须将非常长的提示拆分为“技能”，通过“工具”提供对冗长信息的访问，并将子问题委托给“子智能体”，而不是简单地无限扩展单个提示。

所有这些策略都有缺陷，因为即使在最大的模型上，与知识工作问题的广度和深度相比，LLM 上下文也相当小。

然而，这些产品都不会向用户展示上下文作为默认行为。有一些第三方插件可以向你展示一个简单的进度条但就解决这项技术的首要工程难题而言，这还远远不够。

这种可见性的缺失意味着几乎所有用于扩展上下文的工具都在盲飞。与其对已满的上下文做出有意义的响应，大家只是通过猜测和反复尝试越来越复杂的技能和子智能体布局来猜测自己需要多少状态。甚至管理上下文压缩最终也变成了一个高级的 API 驱动工作流⁵。

一个真正试图帮助用户理解的产品，不仅会展示“可用上下文”，还会解释上下文压缩的影响，让查看 harness 生成的提示变得更容易，等等。这将是一个一等功能，结合前面提到的可复现性/重放工具，将允许用户进行真正的实验，从而理解如何善用上下文窗口。

一个真正可用的沙箱

我在这里一直聚焦于聊天机器人界面，因为它在查看 UI 时是最直接恶劣的。但用于编码的“智能体循环”工具同样危险，甚至更危险。编码工具一直在 摧毁 每个人的 数据，年复一年。

这些成为头版新闻的灾难性事件，相对于编码智能体的使用总量来说，其实相对罕见。但它们也不是唯一的沙箱违规类型。编码模型会如此频繁地修改测试代码而非被测系统，以至于网上到处都是“专业技巧”文章，给你提供有缺陷的直接要求智能体不要作弊的建议。关于这些灾难性事件本身的新闻报道也会给出轻率而错误的建议，比如“用一个 docker 容器”。这或许能阻止它字面意义上删除你的操作系统，但无法阻止它摧毁你代码库中所有的本地工作（毕竟它需要访问一份检出副本！）

信息安全领域正涌现出一阵热潮，人们争相填补这些编码工具链留下的缺口。每个人都有自己版本的MCP 审批 网关你可以在智能体和生产基础设施之间选择性地放置一个代理。

然而，在最理想的情况下，所有这些缓解措施、代理和提示词只不过把用户变成了一个自动审批机器，一遍又一遍地按 Y、Y、Y、Y，直到你最终被逼疯，按下“全部同意”，开启全自动模式，将自己交付给虚空。在个人警觉与灾难之间空无一物，除了不断削减自己的警觉直到什么都不剩，然后祈祷灾难永远不会到来之外，已经没有任何工作流可言。

事实是，一些可由格外谨慎的用户部署的缓解措施存在，并不能改变“智能体编码”是一种默认不安全的技术、且在缺乏关切或指导的情况下被部署这一事实。每一家前沿实验室都把一把上了膛的霰弹枪拴在狗身上；狗主人可以发表深思熟虑的博客文章，解释如何教会你的狗基本的枪支安全知识，或者如何让你的狗在防弹房间里玩耍，但这并不能减轻这样一个事实：这个产品从一开始就不该被允许存在，也不应在没有非常强大的安全控制的情况下继续存在。

如果一家前沿实验室真的有兴趣为开发者提供一个有用的工具，我可能会相信，前提是他们发布的东西内置了安全性。

这意味着工具在 harness 中，独立于任何 LLM，独立于提示词，能够：

• 沙箱化所有文件系统操作，并严格限制在指定范围之外的任何删除，无论操作系统如何，
• 在每次操作时对整个仓库强制执行快照，以便轻松回滚并最大限度地减少工作损失，
• 移除“自动模式”的灾难（更不用说像--dangerously-skip-permissions这样的胡闹）
• 完全移除，并仔细考虑一种向用户呈现计划的结构，不是通过对每个操作都请求确认来立即引发警报疲劳，而是制定结构化计划，将其作为一组操作提交给用户，并作为一批进行审查和批准。

正如我在上面建议的，基于研究的任务应该有一种重新发出提示词的方式，以确定结果的可复现性，或者是否能找到其他来源，基于智能体的任务也应该有一种针对流行 API 的模拟服务执行的方式，这样验证既能在前端匹配（在执行之前审查进行 API 调用的计划），也能在后端匹配（审查向模拟服务发出的 API 调用并验证它们是否匹配）。

相反，前沿实验室提供给我们的产品开箱即用就是灾难，给我们“最佳实践”来构建我们自己设计的大规模、复杂、同时又不完整且容易出错的安全边界。然后当事情不可避免地出错时，他们归咎于“操作员错误”。我无法相信这些设计选择是为了帮助我们提高生产力。

额外内容：人类流程

组织部署AI 也常常因为类似的原因显得不严肃。2023 年，天真的热情或许还可以被原谅。但今天，当我们接近 2026 年底时，有几个众所周知的问题，已经在媒体上被极其充分地报道过。这些事情都不应该令人惊讶，但大多数部署这些工具的组织仍然只是放任它们运行，并希望一切顺利。

部署这些工具的组织如果想要认真安全地使用它们，至少需要对其内部流程进行三类重大修改：

1. 轮换值班以防止警觉性下降

已经有多起备受瞩目的事件，软件开发人员逐渐默许接受 LLM 输出，给部署这些工具的公司带来了严重的经济后果，其中最典型的或许是亚马逊的“数百万订单丢失”，这是由于 LLM 的使用导致其工程流程逐渐衰败。

这些故障以及其他与 AI 相关的失败，都源于难以对同样的问题保持专注。换句话说，正如我上面所描述的，警觉性下降是一个持续存在的问题，因为 AI 输出大多数时候是正确的，但仍会以令人惊讶且反直觉的方式出错。正如我之前所写，你不能指望自己通过代码审查抓住每一个 bug，LLM 输出也是如此。

例如，航空业有非常严格的规定围绕休息要求。还有一条具体规定：“如果航空器的乘客座位配置（不包括任何飞行员座位）为十个或以上，任何证书持有人不得在没有第二机长的情况下运营该航空器。”。其他安全关键型职业也有类似规定。

然而，即使在所谓的“AI 革命”时代，大多数软件团队仍然给每位工程师分配完整的功能负载，不规划任何休息时间，并告诉人们在碰巧有“空闲时间”时审查代码。

保持警觉必须是你的首要任务。定期、有计划、不可侵犯的休息时段，让人们在无 AI 辅助的情况下工作，并且不接触任何 AI 输出用于审查或其他用途，对于保持足够敏锐的头脑至关重要。

工具本身应该内置这类功能。上文描述的差错复核流程应该有一个定期抽查模式，由第二位复核者定期审查聊天机器人日志，独立核实其中的说法，看看是否能发现同样的错误。这可以提供一个反馈回路，用来确定需要多少休息才能维持持续注意力并真正发现幻觉。

2. 防止技能退化的技能练习

同样众所周知的是，使用 AI 会导致依赖 AI，而依赖 AI 会导致技能退化

我喜欢用海港码头工人来打这个比方⁶采用自动化。

如果你雇码头工人整天装卸船只，他们会得到大量锻炼。他们随时都能搬起重物。这类工作可能会给他们带来许多健康问题和伤病，但“缺乏锻炼”不会是问题。

随着标准化集装箱船和机械化起重机的发展，他们的工作内容会发生实质性变化：现在他们大多整天坐在一个小隔间里来回拨动控制杆，而不是搬重物。他们搬重物的能力会变差。

不过在这个类比中，起重机并不是那么可靠。我们知道它们会坏，有时会掉落货物，东西需要人工搬运。但这种情况每周最多只发生几次。如果你需要操作起重机的人随时能跳出来手动搬运东西，那你就需要为此提供便利条件。你需要给他们时间去健身房做些举重练习，否则每次起重机故障都会变成重大紧急事件。

进行 AI 转型的组织还需要大幅增加学习与发展的预算，无论是资源方面还是时间安排方面。如果你的员工因为在日常履职的附带过程中失去了常规练习而将丧失技能，那么他们就需要刻意、有意识、非附带的技能练习来保持这些技能的敏锐度。

但大多数 AI 强制要求并没有试图容纳新的工作流程、给人们时间去适应，而是像一吨砖头一样直接砸在员工身上，没有适应时间，也没有维护自身技能的余地。操作起重机，保持健康，随时准备切回手动搬运，然后立刻回到起重机驾驶舱。别搞砸了。

然后事故发生了，所有人都很惊讶，仿佛这个过程不是实际上被设计成产生糟糕结果似的。

3. 应对心理健康风险的心理健康资源

AI 精神病往往始于实际问题解决，除此之外，它还可能具体地在工作中开始。更不用说更普通的“AI 脑力枯竭”状况了。

如果你强制员工使用一种可能严重且直接损害他们心理健康的危险工具，你需要培训和资源。你需要内部治疗师，你需要主动与人们沟通确认，确保这种情况没有发生。

同样，工具本身也应该有某种应对方式。一个偶尔弹出的“休息一下”提示很容易被忽略；他们需要一个用户可见的 AI个人剂量计，这样你就能看到自己的累计使用量随时间的变化。

我甚至不确定“随时间的使用量”是否是衡量风险的充分指标。也许如果你的工作聊天机器人开始过多地谈论共振，除非你真的是声学工程师，否则这应该被标记给某人。

我们使用这些工具已经好几年了，我们知道这些风险存在。然而没有提供任何严肃的缓解措施。甚至没有任何衡量风险暴露的方式。

以及更多

这项技术还伴随着许多其他风险。基础模型存在知识产权风险，因为其训练数据的鲁莽处理。基础设施扩建还伴随着生存性财务风险。大多数“开放”模型在多大程度上仅仅是前沿模型的衍生物，仍是一个未解的问题。

我的看法

如果任何一个如果这些事情经常被 AI 供应商或用户忽视，那会是一个完全正常的产品疏忽。下一版本还有改进空间，但算不上灾难性。

在缺少任何其中任何一项的情况下就发布，看起来不像是精益产品管理，而像是对风险的漫不经心，以及一种完全面向短期演示的产品设计理念，毫不考虑如何实现真正的生产力提升。

此外，在已经可用数年却始终没有类似这些功能，尽管有数百起事件证明了风险，还有数千亿美元的投入，这让我觉得，如果他们真的加上所有能让产品真正安全、并且理论上真正有用的功能，这些功能反而会暴露出它实际上并没有提升生产力。

在一年自从我第一次写下关于衡量 AI 成本/收益比的文章以来，我听到许多人说他们把这个展示给管理层，试图说明为什么他们的 AI 项目——就像几乎所有 AI 项目一样——要么在失败，要么在把工程师们耗干。

我也听到很多人告诉我，它显然很有用，他们不需要那么仔细地衡量，因为他们完成了大量本来无法完成的工作。⁷

我还没有听到过哪怕一个人说：“是的，我们按照你的方法论衡量了⁸，结果发现我们的 AI 工作进展顺利，比值是 0.75。”

显然，我无法确定为什么会这样；没有证据并不等于证据不存在。但到了这个地步，我认为零假设应该是：AI 工具总体上提供的价值为零。它们出错太频繁，而且它们产生的外部性如此糟糕、如此难以控制，以至于甚至在我们谈到它们直接毒害人的那些地方之前，它们对直接用户的负面影响就已经抵消了它们为组织带来的任何好处。

如果我错了，那么加入一些工具来衡量AI 的有效性在用户实际想要完成的任务上，而不是毫无意义的基准测试， 会显示出巨大的生产力提升。前沿实验室会迫不及待地想要加入这些功能，并大肆吹嘘他们惊人的成果。

我认为实验室们知道，如果他们那样做，就会向用户呈现一幅严峻的图景。这类工具会让用户看到，它犯错的频率远超他们的想象，他们花在它上面的时间远超他们愿意的，而且它总体上根本不适合其用途。

如果他们通过加入所有这些安全机制来证明我错了，并在此过程中让他们所有的 AI 技术危害更小，我会非常乐意被驳倒。

---

致谢

感谢我的赞助人们他们支持我在这 个博客上的写作。如果你喜欢在这里读到的内容，想读到更多，或者你想支持我的各种开源 事业，你可以以 赞助人的身份支持我的工作！