— 2026.10 · AI CODING

AI 驱动的敏捷研发：
从个人提效到团队体系

这两年在不少企业里推动 AI 编码落地，最常听到的一句话是：“工具大家都在用，可团队好像也没快多少。”我越来越相信，AI 放大的是一个团队原本的研发习惯。底子好的，会好上加好；底子乱的，只会乱得更快。

第一个月的热闹，第三个月的沉默

新工具刚进团队的头几周，气氛通常很好。有人半天写完了过去要两天的接口，有人一口气把欠了很久的测试用例补齐，周会上总能听到几个让人兴奋的例子。

到了第三个月，项目经理翻开迭代看板，却发现交付节奏几乎没变，返工单反而多了几张。问题并不在工具。写代码这一步确实变便宜了，但需求有没有讲清楚、代码合不合团队的约定、谁来把关、怎么测试，这些环节原封不动。瓶颈只是从键盘挪到了需求和评审上。再加上每个人和 AI 打交道的方式各不相同，同一个模块能写出五种风格，评审的人反而比以前更累。

所以后来再做体系设计，我问的第一个问题从来不是“用哪个工具”，而是“团队里的信息是怎么流动的”。

规范先行：把默契写下来

老员工之所以写得又快又稳，是因为脑子里装着大量没写下来的默契：哪些字段不能为空，异常该抛到哪一层，接口命名有什么讲究。新同事要花几个月才能摸透这些，AI 则完全无从得知，它只认你写下来的东西。

所以第一步，是把这些默契变成 AI 读得懂的上下文。具体落在三样东西上：一份按模块拆开的 BRD，把业务规则、边界情况和验收标准写清楚，可以直接交给 AI 当上下文；一份面向执行的编码规范，讲清分层、命名和异常处理，既写给人看，也写给 AI 看；再加上一套常用页面和接口的组件模板，让 AI 在现成的骨架上填空，而不是每次从零发挥。

今年五月，我在一个连锁餐饮品牌驻场十天。前三天我们几乎没碰业务代码，一直在梳理 BRD 和规范。客户的同事一开始有点坐不住，私下问我进度是不是慢了。到了第四天，几个人各自借助 AI 写同一个模块的不同部分，合起来一看，目录结构、命名和接口约定几乎一模一样，评审半小时就过完了。十天后，MVP 如期跑通。回头看，那三天的“慢”，是整个项目里最值的投入。

流程驱动：一个迭代怎么走

规范写好了，还得嵌进每天的工作节奏里，否则用不了几周就会被忘在角落。我习惯把一个迭代拆成五步，每一步都有明确的负责人和产出，AI 在每一步里扮演的角色也不一样。下面这张图可以逐步点开看：

前四步大家都不陌生，真正拉开差距的是第五步。每个迭代结束，我们会专门留出一点时间，把 AI 反复犯错的地方补进规范和模板。比如它总把金额字段写成浮点数，那就在规范里加一条，再在模板里放一个正确的写法。这样一来，规范就不再是写完便束之高阁的文档，而是跟着项目一起长大的团队资产。

人的角色在悄悄变化

这样跑上几个迭代，团队里每个人的重心都会移动。产品经理要把需求写得更结构化，验收标准细到 AI 能据此生成测试；技术负责人写代码的时间少了，更多精力花在维护上下文和规范上，有点像团队和 AI 之间的翻译；工程师则越来越像审查者和集成者，判断力比手速重要得多。

这对团队是一次能力升级，也难免让人不适应。所以我不太相信只靠一两场培训就能完成转型。更有效的做法，是陪着团队做一两个真实需求，让大家亲眼看到这套方法在自己的代码库里跑通。方法论在 PPT 上讲十遍，不如在真实项目里成功一次。

写在最后

如果把这两年的体会压缩成几句话，大概是这样：AI 放大的是你已有的流程，流程不清楚的时候，先补流程。与其教每个人写更好的提示词，不如把团队的知识整理成 AI 用得上的上下文。评审会成为新的瓶颈，要提前想好标准。衡量效果要看团队的交付，而不是个人生成了多少行代码。最后，能力一定要留在团队自己手里。