团队落地与治理

个人用 AI 提速容易，团队稳定交付很难。本章解决"从个人提效到组织能力"这一跃：怎么推广、怎么治理、怎么度量。

一、个人提效 ≠ 团队交付

一个人装个插件、写得飞快，叫个人提效；但团队要的是可预期、可维护、可审计的交付。差距在于：

• 每个人和 AI 的对话各说各话，约束没共享（有人守规范有人不守）；
• 产出质量看运气，没有统一验证闸门；
• AI 生成的代码责任归属不清、许可证/IP 存疑；
• 只盯着"写得快"，没盯"回归率、可维护性"。

💡 核心观点：AI 不是在替代团队，而是在逼团队把工程实践升级。落地成败的关键，一半在工具，一半在治理。

二、五步落地路线图

对应成熟度路线图，从组织视角推进：

第1步  选试点   —— 挑 1-2 个低风险项目 + 愿意尝鲜的人，跑出可复制样板
第2步  立规范   —— 沉淀共享的 AGENTS.md / Rules / Skills（见第13章）
第3步  配工具   —— 按范式选工具链（见第17章），统一到团队工作流
第4步  设门禁   —— 把 review / test / 安全扫描编码成 CI 闸门（见第15章）
第5步  度量推广 —— 用指标验证收益，再逐步扩到更多团队

别倒着来：没立规范就先大规模买工具，只会让"各人各样的 AI 用法"把混乱放大。

三、治理要点（团队最容易漏的）

议题	建议做法
规范共享	约束进仓库（AGENTS/Rules），全团队同一份事实来源，而非口口相传
代码评审	AI 产出一律走 review；评审重点从"语法对不对"转向"是否满足 spec/边界"
质量门禁	合并前必须过 lint / test / 类型 / 安全扫描——机器判定，不靠自觉
责任归属	明确"提交人对该代码负责"，AI 不是免责理由；谁 merge 谁兜底
许可证 / IP	警惕 AI 复制训练数据里的受限代码；引入依赖与片段做许可证核查
数据安全	生产数据、密钥、客户信息不得喂给外部模型；遵守数据分级（见安全清单）
能力培训	教会成员"写清意图 + 审查产出"，而非只教"怎么按快捷键让 AI 生成"

四、度量：别只看"写得快"

只看"生成速度 / 代码行数"会被反噬（代码变多但更难维护）。建议平衡指标：

效率类：需求交付周期、单任务耗时
质量类：缺陷/回归率、线上事故数、一次通过率（review 通过比例）
健康类：可维护性（重复度、覆盖度）、AI 产出返工率
成本类：工具订阅/用量成本、人均产能

🕳️ 你可能会遇到的坑：用"AI 生成代码占比"当 KPI，会诱导大家"为用而用"、堆低质代码。度量交付结果，不度量工具使用率。

五、角色与协作的迁移

规模化落地后，团队分工会自然重排（呼应协作与工作流）：

过去：人手写代码，评审看"写得对不对"
现在：人定义意图/边界、设计验证闸门、审查 AI 产出；
      AI 负责生成、整理、首轮自验证

于是最抢手的不再是"打字最快的人"，而是最会把需求讲清楚、最会设计验证系统的人。

六、一个最小可复制的团队起步包

不用一步到位，先攒这四样就能起步：

• [ ] 一份精炼的仓库 AGENTS.md（结构约定 + 编码规范 + 构建命令 + 禁区）；
• [ ] 一套 Rules（如"必须参数化查询""实现阶段禁改测试断言"）；
• [ ] 一条 CI 闸门（secret 扫描 + lint + test，合并前必过）；
• [ ] 一条 团队约定（AI 产出走正常 PR + 评审，谁 merge 谁负责）。

七、本章小结

• 团队落地的难点是把个人提效变成可预期交付，靠的是治理不是某个工具。
• 走五步路线：试点→规范→工具→门禁→度量推广，顺序别乱。
• 治理七议题里，责任归属、质量门禁、数据安全最容易被忽略也最致命。
• 度量要平衡，看交付结果，不看 AI 使用率。

八、下一步

• 回顾工具选型：AI 编码工具链选型
• 一页速查全书：快速参考卡片