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

一位我上季度合作过的 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 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。

一位资深工程师在四分钟内批准了一个 400 行的 PR。diff 很整洁。命名很合理。测试通过。两周后，值班工程师翻阅一个查询时发现，它返回的行形状是对的，但取错了列 —— 本该用 user.created_at 的地方用了 user.updated_at —— 队列分析仪表板已经对 CFO 撒了九天的谎。审查者很称职。代码结构良好。这个 bug 在 diff 中是不可见的，因为它不是语法异味，而是语义问题。审查者无从着力，因为没有人写下这个变更原本打算做什么。

一旦你代码库中的大部分 diff 都源自模型输出，这种失效模式就会出现。审查者不再问“这正确吗？”，而是开始问“这看起来像代码吗？”。答案几乎总是肯定的。AI 编写的代码在语法上极其流畅，这种流畅性绕过了工程师们花费十年时间在人类编写的烂代码上磨练出来的审查启发式规则。

演示表现完美。法务部门已经批准。销售团队已经在向客户承诺该功能将在下个季度上线。接着，第一次生产环境故障发生了——模型言之凿凿地起草了一个引用了并不存在的合同条款的条文，销售将其发给了客户，法务部门花了三周时间进行损害控制。

这不是一个关于坏模型的故事，而是一个关于沟通失误的故事。工程团队知道模型可能会产生幻觉。法务假设它不会。销售假设任何故障在到达客户之前都会被拦截。运维假设有其他人在专门监控这一点。没有人撒谎。每个人都在基于同一个系统的不同心理模型工作。

大多数 AI 项目失败的根本原因不在于 AI 本身。根据兰德公司（RAND Corporation）对失败的 AI 计划的分析，“对问题定义的误解”——包括对能力限制的沟通误导——是单一最常见的原因。70% 到 95% 的企业 AI 计划未能交付预期成果，而技术本身很少是限制因素。限制因素在于，你组织中的每个团队都在悄悄地构建关于你的 AI 系统能做什么的不同理论，而没有人明确地纠正过其中任何一个。

一家大型保险公司的 AI 系统正在拒绝理赔申请。人工审核这些决定后，发现其中 90% 是错误的。这家保险公司的工程团队构建了性能出色的模型，MLOps 团队有完善的部署流水线，数据科学家有严格的评估指标。但这一切都无济于事，因为在董事会层面，从来没有人回答过这个问题：对于影响病人能否获得治疗的 AI 决策，我们可接受的失败率是多少？

这个缺口——功能正常的技术系统与缺失的高管决策之间的鸿沟——正是 AI 治理在实践中最常出现问题的地方。结果是：组织同时在生产环境中运行 AI，却暴露在从未正式承认的责任风险之下。

在AI工作中遇到困难的工程师，最常见的问题不是缺乏技术知识，而是他们一直在问错误的问题。他们想知道的是："这能用吗？"但他们真正应该问的是："这个系统的失败率是多少，这个失败率对于这个使用场景来说是否可以接受？"

这一转变——从二元正确性转向可接受的失败率——是有经验的AI工程师思考问题的核心差异。听起来简单，其实不然。由此延伸的一切都是不同的：你如何调试、如何测试、如何部署、监控什么、以什么为信心基础。没有完成这一转变的工程师会一直在与工具对抗并且不断失败。

一个周二下午，某中型 AI 初创公司的平台团队合并了一个对共享系统提示的"小幅改进"。到周四，三个独立的产品团队相继提交了 bug。一个团队的评估套件准确率从 87% 跌至 61%。另一个团队的 RAG 流水线开始产生幻觉引用。第三个团队的安全过滤器完全停止拦截某类有害输出。四天后，没有人把这些问题联系起来。

这就是共享提示服务问题，任何拥有多个团队基于同一 LLM 平台进行开发的组织都会遭遇它。

你发布了一个 AI 功能。模型在你的留出集（holdout set）上达到了 92% 的准确率。你把这个结果展示给产品 VP、法务团队和客户成功主管。每个人都点头表示认可。功能上线了。

三个月后，一个你没有专门测试过的客户群体正面临 40% 的错误率。法务部门在提问。客户成功团队正在处理升级投诉。产品 VP 想知道为什么没有人预警。

92% 这个数字在技术上是正确的。但在作为决策输入时，它几乎是毫无用处的 —— 因为整体准确率恰恰掩盖了那些最重要的信息。

一个由十二名工程师组成的团队热情地采用了 AI 编程工具。六个月后，每位工程师合并的 Pull Request (PR) 数量几乎翻了一番。工程经理为此欢欣鼓舞。随后，值班轮换开始频繁报警。调试过程的持续时间延长了一倍。没有人能解释为什么某个特定模块要采用那样的结构。编写它的工程师诚实地回答道：“我不知道 —— 这大部分是 AI 生成的，看起来没问题。”

这种情景正在各地的公司上演。个人生产力的故事是真实的：开发人员更快地完成任务，编写更多的测试，更高效地清理积压工作。但团队层面的情况则更为复杂，大多数组织尚未为此做好准备。