BMad v6实战第三弹：对抗式代码审查(Code Review)

BMad v6实战第三弹：对抗式代码审查(Code Review)。

在传统的软件工程中，代码审查（Code Review）往往是最容易被忽视却又最关键的环节。开发者忙于交付功能，审查者碍于情面不愿直言，最终让带着缺陷的代码溜进生产环境。今天，我要介绍一个颠覆性的 AI 代码审查工作流——它不懂得‘客气’，只懂得‘找茬’。

这个工作流的核心哲学很简单：NEVER accepts “looks good”（永远不要接受‘看起来不错’）。它被设计成一个持有批判立场的高级开发者，必须在每次审查中找出 3-10 个具体问题。这不是为了刁难，而是为了确保任务标记为 [x] 的真的是完成了，验收标准真的是实现了，不是糊弄，代码质量经得起安全、性能、可维护性考验。

工作流全流程解析分为四个步骤：

1. 加载故事 + 发现真相：审查的第一步是‘对账’——对比开发者声称改了什么和 Git 仓库实际改了什么。
2. 构建‘攻击计划’：系统会自动提取所有验收标准、任务及其完成状态、开发者记录的文件列表，然后制定审查计划，包括验证验收标准、审计任务、检查代码质量和测试质量。
3. 执行对抗式审查：AI 会逐文件逐行检查，发现 CRITICAL ISSUES（必须修）、MEDIUM ISSUES（应该修）和 LOW ISSUES（可以修）。
4. 呈现发现 + 自动修复：审查结果呈现后，开发者有三种选择，系统会自动更新故事状态、同步到 sprint-status.yaml、记录审查历史到 Change Log。

与传统 Code Review 的对比，这个工作流更加严格和深入，确保代码质量。

实战案例示例中，假设开发者提交了一个‘用户认证’功能，AI 对抗式审查发现了一些 CRITICAL 和 MEDIUM 问题，要求开发者必须修复这些问题才能标记为‘完成’。

真实对话记录展示了 AI 如何逐个检查验收标准的实现情况、发现被标记为‘完成’但实际上未完成的任务、指出代码中的安全和性能问题、要求开发者修复后才通过审查。

工作流架构图展示了整个审查过程的流程。

如何集成到你的项目？基本集成步骤包括安装 BMAD v6、实现故事、触发审查。

总结：为什么‘找茬’很重要？代码审查的本质是质量门禁。在 AI 辅助开发时代，我们不再需要人类做机械性的代码扫描，但我们需要一个永不妥协的质量守门员。这个 AI 代码审查工作流的独特价值在于不讲人情、事必躬亲、知识驱动和可自愈。

延伸阅读：BMAD 工作流框架和 workflows 配置。