祝融说。

你引入了 AI 编码工具。起初一切顺利，但一个月后，问题开始浮现。理解变化，才能应对变化。

1.1 两个场景

场景一：失控

你的团队引入了 AI 编码工具。起初大家都很兴奋——效率确实提高了。但一个月后，问题开始浮现：

• 代码库中出现了大量风格不一致的代码（AI 在不同对话中生成的代码风格不同）。
• 一些关键模块被 AI"顺手"修改了，引入了隐藏的 bug。
• 代码审查变成了一场灾难——审查者看不懂 AI 生成的代码。
• 新成员加入时，没有人能说清楚系统的架构是什么。

AI 没有替代你的团队，但改变了你的团队的工作方式。而你，还没有准备好应对这种变化。

场景二：赋能

另一个团队也引入了 AI 编码工具。但他们的做法不同：

• 团队先制定了 AI 编码规范：什么场景用 AI，什么场景不用。
• 所有 AI 生成的代码必须通过验收才能提交。
• 每个项目开始前，必须产出架构蓝图。
• 每周有代码质量审计，检查架构偏移。

结果：

• 开发效率提升 2 到 3 倍。
• 代码质量保持稳定。
• 团队成员对新工具感到兴奋而不是焦虑。

关键区别： 第一个团队让 AI 主导了开发过程。第二个团队让 AI 在规范的框架内工作。

1.2 AI 编码带来的三个变化

AI 编码不是"工具升级"，而是"工作方式的重构"。它带来的变化不是线性的，而是系统性的——一个变化会引发另一个变化。

变化一：开发速度大幅提升

一个功能，传统开发可能需要两天，AI 编码可能只需要两小时。这是最直观的变化，也是管理者的第一反应："太好了，效率提升了！"

但效率提升会引发连锁反应。交付周期缩短了，业务方自然会期待更高的交付频率——"你们两天能做一个功能，那一个月应该能做十个吧？"但"快速交付"不等于"快速交付正确的东西"——验收的瓶颈从"写代码"变成了"审代码"。以前，一个功能开发两天、审查半天，审查时间是开发的四分之一。现在，AI 两小时写完了，但审查仍然需要半天——审查时间变成了开发时间的三倍。

这对管理意味着什么： 你需要重新审视项目规划和进度评估的方式。不能再用"写代码的时间"来估算工作量，因为编码时间已经趋近于零。真正的瓶颈在"验收"和"集成"——你需要在这两个环节投入更多资源。

变化二：代码量激增

AI 编码工具倾向于生成更多的代码。一个开发者使用 AI 后，产出量可能是之前的三到五倍。这听起来是好事——但代码量激增带来了三个新问题。

第一，代码审查的工作量急剧增加。以前一个 PR 大概 100-200 行代码，审查者可以快速看完。现在 AI 生成的 PR 可能 500-1000 行，审查者需要花更多时间，而且更容易遗漏问题。

第二，代码库膨胀速度加快。如果一个月前你的代码库是 5 万行，一个月后可能变成了 15 万行——但业务复杂度并没有增加那么多。多余的代码意味着更多的维护成本。

第三，技术债可能以更快的速度累积。AI 倾向于"解决问题就好"，不考虑长期可维护性。今天一个"快速实现"，明天一个"快速修补"——技术债就像一个高利贷，利息会越滚越大。

这对管理意味着什么： 你需要更严格的代码结构管理，定期检查代码库的健康度，不能等到"代码库爆炸"了再处理。

变化三：知识沉淀方式改变

传统开发中，开发者通过"写代码"来理解系统。——每一行代码都是亲手敲出来的，代码写完了，系统也理解了。AI 编码后，开发者可能"没写过"核心代码，但仍然需要"理解"它。

这就像你请了一个施工队帮你盖房子。房子盖好了，你住进去了，但你不了解房子的结构——哪里是承重墙、哪里是水管、哪里是电路。当你想改造房子时，你无从下手。

这对管理意味着什么： 代码审查和架构文档比以往任何时候都更重要——它们是开发者理解系统的唯一途径。新成员 onboarding 的方式需要调整——不能依赖"读代码"来理解系统，因为代码可能有一半是 AI 写的，连提交者自己都不完全理解。团队的知识传承需要更结构化的方式——文档、分享、代码走读，而不是"自己去读代码"。

1.3 管理者的新角色

三个变化意味着管理者的角色需要扩展。不是"放弃旧角色"，而是"在旧角色之上叠加新角色"。

从"管人"到"管流程"

传统管理关注的是"谁在做什么"——这个功能谁来做？那个 bug 谁去修？AI 编码时代，问题变成了"流程是什么"——因为流程决定了 AI 工作的质量，而不是"谁在做"。

为什么？因为 AI 没有责任心，没有职业操守。它不会主动思考"这个方案是不是最优的"，它只会执行你给的指令。如果你没有明确的流程（先有蓝图再编码、先验收再提交），AI 就会按照自己的"默认流程"工作——而它的默认流程是"快速生成代码，不考虑质量"。

所以，管理者需要从"分配任务"转向"设计流程"。流程设计得好，AI 和团队都能高效运转；流程设计得不好，AI 会制造混乱。

从"管结果"到"管门禁"

传统管理关注的是"代码能不能跑通"——上线了、没出 bug，就是好的。AI 编码时代，代码几乎总是"能跑通"的——因为 AI 生成的代码从语法上看几乎总是正确的。但"能跑通"不等于"质量好"——密码可能是明文存储的、API 可能缺少权限控制、数据库查询可能有注入风险。

所以，管理者需要从"检查结果"转向"设计门禁"——在代码流向生产环境的路径上设置质量关卡。每个关卡有明确的检查标准，通过才能进入下一关。

从"管个体"到"管规范"

传统管理关注的是"这个开发者做得好不好"——看代码质量、看交付速度、看 bug 率。AI 编码时代，AI 承担了大部分编码工作，个体差异被 AI 抹平了——一个初级开发者和一个高级开发者用 AI 写代码，产出的质量差异可能不大。

但有一个问题 AI 解决不了：遵守团队约定。AI 不会像人类一样自然地遵循团队的编码规范——它不知道你的团队用 camelCase 还是 snake_case，不知道你的 API 要放在哪个目录下，不知道你的错误处理要统一用什么格式。所以，管理者需要从"管个体"转向"管规范"——规范是否明确？规范是否被 AI 理解并遵循？规范本身是否需要更新？

1.4 管理者的常见担忧

担忧一：AI 生成的代码质量不可控

事实： AI 生成的代码质量确实参差不齐，但通过建立验收体系，质量是可控的。关键在于"在哪个环节控制质量"——是在代码提交前（验收），还是在代码上线后（修 bug）？

建议： 建立"提交前验收"的门禁制度。所有 AI 生成的代码必须通过功能、架构、安全三个维度的验收才能提交。

担忧二：团队技能退化

事实： 开发者长期依赖 AI 写代码，可能失去独立编码的能力。

建议： 不要禁止 AI 编码，而是要求开发者理解 AI 生成的代码。验收环节就是强制理解的机会——开发者必须理解代码才能验收。

担忧三：团队对 AI 的依赖

事实： 开发者遇到任何问题都问 AI，而不是先自己思考。

建议： 明确"什么场景用 AI，什么场景不用"的边界。例如：

• 常规 CRUD 功能：可以用 AI。
• 核心业务逻辑：必须先自己思考，再借助 AI 验证。
• 架构决策：AI 提供参考，人做决策。

1.5 管理者的核心任务

基于以上分析，管理者的核心任务可以概括为三项。

任务一：建立规范

制定团队使用的 AI 编码规范，明确：

• 什么场景用 AI。
• AI 生成的代码如何验收。
• 架构蓝图如何维护。
• 代码质量如何审计。

任务二：培训团队

让团队成员掌握正确的 AI 编码方法：

• 基础培训：六步工作法、三大纪律。
• 进阶培训：14 个技能的使用场景和方法。
• 持续学习：复盘、分享、改进。

任务三：持续改进

建立反馈机制，持续优化流程：

• 定期代码质量审计。
• 项目复盘会议。
• 流程改进迭代。

本章小结

AI 编码不是"工具升级"，而是"工作方式的重构"。三个变化——开发速度提升、代码量激增、知识沉淀方式改变——会引发连锁反应，管理者需要重新审视项目规划、代码审查和知识传承的方式。管理者的角色需要从"管人"扩展到"管流程、管门禁、管规范"——因为流程决定 AI 的质量、门禁控制 AI 的输出、规范约束 AI 的方向。下一章，我们概览管理者需要知道的 14 个技能。