AI 编程如何保证代码质量?从上下文、实现计划到双重代码审查的完整方法

引言

大多数开发者用 AI 写代码时，走的都是同一条路：把提示词贴进 ChatGPT，复制输出，盼着它能运行，出错了再调试。刚开始很快，直到有一天快不起来。

其实还有更好的办法。

与其把 AI 当成一台代码自动售货机，不如建立一套结构化、可重复的工作流：让 AI Agent 负责规划、实现、测试和审查，而关键决策仍由你掌握。

本文会从头到尾拆解一套完整的多 Agent AI 开发工作流，其中包括规划、测试驱动开发（TDD）和代码审查。读完后，你会得到一套能应用于任何项目、任何功能的流程。

🚀 Claude Code 与编程 Agent 完整课程[1]

临时拼凑式 AI 编程的问题

让 AI 生成代码很容易，生成一份你能理解、能信任、也能长期维护的代码，却难得多。

典型的“从 ChatGPT 复制代码”模式有几个核心问题：

• 缺少共享上下文——AI 不了解你的代码库、约定和限制。
• 缺少结构——你拿到了代码，却没有计划、测试和审查。
• 缺少责任追踪——输出一旦有误，往往要等到系统出问题后，你才知道原因。

下面这套工作流正是为了解决这三个问题。

六步多 Agent AI 工作流

我用 AI Agent 交付功能的完整工作流[2]

第一步：用“Grill with Docs”补足深层上下文

在写下第一行代码之前，AI 需要理解整个项目，而不只是眼前的任务。

Grill with Docs 是 Matt Pocock 创建的一项技能[3]，它会引导 AI 围绕你的代码库、设计决策和需求，提出一组结构化的深入问题。你可以把它理解成正式实现前的一次需求探索会。

会话结束后，AI 会生成一份 context.md 文件，其中记录：

• 术语表，例如项目里的“post”或“slug”具体指什么
• 数据模型和核心实体
• 双方约定的 API 接口边界
• 数据迁移和策略决策

这种共享理解有时也叫通用语言，它是后续所有工作的基础。随着你继续开发更多功能，新术语也会自动补充进这份文档。

实用建议： 如果追问过程中遇到你答不上来的问题，可以选择推荐选项。实践中，AI 给出的推荐通常相当可靠。

第二步：生成实现计划

上下文确定之后，与其立刻动手实现，不如先用 Claude Code 的 Superpowers 插件生成一份结构化的实现计划。

这份计划会非常详细，往往超过 1,000 行，其中包括：

• 实现该功能所需的每一项任务
• 按依赖关系分组的任务，从而识别出可以并行推进的工作
• 足够具体的执行说明，让成本更低的模型也能完成单项任务

这是关键的一步。先让能力强的模型（例如 Claude Opus）写计划，再让更轻量的模型（例如 Haiku）负责实际实现，便能在保证质量的同时降低词元成本。

第三步：用子 Agent 和 TDD 实现

计划就绪后，就可以通过 Superpowers 插件里的子 Agent TDD 技能启动实现。

整个过程是这样运转的：

• 计划中的每项任务都会交给一个独立的子 Agent
• 可以并行的任务会同时执行
• 每个子 Agent 都从一个干净、聚焦的上下文窗口开始，免受无关任务的干扰

更重要的是，实现过程遵循测试驱动开发（TDD）：

1. 红灯——先写一个必然失败的测试
2. 绿灯——只写刚好能让测试通过的代码
3. 重构——在测试保护下整理代码

TDD 并非只适用于人类开发者，同样适合 Agent 编程。测试能立即告诉 Agent 代码是否正确，因此会显著改善输出质量。

第四步：人工代码审查

代码写完后，由你来审查。

即便有 AI 协助，这一步也绝非可选项。人工审查有两个目的：

1. 质量控制——确认代码结构和设计决策符合你的偏好。如果 AI 把逻辑放错了文件，或做出了你不认同的架构选择，这时就应该调整。
2. 学习——如果你正在提升编程能力，阅读 AI 生成的代码很有价值。遇到陌生的函数或模式，可以让 AI 解释清楚。

这一轮的目标并非找出每一个 bug——那是下一步要处理的事。这里真正要确认的是：代码的组织方式符合你的预期。

第五步：AI 代码审查

人工检查完成后，再让一个全新的 AI Agent 做代码审查。

第二轮 AI 审查很有价值，原因包括：

• 干净的上下文可以避免审查者受到实现阶段决策的先入影响
• 它能发现实现 Agent 遗漏的边界情况
• 换用不同的模型，例如让 Claude Opus 审查 Sonnet 写的代码，可以减少盲区

即便你只有一种模型可用，也值得完成这一步。同一个模型在全新会话中审查自己的代码，往往仍能找出第一次遗漏的问题。

Superpowers 插件里的代码审查技能会识别问题、提出修复建议并应用修改，最后给出变更摘要，以及留待后续处理的事项。

第六步：人工质量检查 / 用户验收测试

最后一步，是站在最终用户的角度测试功能。

让 AI 为这项功能生成一份质量保证（QA）方案，其中会包括：

• 需要测试的所有核心场景
• 需要验证的边界情况
• 每项测试的逐步操作说明

如果是 API 项目，可以使用 Postman、编辑器中的 REST 插件，甚至直接运行 AI 建议的 bash 命令。如果是 UI，则在浏览器里直接测试。

这一步只关心一件事：确保功能真正按照用户的预期工作，而非仅仅符合代码写下的行为。

实战案例：实现文章 slug 功能

下面用一个具体案例说明这套工作流如何应用于博客 API 项目的真实功能。

功能需求：

• 为 Post 模型增加一个 slug 字段，要求唯一，并根据标题自动生成
• 格式采用 kebab-case，例如 my-post-title
• 文章标题变化时自动更新 slug
• 新增一个通过 slug 获取文章的端点

这套工作流最终产出了：

• 一份记录数据模型与 slug 生成策略的 context.md
• 一份超过 1,000 行的实现计划，拆成 13 项可并行任务
• 13 个提交，每项任务一个，而且都经过测试验证
• 一轮代码审查，发现了边界情况和一些小问题
• 一份覆盖所有 slug 场景的完整用户验收测试（UAT）方案

整个过程中，繁重的工作由 AI Agent 完成，重大决策则始终掌握在开发者手中。

核心要点

• 上下文优先。 AI 输出的质量与所提供上下文的质量成正比。Grill with Docs 会强制先补齐这一步。
• 先规划，再动手。 让能力强的模型编写实现计划，再由成本更低的模型负责执行，既节省词元，也能保证质量。
• TDD 同样适合 Agent。 子 Agent TDD 能借助测试提供即时反馈，从而产出质量更高的代码。
• 始终参与其中。 人工代码审查绝非可选项，你需要理解最终构建出了什么。
• 两轮审查胜过一轮。 换一个全新上下文再做一轮 AI 审查，可以发现第一轮遗漏的问题。
• 像用户一样测试。 AI 生成的质量保证方案会给你一份结构化清单，最终仍需要你亲自执行测试。

结语

AI 辅助开发的要义并非把代码写得更快，而是建立一套可重复的流程，产出你真正理解、也愿意为之负责的代码。

本文介绍的六步工作流——收集上下文、制定实现计划、子 Agent TDD、人工审查、AI 代码审查和人工质量检查——正是这样一套流程。它比直接从 AI 对话里复制粘贴稍慢一些，但产出完全不在同一层次：有结构、经过测试、接受过审查，而且真正属于你。

把它用在下一个功能上，看看会有什么不同。

你在关注什么场景的 Agent？采购、客服、还是别的？评论区或私信告诉我，下一篇从大家的需求里挑。

参考资料:

1. https://trk.udemy.com/PzbLxN
2. https://www.youtube.com/watch?v=ls-gruxjQ4M
3. https://github.com/mattpocock/skills

原文链接： https://blog.alexrusin.com/ai-multi-agent-workflow-feature-development/