AMZ
用户中心
AI 与自动化

Claude Code实战：让AI帮你修复一个真实项目bug

摘要：修bug先复现再验证 关键词：Claude Code实战、AI修bug、Claude Code项目

公众号文章库2026/7/710 分钟阅读

摘要：修bug先复现再验证
关键词：Claude Code实战、AI修bug、Claude Code项目

开头：AI修bug，最怕不是慢，而是“看起来修好了”

很多人第一次用 Claude Code 修 bug，会把报错截图丢进去，然后说：帮我修一下。

这句话太危险了。

因为 AI 很容易根据错误信息给出一个“看起来合理”的修改。它可能确实改掉了当前报错，但没有复现、没有定位根因、没有跑验证，也没有确认是否引入新问题。真实项目里，猜对一次不代表流程正确，猜错一次可能让后续报表、Listing 工具、广告脚本全部跟着错。

对跨境卖家来说，bug 不是程序员才关心的事。你做的广告周报工具、Review 分析脚本、Listing 风险词检查器、公众号排版生成器，只要输出错了，最后都会变成运营决策错误。

所以这篇文章不讲“AI 会不会写代码”，只讲一个更实用的问题：怎样让 Claude Code 按工程流程修复一个真实 bug，而不是让它猜答案。

先理解：Claude Code能做什么，不能替你负责什么

Anthropic 官方把 Claude Code 定义为 agentic coding tool：它可以读取代码库、编辑文件、运行命令，并和开发工具集成。官方常见工作流里也专门列了探索代码、修 bug、重构、测试、创建 PR 等场景。

这说明 Claude Code 不只是“补全几行代码”。它更像一个能进入项目目录的协作工程师：先看文件，再提出计划，再改代码，再跑验证。

但边界也要说清楚。Claude Code 官方安全说明提到，它默认采用严格的只读权限；涉及编辑文件、运行测试、执行命令等动作时，需要用户授权。换成卖家能理解的话就是：AI 可以帮你修，但上线责任、数据安全、权限批准、业务验收仍然在你手里。

这也是我们设计修 bug 流程的底层原则。

真实场景：广告周报工具的总花费算错了

假设你有一个内部广告周报小工具。

它的功能很简单：运营每周从广告后台导出 CSV，上传到本地页面，系统自动算出 spend、sales、orders、ACOS，并按搜索词给出动作建议。

现在问题来了：后台导出的总 spend 是 1255.56 美元，但工具页面只显示 21.00 美元。

这个 bug 很典型。它不一定是复杂算法问题，可能只是金额字段处理错了：

  • 有些 spend 带美元符号，比如 $12.30；
  • 有些 spend 是普通小数，比如 8.70；
  • 有些 spend 带千分位，比如 "1,234.56"；
  • 有些行是空值或 N/A，应该按 0 处理；
  • 有些字段名可能是 Spend、spend、cost，大小写和命名不一致。

如果你直接让 AI 改，它可能只处理美元符号，却漏掉千分位。这样表面上修了一半，实际还是错。

正确做法是：先冻结一个最小样例，让 bug 可复现。

准备一个脱敏最小样例

不要把真实广告后台大表一股脑丢进去。先准备一个不会泄露店铺信息的小 CSV：

campaign,search_term,spend,sales,orders
A,wireless charger,$12.30,0,0
A,fast charger,8.70,25.99,1
B,usb c cable,"1,234.56",2600,20
C,brand defense,N/A,0,0

这个样例的预期总 spend 是：

12.30 + 8.70 + 1234.56 + 0 = 1255.56

它故意覆盖了 4 个边界：货币符号、小数、千分位、空值。你后面要求 Claude Code 修复时，就不是让它凭感觉改，而是让它对着明确的业务结果验证。

第一步：只调查，不修改

当前项目有一个 bug：上传广告 CSV 后，页面展示的总 spend 与后台导出的总 spend 不一致。

请先不要修改任何文件。
请完成：
1. 找出处理 CSV 上传、字段映射、金额解析、总 spend 计算的相关文件；
2. 用普通运营能听懂的话说明当前计算逻辑；
3. 根据代码提出 3 到 5 个可能根因，并标注证据来自哪个文件；
4. 告诉我需要哪些最小样例数据才能复现；
5. 不要编辑文件，不要运行会修改项目状态的命令。

这一步的目的，是逼 Claude Code 先建立上下文。

你要看它有没有找对文件。比如它应该去看 CSV parser、字段映射、金额解析函数、汇总函数、前端展示层，而不是只盯着报错行。

如果第一步它都找错方向，不要让它继续修改。让它重新调查。

第二步：复现问题，让错误稳定出现

接下来，把刚才的脱敏样例给它，并要求它先算预期值，再复现当前错误。

下面是最小复现 CSV：

campaign,search_term,spend,sales,orders
A,wireless charger,$12.30,0,0
A,fast charger,8.70,25.99,1
B,usb c cable,"1,234.56",2600,20
C,brand defense,N/A,0,0

请先不要改代码。
请完成：
1. 计算这个样例的预期总 spend；
2. 找到项目里最适合放这个样例的位置，建议用 sample fixture 或测试文件；
3. 运行当前代码或测试，说明实际结果是多少；
4. 如果当前项目没有测试框架，请给一个最小本地验证脚本方案，先等我确认。

这里有一个关键点：先让错误稳定出现，再谈修复。

很多 AI 修 bug 失败，是因为没有把 bug 变成可重复验证的输入输出。今天它根据这张表改对了，明天换一张表又错，这不是修复，是碰运气。

第三步：写一个失败测试，再修

请基于这个最小样例添加一个失败测试。

要求：
1. 测试名称要说明业务含义，例如 should_parse_currency_and_thousand_separator_spend；
2. 断言总 spend 应为 1255.56；
3. 测试只覆盖 spend 解析和汇总，不要顺便测试无关功能；
4. 添加测试后先运行，确认它在当前代码下失败；
5. 在我确认前不要修复实现代码。

为什么要先写失败测试？

因为测试会把“我感觉不对”变成“这个输入必须得到这个输出”。对于非程序员来说，这一步也很好理解：你不是在评估代码风格，而是在评估业务数字是否正确。

如果项目本来没有测试框架，可以退一步，让 Claude Code 写一个临时验证脚本，例如 node scripts/check-spend-sample.js 或 python scripts/check_spend_sample.py。重点不是形式，而是必须能重复跑。

第四步：只做最小修改，不借机大重构

当它定位到问题后，再要求最小修改：

请只修改 spend 解析相关逻辑，不要重构无关代码。

修改范围限制：
1. 可以修改金额解析函数；
2. 可以补充字段名兼容逻辑，但要说明兼容哪些字段；
3. 不要调整页面样式；
4. 不要改广告建议算法；
5. 不要改真实数据文件；
6. 不要删除现有测试。

修改后请运行相关测试，并给出：
- 根因；
- 修改文件；
- 修改前后差异；
- 验证命令；
- 验证结果；
- 仍需人工确认的边界。

这个约束能避免 AI 把一个小 bug 改成大重构。

很多项目被 AI 改坏，不是因为 AI 不会写代码，而是因为用户没有限制修改范围。原本只是金额解析问题，AI 顺手重构了 CSV 上传、页面状态、图表组件，最后你很难判断到底哪里变了。

修 bug 的黄金规则是：一个 bug，一组样例，一个根因，一次最小修改。

第五步：让Claude Code做“修复复盘”

修完以后，不要只看“测试通过”。让它写一份给运营和技术都能看懂的复盘。

请用下面结构总结本次 bug 修复：

1. 业务现象：运营看到的问题是什么；
2. 技术根因：代码里哪里处理错了；
3. 修改内容：具体改了哪些文件；
4. 验证方法：用什么样例和命令验证；
5. 边界覆盖：美元符号、小数、千分位、N/A 是否覆盖；
6. 仍未覆盖：还有哪些情况需要后续补测试；
7. 上线建议：是否可以合并，是否需要人工复核真实报表。

这份复盘很重要。它让 AI 的工作从“我改了”变成“我能交代清楚为什么这么改”。

团队以后遇到类似问题，也可以直接翻这份复盘，而不是重新问一遍。

非程序员怎么验收AI修的bug

AI 跑过测试不代表你可以直接上线。你还要检查：

  • 是否只改了相关文件；
  • 是否解释了根因，而不是只说“已修复”；
  • 是否有一个最小样例能稳定复现原问题；
  • 是否处理了货币符号、小数、千分位、空值这些边界；
  • 是否影响 sales、orders、ACOS 等其他字段；
  • 是否保留了脱敏样例或测试；
  • 是否给出可复制的验证命令；
  • 是否没有暴露店铺真实数据、API key、广告账户信息；
  • 是否有回滚方案，比如提交记录、备份分支或明确的修改文件清单。

这一步尤其适合非程序员。你不一定完全看懂每行代码，但你可以看懂业务结果是否正确。

你可以直接拿这段提示词验收：

请站在运营负责人角度审查这次 bug 修复。

不要继续修改文件。
请回答：
1. 这次修复解决的业务问题是什么；
2. 哪个最小样例证明它已经修复；
3. 修改是否只限制在相关文件；
4. 哪些边界已经覆盖，哪些没有覆盖；
5. 如果我明天上传真实广告报表，最应该人工核对哪 3 个数字；
6. 有没有任何权限、数据安全或上线风险。

什么时候必须停下来，不要继续让AI改

Claude Code 很适合修这类本地工具、小脚本、内部页面、数据清洗问题。但下面几类情况，不建议让 AI 自己一路改到底：

  • 涉及真实订单、库存、价格、付款、发货接口；
  • 涉及 Seller Central、广告 API、ERP、财务系统的写入操作；
  • 涉及数据库迁移、批量删除、线上部署；
  • 涉及账号申诉、合规承诺、法律风险判断；
  • Claude Code 建议运行你看不懂且可能修改系统的命令。

遇到这些情况，AI 可以调查、解释、给方案，但执行前必须找懂技术的人复核。

官方安全文档也强调，Claude Code 只有你授予的权限，用户需要审查它提出的代码和命令是否安全。卖家团队尤其要记住这一点：不要因为 AI 语气很确定，就跳过权限和上线检查。

可以沉淀成团队SOP

如果你团队开始用 Claude Code 做内部工具，可以把修 bug 固定成 8 步：

  • 第一步，脱敏业务数据；
  • 第二步，最小样例复现；
  • 第三步，只读调查；
  • 第四步，确认根因假设；
  • 第五步，写失败测试或验证脚本；
  • 第六步，最小修改；
  • 第七步，跑验证；
  • 第八步，输出复盘和上线清单。

这套 SOP 不只适用于广告周报。Review 分类脚本、Listing 风险词检查器、图片命名工具、公众号 HTML 生成器，都可以按这个流程来。

真正有价值的不是某一次“AI 帮我修好了”，而是你把一次修复变成了团队可以重复使用的工作流。

结论

用 Claude Code 修 bug，关键不是让 AI 更快动手，而是让 AI 按正确流程动手。

复现、定位、假设、失败测试、最小修改、验证、复盘，这七步跑通以后，AI 修 bug 才从“猜答案”变成“协作排查”。

对跨境卖家来说，这件事的意义不只是修一个程序问题，而是把运营经验、业务样例和工具化能力连起来。你会逐渐拥有一批可维护的小工具，而不是一堆靠运气跑出来的脚本。

参考资料