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

这是一个你应该比现在更关注的数字：在模型生成第一个 token 之前，云端 LLM 端点的中位网络往返延迟在 48 到 800 毫秒之间。这不包括推理时间，也不包括排队时间。这是“走出大楼”的代价——DNS 解析、TLS 握手、往返最近数据中心的传输。对于单次聊天补全，你从未注意到它。但对于一个需要进行九次连续工具调用来回答一个问题的智能体，你刚刚交付了 5 秒钟的纯传输延迟，而你的用户能真切感受到其中的每一点。

大多数团队将往返延迟视为业务的固定成本，认为可以通过流式传输和加载动画来优化。但对于越来越多类型的工作负载来说，往返延迟本身就是 Bug。你需要的模型足够小，完全可以在数据所在地运行；任务足够重复，导致边际云端成本累积成一笔巨款；数据足够敏感，将其发送给第三方是你一直在默默承受的风险。端侧和边缘推理是大多数工程团队会反射性拒绝的选项——“本地模型不够好”——而这种拒绝正变得越来越站不住脚。

几十年来，从初级工程师到高级工程师的晋升之路都要经过一堆枯燥乏味的工作。你修正了错误信息中的拼写错误。你为别人编写的函数编写了单元测试。你在凌晨 2 点追踪一个贯穿四层调用栈的空指针，并从切肤之痛中学会了防御性检查存在的意义。没有人专门设计这种课程。它的出现是因为廉价、低风险的任务恰好是培养判断力所必需的任务。

这套课程正在被删除。过去用来培训初级工程师的工作——样板代码、初稿、琐碎的 Bug 修复、测试脚手架——现在成了我们交给智能体（Agent）的工作，因为它们廉价且高效。我们在优化掉繁杂工作的同时，却没有意识到它也是课堂。结果是技能阶梯缺失了底部的横木：我们顶部依然有高级工程师，底部有 AI，而中间原本形成中级判断力的鸿沟却在不断扩大。

这不是一个通过发布更多入门级职位需求就能解决的招聘问题。这是一个学习问题。那些曾经起到教学作用的任务消失了，而剩下的任务——审查智能体的输出、分解模棱两可的问题、决定 不 构建什么——都是我们过去认为人们必须赢得资格才能去做的难题。如果你想在 2032 年拥有高级工程师，你就必须刻意去制造那些过去纯属偶然产生的经验。

二十年来，文档一直是良好初衷的坟墓。你在第一个 Sprint 期间编写 README，那时架构整洁，你的热情高涨。但没人读它。到了第三个 Sprint，它就开始在构建命令上误导人，到了第六个 Sprint，它描述的是一个早已被删除的服务。文档是每个人都同意缴纳但实际上没人在缴的税 —— 一种没有反馈循环的道德准则。写了烂文档，什么也不会发生。不写文档，同样什么也不会发生，因为高级工程师把架构都记在脑子里。

然后我们将编程 Agent 指向我们的代码仓库，反馈循环一夜之间降临。README 现在是你拥有的杠杆率最高的文件 —— 这并不是因为有人做了关于文档规范的励志演讲，而是因为该文件的质量现在直观地决定了你的 Agent 是交付正确的代码，还是会信誓旦旦地对一个已不存在的架构产生幻觉。

这就是文档的复兴，而它与我们过去编写的文档几乎毫无关系。

传呼机在凌晨 2:14 响起。结账服务正抛出 500 错误，收入在流失，而你是值班工程师。你调出故障模块并开始阅读。代码很整洁——函数命名规范，结构合理，甚至还有几处有用的注释。然而你完全不知道它是干什么的。代码不是你写的。你团队里的任何人都没真正写过它。四个月前，一个智能体（agent）生成了这段代码，它通过了评审，测试通过了，并从此在生产环境中运行。现在它出故障了，而那个理应修复它的人却是第一次见到它。

这就是理解债（comprehension debt）：你的组织运行的代码量与人类实际理解的代码量之间日益扩大的差距。它不会显示在仪表盘上。当一切看起来都健康时，它在默默累积，并在最糟糕的时刻——在事故期间，当你对自己系统的理解不足其代价是以停机时间来衡量时——到期偿还。

你的仪表盘从未如此好看。合并的 Pull Request (PR) 数量几乎翻倍。每个工程师的提交次数正在攀升。代码行数源源不断。每一个活动图表都呈现上升趋势，你在六个月前引入的 AI 编程工具看起来是公司今年最划算的一笔支出。

然后，你检查了一个没人会放在幻灯片里的数字：客户从提出需求到实际拿到东西需要多长时间。这个数字纹丝未动。在某些季度，它甚至变得更糟。团队正在产出更多的一切，除了业务真正买单的东西。

这就是“速度幻象”。容易统计的指标上升了，而真正重要的结果却在悄然下滑。这是目前工程领域最昂贵的衡量失败之一，因为它看起来完全像是成功。

有一种特定的遗憾，只发生在 AI 团队中。你花了一个季度的时间构建了一个复杂的变通方案——多步提示词链、自定义重排序器（reranker）、手动调优的工具路由层——然后上线。它起作用了。但六周后，一个新模型发布，一次调用就能原生完成所有这些工作，你一个季度的工作现在变成了必须清除的累赘。功能没有失败。底座（Floor）移动了。

这是 2026 年规划 AI 功能的结构性问题：你构建其上的底座改进速度快于你的发布周期。从 2023 年到 2025 年中期，前沿实验室大约每六个月发布一次。到 2026 年第一季度，这一周期缩短至大约每四周发布一次重大版本，甚至出现过五个实验室在 13 天内密集发布的情况。在你规划和发布之间，你脚下的根基正在发生变动。

询问任何工程主管，他们是否被模型供应商锁定了，他们都会指向抽象层。“我们通过网关路由所有内容。更换供应商只是配置更改。”端点只有一行代码。Base URL 是一个环境变量。在纸面上，迁移只需要一个周二下午。

然后他们尝试了。他们将配置切换到不同的模型系列，集成测试依然通过，但生产环境却悄然崩溃。原本总能解析的 JSON 现在被包裹在 Markdown 代码块中。准确率曾达 94% 的分类器降到了 80% 出头。一个稳定运行了一年的提示词开始因为无人能复现的原因，在每 20 个请求中拒绝 1 个。端点在几秒钟内完成了切换，但行为并没有随之迁移。

这就是没人预料到的锁定。它不在你的合同或 SDK 中，而是在你的提示词（prompts）中——你的团队为了适应单一模型系列的特性，一次又一次地做出的数千个细微调整。你选的不是模型，而是与之“联姻”，而“婚前协议”就是你发布过的每一个提示词。

一位工程副总裁决定公司需要“做 AI”。公司已经有一个机器学习团队——三个人，他们构建了推荐模型，调整了反欺诈分类器，并维护着一个特征存储（feature store）。显而易见的举措是让他们负责新的 LLM 项目。他们懂数学，也发布过模型。能有多大区别呢？

六个月后，原型演示效果惊艳，但在生产环境中却惨遭失败。没人能解释为什么智能体（agent）偶尔会订错会议，每个请求的成本是预估的四倍，而且根本无法判断上周的提示词（prompt）更改是让情况变好了还是变坏了。机器学习团队感到很沮丧，因为他们擅长的所有工具——梯度下降、数据流水线、超参数搜索——在他们既无法重新训练也看不透内部构造的模型上都派不上用场。

这是目前 AI 领域最常见的组织架构错误，它源于一个听起来很合理的假设：构建模型的技术与基于模型构建应用的技术是同一份工作的不同标签。事实并非如此。它们之间的重合度甚至比“前端工程师”和“后端工程师”还要低。

最近我交流的一个团队花了三个工程师周的时间，将平均 Prompt 从 4,000 Token 削减到了 2,600 Token。他们以此为荣 —— 纯 35% 的降幅，实打实的数据，幻灯片里漂亮的图表。然后有人反向算了一笔账：这笔节省每月大约为 1,800 美元。而他们投入的三个工程师周，折算成全额薪酬成本大约是 25,000 美元。按照这个月度消耗率，这笔优化大约需要 14 个月才能回本 —— 这还是假设 Prompt 永远不变、模型永远不降价，且那些工程师没有更有价值的东西可做的情况下。

然而，这些假设一个都没成立。下个季度 Prompt 改了两次。他们使用的模型本身就降价了 40%。而那些工程师那个月没能发布的特性，恰恰是最大客户一直询问的功能。

看看任何 AI 产品的路线图，你都会发现用来列出准备发布之物的分栏：一个新的智能体、一个更好的检索流水线、一次模型升级、一次微调。每一项都是一个“诞生”。看板上没有任何一项代表“死亡”。没有一栏是留给你将停止支持的模型、将停用的提示词、将归档的评估集或将关闭的功能的。路线图从构造上来说就是乐观的——它们是你承诺去创造的未来清单。

对于确定性软件来说，这种遗漏并无大碍，因为你两年前发布的功能在你不改动它时大多能保持运行。但对于 AI 系统来说，这却是无声的灾难，因为无论你是否触碰它们，你发布的东西都在腐化。针对 GPT-4 的特性而优化的提示词，在提供商调整模型的那一天就会退化。针对去年的失败模式编写的评估套件，将不再能衡量任何真实的问题。你所依赖的模型可能会收到一个你并未规划的 60 天弃用通知。一份只规划发布的路线图，在它未追踪的每一行中都在积累隐形负债。

18 个月前，“我们构建了自己的检索流水线”在架构评审中还是一个非常合理的说法。你拥有分块策略、经过基准测试的嵌入模型、调优过的向量数据库、重排序器，以及一个由 3 名工程师耗时一个季度才搞定的上下文填充启发式算法。那一套技术栈曾是真正的差异化基础设施。而今天，同样的能力只需一次托管的工具调用：将文件上传到向量数据库，将其附加到请求中，供应商就会完成解析、分块、嵌入、存储、检索和重排序——所有这些都隐藏在一个 API 背后。曾经需要 3 名工程师开发一个季度的成果，现在只是一个配置对象。

这就是目前构建 AI 产品令人不安的模式。自建与外购之间的界限并非固定，它在移动，而且只向一个方向移动。每隔几个月，模型供应商就会发布一个原生功能（primitive），蚕食掉你曾经拥有的一个层级：记忆、检索、结构化输出、工具路由，甚至是多步编排。上个季度还让你引以为傲的基础设施，这个季度就成了竞争对手可以免费获得的东西，而且默认配置更好，延迟底线更低，因为它就运行在供应商自己的数据中心内部。

一种本能反应是将其视为需要防范的威胁。但这种思维框架是错误的。供应商吸收通用基础设施实际上是在帮你——它帮你删除了你本就不想要的维护工作。真正的问题在于，你选择构建的东西是位于不断上升的水位线之上还是之下。大多数团队从未明确做出这个决策。他们为了演示需求构建了一切，一年后才发现 70% 的代码库是在重新实现供应商现在提供的原生功能，而那 30% 真正具有防御性的部分反而因为缺乏关注而枯萎。

演示成功了。你输入了一个问题，智能体调用了三个工具，经过多步计划的推理，最后给出了一个让全场人都为之振奋的答案。有人说：“上线吧。”三个月后，你的产品依然没有上线，而且没人能解释时间都去哪儿了。

时间都花在了这里：演示只占了 10% 的工作，它只是大脑。剩下的 90% 是管道工程——那些在正常运作时无人喝彩，一旦出故障就是灾难性的评估（Evals）、护栏（Guardrails）、可观测性、成本控制和备用路径。这 90% 就是“从演示到生产的税”，而大多数团队在做预算时，却把它当成了一个可以忽略不计的舍入误差。

数据说明了另一番景象。MIT 2025 年的一项企业 AI 研究发现，95% 的生成式 AI 试点项目未能产生可衡量的损益（P&L）影响。另一项分析则更加直截了当：企业每启动 33 个概念验证（PoC）项目，只有 4 个能进入生产阶段。这意味着夭折率高达 88%，而死因几乎从未出现在模型身上，而是演示让你跳过的所有环节。