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

一位资深工程师在四分钟内批准了一个 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 生成的，看起来没问题。”

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

新员工在入职第三天就上线了一个新功能。团队里的每个人都印象深刻。三周后，她引入了一个 Bug，一位资深工程师只用了五个字就解释了原因：“我们不那样做。”她对此一无所知，写出那段代码的 AI 也是如此。

AI 编程助手极大地缩短了新工程师完成“首次提交”的时间。但这种速度掩盖了一个大多数团队都没有察觉到的权衡：过去那种让初级工程师速度慢下来的“代码阅读”过程，恰恰是教会他们系统如何实际运作的关键。剥离了这个过程，你得到的就是那些能够将自己不理解的功能发布到尚未内化的架构中的工程师。

问题不在于工具。而在于我们没有更新入职流程，以适应 AI 现在所做的工作 —— 以及它不再要求工程师亲自去做的事情。

这里有一个令人不安的模式：你的团队计划在下个季度推出的 AI 功能，其实早在两年前就在公司里“死”过一次了。它当时以不同的名称发布，带着不同的提示词（prompt），解决一个略有不同的问题，并在经历了六个月的增长停滞后被悄然关停。没有人记录它，没有人把这些点串联起来。本可以拯救这个周期的领先指标，一直躺在那些随功能一起被归档的数据看板里。

大多数工程组织都是为了记住成功而设计的精妙机器。发布会有复盘、博客文章和内部庆祝。但那些被砍掉的功能——尽管有精美的演示，但周活跃用户仅为 12% 的功能；当 Token 成本在超预期的工具链中叠加时导致单位经济效益倒挂的功能；那些用户先是学会信任、随后失去信心、最后完全绕开的功能——几乎没有留下任何组织记忆。而这些“死亡”中蕴含的失败模式，恰恰是你的规划流程无法预估并纳入成本的。

某公司在向整个工程团队全面推广 AI 编程助手三个月后，发现了一个令人不安的现象：代码审查通过率下降了 18%，迭代速度有所提升，但生产故障数量却在攀升。当他们在一次事后复盘中要求开发者解释最近一个由 AI 生成的模块时，在场的所有人都说不清楚——就连提交合并的那位工程师也不例外。

这就是认知外包陷阱。问题的根源不是 AI 工具本身，而是团队整合它们的方式。

大多数招聘 LLM 岗位的工程团队进行的面试大同小异：两轮 LeetCode，一个系统设计问题，可能还有一个关于 Transformer 内部机制的小测验。他们考核的重点不对 —— 而且他们自己也知道。那些在这些筛选中表现优异的候选人往往难以交付实际可用的 AI 功能，而那些在二叉搜索上栽跟头的候选人却能从零开始构建一个评估套件，并在一个下午内调试好一个产生幻觉的流水线。

能预示在 LLM 工程领域取得成功的技能，与传统机器学习或软件面试所测试的内容几乎没有交集。尚未更新招聘流程的招聘经理正在产生大量的漏选（false negatives）—— 拒绝了本可以成功的工程师 —— 而误选者（false positives）则带着扎实的 LeetCode 分数步入公司，却对模型何时在自信地胡说八道毫无直觉。

三年前，"AI 团队"意味着一群藏在组织架构角落里的专家，对产品工程师基本不可见。如今，一位金融科技公司的高级软件工程师，周一用微调模型上线欺诈评分功能，周三为客户支持搭建 RAG 管道，周五调试 LLM 延迟问题。专家并没有消失——但"AI 工作"与"产品工程"之间的边界，消失得比几乎所有人预想的都快。

大多数团队的应对方式是把新头衔贴在旧职位描述上，然后宣告完事。这是错误的答案，功能失调很快就会显现：所有权不清、工具重复，以及一个 ML 平台团队把半数时间花在解释"为什么产品团队不能直接调 OpenAI API"上。

本文探讨如何把结构搭对——不是抽象地谈，而是针对大多数工程组织实际经历的 AI 采用阶段。