678 篇博文 含有标签「ai-engineering」

一家大型医疗保险公司部署了一套AI工具来评估病后护理索赔。该系统的错误率超过90%——也就是说，每十个经人工审核人员最终推翻的拒赔案例中，有九个是被错误拒绝的。然而这些拒赔并未被主动纠正。患者不得不逐一提出申诉。当诉讼来临时，公司的回应是将矛头指向AI。

AI什么都没有拒绝。是人类在他们自己设计的工作流程中大规模地批准了这些拒赔，在他们选择部署的系统里。但"AI决定了"这句话把责任引向了一个方向，恰好让组织、批准上线的高管以及在每个案例上签字的审核人员得以脱身。

这就是责任转移问题——它不是未来的风险，而是已经在生产AI系统中普遍存在的现实。

询问任何工程副总裁 AI 编码工具是否能提高生产力，他们都会给出肯定的回答。但如果你询问一名在一套拥有十年历史的代码库中工作的资深工程师（Staff Engineer），这套代码库里有六个没有文档记录的数据模型，部署流程全靠 Shell 脚本维系，你得到的答案将会截然不同。

AI 编码工具带来的生产力提升呈现出一种大多数组织尚未完全消化的分化态势。初级工程师在每周完成的任务量上看到了 27%–39% 的提升。而在一项针对真实世界问题的受控研究中，资深开发者在使用 AI 辅助时，完成任务所需的时间反而比不使用时增加了 19%。这两个结果都与这些工具的工作原理相一致 —— 并且它们正导向一个目前正在工程团队中悄然上演的管理陷阱。

当麦当劳在三年运营后关停其 AI 得来速系统时，失败的原因并不是模型识别订单能力不足。失败的根源在于架构：没有明确的升级路径交给人工收银员，没有触发重试的置信度阈值，也没有定义系统困惑时该如何处理。AI 只是不停地尝试。顾客不断地抓狂。顺利路径设计得很好，其他一切都没有。

几乎每一个失败的 AI 部署都重复着这个模式。模型在演示中运行良好，在生产中出现故障。而事后分析揭示了同样的根本原因：降级设计从来不是架构的一部分，而是某人打算"之后再加"的东西。

你的 AI 功能顺利发布了。文档看起来很棒：输入 schema、预期输出，以及一个经过验证的示例。三个月后，模型静默更新。输出发生了偏移。你的文档错了，但还没人发现——因为它们看起来仍然是“正确”的。

这是 AI 文档债（AI documentation debt）的核心，而且它比任何其他类型的技术债积累得都要快，因为在用户发现之前，这种失败是隐形的。

一位小团队工程师花了三个月将测试生成委托给 AI。代码覆盖率从 47% 跃升至 72%，再到 98%。每次 PR 都返回绿色。然后生产环境崩了。用户注册中的竞态条件因数据库复制延迟导致重复邮箱。优惠码接口在代码无效时返回 null 而非零，导致支付计算对 4700 名客户静默出错。最终损失：4.7 万美元退款和 66 小时工程时间。测试并没有遗漏几个边界情况——它们覆盖了所写的代码，而非所部署的系统。

这就是覆盖率幻觉。随着 AI 辅助开发成为默认选项，落入这个陷阱正变得越来越容易。

思维链提示（Chain-of-thought prompting）本是为了解决语言模型的黑箱问题。展示推理过程，验证每个步骤，理解模型如何得出结论。这个想法直觉上是对的——而这恰恰是问题所在。它感觉太显然正确了，以至于从业者将可见推理链部署到生产系统中，却没有追问一个更难的问题：如果展示推理过程反而让事情变得更糟，该怎么办？

2024年至2026年间的研究已开始系统性地记录这种"更糟"究竟是什么样子。可见推理链导致了两种截然不同的失败模式，在生产环境出现问题之前往往被忽视。第一种是用户侧问题：中间推理步骤会在用户看到最终答案之前，将其锚定于可能错误的结论。第二种是系统层问题：推理追踪制造了审计追踪的假象，而作为模型实际决策过程的解释，它从根本上是不可靠的。

AI 功能在生产环境中夭折有一种典型的模式：它们最初是作为副驾驶 (copilot) 启动的，然后被晋升为自动驾驶 (autopilot)。这种晋升的原因显而易见——降低成本、扩大规模、减少人力——而且这些理由在演示阶段听起来非常充分。随后，边缘情况 (edge cases) 开始积累。面向用户的推荐变成了面向用户的决策。建议变成了行动。当第一次系统性失败降临时，工程团队才发现，最初设计中预设的容错假设从未被重新评估过。

这就是“副驾驶陷阱”：针对自动化频谱的某一个层级构建 AI 功能，然后在没有重建该层级所需的故障模型的情况下，将其强行提升到更高层级。

你的代码库中有三种不同方式实现的身份验证逻辑，而且团队中没人在写过其中任何一种。通过 git blame 快速查看，发现这三个文件都出自同一位工程师之手，但去问那位工程师，他们会告诉你他们只是接受了 AI 的建议，而且看起来“没问题”。这种反模式的蔓延并不是因为有人偷懒，而是因为一个对你现有认证模块毫无记忆的 AI 模型，在每次有人打开新文件寻求帮助时，都生成了看起来合理的实现。

这就是“复制粘贴传染病” (copy-paste contagion)，它在结构上与你已知如何应对的经典复制粘贴问题完全不同。

大多数团队一开始都用一个单一的、庞大的系统提示词。在演示时效果不错。然后产品不断增长：你添加了付费用户层级、企业客户的合规模式、模型可以调用的新工具，以及增长团队想要 A/B 测试的功能开关实验。所有这些都被塞进同一个提示词里。六个月后，你有了 4000 个词的指令，没有人能完全理解，编辑某个部分时行为会不可预测地改变，而调试过程不过是"改点什么看看会发生什么"。

大多数团队会转向可组合的、动态组装的系统提示词——在请求时从模块化组件构建提示词，而不是维护一个静态文本文件。这是一个合理的架构直觉，但实现的复杂度比看起来要大得多。可组合提示词引入了一类静态提示词根本不存在的新型故障模式。

2025 年的一项对照实验让有经验的开发者使用了 AI 编码工具，并测量他们是否变得更快。开发者们预测效率会提升 24%。研究结束后，他们报告自己大约快了 20%。而客观测量显示，他们实际上慢了 19%。

这并不是一个关于 AI 过度炒作的故事。这是一个关于隐性知识的故事——那种存在于每个成熟代码库中、仅靠阅读代码无法恢复的、无文档记录的"为什么"。AI 智能体在全新系统中生产效率出奇地高，正是因为那里几乎没有隐性知识可以违反。它们在成熟代码库中退步，原因完全相同。

大多数团队在反馈采集端的检测体系都非常完善。点击“踩”的操作会被记录，星级评分会流入仪表板，人工标注任务会将每一组偏好对写入表格。数据摄入过程干净、带有时间戳且可查询。

在采集到反馈与下一次模型更新之间所发生的一切，对大多数团队来说都是一个黑盒。

数据被过滤。某些标注的权重被调高。稀有类别被上采样。近重复项被删除。提示词模板的更改导致上个月的标签与本月的不一致，但合并依然在进行。当信号到达奖励模型或微调任务时，它已经通过了 6 个转换步骤，没有审计追踪，没有版本锚定，也无法将退化的模型权重溯源到流水线中特定的损坏点。

这就是反馈溯源鸿沟（Feedback Provenance Gap）：团队知道反馈从何处进入系统，但不知道它在塑造模型行为之前变成了什么。

AI 系统设计中一个常见的错误是要求语言模型像阅读文档一样对图（graph）进行推理。模型会生成一个自信且流利的答案。但这个答案会以一种看起来正确的方式出错——它会列出真实的节点，引用看似合理的路径，并描述几乎存在的关系。接着你会发现，你的组织架构遍历幻觉出了越级经理，你的依赖项解析忽略了超过十个节点的图中的循环，而你的三跳知识图谱查询在第二步时的错误率就达到了 60%。

这不是提示词（prompt）质量的问题。这是一个架构问题，你可以在编写任何提示词之前就诊断出它。