从零理解 AI Skill：不只是Markdown这么简单-平芜编程栈

从零理解 AI Skill：不只是Markdown这么简单
- 先说我最开始的误解
- Skill 到底是什么
- Prompt 和 Skill 的区别，不在长度
- Skill 和 Agent、Memory、Workflow、MCP 的关系
- Skill 和 MCP：一个管工艺，一个管机器
- Codex、Claude Code、Cursor 为什么都在“技能化”
- 一个 Skill 是怎么被选中的
- 写一个接入 LLM 的迷你 Skill Runner
- Skill 真正提效的地方
- 团队里怎么管理 Skill
- 安全问题不能跳过
- 更大的图：Skill + Workflow + Memory + MCP + Multi-Agent
- 我现在会怎么写第一个 Skill
- 最后聊聊：Skill 的价值其实不在“炫”
- 参考资料

从零理解 AI Skill：不只是Markdown这么简单

我第一次看到 AI Skill 这个词的时候，非常疑惑：

这不就是把 Prompt 写进一个 Markdown 文件吗？

后来我把 Codex、Claude Code、Cursor 这些工具放进日常开发里用了几轮，才发现这个理解太浅了。

Prompt 解决的是“这一次怎么问”。Skill 解决的是“以后这类事怎么稳定做”。

这两件事看起来都在写自然语言，但工程意义完全不一样。

我真正意识到这一点，是在反复让 AI 做代码 Review、整理接口文档、检查发布清单的时候。每次我都要重新提醒它：

先看已有实现。 不要上来就重构。 别动无关文件。 先报风险，再讲建议。 日志里不要打敏感字段。 跑不了测试要说明原因。

这些话单次看没什么，一周说十几遍之后就很烦。更要命的是，只要漏说一次，AI 就可能按自己的默认习惯来。

这就是 Skill 出现的背景。

这篇文章不是官方文档翻译。我更想按自己理解这件事的过程，把 AI Skill 讲清楚：

它到底比 Prompt 多了什么。
为什么 Codex、Claude Code、Cursor 都在往“技能化”方向走。
我们自己要怎么写一个真正能落地的 Skill。

先说我最开始的误解

我以前以为 Prompt 的问题只是“不够长”。

比如我要让 AI Review 一段 Go 后端代码，通常会这样写：

帮我按我们团队规范 Review 这段 Go 代码，重点关注接口边界、错误处理、并发安全、日志和测试。

这条 Prompt 当然能用。

但用着用着，我又会补充：

handler 不直接写业务逻辑。 error 要保留上下文，不能只返回 err。 goroutine 启动后要有退出条件。 context 不能随便用 context.Background()。 数据库查询不要 select *。 不要只说代码风格，先找真实风险。

再后来我发现，不只是代码 Review。每个项目、每类任务，都有一堆这种“隐形规则”。

接口文档有接口文档的规则。Review 有 Review 的规则。排查线上日志有排查线上日志的规则。做发布检查也有发布检查的规则。

如果这些规则都靠聊天时临时补充，AI Coding 的体验会很不稳定：

问题	实际表现
记不住上下文	今天按规范写，明天又忘了
难复用	每次开新对话都要重新解释
难协作	团队其他人不知道你平时怎么教 AI
难演进	好用的经验散落在聊天记录里

后来我看了一些有关的科普才把它想明白：

Prompt 更像临时沟通。 Skill 更像可以版本管理的岗位 SOP。

在真实工程里，我们不会指望每个新人都靠口头提醒记住所有规范。我们会写文档、脚本、模板、检查清单。Skill 做的事情也类似，只不过它的读者从人变成了 Agent。

Skill 到底是什么

我现在会这样定义它：

AI Skill = 触发条件 + 操作流程 + 行为约束 + 参考资料 + 可复用脚本/模板

它不是“更长的 Prompt”。

一个典型 Skill 目录大概长这样：

my-skill/ SKILL.md references/ api-style-guide.md database-schema.md scripts/ check_structure.py assets/ template.md

核心是SKILL.md，但真正让它有工程价值的，经常是旁边的references/、scripts/和assets/。

一个最小的 Skill 可以这么写：

--- name: go-service-review description: 用于 Review Go 后端服务代码，重点关注接口边界、错误处理、并发安全、context 传递、数据库访问、日志和测试覆盖。 --- # Go 服务代码 Review 按下面的顺序 Review Go 后端改动： 1. 先看业务行为是否正确，接口边界是否清晰。 2. 检查错误处理：错误是否保留上下文，是否避免吞错和重复包装。 3. 检查并发安全：goroutine 是否可退出，channel 是否可能阻塞，是否存在 data race。 4. 检查 context 传递：不要随意使用 `context.Background()`，超时和取消要能向下传递。 5. 检查数据库访问：不要 `select *`，避免 N+1 查询，新增查询条件要考虑索引。 6. 检查日志和测试：日志不能包含敏感信息，测试要覆盖成功路径、失败路径和边界场景。 报告问题时，先说具体风险和文件位置。除非会影响正确性或维护成本，否则不要把重点放在纯代码风格建议上。

这里有两个细节很重要。

第一个是description。

很多人写 Skill 时，会把“什么时候使用”写在正文里。但 Agent 只有先决定加载这个 Skill，才会看到正文。所以触发条件最好写进description，而且要具体。

这里也顺便解释一下：name保留英文短标识更多是工程习惯，方便目录、脚本和工具识别；description、流程、约束、检查清单都可以写中文。只要你的团队主要用中文协作，中文反而更容易维护。

第二个是流程顺序。

我以前写 Review Prompt，经常只写“关注事务、日志、异常”。结果 AI 会按自己的习惯输出一堆建议。后来我把顺序固定成“业务正确性优先，其次数据一致性，再看日志和测试”，输出质量明显稳定了很多。

不是模型突然变聪明了，而是它的工作路径的输出被收窄了。

Prompt 和 Skill 的区别，不在长度

一开始我把 Skill 当成“长的 Prompt”。后来做了几个小 Skill 才发现，真正的区别不是长度，而是生命周期。

对比	Prompt	Skill
生命周期	一次对话	长期存在
复用方式	复制粘贴	自动发现或显式调用
内容形态	一段文本	文件夹、说明、脚本、参考资料、模板
团队协作	难共享	可以放进 Git
稳定性	依赖当次表达	依赖固定流程和约束
演进方式	聊天记录里改	像代码一样迭代

比如这个 Prompt：

帮我检查一下这次数据库变更，重点看字段设计、索引、兼容性和回滚方案。

能不能用？能。

但它太依赖当次表达。下次你要检查订单表、用户表、账单表，又要重新强调哪些字段不能改、哪些索引要看、哪些兼容性风险要提前说明。

Skill 化之后，可以变成这样：

--- name: db-migration-review description: 用于 Review 数据库表结构和数据迁移变更，重点关注兼容性、索引、数据一致性、回滚方案和上线风险。 --- # 数据库变更 Review Review 数据库变更时，先判断这次改动会不会影响线上读写路径。 检查顺序： 1. 先确认变更目的和影响范围。 2. 检查是否兼容老版本代码和灰度发布过程。 3. 检查新增索引是否匹配真实查询条件，避免无效索引和锁表风险。 4. 检查字段默认值、空值约束、枚举值扩展是否会影响历史数据。 5. 检查数据迁移脚本是否可重复执行，失败后是否可恢复。 6. 检查回滚方案和监控指标是否清楚。 安全边界： - 不要直接执行生产写操作。 - 不要假设业务含义，拿不准时要标出问题。 - 不要只看 SQL 能不能跑，还要看上线时机、数据量和锁影响。

之后你只需要说：

帮我看一下这次订单表结构变更有没有风险。

Agent 就有机会按这套数据库变更 Review 的习惯来，而不是每次重新猜。

这里的关键不是“少打几个字”，而是把协作方式固定下来。

Skill 和 Agent、Memory、Workflow、MCP 的关系

这几个词特别容易混。

我之前看 Agent 架构文章时，经常看到一堆概念堆在一起：

Agent Memory Workflow MCP Skill Tool

刚开始看，会觉得它们都像是在“给 AI 增强能力”。但实际做下来，它们管的层不一样。

简单总结来说：

Agent：真正执行任务的运行体 Workflow：规定任务步骤怎么流转 Memory：长期记住偏好、事实和项目约定 MCP / Tools：连接外部系统，比如文件、GitHub、数据库、浏览器 Skill：告诉 Agent 遇到某类任务时应该怎么专业地做

Skill 不是工具，也不是记忆。

它更像“专业行为层”。

举个更具体的例子。

用户说：

帮我看一下这次订单模块改动有没有问题。

没有 Skill 时，Agent 可能会泛泛地说：

代码整体结构清晰，建议增加测试。

加载go-service-reviewSkill 后，它更可能按后端 Reviewer 的思路看：

1. handler 是否只处理 HTTP 入参和响应，而不是直接写业务逻辑？ 2. 下单流程里的 context 超时和取消是否能传到库存、支付、数据库层？ 3. 支付回调是否幂等？ 4. 新增 goroutine 是否有退出条件，是否可能泄漏？ 5. 失败日志是否带 orderId 和 traceId，同时不包含敏感字段？ 6. 测试是否覆盖重复回调、库存不足和并发下单？

这就是差别。

Skill 没有让 Agent 多一个 shell 工具，也没有让它记住新事实。它改变的是 Agent 做这类任务时的判断顺序和关注点。

Skill 和 MCP：一个管工艺，一个管机器

MCP 是 Model Context Protocol。简单说，它让 AI 应用可以用统一方式连接外部工具。

比如：

Filesystem MCP Server：读写文件 GitHub MCP Server：查 issue、PR、CI Docs/Search MCP Server：查文档或知识库 Database MCP Server：查结构或执行受控查询

但工具只是工具。

有 GitHub 工具，不代表 Agent 就知道修 issue 前应该先看哪些上下文。有数据库工具，也不代表它知道什么时候不能直接执行写操作。

所以我现在更喜欢这个类比：

MCP 像车间里的机器。 Skill 像工艺流程。 Agent 像操作员。

只有机器，没有流程，很容易乱用。只有流程，没有机器，又只能纸上谈兵。

一个规定 MCP 使用方式的 Skill 可能长这样：

--- name: github-issue-fixer description: 用于在具备 GitHub 和文件系统工具的代码库中修复 GitHub issue。 --- # GitHub Issue 修复助手 工作流程： 1. 先阅读 issue 标题、正文、标签和评论。 2. 在代码库里搜索相关模块。 3. 如果条件允许，查看最近相关 commit 或 PR。 4. 编辑文件前，先写一个简短修复计划。 5. 实现最小可行改动。 6. 运行有针对性的测试。 7. 总结修改文件、测试结果和剩余风险。 工具使用建议： - 用 GitHub 工具读取 issue 和 PR 上下文。 - 用文件系统工具检查和修改代码。 - 用 shell 命令运行测试、lint 和安全的只读检查。 安全边界： - 不要自动关闭 issue。 - 除非用户明确要求，不要推送分支。 - 不要修改无关文件。

这段内容本身不提供 GitHub API。

它只是告诉 Agent：有了工具以后，应该按什么顺序用，哪些动作不能擅自做。

这个边界很重要。尤其在真实项目里，AI 不是不能调用工具，而是不能乱调用工具。

Codex、Claude Code、Cursor 为什么都在“技能化”

不同产品叫法不一样，但方向确实很像。

工具	常见形态	更适合沉淀什么
Codex	`SKILL.md`、skills 目录、插件/资源	专项工作流、脚本、项目能力包
Claude Code	Agent Skills、`CLAUDE.md`、slash commands、hooks	团队技能、记忆、命令、自动化检查
Cursor	Project Rules、User Rules、Memories	项目规范、编码风格、持久上下文

它们不一定是完全相同的功能，但都在解决同一个工程问题：

怎么让 AI 的行为从临时对话，变成可复用的协作模式。

我自己使用时，会粗略这样区分：

机制	更像什么	适合场景
Skill	能力包	某类任务的流程、规则、工具策略
Slash Command	按钮	`/review`、`/commit`这种固定入口
Memory / Rules	长期说明	项目规范、个人偏好
Hooks	自动守门	工具调用前后的校验、阻断、审计

比如 Claude Code 里可以有一个项目 Skill：

.claude/ skills/ go-service-review/ SKILL.md

内容可能是：

--- name: go-service-review description: 用于 Review 或修改 Go 后端服务代码，重点关注 handler、service、repository、context、错误处理、日志和测试。 --- # Go 服务代码 Review 编辑前先做三件事： 1. 分清 handler、service、repository 和 DTO 的边界。 2. 搜索项目里是否已经有类似实现。 3. 优先做符合本地约定的小改动。 Review 检查清单： - handler 只处理 HTTP 入参、鉴权结果和响应组装。 - service 承载业务规则、事务边界和核心流程。 - repository 不要把存储细节泄漏到上层。 - 参数校验要在业务状态变更前完成。 - error 要保留上下文，但不要重复包装到难以阅读。 - goroutine、channel、mutex 的使用要检查退出、阻塞和 data race 风险。 - 日志要包含业务标识，但不能包含密钥、token、手机号等敏感信息。 - 测试要覆盖成功、失败、边界和并发场景。

Cursor 里不一定叫 Skill，但你用 Rules、Memories 做的很多事，本质上也在沉淀“AI 应该怎么参与这个项目”。

名字不同，不影响背后的趋势：AI Coding 正在从“提示词技巧”走向“能力工程”。

一个 Skill 是怎么被选中的

最简化的版本，其实就四步：

扫描可用 Skill 读取 name + description 根据用户任务选择匹配项 加载完整 SKILL.md，并把 instructions 注入上下文

真实系统肯定会更复杂，可能会有语义检索、排序、项目作用域、上下文预算、权限策略。但理解原理时，先把它想成“按任务选择操作手册”就够了。

这里有个容易踩的坑：不要把所有 Skill 一次性塞进上下文。

Skill 多了以后，如果全部加载，成本高不说，还会互相干扰。一个数据库变更 Review Skill、一个代码 Review Skill、一个安全审计 Skill 同时进上下文，模型很容易不知道到底该听谁的。

更合理的方式是：

先读取 metadata 命中后再读取正文 正文不够再读取 references 确定性任务交给 scripts

这也是为什么description要写清楚。

写一个接入 LLM 的迷你 Skill Runner

为了搞明白 Skill 到底怎么影响 Agent 行为，最直接的办法不是只打印上下文，而是接一个真实 LLM 跑一遍。

这个教学版 Runner 只做四件事：

扫描skills/*/SKILL.md
读取 Skill 的name和description
选择一个匹配的 Skill
把完整 Skill 正文和用户任务一起发给 LLM

项目结构：

mini-skill-runner/ run_skill_with_llm.py skills/ python-review/ SKILL.md

skills/python-review/SKILL.md：

--- name: python-review description: 用于 Review Python 代码，重点关注正确性、可读性、类型标注、错误处理、测试和可维护性。 --- # Python 代码 Review Review Python 代码时： 1. 先找正确性问题。 2. 再看边界条件和错误处理。 3. 检查类型标注和数据结构是否合适。 4. 检查测试是否覆盖了本次改动行为。 5. 输出时先列问题，再写总结。

run_skill_with_llm.py：

fromdataclassesimportdataclassfrompathlibimportPathfromopenaiimportOpenAIimportosimportreimportsys DEMO_CODE=""" def average_price(items): total = 0 for item in items: total += item["price"] / item["count"] return total / len(items) """@dataclassclassSkill:name:strdescription:strbody:strpath:Pathdefparse_skill(path:Path)->Skill:text=path.read_text(encoding="utf-8")match=re.match(r"---\r?\n(.*?)\r?\n---\r?\n(.*)",text,re.S)ifnotmatch:raiseValueError(f"Invalid skill file:{path}")frontmatter,body=match.groups()data={}forlineinfrontmatter.splitlines():if":"inline:key,value=line.split(":",1)data[key.strip()]=value.strip()returnSkill(name=data["name"],description=data["description"],body=body.strip(),path=path,)defload_skills(root:Path)->list[Skill]:return[parse_skill(path)forpathinroot.glob("*/SKILL.md")]defscore(task:str,skill:Skill)->int:text=f"{skill.name}{skill.description}".lower()words=re.findall(r"[a-zA-Z][a-zA-Z0-9_-]+",task.lower())returnsum(1forwordinwordsifwordintext)defselect_skill(task:str,skills:list[Skill])->Skill|None:ranked=sorted(skills,key=lambdaskill:score(task,skill),reverse=True)ifnotrankedorscore(task,ranked[0])==0:returnNonereturnranked[0]defbuild_input(task:str,skill:Skill)->str:returnf""" 你是一个谨慎的代码审查 Agent。 下面是本次任务加载的 Skill，请按它的流程和约束工作：{skill.body}用户任务：{task}待 Review 代码： ```python{DEMO_CODE.strip()}``` """defmain()->int:iflen(sys.argv)<2:print("Usage: python run_skill_with_llm.py <task>")return2model=os.getenv("OPENAI_MODEL")ifnotmodel:print("Please set OPENAI_MODEL, for example: $env:OPENAI_MODEL='gpt-5.6'")return2task=" ".join(sys.argv[1:])skills=load_skills(Path("skills"))skill=select_skill(task,skills)ifskillisNone:print("No matching skill. Use general agent behavior.")return0print(f"Selected skill:{skill.name}")print()print("LLM response:")print("="*40)client=OpenAI()response=client.responses.create(model=model,input=build_input(task,skill),)print(response.output_text)print("="*40)return0if__name__=="__main__":raiseSystemExit(main())

运行：

pip install openai$env:OPENAI_API_KEY="你的 API Key"$env:OPENAI_MODEL="gpt-5.6"python run_skill_with_llm.py"review this Python code for bugs and tests"

输出会类似：

Selected skill: python-review LLM response: ======================================== 问题： 1. `items` 为空时会触发除零错误。 2. `item["count"]` 为 0 时会触发除零错误。 3. `price` 或 `count` 缺失时会抛出 KeyError，错误信息对调用方不友好。 建议： - 先校验输入列表不能为空。 - 校验每个元素是否包含必要字段。 - 对 `count <= 0` 的数据给出明确错误。 - 为正常、空列表、缺失字段、count 为 0 的场景补测试。 ========================================

这个 Demo 比单纯打印上下文更直观，因为你能看到同一段代码在加载 Skill 后，输出会更接近 Skill 里规定的 Review 顺序。

当然，它仍然很简陋：

Skill 选择还只是英文关键词匹配。
中文任务要做得更好，需要分词、向量检索或语义匹配。
真实系统还要考虑文件类型、目录、历史使用、用户显式指定和工具权限。
调用真实 LLM 会产生 API 成本，所以不要把 API Key 写进代码或仓库。

但它已经能把 Skill 系统的骨架说明白：

Skill 不是黑科技。 它就是先被发现，再被选择，最后作为上下文影响 Agent 行为。

Skill 真正提效的地方

我一开始以为 Skill 最大收益是“少写 Prompt”。

后来发现，这只是最浅的一层。

更有价值的是后面几层：

少解释项目背景 少纠正输出风格 少出现流程漂移 少改无关文件 团队经验可以沉淀进 Git

比如团队共享一个代码审查 Skill：

# Service Review 按下面的优先级找问题： 1. 行为回归。 2. 数据一致性。 3. 安全和权限校验。 4. 可观测性和错误处理。 5. 测试覆盖。 除非影响可维护性或正确性，否则不要把时间花在纯格式、命名这类表层风格问题上。

这几行规则看起来朴素，但很管用。

因为很多 AI Review 的问题不是“看不懂代码”，而是“优先级不对”。它可能花很多篇幅讲命名、空行、注释，却漏掉事务边界、幂等、权限校验这种真正会出事的东西。

Skill 的作用就是把优先级固定住。

还有一个点：Skill 可以减少幻觉空间，但不能消灭幻觉。

比如在 API 文档生成 Skill 里写：

不要编造 API 字段。写接口文档前，先读取 OpenAPI schema 或 controller 定义。

这句话不能保证模型永远不编字段，但会改变它的行为倾向。

更稳的做法是配脚本：

从 OpenAPI JSON 自动抽取 endpoint 再让模型只负责解释和组织文字

能确定的部分交给程序，需要表达的部分交给模型。这才是我觉得 Skill 工程化里最重要的思路。

团队里怎么管理 Skill

如果 Skill 只是你本地的几个 Markdown 文件，它更多是个人效率工具。

如果它进了团队仓库，就变成团队资产。

这时就不能随便写了。至少要像代码一样管理：

有目录规范。
有 owner。
有 Review。
有版本。
有测试样例。
有安全边界。

一个比较舒服的目录可以这样设计：

ai-skills/ skills/ service-review/ SKILL.md references/ backend-style.md error-code.md scripts/ check_structure.py api-doc-writer/ SKILL.md references/ doc-style.md adapters/ cursor/ claude/ codex/

为什么要有adapters/？

因为不同工具的格式不完全一样。团队可以维护一份标准 Skill 源，再生成不同工具需要的格式：

Claude Code: .claude/skills/... Codex: .agents/skills/... Cursor: .cursor/rules/...

我不建议一开始就做得特别复杂。

比较现实的做法是，先从一个高频任务开始，比如：

service-review api-doc-writer db-migration-review incident-analysis release-note

每个 Skill 只解决一类任务。别把所有团队规范塞进一个 “super-skill”，最后谁也不敢改，Agent 也抓不住重点。

安全问题不能跳过

Skill 本身也可能成为风险源。

因为它会影响 Agent 行为，而且里面可能带脚本。

常见风险有这些：

恶意 Skill 在说明里诱导 Agent 泄露数据。
Skill 里的脚本执行危险命令。
Skill 要求读取过多敏感文件。
Skill 给工具过宽权限。
description写得太宽，导致误触发。

所以团队共享 Skill 至少要做几件事：

只安装可信来源的 Skill。
ReviewSKILL.md和scripts/。
不把密钥写进 Skill。
高危写操作、发布、删除必须有人确认。
对 Skill 的变更走代码审查。

这部分听起来没那么有趣，但在真实项目里很关键。

AI Coding 的问题从来不是“能不能自动化”，而是“自动化以后出了事谁兜底”。Skill 越强，这个问题越要提前想清楚。

更大的图：Skill + Workflow + Memory + MCP + Multi-Agent

如果只看单个 Skill，它就是一个能力包。

但放到更大的 AI Coding 系统里，它的位置会更清楚：

用户任务 ↓ Workflow 拆步骤 ↓ 不同 Agent 执行不同节点 ↓ Skill 提供专业行为 ↓ Memory 补充长期上下文 ↓ MCP / Tools 连接真实系统 ↓ 测试、审计、人类确认形成闭环

Multi-Agent 如果没有 Skill，很容易变成角色扮演：

你是架构师。 你是开发者。 你是测试。

听起来分工明确，实际输出经常还是泛泛而谈。

更有用的做法是：

架构师 Agent 有 architecture-review Skill。 开发者 Agent 有 implementation Skill。 测试 Agent 有 test-design Skill。 发布 Agent 有 release-checklist Skill。

角色名只是标签。Skill 才是能力。

我现在会怎么写第一个 Skill

如果让我从零开始，我不会先写一个很大的 Skill 系统。

我会找一个每周都在重复做的任务，比如代码 Review。

然后只写这几个部分：

--- name: service-review description: 用于 Review 后端服务代码改动，重点关注正确性、数据一致性、安全、可观测性和测试覆盖。 --- # 服务代码 Review Review 前： 1. 先阅读变更文件。 2. 梳理请求流和数据变更路径。 3. 搜索项目里是否已有类似实现。 Review 优先级： 1. 行为回归。 2. 数据一致性和事务边界。 3. 权限和安全检查。 4. 日志、指标和排障上下文。 5. 测试覆盖。 报告格式： - 先列问题，按严重程度排序。 - 尽量附上文件和行号。 - 除非影响可维护性，否则跳过纯风格建议。 边界： - Review 过程中不要修改文件。 - 不要编造业务规则。 - 如果测试无法运行，要说明原因。

先让它在真实任务里跑几次。

跑完再改。

不要一开始就追求完美。Skill 跟代码一样，只有进入真实使用场景，问题才会暴露出来。

我自己踩过的一个坑是：Skill 写得太“全面”，反而不好用。

比如一个 Skill 同时要求：

检查安全 检查性能 检查命名 检查架构 补测试 写文档 生成总结

看起来很强，实际执行时容易发散。后来我更倾向把它拆成几个小 Skill，让每个 Skill 只解决一类问题。

最后聊聊：Skill 的价值其实不在“炫”

Skill 这东西看起来没有 Agent 框架、MCP Server、向量数据库那么热闹。

但我越用越觉得，它很接近 AI 工程化的基础设施。

因为真正重要的不是“让 AI 会写一段代码”，而是把团队里的隐性经验沉淀下来：

业务规则
架构约定
发布流程
故障处理经验
数据口径
安全红线
Review 偏好

这些东西不会自动存在于模型里。

你不写，Agent 就只能猜。

Skill 的意义，就是把这些“以前靠人记住、靠口头传递、靠踩坑积累”的东西，变成 AI 可以读取、可以执行、可以迭代的能力资产。

我现在对 Skill 的理解很简单：

Prompt 是一次性交互。 Skill 是长期协作方式。

Codex、Claude Code、Cursor 的实现方式会继续变化，目录名、触发方式、产品入口也可能变。但这个方向大概率不会变：

AI Coding 会从临时聊天，走向可复用、可审查、可演进的工程协作。

如果你还没写过 Skill，可以先从一个最小版本开始：

选一个每周重复做的任务。 写清楚什么时候用。 写清楚先做什么、后做什么。 写清楚不能做什么。 配一个必要的参考文件或脚本。 拿真实任务跑几次，再迭代。

当第一个 Skill 真正跑顺以后，你会发现自己和 AI 的关系会有点变化。

它不再只是一个“问答工具”。

它开始像一个可以被训练、被约束、被复盘的工程协作者。

参考资料

OpenAI Codex: Skills
OpenAI Skills Catalog for Codex
OpenAI Codex Skill Creator
Claude Code: Agent Skills
Cursor Docs: Rules
一文读懂Skill：从基础到实操
保姆级喂饭教程：什么是Skills？如何用Skills？
Skill详解（2万字详细教程），Skills是什么，如何安装并使用Skills
一文搞懂 Skill：这玩意儿到底是啥？为啥大家都在用？

从零理解 AI Skill：不只是Markdown这么简单

目录