用 8 个 Agent Skill 搭一条博客编辑流水线：实现拆解与我的看法

前两天我们手动做了一件事：读一篇公众号文章 → 写一篇分析博文 → 提交到仓库。回头看，这其实就是一条被「人肉驱动」的流水线。

今天读到 brickverse 的一篇实战文《我如何用 8 個 Agent Skill 打造 Blog 編輯流水線》（2026-02-12），作者把同样的流程做成了 8 个 Agent Skill + 1 个桥接 Skill，打一条 /blog-intake 指令就自动跑完。这篇文章我读完觉得「骨架很值得抄」，所以写一篇拆解 + 我的看法，顺带想想我们自己的博客能怎么用。

原文：https://brickverse.com.tw/blog/agent-skill-pipeline

一句话总结

作者用 Claude Code 写博客，厌了每次重复粘贴同一套 prompt（拟大纲、查术语、润色、SEO……），于是把流程固化成 8 个各司其职的 Skill，再用一个「桥接 Skill」/blog-intake 把整条流水线串起来：从对话里收素材 → 依次跑 8 步编辑 → 写进博客后台数据库。核心不是「8 个」这个数字，而是把隐性工作流显式化、专业化分工这一招。

它到底用了哪些 Skill，各自干什么

流水線收斂为 8 个编辑角色，每个负责一个独立环节：

外加一个桥接 Skill /blog-intake：从当前对话里抓取文章素材、自动依次启动上面 8 步、跑完把成品以「草稿」写进博客后台（Insforge）数据库。

这 8 个不是一次设计出来的，是 v1.0 只有 3 个（大纲、编辑、SEO），然后一步步因为「实际用起来有痛点」长出来的：加了小白审查员（编辑只改字不检查读者能不能懂）、AI 引用优化师（2026 年流量有很大一块来自 Grok/ChatGPT/Perplexity 这类 AI 搜索）、视觉顾问（作者总忘记配图）、互动设计师（结尾不能只有「希望对你有帮助」）。

它是怎么实现的：三个关键点

1. 为什么不直接写一个大 Skill

作者一开始确实只有一个超长的 blog-writer.md，把所有指令塞一起，结果撞上三个问题，这三点我觉得讲得特别到位：

• Context Window 溢出：一个 Skill 塞 3000 字指令，AI 读规则就吃掉一大块记忆，跑到后面步骤已经忘了前面的约束（比如「中英文间加空格」到第 5 段就丢了）。
• 角色冲突：让同一个角色既「审查术语有没有解释清楚」又「精简冗长句子」，它会两头摇摆——审查员想多解释，编辑想精简，写在一起就打架。
• 无法中途介入：一口气做完，大纲方向错了后面全白做，只能砍掉重来。

拆成多个小 Skill 后，每个有独立职责、独立记忆空间、可单独执行——本质是「专业分工」，和现实里编辑管文字、SEO 管关键词是一个道理。

2. 模型分级：该省省，该花花

每个 Skill 的 model 字段可以单独指定模型。作者的策略很朴素但很少人用：

需要「从零创造」的用 Opus，需要「检查改善」的用 Sonnet。

• 大纲架构师（从零建结构，要创意和全局思考）→ Opus
• AI 引用优化师（设计结构化表达）→ Opus
• 其余 6 个（润色、SEO、审查、视觉、互动、踩坑）→ Sonnet

如果 8 步全用 Opus，一篇文章成本会非常可观。按任务性质分模型，是在质量和成本间拿平衡。

3. 桥接 Skill 才是真正的「编排层」

/blog-intake 分成三阶段：

这解决的是「手动逐个呼叫很灵活，但每次都要先从聊天记录里手动整理素材」这个痛点。桥接 Skill 把「非结构化的对话 → 结构化的素材包 → 自动化流水线 → 落库」一气呵成。

另外作者还把 Skill 管理也自动化了：分类信息不写死在前端代码，而是放进 SKILL.md 的 frontmatter（category 字段），API 动态读取自动分组。他的原话点题——「让信息住在离它最近的地方」。

对我们来说，能怎么用

我们自己的博客是静态内容仓库（blog/ai/*.mdx + git 提交），没有 Insforge 后台。但流水线的思路完全能照搬，而且——刚才那次「读文 → 写博 → 提交」就是一条人肉版流水线，正好可以固化：

1. 先固化一个桥接 Skill：输入一个文章链接 + 分析角度，自动产出符合我们 frontmatter 约定的 .mdx（title/date/tags/description 都有），最后 git commit。这不就是今天上午我们手动做的事吗？把它变成一条指令，以后省掉每次重新教 AI。
2. 不必照搬 8 个，先拆核心 4-5 个：对我们这种「读文写分析」的场景，最有价值的是 大纲/收斂、小白審查（术语有没有解释）、專業編輯（用语统一、排版）、入庫（写 mdx + 提交）。SEO/AI 引用/互动设计看你是否在意流量，可后加。
3. 模型分级直接复用：写作类 Skill 用强模型，审查/润色类用中等模型，成本立刻下来。
4. 分类用 frontmatter 管：如果你以后 Skill 多了，早点上 category 字段，别像作者一开始那样硬写死在前端。

我的几点看法

读完整篇，我比较认同的部分，和不完全认同的部分，分开说。

认可的地方：

• 「拆分」本身比「8 个」更重要。 这篇文章真正值钱的不是那 8 个具体角色，而是「把重复 prompt 变成 Skill、再按职责拆小」这个方法论。它适用于任何高频 AI 工作流——代码审查、文档生成、测试自动化都一样。
• 角色冲突那个洞察很真实。 我自己在写长文时也常遇到：让同一个 prompt 又「严谨补充」又「简洁有力」，结果输出在两种语气间反复横跳。拆成两个角色后，质量肉眼可见地稳。
• 桥接 Skill 是精髓。 大多数人想到 Skill 是「单个任务」，但作者用 /blog-intake 做了「编排层」——收素材 + 串流程 + 落库。这一步才是从「工具」到「流水线」的质变。
• 模型分级是被严重低估的杠杆。 很多人一个模型跑到底，要么贵要么糙。按「创造 vs 检查」分模型，是几乎零成本的质量/成本优化。

想泼点冷水的地方：

• 8 个对「个人博客」可能过度设计了。 作者后来 Skill 总数涨到 18 个（含部署、代码质量等）。对个人写作者，AI 引用优化师、互动设计师这两个的边际收益未必覆盖维护成本。我的建议是：先跑通 3 个核心（大纲、编辑、入库），痛了再加，别提前抽象。
• 「写进 Insforge 数据库」这一步对我们不成立。 我们是静态仓库，所以这步要替换成「生成 mdx + git commit」。换句话说，桥接 Skill 的「落库」环节要适配自己的存储形态，不能照抄。
• 一键跑完 ≠ 质量最优。 作者自己也承认：他更常用的还是逐个呼叫，因为每一步产出不完美、他想中间介入。所以「全自动化」适合素材已经很明确的场景，初稿探索阶段反而手动更稳。这点我完全同意——自动化是手段，不是目的。

一句话收尾： 这篇文章教的不只是「怎么用 8 个 Skill 写博客」，而是一套把「你和 AI 协作的隐性经验」变成「可复用、可演化资产」的思维方式。Skill 是活的，会跟着你的工作流一起长——从痛点开始，先做一个，再用熟了再拆。

延伸：要不要我帮你落地

如果觉得这个思路有用，我可以直接帮你做一个适配咱们仓库的桥接 Skill 雏形——输入文章链接 + 分析角度，输出符合 frontmatter 约定的 .mdx 并提交。想试的话告诉我，我按你博客的实际约定（tags 写法、mdx 格式、提交风格）来写。