这是一个「Obsidian × AI」系列。
我会从最基础的认知开始，慢慢写到资料整理、写作工作流，再到怎么把 AI 接进来。
如果你还没看过前几篇，可以先看 [[Obsidian入门36：Skill 是什么？把它想象成你给 AI 建的一套 SOP]]。
去年底 Anthropic 把 Skill 格式开源之后，这个东西突然就火了。Codex、Cursor、Gemini CLI 都开始兼容，朋友圈也老有人转。
但我在那之前就已经动手做了。
那时候每次写公众号，我都要手动跑一遍「选题→写稿→审校→配图→归档」的步骤，漏一步后面全乱。
有一次写完了找不到上次的归档文件，翻了十几分钟。就在那个瞬间，我决定把这套流程交给 AI，自己只负责想和写。
后来做了两个：wechat-writer 管写作全流程，wechat-director 管配图。
做完了我才发现，最开始的步骤应该是我自己得先把自己的脑子捋清楚：
- 我到底在干什么？
- 我卡在哪里？
- 我希望 AI 怎么帮助我
什么值得做成 Skill？
先说一个很重要的判断：不是每件事都值得做 Skill。
你问 AI "帮我查一下今天天气"，一句话就搞定了，不需要 Skill。Skill 解决的不是单次问题，是流程问题。
我做第一个 Skill 的时候，是因为发现自己在重复一个上面说到的那个循环：每次写公众号文章，都要走一遍"选题→写大纲→写初稿→审校→配图→发布"的流程。每一步都得花时间和精力盯着。
所以，如果你发现自己在做这样的事情：
- 已经在手动重复的事，每次步骤都差不多
- 步骤多、容易漏，像多米诺骨牌一样倒一个就全乱
- 最后一个信号比较隐蔽：你脑子里已经有全套流程，但每次动手的时候都有种「我怎么又在干这个」的烦躁感。这时候你就需要一个东西替你跑流程
那这件事就值得做成 Skill。
第一步：跟 AI 把话说清楚
很多人一上来就直接跟 AI 说"帮我做一个 Skill"，这句话跟让一个陌生人"帮我做顿饭"差不多。它根本不知道你喜欢吃什么、厨房里有什么、你有多少时间。
做 wechat-writer 的时候，我并不是打了一句 prompt 就完事了。我是先坐下来，跟 AI 聊了十几轮。
我告诉它：我写公众号有一个固定的流程，每次都是先找选题、然后做调研、然后写大纲……每一步都有不同的角色在做不同的事。
AI 会追问："你这个流程里面，哪一步最容易出问题？""你希望我帮你做什么，你希望自己保留什么？""你想要的最终产出是什么样子的？"
这个对话过程，我们俩在一来一回中把模糊的感觉变成了清晰的描述。甚至聊着聊着，我自己会突然想到"诶！这个点也可以加进去"。这是我一个人想的时候不会想到的。
关键认知：不要指望一次说清楚。
第一轮你大概率会漏东西。没关系，AI 会通过追问帮你补上。但是至少你得先扔一个模糊的轮廓出去，AI 才能帮你把轮廓填实。
就像抛砖引玉，你至少得先把“砖”抛出去，才有可能引到玉。
第二步：给 Skill 定结构
什么东西交给 AI，什么东西锁死。这是我花了最长时间才搞明白的事。
最开始做还不叫做wechat-writer 的 Skill 的时候，我没有现在这么清晰的结构，当时只是像搭建起来一个写作天团一样（[[用 AI 审阅 AI：我的写作天团升级记]]）。
当时是一堆独立的 Markdown 文件：一个文件是一个"角色"，比如主编、主笔、审校。然后有个"总管"角色负责调度，告诉 AI 这一步去读主编的文件，下一步去读主笔的文件。
这种做法的好处是灵活。
坏处也很明显：模型强的时候听话，模型一般的时候就开始放飞自我，不完全遵循 Markdown 里写了的步骤和规范，各个步骤出来的东西偏离预期。
后来我接触到 Skill 的标准形式，重新调整了思路。这个过程我之前写过（[[我把 11 个 AI 员工全裁了，只留了 1 个]]）。
现在的做法是三层分工：
第一层：AI 可以自由发挥的部分，用 Markdown 约束。
比如"审校时要检查 AI 味"、"写初稿时要保持口语感"。这些是方向性的指引，AI 需要理解意图而不是死记规则。
第二层：确定性步骤，用脚本锁死。
比如"归档文件到指定目录"、"更新已发文章索引"。这种事不需要 AI 思考，直接执行就行。写成脚本，每次都一模一样。
第三层：输出格式，给模板参考。
Skill 里有个 references 目录，你可以放一些模板文件。在 SKILL.md 里告诉 AI "去读那个模板，按它的格式输出"。AI 看完模板就知道你要什么结构了，比你啰嗦十句都管用。
这个分层思路可以用一句话总结：给 AI 画好边界，但别把每个动作都锁死。 它需要知道"什么绝对不能做错"，也需要知道"什么地方可以自己发挥"。
第三步：用 Skill Creator 写出第一版
背景对齐了，结构想清楚了，接下来就是把想法变成文件。
这时候我会用一个叫 Skill Creator 的东西。它是 Anthropic 官方出的一个 meta-skill。简单说就是"帮你做 Skill 的 Skill"。你把聊好的需求和结构告诉它，它会帮你生成一个标准格式的 SKILL.md。
或者你可以在跟 AI 当前的对话中，调用这个 Skill creator来让他依据于对话的上下文给你创建你自己需要的那个 Skill。
上面提到的 Skill Creator 可以在下面的地址找到：
一个标准 Skill 长这样：
my-skill/
├── SKILL.md # 必须有的主文件
├── scripts/ # 放脚本（可选）
├── references/ # 放模板和参考文档（可选）
└── assets/ # 放图片、字体等资源（可选）
SKILL.md 最前面有一段叫 frontmatter 的东西，里面有两个最重要的字段：name（Skill 的名字）和 description（Skill 的描述）。
description 尤其重要：AI 要不要调用你的 Skill，就看这几十个字写得好不好。
举个例子，如果你的 description 写的是"一个帮助写作的工具"，AI 可能不会主动调用。但如果你写的是"当用户需要写公众号文章、做选题调研、或进行多步骤写作流程时，使用此 Skill"，触发率就高很多。
一个心法：第一版别追求完美。
你一定会觉得它"不够聪明"。这很正常，Skill 真正的打磨不发生在写的时候，发生在用的时候。
第四步：真的去用这个 Skill
Skill Creator 的官方文档里有一整套测试流程：写测试用例、跑 baseline 对比、打分、出报告。很严谨，也很复杂。
我对这套东西的态度是：了解就好，不一定要全用。
我自己的做法更简单，直接拿一个真实任务去跑。
比如 wechat-writer 做好第一版之后，我直接用它写一篇文章。从头到尾跑一遍，盯着每一步看：
- 它有没有按我预期的顺序执行？
- 中间产物是不是我想要的格式？
- 有没有跳步或者自由发挥过头的地方？
- 最终的文章读起来对不对？
发现问题，当场跟 AI 说，当场改。一遍跑下来，十几处小修小补都是正常的。
这种测试方式看起来"不正规"，但它有一个巨大的优势：你测的东西就是你真的要用的东西。
是你的真实工作流。改完之后，下次再跑，你会发现它变好了一点。再跑，又变好了一点。
第五步：Skill 是活的
我自己的两个 Skill，没有一个是一蹴而就的。之前甚至专门做了一个[[我做了一个修 Skill 的 Skill|修 Skill 的 Skill]]，就是为了让迭代这件事更顺手。
wechat-writer 从"多 Markdown 文件 + 编排层"改到"统一 SKILL.md + 脚本分工"，版本号从 0.1 迭代到了现在的 3.5.1。
wechat-director 做出来之后，发现生图 API 的返回格式变了，当场改。发布流程发现某个步骤会卡住，当场改。
这从一个角度说明了Skill 本来就是活的。
你的工作流会变，你的需求会变，你用的工具会更新。Skill 跟着你一起变，它才不算"做完就扔"。你用得越多，它越懂你。你越知道怎么跟 AI 描述你需要什么，它越知道怎么执行。
所以别把"改 Skill"当成一个 bug。它是 feature。
你不需要是程序员
刚开始用 Claude Code 的时候，我看终端那个黑底白字的界面，心里是打怵的。
但后来我发现，做 Skill 根本不需要你会写代码。大部分 Skill 就是一个 Markdown 文件，里面写清楚你想让 AI 知道的事。至于脚本你可以让 AI 帮你写，你说"我需要一个脚本，把这个文件夹里的文件移到那个文件夹里"，它几秒钟就给你写好了。
真正重要的能力，没有一件需要你会写代码：
把事说清楚。
你的工作流分几步、每一步输入什么输出什么。能跟 AI 讲明白这个，就已经成功一半了。
知道哪里卡。
不是"我觉得 AI 可以帮我"这种泛泛的感觉，而是"每次到这个环节我都想关电脑"的具体烦躁。
愿意一遍遍磨。
第一版不行就改，改完不行再改。虽笨但管用！
你跟 AI 一起做的 Skill，是你的思想、你的工作流的外化。它长得像你，因为只有你知道你想要什么，只有你知道什么算「做对了」。
