Anthropic 的 Skill-Creator 从来就不是一个单纯的 SKILL.md 生成工具。翻完源码和设计文档之后，我的感觉是它更像一套把技能开发从个人经验变成可度量、可迭代的工程体系——用测试、评估、基准对比这些传统软件工程的手段，让领域专家也能产出可控的 AI 技能。
先分清两种 Skill：能力提升 vs 偏好编码
Skill-Creator 的设计初衷建立在两个基本分类上：
- 能力提升型 Skill：让 Claude 做到基础模型自己不擅长的事，比如按特定规范生成文档或执行复杂分析。评估重点是有没有让结果明显变好。这类 Skill 可能会随着模型升级而过时。
- 偏好编码型 Skill：按组织工作流编排 Claude 已有的能力，比如 NDA 审查流程。评估重点是是否稳定遵守团队规范，需要持续验证是否匹配实际流程变化。
这两类的迭代策略不一样，能力提升型需要更频繁地对比模型进化后的效果，而偏好编码型则更关注流程对齐。
核心循环不是噱头，是研发习惯
Skill-Creator 的设计哲学简单直白：把产品研发的'假设 - 实验 - 度量 - 人审 - 迭代'循环搬了过来。它的具体流程是：捕获意图、面试式调研 → 写出初版 SKILL.md → 并行运行有/无 Skill 的测试用例 → 通过 Grader、Comparator 等智能体评分 → 人工审核反馈 → 改进后重新评估，直到达到上线门槛。
真正让这个循环跑起来的，是背后五个设计原则：
- 渐进式加载：Skill 内容分三层。Level 1 是元数据（名称和描述），始终在上下文中；Level 2 是 SKILL.md 正文，触发时加载；Level 3 是捆绑资源，按需加载。这种分层省 Token，也让模型更快定位。
- 无意外：Skill 不能夹带恶意内容，行为必须和描述一致。
- 解释 Why，而非强制 Must：文档里鼓励向模型解释'为什么这么做'，而不是死记硬背步骤，这样适配性更好。
- 泛化而非过拟合：从反馈中提炼通用规律，避免让 Skill 只对测试集有效。
- 人始终在环里：关键决策（审核测试结果、收集反馈）仍然靠人，自动化只处理重复评分和对比。
架构：三大模块加三个评分智能体
整个系统按'需求→实现→反馈'这条链路拆成三个功能模块：
- 创建模块：把用户意图转化为结构化 SKILL.md。内置了意图捕获和面试式提问，降低编写门槛。
- 评测模块：这是核心。依赖三个专门设计的子智能体：
- Grader Agent：对执行输出逐条评分，同时批判性评估断言质量。遵循'严格证据导向'，不确定时举证责任在期望一方。
- Comparator Agent：在不知道哪个输出来自哪个 Skill 的情况下盲比较，评分体系分内容和结构维度，采用 1-5 分。
- Analyzer Agent：有两种模式。事后分析模式解盲，识别赢家优势和输家劣势；基准分析模式只记录观察，不提出改进建议。
- 优化模块：根据评测结果和反馈持续改进，包括描述优化、循环改进、打包发布。
源码目录结构很清晰：SKILL.md（485 行核心定义）、agents/（子智能体指令）、scripts/（Python 工具如 run_eval.py、run_loop.py）、eval-viewer/（审核界面）等。
SKILL.md：身份卡与操作手册
文件头部是 YAML Frontmatter，必填的 name 必须用 kebab-case 且最长 64 字符，description 建议 100-200 词。实际 Claude Code 产品中支持的字段更多，比如 user-invocable。
description 的设计直接影响触发精度。Claude 有'欠触发'倾向，所以描述要带点推动性，用祈使语气明确告诉模型：什么场景、什么理由该用这个 Skill。
正文结构通常包括概述、沟通方式、执行流程、评估改进、高级功能、平台适配。写作上强调祈使语气、解释 Why、示例驱动，避免过度约束。
