团队里引入 AI 编程，先定规范还是先买工具
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-11 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只从管理角度看，“先买工具还是先定规范”很像一个顺序问题；但真正落地到团队里，我更愿意把它理解成一个失败概率问题。因为这两条路都会通向使用 AI 编程，但通向的方式完全不同：
- 先买工具：上手快，但团队很容易各自形成野路子
- 先定规范：起步慢一点，但后面更容易稳定放大
我自己的结论越来越明确：工具当然要买，但规范应该先于工具成为团队共识。
不是因为规范比工具更重要，而是因为如果没有规范，工具会把团队原本就存在的差异和混乱放大得更快。
一个团队里最容易发生的真实情况
假设一个 6-8 人的小团队开始引入 AI 编码工具，很快就会出现这些差异：
- 有人拿它写测试
- 有人拿它直接改业务逻辑
- 有人只拿它查文档和补注释
- 有人甚至让它直接改大文件
一开始看起来很热闹，但很快问题就会变得具体：
- review 风格开始分裂
- commit 质量波动变大
- 有些人产出明显加快，有些人只是多了很多噪音代码
- 团队很难判断“这是个人用法问题，还是工具本身问题”
这时候如果还没有基本规范，管理者通常会陷入一种很尴尬的状态：工具已经进来了，但团队并不知道怎样才算“用得对”。
为什么我会把规范放在工具前面
因为团队真正需要统一的，不是品牌偏好，而是最小协作边界。
例如：
- 哪类代码允许 AI 直接生成
- 哪类代码必须人工主写
- review 时对 AI 代码要额外看什么
- 是否要求保留关键提示词或生成说明
- 测试和回归责任落在谁身上
这些问题如果不先对齐，团队很容易把“用了 AI 编码工具”误以为“已经拥有了 AI 编码能力”。
先买工具的常见副作用
1. 速度不均衡会被误解成能力不均衡
不同人使用 AI 的方式差异很大，如果没有规范，很容易出现“为什么他快这么多、我却没有收益”的情绪落差。
2. review 成本变高
因为 reviewer 不知道：
- 这段代码是人工精写还是 AI 草稿
- 应该重点看逻辑、边界，还是命名风格
3. 团队很难沉淀可复用经验
大家各自摸索，各自有效，但组织层面没有形成稳定方法。
我更倾向的落地顺序
现在如果一个团队要引入 AI 编程，我会建议按这个顺序：
第一步：先定 5 条最小规范
例如：
- AI 生成代码默认必须经过人工 review
- 高风险业务逻辑不能直接全自动改写
- 测试和回归责任仍由提交者承担
- 大文件重构优先拆小块，不让 AI 一次性乱改
- review 时重点看边界、幂等、副作用，而不是只看风格
第二步：再选工具
这时工具才更像执行手段，而不是团队行为本身。
第三步：选两三个试点场景
比如：
- 测试代码生成
- schema / DTO / 样板代码
- 小模块重构
第四步：定期复盘
看清楚：
- 哪些地方真的提效
- 哪些地方只是把问题往 review 后移
一个我很看重的现实原则
如果团队里还没有统一 review 标准，那么再好的 AI 编码工具，也只会把代码生成速度提高，不会把工程质量自动提高。
也就是说，工具解决的是“产出速度”，规范决定的是“组织能不能吸收这些产出”。
总结
团队里引入 AI 编程，我的答案不是“只定规范”也不是“只买工具”，而是：规范先定，工具再上。
因为工具决定的是个人怎么写，规范决定的是团队怎么一起接住这些代码。没有后者，前者越强，团队越容易被放大的其实是混乱，而不是效率。