20|协同与审查:调用框架中的 /review 指令,实现标准化审查
一句话总结
把“写完代码”推进到“可合并代码”:
用 Slash Command 做标准化审查,用 AI 生成 commit message 和 PR 描述,把本地代码变成高质量 PR。
一、本讲核心主线
本地代码
→ AI 标准化审查
→ 修复高优问题
→ AI 生成 Commit Message
→ AI 生成 PR 描述
→ 形成可协同、可合并的交付物
二、这讲解决的核心问题
前面 17-19 讲已经完成:
spec.md:需求plan.md:方案tasks.md:任务- 代码 + 测试:实现
但代码写完还不等于真正完成交付。
团队开发还必须经过 3 步:
- 代码审查
- 版本记录
- 发起 PR 协同
所以 20 讲讲的是:
AI 不仅帮你写代码,还帮你把代码“工程化交付出去”。

三、为什么要用 Slash Command,而不是临时 Prompt?
这是本讲最重要的点之一。
临时 Prompt 的问题
比如你随手说:
- 帮我审查 internal/
- 看看代码有没有问题
问题在于:
- 标准不稳定
- 每次问法不一样
- AI 输出质量波动大
- 团队成员之间无法统一
- 经验无法沉淀
Slash Command 的价值
如果把审查逻辑固化进:
./.claude/commands/review-go-code.md
那么得到的是:
- 固定审查准则
- 固定工具权限
- 固定输出格式
- 固定和
constitution.md对齐 - 团队所有人调用结果一致
所以:
Prompt 是临时发挥,Slash Command 是团队标准资产。
四、/review-go-code 的本质
它不是“让 AI 随便看看”,而是:
把团队对好代码的共识,封装为一个可重复执行的审查程序。
它包含几层东西:
1. 审查对象
@$1,比如 internal/
2. 审查依据
constitution.mdgo vet- 团队审查准则
3. 审查维度
- 简单性原则
- 明确性原则
- 单一职责原则
4. 输出格式
- 总体评价
- 优点
- 待改进项
- 高优先级
- 中优先级
- 低优先级
所以它本质上是:
“审查 SOP + 宪法 + 工具链”的组合体。
五、这一讲的 AI 审查有什么意义?
Tony 强调的是:
AI 交叉审查
也就是:
- 上一讲 AI 参与写代码
- 这一讲 AI 再站到“独立审查者”视角来查代码
这构成一个闭环:
AI 生成
→ AI 审查
→ 人类确认
→ AI 修复
这非常关键,因为人类也会漏看。
所以 AI 审查的价值是:
1. 补盲区
人容易忽略一些机械性问题或一致性问题。
2. 标准化
不靠个人水平,而靠统一规则。
3. 提高交付前质量
在 commit / PR 前提前拦问题。
六、审查报告怎么看?
一个好的审查报告,不只是“挑刺”,而是应该有结构:
1. 总体评价
一句话判断整体质量
2. 优点
不是只找错,也要指出做得好的地方
3. 待改进项
按优先级划分:
- 高优:必须改
- 中优:强烈建议
- 低优:风格优化
4. 明确定位
要说清楚:
- 文件名
- 行号
- 问题描述
- 修改建议
所以它其实已经接近正式 code review 产物了。
七、这一步体现了什么 AI 原生特征?
这一步非常像真正团队里的“双人 review”,但这里是:
AI 先审,人工最终裁决。
重点不是让 AI 代替人,而是让 AI 先做一轮高标准预审。
所以推荐流程是:
代码完成
→ /review-go-code
→ AI 报告
→ AI 或人工修复
→ 再跑 build/test/vet
→ 准备 commit
八、审查后怎么处理?
Tony 给的做法很直接:
“请修正你刚才提出的高优先级问题。”
这说明 AI 审查不是终点,而是下一轮执行输入。
也就是说:
审查输出 = 下一轮修复上下文
这就是 AI 工作流里很典型的:
输出即上下文
九、第二步:/commit 指令的本质
这一步把“写 commit message”标准化了。
传统流程里,commit 常见问题是:
- 写得很随意
- 太短
- 太空泛
- 不符合规范
- 看不出改了什么
而 /commit 指令把这个过程变成:
读取 staged diff
→ 根据 CLAUDE.md 的 Conventional Commits 规范生成 message
→ 给用户确认
→ 执行 git commit
所以它的本质是:
把 Git 提交动作,从随手操作变成受规范约束的标准流程。
十、为什么 commit message 也值得交给 AI?
因为 AI 特别擅长这类工作:
1. 它能看完整 diff
比人更快汇总变化点。
2. 它能套规范
像 Conventional Commits 这种格式,它很稳定。
3. 它能写得比大多数人更完整
尤其是多模块修改时,人类常常懒得总结。
所以 AI 在这里很适合扮演:
“版本史官”
帮你把一次变更准确记录进项目历史。
十一、第三步:AI 生成 PR 描述
这一段很重要,因为很多团队的 PR 描述都写得很差。
常见问题:
- 只有一句话
- 没背景
- 没实现思路
- 没测试说明
- reviewer 不知道怎么验
AI 正好非常适合做这件事。
Tony 要求 PR 描述包含:
- 背景
- 实现方案
- 测试
- 如何手动验证
这其实已经是一份优秀 PR 模板。
十二、为什么 PR 描述特别适合 AI?
因为 PR 描述需要整合大量上下文:
spec.mdplan.mdtasks.md- 实际实现
- 测试方式
- 验证步骤
人类写这个很费脑,但 AI 正好擅长整合这些上下文。
所以 AI 的价值不只是“生成文字”,而是:
把整个开发过程压缩成 reviewer 易读的协作说明。
十三、PR 描述的核心结构要背住
一个高质量 PR 描述,最少应该包含:
1. Context
为什么做这个 PR
2. Implementation
怎么实现的
3. Testing
怎么保证没坏
4. How to Verify
reviewer 本地怎么验
这是以后你自己也可以复用的 PR 模板骨架。
十四、这一讲其实在做什么升级?
从 19 讲到 20 讲,本质变化是:
- 19 讲:AI 帮你写代码
- 20 讲:AI 帮你做团队协作文档与交付动作
也就是说,AI 的角色从:
执行者
升级到:
协同助手 + 工程文档官 + 审查辅助者
这意味着 AI 不再只参与“coding”,而是开始参与:
- review
- commit
- PR
- 团队沟通
十五、能不能直接创建 PR?
可以。
Tony 提到如果配置了 GitHub MCP Server,并授予相应权限,就可以直接让 AI:
- 调用 GitHub 工具
- 创建 PR
- 填入 title 和 description
这说明工作流还能继续往前推进:
生成 PR 描述
→ 调用 GitHub MCP
→ 直接创建 PR
这就是从“辅助写作”走向“执行协同动作”。
十六、为什么这里强调 Slash Command,而不是 Skill?
这是本讲最容易考的辨析点。
Slash Command 适合什么?
适合:
- 标准流程
- 必须执行
- 要求确定性高
- 结果格式固定
例如:
- review
- commit
- release checklist
Skill 适合什么?
适合:
- 开放探索
- 不确定任务
- 自主发现问题
- 专家辅助判断
例如:
- 帮我看看项目哪里能优化
- 这个错误可能是什么原因
- 帮我探索一种新方案
所以结论是:
标准流程用 Slash Command,探索任务用 Skill。
在 SDD/工程交付里,review、commit、PR 这类动作更强调确定性,所以 Slash Command 更合适。
十七、本讲的本质:把“协作动作”也资产化
前面我们资产化的是:
- 规范
- 方案
- 任务
- 上下文
这一讲开始资产化的是:
- 审查流程
- 提交流程
- PR 生成流程
这很关键,因为真正成熟的 AI 原生开发,不是只有“写代码能力”,而是:
连协作方式本身都被模板化、标准化、可复用化。
十八、本讲核心流程图
代码写完
│
├── /review-go-code internal/
│ ├── 读取 internal/
│ ├── 读取 constitution.md
│ ├── 跑 go vet
│ └── 输出结构化审查报告
│
├── 根据审查结果修复问题
│ ├── 高优先级先修
│ ├── build/test/vet 验证
│ └── 达到可提交状态
│
├── /commit
│ ├── 读取 git diff --staged
│ ├── 生成 Conventional Commit
│ ├── 用户确认
│ └── 执行 git commit
│
└── 生成 PR 描述
├── 背景
├── 实现方案
├── 测试
└── 如何验证
十九、学霸速记
这讲的核心目标
把“本地代码”转成“高质量 PR”。
三个关键动作
- AI 审查
- AI 生成 commit
- AI 生成 PR 描述
/review-go-code 的价值
把团队代码审查标准封装成统一命令。
为什么用 Slash Command
因为审查和提交流程要求确定性和标准化。
PR 描述的四要素
- 背景
- 实现方案
- 测试
- 如何验证
本讲最重要的区分
- 标准流程:Slash Command
- 探索任务:Skill
二十、这讲最值得记住的三句话
1
AI 不只帮你写代码,也帮你“写好关于代码的一切”。
2
Prompt 是临时发挥,Slash Command 是团队标准资产。
3
标准流程用指令,探索任务用技能。
二十一、学霸总结
这一讲讲的是 AI 原生开发进入团队协作阶段后的关键升级:
让 AI 参与代码审查、版本记录和 PR 协同。
它的核心不是“再生成一点文字”,而是把本来依赖个人习惯和软技能的协作动作,沉淀为可以标准化执行的工程流程。
其中最关键的实践是调用框架中的 /review-go-code。
它说明真正有价值的不是临时问 AI“帮我看看代码”,而是把团队认可的代码审查标准——包括项目宪法、静态检查和输出格式——固化为 Slash Command。这样,任何人调用,都会得到同一套标准、可重复、可传承的审查结果。
随后,AI 又继续承担了“版本史官”和“技术文档专家”的角色:
- 用
/commit自动分析 diff,生成符合 Conventional Commits 的提交信息 - 基于完整上下文生成高质量 PR 描述,让 reviewer 能快速理解背景、实现方式、测试覆盖和验证步骤
所以,这一讲最本质的升级是:
AI 从代码生成器,进一步升级为工程协作与交付助手。
从这一刻起,AI 原生开发不再只是“我和 AI 写代码”,而是:
我和 AI 一起完成一整套面向团队的工程交付流程。
二十二、一句话记忆
20 讲的本质,是把代码审查、提交和 PR 描述也纳入 AI 驾驶舱,用标准化指令把“本地代码”升级为“高质量协作交付物”。