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

新员工在入职第三天就上线了一个新功能。团队里的每个人都印象深刻。三周后，她引入了一个 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 采用阶段。