990 篇博文 含有标签「insider」

你的平台团队通过开发者采纳度来衡量成功。内部 API 的月活跃工程师数量。新服务的首次调用时间（Time-to-first-call）。季度 DX 调研中的净推荐值 (NPS)。每一个指标都假设请求的另一端是一个人类——一个阅读入门指南、复制 curl 示例、并在错误消息毫无帮助时在 Slack 中抱怨的人。

这种假设正悄然变得不再成立。你内部 API 增长最快的消费者不是人，而是一个智能体 (Agent)：一个正在解决工单的编码助手，一个在夜间核对发票的工作流，或者一个为了回答一个问题而调用六个服务的支持机器人。这些调用者不会浏览你的文档——它们会将你的工具模式 (tool schemas) 摄取到上下文窗口中。当错误提示模糊不清时，它们不会提交 bug——它们会默默地重试、消耗 token，然后放弃。而且它们的数量即将超过人类。

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

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

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

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

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

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

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

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

当一个团队的推理端点开始无法达到延迟目标时，他们做的第一件事通常是购买更多的 GPU。一个月后，他们会发现第二件事：p99 延迟几乎没变，而账单却翻了一倍。显卡利用率徘徊在 40%，而尾部延迟依然很难看。有人添加了自动扩缩容（autoscaler）。自动扩缩容频繁震荡。现在有了更多的显卡，更高的成本，以及来自同一批用户的同样抱怨。

错误在于将推理缓慢视为容量不足。事实几乎从未如此。你面临的是一个披着容量问题外衣的排队问题。LLM 端点的尾部延迟取决于大小迥异的请求如何随时间共享固定的计算池——这是典型的调度问题，而非资源配置问题。在你理解服务栈实际运行的排队规则（queue discipline）之前，你添加的每一块 GPU 都只是更昂贵的变慢方式。

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

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

临床决策支持工具的任务只有一个：帮助医生使用他们在病历中使用的词汇来推理症状、药物和治疗方案。这意味着智能体必须能够直呼其名地讨论药物过量阈值、药物相互作用、禁忌症和剂量。这些都不是可选的。这就是产品本身。

因此，当模型在会诊中途打断，对面前就有患者的专业医生说，没有专业监督就无法提供医疗建议时，这是一种特殊的失败。医生没变，患者没变，提示词也没变。改变的是团队并不拥有的安全过滤器，它是针对团队并不属于的人群进行微调的，并按照团队无法控制的时间表进行更新。

这就是“供应商审核裂缝”（vendor moderation seam），它是应用 AI 领域讨论最少的边界之一。大多数团队将供应商的安全层视为模型的固定属性，就像上下文窗口一样。但事实并非如此。这是一种策略——一种动态的策略——无论你是否编写了它，现在它就是你产品的策略。

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

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

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

大多数财务团队都把第一张 LLM 账单放错了地方。它出现在实验阶段，当时只有少数工程师正在使用 API 密钥进行原型设计，它看起来确实就是当时的样子：研发支出 (R&D)。每月花费几千美元来弄清楚这项技术是否可行。因此，无论是在认知上还是在实际操作中，它都被归入了研发支出，没有人对此深究。

随后，功能上线，使用量攀升，第一季度还是可以忽略不计的误差项，到了第四季度就变成了云服务账单中增长最快的成本。问题从来不在于金额大小。问题在于成本已经悄然改变了类别——从对构建某项功能的固定投入，变成了服务每一位用户的变动成本——而思维模型却没有随之转变。

这种分类错误是目前 AI 产品中最昂贵的会计错误，而且它本质上甚至不是会计错误，而是预测错误。

每个发布 LLM 功能的团队最终都会开同一种会。有人会问：新模型 —— 或者新提示词、新的检索优化 —— 是否已经好到可以发布。整个周末都在进行测试的高级工程师说，感觉效果更犀利了。产品经理（PM）则提到，上周正好有客户投诉过这个问题。团队里的怀疑论者翻出一份对话记录，显示旧版本明显更好。45 分钟后，没人改变主意，最后的决定要么由发言最积极的人做出，要么由职位最高的人拍板。

那场会议是一个症状。它之所以反复出现，是因为团队正试图用轶事（anecdotes）来解决一个实证问题 —— 这次变更究竟是让系统变好了还是变坏了？而轶事是无法收敛的。你可以整天堆砌这些案例。争论永无止境的原因在于，缺乏一个大家都同意受其约束的共享工具。那场本该是 Eval 的会议，就是你发现自己正缺少一个 Eval 的时刻。

你的团队采用编程 Agent 的那个季度，发生了两件没人会放在同一张幻灯片上的事情。吞吐量上升了 —— 更多的 PR、更多的合并代码、更多的工单被关闭。然而，你最资深的三位工程师却变慢了。这种慢不是因为偷懒，而是因为“溺水”。他们自己的提交量枯竭了，日历被评审任务填满，一对一面谈的主旋律也从“这是我交付的内容”变成了“我花了一整周时间在帮别人排障”。

这就是“资历倒挂”。那些本该通过 AI 获得更多杠杆效应的人，反而被它埋没了。这既不是动力问题，也不是工具差距，而是 Agent 改变工作形态后的结构性后果：它们让生成变得廉价，而让验证变得昂贵。验证正是你无法交给初级人员或其他 Agent 的那一项任务。

一项提示词变体（prompt-variant）实验在某款 AI 辅助搜索产品的生产流量上运行。成功指标是点击响应中的任何建议操作。变体 B 交付的响应长度增加了大约 40%，且包含更多列举出的选项。点击率（CTR）高出 11%，且具有三个九（99.9%）的统计显著性。该实验被判定为获胜并上线。

一个月后，每周客户满意度调查下降了两个点。没人将其与上线联系起来，因为实验已被记录为成功，团队已经转向其他工作。季度复盘最终将满意度下降追溯到提示词的更改，诊断结果令人难以接受：变体 B 胜出并不是因为它给了用户更好的答案，而是因为更长的回答包含了更多的点击表面（clickable surfaces）。点击处理器在每次展示中触发得更频繁，是因为有更多可点击的内容，而不是因为你阅读的内容更值得采取行动。