从问题描述到可审查的提交

01先建立问题基线

给出真实触发方式、预期行为和实际结果。让 Claude 先定位对应代码并复现，再讨论修改方案。没有稳定复现时，先补观测信息。

02围绕行为实施修改

把任务切成可独立验收的范围。解释为什么改变这个行为，让实现有明确目标；同时避免顺手重写不相关模块。

修复登录失败后按钮一直禁用的问题。
先复现错误响应路径并解释原因。
复用现有组件和错误处理方式。
完成后验证重试成功与再次失败两种情况，
报告修改文件、验证结果和剩余限制。

03交付前检查四件事

把审查建立在实际变更和运行证据上。以下几项检查完成后，再决定是否可以提交。

• 最终 diff 是否只包含本次任务需要的修改。
• 关键边界：空值、重复操作、失败响应和取消。
• 实际运行或相关测试是否证明用户行为已改善。
• 提交说明是否能让不了解对话的人理解目的和验证。

04让经验回到项目里

如果同一种错误反复出现，把约定放入 CLAUDE.md，把重复步骤封装为 Skill，把可自动判断的回归加入现有测试。让下一次任务从更清晰的基线开始。

05一个有价值的回归用例

测试应证明原来的故障不再出现。例如“登录请求返回 401 后按钮可再次点击”，覆盖的是用户可观察到的行为；只检查某个内部变量被赋值，会过度绑定实现细节。

已有测试能可靠覆盖时优先复用。视觉、布局和复杂交互还需要运行真实页面检查，测试通过与用户体验正常是互相补充的证据。

• 先确认用例在旧实现上会失败。
• 让断言描述用户行为或稳定接口。
• 在修复后运行相关用例，必要时追加手动验证。