AI 写的代码出问题了：如何调试和验收 MVP

先把问题重现出来#

记录出错前做了什么、原本期待什么、实际看到了什么。找一份最小的可复现输入，避免每次测试都换一篇文章。

例如，点击提交后按钮一直显示“处理中”，但结果没有出现。先刷新页面，用同一份输入再试。如果第二次正常，就记录两次请求的时间和标识，继续排查差异；不能直接把问题标为已经修复。

1
环境：本地开发，浏览器及版本，项目运行时版本。
2
触发步骤：打开输入页，粘贴测试文章，点击生成。
3
预期结果：结束等待状态，显示结果或失败提示。
4
实际结果：请求结束后，按钮仍处于等待状态。
5
请求标识：如果服务端返回了 requestId，附上它。
6
相关信息：脱敏后的报错、状态码及最近的相关修改。

日志只保留定位问题需要的内容。发送给 AI 前去掉密钥、用户身份信息和无关原文，测试输入尽量使用可公开的样例。

沿着请求走一遍#

打开浏览器开发者工具，先看 Console 和 Network。再到运行服务端的终端或平台日志里，按时间、请求标识找对应记录。

这些是排查入口，不能单凭状态码定根因。比如 403 可能来自自己的访问控制，也可能来自上游供应商；要结合响应和服务端记录确认。

如果接口已经返回格式错误提示，而按钮没有结束等待，问题可能在页面的失败分支。此时让 AI 重写模型调用，通常改不到出错的地方。

让 AI 先解释，再做小范围修改#

带着证据给 AI 一个明确任务：

1
提交后接口返回了 OUTPUT_INVALID，但按钮仍显示“处理中”。
2
以下是复现步骤、脱敏响应和相关报错。
3

4
先检查请求结束时的页面状态，说明根因和拟修改位置。
5
本次只修复等待状态无法结束的问题。
6
保留接口约定和已有页面布局，不更换依赖或重写整个组件。
7
修复后检查成功、失败和超时三条路径。

修改后查看差异，确认每一处都能对应到问题。还要留意 AI 有没有删除输入限制、关闭类型检查，或把真实调用换成模拟结果。这些改动即使让当前报错消失，也没有满足原来的要求。

对于稳定复现的错误，优先留下一个能失败的回归检查，修复后再运行它。测试暂时不容易自动化时，也可以先用固定操作步骤验证，记下实际结果。

测用户得到的行为#

自动化测试应当关注约定：空输入会被拒绝，错误响应会结束等待，有效结果能展示。组件叫不叫某个名字、内部有没有使用某种写法，通常不是用户需要的行为。

以输入长度为例，SPEC 定义有效范围为 100 至 12000 个 Unicode 码点，可以覆盖边界附近的输入：

1
99 个码点：拒绝。
2
100 个码点：允许进入处理。
3
12000 个码点：允许进入处理。
4
12001 个码点：拒绝。
5
只有空白：拒绝。
6
包含补充平面字符：前后端按约定得到相同计数。

这里保留边界值有实际意义。只测一篇普通文章，发现不了大于号写成大于等于号，也发现不了前后端计数方式不一致。

我会用两个问题检查 AI 生成的测试：如果代码换一种写法但行为没变，测试是否仍然成立？反过来，故意让输入校验失效，测试能不能发现？

分别检查程序和生成内容#

模型功能的验收至少有两部分。程序检查负责发现接口、状态和数据结构问题；内容检查负责判断结果是否符合原文。

对于一篇包含价格和使用条件的文章，人工对照标题、摘要和标签，检查数字有没有改、限定条件有没有漏、标题有没有额外承诺。把原文与错误结果保存为获准使用的测试样例，后续更换提示词或模型时再次比较。

模型输出可能变化，不适合把整段摘要逐字一致作为通用通过条件。字段类型、必需信息和不允许出现的错误可以稳定检查，文字质量则需要按具体任务评价。

发布前跑一次完整任务#

局部测试通过后，从页面入口走一遍主流程。测试材料和条件保持固定，检查用户能否在没有口头帮助的情况下完成任务。

1
[ ] 输入规则在提交前能看到，前后端校验一致。
2
[ ] 一份有效输入经过真实处理，结果可以复制使用。
3
[ ] 无效输入不触发模型调用。
4
[ ] 超时、额度不足和格式错误有提示，原输入得到保留。
5
[ ] 失败后能再次提交，旧结果不会被当成新结果。
6
[ ] 重复点击不会从同一页面发出多次提交。
7
[ ] 手机上能输入、查看结果和复制，长文本没有遮挡控件。
8
[ ] 关键回归检查和项目现有检查实际通过。

发现遗漏，就补一条能覆盖它的检查。每次修复不必把所有可能场景都重新检查，但涉及公共接口、状态或模型提示词时，要重新覆盖受影响的路径。

记录结果时写清范围，例如“本地浏览器主流程通过，线上尚未验证”。部署后还要重做哪些检查，也就有了依据。