- 主题：把“高频且需要一致性”的工作沉淀为可触发、可执行、可迭代的 Skill（标准作业程序）。
目录
一、你要写的不是“提示词”，而是一份可执行的 SOP
作为一名开发者，用了 AI 之后，工作速度确实变快了：改页面、联调接口、写排障记录，都能很快推进。直到有一次做国际化改造——把中文文案收口到语言包里，并替换掉代码里的硬编码。我以为这就是 AI 的舒适区：扫描、提取、替换，一气呵成。
事实上，AI 确实很快，但很快也暴露了问题：同一句话被拆成不同 key、命名风格不统一、少数文案在替换时“看起来对但其实不对”。这些问题往往不立刻报错，却会在测试和后续迭代里不断返工。
那一刻我明白了：AI 最大的风险不是慢，而是 “自信地偏离规范”。
于是我开始用 Skill，把国际化这类“高频且需要一致性”的工作写成一张工位卡：
- 什么时候触发
- 按什么步骤做
- 产出什么格式
- 做到什么程度算完成
- 不确定就先澄清，不靠猜
二、什么是 Skills？
Anthropic 的 Skill（简称 Skills）概念，本质上是在给 Agent 配一套 可移植、可版本化、按需加载 的“标准作业程序”。它不是让模型变聪明（模型已经很聪明了），而是让模型在某类任务上更稳、更一致、更可审计：
- 该问什么
- 该怎么做
- 用什么工具
- 做到什么程度算完成
官方文档核心入口：
示例仓库：
https://github.com/anthropics/skills/tree/main/skills/skill-creator
下面将针对 skill-creator 深度分析 Skill。
三、Skill 深度分析
核心思想 1：Skill 是“上岗培训手册”，不是“更长的提示词”
skill-creator 对 Skill 的定位非常工程化：它把 Skill 比作特定领域/任务的“上岗培训”。
“Think of them as "onboarding guides" for specific domains or tasks—they transform Claude from a general-purpose agent into a specialized agent equipped with procedural knowledge…”
解释：
- 写 Skill 的目的不是“让模型更聪明”，而是把模型不可能内置的流程知识（procedural knowledge）、团队规范、工具用法打包进去。
- Skill 的产物应当像 SOP：可复用、可审计、可迭代，而不是一次性的对话技巧。
核心思想 2：渐进式披露（Progressive Disclosure）
skill-creator 直接给出 Skill 的三层加载模型：
“Skills use a three-level loading system to manage context efficiently:
- Metadata (name + description) - Always in context (~100 words)
- SKILL.md body - When skill triggers (<5k words)
- Bundled resources - As needed by Claude (Unlimited*)”
解释：
- 常驻上下文：只留“能否触发”的信息（元数据）。
- 触发后加载：
SKILL.md只放“指挥流程”的内容（建议 < 5k words）。 - 细节与确定性：交给
scripts/、references/、assets/，按需加载/执行。
这条原则会自然推导出后面所有写作准则：哪些该写进 SKILL.md，哪些必须拆出去。
这种方式配合 Agent 工作流，就构成了完整的 Skill 运行方式：
- 发现阶段：启动时只加载每个 skill 的
name + description（大约几十到一百来 tokens），让 agent 知道“我有这些能力”。 - 激活阶段：当任务命中描述，agent 才把完整
SKILL.md读进上下文。 - 执行阶段：需要脚本/模板/参考资料时，再去加载文件或执行代码。
小结：**skill 写得好不好，首先看它是否“省上下文但不省关键”。**你要把信息按层切开：常驻的只有“何时用我”；真正的细节等被调用再展开。
四、SKILL.md 的基本骨架
skill-creator 规定每个 Skill 至少包含 SKILL.md，并鼓励用资源目录分层：
“Every skill consists of a required SKILL.md file and optional bundled resources…”
典型结构（示例）：
skill-name/SKILL.mdYAML Formatter: name,description 等元数据Markdown instructions: 执行指令
scripts/（可选：可执行脚本，强调确定性与可复用）references/（可选：按需加载的资料库、schema、长例子）assets/（可选：用于产出物的模板/素材，不用于理解）
元数据准则：name 与 description 决定 Skill 的“被发现能力”
skill-creator 明确指出：决定 Claude 何时用 skill 的，是 YAML 里的两行字。
“Metadata Quality: The name and description in YAML frontmatter determine when Claude will use the skill. Be specific about what the skill does and when to use it.”
它还要求 description 使用第三人称：
“Use the third-person (e.g. "This skill should be used when..." instead of "Use this skill when...").”
具体规则：
name：建议用 hyphen-case（小写 + 短横线），并与目录名一致。description：必须包含“何时用”的具体触发场景（任务类型/文件类型/用户话术）。- 避免结构性符号污染：
quick_validate.py会检查description不应包含<或>。
内容写作准则：把 SKILL.md 写成“给另一个 Claude 的操作规程”
skill-creator 强调 SKILL.md 的语体并非审美问题，而是为了“可执行”。
“Writing Style: Write the entire skill using imperative/infinitive form (verb-first instructions), not second person. Use objective, instructional language…”
解释：
- 读者不是人类用户，而是“另一个要执行流程的 Claude”。
- 用动词开头的指令体（例如“验证…/读取…/提取…/生成…/检查…”），能显著减少模型在语气层面的自由发挥。
skill-creator 还给了写作时必须回答的 3 个问题（这就是最小可行 SKILL.md）：
- purpose：这个 skill 让 Claude 能做什么（1–2 句）
- when to use：什么时候应该触发
- how to use：实际执行时怎么做（并明确引用
scripts/、references/、assets/）
资源分层准则：把“确定性”交给脚本，把“查阅型信息”放到引用
scripts/：重复劳动 + 可靠性
skill-creator 对脚本的定位非常清楚：
“Executable code … for tasks that require deterministic reliability or are repeatedly rewritten.”
适合放进 scripts/ 的内容：批处理、格式转换、自动化操作、可复用的工具脚本。
references/：让 SKILL.md 保持瘦身
它对 references/ 的定位是“按需加载到上下文的资料库”，并且给出强约束：
“Avoid duplication: Information should live in either SKILL.md or references files, not both… Keep only essential procedural instructions and workflow guidance in SKILL.md; move detailed reference material, schemas, and examples to references files.”
另外还有一个非常实用的提醒：
“Best practice: If files are large (>10k words), include grep search patterns in SKILL.md”
简单来说就是：references/ 可以很长，但要给“可搜索的入口”，否则资料越多越难用。
assets/：用于产出，而不是用于理解
skill-creator 明确指出 assets/ 的原则：
“Files not intended to be loaded into context, but rather used within the output Claude produces.”
例如模板、logo、字体、样板工程等。
skill-creator 的创建流程准则：先例子，再抽象，再打包分发
它把写 Skill 变成 6 步流水线：
- Step 1：用具体例子理解需求（并提醒：不要一次问太多问题，先问最关键的）
- Step 2：从例子反推可复用内容：哪些该脚本化、哪些该进
references/、哪些该做成assets/ - Step 3：初始化：新建 skill 时优先运行
scripts/init_skill.py生成标准骨架 - Step 4：编辑：先落资源，再补
SKILL.md；删掉用不到的示例目录与文件 - Step 5：打包：用
scripts/package_skill.py，先校验再产出 zip - Step 6：迭代：真实使用后更新
SKILL.md或资源，循环优化
五、总结
Skill 写作的关键不在“写得长”，而在“写得可触发、可执行、可迭代”。用高质量的 name/description 让它被正确发现；用渐进式披露把 SKILL.md 控制在“流程指挥”层，把细节放进 references/、确定性放进 scripts/；最后用校验与打包流程把 Skill 当作一个可分发的工程产物维护。
