一个优秀 Skills 的诞生
怎么从零做一个好用的 Skill
好的 Skill 不是写出来的，是调出来的
怎么把一个 AI 技能从"能跑"调到"好用"？
五月中旬，有位同学在仓库里提了个 issue：他在做毕业答辩的 PPT，论文里的实验结果图必须原封不动地放进去。AI 自己画的图再好看也不行——答辩的时候数据图对不上原文，那是要出事故的。
我觉得是整篇文章里最值钱的一句话：我没有骂 AI，我去问它为什么。
"你为啥不用内置的生图工具生成了？" "是 skill 的问题吗，导致你不听 skill 的？" "skill 里如何写才会避免出现类似的问题？"
注意这三句话的递进。第一句问行为，第二句把矛头从 AI 转向 Skill 本身，第三句直接让它给出修改方案。
很多人遇到 AI 不听话，第一反应是"这 SKILL 不行，这模型也垃圾"。但你换个角度想：AI 每次跑偏，其实都是 Skill 的一次 bug 报告。它为什么会这么理解？是哪句话写得有歧义？是哪个步骤缺了约束？你要换位思考，你要做的是搞懂AI的“脑回路”。
AI 自己最清楚它是被哪句话带偏的。你问它，它真的会告诉你。
打造一个好的 Skill，一定要有反馈，一定不要闭门造车。反馈可以是你自己的不同 case，也可以是社区真实使用人的案例。Skill没有什么好闭源的，它就是一堆文本，你没办法加密。独乐乐不如众乐乐。不要担心别人窃取你的成果，Skill是死的，但做事的品味和思想是活的，那才是你的技术壁垒，也是你在未来AI时代安身立命之本。
先把一件事做成，再谈 Skill
我的做法是：先别管 Skill，先把一件具体的事做成。找一件你反复要做的事，先用一次对话把它聊到满意，然后马上说一句"把刚才这个流程做成一个 Skill"。
图片转可编辑 PPT 那个技能，起点是小红书里面一位用户的真实需求，她真的有可编辑PPT的需求。她想让我设计一个skill，可以把做好的图片式PPT转成可编辑的。因为那个时候我的Codex PPT skill做的还是挺好的，但它有一个最大的问题就是不可编辑。
我一开始是拒绝的，因为我其实没有可编辑PPT的需求，但盛情难却，我也想挑战一下，能不能做出一个比较好用的可编辑PPT skill。
那位热心的网友还提供了一个视频，有人用 AI 把一张 PPT 截图还原成了可以编辑的 PPT 文件，视频里的做法非常原始，就是纯prompt，没有任何工程化技巧，一次也只能转一张，需要人工在那里一直问，但是效果和思路确实还行。我觉得这个流程有意思，就把视频丢给 AI：
"把这个视频里每一个关键帧在干啥，整理成一个文本。配上时间线，分镜。"
它整理完，我接着问："你看懂流程了吗？复述一下。"
它复述错了。我说："你理解错了，你再看看视频里的步骤。"
复述对了之后，我才说："试试吧，复刻流程。"
做完我还要验收："你截图对比一下？"
看到没有，这个过程里我没写一行代码，也没写一个字的 Skill。我就是在聊天，但每一步都在验收：先验收它的理解，再验收它的执行。直到那一次对话的结果让我满意了——当天晚上，我立刻让它把整个流程固化成一个 Skill。
为什么要"立刻"？因为那次成功的对话里，藏着所有关键细节：用了什么工具、什么顺序、什么参数。所有的这些都是在我精心指导下完成的，趁热打铁把它变成 Skill，比事后回忆靠谱一百倍。
所以如果你想做自己的第一个 Skill，我的建议是：找一件你反复要做的事，先用一次对话把它聊到满意，然后马上说一句"把刚才这个流程做成一个 Skill"。
第一版就这么来的。粗糙没关系，后面有的是机会调。
AI 是会偷懒的
codex-ppt skill的制作过程也类似，不过那是源于我自己做PPT的习惯，我希望把控大纲，我希望把控风格，我也希望它有演讲者备注。
第一版 Skill 做出来之后，真正的麻烦才开始。
我拿它做一套四十多页的 PPT，发现一个规律：前几页做得有模有样，越往后越糊弄。到三十几页的时候，它甚至开始自作主张："我写个脚本批量生成剩下的页面吧，这样快。"
翻译一下：它想摸鱼。
这不是 AI 的品德问题，是它的生理问题。你可以把 AI 的上下文理解成它的工作记忆——它能同时记住的东西是有上限的。做一页 PPT 它要生图、看图、改图，几十页做下来，工作记忆早就塞爆了。塞爆之后系统会自动压缩旧内容，压缩就会丢细节，丢的偏偏都是你前面千叮咛万嘱咐的要求。
记不住要求，自然就开始糊弄。
解决思路说出来很朴素：别让一个人干所有的活，雇一个团队。
我们把架构改成了"包工头带工人"的模式：
- 主 AI 是包工头，只负责派活、看进度、验收，不亲自下场干活；
- 每页 PPT 派给一个独立的子 AI（术语叫子智能体），它的工作记忆是全新的，只装这一页的任务，干完就解散。纯牛马，真黑奴；
- 同时开工的工人有个上限，默认六个，一个干完了马上补一个进来，流水线不停。
效果立竿见影。每个工人都精力充沛地只干一件事，第四十页和第一页的质量没有差别。而且六个人同时开工，速度也快了好几倍。
还有一个容易被忽略的点：每个工人交活之前，必须自己先检查一遍——文字有没有乱码、风格和样张是不是一致、有没有内容被截断。因为它自己不看一眼，是真的不知道自己做出来的东西有问题。
给有基础的读者补一个细节：工人交活的格式是写死的，只许返回这三行，不许写小作文
backend_used=built-in image tool selected_source=/绝对路径/slide_07.png qa_note=文字清晰无乱码，风格与样张一致
用了什么工具、产物在哪、自检结论是什么。包工头拿到就能机器解析，不需要从一段自然语言汇报里猜重点。子智能体之间的交接，越像协议，越不像聊天，就越稳。
不许踹正在干活的人的椅子
包工头模式跑起来之后，又出了新问题。
主 AI 看不到子 AI 的工作过程。某个工人这一页比较复杂，干得久了点，包工头等得不耐烦，心里嘀咕"这家伙是不是卡死了"，然后——把人家直接杀了，活儿白干，黑奴比窦娥还冤！
或者更隐蔽的：包工头觉得等着也是等着，自己撸起袖子把那页用低质量的方式糊了一个，还不告诉你。
怎么治？我们的答案是一块"任务看板"。
具体说，是几个共享的文件。每页 PPT 在看板上有一张卡片，状态流转只有一条路：
pending（待领取）→ dispatched（进行中）→ recorded（已交付）→ accepted（已验收） ↘ blocked（被卡住）
每张卡片长这样——谁领的活、什么时候领的、领的任务是哪份，全部留痕：
{ "slide_id":"slide_07", "status":"dispatched", "dispatch": { "agent_id":"worker-3a9f", "dispatched_at":"2026-05-29T14:32:05Z", "prompt_sha256":"f8a9b2c3…" } }
连任务文件的指纹（那串 sha256 哈希）都记下来了——工人交活时校验对不上，说明它没按派的任务做，直接打回。
然后立两条铁规矩：
第一条：状态只能由脚本修改，嘴上说的不算。 子 AI 说"我做完了"，没用；必须跑验收脚本，校验通过了，卡片才会变成"已交付"。这一条是专门治 AI 的幻觉的——它有时候真的会一本正经地宣布自己完成了根本没做的事。
第二条：包工头做任何决定之前，必须先看板子。 想杀一个工人？先查卡片。卡片显示这页"进行中"，而且几十秒前刚有动静，那就说明人家活着、正干着呢，不许动。
这跟你查快递是一个道理。包裹在分拣中心待了十分钟，你不会取消订单，因为物流页面写着"最后更新：2 分钟前"。有了这个时间戳，你就有了耐心。
当然也有真失联的时候——工人崩了，永远不会回来了，那张卡片就一直占着坑。我们后来专门加了一个"重置"命令，把卡片退回"待领取"，再派个新工人。但有个讲究：重派之前必须先改变某个条件。 一模一样的条件下重跑，只会一模一样地失败。
这套规矩里还有一条我自己定的，分享给大家：
"同根因失败两次，不要停下来，不要问用户，用户也不懂，换一个方式自己解决。"
这句是我对 AI 说的原话。失败了两次还来问我怎么办，那是它的失职——证据都在文件里躺着，自己去读。
别让 AI 记路，让它问路
做第二个技能的时候，我们把这套看板又往前推了一步，我认为这是整套设计里最漂亮的一笔。
之前的模式是：AI 读完 Skill 文档，把整个流程记在脑子里，然后照着记忆执行。问题还是那个老问题——流程一长，它记不住，走着走着就忘了自己在哪一步。
新模式是：AI 不需要记住流程。它只要反复执行一个CLI命令："下一步该干什么？"
这个命令会去读任务看板，然后直接告诉它该干什么。实际长这样：
```toml $ editppt run next <run目录> stage=dispatch_pages # 现在该派活了 suggested_pages=page_004, page_007 # 派这两页 slots_available=2# 还有两个空闲名额 ```
下一次再问，可能就是
stage=wait（所有人都在干活，你等着），或者 stage=finalize（全部完成，开始组装最终文件）。流程的"地图"不在 AI 的记忆里，在代码里。AI 从"背地图的人"变成了"听导航的人"。导航说下个路口左转，它就左转。
你想想你自己开车去陌生地方，是背地图靠谱，还是开导航靠谱？
对 AI 来说答案更极端，因为它的记忆还会被压缩。把流程交给代码之后，哪怕对话进行到天荒地老，它问一句"下一步干什么"，得到的答案永远是准的。
一个技能还是两个技能
经常有人问：你为什么做了两个 PPT 技能，不合成一个？生成 PPT 顺手就转成可编辑的，不是更省事吗？
这里有个很重要的取舍，我掰开讲讲。
AI 直接生成的 PPT，每一页其实是一张完整的图片。好处是惊艳——AI 的全部注意力都花在"这页怎么好看"上，生图模型现在的水平，第一版出来就很能打。坏处是图片没法编辑，你想改个标题都不行。
如果我要求它从第一版就做成可编辑的呢？可以做，但它的注意力会被无数细节绑架：这个文本框放哪、那个图标怎么拼、字号多大。最后你得到的是一堆细节的拼凑，工整，但丑。
为了可编辑性牺牲美观性，对大部分人来说是亏的。
因为大部分人做 PPT，真的不需要编辑。一场不那么正式的分享，PPT 就是个背景板，内容靠嘴讲。背景板的第一要务是好看。
那真需要编辑的人怎么办？再跑第二个技能，把图片版还原成可编辑版。两个技能自由组合：只要好看的，跑第一个就完事；要改内容的，接着跑第二个。
而且说真的，与其指望事后能改，不如事前把大纲聊清楚。每页要表达什么观点、要放哪张图，这些在生成之前都确认好，第一版的内容就不会有大问题。真有某一页不满意，直接说"第五页重做，问题是什么什么"——AI 改一页的成本，远低于你在四十页可编辑文件里手动调的成本。
这里顺便纠正一个很多人的误区：Skill 不是一个按下去就不能停的全自动流水线。 它跑到任何一步你都可以打断，改点东西，它会接着往下跑。把 Skill 用活的人，和只会"一键运行然后抱怨结果"的人，体验差距是巨大的。
能写死的，全部写死
打磨到后期，我悟出一条挺反直觉的原则：想让 AI 稳定，就要少让它发挥。
流程里有大量步骤其实是固定的：转换文件格式、计算坐标、校验结果、拆分图片。这些事让 AI 每次现场写代码去做，等于每次重新发明轮子——而且每次发明出来的轮子都长得不太一样，错误就藏在这些"不太一样"里。
所以凡是我们明确知道"这件事就该这么做"的，全部写成固定的脚本。AI 只负责调用，不负责发明。
后来更进一步，我们把所有脚本整合成了一个命令行工具。命令行可以理解成"用打字代替点鼠标"的操作方式——对人来说有门槛，对 AI 来说反而是母语：它的训练数据里有海量的命令行用法，不用教就会。
比如 AI 第一次接触我们的工具，只需要敲一句"帮助"命令，就能拿到整张菜单：
editppt ├── prepare 把图片/PDF 整理成一个任务目录 ├── run 推进流程：问下一步、派活、验收、组装 ├── image 生图、改图、抠素材 ├── formula 把数学公式渲染成图片 └── page 单页工具：量字号、出预览、做校验
每个命令后面再加一句"帮助"，又是一层更细的说明，连每个参数怎么填都写好了。AI 顺着这棵树往下摸，几分钟就把整套工具学明白了——而且这是它在训练时就刻进骨子里的学习方式，比读十页文档管用。
还有个隐藏好处：这个工具装好的同时，它需要的运行环境也自动配齐了。懂行的读者会心一笑：Python 虚拟环境的依赖地狱，顺手就解决了。
这一步还有个意外收获：省钱。AI 现场写代码是要消耗 token 的（你可以理解为按字数计费的工作量），而调用一个现成命令只要一行。同样一个任务，成本直接降了一个量级。
现在可以兑现开头那句话了：这么多脚本、整套命令行工具，我真的没写过一行代码，也没看过一行代码。
我只做两件事：把需求讲清楚，以及要求 AI 给每个脚本写测试。测试通过，这个脚本就是可信的。我的精力全部花在"这件事的正确流程是什么"上——这个才是只有你能提供的东西，代码不是。
个人觉得，如果你在现在这个时代，还在一行一行地审AI写的代码，已经是新时代的古法编程了。人的认知是有限的，人的信息带宽也是有限的，你需要审的是文档，而不是代码。
论技术，Claude Code的创始人牛不牛逼，人家甚至给TS写了一本书，但是这样的大牛都已经不审代码了，你还审什么？
四个压箱底的细节
流程的事讲完了，给技术读者上点硬菜：四个具体的"效果是怎么抠出来的"。不爱看技术的朋友可以快速划过，只看每段的第一句。
一、怎么让几十页 PPT 风格统一？
内置的生图工具有个限制：只能传文字提示词，没法传参考图。光靠文字描述"科技蓝、扁平风"，每一页生出来还是各有各的味。
我们的解法土但有效：每个工人在生成自己那页之前，必须先"看一眼"已经定稿的样张图，把风格刻进脑子里，再去调生图工具。就这一个动作，整套 PPT 的一致性立刻上了一个台阶。
到了第二个技能，我们干脆换成 API 方式生图——API 可以把参考图和任务一起传过去，参考图和生成结果在同一个请求里，风格锁得更死。实测下来，一致性比内置工具更稳。
二、AI 不知道"24 号字"长什么样
做可编辑 PPT 时发现一个有趣的盲区。AI 看图认字非常强，比传统 OCR 还强，模糊的字它都能纠正回来。但它完全不知道：图里这行字，对应 PPT 里多大的字号。
它只能蒙。蒙一个 40 号，生成出来一看太大，改成 28，再看，再改……一页 PPT 光调字号就五六轮，时间全耗在这。
解法是别让它蒙，给它量。我们接了 OCR 接口，把每行字的外框宽高量出来，用公式直接换算成 PPT 字号，然后用两种方式喂给 AI：一份 JSON 数据，外加一张"标注图"——在原图上把每行字框出来，旁边直接标上字号。AI 看一眼就知道：标题 32 号，正文 18 号。有时候让AI看图，效果非常好，因为图片能够表达的信息非常的丰富。
蒙变成量，字号从此稳了。
三、十个图标，只生成一次图
可编辑 PPT 要把页面里的图标一个个抠成独立素材。一个个生成？十个图标十次调用，又慢又贵。
我们的做法是让 AI 一次生成一张"素材板"：把页面里所有图标整整齐齐排在一张图上，背景用一种页面里绝对不会出现的高饱和纯色——绿幕抠像的原理，行话叫 chroma key。然后用传统图像算法把每个图标切下来、去掉背景。
一次生图，十个素材。而且重新生成的图标，比从原图里硬裁出来的还要清晰锐利。
四、被挡住的背景怎么补？
把一页 PPT 的文字和图标都"摘"下来之后，背景上会留一堆窟窿。传统修复算法对付纯色背景还行，遇到照片、插画、渐变光影这种复杂背景就露馅了。
这正好是生图模型的主场：让它对着原图，把摘掉的东西重绘掉，补出来的背景和周围浑然一体。传统算法快但糙，生图模型慢但真——所以我们按背景复杂度分流：纯色和简单渐变走脚本，复杂背景走重绘，一次生图调用都不浪费。
这四个细节有一个共同点：没有一个是靠堆提示词解决的，全是靠看清工具的能力边界，然后绕过去。 生图工具不能传参考图？让 AI 先看图再生成。AI 不会换算字号？用 OCR 量出来喂给它。做 Skill 做到后面，拼的就是你对工具的理解深度。
这份说明书是写给 AI 看的
聊点写 Skill 文档本身的技巧。就一个核心问题：你写的每一句话，到底是给谁看的？
Skill 里的每个字都会进入 AI 的工作记忆。所以那些写给人看的东西——项目介绍、更新日志、致谢——统统不要放进去。AI 看了不仅没用，还可能被带偏。你要清楚地分两个区：给用户看的放仓库首页，给 AI 看的放 Skill 里。
落到目录结构上，就是这样：
仓库根目录/ ├── README.md ← 给人看：介绍、截图、安装方法 ├── CHANGELOG.md ← 给人看：更新日志 └── skills/codex-ppt/ ← 给 AI 看，只有这里会进入它的工作记忆 ├── SKILL.md ← 主入口：流程骨架 + "什么情况去读哪个文件" ├── docs/ ← 分阶段的详细规则，按需读取 ├── prompts/ ← 派给"工人"的任务模板 ├── references/ ← 可选的视觉风格库 └── scripts/ ← 写死的固定流程脚本
AI 被触发时只会看到
skills/codex-ppt/ 里面的世界，README 和它一墙之隔，永远不会污染它的判断。给 AI 看的部分，也有讲究：
重要的放前面。 AI 和人一样，开头的内容记得最牢。
可选的往外放。 比如"用不用子智能体""要不要配第三方接口"这种分支流程，不要堆在主文档里，放到二级文件夹，主文档只留一句"遇到什么情况去读哪个文件"。AI 按需去读，工作记忆始终清爽。
给反例，并且给反例起名字。 我们的文档里有一节专门叫"虚假进展"，描述的是 AI 最爱犯的一种偷懒：把简单的部分做完，把难的部分糊弄过去，整体看起来像是完成了。给这种行为起了名字、写清楚为什么不行之后，AI 踩这个坑的概率明显下降。光写"禁止偷懒"是没用的，它不知道什么算偷懒。
少给自主性。 这条可能跟很多人的直觉相反。在一个追求稳定交付的 Skill 里，你要的不是 AI 的创造力，是它的服从性。明确告诉它第一步、第二步、第三步，每步之间设检查点，不过就不许往下走。自主性给多了，可控性和稳定性会肉眼可见地下降。
我们的子任务模板里有一句话，我很喜欢，抄给你：
"这个 Skill 过去的每一种失败模式，都编码在这几份文档里。没读文档就做出的决定，一律无效，一律重做。"
一份好的 Skill 文档，本质上就是一部踩坑史的编码。
别忘了不会敲命令的人
还有一块容易被技术人忽略的：好的 Skill 要照顾没有编程基础的用户。
我们在这上面花的心思不比核心功能少：
需要配置第三方接口？第一次问你要，之后永久记住，跨会话都不用再问。第二个技能甚至会自动检测第一个技能配过的东西，直接复用，连第一次都省了。
需要申请某个免费服务的密钥？Skill 里写好了引导：去哪个网址、点什么按钮、申请下来发给 AI 就行，AI 自己配。全程不需要你打开终端。
想更新技能？对 AI 说一句"更新一下那个 PPT 技能"，它自己去拉最新版装好。仓库地址和更新方法都写在 Skill 里了。
判断一个 Skill 好不好，有个很简单的标准：一个完全不懂命令行的人，能不能纯靠聊天把它用起来。
Skill 只是一段文本
最后说一个我特别想纠正的观念。
很多人把 Skill 当成软件：下载、安装、使用，不好用就卸载，等开发者更新。
错了。Skill 就是一段文本。 没有编译，没有黑盒，没有任何神秘的东西。你可以打开它、读它、改它。
这意味着什么？意味着别人的 Skill 拿到手，你完全可以改成自己的版本。别人做 Skill 是基于他的经验和审美，为了照顾所有人，必然带着各种妥协和冗余。你特别喜欢某种 PPT 风格？直接让 AI 把这个风格写进风格库。我们甚至在 Skill 里内置了这个引导：做完一套你满意的 PPT，说一句"把这个风格存下来"，下次它就成了内置选项。
你的 Skill 会越用越像你。这才是 Skill 这个东西最迷人的地方——它不是你下载的一个工具，它是你和 AI 共同沉淀出来的、独属于你的工作方式。
把全文折成一张清单
前面讲了一堆故事，怕你读散了，把重点收拢一下。哪天你动手做自己的 Skill，对着这张单子检查就行：
起步
1. 别从"做 Skill"开始，从"做成一件事"开始。用一次对话把事情聊到满意，做成的那一刻立刻固化成 Skill 第一版。
2. 拿真实任务反复测。AI 每次跑偏都是 Skill 的 bug 报告——用反问法审它："是 Skill 哪里没写好？"让它自己供出被哪句话带偏。
3. 踩过的坑写成反例放进 Skill，最好给坏行为起个名字（比如"虚假进展"）。光写"禁止"没用，AI 不知道什么算违规。
架构
1. 任务一长 AI 就摸鱼，根因是工作记忆塞爆。拆给子智能体：主 AI 只调度，工人只干一件事，交活前必须自检，返回格式协议化。
2. 多个 AI 协作靠文件状态机：状态只能由脚本推进，嘴上说"做完了"不算；做任何决定之前先看板子，不许凭感觉杀工人。
3. 长流程别让 AI 背地图，让它问路——"下一步干什么"由代码回答，AI 永远不会迷路。
4. 能固定的全部写成脚本和 CLI，AI 只调用、不发明。你不用写代码，只需要说清需求、要求写测试。
5. 摸清工具的能力边界，缺什么就在流程上补什么：不能传参考图就先看图再生成，不会换算字号就用 OCR 量给它。别硬靠提示词怼。
文档
1. Skill 是写给 AI 看的：重要的放前面，可选的下放到二级目录，README 这类给人看的东西隔离在外。
2. 追求稳定就少给自主性：明确第一步第二步第三步，步骤之间设检查点，不过不许往下走。
体验
1. 照顾不懂命令行的人：配置在聊天里就能配完，配过一次永久记住，更新一句话搞定。
2. 记住 Skill 只是文本：可以打断、可以改、可以越用越像你。你的 Skill 永远不是终稿。
如果嫌十二条记不住，那就先记第 1 条。剩下的十一条，等你翻车的时候，自然会一条一条想起来。
最后
写到这里我数了一下，这两个技能从诞生到现在，大大小小的迭代有几十轮。每一条规则背后都是一次翻车，每一个设计背后都是一次不爽。
所以回到开头那个问题：怎么从零做一个好的 Skill？
我的答案是：先别想"做 Skill"这件事。找一件你下周还会再做的事，这周用 AI 把它做成，做成的那一刻让 AI 把过程固化下来。然后用，翻车，审问，修改，再用。
两个月之后，你手里那个东西，会比你今天能设计出来的任何版本都好。
至于它最后会长成什么样子——说实话，我自己的两个技能现在长的样子，也完全不是我当初设想的样子。
这大概就是"调"和"写"最大的区别。