---
url: /blog/r98g73tf/index.md
---
## 1. 摘要与背景

传统的AI编程方式（打开编辑器 -> 输入模糊提示 -> 调试半成品代码）往往只能带来约20%的效率提升，甚至可能因修复AI幻觉而降低效率。

本方法论基于实战经验，提出了一套\*\*"多模型协作 + 严格验证环"\*\*的开发流程。通过将人类工作的重心从"编码实现"转移至"规划与验证"，实现了超高效率的交付。关键在于认识到：**当编码速度趋近于无限快时，规划和验证就成了新的瓶颈。**

***

## 2. 核心哲学：规划前置 (The Core Insight)

在传统编码中，规划与实现是交织进行的。但在AI辅助开发中，实现的成本被极度压缩。如果规划有误，AI会以超人的速度执行错误的计划。

* **原则**：在规划阶段投入比传统模式多2-3倍的时间。
* **收益**：通过前期详尽的Spec设计，避免后期的返工和调试螺旋。
* **质量保证**：代码量的1/3至1/2应为测试代码（单元测试与集成测试），这是自动化生成的安全网。

***

## 3. 标准作业程序 (SOP)

### 步骤一：生成并验证规格计划 (Generate & Verify Spec Plan)

**目标**：在写第一行代码前，产出无歧义的工程实施方案。

1. **初始规划**：

   * 使用高智力模型（如 Codex CLI / GPT-5.2-xhigh）。
   * 输入：PRD（产品需求文档）。
   * 输出：`<feature_name_plan>.md`。
   * **关键Prompt策略**：强制AI在生成前提出澄清问题，通过问答消除需求模糊地带。

   > **Prompt 示例：**
   > "<粘贴 PRD 内容>。请浏览代码库并创建一个 Spec-kit 风格的实施计划，写入到 \<feature\_name\_plan>.md。
   > **在创建此计划之前，请就需求、约束条件或边缘情况向我提出任何澄清性问题。**"

2. **交叉质询（Cross-Model Review）**：
   * 利用不同模型的"认知差异"进行对抗性审查。
   * 方法：让 Claude (Opus 4.5) 审查 GPT 生成的计划，反之亦然。
   * 关注点：架构漏洞、错误处理遗漏、逻辑自洽性。
   * 迭代：根据模型反馈修改计划，直到多方达成一致。

3. **计划书包含要素**：
   * 涉及修改/创建的具体文件列表。
   * 数据结构与接口定义。
   * 具体的设计决策。
   * **每一步的验证标准**（至关重要）。

### 步骤二：带验证环的实现 (Implement with Verification Loop)

**目标**：执行计划，并确保每一步都可控。

1. **执行策略**：

   * **后端**：在实现前先编写执行脚本或集成测试。
   * **前端/全栈**：挂载可视化环境（如 Claude Code Chrome），进行视觉验证。

   > **Prompt 示例：**
   > "根据 '[plan.md](http://plan.md/)' 执行实现。每完成一步，运行 \[验证循环/测试脚本] 并确认输出符合预期。如果不符合，请调试并迭代直到通过。每一步完成后，请在计划文档中记录进度，并记下实施过程中所做的任何设计决策。"

2. **过程监控**：
   * **频率**：每10分钟检查一次计划文档的更新。
   * **干预**：一旦发现设计决策偏离预期，立即停止Agent并重新Prompt。
   * **文档同步**：要求Agent实时更新Spec中的设计选择，作为即时文档。

### 步骤三：多模型交叉代码审查 (Cross-Model Review)

**目标**：在人类介入前，利用AI消除明显的Bug和逻辑错误。

1. **对抗性审查**：

   * 如果代码是 Claude 写的，让 Codex 进行审查，反之亦然。
   * **角色设定**：要求AI以"Staff Engineer（资深架构师）"的视角审查。

   > **Prompt 示例：**
   > "以资深工程师的严谨标准，根据 <[plan.md](http://plan.md/)> 审查未提交的代码变更。你是否发现任何正确性、性能或安全性方面的问题？"

2. **人工验收**：
   * **手动测试**：验证实际运行效果，覆盖AI未考虑的边缘情况。
   * **代码阅读**：逐行阅读变更文件。重点关注架构漂移（Architectural Drift）、不必要的复杂度及反模式。
   * **文档终态**：让Agent将最终的实现细节回写到Spec中，作为永久技术文档。

### 步骤四：CI/CD 与 自动化审计 (Commit & AI Audit)

1. **提交代码**：执行 Git Commit & Push。
2. **AI Code Review 工具**：
   * 使用工具：Coderabbit, Bugbot 等。
   * 关注点：安全性漏洞、性能反模式、可维护性问题。
   * **行动**：必须修复发现的有效问题，不可直接忽略合并。
3. **合并**：当所有自动化检查通过后，合并进入主分支。

***

## 4. 实战时间表案例 (Example Workflow)

**任务**：添加一个新的语义搜索 Agent 会话提供程序 (Session Provider)。

| 时间        | 阶段     | 动作描述                                  |
| :-------- | :----- | :------------------------------------ |
| **09:00** | 启动     | 使用 Codex CLI 输入 PRD，要求其先提问。           |
| **09:20** | 澄清     | 回答关于日志格式、接口定义、Embedding 策略的问题。        |
| **09:45** | 规划审查   | Claude Opus 审查计划，指出缺少错误处理机制。更新计划。     |
| **10:15** | 二次审查   | GPT-5.2 指出缺少速率限制（Rate Limiting）。完善计划。 |
| **10:45** | 开始实现   | 指令 Claude Code 开始编码，使用集成测试作为验证环。      |
| **11:45** | 实现完成   | 测试通过。人工检查 Spec 中的设计决策，确认无误。           |
| **12:00** | 交叉审查   | Codex 发现接口问题，Opus 进行修复。               |
| **12:30** | 人工测试   | 发现时间戳边缘情况，回炉 Claude Code 修复。人工阅读所有代码。 |
| **13:30** | 提交审计   | 推送代码。Coderabbit 发现输入清洗的安全隐患。          |
| **13:45** | 完成     | 修复安全问题，重新推送，合并。Agent 更新最终 Spec。       |
| **结果**    | **交付** | **5小时内完成一个生产级、文档齐全的功能模块。**            |

***

## 5. 局限性与风险 (Limitations)

尽管此流程效率极高，但在以下场景需谨慎使用：

1. **冷启动 (Cold Start)**：在AI未见过的全新代码库中，需要花费大量时间补充上下文（文档、示例、架构说明）。
2. **创新架构 (Novel Architectures)**：当构建没有任何先例的全新系统时，AI 倾向于套用训练数据中的旧模式，可能导致设计平庸。
3. **隐蔽缺陷 (Subtle Issues)**：AI 擅长解决显性 Bug，但对于竞态条件（Race Conditions）、大规模并发下的性能回退等问题，仍需依赖人类直觉。
4. **过度信任 (Trust Trap)**：不要让 Agent 跑太久不检查。一旦它在一个错误的设计假设上跑偏，回滚成本极高。

***

## 6. 结论

**"信任，但要验证 (Trust but Verify)"**

赢得 AI 编程时代的关键不在于谁的 Prompt 打字更快，而在于谁能通过更严谨的\*\*规划（Planning）**和**验证（Verification）\*\*流程，驾驭 AI 的生产力。

* **多模型**互为攻守。
* **测试**即是护栏。
* **文档**驱动开发。
* **人类**把控架构与质量。

## 参考资料

* [How to write 400k lines of production-ready code with coding agents](https://www.reddit.com/r/ClaudeCode/comments/1q7ncvv/how_to_write_400k_lines_of_productionready_code/)