完成不等于代码已经生成
可靠交付需要同时满足功能、测试、范围和可审查性。Claude Code 可以帮助执行这些步骤，但你仍需要检查验证信号是否与任务目标一致。
建立验证顺序
先运行最接近改动的检查，再逐步扩大范围：
# 目标测试或目标脚本
npm test -- path/to/changed.test.ts
# 类型和静态检查
npm run typecheck
npm run lint
# 完整测试和生产构建
npm test
npm run build
项目命令应以仓库实际配置为准，写入 CLAUDE.md，不要让代理每次猜测使用 npm、pnpm、yarn、make 还是其他工具。
让失败保持可观察
如果验证失败，不要只把最后一行发给 Claude。保留执行命令、完整错误、运行目录和退出状态：
命令：npm run build
工作目录：仓库根目录
期望：完成静态生成
实际：content validation 在 tutorial slug 校验阶段失败
请先解释错误来自内容格式、文件路径还是代码逻辑，再决定修改位置。
这样可以避免代理修复错误的层级，例如为了绕过一条无效内容而关闭整个校验。
审查 Git 差异
提交前至少检查：
git status --short
git diff --check
git diff
重点查看：
- 是否修改了任务范围外的文件。
- 是否出现密钥、日志、构建产物或本地路径。
- 新增错误分支是否有测试。
- 命令、版本和文档链接是否真实。
- 大量格式化是否掩盖了行为变化。
可以让另一个干净会话或独立审查步骤只看 diff 和验收条件。审查者应报告影响正确性的缺口，不要为了“必须找到问题”而制造无意义重构。
按模块提交
一个提交应该对应一个可以解释和回滚的模块：
git add src/lib/content tests/content
git commit -m "内容（fix）：修复教程章节关联校验"
如果同一任务同时包含内容模型、页面布局和教程文章，拆成多个提交会让审查和回滚更清晰。
发布前检查清单
- 目标功能可以通过真实用户路径完成。
- 相关测试、类型检查和构建通过。
- Git diff 与需求范围一致。
- 新增文档可以被读者执行，不依赖隐藏环境。
- 外部链接、安全边界和失败状态已经检查。
- 未完成项被明确记录，没有用静态按钮或虚假数据伪装完成。
下一步
完成这套课程后，可以选择一个真实但风险较低的任务，例如新增一个列表筛选、修复一个可复现错误，或者补充一篇 Markdown 教程。坚持使用同一反馈循环，直到你能根据测试证据而不是输出语气判断工作是否完成。