第十章：自动化与例行任务：把重复工作交给 Claude Code

10.1 先定原则：自动化不是“放手不管”，而是“标准化交付”

适合自动化的任务通常具备这些特征：

• 重复发生（每天/每周/每次 PR）
• 验收标准稳定（有固定命令/固定输出）
• 风险可控（不触达生产数据、不改高风险配置）

不适合自动化的任务：

• 涉及密钥、权限、生产数据但没有明确边界
• 没有测试与门禁，靠人工“看起来没问题”

10.2 典型自动化清单（收益最高）

• PR 预审：找风险点、找缺测试、找命名风格问题
• CI 失败分析：定位失败原因、给出最小修复建议
• 依赖巡检：识别过期依赖、建议升级路径
• 代码健康检查：重复代码、过长函数、缺少边界处理

Claude Code 也支持把一些任务做成“按计划运行”的形式（以官方文档为准）。
参考：https://code.claude.com/docs/en/overview

10.3 PR 预审模板（可直接复制）

请作为严格 reviewer 做 PR 预审：
目标：找出会导致线上问题的风险点。

约束：
- 不要建议大规模重构，只给最小修复建议
- 重点关注：边界条件、错误处理、性能回退、兼容性

验收：
1) 列出 Top 5 风险点（按严重程度排序）
2) 每个风险点给出“为什么”和“最小修复方式”
3) 指出哪些地方应该补测试（给出测试用例名称建议）

10.4 CI 失败分析模板（可直接复制）

当 CI 失败时，你可以把失败日志（脱敏后）给 Claude：

目标：分析这次 CI 失败的根因并给出最小修复方案。
约束：不要改无关模块；不要新增依赖。
验收：
1) 根因定位到文件/函数/配置项
2) 给出最小修复 diff 思路
3) 给出本地复现命令与验证命令

10.5 把“标准流程”固化为模板

最能提升团队效率的不是某一次自动化，而是把流程固化：

• 每次修 bug 都按“复现→定位→修复→验证→/diff”走
• 每次发 PR 都按“预审→补测试→验证”走
• 每次依赖升级都按“升级→验证→回滚预案”走

第 11 章会给一个团队模板，帮助你把这些写成“可复用规则”。

10.6 本章小结

你已经能把 Claude Code 用在高收益的自动化任务上：

• PR 预审、CI 失败分析、依赖巡检
• 用固定模板把输出标准化
• 自动化也要有边界与验收，不做“放手不管”

下一章我们进入团队落地：如何把经验写成规则与模板，让新同学也能稳定产出。