Claude Code 实战 10｜端到端：用 Agent 搭一条博客自动化发布流水线原创

# Claude Code 实战 10｜端到端：用 Agent 搭一条博客自动化发布流水线

前九篇讲的是单点能力：CLI 心智、活文档、驾驭工具、Git、会话、护栏、MCP、编排、远程。这一篇把它们串起来，做一个完整的端到端案例——你现在读的这个系列，就是这条流水线生产出来的。从"一堆对话记录"到"公网上一个返回 200 的页面"，中间有采集、脱敏、扫描、构建、部署、验证六道关口。每一道都可能让 Agent 翻车，也每一道都能交给 Agent 自己看守。

# 1. 场景：一条把"素材"变成"公网页面"的流水线

写技术博客最耗人的从来不是"写"，是写之前和写之后的那一堆杂活：素材从哪来、敏感信息怎么擦干净、构建环境和本地不一致怎么办、推上去到底有没有生效。把这些杂活拆开，是一条清晰的单向流水线：

对话素材库 ──▶ 采集+摘要 ──▶ 起草文章 ──▶ 脱敏 ──▶ 泄漏扫描(✅ CLEAN)
                                                        │
                                              pre_push_check 构建预检
                                                        │
                                            git push master ──▶ Cloudflare Pages 构建
                                                        │
                                          轮询新 permalink 到 200 ──▶ 上线完成

1
2
3
4
5
6
7

关键的设计原则只有一条：每一步都有一个可执行的"闸门"，闸门不过就不许往下走。Agent 擅长把命令跑顺，但也擅长"看起来跑顺了"就往前冲。流水线的价值就是把"感觉没问题"换成"扫描器打印 ✅ CLEAN"这种硬判据。

# 2. 上游：素材采集与"读库不用登机器"

素材来自一个长期运行的对话库——三个 Agent 的会话实时流进自建数据库，标了 exportable = true 的会话才可导出。采集脚本（collect_from_convdb.py）做三件事：拉取可导出会话 → 脱敏 → 用小模型摘要成一篇博客可读的笔记。

这里有一个演进过的坑值得记：早期采集要 SSH 到存库的机器上跑，既慢又把凭证暴露在会话环境里。现在改成纯 HTTPS + 一个只读 Token（AGENT_CONV_READ_TOKEN，放在 profile 的 .env），脚本直接读两个只读视图。好处是本地后端也能跑，权限被 Token 卡死在"只读"这一层——Agent 拿不到写权限，就不可能在采集阶段污染源库。这条经验可以推广：给 Agent 接数据源时，宁可多配一个窄权限的只读凭证，也别把管理级 Key 递给它。

# 3. 核心闸门：脱敏与泄漏扫描是两个脚本，不是一个

整条流水线最不能省的一步，是发布前把敏感信息擦干净。这里刻意做成两个互相独立的脚本，职责分离：

redact.py 是改写器：把命中的 Stripe/AWS/GitHub Token、私钥块、密码字段、内网 IP、真实邮箱等，就地替换成 <PLACEHOLDER> 占位符。
scan_leaks.py 是只读验证器：只报告、不改写，按严重级打标（CRITICAL / HIGH / MEDIUM / LOW），并用退出码驱动闸门。

判据非常硬：只有扫描器打印 ✅ CLEAN（0 个 CRITICAL + 0 个 HIGH）才允许发布。为什么要分成两个脚本？因为"改写"和"验收"必须是两双眼睛。如果同一个脚本既擦又验，它擦漏的东西自己也验不出来。让验证器成为更严格的一方（比如把邮箱、内网 IP、真实品牌名都判成 HIGH），才能兜住改写器的疏忽。

规则本身是一份可扩展的正则目录，分三档：

CRITICAL：直接是 Key/身份——各家云和平台的 Token、私钥块、身份证号；命中即"永不发布"。
HIGH：密码、PII、内网信息——手机号、JWT、Bearer、user:pass@host、RFC1918 私网段、各种 PASSWORD= 字段。
MEDIUM：环境指纹——公网 IP、内网域名、真实用户名、内部品牌代号；逐条人工复核。

新增一类泄漏时的规矩是：同时改两个脚本，再更新规则表。只在改写器里加规则、不给验证器加，等于闸门形同虚设。

# 4. 下游：构建预检与部署验证

素材干净了，剩下的是"把它安全地送上线"。这个博客用 VuePress 构建、Cloudflare Pages 在 push 到 master 后自动构建部署——不是 GitHub Actions。这带来一个经典陷阱：构建环境（Node 22）比本地开发环境更严格，本地 npm run dev 绿的，云端可能红。

为此有一个秒级的构建预检脚本 pre_push_check.sh，专门在推之前把已知的严格性差异挡下来。它是被两次真实翻车逼出来的：

教训一·sitemap/host 必须是绝对 URL：新版 generate-robotstxt 拒绝相对路径 "/sitemap.xml"，本地旧 Node 却接受。修法是写全 https://.../sitemap.xml。
教训二·修配置要 lint 整个文件，不是只改那一个字段：字段改绝对后构建仍然失败，因为插件用了遗留的裸字符串写法（'robots', {…} 会被现代 VuePress 误注册到顶层），必须数组包裹成 ['robots', {…}]。

从这两次事故里提炼出一条能复用到任何配置改动的规则：修配置 bug 时，lint 整份配置，而不是只 lint 你的 diff；同一个插件绝不声明两次。

预检过了才 push。而部署验证的关键认知是：Cloudflare 构建失败在 Git 侧是"静默"的——老站点继续挂着，你不主动查根本不知道新内容没上去。所以最后一道闸门是主动轮询刚发布的 permalink 直到返回 200：

curl -sI https://www.ranisa.cn/pages/claude-code-blog-pipeline/ | head -1   # 期望 200

不轮询到 200，就不算"发布完成"。

# 5. 踩坑：流水线的坑，都在"步骤之间"

单个步骤本身都不难，真正的坑几乎全在步骤衔接处：

坑一·"跑完了"不等于"过了"：Agent 最容易在脱敏后直接 push，跳过 scan_leaks.py。防线是把"扫描器打印 ✅ CLEAN"设成硬前置条件——笔记本身已经脱敏过，但成稿必须再扫一遍，因为起草时你可能又粘进了新的真实值。
坑二·本地绿 ≠ 云端绿：本地 Node 版本和 Cloudflare 的 Node 22 不一致，是最隐蔽的失败源。pre_push_check.sh 只能挡已知差异；拿不准就用与云端同版本的 Node 真跑一次 npm run build。
坑三·静默失败：构建挂了老站还在，页面看起来"没变"其实是"没更新"。永远以 permalink 返回 200 为终点，别以 git push 成功为终点。
坑四·顺手改配置：.vuepress/config/plugins.js 目前有一个已知的重复 sitemap 声明，构建今天是绿的但预检会 WARN。规矩是——不要在写文章的提交里顺手改 VuePress 配置；配置修复必须是一个单独的、本地构建验证过的提交。混在内容提交里，一旦构建挂了你都分不清是内容问题还是配置问题。

# 6. 可复用要点

流水线 = 一串带闸门的单向步骤：采集 → 脱敏 → 扫描 → 预检 → 部署 → 验证，每一步都有可执行的硬判据，闸门不过不许往下走。
脱敏用两个脚本：改写器（redact.py）和只读验证器（scan_leaks.py）职责分离，让验证器当更严格的一方；只有 ✅ CLEAN 才放行，新增规则两个脚本一起改。
给 Agent 接数据源用窄权限只读凭证：只读 Token 把 Agent 卡在"读"这一层，从架构上杜绝它污染源库。
构建预检挡住环境差异：本地宽松、云端（Node 22）严格；pre_push_check.sh 秒级挡下已知的严格性差异，修配置要 lint 整份文件、插件用数组形式、绝不重复声明。
以 200 为终点，不以 push 为终点：Cloudflare 构建失败是静默的，老站会顶着，必须主动轮询新 permalink 到 200 才算上线。

# 7. Agent 可直接解析的元数据块

{
  "_meta": {
    "doc_version": "2026-07-28",
    "article_id": "claude-code-10-blog-pipeline",
    "profile_context": "blog",
    "estimated_setup_time": "60min"
  },
  "pipeline": {
    "step_1_collect": "从只读 API + 窄权限 Token 拉取 exportable 会话，脱敏后用小模型摘要成博客笔记；不 SSH 上机器",
    "step_2_draft": "按 6 段式结构起草文章，成稿必须重新脱敏（笔记虽已脱敏，起草可能又粘进真实值）",
    "step_3_redact_scan": "redact.py 改写占位符 → scan_leaks.py 只读验证，必须打印 ✅ CLEAN（0 CRITICAL + 0 HIGH）才放行",
    "step_4_precheck": "pre_push_check.sh 秒级挡下 Cloudflare Node 22 的严格性差异（绝对 URL、插件数组形式、无重复声明）",
    "step_5_deploy_verify": "git push master → Cloudflare Pages 自动构建 → 轮询新 permalink 到 200 才算完成"
  },
  "safety_rules": [
    "脱敏用两个独立脚本：改写器 redact.py + 只读验证器 scan_leaks.py，验证器当更严格的一方，只有 ✅ CLEAN 才发布",
    "新增泄漏规则必须同时改 redact.py 和 scan_leaks.py，再更新规则表，否则闸门形同虚设",
    "给 Agent 接数据源用窄权限只读 Token，从架构上杜绝它污染或写坏源库",
    "以 permalink 返回 200 为发布终点，不以 git push 成功为终点——Cloudflare 构建失败在 Git 侧是静默的",
    "不要在写文章的提交里顺手改 VuePress 配置；配置修复必须是单独的、本地构建验证过的提交"
  ],
  "verification": {
    "check_1": "成稿 push 前必跑 scan_leaks.py，看到 ✅ CLEAN（0 CRITICAL + 0 HIGH）才允许下一步",
    "check_2": "改 .vuepress/ 后用与云端同版本 Node 跑 npm run build，或至少 pre_push_check.sh --strict；修配置 lint 整份文件不是只 lint diff",
    "check_3": "push 后 curl -sI <permalink> | head -1 轮询到 200；非 200 说明构建静默失败，老站还顶着"
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

AI Agent 使用指南：

当用户说"帮我把这批素材整理成一篇文章发出去" → 按 pipeline 六步走，逐个闸门过，别跳步。
当用户说"发布前要注意什么脱敏" → 按 safety_rules，两个脚本改写+验证分离，只有 ✅ CLEAN 放行。
当用户说"本地构建是好的怎么线上挂了" → 按 verification.check_2，用云端同版本 Node 复现，lint 整份配置。
当用户说"我 push 了但页面没变" → 按 verification.check_3，构建可能静默失败，轮询 permalink 到 200 为准。
当用户说"顺手把配置也改了吧" → 按 safety_rules，配置修复单独成提交，别混进内容提交。

上一篇：Claude Code 实战 09｜远程与浏览器：让 Agent 伸手到别人的主机和网页里下一篇：Claude Code 实战 11｜Agent 当"运维值班员"：多云资产 / DBA / 监控巡检复盘

#Claude Code #AI Agent #自动化流水线 #脱敏 #CI/CD

上次更新: 7/29/2026

← Claude Code 实战 09｜远程与浏览器：让 Agent 伸手到别人的主机和网页里 Claude Code 实战 11｜Agent 当"运维值班员"：多云资产 / DBA / 监控巡检复盘→