Claude Code Safe Deploy Dry Run：申请生产权限前先验证

让 Claude Code 部署可以省时间，但没有 dry run 就给生产权限，会让每次失败都变成恢复会议。更安全的做法是先证明部署可以成功。

这篇文章建立部署 dry run：生产权限前确认 build、diff 风险、preview URL、rollback owner、触碰范围和重试条件。

相关阅读: claude-code-permissions-guide, claude-code-permission-audit-before-deploy, claude-code-cloudflare-workers. 官方文档基线: Anthropic Claude Code docs.

为什么要在第一条命令前决定

在生产权限前收集公开证据和回滚负责人

关键是不要把第一条请求写得太大。先写清阅读范围、禁止触碰的区域、第一步动作和验证命令，Claude Code 就不容易把任务扩展到无关修改。

用 Claude Code 更新 Cloudflare Pages、Workers 或静态站点的人

实际工作流程

1. 先通过本地 build
2. 检查 diff 是否涉及 secrets、支付或认证
3. 在 preview URL 检查 h1、canonical、hero 和 CTA
4. 指定 rollback owner 和命令
5. 证据完整后才申请生产权限

场景	交给 Claude Code 的工作	人工确认的证据
文章发布	部署前跑 dist build 和公开URL检查	build, diff, URL
CTA 修改	在 preview 验证 Gumroad 和咨询链接	build, diff, URL
Workers 修改	用 dry-run log，不碰环境变量	build, diff, URL

有了这些证据，Claude Code 的结果就能用可观察的工作来判断，而不是只看一段自信的总结。

可复制的提示词和代码

请把这个修改转换成生产部署前 dry run checklist。用表格返回 build 结果、diff 风险、preview URL、rollback owner、未触碰区域和重试条件。暂时不要执行生产 deploy。

const deployCheck = {
  build: "passed",
  diffReviewed: true,
  previewUrl: "https://example.pages.dev",
  rollbackOwner: "Masa",
  changedAreas: ["content", "cta-copy"]
};

function canRequestProductionAccess(check) {
  return check.build === "passed" &&
    check.diffReviewed &&
    /^https:\/\//.test(check.previewUrl) &&
    check.rollbackOwner.length > 0 &&
    !check.changedAreas.includes("secrets");
}

console.log({ ready: canRequestProductionAccess(deployCheck) });

真实例子和失败模式

场景	交给 Claude Code 的工作	人工确认的证据
文章发布	部署前跑 dist build 和公开URL检查	build, diff, URL
CTA 修改	在 preview 验证 Gumroad 和咨询链接	build, diff, URL
Workers 修改	用 dry-run log，不碰环境变量	build, diff, URL

• build 前运行 wrangler 会让失败原因不清楚。
• 没有 rollback owner 会拖慢失败后的决定。
• 跳过 preview URL 会漏掉返回 HTTP 200 的 fallback 页面。

关键是不要把第一条请求写得太大。先写清阅读范围、禁止触碰的区域、第一步动作和验证命令，Claude Code 就不容易把任务扩展到无关修改。

把证据包留下来

在生产权限前收集公开证据和回滚负责人 如果只停留在一次聊天里，价值会很快消失。更好的做法是保存成证据包：原始请求、Claude Code 阅读的文件、没有触碰的区域、执行的命令、公开URL或截图，以及仍然不确定的判断。下一次 session 就能复用同一套判断，而不是重新解释背景。

对用 Claude Code 更新 Cloudflare Pages、Workers 或静态站点的人来说，第一天不需要完整的团队制度。先在一个 PR、一条笔记或一次部署上使用这个流程。失败时，把失败原因写回 checklist，再用更小的版本重试。只有在 build、diff、URL、CTA、rollback 证据都可见之后，才扩大 Claude Code 的访问范围。证据不足时扩大权限，看似更快，实际会把验证成本留给后面的人工 review。

收入路径也遵循同样原则。读者还卡在基础命令时，免费PDF是下一步。读者每周重复同类 prompt 时，Gumroad 教材更合适。读者要做团队或生产判断时，咨询更合适。文章不是把所有人都推去购买，而是只把需要 安全部署检查和权限设计 的读者送到付费教材，其余读者回到免费PDF和相关文章。

还要留下一个判断分支。Claude Code 的建议是直接采用、缩小范围，还是先补一个验证步骤，都用一句话写下来。PR 评审可以写「没有 P0，P1 是移动端破版，P2 是测试缺口」。Obsidian 到 issue 可以写「没有使用整篇笔记，只采用 CTA 改善」。deploy dry run 可以写「preview URL 正确，但 rollback owner 未设置，所以暂不生产部署」。

有了这句话，下一次选择 CTA 也更清楚。基础命令不熟的人去免费PDF，反复做同类工作的人去 Gumroad，卡在责任边界或生产权限的人去咨询。安全部署检查和权限设计 对应的是已经可以自学、但需要带走一个稳定模板的读者。

把读者导向免费PDF、Gumroad 和咨询

如果基本命令还不稳定，先用 免费速查表 固定日常习惯。想深入 安全部署检查和权限设计，请看 Gumroad 教材。如果需要团队导入、评审规则或收入路径设计，请进入 咨询；产品比较从 products 开始。

CTA 不应该只放在文章底部。开头适合免费PDF，实作例子之后适合 Gumroad 教材，涉及团队导入或生产风险时，咨询就是自然的下一步。

发布后要看的数字

发布后观察权限类文章到 Setup Guide、/en/training 和免费PDF的流动。

不要只看 PV。要分开看正文开头阅读、内部链接、免费PDF注册、Gumroad 点击和咨询页访问。HTTP 200、h1、canonical、heroImage、CTA 和本地化正文都必须指向同一个 slug。