用 Claude Code 自动化发布前收益检查：别再让流量白白漏掉

那天早上打开数据分析后台，我整个人愣住了。前一天发布的文章，PV 是平时的三倍。可是免费 PDF 的注册是 0 次，教程的点击也是 0 次。说白了就是「火了一把，结果一分钱都没动」。

查下来，原因蠢得让人想笑。文章末尾那个报名按钮，链接指向的是半年前就下架的旧产品页。更糟的是，英文版文章写到一半正文就切回了英文，海外读者读到那里就直接走人了。正文其实写得挺好，偏偏在最后那几行把读者全漏光了。

从那以后，我把「写文章」和「确认能不能发布」这两件事彻底分开。后面这一步如果每次靠手动做，我一定会偷懒，所以我把它做成了固定流程交给 Claude Code。今天我把这套流程原样拿出来，全部都能直接复制使用。

本文要点

• PV 增加但报名不增加，原因多半是链接失效、旧产品页、正文还停在英文这类「发布前本来能发现的低级错误」。
• 把发布前要看的项目固定成 9 个，每次按同样顺序检查，漏掉的情况会大幅减少。
• 交给 Claude Code 的是「打开页面、机械地核对每一项」；至于哪个按钮当主角，由人来决定。
• 把报名按钮收敛到一篇文章只放一个，读者就不会犹豫，也更容易走向下一步行动。
• 把检查过的内容记成日志，事后就能追溯「当时凭什么判断可以发布」。

先定好发布前要看的 9 个项目

光说一句「好好检查一下」，人和 AI 都不会动。所谓检查，就是一份具体的项目清单。我固定下来的是下面这 9 项。

#	检查项目	看的重点
1	页面能否打开	服务器是否返回 200（而不是 404 或 500）
2	标题是否正确	页面顶部的大标题是否和文章标题一致
3	canonical 规范链接	规范链接指向的是不是这篇文章本身的 URL
4	封面图	图片能否显示（不是旧图、也不是空白）
5	正文语言	每个语言版本是否从开头就用对应语言书写
6	免费 PDF 入口	注册按钮是否存在、链接是否还活着
7	教程链接	链接指向的是不是预期的产品页（别跳到别的产品）
8	咨询页入口	链接指向的是不是咨询页
9	手机端显示	有没有出现横向滚动（有没有内容溢出）

最关键的是第 3 项和第 7 项。如果 canonical 规范链接指向了首页或别的文章，搜索引擎就会把那个页面当成「正版」来评价，这篇文章再好也得不到应有的权重。链接指错产品这种事，越是靠复制粘贴拼出来的文章越容易发生。

交给 AI 的范围，和人来决定的范围

这两块一旦混在一起就要出事，所以要把界线划清楚。

交给 Claude Code 的，是能机械判断的检查。打开页面、读取标题、获取链接的跳转目标、看图片能不能显示、用手机宽度确认布局。这些事人来做又烦又乏味，一乏味就会跳过，所以让 AI 每次都老老实实做完。

人来决定的，是需要判断的部分。这篇文章要把哪个按钮当主角？正文的措辞是否自然？有没有不小心推荐了已下架的旧产品？还有最后那个「这篇到底能不能发布」的终极判断。这部分要是甩给 AI，就会出现「链接都是活的，但内容跑偏了」的文章。

拿不准的时候，判断标准很简单：答案唯一确定的交给 AI，掺杂偏好或策略的交给人。链接是否返回 200 是唯一确定的，归 AI；三个按钮里突出哪一个属于策略，归人。

可以直接复制的指令模板

下面这段指令可以原样贴给 Claude Code。只要把仓库名和你要检查的 URL 换成自己的就行。

请对下面每一个 URL 执行发布前检查。
确认：页面能以 200 打开；大标题与文章标题一致；
canonical 规范链接指向同一篇文章；封面图能够显示；
正文用对应语言书写；免费 PDF 的注册按钮是活的；
教程链接跳转到预期的产品页；咨询页链接正确；
在手机宽度下不出现横向滚动。

对每个 URL 用一行汇报，把通过的项目和未通过的项目分开列出。
不要只因为「200 能打开」就判为通过。如果有未通过的项目，
请一并写出原因推测，以及应该修改哪个文件。

最后两句话是精髓。如果停在「200 能打开 = OK」，最常见的「链接指错产品」就会被漏掉。强制它把未通过的项目单独列出、连要改的位置都说清楚，你就能直接接着动手修。

可以直接运行的判定脚本

把「该不该发布」这个汇总判断写成代码，每次的结果就不会飘。下面是用 Node.js 跑的最小版本。

// 发布前必须全部通过的 9 项
const requiredChecks = [
  "页面以 200 打开",
  "大标题与文章标题一致",
  "canonical 指向同一篇文章",
  "封面图能够显示",
  "正文用对应语言书写",
  "免费 PDF 的注册按钮是活的",
  "教程链接指向预期产品页",
  "咨询页链接正确",
  "手机宽度下无横向滚动",
];

// passed 传入「已通过项目名」的数组
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "可以发布" : "修复后重新检查",
  };
}

// 示例：只有教程链接这一项未通过
const passed = requiredChecks.filter((c) => c !== "教程链接指向预期产品页");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "发布 OK" : "发布 NG");
console.log("未通过项目:", result.missing);
console.log("下一步行动:", result.nextAction);

运行这段脚本，会输出 发布 NG、未通过的项目名，以及下一步要做什么。只要缺一项，ok 就是 false，所以不会出现「差不多就行」糊里糊涂发布的事故。你要做的，只是用前面那段指令让 AI 检查出来的结果，去填满 passed 数组。

真正起作用的三个场景

1. 一天发好几篇的日子 一口气发三篇的日子，检查最容易变得马虎。这时我会把每篇都用手机宽度逐一打开，滚动到标题、正文开头、报名按钮附近一一看过。如果非英语版本的正文还停在英文，当场就停止发布。越是容易偷懒的日子，固定清单越值钱。

2. 只替换热门文章里的一个按钮 就算只是把一篇常被读的文章末尾按钮换掉一个，光说一句「找到相关组件帮我改好」也太宽泛了。我会先定好：哪些文件可以动、哪些文件不能碰、要验证哪些 URL、每个链接该指向哪里。光是这一步，改完之后的判断就从「感觉还行」变成了「凭这些证据可以发布」。

3. 多语言文章的质量确认 就算文章设置里的语言指定是对的，只要正文还停在英文，就不算发布质量。我会在每个语言版本里看大标题、正文开头、按钮附近，确认那个语言的读者读完后知道下一步该做什么。对中文读者来说，免费 PDF 的说明、教程的引导、咨询的入口，都得用自然的中文读起来通顺。

常见的坑和修法

坑 1：只在本地构建通过，就汇报「能发布了」 本地构建成功，并不代表线上页面会正确显示。修法是：把检查对象从「本地构建结果」换成「线上 URL 的实物」。也明确告诉 AI「打开线上 URL 来确认」。

坑 2：把所有报名按钮一股脑全排上 把免费 PDF、教程 A、教程 B、咨询用同样的大小并排放出来，读者不知道该点哪个，最后哪个都不点。修法是：每篇文章只定一个主角按钮，其余的退成低调的辅助链接。

坑 3：链接跳到别的产品上 明明写着「免费 PDF」，一点却跳到付费教程——这在复制粘贴的文章里特别高发。修法是：让 AI 务必执行第 7 项的链接跳转目标获取，连产品 ID 都人工核对一遍。

坑 4：没想好怎么回退就大改 临发布前大范围改动，一旦改坏了又没法还原，是最糟的情况。修法是：把单次作业控制在「万一不对、能先准备好回退步骤」的范围内。写不出回退方案的改动，对这一轮来说就是太大了。

常见问题

Q. PV 涨了报名却没涨，先看哪里？ A. 先看报名按钮的链接跳转目标，和正文的语言。链接还指向旧产品页、或者面向海外读者的版本没切成对应语言，这两个是最大的两个原因，对应发布前检查的第 5、6、7 项。

Q. 每次都要做这个检查吗？太麻烦了。 A. 每次都要。正因为麻烦，才别靠手动，把本文的指令交给 Claude Code 机械地做。越麻烦的检查，人在忙的日子越会跳过。偏偏跳过的那天就出事。

Q. 把按钮收敛到一个，是不是就少了通往其他产品的入口？ A. 比起入口数量，读者能不能毫不犹豫地点下那一个更重要。并排太多反而选不出来、直接走人。定一个主角，辅助链接在正文里自然地放 1 到 2 个，就是刚好的平衡。

Q. canonical 规范链接为什么那么重要？ A. 搜索引擎会把被指定为 canonical 的页面当成「正版」来评价。如果这里指向了别的文章或首页，得到评价的就不是你写的这篇，搜索排名也会聚到那个页面上去。

Q. 检查日志留着是为了什么？ A. 为了事后追溯「当时凭什么判断可以发布」。一旦出问题，就更容易切分出是正文、按钮、链接还是咨询入口出了岔子。没留日志的话，下次运营就得从零重新查一遍。

把检查过的内容记在一张纸上

发布后留一段简短的备忘，下次检查会一下子轻松很多。下面这种形式就够用了。

- 文章: claude-code-revenue-smoke-test
- 发布日: 2026-06-14
- 检查到的证据: 线上 URL, 大标题, canonical, 封面图, 正文语言, 按钮跳转目标
- 主角按钮: 教程链接（面向能自走的读者）
- 接下来看的数字: PV, PDF 注册, 教程点击, 咨询页跳转

看数字的时候，也别只用 PV 下结论。把免费 PDF 的注册、教程的点击、咨询页的跳转按同一个日期并排放。再跟假设对照：偏初学者的文章应该是 PDF 注册涨，处理设置或权限的文章应该是教程点击涨。养成这个习惯，每天的发布就从「只是发出去」变成了「一点点修好转化路径的机制」。

这套「机械的检查交给机器、需要判断的交给人」的划界思路，在收益检查之外也通用。非工程师如何用 Claude Code 的整体图景，我整理在了非工程师如何使用 Claude Code；让每天的活儿更快的小技巧，整理在Claude Code 提效小技巧。要让 AI 正确地帮你检查，指令的精度很关键，所以配合Claude Code 提示词实战技巧一起读会更有效。

另外，让 AI 读文件、检查链接这类处理背后的机制，可以在官方的 Claude Docs 里确认。一旦感觉行为变了，先去看一手资料，往往才是最快的路。

我实际试下来的结果

这套流程在我自己的站点上跑了大约两周。我想验证的是：「发布前的 9 项检查，到底能不能真的减少漏掉。」

结果，那些只看「页面能以 200 打开」时会直接放行的问题，被揪出来好几处。具体来说：把别篇文章的封面图直接拿来就准备发布的有 2 篇；报名按钮链接指向旧产品的有 1 篇；英文版正文写到一半还停在日文的有 1 篇。这些要是只看「200 能打开」，全都会算通过。

特别管用的，是把报名按钮收敛到一篇一个的做法。我把原先免费 PDF、教程、咨询用同样分量并排的文章，重新整理成只突出一个主角，结果按钮的点击率肉眼可见地涨了。「读者选项越少越愿意行动」这件事，我是用数字实打实感受到的。

反过来也搞明白一件事：这种检查靠手动是坚持不下去的。最开始几天我是手动做的，结果一忙就轻松地跳过了。直到把它做成指令加脚本、每次都按同一套流程跑，才终于固定下来。

把发布前这些不起眼的检查做成机制——这就是把 PV 变成收益最便宜的一份保险。如果你想把它嵌进公司的博客运营或团队的发布流程，我可以在研修・咨询里，结合你们实际的运营一起设计这套流程。