— 2026.10 · AI CODING

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

个人用上 Cursor、Claude Code 并不难，难的是让一支团队的交付整体变快、变稳。这两年在企业里做 AI 编码落地，我越来越确定：AI 放大的是你原有的研发体系，好的更好，乱的更乱。

一个常见的落差

很多团队引入 AI 编码工具后的第一个月，反馈都很积极：写代码快了，样板代码不用手敲了。但到了第二、第三个月，项目经理会发现一个奇怪的现象，个人产出明显上升，迭代的整体交付却没什么变化，甚至返工更多了。

原因并不复杂。AI 让"写代码"这个环节变得很便宜，但需求是否说清楚、代码是否符合团队约定、谁来审查、怎么测试，这些环节一个都没变。瓶颈只是从编码挪到了需求和评审上。每个人都在用自己的方式和 AI 对话，生成的代码风格各异，评审的人反而更累。

所以我做体系设计时的出发点是：不要先问"用哪个工具"，而是先问"团队的信息怎么流动"。

规范先行：把团队约定变成 AI 的上下文

AI 编码的质量，很大程度上取决于它拿到的上下文。人类工程师靠多年耳濡目染理解团队的约定，AI 只能靠你写下来的东西。因此第一步，是把原本存在于老员工脑子里的隐性知识，变成可以喂给 AI 的显性规范：

• 模块级 BRD：不是一份大而全的需求文档，而是按模块拆开、能直接作为提示上下文的业务说明，包含业务规则、边界情况和验收标准。
• 编码规范：前后端分层、命名、异常处理、接口风格，写成 AI 能读懂、能执行的规则文件，而不是只给人看的 Wiki。
• 组件与模板：常见页面、接口、数据访问模式沉淀成模板，让 AI 在既有骨架上填充，而不是每次从零生成。

今年在一个连锁餐饮品牌做 10 天驻场陪跑时，我们前三天几乎没有写业务代码，全部花在梳理 BRD 和规范上。客户团队一开始有些着急，但从第四天开始，同一个模块由不同的人借助 AI 实现，代码风格、目录结构和接口约定高度一致，评审时间大幅缩短。最后 MVP 按时闭环，这三天的"慢"是最划算的投入。

流程驱动：重新设计一个迭代

有了规范，还需要把它嵌进日常节奏里。我建议把一个迭代内的工作拆成一条清晰的流水线：

1. 需求澄清：产品经理与技术负责人一起把需求写成模块 BRD，验收标准要具体到 AI 可以据此生成测试。
2. 方案与拆分：技术负责人确定接口与数据结构，把任务拆到 AI 一次能可靠完成的粒度。
3. AI 生成与自测：工程师带着 BRD 和规范与 AI 协作实现，同步生成单元测试。
4. 评审与集成：评审的重点从"代码写得对不对"转向"是否符合业务意图、是否越过了边界"。
5. 回顾与沉淀：每次迭代结束，把 AI 反复出错的地方补进规范和模板里。

最后一步最容易被忽略，却是体系能否越用越好的关键。规范不是一次写完的文档，而是一份随项目持续生长的团队资产。

角色在变化

在这样的流程里，团队角色的重心也会发生变化：产品经理需要把需求写得更结构化、更可验证；技术负责人花更多时间在上下文管理和规范维护上，像是团队与 AI 之间的"编译器"；工程师则更多承担审查者和集成者的角色，判断力比打字速度重要得多。

这对团队是一种能力升级，也会带来不适应。所以落地时我会安排一段陪跑期，和团队一起做真实需求，而不是只做培训演示。方法论只有在真实项目里跑通一次，团队才会真正相信它。

几点心得

• AI 不会自动带来效能，它放大的是原有流程。流程不清晰时，先补流程。
• 上下文工程比提示技巧更重要。与其教每个人写好提示词，不如把团队知识整理成 AI 可用的上下文。
• 评审是新的瓶颈。要提前设计评审标准，否则节省下来的编码时间会全部消耗在返工上。
• 度量要看团队交付，而不是个人生成了多少行代码。
• 能力要留在团队里。外部顾问能带一段路，但规范和习惯必须由团队自己维护。

规范先行，流程驱动，让 AI 编码成为团队能力，而不只是少数人的个人技巧。这是我这两年最核心的一点体会。