使用四阶段工作流
官方最佳实践反复强调：给 Claude 一个可以验证工作的反馈信号，并在复杂任务中先探索、再计划、再编码。可以把日常开发固定为四个阶段：理解、计划、实现、验证。
阶段一：理解现状
处理错误时，不要只提供一句“测试失败了”。给出完整命令、错误信息、复现条件和期望结果：
运行 `npm test` 时，content service 的分页测试失败。
请先复现并说明：
1. 失败断言是什么；
2. 输入数据经过哪些函数；
3. 最可能的根因有哪些。
暂时不要修改代码。
对于陌生代码，可以先询问入口、数据流、边界和现有测试。探索阶段的产出应该是事实和不确定项，而不是立即生成补丁。
阶段二：形成计划
复杂修改进入计划阶段，要求 Claude Code列出文件、步骤和验收方法：
根据刚才的根因分析制定最小修复计划。
计划中请写明：
- 需要修改的文件；
- 先增加什么失败测试；
- 为什么不会影响其他分页调用；
- 完成后运行哪些命令。
如果计划包含与问题无关的重构，先缩小范围。稳定的计划应该能在一次提交中解释清楚，而不是顺便“清理整个模块”。
阶段三：小步实现
让 Claude Code一次解决一个明确问题：
按计划先增加能够复现问题的测试，运行并确认它因预期原因失败。
然后进行最小修复，再运行同一测试。
不要修改公共 API，除非测试证明现有接口无法表达正确行为。
重构同样应该小步进行。每次只改变一种结构，并保持行为测试通过。大范围机械迁移可以分批执行，每批都检查差异和测试。
阶段四：验证结果
要求 Claude Code展示证据，而不是只回复“已经完成”：
请运行相关单测、完整类型检查和生产构建。
然后检查 git diff，列出：
1. 实际修改的行为；
2. 新增或调整的测试；
3. 尚未覆盖的风险；
4. 每条验证命令的退出结果。
对于前端任务，验证可以是浏览器断言、截图对比或无横向溢出检查；对于 API，验证可以是请求脚本和响应断言；对于性能问题，应记录修复前后的测量结果。
三类常用任务模板
修复问题
复现 → 缩小范围 → 写失败测试 → 最小修复 → 回归验证。
不要在无法复现时猜测并直接修改。
新增功能
先确认用户流程和边界条件，再实现最小纵向切片。
每个切片包含真实数据、错误状态和自动化测试。
重构代码
保持外部行为不变。先补充行为测试，再分步移动或抽取代码。
每一步运行目标测试，最后运行完整检查。
控制会话上下文
不相关任务之间使用 /clear。如果同一问题连续纠正多次，重新整理已经确认的事实，用干净会话重新开始，往往比在混乱上下文中继续补充说明更可靠。