为什么 Markdown 能影响 AI 的工作

你的观察是正确的：许多 Skills 的核心，确实就是人也能读懂的文字。理解这一点以后，下一步要问的是：谁把这些文字交给 AI，它又如何影响当前任务？

你其实已经用过最基础的形式

你在对话里说“请先解释术语，再举例，最后问我一个问题”，这段文字就会影响 AI 接下来的回答。它不是程序代码，而是当前任务的要求。

如果你每次学习都重复输入这一大段要求，就会麻烦，而且很容易漏掉某一句。现在把它保存成一份可重复使用的说明，给它起名，规定何时使用，需要时再读取，就有了理解 Skill 的起点。

但正式 Skill 不只是把一段话随意另存为文件。兼容的产品还需要认出它是什么、在什么情况下适用，以及到哪里找到完整内容。

Markdown 只是组织文字的方式

Markdown 是一种容易用普通文本编辑器阅读的文档格式。常见文件后缀是 .md。

这些符号帮助组织和显示内容。它们本身不会运行测试、打开浏览器或发布网站。真正的动作仍由使用文档的 AI 系统和工具完成。

一份教学用 Skill 长什么样

下面是为讲解而编写的简化例子，不是 Matt 的原文，也没有因为出现在网页上就被安装。

---
name: clarify-learning-goal
description: 用户提出模糊的学习目标，希望先通过问答把目标讲清楚时使用。
---

# 澄清学习目标

1. 先询问用户希望解决的一个具体问题。
2. 每次只问一个问题，并解释为什么需要知道答案。
3. 不清楚用户已有基础时，先了解基础。
4. 把已确认内容与尚未确认内容分别列出。
5. 用户确认目标后，再讨论练习安排。

开头两条 --- 之间，是供产品识别的说明字段，叫作元数据。你暂时只需要认识两项：name 表示名称，description 描述用途和使用条件。后面的正文才是工作要求。

因此，“我想提高 AI 使用能力”这句话可能与描述匹配。AI 读取正文后，就获得了进一步澄清目标的具体方法。

为什么通常是一个文件夹，而不只是一个文件

开放格式的核心是：一个文件夹里有一份 SKILL.md，还可以带脚本、参考文档或模板。这使一项方法能够携带所需材料。Agent Skills 开放规范

例如“整理学习记录”可能需要一份笔记模板；“检查代码”可能需要阅读项目检查规则；另一项技能可能需要一个已经写好的辅助程序。只有主文档，没有它引用的必要文件，方法就可能无法完整执行。

Matt 的 grill-me 就是一个特别容易误解的例子：它的正文很短，主要要求加载 grilling。如果只拿到 grill-me 这一页，却没有 grilling 的正文，真正的访谈方法仍然缺失。grill-with-docs 还会调用 domain-modeling。这就是“配套依赖”的具体意思：要使用这一项，还需要另外的材料或能力。对照教材中的 grill-me、grill-with-docs

文本怎样进入 AI 的工作过程

“上下文”可以先理解为：AI 在这一轮处理任务时能够参考的信息。它可能包括你的要求、前面的对话、读到的文件和工具返回的结果。

支持 Skills 的产品通常先提供技能的名称和用途。需要使用某项技能时，再读取完整正文。于是，该 Skill 的工作要求也进入了这次任务可参考的信息中。这种按需要读取的方式，叫“渐进加载”或“渐进披露”。OpenAI：Build skills

这里有两点非常重要。第一，正文不是安装时就永久写进模型的知识中。第二，不能认为不用时绝对不占任何上下文，因为名称、描述等目录信息也可能占用空间；正文读入后，在当前会话中怎样保留，又取决于具体产品。

与直接粘贴提示词有什么不同

直接把完整说明粘进当前对话，也可能有效地指导 AI。正式 Skills 主要让这件事更容易重复、组织和管理。

例如你有十种不同的工作方法。每次手工找到正确文件、复制全文、补齐参考材料，容易出错；如果产品已经识别这些技能，就可以提供选择入口，或者在合适任务中帮助选择，再按需要读取。

所以，它的实际收益包括：少重复粘贴、减少漏步骤、保留统一版本、复用配套材料。但一份写得含糊、过时或不适合当前任务的 Skill，仍可能让 AI 做错。文件名不是质量保证。

阅读与执行是两件不同的事

你说“请翻译并解释这份 Skill”，文件就是学习材料。里面即使写着“提交代码”，也不表示你正在要求 AI 执行提交。

你说“请使用这份 Skill，处理我提供的任务”，才是在请求按它的方法工作。能否完成，还要看文件是否完整、工具是否可用、任务是否已经说明清楚。

**自问：**把本网页复制进一个聊天窗口，要求解释它，与把一项完整 Skill 安装到 Codex 中，分别发生了什么？