哈喽大家好，我是欧呦，这篇文章将为大家分享如何从 0 到 1 写出自己的第一个 Skill，以及怎样把一个「只能在自己电脑上勉强跑通的草稿」，一步步打磨成别人装上也能稳定复用的产品级工具。
在上一篇《从 0 到 1 了解什么是 Skill》里，我们聊清楚了 Skill 的文件夹本质、渐进式加载机制和按需安装的原则。其实 Skill 的创建门槛非常低——相比到处寻找现成的通用 Skill，针对你自己的真实工作流定制出来的 Skill，往往掌握度最高、用起来也最顺手。
从 0 到 1 写自己的第一个 Skill
什么时候值得提炼成一个 Skill？
我日常决定要不要把一件事做成 Skill，一般就看两点：
- 这件事情我自己需要重复执行（比如每天或每周都要跑好几遍的固定流程）；
- 或者我认为这件事情它有分发给别人的价值，别人可能也会遇到类似的问题。
如果你一时想不起自己平时有哪些重复劳动，甚至可以让 Agent 扫描一下你本地过去几周的历史对话记录，让它帮你找出那些反复出现、适合提炼成 Skill 的工作流。
从零开始做一个 Skill 的真实四步流程
一般我们不会自己从头手写 SKILL.md，也不需要去背它的格式规范，创建过程都可以交给 Agent 来完成。我从零开始做一个新 Skill，真实流程是下面这四步：
第一步：先把这个任务真正执行一遍
不要一上来就对着空白文档凭空编规则。我自己的习惯是，先在没有 Skill 的情况下，在对话框里带着 AI Agent 把这个任务真刀真枪地执行一遍——比如先让它真的做完一份满意的 PPT，或者真的把一次页面改版走通。在这个过程中，你会一步步纠正它的偏差，摸清整条路径是怎么走的、中间踩了哪些坑。
第二步：让 AI Agent 复盘刚才的流程，用 skill-creator 生成骨架
等任务真正做出来、跑顺之后，直接在当前对话里让 AI Agent 复盘刚才执行的流程，并使用 skill-creator（像 Codex 已内置该能力，也可以直接安装我文末开源的 oil-skill-creator）生成一个 Skill。你可以直接在当前对话里这样对它说：
请复盘我们刚才完成这项任务的完整流程、中间纠正过的问题和关键判断标准，调用 skill-creator 把它提炼生成一个可复用的 Skill，并安装到我的 Skill 目录里。
Agent 就会自动新建好文件夹、写好 SKILL.md 的目录描述和正文步骤。
第三步：去一个没有历史上下文的新话题里真正实测
在 Skill 开发生成完成之后，我还会去一个没有历史上下文的新话题里面去真正实测，看一下它到底能不能够顺利地把整个流程给跑通。
为什么拿着刚生成的 Skill 去一个没有历史上下文的新话题里实测，才能够发现问题？
因为你在生成这个 Skill 的时候，在原来的旧话题里，你已经有很多主观跟 AI Agent 传递的信息了，它有很多过往的业务信息，那么它在原来的窗口里能跑通也是正常的。而当你去到一个新的上下文里面，你没有历史上下文，这时候考验的就是你的 Skill 里面的内容写得是否足够完善，能够让 AI Agent 单靠读取这个 Skill 就理解你的要求。
实测时如果发现执行结果没有达到预期，第一件事不是在当前聊天框里临时补救，而是回去把漏掉的前提补进 Skill 里，再开新话题重新测试。我们要减少的是未来的使用成本。
第四步：把重复的步骤程序化，并持续迭代测试
在实测打磨的过程中，把流程里反复执行、固定的操作抽出来写成 scripts/ 脚本（下面下一节会细讲），并用科学的方式对比迭代效果。
如果做的是改文案、做 UI 设计这类结果偏主观的 Skill，人工很难一眼量化好坏，AI 自己也很难客观评价一段话到底有没有「AI 味」。这时候我们可以直接让主 Agent 派生子 Agent 来做无上下文的对比测试，省去自己手动开多个窗口的麻烦。你可以直接跟主 Agent 这样说：
请同时启动两个不带当前历史上下文的子 Agent：一个不读取这个 Skill（或读取修改前的旧版），另一个读取刚改好的新版 Skill，让它们分别执行同一个任务，把两份结果并排发给我对比。
等你对比完两边的产出，指出哪一版更好、好在哪、差在哪之后，再让主 Agent 按这个标准修改 Skill，然后重新派两个干净的子 Agent 比下一轮，直到读取 Skill 的子 Agent 一次就能稳定做出满意的结果。
把 Skill 写好、做成产品的核心心得
用 skill-creator 复盘生成的 Skill，通常只能算是一个基础骨架。如果你想让它不仅在自己电脑上能跑通，还能长期稳定运行，甚至作为一个顺手的产品分发给别人用，下面这几条是我开发十几个 Skill 总结出来的核心心得。
1. Skill 是写给 Agent 看的，能够程序化的事情就程序化
首先要记住：SKILL.md 不是写给人看的，是写给 Agent 看的（给人类用户看的功能介绍、效果展示和安装说明，应该写在仓库的 README.md 里）。对 Agent 来说，上下文越简洁、越准确，执行效果越好，所以正文里不要堆砌冗长的解释；开放式任务也不要把规则写得太死，避免模型矫枉过正。
在此基础上，最重要的一条心得就是：Skill 里面能够程序化的事情就程序化，这样子可以减少 AI Agent 理解的负担。
scripts/ 里面的脚本，就应该是一些非常重复、适合用脚本来做的工作。比如说我有一个浏览器自动化的工作，或者自动跨平台发布视频、生成封面的流程——如果我已经跑通过一次，我就不应该再用文字的方式告诉 AI Agent 怎么样去跑，而是把它落地成一个脚本。
再比如说我做 UI 设计的 Oil UI，我在里面也会提供一些现成的脚本：一个是用来合成不同风格同屏对比页面的脚本，还有一个是对页面进行真实截图、用来定位和检查实际设计情况的脚本。这些工作，我不需要让每一次 AI Agent 都手动去写代码，或者利用其他的工具去做。把固定的、稳定的步骤交给程序，把需要灵活调整的部分留给 Agent；万一哪天网页结构变了导致脚本执行遇到问题，Agent 还能临时介入做一层微调兜底，既省 Token 又稳定。
2. 像做产品一样打磨：从「本地能跑通」到「别人用得顺手」
我们可以把 Agent 看作操作系统，每一个 Skill 都是运行在它上面的软件。如果希望别人装上你的 Skill 也能稳定顺手，还要注意四个细节：
- 设计好首次上手引导（Onboarding），别让模型去翻脚本源码。 很多需要外部环境或 API Key 的 Skill，在你自己电脑上早就配好了，但换到别人的电脑上直接调脚本就会失败。如果没做引导，弱一点的模型遇到报错就会去翻
scripts/里的脚本源码，试图分析为什么跑不通，白白消耗上下文。合理的做法是让脚本在报错时直接输出清晰的配置指引，引导 Agent 按说明提醒用户配置，而不是去读脚本的实现源码。 - 管好外部 API Key，别让用户把明文密钥发进聊天框。 当 Skill 需要配置第三方 API Key 时，直接让用户把明文密钥粘贴进对话框有两大隐患：一是如果用户走的是第三方模型中转站，密钥会直接流经不可控的服务器日志；二是 Agent 可能会顺手把明文密钥写进代码文件，一旦提交到公开的 GitHub 仓库就会泄露。更稳妥的做法是：检测到缺少密钥时，由本地脚本在
127.0.0.1拉起一个轻量配置网页，用户在浏览器填入后，直接存入操作系统的原生凭据库（如 macOS 钥匙串、Windows 凭据管理器），全程不经过 Agent 上下文；而非敏感的普通设置则存进系统的用户级配置目录，这样在电脑上混用不同 Agent 时也能直接共享配置。（这套本地网页录入与系统凭据组件我已经封装进了下面的oil-skill-creator，直接复用即可，不需要自己从头写。） - 照顾弱模型的承受能力，拆小文件并保留中间产物。 强模型能硬扛很长的文档和几千行的大文件，但能力弱一些的模型面对过长上下文时，指令遵循能力会明显下降。比如做生成多页 HTML 演示文稿的 Skill 时，如果让模型把两三千行代码全写进同一个文件里，不仅中途网络一波动就会前功尽弃，后期某处标签出错时弱模型也改不动。把每一页拆成独立的 HTML 文件，最后再用脚本自动合并成完整文稿，这样每一页都有独立的阶段性产物，就算中途断掉也能接着跑。
- 补充可视化交互模板，并做好跨平台兼容。 对于需要人工确认或微调的环节（比如修改识别出来的视频字幕、同屏比较几版设计稿），在
assets/里提供一个现成的 HTML 模板，让脚本把数据注入进去并在浏览器打开操作，比每次让 AI 临时手写一个界面稳定得多。同时，写脚本时要兼顾 macOS、Windows 和 Linux 的环境差异（比如不要假设所有电脑上都有python命令，macOS 通常是python3，Windows 可能是py -3）。
直接复用 oil-skill-creator 帮你创建与体检
上面提到的这一整套经验——从判断一个需求值不值得做成 Skill、生成目录骨架、接入现成的本地网页 API Key 录入组件，到启动无上下文的子 Agent 做对比评估、检查弱模型与跨平台兼容性，甚至规划免费版与付费版的商业化方案——我都已经沉淀到了开源的 oil-skill-creator 里：
npx skills add oil-oil/oil-skill-creator
你可以直接让 AI Agent 安装这个 Skill。无论你是准备把刚跑通的流程提炼成自己的第一个 Skill，还是想让它把手头已有的 Skill 全面扫描体检一遍，它都能按这套标准帮你找出隐患并一步步改好。