「代码审查不是为了证明你是对的，而是为了证明代码没有错。」
在传统的软件工程中，代码审查（Code Review）往往是最容易被忽视却又最关键的环节。开发者忙于交付功能，审查者碍于情面不愿直言，最终让带着缺陷的代码溜进生产环境。
今天，我要介绍一个颠覆性的 AI 代码审查工作流——它不懂得「客气」，只懂得「找茬」。
一、什么是「对抗式」代码审查？
这个工作流的核心哲学很简单：**NEVER accepts "looks good"**（永远不要接受「看起来不错」）。
它被设计成一个持有批判立场的高级开发者，必须在每次审查中找出 3-10 个具体问题。这不是为了刁难，而是为了确保：
- ✅ 任务标记为
[x] 的真的是完成了
- ✅ 验收标准真的是实现了，不是糊弄
- ✅ 代码质量经得起安全、性能、可维护性考验
description: "Perform an ADVERSARIAL Senior Developer code review
that finds 3-10 specific problems in every story. Challenges everything:
code quality, test coverage, architecture compliance, security, performance.
NEVER accepts `looks good`"
二、工作流全流程解析
步骤 1：加载故事 + 发现真相
审查的第一步是「对账」——对比开发者声称改了什么和 Git 仓库实际改了什么。
git status --porcelain # 找未提交的改动
git diff --name-only # 看修改了哪些文件
git diff --cached --name-only # 看暂存区的文件
发现真相的三个维度：
- Git 有改动，但故事文件里没记录 → 文档不完整
- 故事声称改了文件，但 Git 没痕迹 → 虚假声明
- 有未提交改动没追踪 → 透明度问题
步骤 2：构建「攻击计划」
系统会自动提取：
- 所有验收标准（Acceptance Criteria）
- 所有任务及其完成状态
- 开发者记录的文件列表
然后制定审查计划：
- AC 验证：每个验收标准真的实现了吗？
- 任务审计：每个打钩的任务真的完成了吗？
- 代码质量：安全、性能、可维护性
- 测试质量：是真测试还是占位符？
步骤 3：执行对抗式审查
这是最核心的环节。AI 会逐文件逐行检查：
🔴 CRITICAL ISSUES（必须修）
├── 任务标记 [x] 但实际没实现
├── 验收标准没有实现
├── 故事声称改了文件但 Git 无证据
└── 安全漏洞
🟡 MEDIUM ISSUES（应该修）
├── 改了文件但没记录到故事文件列表
├── 未提交的改动未追踪
├── 性能问题
├── 测试覆盖率/质量不足
└── 代码可维护性问题
🟢 LOW ISSUES（可以修）
├── 代码风格改进
├── 文档缺失
└── Git 提交信息质量
关键机制：如果发现问题少于 3 个，AI 会被要求继续深挖：
<check if="total_issues_found lt 3">
<critical>NOT LOOKING HARD ENOUGH - Find more problems!</critical>
<!-- 重新检查边界情况、架构违规、集成问题... -->
</check>
步骤 4：呈现发现 + 自动修复
审查结果呈现后，开发者有三种选择：
| 选项 |
行动 |
| 1️⃣ 自动修复 |
AI 直接修改代码和测试 |
| 2️⃣ 创建行动项 |
将问题加入故事的待办任务 |
| 3️⃣ 深入查看 |
显示问题的详细解释和代码示例 |
步骤 5：状态同步
最后，系统会自动：
- 更新故事状态（done / in-progress）
- 同步到
sprint-status.yaml
- 记录审查历史到 Change Log
三、与传统 Code Review 的对比
| 维度 |
传统 Code Review |
AI 对抗式审查 |
| 态度 |
礼貌、顾忌 |
直接、不留情面 |
| 覆盖度 |
随机抽查 |
100% 覆盖 |
| 速度 |
依赖人工时间 |
即时反馈 |
| 一致性 |
审查者水平波动 |
标准统一 |
| 可追溯 |
口头讨论或零散记录 |
结构化问题列表 |
四、实战案例示例
假设开发者提交了一个「用户认证」功能：
开发者声称：
[x] 实现登录 API
[x] 添加 JWT 验证
[x] 编写单元测试
AI 对抗式审查发现：
🔴 CRITICAL: 任务标记 [x] 但未实现
├── src/auth/login.ts:45 - JWT 密钥硬编码，应从环境变量读取
└── tests/auth.test.js - 所有测试都使用 t.skip() 跳过
🟡 MEDIUM: 性能问题
└── src/auth/login.ts:23 - 每次登录都查询数据库获取用户权限
建议：使用 Redis 缓存用户权限
🟡 MEDIUM: 测试质量不足
└── tests/auth.test.js - 缺少错误场景测试（密码错误、用户不存在）
结果？开发者必须修复这些问题才能标记为「完成」。
五、真实对话记录
想看看 AI 对抗式代码审查的真实运行过程吗？
完整对话记录：https://autoqa-chats.lovable.app/chat/27
在这个真实对话中，你可以看到 AI 如何：
- 逐个检查验收标准的实现情况
- 发现被标记为「完成」但实际上未完成的任务
- 指出代码中的安全和性能问题
- 要求开发者修复后才通过审查
六、工作流架构图
七、如何集成到你的项目？
这个工作流是 BMAD v6 框架的一部分。基本集成步骤：
- 安装 BMAD v6: npx bmad-method@alpha install
- 实现故事：
/dev-story
- 触发审查：
/code-review
八、总结：为什么「找茬」很重要？
代码审查的本质是质量门禁。在 AI 辅助开发时代，我们不再需要人类做机械性的代码扫描，但我们需要一个永不妥协的质量守门员。
这个 AI 代码审查工作流的独特价值在于：
- ✅ 不讲人情：只认代码，不认关系
- ✅ 事必躬亲：逐文件验证，不遗漏
- ✅ 知识驱动：结合架构文档、项目上下文综合判断
- ✅ 可自愈：发现问题时可以自动修复
正如工作流文档所说：
"YOU are so much better than the dev agent that wrote this slop"
这种「对抗」不是对抗开发者，而是对抗缺陷、对抗技术债务、对抗生产环境的故障。
📚 延伸阅读
Select Language