给 Claude Code 一份范围清楚的小改动任务

把一句需求变成验收条件

“修一下表单”可能带来远超预期的修改。开始前先写出现象、输入、期望结果和允许修改的范围。官方 Claude Code 工作流文档介绍了错误排查和测试任务；本文提供的是本站设计的任务拆解例子，不包含已运行的 Claude 测试成绩。

第一步 复现并保留基线

在自己的测试副本或开发分支工作，先确认当前未提交的改动，避免把他人的修改一起覆盖。记下复现步骤与现有测试结果。暂时无法复现时，先收集输入、错误信息和环境差别，不要直接让 Claude 根据猜测重写整个组件。

第二步 给一个明确的小目标

假设一个虚构订购表单的数量规则是 1 到 99 的整数，当前把“1a”当成 1 接受。任务可以写成：只修正数量输入的校验和相关测试，保持接口字段、样式及其他表单行为不变。先定位负责校验的函数，解释原因，再提出最小修改方案。

验收输入包括空值、0、1、99、100、1.5 和“1a”。按本例约定，只有 1 与 99 通过；空值应提示必填，其他无效输入应给清楚错误。前后空格是否允许要先约定，不要让实现者默默决定。这些是预期结果，不是执行日志。

第三步 检查差异与边界

允许修改后，检查每个变化的文件是否与任务有关。若补丁突然升级依赖、重排整仓格式或改变请求协议，应要求解释必要性，并把独立改动拆开。让 Claude 写明新增测试对应哪个行为，再运行项目已有的相关检查。测试失败时保留错误原因，不用删断言换取通过。

交付清单：原错误是否能够稳定复现并被修复；有效输入是否仍通过；错误提示是否可理解；服务端是否还有独立校验需要核对；无关文件是否未变；未执行的检查是否明确列出。前端验证不能替代后端对输入的检查。还要检查回车提交、粘贴输入和快速重复提交等操作，避免只测试理想的逐字输入。涉及工具权限时，应查看实际授权范围；一段提示词不能代替环境隔离或访问控制。

保留停止条件与回退方法

若问题需要数据库迁移、权限变更或生产配置修改，应停下重新说明范围，不能把它们藏进“小修复”。保留变更前版本和恢复步骤，但不要在未确认有价值的本地修改时执行破坏性回退。官方最佳实践强调给 Claude 可执行的验证条件；最终仍需由负责的人判断变更是否适合交付。