夜雨聆风前几篇我们讲了 Codex App 的安装、工作流、Commands、项目指令、权限和 MCP。
这篇讲 Skills。
如果说 Commands 是入口，MCP 是外部工具，那么 Skills 就是你给 Codex 写的一本小手册。
它不一定连接外部服务。
也不一定需要代码。
它更关心一件事：
这类任务以后都按同一套方法做。
比如：
公众号文章审稿Markdown转公众号排版安全审查发布前检查PR 描述生成项目初始化清单
这些事情不是一次性任务。
你今天要做，明天还会做。
每次都重新写 prompt，很烦。
这时候就适合做成 Skill。
一、Skill 到底是什么
Skill 是 Codex 的可复用工作流。
它通常是一个目录。
目录里最重要的是：
SKILL.md
SKILL.md 里写两类内容。
第一，什么时候应该使用这个 Skill。
第二，使用时应该按什么步骤做。
一个最小 Skill 大概长这样：
---name: wechat-md-publisherdescription:PrepareMarkdown drafts forWeChatOfficialAccount publishing.---# WeChat MD PublisherUsethis skill when preparing Markdown articles forWeChat publishing.## Workflow1.Check mobile reading flow.2.Keep paragraphs short.3.Verify image references.4.Produce a publish checklist.
这个例子不复杂。
但已经能告诉 Codex：
遇到公众号Markdown发布任务时，按这套流程来。
二、Skill 不是更长的 prompt
很多人第一次写 Skill，会把它写成一段超长 prompt。
这样当然也能用。
但不太划算。
Prompt 适合一次性任务。
Skill 适合重复任务。
比如你今天只想让 Codex 改一段 README：
请把 README 的安装步骤写得更清楚。
这不需要 Skill。
但如果你每次写公众号文章，都要检查：
手机端段落标题层级图片路径敏感信息发布清单
那就值得做成 Skill。
判断标准很简单：
同一类事情，你已经重复说过三次。
这时候就可以考虑沉淀。
三、Skill、Command、MCP、Automation 怎么分
这几个概念很容易混。
我用最粗的方式分一下。
Command 是当前线程里的入口。
比如：
/plan/review/status/mcp
Skill 是一套可复用工作方法。
比如：
$humanizer-zh$markdown-to-html$wechat-md-publisher
MCP 是外部工具连接。
比如：
文档查询浏览器操作设计稿读取数据库 schema 查询
Automation 是定时或后台任务。
比如：
每天检查仓库状态每周提醒复盘文章定时监控某个测试结果
所以不要把所有东西都写成 Skill。
如果它只是一个入口，用 Command。
如果它要连接外部工具，用 MCP。
如果它要定时运行，用 Automation。
如果它是一套反复用的做事方法，再写 Skill。
四、什么时候该写 Skill
我会在这些场景写 Skill：
任务反复出现步骤比较固定输出格式有要求容易漏检查项需要引用固定脚本或资料不同文章/项目都能复用
比如我们这个公众号项目里，已经有几个很典型的 Skill 场景。
一个是文章发布。
Markdown 源稿要变成可复制到公众号后台的版本，还要检查图片、段落和发布清单。
一个是去 AI 腔审稿。
每篇文章都要看有没有公式化表达、过度总结、三段式排比。
一个是 Markdown 转 HTML。
文章源稿可以转成网页预览，方便检查结构。
这些工作每次都差不多。
写成 Skill 后，不用每次重新解释。
五、什么时候不要写 Skill
有些事情不适合写 Skill。
比如只做一次的临时要求：
把这篇文章标题改短一点。
这直接用 prompt 就行。
再比如高度不确定的探索：
帮我想几个产品方向。
这种先正常聊天。
等流程稳定下来，再沉淀。
还有一类也别急着写：
需要真实访问外部系统的任务。
如果主要工作是查数据库、读浏览器、访问设计工具，那可能要先考虑 MCP。
Skill 可以描述怎么用这些工具，但它本身不等于工具连接。
六、一个好 Skill 应该写什么
一个好 Skill 不需要很长。
但它要说清楚几件事。
第一，触发条件。
什么时候该用它？
什么时候不该用它？
第二，输入。
它需要什么文件、链接、截图、目标或约束？
第三，流程。
先做什么，后做什么。
第四，输出。
最终交付 Markdown、HTML、检查报告，还是代码修改？
第五，边界。
不要做什么。
不要编造什么。
不要访问什么。
可以先按这个骨架写：
---name: skill-namedescription:Usewhen...---# Skill Name## When to useUsethis skill when...Donotuse it when...## Workflow1.Read the input.2.Check...3.Produce...## OutputReturn...## Safety-Donot...-Ask before ...
这就够开始用了。
七、description 比你想的更重要
description 很短。
但它很要命。
Codex 会根据它判断什么时候该用这个 Skill。
如果你写得太泛：
description:Helpwith writing.
那就很难匹配准确。
因为“写作”太大了。
更好的写法是：
description:PrepareMarkdown drafts forWeChatOfficialAccount publishing, including mobile reading flow,local image placeholders,and publish checklist.
这句话虽然长一点，但范围清楚。
它告诉 Codex：
公众号Markdown手机端阅读图片占位发布清单
这些词就是触发线索。
写 description 时，别追求文采。
写清楚它管什么、不管什么。
八、Skill 可以只有说明，也可以带脚本
很多 Skill 只需要说明。
比如审稿、写作风格、项目检查清单。
这些靠文字规则就够了。
但有些 Skill 适合带脚本。
比如：
批量检查图片路径把Markdown转成发布稿生成图片清单导出 HTML分析固定格式日志
脚本的好处是稳定。
同样的输入，尽量得到同样的输出。
但别什么都写脚本。
脚本越多，维护成本越高。
我的建议是：
先写说明。重复几次后，发现某一步总是机械重复，再抽成脚本。
九、Skill 应该放在哪里
Codex 可以从多个位置读取 Skills。
日常可以先记两个。
个人通用 Skill：
~/.agents/skills
适合放你所有项目都可能用到的能力。
比如：
中文审稿Markdown转 HTML通用发布检查
项目内 Skill：
.agents/skills
适合放只服务当前仓库的能力。
比如这个公众号项目里的：
.agents/skills/humanizer-zh.agents/skills/markdown-to-html
如果一个 Skill 只对这个项目有意义，就放项目里。
如果你想所有项目都能用，就放个人目录。
团队要共享，就提交到仓库。
十、怎么调用 Skill
有两种方式。
第一种，显式调用。
也就是你在 prompt 里直接写：
$humanizer-zh
或者：
用 $markdown-to-html 把这篇Markdown转成 HTML。
这种方式最稳。
你明确告诉 Codex：
这次就用这个 Skill。
第二种，隐式调用。
也就是你不点名 Skill，但任务描述命中了它的 description。
比如你说：
检查这篇公众号文章有没有 AI 腔。
如果 humanizer-zh 的描述写得清楚，Codex 就可能自己选择它。
新手阶段，我建议显式调用。
少一点猜测。
十一、写 Skill 前先用 prompt 跑几次
不要第一次想到流程，就马上写 Skill。
先用普通 prompt 跑几次。
看哪些步骤每次都一样。
比如公众号文章发布，你可能会反复说：
段落要短不要放文末资料堆图片放 assets文章放 articles输出适合公众号手机端阅读检查敏感信息
这些反复出现的要求，就是 Skill 的原材料。
等你发现自己已经懒得再打这些话，就可以沉淀了。
Skill 不是从天上写出来的。
它通常是从重复 prompt 里长出来的。
十二、Skill 写完要测试
Skill 写完不要直接相信它。
至少测试三件事。
第一，能不能触发。
你显式点名 $skill-name，Codex 是否会读取它？
第二，会不会误触发。
一个不相关任务，Codex 是否也错误使用了它？
第三，输出是否稳定。
同一类输入，结果是否大致符合预期？
可以这样测试：
用 $skill-name 处理这篇文章。只说明你会按哪些步骤做，先不要修改文件。
先看步骤。
再让它动手。
这样比较稳。
十三、Skill 不要写成管家
有些 Skill 会越写越大。
最后变成：
写文章排版生成封面转 HTML发布检查Git提交推送远程
看起来省事。
实际很难维护。
更好的方式是拆开：
写作审稿SkillMarkdown转 HTML Skill图片生成Skill发布检查Skill
每个 Skill 管一件事。
需要组合时，在当前任务里组合。
不要让一个 Skill 变成所有工作的入口。
入口太大，失控也快。
十四、Skill 里的安全边界要写清楚
Skill 里一定要写“不做什么”。
比如公众号发布 Skill 可以写：
不要编造截图。不要声称本地图片已经上传到公众号。不要把本地相对路径当成可发布图片。不要输出 API Key、Token、Cookie。
代码审查 Skill 可以写：
优先报告 bug、风险和缺少测试。不要只写总结。不要把风格偏好说成严重问题。
安全边界越具体，Codex 越好执行。
“注意安全”这种话太空。
写清楚具体不能做什么。
十五、什么时候要升级成 Plugin
Skill 适合本地和项目内复用。
Plugin 适合分发。
如果你只是自己用，或者团队在一个仓库里用，Skill 就够了。
如果你想把多个 Skills、MCP 配置、图标、默认配置一起打包给别人安装，那就考虑 Plugin。
可以这样判断：
只沉淀工作流：Skill要打包分发一组能力：Plugin
不要一开始就做 Plugin。
先把 Skill 用顺。
等它真的稳定，再考虑打包。
十六、我的建议路线
如果你第一次做 Codex Skills，可以按这个顺序来：
1.先用 prompt 跑三次2.记录重复步骤3.写一个 instruction-only Skill4.把 description 写具体5.显式调用测试6.改到不误触发7.需要稳定输出时，再加脚本8.团队要共享时，再考虑Plugin
这条路线慢一点。
但不会一上来就陷进配置和打包里。
大多数个人工作流，从一个干净的 SKILL.md 开始就够了。
总结
Codex Skills 解决的不是“怎么让 Codex 多一个按钮”。
它解决的是：
怎么让同一类任务下次还能按同一套方法做。
新手先记住几个判断：
一次性任务，用 prompt当前入口，用Command外部工具，用 MCP定时任务，用Automation可复用流程，用Skill打包分发，用Plugin
写 Skill 时，别一上来就做得很大。
先让它专心做好一件小事。
用一阵子你会发现，省时间的往往不是某个特别厉害的 prompt。
而是把重复劳动一点点沉淀成稳定流程。
