从提示词到 Skills：2026 年大模型实战工作流搭建全指南

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

如果你正在被这些问题困扰：每次跟 AI 聊天都要重新解释一遍需求、换一个对话窗口之前的"调教"全部归零、想把一套固定的工作流程交给 AI 自动执行却发现它每次都跑偏——那你需要的不是更好的提示词，而是 Skills。

Skills（技能）是 2026 年 AI 工具链中最被低估的生产力杠杆。它本质上是一套结构化的"说明书文件夹"，能把你的工作流程固化下来，让 AI 每次按同一个标准干活。本文会从零开始，把 Skills 的底层逻辑、创建方法、优化迭代、安全审查、以及如何把多个 Skills 串成一条完整的自动化工作流全部讲透。不管你用的是 Codex、Claude Code 还是其他支持 Skills 的 AI 编程助手，这套方法论都能直接迁移。

想看完整拆解，往下翻。

一、先搞清楚一个底层问题：Skills 到底是什么

很多人第一次听到"Skills"这个词，脑子里冒出的第一反应是：这不就是一段写好的提示词吗？我把常用的提示词保存到备忘录里，每次复制粘贴不就行了？

这个直觉不算错，但它严重低估了 Skills 的能力边界。Skills 和普通提示词之间的差距，比"备忘录里的模板"和"一个能自动干活的小助手"之间的差距还要大。

1.1 先用一张表把核心区别讲清楚

这张表其实已经把本质说清楚了：Skills 是给 AI 装上的"职业技能证书"。安装之后，AI 不再只是对着你每次现编的提示词去猜你的意图，而是按照一套固定的 SOP（标准操作流程）去执行任务。

1.2 Skills 不是单个文件，而是一个"带说明书的文件夹"

这是新手最容易搞错的地方。很多人以为在某个目录下创建一个 skill.md 就完事了——不，Skills 本质上是一个文件夹，里面至少要有一个 SKILL.md（注意，全大写），但完整的结构是这样的：

my-skill/
├── SKILL.md          ← 核心：描述 + 触发条件 + 执行步骤
├── scripts/          ← 可选：Python/JS 脚本，AI 可以调用执行
├── references/       ← 可选：参考文档、范文、补充材料
└── assets/           ← 可选：静态资源（图片、截图、模板等）

SKILL.md 是整个 Skills 的灵魂。它的内部结构可以拆成三层：

• 第一层：描述（Description）。告诉 AI 这个 Skill 是干什么的、什么时候该触发。比如"当用户不知道写什么、缺乏选题灵感时，调用此技能"。这一层直接决定了 AI 能不能在正确的时机自动激活这个 Skill。
• 第二层：指令（Instructions）。这是 Skill 被触发之后，AI 具体要执行的操作步骤。比如"根据用户提供的主题方向，生成 10 到 15 个简洁的中文标题，禁止使用疑问句，禁止过多解释"。
• 第三层：限制与禁止项。在 Skills 的世界里，告诉 AI"不能做什么"往往比"可以做什么"更能控制输出质量。因为大模型天然是发散的，不加限制它就容易跑偏。

理解了这三层结构，你就已经抓住了 Skills 80% 的核心。剩下的 20% 是怎么写得好、怎么优化、怎么串联——这些后面会逐一展开。

不过在此之前，还有一个更基础的问题需要回答：Skills 的底子到底是什么？答案是——提示词。

二、为什么 2026 年还要学提示词？因为 Skills 的底座就是它

有一种声音说"有了 Skills 就不需要学提示词了"，这话说反了。Skills 本质上就是把"写得很好的提示词"固化成文件。如果你连一段好的提示词都写不出来，那你创建的 Skills 也是半残的。所以，在动手做 Skills 之前，我们有必要把提示词的基本功打扎实。

2.1 2026 年，提示词工程已经彻底变了

如果你对提示词的认知还停留在 2024 年的水平——"角色扮演 + 任务描述 + 输出格式"三段式——那你需要更新一下知识库了。

2024 年主流模型的上下文窗口还在 128K token 左右，到了 2026 年，头部模型的上下文窗口已经普遍突破百万 token 级别，这意味着你可以把整本书、整个代码库、整份项目文档扔进去。但窗口大了不代表你就会用——大多数人根本不知道如何有效利用这个窗口。

更关键的变化在指令方式上。OpenAI 在 2026 年 4 月更新的官方提示词指南中给出了一个明确的信号：减少逐步指令，多定义目标和成功标准，信任模型的自主规划能力。这和两年前"一步步手把手教 AI 做事"的思路完全相反。

我把这个转变总结成下面这张对照表：

这个转变的关键词是：从"指挥"到"委托"。

2.2 CREATE 原则：2026 年写提示词的骨架

IBM 在 2026 年发布的提示工程指南中提出了一个升级版的 CREATE 框架，我个人用下来觉得比市面上大多数模板都实用：

C - Context（背景/角色 + 能力边界）
R - Request（任务指令 + 成功标准）
E - Examples（1-3 个多模态示例）
A - Anti-patterns（明确禁止的行为）
T - Test criteria（验收标准：你怎么判断输出是否合格）
E - Exit condition（终止条件：什么时候 AI 应该停止并询问你）

举个实际例子。假设你要让 AI 帮你写一份内部培训通知，模糊的提示词可能是这样：

"帮我写个培训通知。"

这种提示词扔给任何大模型，出来的东西都大概率是废话连篇的模板。但如果你按 CREATE 原则改写：

Context：你是公司行政人员，面向业务部门同事发布通知。你的能力边界：不要编造培训内容细节，信息不足时提问。
Request：写一份 AI 入门培训通知，包含主题、时间（本周五下午两点）、地点（三楼会议室）、对象（业务部门全体同事）、报名方式。风格正式但不生硬，300 字以内。成功标准：同事看完知道何时、何地、需要准备什么。
Anti-patterns：不要使用感叹号堆砌、不要虚构培训内容、不要添加未经确认的讲师信息。
Test criteria：是否包含全部五个要素？语气是否适合企业内部沟通？
Exit condition：如果缺少关键信息（如培训主题、时间），先提问再动笔。

对比一下两次输出，差距是肉眼可见的。这就是结构化提示词的力量——而这份力量，最终会被我们封装进 Skills 里。

2.3 从模糊到精确：一个真实迭代案例

上个月我在帮一位做电商的朋友处理客户反馈信息。他扔给我一段微信聊天记录，大概长这样：

"客户说下个月想搞个大活动，预算别太高，主要维护老客户，最好有点互动，别太严肃，控制在半天以内。"

这就是现实世界中我们拿到的"需求"——含糊、零碎、充满了"大概""最好""差不多"。如果你直接让 AI 出方案，它当然可以给你编一个看起来很完整的方案——但大概率没法落地执行。

正确的做法不是让 AI 一次生成终稿，而是先让 AI 反问。我的提示词是：

请站在活动策划的角度，针对这段信息列出 6 到 10 个需要确认的关键问题。先不要出方案，先把信息缺口找出来。

AI 返回来一串问题：客户画像是什么？老客户大概多少人？预算的"不高"具体是几千还是几万？有没有场地限制？互动形式偏好线上还是线下？

你看，这些才是真正影响方案能不能落地的核心变量。把这些问题逐一确认之后，再让 AI 出方案——出来的东西就完全不一样了。这个"模糊→反问→补全→生成→验证"的五步法，是所有高质量 AI 输出的底层逻辑，也是我们后面创建 Skills 时最核心的思维模型。

现在，提示词的基本功我们已经有了。接下来，该把战场转移到真正的生产力工具上了——Codex。

三、Codex 入门：先把工具配好，再谈效率

Skills 这套机制并不是某个特定工具的专利。Anthropic 的 Claude Code、OpenAI 的 Codex、甚至一些国产 AI 编程助手都在不同程度上支持了 Skills。在 2026 年的实际体验中，Codex 对 Skills 的支持非常原生——它从底层设计了全局/项目双作用域的 Skills 管理机制，并且通过标准的 SKILL.md 规范与 skills.sh 等社区生态无缝对接。此外，Codex 在 2026 年 6 月推出的 Record & Replay 功能，允许你把一个重复性的操作流程录制下来，Codex 会将其自动转化为一个可编辑、可复用的 Skill——这让创建 Skills 的门槛降到了新低。

所以，在进入 Skills 实操之前，我们先把 Codex 这台"引擎"调校到位。

3.1 Codex 不是聊天框，它是能操作你电脑的 Agent

普通人第一次打开 Codex，第一反应往往是"这不就是个聊天窗口吗"。表面上看确实很像——左边文件夹树，右边对话区——但底层能力差了不止一个量级。

普通聊天工具（不管是 ChatGPT、豆包、Kimi 还是 DeepSeek）的工作模式是"你问，我答，答完就完了"。它给你的是一段文字，你用不用、怎么用，是你自己的事。

Codex 不一样。它能读你电脑上的文件、能创建和修改文件、能执行命令行操作、能安装依赖——说白了，它不仅给你答案，它直接帮你把活干了。这是一条从"顾问"到"助理"的质变线。

我自己折腾下来的体会是：Codex 最适合的不是"一次性