AI工具AgentLLM智能体skill
最近在调试一个”AI内容创作助手”，废了九牛二虎之力写了一份详细的技能文档，结果AI用起来跟没看过一样——让它写技术文章，它开始跟我聊人生；让它生成代码，它先给我讲五分钟原理。
我一度怀疑是模型太笨。直到我看到了Anthropic官方发布的skill-creator——一个专门教你怎么给AI写指令的skill——才恍然大悟：问题不在AI，在指令本身。
skill-creator的设计原则，让我重新理解了什么叫”给AI写指令”。
先说结论：你可能一直在给AI写”人类文档”#
看看下面这段”技能说明”，眼熟吗？
## 代码审查技能
### 背景
本技能基于团队多年的代码审查经验总结而成，旨在提升代码质量和团队协作效率。
### 审查原则
- 保持专业、建设性的语气
- 关注代码质量而非个人风格
- 平衡严格性和灵活性
### 使用方式
当用户提交代码时，对代码进行全面审查，给出改进建议。这份文档写给人类看，没问题。有背景、有原则、有使用说明，甚至还体贴地加了版本记录。
但AI看了会怎样？
- “保持专业、建设性的语气” → AI把”专业”展开成一百种组合，每次输出都不一样
- “平衡严格性和灵活性” → 人类知道什么时候该严什么时候该松，AI没有这个直觉
- “全面审查，给出改进建议” → AI需要的是：先检查什么？再检查什么？什么问题必须指出？
skill-creator的核心洞察：Skill是给AI写的指令，不是给人写的文档。读者不同，写法就完全不同。
原则一：上下文窗口是公共资源，每句话都要值得占用的token#
AI的上下文窗口就像一张工作台——同一时间能摊开的资料是有限的。你的系统提示、对话历史、所有已安装技能都在上面抢位置。
skill-creator的第一原则就是：每一句话都要值得它占用的token。
基于这个原则，它设计了一个三级分层架构：
| 层级 | 内容 | 加载时机 | Token成本 |
|---|---|---|---|
| L1 | frontmatter（name+description） | 始终在上下文 | ~100词 |
| L2 | SKILL.md body | 触发后加载 | <5k词 |
| L3 | scripts/references/assets | 按需加载 | 零 （执行不读入） |
这本质上是一个信息熵管理系统——不是所有信息都需要一开始就加载 。
L1是过滤器，让AI从几十个技能中选出该激活哪个；L2是操作手册，触发后才加载；L3是工具箱，只在需要时调用，而且scripts/执行而不读入，零token成本。
对比我之前写的那个44k字节的技能文档，恨不得把所有细节都塞进去，AI每次激活都要读完——这不是在教AI，这是在折磨AI。
原则二：“不做什么”比”做什么”更精确#
skill-creator在写约束时，用了很大篇幅说”什么不该做”，而不是泛泛地说”该怎么写”。
它没有写：
请用温暖、克制、有洞察力的语气写作。它做的是写了一份反模式清单：
| 不这样做 | 症状 | 怎么改 |
|---|---|---|
| 角色堆砌 | 连续出现多个名字和对白 | 保留一个冲突场景，补抽象提炼 |
| 只有鸡汤没有动作 | 全文”要坚持、要努力” | 改为今天可做的一小步 |
| 直接大道理 | 开头就讲规律 | 先铺生活场景 |
| 过度绝对化 | ”永远""一定” | 加限定词”多数时候""往往” |
背后的原理很朴素：
- “做什么” → 描述一个无限大的可行域 → AI在里面随机游走
- “不做什么” → 在可行域上画边界 → AI的行为空间被收窄到你想要的范围
我把这个原则用到了我的知乎创作技能优化上。原来的SKILL.md写的是”应该怎么写好文章”，改成”写文章时不能做什么”之后，AI的输出质量明显稳定了。
原则三：给AI多大自由度？取决于任务有多”脆弱”#
skill-creator引入了一个自由度光谱：
| 自由度 | 适用场景 | 实现方式 |
|---|---|---|
| 高 | 创意写作、多解法任务 | 文字引导，启发式 |
| 中 | 有最佳实践但允许变通 | 伪代码+参数配置 |
| 低 | 格式控制、精确输出、命名规范 | 脚本锁死 |
关键判断标准只有两个：
- 做错了后果多严重？ — 越严重 → 越低自由度
- 有多少种”正确”的做法？ — 越多 → 越高自由度
举个例子：让AI写一篇技术博客，十个人写出十种风格都可以，你只需要给方向——这是高自由度。
但让AI生成一个YAML配置文件，里面有个short_description字段要求25-64个字符、首字母大写、不能有引号。差一个字符就出问题——这是低自由度，必须用脚本锁死 。
skill-creator自己就是这么做的。它有三个脚本：
init_skill.py— 初始化目录结构（低自由度，脚本保证合规）generate_openai_yaml.py— 生成配置文件（低自由度，格式约束）quick_validate.py— 校验输出（低自由度，格式校验）
中间夹着的”编辑技能内容”才是AI的发挥空间（高自由度），前后两端都是脚本保障（低自由度）。
这叫”质量保障链”——脚本夹住创造性的中间步骤，确保起点正确、终点合规。
落地：六步创建流程#
有了原则，skill-creator还给出了一个可执行的六步流程：
- 理解 — 用具体例子建立共识（不要一次问太多问题）
- 规划 — 分析哪些东西会被反复使用，封装成scripts/references/assets
- 初始化 — always 用脚本，不要手建目录（低自由度操作）
- 编辑 — 先实现可复用资源，再写SKILL.md
- 校验 — 跑
quick_validate.py检查格式 - 迭代 — 在真实任务上测试，发现问题再改
重点说第三步”初始化”——skill-creator用了”always”这个词，不是”建议”，是”必须”。
因为初始化是一个脆弱操作：目录结构对不对、文件命名规范不规范、手一抖就出错。用脚本执行，消除出错的可能。
三个月后，我用这个原则优化了知乎创作技能#
回头看我原来写的那个知乎创作技能（v8.7.0），SKILL.md有44,830字节，恨不得把每个细节都写进去。
按skill-creator的原则重构后：
| 对比项 | 优化前 | 优化后 |
|---|---|---|
| SKILL.md | 44,830字节 | 10,132字节（-77%） |
| 详细流程 | 全部塞在SKILL.md | 拆到references/workflow.md |
| 反模式清单 | 散落各处 | 独立references/anti-patterns.md |
| 格式校验 | 靠人工 | 新增scripts/validate.py |
优化后的技能结构：
zhihu-creator/
├── SKILL.md # L2: 核心指令（<5k词）
├── references/
│ ├── anti-patterns.md # "不做什么"清单
│ ├── workflow.md # 详细流程参考
│ └── ...
└── scripts/
├── validate.py # 输出校验
└── ...SKILL.md只保留最核心的操作指令（约2500词），按需加载的内容放到references/，scripts/执行而不读入上下文窗口。
你也可以试试#
skill-creator的设计原则，用一句话总结就是：
用最少的token，在正确的层级，给AI最精准的约束，让它在边界内自由发挥。
具体操作：
- 精简frontmatter的description — 写清楚”什么时候用”，不要写”是什么”
- 拆分SKILL.md — 核心指令<5k词，详细流程放到references/
- 加反模式清单 — 用”不做什么”画边界，比”做什么”更精确
- 关键操作用脚本 — 初始化、格式校验这类脆弱操作，不要手做
这套方法不限于Claude Code或OpenClaw。任何支持Skill/插件体系的AI产品，本质上都是一样的——你给AI的约束，决定了AI输出的上限 。
你有哪些AI技能优化的心得？欢迎评论区聊聊。