CCClaude Code中文喂饭教程

实战：发布前检查

发布前检查要比提交前检查更严格，要让 CC 逐项确认环境、配置、数据、回滚、监控和未验证风险，避免带病上线。

检查模板

发布前检查比提交前检查更严格。提交前只看这次代码能不能进 Git；发布前要看上线后会不会影响真实用户、真实数据、真实配置。

请做发布前检查，但不要执行发布。

要求：
1. 回顾本次改动范围。
2. 检查是否有配置、环境变量、数据库或权限变更。
3. 检查测试、构建、Lint、类型检查是否完成。
4. 检查是否有回滚方案。
5. 检查是否需要人工验收或截图。
6. 输出发布风险清单。

发布前信息清单

让 CC 做发布检查前，先提供这些信息：

请只做发布前风险评估，不要执行发布。

发布内容：
【列出本次要发布的改动】

已完成检查：
【构建 / 测试 / Lint / 类型检查 / /verify / /code-review】

可能风险：
【数据库 / 配置 / 权限 / 支付 / 登录 / 性能 / UI】

请输出：
1. 发布阻塞项。
2. 发布前必须人工确认项。
3. 建议发布步骤。
4. 回滚方案。
5. 监控和验收方式。

必须人工确认

这些事项不能只靠 CC 判断。CC 可以帮忙列清单、查代码、整理风险，但最终确认必须来自负责人、环境管理员或业务方。

发布前阻塞项

看到这些情况，不建议发布：

阻塞项不要靠感觉判断。可以让 CC 把每个阻塞项写成“风险 + 证据 + 负责人”：

请把发布阻塞项整理成表格。

字段：
阻塞项
证据
影响范围
需要谁确认
解除条件

没有解除条件的阻塞项，很容易变成“大家都知道有风险，但没人处理”。

发布风险分级

可以按这张表让 CC 分类：

类型示例处理方式
阻塞发布构建失败、核心测试失败、无回滚暂缓
发布前确认配置、域名、灰度、迁移人人工确认后再发
发布后观察日志、性能、错误率、用户反馈发布后盯监控
可记录风险非核心历史问题记录，不混入本次发布

让 CC 生成发布决策

请生成发布决策建议。

请按三类输出：
1. 可以发布：
   - 条件是什么。
2. 暂缓发布：
   - 阻塞项是什么。
3. 需要人工确认：
   - 谁或什么角色确认。

最后给出你的建议：发布 / 暂缓 / 需要更多信息。

回滚方案要写清楚

请生成回滚方案。

要求：
1. 如果代码发布失败，怎么回滚。
2. 如果数据库迁移失败，怎么处理。
3. 如果配置错误，怎么恢复。
4. 哪些改动不能简单回滚。
5. 回滚后如何验证用户流程恢复正常。

灰度和分批发布

请判断本次是否需要灰度或分批发布。

请考虑：
1. 是否影响核心流程。
2. 是否涉及数据库或配置。
3. 是否可以按用户、区域、比例或环境分批。
4. 每一批观察什么指标。
5. 什么时候扩大或回滚。

发布后验收

请生成发布后验收清单。

请按优先级列出：
1. 需要立刻检查的核心页面或接口。
2. 需要观察的日志和监控。
3. 需要人工确认的业务流程。
4. 如果发现异常，第一时间该收集什么信息。
5. 是否需要通知团队或用户。

发布后异常怎么处理

发布后发现异常，请先不要盲目继续发布。

请帮我整理：
1. 异常现象。
2. 影响范围。
3. 是否和本次发布相关。
4. 需要立刻回滚还是先收集信息。
5. 回滚前需要确认什么。
6. 应该通知哪些角色。

CC 不能替你确认什么

这些事项可以让 CC 帮忙列问题，但必须由对应角色确认。发布前最危险的不是“不知道”，而是把“没有证据”当成“没问题”。

发布复盘

请生成发布复盘记录。

请包含：
1. 本次发布内容。
2. 发布前检查结果。
3. 发布后验收结果。
4. 是否出现异常。
5. 需要沉淀到 CLAUDE.md、Skill 或发布清单的经验。

发布清单怎么持续变好

每次发布后，都可以问 CC：

请根据这次发布过程，判断发布前检查清单是否需要更新。

请输出：
1. 哪些检查项应该保留。
2. 哪些检查项没有价值。
3. 这次暴露了哪些新风险。
4. 哪些内容适合沉淀到 CLAUDE.md。
5. 哪些内容适合做成发布模板。

发布清单应该随着项目演进，不是一份永远不变的表。

验收结果

下一篇：交接总结