# 万物皆可 Skill：如何基于 Codex 把任何内容变成可复用 AI 能力
**作者**: 知识猫图解
**日期**: 2026-06-15T15:56:17.000Z
**来源**: [https://x.com/GeekCatX/status/2066550371724730721](https://x.com/GeekCatX/status/2066550371724730721)
---
过去我们使用 AI，常常停留在“提问”。
看到一篇文章，让 AI 总结一下；遇到一个报错，让 AI 分析一下；要写一份报告，让 AI 起草一下；要做一个项目，让 AI 帮忙拆解一下。
这些做法当然有用，但效率并不高。因为每一次你都要重新解释背景、规则、格式、偏好和验收标准。真正高阶的 AI 使用方式，不是不断写更长的提示词，而是把一次次有效的 AI 协作经验沉淀成 Skill。
一句话概括：
提示词解决一次问题，Skill 解决一类问题；Workflow 解决一条流程，Agent 解决一个目标系统。
在 Codex 里，Skill 是一种可复用的能力包。OpenAI 官方文档将 Codex Skill 定义为由 SKILL.md 加上可选的 scripts/、references/、assets/ 等资源组成的目录，用来让 Codex 更可靠地执行某类任务。其中，SKILL.md 必须包含 name 和 description。Codex 可以通过显式调用 Skill，也可以根据 description 自动判断是否加载某个 Skill。
但 Skill 的意义不止于“给 AI 写一份说明书”。它更像一种把人类经验、组织流程、专业判断、工具调用方式和失败修正记录，转化为 AI 可复用能力模块的方法。
这就是本文的核心观点：
万物皆可 Skill。
## 一、什么是 Skill？它不是提示词，而是能力模块
很多人第一次接触 Skill，会把它理解成“一个更长、更复杂的提示词”。这个理解太浅了。
提示词通常是一次性的。它告诉 AI：“这次请你这样做。”
Skill 是可复用的。它告诉 AI：“以后遇到这一类任务，都按这套方法做。”
一个成熟的 Skill，至少封装了 7 件事：
```
1. 什么时候使用它
2. 输入材料是什么
3. 处理步骤是什么
4. 输出格式是什么
5. 质量标准是什么
6. 出错时怎么办
7. 如何验证结果是否合格
```
所以，Skill 的本质不是一段文本，而是一组可复用的能力结构：
任务边界 + 操作流程 + 判断标准 + 失败处理 + 可复用资源。
Agent Skills 规范也强调，Skill 的核心是一种轻量、开放的能力扩展格式：最小结构是一个包含 SKILL.md 的文件夹，里面可以继续放脚本、参考资料、模板和其他资源。
如果说工具回答的是“AI 能做什么”，那么 Skill 回答的就是“AI 应该如何做”。
Anthropic 官方 Skill 指南里有一个很好的厨房类比：MCP 或工具像厨房设备，Skill 像菜谱。工具提供能力，Skill 提供方法。没有菜谱，设备再多也只能临场发挥；有了菜谱，同样的设备才能稳定做出同一道菜。
## 二、为什么说“万物皆可 Skill”？
“万物皆可 Skill”，不是说任何东西都要机械地写成 SKILL.md。它真正表达的是：
任何可重复、可抽象、可验证的经验，都可以 Skill 化。
一篇文章可以变成“文章总结 Skill”。一个视频脚本可以变成“短视频拆解 Skill”。一次成功调试可以变成“报错诊断 Skill”。一份公司规范可以变成“品牌写作 Skill”。一个优秀提示词可以变成“提示词生成 Skill”。一个失败案例可以变成“避坑检查 Skill”。一套项目流程可以变成“项目交付 Skill”。一个专家的判断方式可以变成“领域分析 Skill”。
关键不在内容本身，而在内容背后的 可迁移方法。
例如，一篇《如何写爆款标题》的文章，不应该只是被保存成资料。你应该继续追问：这篇文章背后有没有一套可重复使用的标题生成方法？它适合什么类型的内容？输入需要哪些信息？生成标题时要经历哪些步骤？怎样判断标题好不好？什么标题不能用？有没有测试样例？
当这些问题被回答清楚，文章就不再只是文章，而变成了一个“标题生成 Skill”的雏形。
## 三、递归视角：Skill 不只是结果，也是制造 Skill 的工具
更重要的是，Skill 不只是被创建出来的东西。Skill 本身也可以继续创建 Skill。
这就是递归。
第一层，你把内容变成 Skill。第二层，你把“把内容变成 Skill 的方法”也变成 Skill。第三层，你让这个 Skill 读取真实使用反馈，再自动改进自己。第四层，你让它把多个小 Skill 组合成 Workflow。第五层，你让 Workflow 变成 Agent 的操作系统。
这个过程可以写成一个递归公式：
```
内容 → 提炼方法 → 生成 Skill → 使用 Skill → 收集失败 → 修正 Skill → 生成更好的 Skill
```
再抽象一点：
```
Skill = f(经验)
更好的 Skill = f(Skill 的使用轨迹 + 失败反馈 + 测试结果)
元 Skill = f(如何生成和改进 Skill 的方法)
```
所谓“元编程”，在这里可以通俗理解为：
不是直接解决一个任务，而是写出能生成任务解决方法的规则。
普通使用者让 AI 写文章；高级使用者让 AI 总结写文章的方法；更高级的使用者把这个方法封装成 Skill；再进一步，就会写一个“自动生成 Skill 的 Skill”。
这就是从提示词工程进入 Skill 工程的关键跃迁。
## 四、从提示词到 Skill：能力封装的 5 个层级
你可以把 AI 使用能力分成 5 层：
```
第 1 层：Prompt
解决一次任务。
第 2 层：Template
解决相似任务。
第 3 层：Skill
解决一类任务。
第 4 层：Workflow
串联多个 Skill，解决一条完整流程。
第 5 层：Agent
围绕目标自动规划、调用工具、检查结果、失败回退。
```
以“把任意内容变成 Skill”为例，这件事也可以逐层升级：
```
Prompt：
请把这篇文章变成 Skill。
Template：
请按固定结构提炼使用场景、输入、步骤、输出、质量标准。
Skill：
content-to-skill/
└── SKILL.md
Workflow：
内容采集 → 方法提炼 → Skill 生成 → 测试 → 修正 → 入库
Agent：
自动发现高频任务 → 生成 Skill → 跑测试 → 根据失败记录迭代 → 推荐是否发布
```
Codex 官方最佳实践也强调，Codex 更适合被当成一个可以持续配置和改进的队友，而不是一次性助手；当某个工作模式反复出现时，应把它沉淀为可复用指导、Skill 或自动化。
从这个角度看，Skill 是从“临场协作”走向“能力资产”的关键中间层。
## 五、什么内容最值得 Skill 化？
不是所有内容都值得变成 Skill。判断标准很简单：
```
高频吗？
稳定吗？
有输入吗？
有输出吗？
有步骤吗？
能判断好坏吗？
失败后能修正吗？
```
只要满足其中大部分，就值得 Skill 化。
最适合 Skill 化的内容，通常有 8 类：
但有三类内容不要急着 Skill 化。
第一，一次性任务。例如“帮我写今天这封邮件”，普通提示词就够了。
第二，目标还不清楚的任务。如果你还不知道自己想要什么输出，就先不要封装。
第三，高风险判断。法律、医疗、金融、安全等领域可以做辅助分析 Skill，但不能把 Skill 当成最终专业判断。
Skill 化的前提不是“内容看起来有价值”，而是“它背后有一套可以反复调用、可以检查结果、可以持续改进的方法”。
## 六、把任何内容变成 Skill 的核心方法：抽象，而不是复制
很多人做 Skill 的第一个错误，是把原文直接塞进 SKILL.md。
这不是 Skill，这是资料堆积。
Skill 化的关键是抽象。你要从内容里提取 6 个东西：
```
1. 问题：它解决什么问题？
2. 场景：什么时候使用？
3. 输入：需要什么材料？
4. 过程：按什么步骤处理？
5. 标准：什么结果算好？
6. 回退：失败、不确定、信息不足时怎么办？
```
可以用这个公式理解：
```
内容 Skill 化 = 去掉一次性信息 + 保留可迁移方法 + 增加验收标准
```
比如你有一篇关于“如何写产品需求文档”的文章。
低级做法是：
```
请以后写 PRD 时参考这篇文章。
```
高级做法是把它提炼为 PRD 写作 Skill：
```
适用场景：从想法到产品需求文档
输入：用户问题、目标用户、核心功能、约束
步骤：用户场景 → 功能清单 → 优先级 → 验收标准 → 风险
输出：标准 PRD 模板
质量标准：需求清晰、边界明确、可开发、可测试
失败处理：信息不足时先提问，不要编造需求
```
这才是 Skill。它不是让 AI “参考一下”，而是告诉 AI 在这一类任务中如何判断、如何执行、如何交付、如何避免错误。
## 七、Codex Skill 的推荐结构
一个实用的 Codex Skill，可以这样组织：
```
my-skill/
├── SKILL.md
├── references/
│ └── examples.md
├── assets/
│ └── template.md
├── scripts/
│ └── validate.py
└── evals/
└── evals.json
```
其中，SKILL.md 是核心；references/ 放详细资料；assets/ 放模板；scripts/ 放需要稳定执行的代码；evals/ 放测试用例。OpenAI 文档和 Agent Skills 规范都采用类似结构，并建议把详细资料拆到引用文件中，以便 Agent 按需加载，而不是一次性把所有内容塞进上下文。
最小可用版只需要一个文件：
```
---
name: content-to-skill
description: Use this skill when the user wants to convert articles, notes, workflows, prompts, tutorials, examples, or expert knowledge into reusable Agent Skills. Do not use for one-off summaries.
---
# Content to Skill
## Goal
Turn provided content into a reusable, testable Skill.
## When to use
Use when the input contains repeatable methods, workflows, standards, examples, or expert judgment.
Do not use when the user only wants a one-time summary or answer.
## Input
The user may provide:
- Article
- Notes
- Workflow
- Prompt
- Code practice
- Tutorial
- Failure case
- Expert explanation
- Existing conversation trace
## Process
1. Identify the repeatable task behind the content.
2. Separate one-time facts from reusable methods.
3. Define the trigger scenario.
4. Define required inputs.
5. Extract step-by-step workflow.
6. Define output format.
7. Define quality standards.
8. Define failure handling.
9. Add examples.
10. Add test cases.
## Output
Generate a complete SKILL.md draft.
## Quality standards
A good Skill must be:
- reusable
- specific
- testable
- scoped
- not overloaded
- clear about when to use and when not to use
## Failure handling
If the content is too vague, ask for missing context.
If the content is not suitable for a Skill, suggest Prompt, Checklist, Workflow, or Agent instead.
```
这里的 description 非常关键。Codex 是否自动加载某个 Skill，很大程度上取决于 description 是否准确。因此，描述要清晰、范围明确，并把关键使用场景放在前面。它不是一句简介，而是 Skill 能否被正确触发的主要机制。
## 八、最重要的设计原则：渐进披露
优秀的 Skill 不应该把所有内容都堆进 SKILL.md。
原因很简单：Agent 的上下文是有限的。Skill 越多，描述越长，越容易互相干扰。Codex 启动时通常只会把可用 Skill 的名称、描述和路径放入初始上下文；当它决定使用某个 Skill 时，才会读取完整 SKILL.md。
这就是渐进披露：
```
第一层：name + description
告诉 Agent：什么时候该想起这个 Skill。
第二层：SKILL.md
告诉 Agent：这类任务怎么做。
第三层：references / scripts / assets
只有需要时才加载详细资料、模板和脚本。
```
所以，一个好的 Skill 应该像一个好函数：
```
名称清楚
职责单一
输入明确
输出稳定
内部逻辑可维护
可以和其他函数组合
```
Skill 应该聚焦在一个连贯的工作单元上，不要太窄，也不要太宽。过宽会导致触发不准，过窄则容易让多个 Skill 同时加载并互相冲突。
## 九、元编程视角：写 Skill，就是在写“AI 的程序”
传统编程是写代码，让机器执行。提示词工程是写指令，让模型生成。Skill 工程是写能力结构，让 Agent 在合适场景自动调用。
所以，Skill 可以被看作一种“自然语言程序”。
它有变量：
```
输入材料
用户目标
上下文
约束条件
输出格式
```
它有流程：
```
分析 → 判断 → 执行 → 验证 → 修正 → 输出
```
它有条件分支：
```
如果信息不足，先提问。
如果用户只要总结，不要生成 Skill。
如果任务高风险，标注专业边界。
如果输出不符合标准，重新修正。
```
它有模块：
```
SKILL.md
references/
scripts/
assets/
evals/
```
它甚至有测试：
```
正常场景
边缘场景
压力场景
不应触发场景
```
这就是元编程思路：
你不是直接让 AI 完成任务，而是在设计 AI 完成一类任务的“生成规则”。
当你写一个“生成 Skill 的 Skill”时，你就在做元 Skill。当你写一个“优化 Skill 的 Skill”时，你就在做递归改进。当你写一个“评估 Skill 的 Skill”时，你就在做 AI 能力工程化。
Skill 的价值，也正是在这里从“技巧”变成了“系统”。
## 十、递归 Skill 系统：让 Skill 自我进化
一个普通 Skill 是静态的。一个高级 Skill 系统是递归进化的。
你可以设计一个闭环：
```
1. 输入内容
2. 生成 Skill v0.1
3. 用真实任务测试
4. 记录触发错误、输出错误、遗漏步骤
5. 生成修订建议
6. 更新 Skill v0.2
7. 再测试
8. 稳定后入库
```
Skill 的第一版通常不会完美。真正可靠的 Skill，需要根据真实执行结果持续改进：不仅要看最终输出，还要看 Agent 的执行轨迹，找出哪些步骤浪费时间、哪些指令过于模糊、哪些选项缺少默认策略。
你甚至可以把这个过程写成一个“Skill 进化 Skill”：
```
---
name: skill-evolver
description: Use this skill to improve an existing Skill based on execution results, user corrections, failed outputs, eval results, or agent traces.
---
# Skill Evolver
## Goal
Improve an existing Skill through recursive feedback.
## Input
- Existing SKILL.md
- Real user tasks
- Agent outputs
- User corrections
- Failed cases
- Eval results
## Process
1. Compare expected behavior with actual output.
2. Identify failure type:
- wrong trigger
- missing context
- vague instruction
- unstable output
- missing validation
- wrong tool usage
- unsafe assumption
3. Modify the smallest necessary part of the Skill.
4. Add the failure case to Gotchas or evals.
5. Preserve backward compatibility unless explicitly changing behavior.
6. Output a new version and changelog.
## Output
- Revised SKILL.md
- Change summary
- Added test cases
- Remaining risks
```
这就是递归思想的落地：
Skill 不只执行任务，Skill 还改进 Skill。
## 十一、最佳实践：好 Skill 的 10 条原则
综合 Codex 文档、Agent Skills 规范、Anthropic Skill 指南和相关最佳实践，优秀 Skill 通常遵守下面 10 条原则。
1. 从真实任务中提炼，不要凭空生成
不要只说“帮我生成一个数据分析 Skill”。
更好的做法是：先完成一次真实数据分析，把成功步骤、失败修正、输入输出和边界情况记录下来，再提炼 Skill。
好的 Skill 应该来自真实专业上下文，例如内部文档、运行手册、代码审查记录、Issue、版本修改历史和真实故障案例，而不是只依赖模型的通用知识。
2. 一个 Skill 只做一类事
不要写一个“万能办公 Skill”，它会太宽。
可以拆成：
```
meeting-summary
weekly-report
email-rewrite
customer-feedback-analysis
proposal-review
```
每个 Skill 最好聚焦一个任务，并优先用明确输入输出的命令式步骤来描述。
3. description 决定是否能被正确调用
description 不是简介，而是触发器。
差的写法：
```
description: Helps with writing.
```
好的写法：
```
description: Use this skill when the user wants to turn rough notes, meeting transcripts, or project updates into a structured weekly report with progress, risks, blockers, and next actions. Do not use for casual rewriting.
```
description 应该清楚说明 Skill 做什么、什么时候使用、什么时候不使用，并加入具体关键词，帮助 Agent 判断相关任务。
4. 少讲常识，多写 Agent 不知道的东西
不要在 Skill 里解释“什么是 Markdown”“什么是 API”“什么是总结”。这些模型本来就知道。
你要写的是那些没有这个 Skill 时，Agent 容易做错的规则：
```
我们的报告必须先写结论再写证据。
所有风险必须按高/中/低分级。
客户名称不能出现在公开版本中。
代码审查必须先跑测试再给建议。
```
换句话说：只写会改变执行结果的内容。如果 Agent 本来就能做好，就删掉。
5. 给默认方案，不要给一堆菜单
差的写法：
```
你可以用 A，也可以用 B，也可以用 C，看情况选择。
```
好的写法：
```
默认使用 A。
只有当输入是扫描 PDF 时，才切换到 B。
如果 A 和 B 都失败，说明失败原因并请求人工确认。
```
给 Agent 默认路径，比给它一堆并列选项更可靠。复杂到难以一次写对的命令，应该移入脚本。
6. 加 Gotchas，而不是只写原则
很多 Skill 最有价值的部分，不是流程，而是“坑”。
例如：
```
## Gotchas
- 我们的用户 ID 在数据库叫 user_id，在支付系统叫 accountId。
- 生成日报时不要把“计划”写成“已完成”。
- 如果用户没有提供数据来源，不能编造数据。
- 对外文案不要使用“绝对领先”“唯一”等不可验证词。
```
当 Agent 反复犯同一个错，就把它加入 Gotchas。
7. 输出模板要具体
不要说“输出清晰一点”。
直接给模板：
```
# [标题]
## 一句话结论
...
## 关键发现
1. ...
2. ...
3. ...
## 风险与不确定性
- ...
## 下一步行动
- [ ] ...
```
Agent 对具体结构的模仿能力，通常比对抽象描述的执行更稳定。
8. 必须有失败处理
一个 Skill 没有失败处理，就不可靠。
至少写清楚：
```
信息不足时怎么办？
输入格式错误时怎么办？
任务不适合 Skill 时怎么办？
涉及高风险判断时怎么办？
输出无法验证时怎么办？
工具失败时怎么办？
```
好的 Skill 不只规定“成功时怎么做”，也规定“不确定时如何不乱做”。
9. 用 evals 测试 Skill，而不是凭感觉
不要因为跑通一次就认为 Skill 好用。
至少准备 3 类测试：
```
正常场景：它应该触发，并输出正确结果。
边缘场景：输入混乱、缺字段、格式不标准。
反向场景：它不应该触发。
```
测试的目标不是证明 Skill 能用，而是找出它什么时候会误触发、漏触发，或者输出不稳定。
10. 复杂逻辑交给脚本
如果某一步必须稳定、可重复、可验证，不要只靠自然语言。
例如：
```
校验 JSON
统计字段
转换文件
跑测试
格式化代码
检查链接
计算指标
```
这些都适合放进 scripts/。脚本应自包含、说明依赖、提供有用错误信息，并优雅处理边界情况。只要命令复杂到容易写错，测试过的脚本通常比自然语言指令更可靠。
## 十二、把任何内容变成 Skill 的通用提示词
你可以把下面这段直接丢给 Codex：
```
你是一个 Codex Skill 架构师。请把我提供的内容转化为一个可复用、可测试、可迭代的 Agent Skill。
核心目标：
不要复述内容，而是提炼内容背后的可迁移方法，把它变成以后可以重复调用的 Skill。
请按以下步骤处理：
1. 判断这份内容是否适合 Skill 化
- 是否高频
- 是否有稳定输入
- 是否有稳定输出
- 是否有可重复步骤
- 是否有质量标准
- 是否能测试
2. 如果适合，请提炼：
- Skill 名称
- 触发场景
- 不应触发场景
- 输入格式
- 执行步骤
- 输出格式
- 质量标准
- Gotchas
- 失败处理
- 示例输入
- 示例输出
- 测试用例
3. 如果不适合 Skill 化，请判断它更适合变成：
- 普通提示词
- 提示词模板
- Checklist
- Workflow
- Agent
- 参考资料
4. 输出完整 SKILL.md 草稿。
5. 再输出：
- 设计理由
- 可能过宽或过窄的地方
- 需要补充的上下文
- 3 个正常测试用例
- 3 个边缘测试用例
- 3 个不应触发测试用例
待转化内容如下：
【粘贴内容】
```
这段提示词本身也可以继续 Skill 化。也就是说，它不仅能完成一次转换，还可以成为一个“内容转 Skill”的能力原型。
## 十三、终极模板：元 Skill——content-to-skill
下面是一个更完整的元 Skill 草稿。它的作用是：把任意内容转化为 Skill。
```
---
name: content-to-skill
description: Use this skill when the user wants to convert articles, notes, prompts, workflows, tutorials, examples, expert explanations, project rules, failure cases, or conversation traces into reusable Agent Skills. Use especially when the user asks to "turn this into a skill", "extract a reusable workflow", "make this repeatable", or "codify this process". Do not use for one-off summaries or casual rewriting.
license: Proprietary
metadata:
version: "1.0"
author: "your-name"
---
# Content to Skill
## Goal
Transform any content into a reusable, scoped, testable Agent Skill by extracting its underlying repeatable method, workflow, standards, edge cases, and validation rules.
## Core principle
Do not copy the source content. Extract the transferable capability behind it.
A Skill is valuable only if it helps an agent perform a class of tasks more reliably than it would without the Skill.
## When to use
Use this Skill when the user provides one or more of:
- Article
- Book notes
- Course notes
- Prompt
- Workflow
- SOP
- Tutorial
- Code pattern
- Debugging record
- Expert explanation
- Meeting transcript
- Project convention
- Failure case
- Agent trace
- Previous conversation
Use when the user wants to convert the material into:
- SKILL.md
- reusable workflow
- prompt template
- operating procedure
- agent capability
- evaluation checklist
## When not to use
Do not create a Skill when:
- The task is clearly one-off.
- The user only wants a summary.
- There is no stable input or output.
- The method cannot be generalized.
- The domain is high-risk and requires licensed professional judgment.
- The content is too vague and the user refuses to provide context.
In those cases, recommend Prompt, Template, Checklist, Workflow, Agent, or Reference instead.
## Input format
The user should provide:
text
Content:
[article / notes / workflow / prompt / examples / trace]
Target user:
[who will use this skill]
Target task:
[what recurring task this skill should support]
Environment:
[Codex / Claude Code / ChatGPT / local repo / team workflow]
Constraints:
[style, tools, safety rules, output format]
Examples:
[optional successful or failed cases]
## Process
### Step 1: Identify the repeatable task
Ask:
- What recurring job does this content imply?
- Who performs this job?
- What input triggers the job?
- What output should be produced?
- What mistakes happen repeatedly?
### Step 2: Separate content from method
Classify source material into:
- One-time facts
- Reusable steps
- Domain rules
- Output preferences
- Quality criteria
- Edge cases
- Failure examples
- Tool instructions
- Templates
Keep reusable elements. Remove one-time noise.
### Step 3: Define skill boundary
Decide:
- What this Skill does
- What it does not do
- When it should trigger
- When it should not trigger
- Whether it should be split into smaller Skills
If the Skill covers more than one coherent job, propose splitting it.
### Step 4: Design the frontmatter
Create:
yaml
---
name: lower-case-hyphen-name
description: Use this skill when... Do not use when...
metadata:
version: "0.1"
---
The description must include:
- User intent
- Trigger words
- Positive use cases
- Negative boundaries
### Step 5: Write executable instructions
Include:
- Goal
- Input requirements
- Step-by-step workflow
- Output format
- Quality standards
- Gotchas
- Failure handling
- Examples
- Test cases
Prefer procedures over vague principles.
### Step 6: Add progressive disclosure
If the Skill is long:
- Keep core instructions in SKILL.md.
- Move detailed examples to references/examples.md.
- Move templates to assets/.
- Move deterministic operations to scripts/.
- Tell the agent exactly when to load each file.
### Step 7: Add validation
Every Skill must include at least:
- normal test cases
- edge test cases
- should-not-trigger test cases
- self-check checklist
### Step 8: Produce the final package plan
Output:
- SKILL.md
- optional folder structure
- suggested references
- suggested scripts
- eval cases
- revision notes
## Output format
Return:
markdown
# Skillization Report
## 1. Suitability judgment
[Suitable / Not suitable / Needs more context]
## 2. Extracted reusable capability
...
## 3. Recommended skill boundary
...
## 4. Generated SKILL.md
\markdown
...
\
## 5. Suggested files
\text
skill-name/
├── SKILL.md
├── references/
├── assets/
├── scripts/
└── evals/
\
## 6. Test cases
### Should trigger
...
### Edge cases
...
### Should not trigger
...
## 7. Risks and next iteration
...
## Quality standards
A good output must be:
- reusable
- scoped
- specific
- testable
- concise
- grounded in source material
- explicit about failure handling
- clear about when not to use the Skill
## Gotchas
- Do not summarize the content as the Skill.
- Do not create an overly broad “do everything” Skill.
- Do not include generic AI advice unless it prevents a likely failure.
- Do not invent domain facts missing from the source.
- Do not hide uncertainty.
- Do not omit should-not-trigger examples.
- Do not make the description too vague.
## Failure handling
If source content is insufficient:
1. Explain what is missing.
2. Ask at most 3 targeted questions.
3. Provide a provisional Skill draft with assumptions clearly marked.
If source content is not suitable:
1. Explain why.
2. Recommend a better artifact type.
3. Provide a minimal alternative.
If the generated Skill is too large:
1. Split into multiple Skills.
2. Move detail into references/.
3. Keep only core execution logic in SKILL.md.
```
详细参考：https://github.com/gnipbao/content-to-skill
## 十四、结语：未来的高手不是会问 AI，而是会训练 AI
AI 时代的核心能力，正在从“会不会提问”升级为“会不会沉淀能力”。
普通人把 AI 当搜索框。进阶者把 AI 当助手。高手把 AI 当团队成员。真正的专家，会为 AI 建立 Skill、Workflow 和 Agent 系统。
Skill 是一个关键中间层：它比提示词稳定，比 Agent 简单，比 Workflow 更模块化，比文档更可执行。
所谓“万物皆可 Skill”，不是把世界都写成 Markdown，而是当你看到任何有价值的内容时，都能多追问一句：
这背后有没有一种可重复使用的能力？
如果有，就提炼它，封装它，测试它，迭代它；让它调用别的 Skill，让它生成新的 Skill，让它递归改进自己。
最终，你拥有的就不再是一堆提示词，而是一套属于自己的 AI 能力库。
## 相关链接
- [知识猫图解](https://x.com/GeekCatX)
- [@GeekCatX](https://x.com/GeekCatX)
- [15K](https://x.com/GeekCatX/status/2066550371724730721/analytics)
- [https://github.com/gnipbao/content-to-skill](https://github.com/gnipbao/content-to-skill)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:56 PM · Jun 15, 2026](https://x.com/GeekCatX/status/2066550371724730721)
- [15.3K Views](https://x.com/GeekCatX/status/2066550371724730721/analytics)
- [View quotes](https://x.com/GeekCatX/status/2066550371724730721/quotes)
---
*导出时间: 2026/7/6 08:20:59*