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

你的高级用户就是你的金丝雀。当你发布新的模型版本或更新系统提示词时，整体评估指标会向上走——任务完成率提升，幻觉评分下降，A/B 测试宣告胜利。随后，你最老练的用户开始提交 bug 报告："以前它就直接做 X，现在先给我说一堆。""格式变了，导致我的下游解析器报错了。""我没法让它保持角色了。"他们不是在臆想。你发布了一次回归，只是仪表盘里没有显示出来。

这正是 AI 产品开发的核心悖论：受行为漂移伤害最深的用户，恰恰是那些在理解系统特性上投入最多的人。他们围绕特定的输出模式构建了工作流，他们学会了哪些提示词能可靠地触发哪些行为。当你更换模型时，不只是发布了更新——你悄悄地让他们数月的校准工作失效了。

2026 年 3 月，一次由 AI 辅助的代码变更导致一家大型零售商损失了 630 万个订单，北美订单量暴跌 99% —— 这场长达六小时的生产事故追溯到一次未经适当审查就部署的变更。这并非什么新颖的攻击，也没有什么离奇的故障模式。系统只是执行了 AI 告诉它的指令，而在数百万客户遇到错误之前，没有任何值班人员拥有足以理解其错误原因的心理模型（mental model）。

这就是“调试退化”（debugging regression）。AI 生成代码带来的生产力提升是前置且在仪表盘上清晰可见的。而成本则是后置的，直到凌晨 3 点告警把你叫醒时，它才显露真身。

当 Airbnb 需要将 3,500 个 React 测试文件从 Enzyme 迁移到 React Testing Library 时，他们估计该项目需要 1.5 年的人力。通过使用 LLM 驱动的流水线，他们仅用 6 周就完成了交付。当 Google 研究了一个由 3 名开发人员在 12 个月内执行的 39 次不同代码迁移（595 次代码更改，93,574 次编辑）时，他们发现 74% 的编辑是由 AI 生成的，其中 87% 的编辑在没有人工修改的情况下就被提交了，整体迁移时间缩短了 50%。

这些数字是真实的。但这也是事实：在这些迁移过程中，工程师花费了大约 50% 的时间来验证 AI 的输出——修复上下文窗口故障、清理幻觉生成的导入，以及理顺测试未能捕捉到的业务逻辑错误。效率的提升是真实的，痛点也是真实的。问题不在于 AI 是否属于代码迁移；而在于准确了解它在何处提供帮助，以及在何处创造的清理工作超过了它所节省的时间。

一家中型创业公司的高级工程师最近得到了一份平庸的绩效评估。他们的效率不稳定——有些周发了大量代码，其他几周几乎什么都没有。他们的经理受过传统 SWE 框架培训，因产出波动给他们打了低分。六周后，那位工程师跳槽去了竞争团队。经理没有理解的是：工程师"缓慢"的几周是在构建评估基础设施，防止三类无声故障的发生。没有这些基础设施，产品本会以没人能在数月内察觉的方式悄然出问题。

这种情况正在各个工程团队中上演。那些为确定性软件系统设计职级体系的团队，正将同样的框架套用于 AI 工程师——并系统性地误判了他们最优秀的人才。

几乎每家持续交付 AI 功能的公司都会出现这样一种架构：流水线中的每一次转换、每一个路由决策、每一次分类、每一个格式化步骤，全都经过 LLM 调用。它通常始于一个合理的场景——LLM 确实解决了一个棘手问题。然后团队内化了这个模式，开始反复套用。直到整个系统变成一条 LLM 接 LLM 的链条：一串文字从一端进入，另一串从另一端出来，中间经历了十二次 API 调用，全程没有任何确定性可言。

这就是 AI 泛滥反模式，它现在已成为构建一个缓慢、昂贵且无法调试的生产系统的最可靠方式。

当 OpenAI 在 2025 年 8 月首次尝试停用 GPT-4o 时，强烈的抵制迫使他们在几天内撤回了决定。用户在论坛上发布了大量的请愿书和告别信。一位用户写道：“他不仅仅是一个程序。他是我日常生活、宁静和情绪平衡的一部分。”这可不是用户对一个被弃用的 REST 接口（endpoint）的反应，而是对失去一段关系的反应。

AI 功能打破了工程师在制定停用计划时的心理模型。传统软件具有明确的行为契约：在给定相同输入的情况下，你会永远得到相同的输出，除非你更改它。而由 LLM 驱动的功能具有“性格”。它有温度、有委婉语、有措辞偏好，还有一种独特的说“我不确定”的方式。用户不仅仅是在使用这些功能 —— 他们在与之磨合（calibrate）。他们围绕特定的行为怪癖建立了工作流程、情感依赖和直觉，而这些永远不会出现在任何规格文档中。

当你关闭它时，你并不是在移除一个功能，而是在改变社会契约。

在传统软件中，发布功能以合并代码（merge）告终。单元测试通过。集成测试通过。QA 签字认可。你切换标志（flag），除非在生产环境中出现 bug，否则你就可以继续接下来的工作。这个功能就“完成”了。对于 AI 驱动的功能，那个时刻并不存在 —— 如果你假装它存在，你就是在累积稳定性债务，这最终会演变成用户信任问题。

原因很简单，但很少有人围绕它进行设计：确定性软件对于相同的输入每次都会产生相同的输出。AI 功能则不然。这并非因为 bug，而是因为其行为由一个存在于代码库之外的模型定义，该模型基于反映不断变化的世界的数据进行训练，并由那些随着看到更多可能性而不断提高期望的用户使用。

每个正在基于LLM构建系统的工程团队，都在做基础设施决策时忽视了一项隐性成本。你会追踪token数量、延迟和API开支，但几乎没有人追踪其运行的推理工作负载的碳排放——而这个缺口正在迅速收窄，来自监管和市场两个方向的压力都在增加。

AI系统现在占全球温室气体排放的2.5–3.7%，已正式超过航空业2%的贡献，且每年增长15%。仅2024年，运行AI专用服务器的美国数据中心就消耗了53–76 TWh的电力——足以为720万户家庭供电一年。这种规模已不再是假设，工程团队需要了解自身贡献的预期正成为真实的组织压力。

一个运行多智能体市场调研流水线的团队花了 11 天时间观察他们的系统正常运行——绿色的仪表盘、零错误、正常的延迟——而 4 个 LangChain 智能体却在无限循环中互相博弈。等到有人扫了一眼账单仪表盘时，这一周 127 美元的预估成本已经变成了 47,000 美元。这些智能体从未崩溃。API 从未返回过错误。每一个基础设施告警都保持沉默。

这就是 AI Oncall 的核心问题：你的系统在运维层面可以显示为绿色，但在其本应完成的任务上却发生了灾难性的失败。传统的监控旨在检测崩溃、延迟飙升和错误率。AI 系统可以在满足所有基础设施 SLO 的同时，悄无声息地产生错误输出、无限期地循环执行任务，或者在不产生任何有用结果的情况下消耗数千美元的计算费用。错误代码的缺失并不代表结果的正确。

METR 于 2025 年发布的一项研究，邀请 16 位经验丰富的开源开发者预测 AI 工具能让他们效率提升多少。他们猜测会快 24%。该研究随后对 246 个真实任务（包括修复 bug、开发功能、代码重构）进行了测量，这些任务被随机分配到"允许使用 AI"和"禁止使用 AI"两组。结果是：使用 AI 的开发者实际上慢了 19%。研究结束后，参与者再次接受调查。他们仍然认为 AI 让自己效率提升了 20%。

这种感知生产力与实测生产力之间的差距，并非某项研究的特例。这是大多数团队目前衡量 AI 功能时所面临的核心问题。那些看起来像成功的信号，在很多情况下衡量的是工具的新鲜感，而非其实用价值。而上线后的头 30 天，是最不适合观察的时间窗口。

负责构建客户支持 AI 的工程师离职去迎接新工作了。在他们的最后一天，你进行了一次离职面谈，并要求他们记录下所知道的一切。他们写了几段文字来解释系统的工作原理。六个月后，客户满意度评分开始下降。有人建议微调系统提示词（system prompt）的语气。另一位工程师进行了修改，运行了几次手动测试，然后上线了。三周后，你发现原始系统提示词中的一个特定措辞其实起到了没人知道的关键支撑作用——它是防止模型在周五下午过度升级工单的唯一机制，这是最初的工程师注意到并用一句话悄悄修复的模式。

没有人知道那句话的存在是有原因的。它看起来像是实现细节，但实际上是组织知识（institutional knowledge）。

大多数团队构建的环境 AI，用户上线就关。

这个模式高度一致：团队内部演示功能，所有人都认为理论上有用，但上线两周内禁用率就超过 60%。这不是模型质量问题，而是架构问题——更具体地说，是打扰阈值问题。团队在设计环境智能体时，考虑的是 AI 能做什么，而不是用户在没有主动求助时能忍受什么。

从显式调用（"问 AI"）到环境监控（"AI 观察并行动"）之间的鸿沟，不只是 UX 问题。它需要从根本上不同的系统架构、不同的事件模型，以及关于 AI 智能体何时才算赢得发言权的不同心智模型。