全文摘要
如果你只是偶尔让 AI 帮忙，提示词就够了。但只要一个需求会反复出现，比如每周规划、固定检查、资料整理、代码审查，它就不该永远停留在一段临时提示词里。
这篇文章用 “北京周末遛娃推荐” 这个小例子，拆一次生产级 Skill 的创建过程：为什么直接提示词适合打草稿，却很难长期复用；一个稳定可用的 skill，需要怎么处理触发、动态信息、输出标准、目录分层和质量检查。
使用的 Agent：Codex。文中例子以 Codex 为主，但方法不只适用于 Codex。不同产品可能叫 Skill、Agent、Command 或 Workflow，本质都是把反复出现的 AI 任务沉淀成稳定入口。
文中提到的 skill 来源和安装命令，放在文末。
最近我在想一个很具体的小需求：能不能做一个 “北京周末遛娃推荐 skill”。
每到周五，我只要说一句 “这周末带娃去哪玩”，它就能根据周六、周日的天气、我大概住在哪个区、孩子年龄、预算、出行半径，给出几个适合亲子出行的方案。最好还要区分室内室外，提醒预约、闭馆、交通压力和备选路线。
第一反应很自然：让 AI 直接写一个 SKILL.md 不就行了吗？
真往下想，就会发现这里面有不少坑。天气是动态的，场馆开放状态是动态的，孩子年龄会影响路线强度，当前位置不能要求用户给精确住址，输出结构也不能每次飘。更麻烦的是，如果我把一堆景点资料硬塞进 skill，过一段时间就会过时。
我这里说的 “生产级 Skill”，不是非要做成企业平台，也不是把个人工具复杂化。它至少要做到三件事：触发稳定、边界清楚、结果可检查。否则它只是换了一个文件名的长提示词。
直接提示词可以创建 skill 草稿，但不适合作为生产级 Skill 的默认创建方式。更准确的说法不是 “不能用提示词创建 skill”，而是 “不要只靠提示词创建生产级 Skill”。
这也是我觉得每个 AI 使用者都应该学一点 skill 创建的原因。不是为了人人都变成工具作者，而是为了识别哪些工作值得沉淀，哪些东西不能继续靠 “下次再复制一段提示词” 解决。
一、草稿和生产级 Skill 的区别
三句话速览
① 反复出现的 AI 任务，不应该永远靠临时提示词解决。
② 直接提示词适合草稿和试错，生产级 Skill 还要补上触发、边界、结构和验收。
③ 更稳的路径是：先问路，再澄清，再用 $skill-creator 建结构，最后用 $writing-great-skills 查质量。
二、直接提示词不是错，它适合试错
我不太赞成一上来就说 “不能用提示词创建 skill”。这个说法太绝对。
如果你只是想快速验证一个想法，比如：
- 这个工作流有没有必要沉淀成 skill；
- 这个 skill 大概应该叫什么；
- 用户会用什么话触发它；
- 输出大概长什么样；
- 有没有必要拆 references 或 scripts。
- 那直接提示词非常合适。
比如你可以直接说：
帮我创建一个 skill，用来根据北京周末天气推荐亲子出游地点。
模型大概率能给你一版 SKILL.md。它可能还能写出目标、步骤、输出格式，看起来已经像那么回事了。
这种方式的优点很明显：快、轻、不需要想太多工程结构。适合做草稿，适合一次性个人实验，也适合你还没有想清楚需求时先把想法摊开。
但它的问题也在这里：它很容易让你误以为 “生成了一个文件” 就等于 “创建了一个长期可用的 skill”。
三、生产级 Skill 麻烦的地方，不是写出来
生产级 Skill 的难点不在于让 AI 写几段步骤，而在于它以后能不能稳定工作。
我一般会看几个问题。
第一，description 能不能稳定触发？
一个 model-invoked skill 的 description 不是普通简介，它是触发入口。你希望用户说 “北京周末遛娃”“亲子游推荐”“这周末带孩子去哪玩” 时，Codex 能想起这个 skill，那这些触发语就应该体现在 description 里。反过来，如果 description 写成一段漂亮但模糊的说明，就可能每次都靠运气触发。
第二，动态信息有没有被写死？
像北京周末出游这种需求，天气、闭园、展览、预约、票务、交通管制都可能变化。skill 里应该沉淀的是 “查询和判断流程”，不是把一堆景点百科写进去。否则它今天看起来很完整，下个月就可能变成错误信息的来源。
第三，输出有没有稳定的完成标准？
推荐地点不等于完成任务。对一个亲子出游 skill 来说，更合理的输出应该至少包含：周六周日天气判断、最推荐方案、备选方案、适合年龄、通勤压力、预约提醒、避坑提醒、出行前检查清单。否则每次输出都可能变成一串地点列表。
第四，内容有没有分层？
有些东西应该留在 SKILL.md，比如核心流程、输入输出、完成标准。有些东西应该放到 references/，比如天气分流规则、亲子地点评分标准、输出模板。还有些重复计算或稳定操作，必要时可以放到 scripts/。如果所有东西都塞进一个长文件，skill 很快会变成另一个难维护的提示词。
这就是直接提示词创建生产级 Skill 的主要风险：它能生成内容，但不一定帮你设计触发、边界、资源分层和验证。
四、推荐 4 步创建生产级 Skill
我的建议不是把流程搞复杂，而是给生产级 Skill 留四个检查点：先问路，再澄清，再创建，最后检查。
第一步：先用 $ask-matt 问 “该怎么问”
$ask-matt
我想创建一个 skill：北京周末遛娃推荐。
我期望通过：
1. $grill-with-docs 澄清 skill 需求；
2. $skill-creator 开发 skill；
3. $writing-great-skills 做 skill 质量检查。
请帮我判断这个流程是否合适，并给出一段可以直接复制给 Codex 的创建提示词。
这个输入的产出，不是一个 skill，而是一段更完整的创建请求：先确认是否需要 $grill-with-docs，再把目标、触发场景、使用例子、资源目录、完成标准和验证方式写进同一段 prompt。
这一步的意义是先把 “我要怎么问” 问清楚。很多 skill 做坏，不是因为 Codex 不会写，而是因为一开始的创建请求太散。
第二步：需求复杂时，用 $grill-with-docs 澄清边界
如果 skill 和代码库、团队流程、领域术语有关，先澄清很有价值。
在 “北京周末遛娃” 这个例子里，我把澄清后的边界压成几句话：不问精确住址，只问行政区、商圈或地铁站附近；没有孩子年龄时默认 3-8 岁并说明假设；所有天气、开闭馆、预约、票务、交通状态都必须确认，不能编造。
这些不是文案细节，而是生产级 Skill 的边界。边界没说清，后面目录再完整，也只是把不稳定包装得更漂亮。
第三步：用 $skill-creator 生成结构
直接提示词版输入
帮我创建一个 skill，用来根据北京周末天气推荐亲子出游地点。
输出目录
case-study/direct-prompt-weekend-family/
└── SKILL.md
这份 SKILL.md 只有 18 行。它能说明 “推荐亲子活动” 这件事，但没有触发语设计、没有实时信息边界、没有 references，也没有固定输出验收。
推荐流程版输入
$skill-creator $writing-great-skills
请创建一个新的 Codex skill：weekend-family。
目标：北京周末亲子出游规划。
触发：周末遛娃、带娃去哪玩、亲子周末计划。
要求：按天气、孩子年龄、粗略位置、预算、预约状态和疲劳程度生成可执行方案。
资源：把天气分流、地点评分、输出模板放到 references/。
完成标准：输出周末判断、最推荐方案、周六方案、周日方案、备选清单、出行前检查、未确认信息。
输出目录
case-study/recommended-weekend-family/
├── SKILL.md
├── agents/openai.yaml
├── assets/.gitkeep
└── references/
├── output-template.md
├── venue-scoring.md
└── weather-routing.md
这就不是 “多几个文件” 而已。SKILL.md 负责入口和流程，references/ 负责天气分流、地点评分和输出模板，agents/ 负责界面侧展示，assets/ 预留输出资源位置。
第四步：用 $writing-great-skills 做质量检查
我对两份样例做了一个很直接的检查。
我也尝试运行 quick_validate.py。脚本存在，但当前 Python 环境缺少 yaml 模块，所以这一步没有通过工具跑完。这个结果反而提醒我：生产级 Skill 不只是写目录，还要保证验证环境本身可用。
总结
我现在更愿意把 skill 看成一种工作流资产，而不是一段高级提示词。
提示词当然有用。很多 skill 的第一版，也应该从提示词草稿开始。问题在于，草稿一旦要长期使用，就要补上工程化的部分：需求边界、触发设计、结构化目录、质量标准和验证。
可以这么判断：
如果只是试想法，直接提示词就够了。
如果准备长期使用，就不要只靠提示词。先用 $ask-matt 把创建请求问清楚，再用 $grill-with-docs 澄清边界，用 $skill-creator 建结构，最后用 $writing-great-skills 做质量检查。
能生成，不等于能复用。生产级 Skill 真正要解决的，是下一次、下下次、换一个上下文之后，它还能不能带着你走同一条靠谱的路。
文中提到的 skill 来源和安装
本文使用的 Agent 是 Codex。文中主要提到这些 skill：
ask-matt、grill-with-docs、writing-great-skills：本机安装记录显示来源为 mattpocock/skills，仓库地址是 https://github.com/mattpocock/skills.git。
skill-creator：Codex 自带的系统 skill，通常不需要单独安装。如果你不是 Codex 用户，也可以看看自己使用的大模型产品是否提供官方的 skill 创建工具；比如国产产品 CodeBuddy Code 里就有 /add-skill，可以通过交互式引导收集 skill 信息，并自动生成规范的 SKILL.md。
如果你的环境已经安装 Skills CLI，可以按下面方式安装公开来源的几个 skill：
npx skills add mattpocock/skills@ask-matt -g -y
npx skills add mattpocock/skills@grill-with-docs -g -y
npx skills add mattpocock/skills@writing-great-skills -g -y
如果缺少 skill-creator，优先检查 Codex 是否已更新到支持 Skills 的版本；它属于 Codex 的系统 skill，不建议当成普通第三方 skill 手动复制。