给 Claude 写一份「专业入职材料」：Skill 设计方法论

我一直觉得给 AI 写 prompt 这件事被过度哲学化了。写提示词当然重要，但真正决定 AI 在特定领域能不能可靠运作的，是「它能不能在需要的时候拿到正确的知识」。

这件事有个更系统的解法：Skill。

Skill 是什么，不是什么

Skill 不是一段「让 AI 扮演专家」的人格设定 prompt，而是一个模块化的知识包——把专业的工作流程、领域文档、可复用的脚本和模板打包在一起，让 AI 在对应场景下从「通才」变成「有备而来的专业人员」。

我喜欢用「入职材料」来类比：一个新员工进入公司，不可能从零开始学所有领域知识。公司会给他一份 onboarding guide，里面有业务规范、常用工具的使用说明、历史决策文档。Skill 做的就是这件事——只不过对象是 AI。

Skill 的结构很简单：

skill-name/
├── SKILL.md          ← 必须有，工作流程 + 触发条件
├── scripts/          ← 可重复执行的脚本（Python/Bash）
├── references/       ← 按需加载的参考文档（schema、API 文档、业务规则）
└── assets/           ← 输出用的素材（模板、图片、字体）

关键在「按需加载」四个字。SKILL.md 只放核心工作流，详细的参考资料放 references/，AI 判断需要时才读入上下文。这个分层设计让 Skill 既不占用不必要的上下文，又在需要时能拿到完整信息。

设计一个好 Skill 的三个步骤

第一步：从具体例子出发，不要从抽象功能出发。

「我要一个 PDF 编辑 Skill」太模糊了。更好的问法是：「用户会说什么触发这个 Skill？」——「帮我把这个 PDF 旋转 90 度」「把第 3 页删掉」「给这个 PDF 加水印」。把这些例子列出来，执行每个例子需要什么，Skill 该打包什么东西就清楚了。

第二步：分析哪些东西值得打包进 Skill。

每个例子想象手动执行一遍：哪些代码每次都要重写？那就打包成 scripts/。哪些文档每次都要查？那就放进 references/。哪些模板每次都要找？那就放进 assets/。

不要把什么都塞进去，只打包「重复出现」或「确定性要求高」的东西。一个常旋转 PDF 的场景，有一个 scripts/rotate_pdf.py 就够了，不需要把 PDF 格式规范整个塞进去。

第三步：写 SKILL.md 时，想象在给另一个 Claude 写操作手册。

这是最容易忽视的一点。SKILL.md 的读者不是人，是另一个 AI 实例。用指令体（verb-first），写清楚「什么情况下用这个 Skill」「怎么用打包好的资源」「遇到什么情况停下来问人」。不要写成哲学散文，写成可执行的操作步骤。

Skill 的迭代是主线，不是尾声

一个 Skill 不可能第一版就完善。真正的收益来自「用了之后发现哪里不顺手，立刻更新」的闭环。

好的迭代路径是：用 Skill 完成一个真实任务 → 观察 AI 在哪里卡住、哪里绕远路 → 判断是 SKILL.md 说得不清楚、还是缺一个 references 文档、还是某个脚本该自动化 → 更新对应的文件。

这个过程跟写代码很像：先跑通，再重构，别一开始就想着大而全。

取舍与边界

Skill 适合的场景：有固定工作流的专业领域（数据处理、文档生成、特定 API 的集成）、团队/个人有需要反复调用的知识资产。

不适合的场景：一次性任务、流程还没稳定下来的探索期。对探索期的任务，直接在对话里解决就好，等它稳定了再沉淀成 Skill。

还有一个常见误区：把 Skill 当成「让 AI 无所不知的超级系统 prompt」来设计，结果 SKILL.md 写了几千字，references 堆了几十个文档。这样上下文预算会被吃空，反而影响任务质量。Skill 要设计得「刚好够用」，多余的信息是负担不是保障。

一句话心法

Skill 的价值不在于「告诉 AI 更多」，而在于「在对的时刻给 AI 对的知识」——程序性、模块化、按需加载。