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

你的代码评审正在优化错误的目标。当 AI 智能体（agent）贡献了你大部分的代码提交（commits）时，评审局部正确性——这个函数的功能是否如其所述？——就像是通过检查笔迹来给数学考试评分一样。机器已经通过了你的代码检查工具（linter），运行了你的测试套件，并按照规范格式化了输出。它所引入的 Bug 并不是行内（line-by-line）评审所能捕捉到的那种 Bug。

一项针对 GitHub Pull Request 的大规模研究发现，AI 协同编写的 PR 包含的缺陷是纯人工 PR 的 1.7 倍——其中包含多出 75% 的逻辑和正确性问题、2.74 倍的安全漏洞以及 3 倍的可读性问题。这并不是因为代码看起来有问题，而是因为它在错误的地方做了错误的事情，且对系统的其他部分持有错误的假设。这些恰恰是为捕捉拼写错误和风格违规而优化的传统代码评审所无法发现的故障模式。

一个欺诈检测模型的准确率在三周内悄无声息地下降了一半。延迟正常，错误率为零，所有基础设施仪表盘都显示绿色。工程师们在第一周审计数据管道，第二周比较模型权重，第三周重新审视工单，直到有人发现欺诈者只是改变了他们的语言模式。修复工作——用最近的样本重新训练——只花了两天。而误诊却花了三周。

这种模式在生产环境中的 AI 团队里不断重复：性能下降触发了笼统的“模型问题”警报，团队开始基于直觉而不是根本原因来调整参数。原因并不是缺乏监控纪律，而是大多数可观测性技术栈将三个结构上截然不同的问题混为一谈。模型漂移（Model drift）、数据漂移（Data drift）和提示词漂移（Prompt drift）具有不同的检测特征、不同的警报拓扑结构和不同的修复路径。将它们混淆，就会在错误的修复方案上浪费数周时间。

在每一家拥有成熟敏捷实践并决定增加 LLM 功能的公司，都悄然发生着这样一种失败模式：团队用故事点评估工作，将其分配到为期两周的冲刺（sprint）中，然后连续三个冲刺都报告“完成了 70%”，而工程经理则盯着那张拒绝下降的燃尽图发愁。没人撒谎。功能确实很难完成 —— 因为让故事点成为有用规划工具的条件，在 AI 功能中并不存在，而大家直到投入其中才察觉到这一点。

问题不在于工程师不擅长估算。问题在于故事点编码了关于软件工作本质的假设 —— 而 LLM 功能在结构上（而非偶然地）违反了这些假设。

你的 embedding 模型在周二下午 3 点宕机了。不到 30 秒，你的支持聊天机器人停止回答问题，个性化推荐引擎开始返回空结果，文档搜索一无所获，入职助手也停止工作了。你的值班工程师打开事件频道，看到来自 15 个彼此看不出联系的功能同时发出的告警。没有堆栈跟踪指向根本原因。这看起来像是分布式系统故障 —— 但其实不是。这是一个单一的共享依赖项失效了，而你之前并不知道有 15 个功能共享它。

这就是 AI 功能依赖问题：你的产品功能底层的基础设施层是深度互连的，但你的架构图却将每个功能显示为孤立的方框。当耦合是不可见的，故障传播也是不可见的 —— 直到问题爆发。

当一次人格更新让一个流行的 AI 助手变得明显更加讨好和客气时，工程团队迅速发现了问题，并在几天内发布了回滚。代码更改很干净。模型切换也很直接。然而，用户还是被激怒了——不是因为回滚出错了，而是因为他们中的一些人已经围绕那个“奉承版”建立了工作流。他们的提示策略、审阅环节、对模型置信度信号的解释——所有这一切都针对一个他们再也无法访问的 AI 进行了调整。

回滚代码只花了几个小时。回滚用户却是不可能的。

这种不对称性是 AI 功能管理的中心挑战，大多数工程团队在吃亏之前都会低估它。传统的回滚思维将“撤销”视为一种纯粹的技术操作。对于 AI 功能来说，这只是故事的一半。

上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。

这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。

麦当劳得来速 AI 的失败，并非因为用户抱怨。它失败，是因为用户停止使用得来速。三年来，这套系统一直记录着"健康"的接受率，而病毒式传播的视频却显示顾客在苦苦哀求它从订单中删除 260 块鸡块。当合作关系终止时，官方给出的理由是技术"尚未成熟"。真正的信号其实一直隐藏在客流量数据里——无人阅读，无人量化，无人汇报。

这就是大多数 AI 功能在生产环境中失败的样子。用户不会关闭你的功能。他们不会提交工单。他们不会留下一星评价。他们悄悄地绕开它，而你的仪表板依然一片绿色。

你的 AI 功能上线了。用户正在使用它。每一次会话回放、每一次点踩、每一个返回错误答案的请求，都清晰地暴露出它现在的表现与它应有水平之间的差距。信号就在眼前。问题是：你是否可以合法地利用这些信号。

这就是团队撞上合规高墙的地方。这不是一堵理论上的墙——而是实实在在的。仅在 2024 年，欧洲监管机构就开出了逾 12 亿欧元的 GDPR 罚款，OpenAI、Meta 和 LinkedIn 均在被点名之列。大多数执法行动背后有一条共同主线：以原先收集目的之外的方式使用行为数据，或收集了超出运营功能所必要的数据。监管机构并不会因为你的意图是改进模型而非投放广告就网开一面——尽管工程师们往往这样以为。

大多数工程团队将 API 文档视为开发者体验关注点——一种为了减少支持工单和入职时间而进行的改进。当你的主要消费者是在浏览器中阅读文档的人类时，这种思维方式是有道理的。但现在，这已经不再足够。

当 AI 智能体通过工具调用访问你的 API 时，你的文档就不再仅仅是指南，而是变成了运行时行为。模糊的参数描述不再是 UX 上的不便，而是对模型产生幻觉值的直接指令。缺失的错误代码不再是参考文档中的空白，而是一个模糊信号，可能导致智能体陷入没有退出条件的重试循环。你三年前为人类读者编写的文档，现在正被一个无状态的语言模型解析，无论它是否理解正确，都会自信地执行。

大多数团队在开发初期选择一次上下文格式后，就再也不会重新审视它。一位开发者选择 JSON 是因为它看起来结构化且机器可读。另一位开发者则选择 Markdown，因为他们在 README 文件中一直使用它。当似乎没有其他必要时，普通文本（Plain text）就成了默认选择。这些并不是工程决策——它们只是习惯。并且它们在无形中塑造了你的模型如何进行推理。

你传递给 LLM 的格式并非死板的包装。它本身就是一条指令。结构化的 JSON 上下文会引导模型进入遵循模式（schema-following）的行为。Markdown 鼓励层次化的综合。普通文本则开启了更灵活的推理。即使只是选错了一个格式类别，也可能导致准确率下降 40% 或更多——而且你无法在日志中查看到这种错误。

2025 年，全球新合并的代码中约有 41% 是 AI 生成的。这些代码绝大多数流入了公开索引、被爬取、并最终反哺到下一轮 AI 编程工具训练数据中的生产代码库。其中的含义直截了当，但后果仍在持续显现：AI 模型正日益在前代 AI 模型的输出上进行训练，而没有任何结构化的记录来追踪哪些代码来自何处。

这就是上下文污染问题。它并非假设。反馈循环已在大规模运行，质量影响可以量化，而其失效模式足够特殊——在短期内可能看起来像是进步，而底层分布却在悄然退化。

你上线了一个 AI 功能，运行了一次干净的两周 A/B 测试，看到参与度提升了 4%，然后宣告成功。六个月后，功能全量发布，参与度却持平甚至下滑。测试结果不是因为噪声——而是根本就在衡量错误的东西。

A/B 测试建立在一个假设之上：实验组和对照组的用户在统计上是相互独立的。而 AI 功能会系统性地打破这一假设。用户相互交流、从彼此的行为中学习，并共享 AI 工具的输出结果。当真正的机制是长期的行为适应时，两周内处理效应并不会趋于稳定。忽视这一点，你的实验会给出一个内部自洽却因果无意义的数字。