让 AI 改代码时，最容易漏掉的是“怎样判断做对了”。这里用一个具体问题演示：用户连续点击两次提交按钮，服务端收到两次创建请求。以下是示范任务与验收方法，不是对某个工具的性能实测。
先判断问题在哪一层
重复记录不一定只是按钮问题。可能是前端没有禁用按钮，也可能是网络重试、服务端缺少幂等处理，或者用户在多个窗口提交。把“禁止双击”当成整个修复，会遗漏其他入口。
第一轮让 Agent 阅读提交事件、请求封装和服务端创建接口，列出可能的路径。此时先不修改代码。如果项目只包含前端，也要明确指出服务端约束无法在当前仓库验证。
准备一个可恢复的起点
先查看并保存当前工作区的修改，再记录项目启动方法和已有检查命令。如果原来的构建就失败，保留失败输出，不能让新改动替之前的问题背锅。不要为了得到绿色结果，让 Agent 删除失败测试或放宽校验。
在隔离的开发环境里，用测试账号和测试数据复现一次。记录页面、输入、点击顺序和实际结果。涉及支付、发信等外部动作时，使用项目已有的测试模式。
可以直接使用的任务书
将下列内容中的项目路径和检查命令替换为你的实际情况。没有服务端仓库时，删掉相应实现范围，但保留“说明无法验证”的要求。
目标：修复连续点击提交导致的重复创建。
现象：在测试环境的创建页面填写有效内容，快速点击两次提交，会产生两条记录。
先阅读提交处理、请求封装与创建接口，说明原因和最小修改范围。
保持现有接口、页面文案和无关业务逻辑；不要顺手升级依赖。
验收：
1. 正常提交只创建一次；请求未完成时不能重复发起同一次操作。
2. 请求失败后能重试，按钮不能永久卡住。
3. 无效输入仍使用原来的校验提示。
4. 如果涉及服务端幂等，说明幂等标识的生成、重复请求与过期行为。
执行项目已有的相关测试与构建。
交付时列出改动文件、实际执行的检查、结果和未验证项。这里的价值不在提示词措辞，而在四个能独立检查的行为。换成文件上传、预约或评论提交时，也要重新定义成功、失败和重试，不能机械套用接口规则。
审查时沿着用户动作走
| 场景 | 要观察什么 | 容易遗漏的地方 |
|---|---|---|
| 正常提交 | 页面反馈与实际创建记录一致 | 只改变按钮样式，却没有正确处理返回结果 |
| 连续点击 | 同一操作不会并行创建多次 | 按钮禁用后，键盘回车仍能触发 |
| 请求失败 | 错误可见，用户可以再次尝试 | loading 状态只在成功分支清除 |
| 响应很慢 | 状态持续合理，不会再次发送 | 超时后重试可能重复创建 |
| 输入无效 | 原有校验保留 | 修复重复提交时跳过输入校验 |
服务端是否真正幂等，需要看接口契约和测试结果。前端只发送一次请求，不能证明服务端对重复网络请求也安全。
如何识别“看似完成”
如果交付只有“已经修好”，追问三个具体对象：改了哪些文件、实际运行了哪条检查、检查输出是什么。截图只能说明某一时刻的界面；测试通过也只覆盖测试中的输入。
对于无法执行的检查，要求说明阻碍，例如数据库未启动、凭据不可用或缺少依赖。把“未运行”保留下来，比让 Agent 猜测成功更有用。
什么时候拆成两个任务
当修复同时触及按钮状态、服务端幂等和历史重复数据时，先完成新请求路径，再单独设计历史数据处理。后者需要确认哪些记录可以合并，不能让 Agent 根据相似内容自行删除。
把每次任务限制在可解释、可验证、可恢复的范围，你就能比较不同工具实际减少了多少人工工作。继续阅读编程助手选择指南，或使用先复现再修复的提示词。
参考与边界
本页的任务书和验收表是本站针对示例问题编写的方法建议。产品入口与权限行为请分别核对 OpenAI 官方入门、Claude Code 概览和 Cursor Agent 文档。不同项目的幂等实现不能仅凭本文决定。