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

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

如果你正在被这些问题困扰：每次跟 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 最适合的不是"一次性的问答"，而是"需要产出文件的完整任务"。比如写一份通知并保存成 Markdown、整理一段会议纪要并输出结构化文档、读取你的项目代码然后帮你修 Bug——这些场景下，Codex 的效率甩普通聊天工具好几条街。

3.2 四个必须搞懂的配置

打开 Codex，你会看到一堆设置选项。对于新手来说，不用全部搞懂——但下面这四个，直接影响你的使用体验和产出质量：

（1）模型选择：决定"谁来干活"

2026 年的 Codex 支持多个底层模型，从 GPT-5.5（OpenAI 旗舰）到 Claude Opus 4.7，再到一些轻量级的快速模型。选择逻辑很简单：

（2）推理深度：决定"想多远"

Codex 提供了低、中、高、超高四档推理深度。这不是简单的"越高越好"——推理深度越高，消耗的 token 就越多，响应也越慢。日常写作和代码补全用"高"就足够了；只有遇到需要多步推理、交叉验证的复杂问题时，才值得开"超高"。

一个实用技巧：如果你想让 Codex 快速跑一个简单任务（比如格式化一段 JSON），把推理深度调到"低"会快很多，而且质量差距不大。

（3）额度管理：别做到一半卡住

Codex 的额度有两层限制：五小时限额 + 一周总限额。如果你一天内密集使用，很容易在下午三四点就触发五小时限制。我的做法是：把重要任务排在使用额度重置之后的时间段，比如凌晨三点额度重置后，上午八点到十点做高价值任务，下午穿插做一些不需要 AI 的整理工作。

（4）权限控制：新手必选默认权限

Codex 有三档权限：默认权限（任何涉及文件操作的行为都会弹窗询问你）、自动审查（AI 自己判断安全风险，低风险自动放行）、完全访问（AI 拥有全部权限，不会询问）。

除非你已经非常熟悉 Codex 的行为模式，否则坚定不移地用默认权限。这不是保守，是必要的安全边界。我就见过有朋友开了完全访问，AI 在调试过程中不小心覆盖了一个重要配置文件——虽然能从 Git 恢复，但那半小时的心跳加速是真的不值当。

3.3 用 Codex 跑通第一次对话

配置搞定之后，先别急着创建 Skills。跑一次最简单的对话，感受一下 Codex 和普通聊天工具的差异：

在 Codex 中输入：

帮我总结一下今天全球 AI 领域最重要的三条新闻，保存为 news-summary.md

你会发现，Codex 不仅给了你新闻摘要，还在你的项目目录下真的创建了一个 news-summary.md 文件。这就是它和普通聊天工具的根本区别——它能"落地"。

如果这一步跑通了，恭喜你，基础设施已经就绪。下面我们正式进入 Skills 的世界。

四、动手创建你的第一个 Skill：从对话到数字资产

理论讲够了，这一章我们直接上手。我会用最直观的方式——从一段你日常工作中反复出现的 AI 对话开始，把它抽取成一个可复用的 Skill。

4.1 识别"值得变成 Skill"的任务

不是所有的工作都适合变成 Skill。一个任务值不值得 Skill 化，看三个标准：

• 重复频率高：每周至少做 2 到 3 次，或者虽然频率不高但每次的步骤完全相同。
• 输入输出结构固定：输入的内容会变（比如每次的主题不同），但处理的流程和输出的格式是不变的。
• 有明确的质量标准：你知道"好的输出"长什么样，能用几句话描述清楚。

举个例子：如果你是一个做自媒体的创作者，每次写文章之前都要让 AI 帮你头脑风暴选题——这就是一个绝佳的 Skill 化候选。输入是"一个大致的方向"，输出是"10 到 15 个简洁的标题"，流程每次都一样：你给方向，AI 出标题，你筛选。

4.2 方法一：从现有对话中抽取（最推荐新手用）

这是最省力的方式。具体操作是这样的：

第一步：在 Codex 中开一个对话，把你平时跟 AI 聊选题的那一套完整流程走一遍。比如：

• 第一轮："帮我找一些 AI 写作相关的选题灵感。"
• 第二轮："太多了，精简到 15 个以内，而且不要疑问句标题。"
• 第三轮："再优化一下，标题要更有吸引力，适合小红书平台。"

第二步：当输出达到你满意的状态后，直接对 Codex 说：

请把上面这段对话抽象成一个 Skill，名字叫"选题灵感"。触发条件是：当用户需要写作选题、不知道写什么、缺乏内容方向时。指令是：根据用户提供的方向生成 10 到 15 个简洁的中文标题，禁止疑问句，禁止过多解释，按平台风格（默认小红书）输出。

第三步：Codex 会根据你的对话内容，自动帮你创建文件夹结构、编写 SKILL.md、并把你的要求整理成结构化的指令——这本质上就是 Codex 的通用能力在发挥作用，它理解了你"抽象成 Skill"的意图，然后按照 Skills 规范生成对应的文件结构。整个过程通常一分钟内完成。

创建好之后，用高尔夫命令（@选题灵感）测试一下，看看输出和你刚才手动调试的结果是不是高度一致。如果是，那就说明这个 Skill 已经把你的工作流程成功"固化"了。

4.3 方法二：问答式创建

如果你不习惯从对话中抽取，也可以用更结构化的问答方式。对 Codex 说：

帮我创建一个 Skill。

Codex 会引导你回答几个关键问题：

1. 这个 Skill 叫什么名字？——建议用中文描述性名称，比如"选题灵感""周报生成""客户反馈整理"。
2. 什么时候触发？——比如"当用户表达不知道写什么、需要选题方向时"。
3. 具体做什么？——比如"根据方向生成 10 到 15 个标题，格式为一行一个，不加序号，不加解释"。
4. 输出格式要求？——纯文本列表？Markdown 表格？还是特定模板？

回答完这四个问题，Skill 就建好了。这种方式的好处是每一步都很清晰，不容易遗漏关键信息；缺点是对于复杂流程，四个问题可能不够用——这时候方法一（对话抽取）就更有优势。

4.4 方法三：手动编写 SKILL.md（适合有经验的用户）

当你熟悉了 Skills 的规范之后，也可以直接手动编写 SKILL.md 然后丢到对应目录。一个最精简的 SKILL.md 模板长这样：

---
name: 选题灵感
description: 当用户缺乏写作选题、不知道写什么、需要内容方向时触发
---

# 选题灵感

## 指令

你是内容选题助手。根据用户提供的主题方向，生成 10 到 15 个简洁的中文标题。

## 规则

- 一行一个标题
- 禁止使用疑问句结尾
- 禁止过多解释和展开
- 默认按小红书风格输出
- 如果用户没有指定方向，先询问再生成

## 禁止项

- 不要输出超过 20 个标题
- 不要添加任何标题以外的说明文字
- 不要使用"如何""怎么"等疑问句式

保存到 选题灵感/SKILL.md，然后重启 Codex（或等待热加载），这个 Skill 就生效了。

如果你是第一次手动编写，一个小建议：先让 AI 帮你生成一版 SKILL.md（用前面讲的方法一或方法二），然后你再手动微调。完全从零手写不仅容易漏掉关键字段，而且格式稍有偏差就可能导致 Skill 加载失败。AI 生成的版本至少格式规范是正确的，你只需要在内容上做加减法——这比从空白页开始省心得多。

4.5 创建完成后，记得做三件事

1. 验证：在高尔夫命令中 @你的Skill名，跑一次看看输出是否达标。
2. 微调：如果输出不太对（比如标题风格不是你想要的），立刻对话调整，让 AI 帮你修改 SKILL.md 里的限制条件。
3. 存好位置：确认你的 Skill 是放在全局目录还是项目目录——这个决策比你想象的重要，下一章专门展开。

五、Skills 的两种作用域：全局还是项目级别，这是个关键决策

很多人在 Skills 上栽的第一个跟头，不是创建失败，而是"明明建好了，怎么死活调不出来"。80% 的情况，问题出在作用域上。

5.1 两张作用域的直观对比

5.2 一个真实案例：为什么"选题灵感"应该放全局

假设你是一个自媒体创作者，同时在运营公众号、小红书、知乎三个平台。你每个平台的创作流程里都有"选题"这个环节——那你把"选题灵感"这个 Skill 放在全局就是合理的。因为不管你在哪个项目里写文章，都可能需要它。

但如果你在给某个客户做交付，客户有自己的一套术语表和格式规范，那这个"客户交付规范"的 Skill 就只应该放在那个客户的项目文件夹里。放到全局的话，当你写自己的文章时，AI 可能也会误触发这个规范，把你的个人文章格式搞得四不像。

下面这张流程图可以帮你快速做决策：

flowchart TD
    A[我有一个 Skill 想法] --> B{这个 Skill 在其他项目里也需要吗？}
    B -->|是| C{它会不会干扰其他项目？}
    B -->|否| D[放在项目级别]
    C -->|不会| E[放在全局]
    C -->|会| F[可不可以改名字/加限定条件？]
    F -->|可以| E
    F -->|不行| D

5.3 四条铁律，帮你避开 90% 的陷阱

我在过去一年里踩过的 Skills 作用域坑，浓缩成下面四条：

铁律一：全局和项目永远不要同名。 如果你在全局有一个"周报生成"，项目里又建了一个同名的，AI 到底调用哪一个？它会按"就近原则"选项目里的——但你自己可能都不知道有两个版本，下次在另一个项目里调用的又是全局版本，输出不一致，你还以为是 AI 抽风了。

铁律二：不确定安全性的 Skill，先放项目级别测试。 一个来自第三方的新 Skill，你不知道它会不会读你的私人文件、会不会执行什么奇怪的脚本——先在一个空项目或测试项目里跑一遍，确认没问题再考虑移到全局。

铁律三：项目级别的 Skill 在全局列表中看不到——这不是 Bug。 很多人装了一个项目级别的 Skill，然后用 skills list 命令查看，发现找不到，就以为安装失败了。实际上它只在高尔夫命令（项目内）中可用，这是设计如此，不是出错。

铁律四：切换项目后，项目级别的 Skill 自动"消失"。 这是项目级别 Skills 的核心特性——换一个项目文件夹，之前项目里的 Skills 就用不了了。如果你发现某个 Skill 突然调不出来，第一件事就是检查你当前在哪个项目里。

这两章已经把创建和管理的核心逻辑讲清楚了。接下来，我们要面对一个更实际的问题：第一版 Skill 永远不完美，怎么让它越用越顺手？

六、让 Skill 越用越顺手：优化迭代的三个方向

创建好第一个 Skill 只是起点，不是终点。我自己的经验是，一个真正好用的 Skill 通常要经过至少 5 到 10 轮迭代。第一版能打 60 分，经过打磨之后能稳定在 85 分以上——而那 25 分的差距，就藏在这一章讲的三个优化方向里。

6.1 方向一：改风格——让输出有"人味"

最典型的场景：你建了一个"选题灵感"的 Skill，默认输出的标题是泛化的、中性的。但你的实际发布平台是小红书——小红书的标题风格和公众号、知乎完全不同。小红书的标题需要带 emoji、需要钩子、需要口语化的表达。

怎么办？一句话就能搞定的优化：

修改"选题灵感"Skill，输出风格默认对齐小红书：标题前加 emoji、语气口语化、要有"点击冲动"。

AI 会帮你改写 SKILL.md 里的描述和指令。改完之后立刻测试——用高尔夫调用一次，看输出是不是带上了小红书的风味。如果不够，再继续对话调整：

emoji 太多了，每个标题最多一个 emoji。还有，不要用"绝了""谁懂啊"这种过度夸张的表达。

你看，整个过程就是"使用 → 不满意 → 对话修改 → 再次使用 → 再不满意 → 再修改"。这其实也是 Skills 和普通提示词最大的区别之一：Skills 是会成长的。每次优化都被持久化到了文件里，下次自动生效。

6.2 方向二：加约束——禁止往往比允许更有效

大模型天然是发散的。你让它生成标题，它可能会给你五六个方向，每个方向下列七八个标题，最后洋洋洒洒几十条——你本来只要 15 个，结果被淹没在信息洪流里。

这种时候，加禁止项比加允许项更有效。不告诉它"多生成一些"，而是告诉它"禁止超过 15 个"。不告诉它"要简洁"，而是告诉它"禁止在标题后添加任何解释性文字"。

我常用的禁止项清单，直接给大家参考：

## 禁止项
- 禁止生成超过 15 个标题
- 禁止使用疑问句作为标题（不用"如何""怎么""为什么"开头）
- 禁止在标题后添加任何说明、解释或展开
- 禁止按分类组织标题（不要出现"AI工具类：""写作技巧类："等前缀）
- 禁止输出标题列表以外的任何内容（不要加开头语和结尾语）

这套禁止项组合拳打下来，输出就被牢牢框定在一个可控范围内了。

6.3 方向三：调输出格式——从纯文本到结构化

还有一个经常被忽略的优化维度是输出格式。如果你的 Skill 输出的内容需要被下一个 Skill 消费（关于串联，下一章详聊），那纯文本就不合适了——你需要结构化的输出。

比如，让"选题灵感"输出一个 Markdown 表格而不是纯文本列表：

## 输出格式
以 Markdown 表格形式输出，每行一个标题，包含三列：

| 序号 | 标题 | 适用平台 |
|------|------|---------|
| 1 | AI写作到底能省多少时间 | 公众号 |
| 2 | ✨用AI写小红书文案的3个秘诀 | 小红书 |

这样的输出，下游的"大纲生成"Skill 就能直接读取表格，按平台分拣标题，进入不同的创作分支。

6.4 版本管理：给自己留条退路

优化 Skill 的时候，有一个小习惯非常实用：每次大改之前给 Skill 做个版本标记。最简单的方式是在 SKILL.md 的文件名或内部注释中标明版本：

---
name: 选题灵感
version: 2.1  # 增加了小红书风格，减少了 emoji 数量
---

你也可以直接复制整个 Skill 文件夹，命名为 选题灵感-v1、选题灵感-v2。这样万一新版的效果反而不如旧版，你可以随时回退——特别是当你把 Skill 分享给团队使用时，版本管理会让你省去无数沟通成本。

七、从单个 Skills 到完整工作流：把积木搭成城堡

单个 Skill 解决的是"一个环节"的问题。但真正让效率起飞的是把多个 Skill 串起来，形成一条端到端的自动化流水线。

7.1 什么是 AI 工作流？一句话讲清楚

AI 工作流就是：用 Skills 把"输入→处理→输出→下一个处理"串联起来，让每个 Skill 的输出自动成为下一个 Skill 的输入。

以前没有 Skills 的时候，你要完成"写一篇文章"，大概是这么个流程：在聊天窗口里让 AI 帮你选题 → 选好一个标题 → 再开一个新对话让 AI 帮你写大纲 → 大纲出来之后 → 再让 AI 按大纲写正文 → 正文写完 → 再让 AI 帮你起封面标题。每一步都要手动搬运上一轮的输出，每一步换新对话都可能丢失上下文。

有了 Skills 之后，这个流程就变成了：

flowchart LR
    A[选题灵感 Skill] -->|输出15个标题| B[你选一个标题]
    B -->|输入选中的标题| C[大纲生成 Skill]
    C -->|输出结构化大纲| D[正文扩写 Skill]
    D -->|输出初稿| E[标题优化 Skill]
    E -->|输出定稿标题+封面提示词| F[成品]

这个链条里，每个 Skill 都是独立的，可以单独优化、单独替换。比如你觉得"大纲生成"这个环节不够好，你只需要修改这一个 Skill，不会影响到前面的选题和后面的正文。

7.2 自媒体的最小创作工作流：一个完整示例

我自己搭建过一套自媒体的创作工作流，从零到一篇可以发布的文章，分了五个环节：

环节 1：选题灵感——输入大致方向（如"AI + 职场效率"），输出 15 个备选标题。

环节 2：大纲生成——输入选中的标题，输出一个包含引言、三个核心论点、结尾总结的结构化大纲，每个部分标注预计字数。

环节 3：正文扩写——输入大纲，按章节逐一扩写。这个 Skill 里我加了很强的风格约束：第一人称叙事、段落不超过 5 行、每 300 字至少有一个案例或数据点、禁止使用"首先其次最后"这种机械过渡。

环节 4：标题优化——正文写完后，基于正文内容重新生成 5 个自媒体爆款标题，因为最初选的标题可能在写作过程中已经偏离了正文的重点。

环节 5：封面提示词——输入定稿标题和文章摘要，输出一个中文封面提示词和一个英文版本（适配不同的 AI 绘图工具），可以直接扔进 AI 绘图工具生成封面。

这个工作流跑通之后，我从"有一个模糊想法"到"一篇可发布的文章 + 封面"，基本只需要 40 到 60 分钟——其中大部分时间花在我自己的思考和修改上，AI 执行的环节基本不需要我盯着。

7.3 Agent.md：你工作流的"宪法"

很多人在搭建工作流时会遇到一个困惑：我有 5 个 Skills 了，但它们之间怎么协调？谁先谁后？冲突了怎么办？

答案是一个叫做 Agent.md 的文件。这是放在你项目根目录下的一个"规则手册"，相当于整个工作流的宪法。AI 在每次干活之前都会读取这个文件，它定义了：

• 项目结构规范：想法放在哪个目录、草稿放在哪、定稿放在哪。
• 不可逆的流程方向：只能从想法→草稿→定稿，不能反过来。
• 安全边界：AI 不确定该改哪篇文章时，必须停下来问，不能自己猜。
• 最高优先级：你手动添加的规则，优先级高于 AI 自己学到的任何模式。

一个精简的 Agent.md 示例：

# 工作流规则

## 目录约定
- idea/：存放选题和灵感
- draft/：存放初稿（AI 生成后不可修改）
- working/：工作稿（唯一可修改的文件）
- final/：定稿（从 working 复制而来）

## 流程规则
1. 方向不可逆：idea → draft → working → final
2. 不确定时先提问，不要自己猜
3. 生成 final 时自动生成封面提示词

## 风格记忆
- 读取 memory/writing-habits.md 中的改稿习惯
- 手动添加的习惯优先级最高

有了 Agent.md，你的工作流就从"你自己心里知道"变成了"AI 每次都会遵守的系统规则"。这是从"用 AI"到"让 AI 按你的方式工作"的关键一步。

八、第三方 Skills 去哪找：三个渠道 + 安全审查四步法

不是每个 Skill 都要自己从零写。2026 年，Skills 生态已经相当成熟，很多日常工作早就有现成的 Skills 可以用。但"拿来就用"的前提是——你得知道去哪找，以及怎么判断一个 Skill 安不安全。

8.1 三个渠道，从"稳"到"多"排序

渠道一：skills.sh —— Vercel 推出的"Agent 界 npm"，社区生态最活跃

skills.sh 是由 Vercel 在 2026 年 1 月推出的 Skills 社区目录和排行榜。Vercel 将其定位为"Agent 界的 npm"——就像 npm 让 JavaScript 开发者能共享和复用代码包一样，skills.sh 让 AI 用户能发现、安装和分享 Skills。平台上线至今已有超过 600 个社区技能，上线当天顶级 Skill（vercel-react-best-practices）在六小时内就超过了 2 万次安装。

需要特别说明的是：skills.sh 是 Vercel 运营的社区平台，与 Anthropic 官方的 Skills 仓库（github.com/anthropics/skills）是两个完全不同的平台。skills.sh 上的 Skills 来自社区贡献者和各大团队（包括 Vercel 自己发布的），经过社区筛选和排行榜机制自然淘汰——质量比完全野生的个人 GitHub 仓库要靠谱一些，但安装前仍然建议按 8.2 节的方法做安全审查。适合日常使用——你想找一个"营销文案优化"的 Skill，直接在上面搜索关键词就行。

渠道二：GitHub —— 种类最多，但鱼龙混杂

GitHub 上有大量的 Skills 开源仓库。搜索 codex skills 或 claude code skills 能翻出一大堆。判断一个仓库靠不靠谱，star 数是最直观的信号。star 数超过 100 的，至少说明有人用、有人验证过。star 数是个位数的，建议多留个心眼。

品牌团队发布的 Skills 仓库可以优先考虑。比如 Vercel 发布的 vercel-labs/agent-skills，包