你的工程师没有AI技能鸿沟，他们有的是许可问题

原文：Your Engineers Don't Have an AI Skill Gap. They Have a Permission Problem. by Brian Madison

在当今大多数工程组织中，AI编码工具实际能做的事与工程师实际在用它做的事之间，存在一道鸿沟。这道鸿沟很宽，而且不会自行弥合。采购方试图弥合它的标准动作——采购、发布邮件、午餐学习会、无会议周五——同样没有效果。这就是企业健身房会员卡问题在工业规模上的重演：许可证已经部署，欢迎邮件已经发出，几个热心人确实从器械中获得了真正的价值，而团队其他人仍然在做健身房开业前大致相同的事情。

我从这道鸿沟的两边都经历过。我曾在敏捷转型咨询领域工作多年，常驻在客户组织中数周甚至数月，帮助团队改变他们计划和交付的方式。我相信那项工作，现在依然相信。原则是正确的，证明就在于我离开咨询之后的这些年里，我亲手打造了多个产品工程团队，使它们成为敏捷所追求的那种有纪律、协作默契、运转顺畅的组织。方法确实有效，但和任何手艺一样，它只有在被练习、被施压、被锻炼、被内化到感觉自然的程度时才有效——而这是任何工作坊或PPT都从未实现的状态。反复练习才能做到。我后来慢慢且不安地认识到的是，那些请我去做咨询的公司其实并不需要变革真正持久，他们只需要变革持续到可以开出发票的时间，并且失败得足够彻底，以便同一家公司在六到十二个月后再打电话回来要求重新培训。失败不是合作的缺陷，不，朋友们，失败是内置的营收模式。

失败不是合作的缺陷，朋友们，那是内置的营收模式。

我现在把大量时间花在帮助组织采用AI原生工程实践上，这正是我写这篇文章的原因。这个模式正在重演。那些从敏捷转型的部分成功中获利的公司，已经改头换面成了AI转型公司，交付物更花哨，PPT更厚重，底层引擎却一模一样。

看看目前最引人注目的版本：前沿部署工程师（FDE），从AI实验室来到客户团队中，帮助他们用实验室的工具完成真正的工作。这个模式在最佳状态下确实有用，因为FDE带来了关于Agent实际行为和什么技术能在规模上产生可靠结果的深度、前沿的专业知识，这是大多数组织无法在需要的时间内内部构建的知识。在任何此类合作（FDE或其他）开始前值得问的问题是：当嵌入专家离开时，你的团队是什么样子？你的工程师是否发展出了构建、演化和控制自己AI流程的能力，还是他们主要学到了专家的思维方式——一种有利于专家每六个月回来的方式？两种答案都不是注定的；它完全取决于合作的结构，取决于内部能力转移是设计目标还是副产品。结构性风险与每一次敏捷转型所伴随的风险相同：当能力存在于顾问而非团队中时，能力会随顾问一起离开。

在我找到真正有效的方法之前，我让自己的工程团队尝试了这种模式的每一种变体——那些我曾经作为顾问推销的，和后来作为管理者购买的——实际上没有产生任何行为改变。然后我尝试了一种不同的做法，效果如此彻底，以至于从那以后我一直在不停地谈论它。我们很快会讲到这个。

先说说那个剧本，因为这个剧本无处不在，一旦你看清了它，你就再也无法视而不见。一个供应商，或者你自己的培训部门，或者一个戴着精致细框眼镜的顾问，向你的CTO推销一份转型路线图，然后召开一个启动会，出现一份标题类似"工作的未来"或"AI原生工程"的PPT，接着是一个有分组讨论、彩色便利贴的工作坊，最后以一个收尾练习结束——每个人分享一件自己"承诺尝试"的事。然后所有人回到他们的工单前，之前真实的迭代压力依然真实，之前没人真正信任能做实际工作的Agent模式依然是没人的主要工作方式，六个月后，当一切都没有改变时，有人雇了另一个顾问，循环重新开始。

我在足够大、本应该更懂事的公司里亲眼看过这种事发生，运营这些公司的人是我尊敬的人。这个模式足够一致，以至于一旦你看到了诊断，你就能在下一个合作开始之前预测到它。

以下是最常见的三种失败模式的分类——这个行业在实际上没有改变任何人的时候对自己说的谎言。如果你是一名工程领导者，你几乎肯定在至少其中一个中点头了。

谎言一：许可证倾倒

这是剧本中最常见的一招。采购部门买了许可证，IT分配了席位，然后发一封邮件宣布Claude Code（或Cursor、Copilot，或那个季度占据行业媒体头条的任何工具）现在已经"可用"，附带一个供应商入门页面的链接。然后所有人等待生产力数字上升。

它们不会上升。许可证不是转型；许可证是一张意向收据。你把一个工具丢给团队然后走开，实际购买的只是在董事会PPT上声称你的工程组织"拥有AI工具"的权利。这就是全部产品。你的工程师的行为和之前一模一样，因为一个放在开发者机器上无人使用的工具，在任何可衡量的标准下，与没有工具毫无区别。

讽刺的部分不是工具的投放，讽刺的是之后发生的事——也就是什么都没发生。许可证投放了，指针没有移动，批准预算的同一批高管在六个月后开始问为什么生产力提升没有实现，而在整个过程中，没有一个人打开供应商仪表盘去查看token消耗量或会话数数据——这些数据能在五分钟内告诉他们，团队里没有人使用Agent模式。调查从未进行，因为调查会得出一个与PPT矛盾的答案。表现出惊讶更容易。

听好了，当你投放一个工具然后走开时，你真正要求的不是IDE之间的迁移，也不是从Subversion到Git的切换。你要求的是一个高级工程师颠覆他们手艺中最根本的行为——将代码输入文件的行为——在做了十五二十年作者之后，转而开始指挥，而且你要求他们在自己的时间、在迭代任务之间、仅凭一个供应商链接和一条Slack公告来完成这件事。这不是工具变更，这是一次穿着供应商链接伪装的身份变更，整个肌肉记忆、工作流程、以及从工单进入队列那一刻起问题的分解方式——所有这些都必须从零开始重建。

当你投放一个工具然后走开时，你真正要求的是一个工程师颠覆他们手艺中最基本的行为，在十五二十年用同样方式做事之后。这是一次穿着供应商链接伪装的身份变更。

更糟的是。你要求这样做的工程师中有相当一部分已经在周末的副项目中尝试过这个工具，或者在一个小型的内部工具上，或者在一个只有三个文件的新项目中，在那个场景下，工具的表现足以证实他们已有的怀疑——这就是个玩具。一个聪明的玩具，或许对快速脚本和原型有用，但不是用于生产关键系统的严肃工程工具，更不用说那个有七年历史、服务边界纠缠不清、文档大部分是错的棕地单体了。他们试过了，得出了结论，现在构成了你最能言善辩、最资深、最有说服力的反对力量。所以当你把企业许可证扔到他们机器上时，你不是在向他们介绍这个工具，你是在确认——通过把它当作一个自助问题来处理——你根本不理解他们认为工具能做的和正确使用时工具实际能做的之间的鸿沟。

谎言二：许可便签

这是针对那些认识到学习很重要但不太愿意承认仅仅要求学习不足以产生学习的组织的手势。你宣布一个无会议周五，或者一个阅读日，或者每天一小时AI探索时间，然后假设你的工程师会利用这个空间来学习工具。他们不会。原因是高绩效的工程团队实际上不会利用给予他们的许可。速度是他们衡量自己的单位，把速度让给学习——即使有来自上面的明确掩护——在身体感觉上就是不对的。你最想要提升技能的工程师恰恰是最不愿意利用这些空闲时间的人。他们会用无会议的周五来追赶周二被四个会议耽误的四个工单。当工程师自己背负着压力时，压力不需要从上面施加。

在自我施加的压力之下是更深的问题：学习Agent模式不是适合周五下午的那种学习。它需要在对真实工作的刻意、反复、持续的练习上，那种随着时间推移对工具产生感觉的练习。读一篇博客不会产生那种感觉，看一个教程也不会。反复练习才能做到。而反复练习需要一个被塑造成让练习本身就是工作的任务单元，这是许可便签无论多么慷慨都无法提供的。

读一篇博客不会产生那种感觉，看一个教程也不会。反复练习才能做到。

谎言三：回音室

你安排了一个午餐学习会，买了披萨，请一位"对Claude非常兴奋"的高级工程师做一个四十五分钟的演示。或者你创建了一个#ai-tips Slack频道，放了三篇文章和一个YouTube链接。或者两件事都做，理由是曝光加上共享工作空间会产生动力。

每次来参加午餐会和在频道里发帖的都是同样的五个人，而且这些工程师即使没有你也会自己搞明白这些，因为他们是那个在业余时间读Newsletter、看教程的AI好奇型少数派，不管你买不买披萨他们都会继续这样做。这些干预措施感觉很有成效，因为这五个人确实很有成效，他们在午餐后的调查和频道互动指标中看起来像是更广泛转变的前沿——但他们不是任何前沿，他们是一开始就不需要这些干预的人。你团队里另外二十个工程师，那些行为真正需要改变才能推动组织转变的人，没有参加午餐会，也没有在读那个频道。所以干预触及了已经皈依的人，而未皈依的依然未皈依，你购买的是布道的外表，而不是任何实际的转变。

这并不是说午餐会、频道或指定的布道者没有价值——它们是极好的支撑结构，即使在团队转型完成之后依然如此。一个经历过冲刺的布道者会成为真正的传道者，有亲身经历可以传授；考虑到AI发展之快，一个专门负责追踪变化的人确实是长期有用的。一个由每天实际使用Agent模式的工程师填充的#ai-tips频道会成为一个有效的知识库，一个由有两周强制实践经历的人主持的午餐学习会会成为真正的教学时刻——因为房间里有一个真正的老师。这些干预措施都不是无用的，它们只是不足以作为第一步，你不能在冲刺之前运行它们然后期望它们完成冲刺的工作。

我以某种形式运行了所有这些，我信任它们，它们没有改变我的工程师实际工作的方式。他们用Cursor的方式和前一年用Copilot一样——高亮一个函数做小重构，用行内自动补全快速推送变更，偶尔向聊天提问，就像以前向Stack Overflow提问一样。Agent模式坐在IDE的角落里，偶尔被召唤来快速重写一个高亮的代码块，但从不被信任来驱动工作。六个月过去了，他们仍然在用Sonnet 3.5，仍然是和一年前一样的工作流程，仍然把Agent当作好奇物而非手艺。我花了真实的预算，给了真实的时间，产出了一堆零。

原因在每种情况下都是一样的。这些干预措施没有一个改变了工程师被考核的工作单元。站会仍然是关于你的故事，迭代评审仍然是关于你的故事，绩效评审仍然是关于你的故事。当学习与交付竞争时，交付每次都会赢，因为交付是你所运作的系统实际被设计来奖励的东西，而系统会吞噬一百张关于创新的海报和一百顿午餐，然后像前一周一样交付。

真正有效的方法

这个冲刺是一个更长弧线的结论，而不是它的前提。这条弧线值得简要叙述，因为它解释了为什么这个格式被塑造成了现在的样子。

当我第一次把现代编码工具放到我的工程师面前时，收益是边际的。多标签自动补全让小变更更快，行内重构处理高亮块还算可以，聊天偶尔充当Stack Overflow的替代品。它是一个更好的Copilot。被要求使用Agent模式做真正的工作时，工具产生幻觉，三轮之内就爆了上下文窗口，产出的代码如此不可用以至于工程师会关掉面板自己手写。

与此同时，AI YouTube生态系统在卖相反的故事。无需经验。跟着这个方法。一夜之间发布一个百万美元的SaaS。对于任何实践中的工程师来说，这显然是胡说八道，但YouTube上的幻想和我在自己团队中观察到的现实之间的差距如此之大，真相一定存在于两者之间的某个地方。某些人，在某些地方，正在用这些工具做真正的工作。诀窍不在工具本身；诀窍在于工具被使用的方式。

所以我花了大约两个月的时间——大多是在夜里自己的沙发上，打开Cursor看着Sonnet 3.5在慢速模式中产生幻觉——尝试在不触碰代码的情况下端到端构建一个复杂的应用。实施计划、在表格中命名技术栈供Agent参考的PRD、小序列的工作、上下文崩溃时的新会话、写入代码仓库的规则让Agent不再犯同样的错误。这些技术，通过感觉像一千次重启积累而成，变成了BMad V1：仓库中的六个markdown文件，整个方法论比书中的一章还短。

我把它带到我的团队，它没有留下来。他们有文档，他们有我——随时可用、热情洋溢地引导他们了解每一个部分——但他们仍然像用Copilot一样用Cursor，因为压力是真实的，而方法论是我的，不是他们的。这个冲刺就是在我意识到给人再多的BMad也永远无法替代让他们自己发现同样技术之后设计的格式。

冲刺的形式刻意简单：两周，每个工程师一个故事，大小约为通常需要三四天的工作量。这个故事是工程师在冲刺期间唯一负责的事情，唯一的约束是它必须端到端使用Agent模式来执行，如果他们在两周结束前完成了，他们必须从头开始重做同一个故事。最后一个约束不是玩笑，它是整个格式中最重要的规则。

在两周内，几乎团队中的每个工程师都在以全力使用Agent模式。十年来一直用同样方式写代码的人在十四天内重新改造了自己。我团队的产品经理，在冲刺期间因为他不是开发者而无事可做，对工程师们肉眼可见的兴奋如此羡慕，以至于我建议他自己去玩Gemini gems。他第二天早上六点给我打电话，气喘吁吁，因为他一夜之间构建了五十三个，其中一个作为我们代码库某个角落的领域专家——正是他几个月来一直暗暗缠着工程师们处理的那个角落。

这就是当许可是真实的时会发生的事。在这种格式中，许可不是一句口号，它是通过替换两周的工作单元而非在周围做补充来融入设计的，而上面三种失败模式没有一个做到了这一点。只有冲刺做到了。

而浮现出来的技术恰恰是没人能教的技术，包括我。我试过。人们实时地、在早晨站会中看着彼此，自己得出了这些结论。*如果我写一个实施计划，把Agent分成小序列喂入，它能走得更远。如果我在会话恶化时重启它，它就不再犯蠢。如果我往仓库里写规则，它就不再犯同样的错误。*这些正是我一年前在自己沙发上得出的同样结论，是变成BMad V1的结论，是此后每个发布的框架都独立重新发现的结论。我团队中的每个工程师都在两周内自己得出了这些结论，因为格式没有给他们其他选择。

更深层的结果——那个没有人计划的——是团队对工作中每一个部分的思考方式发生了转变。一旦工程师花了两周时间质疑他们对手艺中最根本行为的假设，这种质疑就不会止步于编辑器。他们开始审视每天每一个手动流程、每一个错误分类例程、每一个代码审查仪式、每一个部署操作手册、每一个复盘模板，并提出他们在冲刺期间对代码提出的同类问题——Agent能否处理这件事？如果它能，工作流会变成什么样？这就是每一份PPT都承诺、每一封全员邮件都试图强制执行的AI原生文化转变。听着，强制执行产生不了它，只有正确的格式才能。两周与Agent在一件真实工作上的强制交锋做到了没有任何高管宣言曾做到过的事：让团队中的每个工程师开始主动地、每天地、在没有人告诉他们的情况下，对自己的工作提出AI原生的问题。冲刺是为Agent模式采用而设计的，但它实际交付的是一个开始对一切不同思考的组织。

AI原生文化转变是每一份PPT都承诺、每一封全员邮件都试图强制的，听着，强制执行产生不了它。只有正确的格式才能。

如何实际操作

如果你读到这里，你已经停止支付健身房会员费，准备安装深蹲架了。好。以下是具体的做法。

在开始之前先稳住组织的其他部分。如果你的Scrum Master、产品经理或你的上级打算在过程中注入迭代压力，这个格式就会崩溃。有限的范围在整个两周内必须是神圣不可侵犯的，这笔交易要在第一天之前与所有可能推翻它的人公开达成。

两周是正确的长度：不是一周，也不是三周。原因是中间的那个周末。几乎每次我运行这个冲刺时，我都看到人们在第一周的周五变得兴奋，并把周末的一部分用于自主探索。他们周一带着更多东西回来分享，第二周在此基础上叠加。一周的冲刺不提供那个间隔，更长的冲刺稀释了紧迫感。

精心挑选故事。这是冲刺中你唯一不能做到敏捷有机和允许自主选择的部分。作为工程经理，你来选择，每个人收到一个大约相当于不用Agent模式时三到四天工作量的任务，不超过一周。它可以是故事、缺陷、Bug，任何东西，比类型更重要的是团队中的多样性——一个工程师做UI密集型的，另一个做复杂后端故事，还有一个做数据密集或性能敏感的。混合绿地和棕地项目，尤其是棕地，因为很多人会告诉你AI在棕地项目中不好使，而用真实的遗留代码来验证这个说法，正是这个格式证明自身价值的地方。

让故事彼此独立，这样没人会被阻塞在等待别人工作上。

冲刺期间不使用框架。这意味着不要给他们BMad，不要给他们Spec Kit，不要给他们任何操作手册，因为全部意义在于让他们自己发现这些技术，这正是让他们在冲刺后真正有意义地使用BMad的原因——作为将他们新内化的技术转化为可重复团队实践的框架。你可以提供几个入门提示：代码仓库中的良好文档、AGENTS.md或CLAUDE.md、编写规则的实践、制定实施计划并分批喂入的纪律、通过MCP或CLI将Agent连接到Jira或Linear。这是底线，过了这条线，让他们自己来。

重建站会。从第一天起，站会不再是状态同步会议。每个人分享前一天的一个新的或有趣的发现，这就是站会的全部内容。第一天会感觉有点尴尬，到第三天就不会了，人们会开始保存东西来分享，早晨会变成冲刺中最具生产力的部分。

用两次演示为两周画上书签。第一个周五，举行一个加长版站会，让人们详细分享他们的发现。最后一个周五，举办一个真正的演示会——根据团队规模一到两小时——每个人展示的不是他们交付的故事，而是他们学到了什么。

而我每次在第一天首先提出的规则是：每个人在冲刺期间都在同一个故事上工作，如果你完成了就从头开始，如果你碰壁了就后退尝试不同的方法。用不同的技术把同一个故事循环两到三次，是技术开始叠加的地方。你寻找的突破不在终点线上，而在你的工程师到达终点的每一次重启中。

你寻找的突破不在终点线上，而在你的工程师到达终点的每一次重启中。

最后一件事

这是不够经常被说出来的部分。

AI培训和转型行业很年轻，但它使用的剧本并不年轻。合作的形式、交付物、成熟度模型、认证项目、季度保留服务结构——所有这些都完整地借用了比它早二十年的敏捷转型行业，而那个剧本有一个我亲身经历并近距离观察到的结构性问题。它被设计成在采购方制造运动的表象，而不是在团队中产生实际的行为改变，所以交付物为董事会PPT制作了漂亮的幻灯片，但它们自身并不能在周一早上产生以不同方式使用工具的工程师。这不是运营这些合作的人的道德缺陷——他们中的大多数人相信自己的工作——这是一个被写入协议结构的设计缺陷，而采购市场和销售市场至今还没有共同修复它的动力。

两周。每人一个故事，精心挑选。仅限Agent模式，端到端。每天分享一个酷发现。两个周五的演示。如果有人提前完成就重新开始。

不要缩减它，不要因为两周感觉太长就缩到一周——因为这两周是格式，不是预算——不要给他们框架。也不要告诉我你的团队太资深、你的棕地项目太混乱、或者你的工程师会拒绝，因为我的团队很资深，我们的项目是棕地，他们持怀疑态度且很忙，但他们参与了。你的团队也会的。

还有一件事，在你假设运行冲刺就能独立解决你的AI转型问题之前。如果你运行了它但没有改变组织中其他任何东西，你的工程师会很好地使用Agent模式，用新的眼光审视工作流程中的每一个手动过程，并且交付速度比之前快百分之十到二十——这是有意义的、值得做的，但本身并不是变革性的。变革性的转变发生在同样的思维贯穿软件开发生命周期中的每个角色时，当产品、设计、技术领导力、质量和运营都开始以AI原生的方式对着同一个待办列表工作，以二十年前敏捷重组工程时同样的协调方式。两周冲刺是这种转变的工程前提，不是转变本身。BMad方法——这是我从自己沙发上早期的重启周期以来一直在开发的框架——是更大重组的蓝图，是许多工程组织已经开始大规模采用的框架，这个系列的下一篇文章将讲述如何运行它。冲刺是你的起点。

如果你运行了这个冲刺，并且它在你的团队上发挥了和在我的团队以及我观察过的每个其他团队上一样的效果，我很想听听你的版本是什么样的。