如何写技术博客：我把整套思路拆成了 6 个 Agent Skill
从"每次重新教 AI 写"到"一句话跑完整条流水线"——分享我写技术博客的 6-Skill 方法论：为什么拆分角色、模型怎么分级、技术文为何要多一步、以及它实际改变了什么。
TL;DR：我把"写技术博客"这件重复了无数次的事，固化成了 6 个各司其职的 Agent Skill，用一条
/blog-intake指令就能从素材跑到入库。核心不是"6 个"这个数字，而是把隐性工作流显式化、专业化分工这一招。
我写技术博客的频率不低，但一直有个反反复复的痛点：每次动笔，都得重新"教" AI 一遍同样的话——先拟个大纲，顺便解释下术语，再润色一遍，最后想想 SEO 和标题……这些步骤每次都差不多，可每次都得从头说一遍。重复得发指。
之前我写过一篇拆解别人的 8-Skill 博客流水线的文章，讲完"别人的思路"后，我顺手给自己落地了一套。今天这篇不是拆解别人，而是讲我自己的方法：我是怎么想的、拆成了哪 6 个、为什么这么拆，以及它实际改变了什么。
核心思路：把"隐性工作流"变成"可复用资产"
我最初的尝试，和大多数人一样——一个超长的 prompt，把所有要求塞一起："你帮我写篇博客，要口语化、要有观点、要分小节、要检查术语、要 SEO……"
结果撞上了三个老问题：
- 上下文溢出：一个 Skill 塞几千字规则，AI 读到后面早把前面的约束忘了（比如"中英文间加空格"到第 5 段就丢了）。
- 角色冲突：让同一个 prompt 既"严谨补充术语解释"又"精简冗长句子"，它会在两种语气间反复横跳。
- 无法中途介入：一口气做完，大纲方向一旦错了，后面全白做。
解法只有一个字：拆。把一条流水线按职责切成多个小 Skill，每个独立负责一个环节、有独立记忆空间、还能单独重跑。这本质上是"专业分工"——和现实里编辑管文字、校对管事实、运营管分发是一个道理。
关键认知：值钱的不在于"拆成几个"，而在于"把重复的协作经验固化成可复用、可演化的资产"。Skill 是活的，会跟着你的工作流一起长。
我的 6 个 Skill，各自管一段
我把流程收敛成 6 个角色，其中一个是"桥接/入口"，其余 5 个是具体的编辑环节：
| 步骤 | Skill | 角色 | 负责什么 |
|---|---|---|---|
| 0 | blog-intake | 入口/桥接 | 从链接或对话里收素材 → 串起整条流水线 → 落库 |
| 1 | blog-outline | 大纲架构师 | 把灵感/素材收敛成结构化骨架（从零创造，用强模型） |
| 2 | blog-pitfall-recorder | 踩坑记录员 | 补技术坑点（仅技术文启用） |
| 3 | blog-beginner-reviewer | 小白审查员 | 用初学者视角，标出看不懂、跳太快的地方 |
| 4 | blog-editor | 专业编辑 | 润色 + 统一术语 + 排版 + 写 frontmatter |
| 5 | blog-optimizer | 优化师 | 打磨标题/标签/描述 + 让文章更易被 AI 搜索引用 |
注意第 0 步 blog-intake 是个桥接 Skill：它本身不写内容，只负责"收素材 → 按序呼叫上面 5 步 → 把成品写成 .mdx 并提交 git"。它才是真正的编排层。
流水线是怎么跑起来的
普通文章跑 4 步（大纲 → 小白审查 → 编辑 → 优化）；技术文多一步踩坑记录。每一步的产物都带入下一步，前一步不满意还能单独重跑那一步。
几个关键设计决策
光列角色没意思，真正体现"思路"的是下面这几个决定。
1. 模型分级：该省省，该花花
每个 Skill 可以单独指定模型。我的策略很朴素：
需要"从零创造"的用强模型，需要"检查改善"的用默认模型。
blog-outline（从零建结构、要创意和全局思考）→ 强模型blog-optimizer（设计结构化表达、打磨标题）→ 强模型- 其余 4 个（润色、审查、踩坑、入库）→ 默认模型
如果 6 步全用强模型，一篇文章成本会很可观。按任务性质分模型，是在质量和成本间拿平衡。
2. 不照搬 8 个，我砍到 6 个
参考的那套方案有 8 个 Skill，外加视觉顾问、互动设计师。对我来说，这两个的边际收益覆盖不了维护成本——我写的技术文配图需求不固定，结尾也不靠社群分享拉流量。所以我的原则一直是：
先跑通核心 3 个（大纲、编辑、入库），痛了再加，别提前抽象。 我最终是 6 个，但那是因为"小白审查"和"踩坑"两个痛点确实反复出现，才长出来的，不是一次性设计的。
3. 落库方式适配自己的仓库
参考方案是把文章写进 Insforge 后台数据库。我的博客是静态内容仓库（blog/ai/*.mdx + git），没有后台。所以桥接 Skill 的"落库"环节被我换成了：生成符合 frontmatter 约定的 .mdx → git commit。自动化是手段，不是目的，得适配自己的存储形态。
4. 踩坑这一步，只给技术文
blog-pitfall-recorder 我设了硬约束：只在文章类型是"技术文 / 教程"时启用。观点文、趋势分析、纯总结没有"照做"风险，硬加一堆"⚠️ 注意"反而很尬。这一点看似小，却是"别为不存在的场景加复杂度"的具象化。
它实际改变了什么
讲完方法，说点实在的——这套东西用下来，区别在哪：
- 从"每次重新教"到"一次定义，反复用"。 最直观的省心：再也不用每次粘贴那套长 prompt。
- 初稿质量更稳。 小白审查逼我把术语解释清楚，踩坑记录逼我把"想当然"的断言补上风险点。读者照做出错的概率明显低了。
- 我仍然保留手动介入。 素材已经很明确时，我才会一键跑完；初稿探索阶段，我更常单独跑某一步，因为中间想改方向。全自动适合"已知要写什么"，不适合"还在想写什么"。
这套方法论不止能写博客。代码审查、文档生成、测试自动化，本质都是"把隐性协作经验拆成可复用的角色"——同一招，到处用。
总结
写技术博客的本质，不是"文笔好不好"，而是你和 AI 协作的隐性经验，能不能变成可复用、可演化的资产。
我的做法是：用一个桥接 Skill 串起 5 个专业角色，按"创造 vs 检查"分模型，按痛点决定加不加某一步，最后适配自己的仓库落库。6 个不是标准答案，3 个也行、10 个也行——从你最痛的那一步开始，先做一个，用熟了再拆。
如果你也在用 Agent 写东西，不妨从"把你最重复的那个 prompt 变成第一个 Skill"开始。剩下的，痛点会帮你长出来。
Last updated on