让 AI 写代码前，先写一张能验收的改动单
从一张改动单开始：用四句话把需求讲明白，让每次交付都有证据。
“给订单页加个搜索”是个很自然的开头，却很难验收。按订单号还是商品名？是在当前页里筛，还是搜历史订单？如果没有结果，页面该显示什么？这些问题留到代码写完再答，往往意味着重做接口、测试和界面。
交给编码助手的任务
给 Codex 一份两页订单数据和两个权限不同的测试账号。要求先用文件名说明分页在哪一层、查询使用哪条权限条件，再实现。交付时只接受真实命令与输出，并让它记录哪些路径没有在真实环境验证。
拿一个小店的后台举例。客服每天拿着订单号查记录，翻页很慢。先把这个动作写清楚，搜索框要放哪里，反而可以晚一点决定。
写一张能验收的改动单
目的：客服拿到完整订单号后，能直接找到对应订单。
范围：只改后台订单列表，沿用现有访问权限。
验收：第二页的已知订单也能找到；找不到时显示空状态；
清除搜索后恢复原列表。
证据：给出测试命令、运行结果，以及涉及的文件。这里最有用的是「第二页的已知订单」。如果测试数据只有一页，筛当前页和搜全部订单都可能通过。准备两页数据，把目标放在第二页，才有办法区分这两种实现。权限也要覆盖：用原本看不到那条订单的账号搜同一号码，预期仍然查不到。
先看路径，再决定改哪里
让助手先找出三处：列表请求在哪发出、分页和权限在哪处理、已有测试从哪里进入。拿到文件名后，可以追问一句：「如果只改前端，为什么还能搜到第二页？」回答如果依赖浏览器已经拥有全量数据，就检查这个前提。仓库里真正存在的数据流，比一份写得漂亮的实现计划更有用。
小改动可以让助手一次做到测试通过。碰到访问权限或跨服务调用时，先停在方案这一层，把影响范围说清楚，再让它改。
验收时，至少亲眼看一次失败
准备一条正常路径和一条边界路径。能重放的话，让新加的用例先在旧实现上失败，再在新实现上通过。这样能排除一种常见误会：测试是绿的，但根本没有测到这次改动。
收尾只要三样东西：改了哪里、跑了什么、还有什么没验证。最后一项写具体，例如「没接到真实订单库；只用两页测试数据验证」。下一次排障，这句话可能比整段改动总结更有用。
先准备一个对照样例
用 ORD-204 做目标，第一页只放 ORD-001 等其他订单。给助手的验收表只需要「操作者、动作、预期订单编号」三列。管理员和受限账号输入同一编号，结果不同，这一行比多写半页实现建议更能划定需求。
用这些结果验收
- 目标订单故意放在第二页。
- 受限账号搜索同一编号应为空。
- 清空关键词恢复原列表和产品约定的分页状态。
审查时容易漏掉什么
验收样例应能区分两种错误实现：只筛当前页、跨权限搜全库。把这两种错误都变成断言后，再讨论输入框样式。这样即使换一个助手接手，也能用同一批样例判断是否完成。
还应给这项改动一个「不改什么」的清单，例如列表外观、订单详情地址和导出权限。做完后用差异检查助手是否扩展到了未授权入口。若工作量必须扩大，先用当前实现的数据流解释阻碍，再决定要不要改任务单。
