别再重复写提示词了！我用 Skill 把 AI 训练成自己的专属助手

今天让它写一篇文章，明天让它改一段代码，后天让它总结一场会议。每一次都要重新解释背景、要求、格式、标准和禁忌。结果是：模型很强，你却每次都在从零指挥。

真正会用 AI 的人，不只是会写提示词，而是把自己的经验、流程和标准，封装成可以反复调用的 Skill。

一句话区分：

普通提示词是临时吩咐：“帮我把这篇文章改好一点。” Skill 是标准操作流程：先判断读者，再梳理逻辑，再优化表达，再检查是否改变原意，最后按固定格式输出。

一个是临时沟通，一个是能力沉淀。这篇文章要做的，就是带你从“AI 使用者”升级为“AI 能力设计者”。

一、Skill 到底是什么

Skill 的本质并不神秘：

Skill = 指令 + 流程 + 示例 + 质量标准 + 失败处理 +（可选）工具与代码

在 ChatGPT 的官方语境里，Skill 是可复用、可共享的工作流，用来告诉模型如何更一致地完成某类任务，可以包含指令、示例和代码。创建并安装后，模型会在有帮助时自动调用一个或多个 Skill。

在 Codex 里，Skill 有明确的编写规范：一个 Skill 就是一个包含 SKILL.md 的目录，可选包含 scripts/、references/、assets/ 等资源，其中 SKILL.md 必须写明 name 和 description。

所以你可以这样理解：Skill 就是把你脑子里“这件事该怎么做”的方法，写成 AI 能稳定执行的说明书。

二、为什么普通提示词不够

普通提示词最大的问题不是“不够长”，而是不稳定。

你输入：

帮我优化这篇文章。

AI 可能会改成营销腔、悄悄改变原意、省略关键细节、每次输出格式都不一样，信息不足时还会编造。

原因很简单：你只说了“做什么”，没有说先做什么、后做什么、什么不能做、什么算好、不确定时怎么办、输出该长什么样。

高手用 AI，不是让它自由发挥，而是让它按自己的工作方法稳定执行。

三、什么任务值得做成 Skill

不是所有任务都要 Skill 化。用这 5 个问题自查，命中 3 条以上就值得做。

Codex 的最佳实践也是同一个思路：当一个工作流开始重复出现，就不该继续靠长提示词和反复沟通，而应该用 Skill 把说明、上下文和支持逻辑封装起来，而且每个 Skill 只聚焦一个清晰任务。

典型可 Skill 化的任务：写周报、改文章、总结会议、分析报错、代码 Review、生成测试用例、整理学习笔记、写需求文档、检查提示词质量。

四、最小可用 Skill 结构

不要一开始就追求复杂。先记住这个骨架：

--- name: skill-name description: 这个 Skill 什么时候使用，什么时候不要使用。 --- ## 目标 这个 Skill 要完成什么任务。 ## 输入 用户需要提供哪些信息。 ## 执行步骤 1. 第一步做什么 2. 第二步做什么 3. 第三步做什么 ## 输出格式 最终结果应该怎么呈现。 ## 质量标准 什么结果算合格。 ## 失败处理 信息不足、目标冲突、不确定或工具不可用时怎么办。

如果只记一句话，就记这句：好 Skill 不只告诉 AI 做什么，还告诉它怎么做、怎么判断做得好不好、做不了时怎么办。

五、你的第一个 Skill：文章润色

原来的提示词：

帮我把这篇文章改得更通顺，小白能看懂，不要改变原意。

升级成 Skill：

--- name: article-polisher description: 当用户需要润色、改写、优化文章、公众号稿、博客稿、说明文时使用。不要用于翻译、写代码或从零生成全新选题。 --- # 文章润色 Skill ## 目标 把用户提供的文章改得更清楚、更自然、更适合目标读者阅读，同时保留原意。 ## 输入 用户可能提供： 1. 原文 2. 目标读者 3. 希望语气 4. 是否保留原结构 5. 是否需要压缩或扩写 如果用户没有说明目标读者，默认面向新手读者。 ## 执行步骤 1. 先判断原文的核心观点。 2. 找出表达不清、逻辑跳跃、重复啰嗦、术语过多的地方。 3. 在不改变原意的前提下重写。 4. 优化标题、小标题和段落衔接。 5. 检查是否有过度营销、空话、AI 味表达。 6. 输出优化后文章和修改说明。 ## 输出格式 1. 优化后文章 2. 主要修改点 3. 下一步优化建议 ## 质量标准 - 不改变原意 - 语言自然，句子可读出声 - 新手能看懂 - 结构比原文更清晰 - 不使用夸张营销腔 - 不编造原文没有的信息 ## 失败处理 如果原文太短或信息不足： 1. 先基于现有内容给出最小可用优化版本。 2. 明确列出还需要补充的信息。 3. 不自行编造事实。

它强过普通提示词，不是因为更长，而是因为多了 5 样东西：输入要求、执行步骤、输出格式、质量标准、失败处理。这 5 项就是稳定性的来源。

六、核心心法：把“经验”变成“流程”

很多人以为 Skill 是提示词模板。不是。

模板固定的是说法，Skill 固定的是做法。

真正值钱的 Skill，写进去的是你的判断经验。比如你改文章的经验可能是：

• 不能先改句子，要先看结构；

• 不追求华丽，优先保留原意；

• 面向新手时少用术语；

• 改完要说明改了什么；

• 信息不足时不补事实。

这些经验不写进 Skill，AI 每次都会忘；写进去，它就变成可复用能力。

Skill 的本质：把人的经验流程化，把流程标准化，把标准交给 AI 执行。

七、从 0 到 1：七步法

1. 找一个重复任务 不要做“大而全”。选一个最近一周至少做过 3 次的小任务：写周报、改文章、分析报错、写短视频脚本、总结学习内容。

2. 写出你现在的普通提示词 请帮我总结下面这段内容，提炼重点、行动项和后续问题。 这就是 Skill 的种子。所有 Skill 都从一句普通提示词开始。

3. 拆出稳定流程（最关键的一步） 问自己 6 个问题：AI 第一步该判断什么？第二步该处理什么？第三步该检查什么？输出长什么样？什么结果算好？信息不足或内容混乱时怎么办？ Skill 不是“把提示词写长”，而是“把流程写清楚”。

4. 写成 SKILL.md 直接套用第四节的骨架，先把七个小节填满。

5. 设计 3 个测试用例

测试的目的不是证明 Skill 完美，而是找出它在哪里不稳定。 6. 按失败结果迭代，每轮只修一个问题

• 经常跑偏 → 改 description 和“不要用于”；

• 输出格式乱 → 强化“输出格式”；

• 信息不足时编造 → 强化“失败处理”；

• 质量不稳 → 补“质量标准”和反例。

7. 沉淀到 Skill 库 连续通过三类测试后入库。第一批 Skill 库建议：学习总结、文章润色、提示词优化、报错分析、代码 Review、周报生成、会议纪要、项目拆解。

从这一刻起，你不再每次重写提示词，而是在积累 AI 能力资产。

八、进阶：让 Skill 生产 Skill（递归）

递归的意思是：一种能力可以调用同类能力，甚至用自己改进自己。放到 Skill 上就是——用 Skill 创建 Skill、检查 Skill、重构 Skill、编排 Skill。

第一层：Skill Builder（生成）

--- name: skill-builder description: 当用户想把重复任务、提示词、SOP、工作流或经验流程封装成 Skill 时使用。不要用于直接执行原任务。 --- # Skill 生成器 ## 目标 把用户描述的重复任务，转化为结构完整、可测试、可迭代的 Skill。 ## 输入 1. 任务名称 2. 使用场景 3. 当前提示词 4. 输入材料 5. 期望输出 6. 常见失败情况 7. 成功标准 ## 执行步骤 1. 判断这个任务是否适合做成 Skill。 2. 如不适合，说明原因，并建议改为普通提示词、Workflow 或 Agent。 3. 如适合，提炼目标、触发条件、输入、步骤、输出和质量标准。 4. 生成完整 SKILL.md。 5. 设计正常、边缘、压力三类测试用例。 6. 给出下一版优化方向。 ## 输出格式 1. 是否适合做 Skill 2. Skill 设计说明 3. 完整 SKILL.md 4. 测试用例 5. 优化建议 ## 质量标准 - 只聚焦一个任务 - 输入输出清晰 - 步骤可执行 - 质量标准可判断 - 失败处理具体 - 测试用例能暴露问题

第二层：Skill Reviewer（评审）

生成不等于好用。常见毛病是：description 模糊、一个 Skill 想做太多事、输入要求不清、输出格式不稳、没有失败处理、没有测试、质量标准无法判断。

--- name: skill-reviewer description: 当用户提交 Skill 草稿，需要检查质量、可执行性、触发可靠性和可复用性时使用。不要用于从零生成新 Skill。 --- # Skill 评审官 ## 目标 评审一个 Skill 草稿，指出问题，并给出优化后版本。 ## 评分标准（满分 100） 1. 使用场景清晰度：15 2. 输入输出定义：20 3. 执行步骤完整度：20 4. 质量标准：15 5. 失败处理：15 6. 示例与测试质量：10 7. 可复用性：5 ## 执行步骤 1. 判断 Skill 类型。 2. 判断任务是否适合做成 Skill。 3. 按评分标准打分。 4. 找出最多 3 个主要问题。 5. 给出修改建议。 6. 输出优化后的 Skill。 7. 给出测试用例。 ## 输出格式 1. 总分 2. 当前等级：未完成 / 可用 / 良好 / 优秀 / 可交付 3. 做得好的地方 4. 主要问题（最多 3 个） 5. 修改建议 6. 优化后 Skill 7. 测试用例 8. 是否通过

第三层：Skill Refactorer（重构）

Skill 变多后会出现重复、过大、边界冲突。比如一个“内容生产 Skill”同时管选题、调研、大纲、初稿、润色、事实核验、发布计划——它太大了，应该拆成：topic-research、outline-builder、article-writer、article-polisher、fact-checker、publish-planner。

原则：一个 Skill 只做一个稳定动作，多个 Skill 串起来才是 Workflow。

第四层：Skill Orchestrator（编排）

它负责判断：该调用哪个 Skill、需要几个串联、哪些可以并行、哪些结果要复查、失败后回退到哪一步。

写一篇深度文章的编排：topic-research → outline-builder → article-writer → article-polisher → fact-checker → publish-planner。

到这里你已经从 Skill 进入 Workflow；再加上目标规划、工具调用、记忆和失败回退，就进入 Agent 系统。

元 Skill：大师级的核心

普通人积累提示词，高手积累 Skill，大师积累元 Skill——因为元 Skill 会持续生产、评审和升级你的整个 Skill 库。

九、Skill、Workflow、Agent 的分层

打个比方：Skill 是积木，Workflow 是流水线，Agent 是会调度流水线的项目经理。

正确顺序是 Prompt → Skill → Workflow → Agent。没有稳定 Skill 的 Agent，只是一个更容易跑偏的聊天机器人。

十、工程化：Skill + Codex

写作、总结、办公类 Skill 可以是纯文本。但涉及编程、自动化、代码审查、测试生成、项目交付时，就该配合 Codex。

Codex Skills 可在 Codex CLI、IDE 扩展和 Codex app 中使用，既能显式调用，也能由模型根据 description 隐式选择。这让 Skill 从“让 AI 回答更好”变成“让 AI 做项目”：自动代码 Review、报错分析、生成测试、写 README、整理发布说明、制定迁移计划、日志与事故摘要。

关键机制：渐进式加载（progressive disclosure）

Codex 一开始只用 Skill 的 name、description 和文件路径来发现 Skill；决定使用后才加载完整 SKILL.md；需要时才读取 references/ 或运行 scripts/。

结论：description 决定你的 Skill 能不能被正确发现，它不是随手写的一句话。

# 差：太泛，无法判断何时触发 description: 帮助用户处理代码问题。 # 好：任务类型 + 触发词 + 边界 description: 当用户需要审查代码 diff、检查 PR 风险、发现 bug、边界问题、安全隐患和测试缺口时使用。不要用于直接实现新功能。

好的 description = 搜索关键词 + 使用场景 + 不适用场景。

可直接用的 Codex 代码 Review Skill：

--- name: code-reviewer description: 当用户要求检查代码、审查 PR、分析代码 diff、发现 bug、检查边界情况、评估可维护性或测试缺口时使用。不要用于直接实现新功能。 --- # 代码 Review Skill ## 目标 对代码变更进行结构化 Review，发现功能问题、边界问题、错误处理缺口、安全风险、可维护性问题和测试不足。 ## 输入 1. 代码 diff 2. 文件路径 3. 需求说明 4. 测试结果 5. 报错信息 6. 相关上下文 信息不足时，先基于现有内容做最小可用 Review，并列出缺失信息。 ## 执行步骤 1. 理解本次变更的目标。 2. 检查是否满足需求。 3. 检查潜在 bug 和边界情况。 4. 检查错误处理是否完整。 5. 检查安全风险。 6. 检查命名、结构和可维护性。 7. 检查测试覆盖是否足够。 8. 按风险优先级输出问题。 9. 给出可直接交给 Codex 执行的修复提示词。 ## 输出格式 1. 总体结论 2. 高风险问题 3. 中低风险问题 4. 测试建议 5. 可直接执行的修复提示词 6. 是否建议合并 ## 质量标准 - 不只评价代码风格，要找真实风险 - 每个问题必须说明影响 - 修改建议要具体 - 不确定时明确说明 - 不编造不存在的代码上下文 - 不建议无关的大规模重构 ## 失败处理 缺少上下文时： 1. 列出缺失的文件或信息。 2. 给出基于现有代码的初步结论。 3. 不做无法验证的断言。

想让它更稳定，可以在 scripts/ 里加测试脚本、lint 或静态检查——Skill 可以包含可执行代码、参考文档和模板资源，只在需要时读取或运行。

五种组合方式

适合自动化的任务：每天检查日志异常、每周生成项目进展、每次 PR 更新后 Review、每晚检查依赖风险、部署后定时巡检。

十一、能力地图：你在第几层

十二、最容易犯的 10 个错误

Skill 是练出来的，不是一次写完就完美的。

十三、今天就做的行动任务

别再看更多概念，做这一个练习。选一个你最近做过 3 次以上的任务，先填空：

任务名称： 我为什么经常做这个任务： 我现在通常给 AI 的提示词： 输入材料一般是什么： 我希望输出什么： 我最不满意 AI 的地方： 这个任务成功的标准： 信息不足时 AI 应该怎么做：

再改写成结构：

--- name: description: --- ## 目标 ## 输入 ## 执行步骤 ## 输出格式 ## 质量标准 ## 失败处理 ## 测试用例 ### 正常场景 ### 边缘场景 ### 压力场景

完成后你就有了第一个真正属于自己的 Skill。接着做两件事：写一个 Skill Builder 帮你把更多重复任务 Skill 化，再写一个 Skill Reviewer 帮你检查质量。

当你能做到“自己做 Skill → 用 Skill 生成 Skill → 用 Skill 检查 Skill”，你就进入 Skill 架构师阶段了。

附：大师级 Skill 完整模板

新手只写前 7 节；进阶补示例、测试与迭代记录；工程化再考虑 scripts/、references/、MCP 和 Automations.

--- name: description: <解决什么任务、什么时候触发、什么时候不要使用> --- # ## 1. 使用场景 当用户需要……时使用。 不要用于：…… ## 2. 目标 ## 3. 输入格式 用户可能提供：…… 缺少关键信息时：先完成最小可用版本、列出缺失信息、不编造事实。 ## 4. 执行步骤 1. 理解任务目标 2. 检查输入完整性 3. 拆解任务 4. 执行核心处理 5. 按质量标准自检 6. 输出结果 7. 给出下一步建议 ## 5. 输出格式 ## 6. 质量标准 ## 7. 失败处理 - 信息不足： - 目标冲突： - 不确定事实： - 工具不可用： - 输入过长： ## 8. 示例输入 ## 9. 示例输出 ## 10. 测试用例 ### 正常场景 ### 边缘场景 ### 压力场景 ## 11. 迭代记录 - v0.1 最小可用版本 - v0.2 增加失败处理 - v0.3 增加测试用例 - v0.4 接入脚本、MCP 或自动化

结语

Skill 的本质不是提示词技巧，而是能力封装。它让你从“每次重新沟通”，变成“长期沉淀能力”。

记住这条路线：

重复任务 → 提示词 → Skill → 测试 → Skill 库 → 元 Skill → Workflow → Agent → 自动化系统

你不需要一开始就复杂。从一个最小 Skill 开始，测试它、改进它、复用它，再让它帮你生产更多 Skill。

这就是从小白到 Skill 大师的真正路径。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～