夜雨聆风本文是关于 AI 编程的第 3 篇文章。
在 《零编程基础，手把手教你用 AI 做一个能用的 App》 一文中，大家已经初步练习了提示词的写法；
在 《AI 编程水平的高下，取决于清晰表达意图的能力》中，进一步谈了如何用结构化方法来向 AI 清晰表达用户意图，这是 AI 的进阶应用。
假设大家都会写提示词，有了通过写提示词让 AI 解决问题的成功经验。现在来看看怎样通过开发和复用 Skill，来避免在日常的重复性工作中，一遍遍地为 AI 重复写提示词。
从 Prompt 到 Skill
Prompt 是一次性指令。它可以很短，也可以很长，但它通常只服务当前这一次交互。
在 OpenAI Help Center 的资料中，把 Skills 描述为可复用、可共享的工作流。它不只告诉大模型要“做什么”，还要告诉它：
什么时候应该使用这套流程。 用户必须提供哪些输入。 哪些信息可以合理推断，哪些必须追问。 主要流程的执行步骤是什么。 可以调用哪些参考资料、脚本或资产。 输出格式有什么规定。 什么结果算通过，什么结果必须返工。
下表列出了它们的主要差异：
本文从一个更工程化的视角来看 Skill，即：Skill 是给大模型执行的程序规格。传统程序把指令写给计算机执行，Skill 是写给模型执行和遵守的工作流、约束、资源和验收标准。所有写 Skill 的第一步，是把它当成一个需要设计的工程产物。
把 Skill 看成给大模型执行的程序
下面是一个实用的 Skill 模型：
Skill = Trigger + Input Contract + Workflow + Constraints + Output Contract + Acceptance Tests如果你熟悉传统软件开发，那么把这个模型映射到软件开发，会看得非常直观：
namedescription，帮助模型判断何时使用 | |
references/scripts/、assets/ 等资源 | |
这里的“入口”不是传统程序里的严格 dispatch。Skill 是否触发，通常取决于模型对描述、当前任务和上下文的判断；你可以通过清晰的 description 提高命中率，但不能保证它会像函数调用那样百分百被触发。
也有些任务不适合写成 Skill。一次性探索、临时事实查询、目标还没有稳定形态的头脑风暴、强依赖实时外部状态但没有可靠工具链的任务、需要法律/医疗/金融等高风险判断且无法建立审核流程的任务，都不应该急着 Skill 化。
Skill Creator 像程序员，但人要负责写好需求规格
OpenAI Help Center 的 Skills in ChatGPT 资料提到，当你要求 ChatGPT 创建或修改 Skill 时，它会使用 skill-creator 来帮助生成、更新或排查。其实 Skill Creator 本身也是一个 Skill，它是可以帮助你写 Skill 的 Skill。
这里很容易产生误解。很多人会以为，既然有 Skill Creator，我只要说“帮我做一个厉害的写作 Skill”就够了。但这样生成出来的东西，质量肯定不会太高，因为你的输入本身就只是一个泛泛而谈的需求。
Skill Creator 更像脚手架生成器，它可以帮你组织结构、补充缺口、生成初版文件，但它不能替你决定以下事情：
这个 Skill 到底服务谁。 哪些任务应该触发它，哪些不应该。 哪些输入缺失时必须追问。 什么输出算好。 遇到事实不确定时该怎么处理。 哪些事情需要用户确认。 怎么证明这个 Skill 已经可用。
这些都属于“规格”。人不是可被 Skill Creator 替代的人，而是要负责写这些规格的人。你写得越像需求规格，Skill Creator 生成出来的 Skill 就会越接近可用。
下面仍以软件开发作为类比，看看如何在 Skill 开发中进行更好的分工：
SKILL.md | |
一个小样例：会议纪要 Skill
给 Skill Creator 的规格可以这样写：
目标：把会议转写稿整理成可执行纪要。使用场景：项目例会、需求评审、事故复盘后的文字转写整理。不适用场景：没有会议内容、只要求润色文字、需要法律留痕的正式会议记录。输入：会议转写稿；可选参会人名单、项目背景、公司行动项模板。缺失处理：缺负责人、截止时间、决策依据时标记“待确认”，不得编造。流程：1. 提取议题。2. 区分事实、讨论意见、已决策事项、待确认事项。3. 生成行动项表格。4. 列出风险和阻塞。5. 输出待确认问题。输出：摘要、决策、行动项、风险、待确认问题。质量门：不能把讨论意见写成已决策事项；所有缺失信息必须显式标注。验收样例：给一段没有负责人和截止时间的转写稿，输出中必须出现“待确认”，不得补造人名和日期。然后，把上述规格交给 Skill Creator ：
请根据下面的规格创建一个 Skill：<粘贴上面的规格>要求：- 优先生成简洁的 SKILL.md；- 如需长模板，放到 references/；- 不要把示例中的人名、日期当成默认值；- 生成后请列出 3 个验收样例。像测试软件那样测试 Skill
拿到 Skill Creator 生成的初版后，要自己读一遍，建议按如下清单检查：
description是否说清触发和不触发； 缺失信息是否会标记“待确认”； 是否按要求输出； 是否禁止自动编造负责人和日期。
人工读完之后，要像测试软件一样去测试 Skill，不能只看一次输出，就凭是否顺眼来决定是否接受这个 Skill。
测试用例可以用 Given-When-Then 的形式来设计，例如：
给定：用户提供一份会议转写稿，但没有明确负责人和截止时间。当：用户请求生成项目行动项。则：Skill 应输出任务、上下文、待确认负责人、待确认截止时间；不得编造负责人或日期。测试时不要追求每次输出完全一致。大模型不是传统函数，不适合用逐字相等来验收。更合理的做法是检查关键行为、输出字段、边界处理和禁止事项是否稳定：
是否正确触发。 是否遵守输入边界。 是否走关键流程。 是否在不确定时追问或标注假设。 是否按约定格式输出。 是否避免了明确禁止的行为。 是否在多次运行中保持同等结构质量。
结语：从简单提问到设计工作系统
AI 的基础用法，是把 AI 当回答机器。你问一次，它答一次。
AI 的进阶用法，是学会在 prompt 中把自己的意图写清楚，让 AI 知道任务的上下文、约束、输出要求、验收标准和禁忌事项。
AI 的系统化用法，是把自己的工作方法写成一个可复用的执行规格，把隐性经验沉淀为 Skill。Skill Creator 可以帮你写 Skill，但它需要你先写清楚规格。