让 Claude Code 上线前先做一次「空跑」检查的完整流程

那是个周五傍晚，我对 Claude Code 说「把这篇文章的修改发到生产环境吧」。它回了一句「已发布」，外加一个绿色的对勾。我放心地下班回家，第二天早上一打开网站，首页一片空白。

原因其实很蠢：根本没人打开过预览页。Claude Code 只看了构建通过的日志，就判断「成功」了。但实际页面加载的是另一篇文章的模板，内容是空的。因为 HTTP 返回的是 200，从机器的角度看，这就是「发布成功」。

那一刻我才真正意识到，快和安全是两码事。把整个部署丢给它，看上去一瞬间就完成了。但如果没有留下「到底确认了什么」的记录，一旦摔倒，你根本不知道该把哪一步退回去。今天就来写写对策：在交出生产权限之前，怎么用一次「空跑（dry run）」把证据先备齐。

本文要点

• Claude Code 部署翻车，多数不是因为它不够聪明，而是跳过了「碰生产之前的确认」。
• 交出生产权限前，要空跑确认五件事：构建、差异、预览 URL、回滚负责人、以及没被动过的范围。
• 把「机器能判定的检查」和「人要亲眼看的判断」分开，半夜的事故会少很多。
• 文末给了可以直接复制的提示词模板，还有一段把确认结果交给机器判定的代码。
• 不需要一上来就建立完美的流程。先拿一处修改试一遍，每摔一次就往清单里补一条。

部署事故不是「不够聪明」，而是「确认不够」

Claude Code 很聪明。但聪明和能在生产环境里安全干活，是两回事。

这就像一个考试满分的学生，第一次打工却把收银机搞坏了——问题不在能力，而在脚下的「脚手架」。放到部署上，脚手架指的就是「碰生产之前，到底要确认什么」。

尤其是静态站点的部署，失败是悄悄发生的。构建通过、HTTP 返回 200，表面上一切都妥了。可哪怕内容是空的、哪怕页面被换成了别的，只盯着状态码你是看不出来的。所以要确认的不是「代码跑没跑通」，而是「正确的页面有没有正确地呈现」——这一步必须让人亲眼看一遍。

碰生产之前的五步空跑

我现在用的流程就这么几步。顺序很重要，所以我从上往下排好了。

1. 先在本地把构建跑通。 这一步就挂了的话，谈生产还早。先把「是代码的问题还是环境的问题」在碰生产之前分清楚。
2. 读一遍差异。 用眼睛确认有没有混进机密信息（API 密钥、令牌）或者跟计费相关的改动。
3. 打开预览 URL。 标题（h1）、规范链接（canonical）、报名按钮的跳转地址，是不是和预期一致——在真实页面上确认一遍。
4. 定好回滚负责人和回滚方式。 出事时由谁、用哪条命令退回上一个状态。这件事不提前定好，事故一发生人就僵住了。
5. 证据齐了，再去申请生产权限。 只有第 1 到第 4 步都有了结果，才让 Claude Code 执行生产部署。

光是守住这个顺序，开头那种「首页一片空白」的事故基本就不会再发生。因为第 3 步一定会逼你打开预览。

交给 AI 的范围，和人来判断的范围

既不是把所有事都丢给 AI，也不是全退回手工。要分工。下面这张表，是我在自己实际工作里画的那条线。

场景	交给 Claude Code 的事	人要亲眼看的证据
文章发布	先自动跑 dist 构建和公开 URL 检查	构建结果、差异、URL
报名按钮的改动	把跳转地址和咨询入口在预览里对一遍	构建结果、差异、URL
Workers 的修改	不碰环境变量，只输出空跑日志	构建结果、差异、URL

要点是：读取、罗列、机器检查这类活儿交给 AI，对生产做不可逆改动的操作由人来批准。 删除、写入生产数据库、计费、force push，一开始全部倒向「先问人」。只有那些被确认安全的操作，之后再升级成自动。

想把权限边界划得更细的话，Claude Code 权限设置指南和部署前的权限审计可以参考。

可以直接复制的提示词模板

不要把任务整个甩出去，关键是明确写上「先别发到生产」。下面这个模板可以直接粘贴使用。

请把这次改动转换成上线前的「空跑检查清单」。
请用表格返回以下项目：
- 构建结果（成功 / 失败及日志要点）
- 差异的风险（是否包含机密信息、计费、删除）
- 预览 URL
- 回滚负责人和回滚命令
- 没有动过的范围
- 重试的条件
暂时不要执行生产部署。请等我确认完检查清单再继续。

最后两行最管用。写上「暂时别执行」「等我确认完再继续」，就能避免 Claude Code「自作主张」帮你提前发布的事故。这种用提示词把行为倒向安全一侧的写法，我在进阶提示词设计里也整理过。

可以直接跑的验证脚本

把确认结果交给机器判定，而不是凭「感觉」，能少很多漏看。下面这段脚本接收空跑的结果对象，返回一个布尔值，告诉你现在是不是可以去申请生产权限了。只要装了 Node.js 就能直接跑。

// 空跑的结果，把实际确认到的内容填进来
const deployCheck = {
  build: "passed",              // 本地构建是否通过
  diffReviewed: true,           // 是否用眼睛看过差异
  previewUrl: "https://example.pages.dev", // 预览 URL
  rollbackOwner: "Masa",        // 回滚负责人
  changedAreas: ["content", "cta-copy"],   // 动过的范围
};

// 判断是否可以去申请生产权限的「门卫」
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // 构建通过了
    check.diffReviewed &&                // 看过差异了
    /^https:\/\//.test(check.previewUrl) && // 预览 URL 以 https 开头且存在
    check.rollbackOwner.length > 0 &&    // 回滚负责人定好了
    !check.changedAreas.includes("secrets") // 没动过机密范围
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// 在把 ready 为 false 的项目补齐之前，不去申请生产部署

这段代码的价值在于：只要 changedAreas 里出现 "secrets"，它立刻返回 false。在不小心碰了机密信息的状态下，绝不会推进到「申请生产权限」那一步。哪怕人忙得漏看了，门卫也会替你拦下来。

真正起作用的三个场景

第一个是文章发布。 只说一句「把博客发出去」的话，构建一通过就会一路冲到发布。插入空跑之后，会先打开公开 URL 看标题和内容对不对得上，开头那种白屏事故就被挡住了。

第二个是报名按钮的替换。 跳转地址只要打错一个字，辛苦做的转化入口就掉进 404。加入「在预览里真正点一下按钮、确认跳转去向」这一步之后，断链就归零了。

第三个是 Cloudflare Workers 的修改。 这里只要删掉一个环境变量，生产就挂了。所以空跑时不让它碰环境变量，只让它输出日志。Workers 的特有注意点，我在Cloudflare Workers 集成那篇里也整理过。

常见的坑和修正方法

下面是我自己真踩过的三个坑，以及怎么修。

坑 1：还没构建就先敲生产命令。 一上来就跑 wrangler deploy，失败时根本分不清是代码的锅还是环境的锅。修法很简单：先在本地把构建跑通。只是把顺序换一下，排查原因就快了一大截。

坑 2：没定回滚负责人。 失败之后才开始商量「谁来回滚？」，这几分钟里访问量就直接砸过来了。修法是在空跑阶段就把回滚负责人和回滚命令用文字写下来。哪怕只是把 previousDeployId 记一下，恢复时也会从容很多。

坑 3：不打开预览，只信状态码。 HTTP 200 只代表「服务器返回了点什么」，不代表「正确的页面出来了」。修法是预览 URL 一定要在浏览器里打开一次，用眼睛看标题、规范链接和主视觉图。这是看穿开头那种白屏的唯一办法。

把证据留成「下次还能用的笔记」

空跑里确认过的东西，别当场扔掉，随手整理成一小段笔记，下一次干活会快很多。

要留的就这些，足够了：最初发出的那条请求、Claude Code 读过的范围、没有碰的范围、执行过的确认命令、公开 URL 或截图、以及当时拿不准的判断点。不需要长篇会议纪要。事后能追溯「为什么当时这么判断」，目的就达到了。

特别管用的，是把「判断的分岔口」用一行写下来。比如写成「预览 URL 没问题，但回滚负责人还没定，所以暂时不上生产」。下次再做同样的活儿，不管是你自己还是别人，都能复现同一套确认。部署之外的自动化也是同一个思路，配合写给非工程师的 Claude Code 入门一起读，你会更容易找到「该怎么把活儿交出去」的感觉。

常见问题

问：空跑说到底不就是多了一道麻烦吗？ 一开始确实会这么觉得。但事故一旦发生，光是恢复和查原因就能耗掉好几个小时。空跑只要几分钟，我把它当成划得来的保险，一直坚持着。

问：本地构建过了，预览可以不看吗？ 不行。构建通过，模板被换、页面变空照样会发生。HTTP 200 和「正确的页面」是两码事，目视这一步省不掉。

问：就我自己一个人，定回滚负责人还有意义吗？ 有。哪怕只有一个人，提前用文字写下「失败就用这条命令退回去」，真出事时也不会慌。光是「定下来」这件事本身，就成了流程。

问：Claude Code 说「已发布」，可以信吗？ 别看它怎么回，看空跑的证据。用构建、差异、预览、回滚负责人有没有齐来判断。话是氛围，证据才是事实。

问：小站点也要做到这一步吗？ 别按规模想，按「能不能退回去」想。再小，生产挂了也是麻烦。先只加「打开预览」这一步，你就能感受到效果。

实际试下来的结果

开头那次白屏事故之后，我把这套空跑流程装进了自己的博客运维里。

我确认了三点。第一，把「预览 URL 必开」定成规矩之后，模板被换导致的空页面归零了。第二，让上面那段验证脚本在发布前跑一遍之后，碰过机密范围的改动会卡在 ready: false，根本推不到申请生产权限那一步。第三，每次都把回滚负责人和回滚命令记下来之后，哪怕遇到惊出一身冷汗的场面，也能在几分钟内退回上一个状态。

与其把一切丢给聪明的 AI 然后祈祷，不如先搭好「摔了也不会受伤」的脚手架。看着像绕远路，但在我看来，这反而才是最快的路。先从「打开预览」这一步开始，给自己的部署加上一个门卫吧。

如果想在团队里把生产部署的边界和评审机制都整理出来，可以在培训与咨询里一起把它流程化。官方的运维基准也建议参考Anthropic 官方 Claude Code 文档。