先说这件事本身
把一座写了四年、积累了 120 多篇文章的博客，从内容架构到运营方式全部重新组装一遍，需要多大的团队？
我今年上半年给出了自己的答案：一个人，带一队分工明确的 Agent。 人负责判断和方向，Agent 负责几乎全部执行。新版就是你现在看到的 cubxxw.com ——它不只是一次改版，而是把"博客"这个东西从一个静态网站，改造成了一个会自己写日报、自己提修复建议、自己对外提供接口的系统。
首页右侧那个线框球体不是装饰，是我的数字分身：访客可以直接问它"我该从哪篇读起"“GEO 是什么”，它背后接的是全站内容索引。暗色模式下是另一种气质：
这篇文章是整个重组过程的完整复盘。不是"AI 真厉害"的感叹文——而是把每一层怎么搭、我和 AI 怎么说话、哪些环节我放权、哪些环节我绝不放权，全部摊开讲一遍。如果你也维护着一个内容站点、一个知识库，或者任何"一个人忙不过来"的系统，这套方法应该可以直接抄。
一、重组之前，先回答"博客到底是什么"
四年前我理解的博客是"一个放文章的网站"。这次重组前我想明白了一件事：博客不是源头，它只是我内容流水线最下游的一个出口。
于是整个仓库里长出了一个不会被 Hugo 发布、却统领一切的目录——writing-pipeline/：
0-inbox/ 收集箱 → 零摩擦捕获灵感，绝不整理
1-notes/ 原子笔记 → 每条自包含、可互链
2-master/ 母版(SSOT) → 一次写完的完整版，平台无关 ★真相源★
3-adapters/ 适配器 → AI 指令模板，把母版派生成各平台版本
4-published/ 发布追踪 → 哪篇发到哪、表现如何，反哺选题
数据只朝一个方向流：碎片 → 原子笔记 → 母版 → 各平台。母版是唯一真相源，博客版、小红书版、海外平台版、视频脚本，全部由适配器从母版派生。改内容只改母版——这是整条流水线唯一要守的纪律，否则各平台版本各自漂移，母版就名存实亡。
适配器本质上是给 AI 的指令文件，每个平台一份，封装那个平台的算法机制和人群心理。对我来说发布动作变成了一句话：“读 2-master/ 这篇，按 3-adapters/xiaohongshu.md 的规则生成小红书版本。“深度让位于共鸣、干货压缩成清单、配图脚本一并生成——这些平台适配的脏活，全部固化在适配器里，不再依赖我每次的临场发挥。
想清楚这一层，后面所有 AI 分工才有了挂靠点：AI 不是"帮我写文章”，而是在一条明确的流水线上，各自认领一段工序。
二、我和 AI 怎么说话：几个被反复验证的询问模式
重组期间我和 Claude、Codex 的对话量非常大。大到一定程度后，有效的问法会自己沉淀出来。这几个模式我现在每天都在用：
1. 给任务，不给方向。 这是我所有模式里最重要的一条，重要到我单独写过一篇《给 AI 任务，别给方向》 。区别只在一个词：完成态。“帮我优化一下首页"是方向，没有终点，能聊到天荒地老；“把首页 LCP 降到 2.5s 以内，只许动图片加载策略，改完给我 Lighthouse 前后对比"是任务，做没做完一眼可验。重组这么大的工程，全部是被切成一个个带完成态的任务喂下去的。
2. 方案先过对抗评审，再执行。 AI 最危险的输出不是报错，是一段流畅、自信、方向却歪了的话。所以凡是牵涉架构的方案——内容目录怎么分、重定向怎么配、noindex 的阈值定多少——我都让第二个 AI 扮演最挑剔的评审：“列出这个方案最可能失败的三个理由。“这道门禁便宜得几乎免费，却拦下过好几次"看起来很对"的错误。展开版在《给你的 AI 工作流装上质量门禁》 。
3. 每搭一个模块，问一句"这里出问题，我怎么知道？” 这是运维思维搬进个人系统。AI 的 bug 不红屏、不抛异常，它安静地给你一个错误的结果。所以我要求每个自动化环节都必须有报警出口——后面你会看到，整套 SEO 自动化的产出物不是"改好的代码”，而是一份每天弹到我面前的日报 issue。系统的目标不只是能跑，是出了问题会喊我。
4. 用白名单圈权限，不要用形容词。 对 AI 说"别乱改东西"毫无意义，它对"乱"的定义和你不一样。有效的做法是给一份明确的允许清单：这几个文件可以动，其余不许碰；这几个命令可以跑，其余全部拒绝。这个模式后来直接产品化进了我的自动化流水线——AI 修复工单里有一个 scope_hint 字段，就是那次任务的文件白名单。
5. 要求 AI 交代依据和不确定处。 产出里必须带"这个结论基于什么、哪一步我最没把握”。相当于强制它给自己的输出打日志，我验收时先看日志再看结论。
这五条合起来其实是一句话：方向、标准、边界是我的；执行是 AI 的。 分工线画清楚，协作才会越用越快，而不是越聊越散。
三、Skills：把踩过的坑固化成手艺
对话模式解决"一次怎么问好”，但真正的杠杆在于让好的问法可以复用。这就是 skills 在我系统里的角色：.claude/skills/ 下的每一个技能，都是一段被验证过的工序说明书，AI 每次执行都照着走，不再依赖我重新描述。
现在这个仓库里长驻的技能有六个：article-covers（封面生成）、apple-design 与 emil-design-eng（设计审美与实现规范）、animation-vocabulary、review-animations、improve-animations（动效的词汇表、评审标准与改进流程），外加一个 /check-posts 命令——发布前的文章质检清单，front matter 时区、未来时间、标签规范、双语完整性，逐项过。
拿最有代表性的 article-covers 拆开讲，因为它同时回答了"图片怎么生成"这个问题。
封面工厂：两段式图片生成
博客一百多篇文章都需要封面（没有封面的文章，分享到微信、X、小红书时的预览图全长一个样）。我的方案是一条脚本流水线 scripts/generate-covers.mjs，底层接了两个图像模型：豆包 Seedream（默认，国内直连，约两毛钱一张）和 Gemini（备选）。
但真正值钱的不是脚本，是流程被强制拆成了两段：
- 第一段：读文章、想画面——交给擅长阅读的模型（或者我自己）。 产出一到两句具体的、可画的场景描述：“清晨的书房里，几条细流从不同的窗口淌到一张长木桌上，汇进一只敞开的木匣；匣子另一侧，沉淀出的卵石被码成一条向右延伸的小径。”
- 第二段：画——图像模型只收到这句场景，别的什么都不给。
为什么要这么切？因为两类失败我都真金白银踩过：
- 凡是具体的东西，图像模型会照抄着画出来。 有一次把文章标签一起喂了进去，生成的封面上赫然印着拼错的 “AI Inteligenct”、“Agetic”、“monitzring”；还有一次把站点配色的十六进制色号写进提示词，它直接画了一张带色号文字的色卡。每一次脚本都报告成功、退出码为 0、测试全绿——只有眼睛能发现这种错。
- 凡是抽象的东西，图像模型会退回它的刻板印象。 让它"读懂文章画个贴合的画面”，得到的永远是发光的电路板和蓝色渐变隧道。
所以分工必须是：理解交给读得懂的，绘制交给画得出的，两边中间只传一句人话。 再配几条不可谈判的规则：全站统一一行风格锚点（扁平杂志编辑插画、低饱和不超过四色、大面积留白），图里不出现人脸、logo 和任何文字，中英文版本共用同一张图。生成后必须打开看一眼再决定用不用——这是整条流水线里唯一无法自动化的环节，也不该自动化。
这套东西第一次跑通花了我一个晚上，之后每篇新文章的封面成本是：一句场景描述加两毛钱。这就是 skill 的意义——学费只交一次。
四、MCP：给博客长出接口
重组里我最喜欢的一步，是给博客写了一个自己的 MCP server（scripts/mcp-server.mjs，零依赖，一个文件）。它暴露两个工具：search_blog 和 get_blog_post——任何支持 MCP 的客户端（Claude、Cursor、ChatGPT 桌面版）配置一行，就能直接检索和读取我的全部文章。
有意思的地方在于它的实现：这个 MCP server 和站内 AI 问答、首页那个数字分身，共用同一份内容索引（content-index.json）。也就是说"让 AI 理解我的博客"这件事只做了一次，然后被三个出口复用——站内问答、数字分身、外部 MCP。写一篇新文章，跑一遍索引脚本，三个出口同时更新。这是我理解的 close the loop：不是每个功能各拉一条管道，而是一条管道开三个龙头。
日常写作和维护时，我自己这端挂的 MCP 工具也各有分工：Playwright MCP 负责浏览器——本文里所有截图就是它拍的；Context7 负责查框架文档的最新版本，治 AI 拿三年前 API 一本正经写代码的病；GitHub MCP 负责 issue 和 PR 的往返。工具不在多，在于每个都有明确的岗位。
顺带一提排版。新版文章页是三栏：左栏是元数据（作者、成熟度、篇幅、参与贡献），中栏正文，右栏目录——目录旁边还有一个 AI 标签页，读者可以针对当前这篇文章直接提问：
五、Claude 与 Codex 的工程化用法
这次重组我同时用 Claude Code 和 Codex（仓库里 CLAUDE.md 和 AGENTS.md 并存，各自还挂了自己的配置目录）。用得越深，越确认一个判断：这类工具的上限不取决于模型，取决于你给它铺的结构。几条实打实的经验：
把"版本敏感的坑"写进 CLAUDE.md，而不是写教程。 我的 CLAUDE.md 里最有价值的内容长这样：“编译不要用 make，用 netlify dev”；“SVG 必须放 static/，放 assets/ 会 404”；“不要把大段 SVG 内联进 Markdown，Goldmark 见到行首零宽空格会把它拆碎”。每一条背后都是一次真实的翻车。AI 不需要你教它 Hugo 是什么，它需要知道这个仓库里哪些地方和它的先验不一样。
结构即约束。 配置文档一度越写越长，AI 反而越来越不听话——后来把它拆了：CLAUDE.md 只留仓库级的硬规则，手艺全部下沉到单一职责的 skills，一事一个目录。文件变多了，每个文件变小了，AI 的执行准确率肉眼可见地上升。目录结构本身就是给 AI 的地图；地图画得乱，它走得就乱。
权限渐进放行。 settings.local.json 里的允许清单是一条一条攒出来的：先手批，重复出现的操作才进白名单。现在 git add/commit/push、gh pr 都是免批的，但危险半径大的命令永远单独确认。信任是攒出来的，不是一次性授予的。
过夜任务用 Ralph 循环。 对于"一句话说不清、但可以拆成一串用户故事"的大活，我用一个很糙但很有效的脚本 ralph.sh：把需求写成 prd.json 里的一组 user story，脚本循环启动 Claude，每轮只做一个 story——实现、跑质检、commit、把学到的模式追加进 progress.txt，全部通过后自己开 PR。progress.txt 是精髓：每轮 Agent 把"这个仓库的坑"写下来留给下一轮，相当于给一支健忘的队伍配了一本值班交接簿。为什么每轮只做一个 story？因为长链条任务的成功率是乘出来的——单步 95% 的把握，二十步连乘就只剩三分之一。把链条切短，把状态外置，是对抗复合误差最朴素的办法。
六、自动化运营：GitHub Actions 里的 AI 值班员
重组后最大的变化不是站点长什么样，而是它开始自己运营自己。整套循环长这样：
每日定时 每日定时
┌──────────────┐ 数据 ┌──────────────┐ 日报 ┌─────────────────┐
│ seo-snapshot │ ────────▶ │ seo-analyze │ ───────▶ │ 站点日报 issue │
│ 抓 GSC/PSI/ │ data/seo/ │ (AI 读快照) │ │ + Lighthouse 段 │
│ CrUX 快照 │ └──────────────┘ └────────┬────────┘
└──────────────┘ │ 我点名一条建议
▼
┌──────────────┐ PR ┌─────────────────┐
│ seo-fix │ ──────▶ │ 我 review/merge │
│ (AI 开分支) │ └─────────────────┘
└──────────────┘
每天下午，一个跑在 GitHub Actions 里的 Claude 会读当天和前一天的 Search Console、PageSpeed、CrUX 快照，对比出关键变化——哪个页面性能掉了五分以上、哪些查询词排在 8 到 20 名是便宜的标题改写机会、哪些页面曝光不少但点击率异常——然后把观察写进当天的《站点日报》issue。Lighthouse 的巡检结果也汇入同一张 issue，一天一张，绝不刷屏。
我觉得某条建议值得做，就手动触发 seo-fix，把那条建议的原文和文件白名单传进去。AI 开一个分支、只改白名单内的文件、跑一遍完整构建确认不破站、开一个 PR，并回到日报 issue 里留一句"处理建议 X → PR #NN"，留下完整的纸面轨迹。
这套流水线的权限设计比功能设计花了我更多心思：分析任务的 token 权限是只读的，提示词里再叮嘱一遍不许碰源码——belt and suspenders；工具白名单精确到单条命令；连"写 issue"都不许 AI 直接调 gh，必须走一个幂等的脚本，防止它自作主张开新 issue。发布侧的推送（sitemap ping、IndexNow、百度推送）也全部由 Actions 在部署后自动完成。
唯一不自动的环节是 merge。 这不是技术做不到，是刻意保留的。AI 可以观察、可以建议、可以准备好一切，但"这个改动要不要进主干"的签字权在我。关于怎么才能放心把活交给没人盯着的 Agent，我在这篇 里写得更细。
七、GEO：让 AI 引用你，而不只是 Google 收录你
重组的最后一块拼图是 GEO——生成式引擎优化。当越来越多的人从 AI 那里直接拿答案，内容的可见性就不再由点击率决定，而是由"被 AI 引用的概率"决定。我为此写了一个完整的六篇专栏 ，而这个博客本身就是专栏方法论的试验田：
落到这次重组里的实操，捡几件说：robots 明确欢迎 GPTBot、ClaudeBot、PerplexityBot 们来抓；站点根下放了 llms.txt；每篇文章的 front matter 都带结构化的 tldr 字段——AI 摘答案时最喜欢这种段落级可提取的结论；四类 JSON-LD 结构化数据补齐。更疼的一刀是砍索引：博客攒了四年的标签页里，七成标签底下只有一篇文章，这些薄页占掉了 sitemap 的一大半——统一 noindex 并踢出 sitemap 之后，提交给搜索引擎的 URL 几乎砍半，把抓取预算还给正文。还有域名迁移（nsddd.top → cubxxw.com）这种一步走错前功尽弃的事：301 保路径、新旧资源并存监控、旧域重定向至少保 180 天。
这套东西的完整方法论在专栏里，我自己站点的真实数据复盘（87 万曝光为什么只换来 852 次点击、虚荣指标怎么祛魅）单独写在改造复盘篇 。这里只留一句最重要的：技术满分只是入场券，真正决定被不被引用的，是结构、证据和背书。
另外，重组后的内容组织也是为"被引用"服务的：成组的长文全部挂进专栏系统，AI（和人）都能沿着一条线索读到底：
八、没做完的部分
诚实的复盘必须包含这一节。
英文版落后于中文版——适配器能派生初稿，但我还没建立稳定的英文润校节奏。封面积压——两段式工厂跑得动，但"每张都要人眼看过"这条红线让批量补旧文封面变成了慢工程，我接受这个速度。收录还在爬坡——新域名的索引率仍然难看，域名迁移的权重转移需要以月计的耐心，GEO 的站外背书（L5）基本还没动。自动化的半径也止步于"建议到 PR"——我试过想象全自动 merge 的样子，然后每次都在同一个问题上停下：出了错，谁发现？在这个问题有可靠答案之前，签字权不外放。
这些坑留在这里，既是备忘，也是下一轮迭代的 backlog。
九、常见问题（FAQ）
Q：这套流水线迁移到别的博客系统（非 Hugo）能用吗？ A：能。母版流水线、询问模式、两段式封面、AI 值班员、GEO 清单都不依赖 Hugo。只有具体脚本（索引生成、front matter 解析）需要按你的系统重写——这正是适合丢给 AI 的带完成态任务。
Q：整套系统的月成本大概多少？ A：大头是 Claude 的订阅和 API 用量；封面按张计费约两毛一张；GitHub Actions 在免费额度内；Netlify 免费档够用。对一个个人站点，总成本大致是"一顿饭钱"的量级——但前提是你自己的时间投入换来了杠杆，而不是又多了一堆需要你照看的玩具。
Q：为什么不让 AI 直接写文章、全自动发布？ A：因为我试过让 AI 全自动追信息、写内容，它的能力边界我在这篇 里拆过：采集、整理、派生它都行，但"值不值得写、观点是什么、对不对得起署名"是判断，判断外包出去，博客就没有存在的理由了。AI 组装这座博客，但住在里面的得是我。
Q：从零开始抄这套系统，第一步做什么？ A：不是装工具，是把你重复做的事拆成带完成态的任务清单。先手动跑通一遍，再把跑通的流程写成 skill 或脚本，最后才谈自动化。顺序反了，你只会得到一堆更快地产出错误的机器。
十、重组的不是博客
最后想说的是：这次重组表面上交付了一个新网站，实际上交付的是我处理信息方式的一次升级。
四年前，写博客的瓶颈是"写"本身——排版、封面、发布、SEO，每一样都在消耗写作的心力。现在，这些全部变成了流水线上的固定工序：Agent 各守一段，出问题会报警，改进有纸面轨迹。我只剩下一件事没法外包，也不想外包——决定写什么，和为写下的东西负责。
信息不值钱，值钱的是处理信息的能力。而处理信息的能力，在 2026 年具体长这样：一条想清楚的流水线，一队圈好边界的 Agent，一套攒出来的信任，和一个始终握着签字权的人。
新版博客在 cubxxw.com 。欢迎来逛，也欢迎直接问首页那只数字分身——它比我更清楚该推荐你从哪篇读起。
延伸阅读：方法论总纲《Agent Engineering 全景地图》 ｜《超级个体的情报系统》 ｜《怎么才能放心把活交给一个没人盯着的 AI Agent》 ｜GEO 完整方法见 GEO 专栏 。
读者回响