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

一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。

没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。

行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。

当你第一次尝试像调试服务那样调试 Agent 时，你会发现以往的肌肉记忆完全派不上用场。你设置了一个假设的断点——虽然 IDE 中没有面板可以放置它，但你在脑海中想象了一个——就在 planner 选错工具的那一步。你使用相同的输入重新运行。这一次，planner 选择了正确的工具。你再次运行。它又选了一个你从未见过的第三种工具。Bug 是真实存在的，你的同事今天早上复现了两次，而你用了十五年的调试器突然间变成了博物馆里的陈列品。

这里失效的心智模型并不是“使用调试器”，而是背后更深层的假设：即一个程序在给定相同输入的情况下，会产生相同的执行过程。现代调试器中的每一项功能——断点、单步跳过 (step-over)、观测表达式 (watch expressions)、条件断点、热重载——都是建立在这种确定性之上的。你暂停执行是因为暂停是有意义的。你向前单步执行是因为下一步是可预知的。你检查一个变量是因为它的值是一个事实，而不是从某种分布中随机抽取的结果。

打开你的智能体产品，开启 VoiceOver，然后发送任意提示词。如果你使用的是典型的带有内联推理过程的流式 UI，那么你在接下来的 30 秒内听到的内容并非你的产品。那是一股汹涌的局部 token 流、单词中间的重排、无人播报的状态变化，以及一段视力正常的用户选择查看、但盲人用户却无法逃避的推理独白。在舞台上演示效果极佳的界面，对于屏幕阅读器来说，是一场以语音形式发起的拒绝服务攻击。

这是 AI 团队中没有人会运行的审计。设计评审批准了流式动画。评估套件测量了回答质量。延迟仪表盘追踪了首个 token 响应时间。但这些工具都没有注意到，让某一群体感到产品快速且贴心的功能特性，却让另一群体完全无法使用。这种疏忽正开始出现在亲自诉讼申请中——过去十年一直在处理针对电商网站无障碍投诉的联邦法院，现在看到的 AI 界面相关投诉正急剧增加，据一家追踪机构报告，仅在 2025 年，同比增幅就达到了 40%。

每个 AI 组织都有一个坟场。不是服务的坟场——服务会有操作手册（runbook）、弃用横幅、30 天的迁移窗口，以及在平台团队季度路线图上的位置。这个坟场是属于 功能 的：从未转正的智能摘要 Beta 版、两个大客户据此构建了工作流的自动分类器、演示效果极佳但在灰度发布后无人问津的 Agent 流程。弃用一个端点很容易。但与之关联的其他四个东西——提示词（prompt）、评测员（judge）、回归测试集（regression set）和事故记忆（incident memory）——才是真正需要一个季度才能搞定的，而且团队中没人写过这种手册，因为没人会因为下线某个功能而获得晋升。

这就是差距。大多数关于“模型弃用”的公开讨论都是针对供应商侧的下线：GPT-4o 在某天停止服务，Assistants API Beta 版在 8 月 26 日下线，DALL-E 3 在 5 月 12 日退休，而你的平台团队有一个通知期来进行迁移。这个问题有现成的手册，因为供应商发布了日期，迁移是被迫的，而且工作量可以塞进一个 Sprint 中。而“内部”版本——当你决定你构建的一个功能未能转正并必须将其撤除时——则没有任何这类强制因素。弃用日期由你说了算。迁移路径由你来构建。而且你必须退役的产物不是单个端点，而是一堆纠缠在一起的、与模型相关的资产，你的监控系统几乎感觉不到它们的存在。

在 2026 年的代码审查（Code Review）讨论串中，最昂贵的一句话莫过于“这是 Agent 这么写的”。这并非因为它本身是错的——有时它确实没错——而是因为它终止了本该由此开启的对话。审查者输入一个问题，作者直接引用模型的推理作为回复，讨论在任何人真正开始争论这项变更之前就结束了。反对一个自信且谈吐得体的模型的社交成本，已经悄然高过了合并一个隐蔽 Bug 的成本，而大多数团队在未来两个季度内都无法在指标中察觉到这种权衡。

这不是一个关于 AI 写代码好坏的故事。它会写代码，其中有些还写得不错。这是一个关于当编写代码的摩擦消失时，质量关卡（Quality Gate）会发生什么的故事。审查速度上升，缺陷率也随之同步上升，而这种关联并不明显，因为没有人在追踪审查耗时与缺陷时会关联作者的类别。曾经是代码库品味核心的资深工程师，在一个悄然转向“模型盲从”的文化中，变成了孤独的坚持者。

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

你的状态页是一片绿色。你的错误率为零。你的运行时间仪表盘连续第七个月显示为 100%。然而，在周二上午 9:14，你的客户团队给你转来了一条来自一家财富 500 强客户的消息，上面写着：“我们的团队注意到这周助手的表现变差了。你能告诉我们发生了什么变化吗？”午饭前，你又收到了 12 条类似的反馈。现有的事故沟通手册（incident-comms playbook）无法回答其中任何一个问题，因为那套手册是为停机事故准备的，而现在没有任何东西崩溃。

这就是面向客户的 AI 复盘难题，也是我在将 LLM 功能交付给企业合约的团队中看到的最普遍的差距。可靠性的维度已经从“系统是否在线”转向了“系统是否和上周一样好”，而几乎没有任何沟通基础设施跟上了这一变化。状态页上没有相应的展示块。严重性等级标准（Severity rubrics）没有对其进行评分。支持服务的回复模版默认为“我们发现了一个问题并已解决”，这取决于客户当天的情绪，听起来要么是敷衍，要么是危言耸听。

你公司最昂贵的评测集 (eval set) 并不在你的代码仓库里。它藏在销售工程师六个月前整理的一份幻灯片里，外加三个以你前五大客户命名的演示账号，以及一段半记不清的脚本，上面写着“点击这里，让智能体总结上个季度，见证奇迹的时刻”。它每周运行一两次，面向价值六位数或七位数的潜在客户。AI 团队里没有人曾为它完整跑过一次。

接着，你在某个周二发布了模型迁移。周四下午 4 点，销售工程师在值班频道发消息：摘要输出现在以“当然可以！这是摘要……”开头，而不是直接进入要点；数字被拼写成了单词而非阿拉伯数字；而潜在客户 —— 一位在四周前就预约了这次会议的财富 500 强 CFO —— 刚刚询问该产品是否一直这么啰嗦。发布说明称这是一次 1.2 个百分点的评测提升 (eval lift)。

评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。

这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。

十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。

大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。