前言

最近在开发项目时，我经常使用 Codex、Claude Code 这些 AI Coding 工具。不得不说，AI 确实能帮我省下不少写代码的时间，但用得越多，我也发现了一些问题。

比如项目出现 Bug，我通常就是直接告诉 AI 哪里报错了，让它帮我修改。改完之后运行，发现还是不对，于是继续把新的报错发给它，让它接着改。就这样来来回回折腾了好几轮，问题可能还是没解决，有时候甚至把原本正常的功能也改出了问题。

后来我发现，虽然我一直在用 AI 辅助开发，但其实大部分时间都只是在和 AI 不停地对话。 遇到问题就让它改，改错了就继续问，整个过程没什么章法，也缺少对修改结果的验证。

开发新功能也是一样，往往就是把需求直接丢给 AI，然后根据它写出来的东西不断补充要求。至于应该让 AI 自己完成哪些工作、什么时候需要我介入、怎样才能保证最终代码是正确的，我之前并没有认真想过。

所以我专门去查了一些 Codex、Claude Code 的官方最佳实践，也了解了一下实际开发中比较常用的 AI Coding 工作方式，整理成了这篇文章。

主要想弄清楚两个问题：

  1. 平时到底应该怎样使用 AI 辅助开发，才能更高效、更有章法？
  2. 当 AI 反复修改 Bug 却始终解决不了时，应该怎么办？

也算是对自己平时使用 AI Coding 的一次总结，希望以后能少一些来回折腾，让 AI 真正帮我提高开发效率。

一、如何使用 AI 辅助开发？

常用工具：Codex、Claude Code。

核心流程：需求分析 → 方案设计 → 代码实现 → 测试验证 → 代码审查

1. 需求分析

目的： 明确功能需求、输入输出、边界条件及验收标准。

**如何操作：

示例 Prompt：

我需要在当前 Spring Boot 项目中新增订单分页查询功能，支持按用户 ID 和订单状态筛选。请先分析需求，明确接口参数、返回格式、边界条件及验收标准。暂时不要修改代码。

2. 方案设计

目的： 让 AI 理解现有架构，制定符合项目规范的实现方案。

**如何操作：

示例 Prompt：

请阅读当前项目相关代码，分析 Controller、Service、Mapper 的调用关系。列出需要修改的文件、方法及数据库查询方案，并说明原因。先不要修改代码。

Agent 可以自主搜索文件、分析调用链，不需要手动逐个提供源码。

3. 代码实现

目的： 按照确定的方案完成代码开发。

**如何操作：

示例 Prompt：

按照刚才确认的方案实现功能。遵循现有项目规范，优先复用已有代码，不要修改无关模块。完成后列出修改的文件和主要逻辑。

Agent 可以直接编辑 Controller、Service、Mapper 等文件。

4. 测试验证

目的： 验证代码是否满足需求，而不只是能够编译运行。

**如何操作：

示例 Prompt：

请为新增功能编写测试用例，覆盖正常查询、空结果、分页边界和非法参数。执行相关测试，若失败请分析实际报错并修复，不要通过删除断言或跳过测试来制造通过结果。

5. 代码审查

目的： 检查代码质量，避免无关修改和潜在问题。

**如何操作：

示例 Prompt：

请使用 Git Diff 检查本次所有修改，重点检查业务逻辑、异常处理、重复代码及是否破坏原有功能。列出发现的问题，不要直接修改。

相关终端命令：

  • git status：查看修改了哪些文件。
  • git diff：查看具体代码差异。

6. 实际开发时，如何组织 Prompt？

上述五个步骤是开发流程，不代表必须分别发送五条 Prompt。

实际使用 Codex、Claude Code 时，主要有两种方式。

方式一：简单任务——一次性下达完整指令

适用场景： 需求明确、修改范围较小、风险较低的任务，例如新增普通 CRUD 接口、修改简单 Bug。

操作方式： 把需求分析、方案设计、代码实现、测试验证和代码审查合并到一条 Prompt 中，让 Agent 自主执行。

完整示例：

请在当前 Spring Boot 项目中新增订单分页查询接口，支持根据用户 ID 和订单状态筛选。

请按照以下流程自主完成：

  1. 阅读项目相关代码，了解现有架构和编码规范。
  2. 明确接口参数、返回格式和边界条件，制定实现方案。
  3. 按照现有规范完成 Controller、Service、Mapper 等必要修改，不要修改无关模块。
  4. 编写并运行相关测试，覆盖正常查询、空结果、分页边界和非法参数。如果测试失败，请根据实际报错分析并修复。
  5. 最后通过 Git Diff 审查改动，汇报修改文件、测试结果和潜在风险。

请自主完成以上流程，遇到需求不明确或高风险操作时再向我确认。

特点： 开发者只需提供任务目标、约束和验收标准，Agent 自主调用文件操作、终端和测试工具，不需要每一步人工干预。

方式二：复杂任务——分阶段下达指令

适用场景： 涉及多个业务模块、复杂状态流转、数据库一致性或高风险操作的任务。

例如：在在线商城支付系统中新增支付宝退款功能。

第一阶段：分析与方案设计

Prompt：

请分析当前商城项目的支付流程、订单状态机、数据库结构及相关接口，设计支付宝退款功能。

列出需要修改的文件、退款状态流转、幂等性方案和测试计划，并指出潜在风险。

本阶段只分析和设计，不要修改业务代码，等待我确认方案。

Agent 完成分析后，由开发者审查方案。如果方案不合理，可以继续讨论修改。

第二阶段：代码实现与验证

确认方案后输入：

方案确认。请按照确定的设计实现退款功能。

你可以自主完成代码修改、测试编写、测试执行和 Git Diff 审查，不需要每一步都向我确认。

如果需要执行真实退款、破坏性数据库操作或者修改已确认的核心设计，请先暂停并征求我的确认。

完成后汇报修改内容、测试结果和剩余风险。

特点： 在重要技术决策处设置人工检查点（Human-in-the-loop），其余过程由 Agent 自主完成。

核心原则：简单任务尽量自动化，复杂任务设置关键检查点，最终以实际测试结果作为验收依据。

二、如果 AI 反复修改 Bug，仍然无法解决怎么办？

核心流程：停止修改 → 回顾问题 → 恢复基线 → 定位根因 → 最小修复 → 回归测试

1. 停止修改，回顾历史

目的： 判断之前是否定位错误，或者修改过程中引入了新问题。

如何操作： 直接要求 Agent 暂停编辑，分析历史信息。

示例 Prompt：

暂停修改代码。请回顾原始报错、此前的修改内容及每次修改后的执行结果，结合 Git Diff 分析为什么问题仍然存在。区分已经确认的事实和未经验证的猜测，判断之前的根因定位是否有误。

2. 恢复可靠的代码基线

目的： 避免在错误补丁的基础上继续修改。

如何操作： 让 Agent 检查 Git 状态，识别需要撤销的修改，确认后再恢复。

示例 Prompt：

如果确认之前的修改方向错误，请先通过 Git 检查改动，列出建议回退的文件及原因。保留原有代码和有效测试，等待我确认后再执行回退。

常见命令：

  • git diff：查看修改内容。
  • git restore 文件路径：恢复指定文件未暂存的修改。
  • Claude Code 的 /rewind：可恢复部分代码或会话状态。

注意：使用 Git 恢复代码的前提是存在可靠的版本基线，且回退前应确认不会丢失需要保留的修改。建议让 Agent 开始开发前先建立 Git 提交。

3. 重新定位根因

目的： 通过证据定位问题，避免 AI 继续猜测。

如何操作： 让 Agent 尽可能构造最小复现案例（MRE），结合日志和调用链分析。

示例 Prompt：

请重新定位原始 Bug。首先判断能否稳定复现，必要时编写最小复现测试。然后沿实际调用链检查相关代码，结合日志、数据库状态或断点结果验证根因假设。在确认根因之前不要修改业务代码。

最小复现的作用：把复杂场景中的问题简化为可重复触发的错误，从而验证根因假设。

4. 最小范围修复

目的： 只修复已经定位的问题，避免引入额外错误。

如何操作： 给出明确的修改范围和验证要求。

示例 Prompt：

根据已经确认的根因进行最小范围修复，不要重构无关代码。修改完成后，重新运行之前能够复现 Bug 的测试，确认原始问题是否解决。

5. 回归测试与代码审查

目的： 确认原始 Bug 已修复，并且没有破坏其他功能。

如何操作： 要求 Agent 执行相关测试并审查最终差异。

示例 Prompt：

请运行相关单元测试和接口测试，重点验证本次修复涉及的业务流程，以及可能受影响的原有功能。最后使用 Git Diff 审查全部修改，汇总测试结果、未验证部分及潜在风险。

6. 多次失败时管理上下文

目的： 避免大量失败尝试和错误假设持续干扰 Agent 的分析。

如何操作： 让 Agent 总结已确认的事实、失败的尝试和当前代码状态，必要时开启新的会话。

示例 Prompt：

请总结目前已经确认的错误现象、排查证据、失败的修改方案以及尚未验证的假设，不要继续修改代码。我将基于这些信息重新开始排查。

Claude Code 可以使用 /clear 清理会话上下文，必要时使用 /rewind 恢复到此前的检查点。

注意：清理会话上下文不等于恢复代码文件。如果代码已经被错误修改，仍然需要通过 Git 或检查点机制处理。

核心原则：不要让 AI 无限尝试，而是建立基于证据的“问题复现 → 根因定位 → 最小修复 → 测试验证”闭环。