24 篇博文 含有标签「engineering-leadership」

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

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

PR 审查仪表盘连续六周显示绿色。机器人捕获率、评论量、开发者的“点赞”反应——一切都很稳定。然后生产环境发生了一起安全事故，事后分析指向一个缺失的空值检查（null-check），而这个检查机器人以前是能捕获到的，大约在两个月前悄然停止了。没有人更改机器人。没有人降级模型。仪表盘从未变动。但标准变了。

这是自动化代码审查在任何产品演示中都不会出现的失效模式。团队采用 LLM 审查器是为了获得一致性——每个 PR 都遵循相同的检查清单，没有资深工程师因“心情不好”而产生的波动，初级贡献者的周转速度也很快——这种一致性在最初的一个季度确实存在。然后系统提示词（system prompt）演变了，模型升级了，few-shot 库积累了，机器人开始使用不同于团队验证时的模型，根据不同的准则来审查不同的代码库。团队对“机器人能捕获什么”的心理模型衰退成了“机器人上周捕获了什么”。

一名产品市场经理 (PMM) 在发布简报中写下了“AI 智能体 (AI agent)”。新闻稿发布后，将其描述为具备自主决策能力。六周后，工程团队正盯着 Jira 看板上满满的“智能体可观测性”工单，而这些是他们从未针对一个本质上只是“单个提示词后接硬编码工具调度”的系统所规划的。没人撒谎。没人犯技术错误。团队只是意识到，“智能体”这个词并非一种描述——它是一个戳记 (stamp)，而这个戳记带有的运维影响，无论实现方式是否合理，工程团队都必须承接。

这就是 Gartner 如今所谓的“智能体洗白 (agent washing)”的内部版本。外部版本——供应商为了追赶炒作周期将聊天机器人重新包装为智能体——往往会获得媒体关注。而内部版本则更加隐蔽且昂贵，因为这笔账落在了那些在术语被批准时无法反驳的人身上。

发布并不是 AI 功能上线的那一刻，而是平台团队开始接手一个他们从未有机会参与设计的生产系统的瞬间。

产品团队开发了一个功能原型。演示在管理层反响很好。发布日期定了。而在幻灯片与正式上线之间，这个功能在任何人构建评估测试框架 (eval harness)、提示词注册表 (prompt registry)、路由层、成本仪表板、回滚原语、了解智能体 (agent) 运作方式的值班轮岗制度，或针对新供应商 API 密钥的密钥轮换策略之前，就已经上线生产环境了。功能运行正常。演示指标一片大好。而平台团队现在却要为一个基础原语 (primitives) 尚不存在的运维系统负责。

这就是“平台就绪差距” (platform-readiness gap)，也是为什么那些在发布时看起来很健康的 AI 项目，往往在开发到第五个功能时就变得无法管理的最常见原因。

负责构建你公司内部 LLM 网关的团队最初将其范围设定为“限流和审计”。十八个月后，同一个团队正在主持季度分配会议，调解两个产品组之间的配额纠纷，并发现他们为解决容量问题而交付的架构，现在充当着公司内部的 AI 财务部。没有人授权他们担任这个角色，但也没有人把它从他们的职责中拿走。

这是每个 AI 平台团队都在经历的发展轨迹，大多数团队在拥有政策、赞助人、甚至拥有足以支撑决策的遥测数据之前，就已进入了“政治经济阶段”。技术工作——请求路由、密钥管理、重试——是简单的部分。困难的部分在于，有限的供应商配额加上三个有上线期限的产品团队，就构成了一个预算分配系统，而运行网关的团队正是那个被要求进行分配的角色。

一个在内部基准测试中得分 94%、在演示中令利益相关者印象深刻、通过所有离线评估的模型，进入生产后仍然可能跌落至 7% 的真实客户数据有效准确率。这不是假设——这是多个企业 AI 部署中有据可查的结果，也是一种更广泛模式的症状：从"试点成功"到"生产价值"之间的鸿沟，正是大多数企业 AI 悄然消亡的地方。

在各行各业，大约 85–88% 的企业 AI 试点项目从未到达生产。每启动 33 个 PoC，只有四个能够上线。尽管模型能力大幅提升，这一比例三年来几乎没有改变。失败的根源几乎从不在于模型是否足够好——几乎总是在于成功演示与真实用户真正依赖该系统完成实际工作之间所发生的事情。

大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。

这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。

一位我上季度合作过的 Staff Engineer 发现了一个在过去六周内已经被“修复”过三次的 bug。由三位不同的工程师处理，涉及三个不同的文件。三次 CI 运行都顺利通过。三次都采用了由 Agent 生成并被接受的补丁。每一个补丁都让失败的测试通过了，也让用户报告的错误消失了。但每一个补丁都只是把 bug 转移到了别处，潜伏在那里，直到被另一个表现面再次触发。当它第四次出现时，它导致的数据损坏已经静默累积了 40 天。

这个 bug 只是分页游标中一个简单的“差一错误”（off-by-one）。Agent 对于“症状会消失”的判断是正确的，但它对“原因”的判断是错误的。而那些优秀的、资深的、动机良好的工程师们，在理解失败机制之前，就各自接受了一个通过测试的补丁。

这就是“智能代理调试陷阱”（agentic debugger's trap）：你的 Agent 生成修复方案的速度，超过了你构建评估该方案正确性所需的心智模型（mental model）的速度。补丁速度超过了诊断速度。Bug 数量下降了，CI 面板变绿了，而你交付的代码库，其失败模式你却不再理解。

走进一个季度业务复盘（QBR）会议，问问谁的名字写在那个 AI 功能旁边。看看会发生什么。PM 指向平台团队。平台团队指向编写评估工具集（eval harness）的研究工程师。研究工程师指向那个一直在发关于成本图表邮件的 FinOps 分析师。FinOps 分析师又指回了 PM。四个人，一个功能，零个负责人。评估分数已经连续六周下滑，却无人排查，因为监控仪表盘躺在一个上次更新还是发布次日的 Notion 页面里。

这是 2026 年各组织交付 AI 功能最可预见的结果。该功能是由一个攻坚小组（tiger team）发布的，而该小组在发布新闻稿发出的那一刻就解散了。埋点是由一个没有产品授权的基础设施团队生搬硬套上去的。Prompt 是代码库中的一个 prompts/v3.txt 文件，其 Git blame 记录分散在九个工程师身上，谁也不记得为什么第 47 行要写那些内容。面向用户的入口由一位 PM 负责，但他的 OKR 在两个季度前就已经转向了下一个发布项目。这个功能在技术上处于生产环境，技术上有负责人，但在结构上已经沦为孤儿。

你共享驱动器上那份签署了 14 个月的 AI 供应商合同是根据 SaaS 模板起草的。它保证了正常运行时间，指定了安全联系人，并将责任上限设定为 12 个月的费用。但对于你的提示词是否会被喂进下一次训练运行，当你依赖的模型被悄悄换成更小的变体时会发生什么，或者当监管机构询问时你的推理日志存放在哪个地区，它却只字未提。起草它的律师利用他们掌握的词汇量完成了一项称职的工作。但这些词汇量比现在的覆盖范围落后了一个世代。

采购团队仍在为错误的合同进行优化。标准的 MSA（主服务协议）打的是 2010 年代的战争——停机补偿、漏洞通知窗口、进入源代码仓库的知识产权赔偿。AI 供应商关系有着不同的攻击面，而最重要的条款往往在现有模板中连个标题都没有。如果一个团队任由去年的采购指南来处理今年的供应商技术栈，那么他们正在签字放弃一年内就会需要的筹码。

打开公司里那位上线真实的 AI 功能超过六个月的工程师的日历。数一数那些重复出现的 “30 分钟同步 —— 关于 Agent 的问题” 邀请，那些最终被预定的即时 “能耽误你 15 分钟吗？” Slack 消息，那些被标记为 “可选” 但他们实际上不得不参加的架构评审，以及最初只是周五下午的一个时段、现在却每天吞噬两个小时的 Office Hours。然后看看路线图，追踪哪些功能取决于该工程师尚未做出的决定。两者的交集才是你真正的发布时间表。Jira 看板只是虚构。

这就是 AI Office Hours 瓶颈，它在 2026 年的 AI 组织中是核心承重约束，尽管组织里没人会大声说出来。团队快速扩展了 AI 功能开发 —— 每个产品小组都拿到了模型预算，每个 PM 都学会了写 Prompt —— 然后把每一个 “这个模型对吗”、“这里该不该用 RAG”、“我们的评估设计是否有效”、“为什么缓存命中率很奇怪” 的问题都抛给了唯一那个真正上线过足够多生产环境 AI 功能、能给出答案的工程师。六个月后，那位工程师的日历成了半个路线图的限速试剂，“我需要找他谈 30 分钟” 成了你的事故响应本该明确化的核心升级路径。

团队承诺“在本季度交付 AI 摘要生成器”，在第十周通过了技术门槛，在全员大会上庆祝胜利，然后正式上线。六周后，遥测曲线开始向错误的方向弯曲——无声且缓慢，没有人为其制作仪表盘，因为没有人负责这个曲线的走向。OKR 已经被标记为绿色。下个季度的 OKR 已经围绕新功能的发布起草好了。摘要生成器现在成了某个人的次要维护工作，到季度末评审时，团队开始纳闷，为什么在没有任何明显变化的情况下，该功能的客户满意度下降了 15 分。

这不是团队的缺陷，而是运营模式的缺陷。季度 OKR 是为软件校准的，在这种模式下，一个功能可以被界定范围、构建、交付，然后很大程度上就可以不管它，直到下一次重大版本更新。AI 功能不具备这种特性。它们有一条上线曲线和一条持续曲线，而持续曲线才是大部分价值——以及大部分风险——真正所在。将它们视为带有发布日期的交付物的 OKR 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。