让AI进代码仓库前，我先立了三条规矩——一个小团队负责人的PR流程改造记
一、管理者的真实痛点
我是团队负责人，管着几个开发。引入AI辅助编程之前，我最担心的不是“AI写不写得出来”，而是另外几件事：
1. 代码review变成赌博。 工程师用AI生成了大段代码，提交上来的PR动辄几百行。我review的时候心里打鼓：这些代码他真的理解了吗？出了线上事故谁负责？
2. 风格和质量的失控。 AI生成的代码风格五花八门，有人直接贴进去就提PR，注释是英文的、异常处理是空的、连日志都没有。合并进去就是技术债。
3. 流程黑箱化。 谁在用什么工具、提示词写了什么、生成的代码有没有过安全扫描——这些我全都看不见。对管理者来说，看不见的风险才是最大的风险。
4. 效率的错觉。 写代码快了，但需求理解、测试、review的时间没变甚至变长了。整体交付周期并没有缩短多少。
这些问题的共同根源是：团队把AI当成了“个人的提速器”，而不是“流程中的一个环节”。所以我做的事情是重构流程，而不是简单地“让大家用AI”。
二、我定的三条规矩
在AI正式进入我们的开发流程前，我立了三条规矩，写进了团队Wiki：
规矩一：AI可以写代码，但需求必须人来拆。 需求澄清、验收标准、边界条件的定义，必须由工程师完成并写成文档，AI只基于这份文档工作。这样保证PR里的每一行代码都有“需求依据”可查。
规矩二：AI参与的痕迹必须可见。 提示词、AI生成的初稿、人工修改的diff，全部附在PR描述里。不是监视，而是让reviewer知道“这份代码的思考过程”，也让新人能学习怎么用好AI。
规矩三：质量门禁一票否决。 AI生成的代码和其他代码走完全一样的门禁——单元测试、静态检查、安全扫描、至少一人review。AI不享受任何“绿色通道”。
这三条规矩定下来之后，AI才真正从“个人玩具”变成了“团队工具”。
三、完整流程：从需求到PR
改造后的流程分六步，每一步AI都承担明确的角色：
第一步：需求理解与任务拆解（人主导，AI辅助）
工程师把需求文档丢给AI，让它输出任务拆解、技术方案建议和风险点清单。人负责判断和取舍。这一步产出一份“任务说明文档”，是后续所有步骤的输入。
第二步：生成实现计划
AI基于任务说明输出实现计划：改哪些文件、影响范围、需要的测试用例清单。工程师确认后才开始写代码——先对齐计划，再生成代码，能极大减少返工。
第三步：代码生成与自测
按计划分块生成代码，每块生成后立即本地跑通、人工通读。禁止“一口气生成五百行再回头看”。
第四步：AI辅助生成测试
让AI根据实现代码生成单元测试，人再补充边界用例。测试必须真实跑过，覆盖率不达标的PR不予合并。
第五步：PR准备
AI根据本次改动生成结构化的PR描述：做了什么、为什么这么做、风险点、回滚方案、AI参与记录。
第六步：AI预review + 人工终审
在人工review之前，先让AI做一轮预review，标出可疑点（未处理异常、潜在注入、命名不一致等），reviewer带着这份清单再看，效率明显提升。但最终拍板权永远在人手里。
四、提示词模板（可直接复制）
以下是我们在“第二步：生成实现计划”中使用的模板，团队成员统一使用、统一维护：
你是一名资深工程师，请基于以下需求完成实现计划。
## 需求描述
[粘贴需求文档或用户故事]
## 现有代码上下文
[粘贴相关的接口定义/数据模型/关键代码片段]
## 请输出：
1. 技术方案概要（200字以内，说明改哪些模块、为什么）
2. 文件级改动清单：每个文件改什么、新增还是修改
3. 影响范围分析：这次改动可能影响哪些现有功能
4. 测试用例清单：至少包含正常路径、边界条件、异常处理
5. 风险点与回滚方案
6. 你不确定的地方（需要人来决策的问题清单）
## 约束：
- 遵循团队现有的代码规范和目录结构
- 不要引入新的依赖，除非在"不确定的地方"中说明理由
- 输出为Markdown格式第6点“不确定的地方”是我们踩坑后加上去的——它强制AI暴露自己的盲区，把决策权还给工程师。
五、用AI前后对比
| 维度 | 改造前（各自用AI） | 改造后（流程化使用） |
|---|---|---|
| PR质量 | 大段未读代码直接提交，review像拆盲盒 | 计划先行，PR描述完整，review有据可依 |
| review耗时 | 平均较长，且reviewer心理负担重 | AI预review筛掉低级问题，人聚焦设计层面 |
| 测试覆盖 | 经常“能跑就行” | 测试清单前置，覆盖不达标不合并 |
| 风险可见性 | 谁用了AI、怎么用的，完全不可见 | AI参与记录完整，审计有痕 |
| 新人上手 | 各用各的提示词，好坏全凭运气 | 统一模板+沉淀的最佳实践，快速达标 |
| 交付节奏 | 写码快但返工多，整体没快多少 | 返工减少，交付周期实际缩短 |
最大的变化不是“写代码变快了”，而是整个流程变得可控、可审、可复制。作为管理者，我可以放心地说：AI产出的一切都有迹可循。
六、给管理者的三点建议
- 先定流程，再发工具。 没有规矩的AI使用，效率提升会被review成本和线上事故吃光。
- 让AI承担“重复性劳动”，人守住“判断和责任”。 拆解、生成、预review交给AI；方案取舍、最终合并由人签字。
- 模板是团队资产。 统一维护提示词库，比每人自研一套更有价值，也更好迭代。
如果你还没有稳定的模型接入方案，可以在 https://api.thistoken.ai/register 注册一个账号试试，把这套流程跑起来——工具不难找，难的是从今天开始把规矩立起来。
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。