用元提示词生成 Skill，用 /doctor 精简配置

前面九节讲了能配什么。这一节讲两件相反的事：怎么让它替你写，以及怎么定期让它替你删。

一、别自己写，让它写

「我知道要做什么，但不知道规则该怎么写」——这是空白页问题。

它有专门的解法。原理见文章区的让 AI 帮你写提示词：元提示词。

落到 Claude Code 里，做法就是直接说：

我每次整理访谈稿都要重复交代这些：

〈把你平时说的那一大段原样粘上来〉

帮我做成一个技能，放在 ~/.claude/skills/ 下面。
描述那一行要写得能被「访谈编码」「提取主题」这类说法触发。
正文写成常驻指令，不要写成一次性步骤。

关键是最后两句。 它们对应的是技能的两个真实性质：

• 描述决定它会不会自己想到用
• 正文一旦加载会留到会话结束，所以要写成常驻指令

见Agent Skills 的创建、结构与调用。

让它先问你

更好的做法是不要一次说完：

我想做一个处理访谈稿的技能，但我自己也没完全想清楚要求。
先别写文件——你先问我几个问题，把要求问清楚，
然后给我一份草稿，我确认了你再写进去。

这一步的价值：你以为自己讲清楚了的地方，往往是它会问的地方。在写文件之前把这些问出来，比写完再返工便宜。

从真实的失败里长出规则

这是最靠谱的一种来源：

刚才这一版的问题是把两句口语合成了一句。
把这条加进 ~/.claude/skills/interview-coding/SKILL.md，
写在最前面。

规则最好的来源是它真的犯过的错，不是你想象中它可能犯的错。

想象出来的规则通常写得太宽、太抽象，反而稀释了真正有用的那几条。

二、定期删

配置会自己长胖。 三个月之后你会有：

• 一份两百行的 CLAUDE.md，其中一半是当时的临时情况
• 七八个技能，其中三个你已经忘了存在
• 一堆自动记忆，里面写着已经不成立的事

这些不是中性的。 它们会挤掉真正该生效的那些。

/doctor 是干这个的

/doctor

它会做四件事：

「CLAUDE.md 精简」那一条是它最有价值的能力。

它的取舍标准很准：目录结构、依赖列表、架构概述这类它自己能看出来的，删；踩过的坑、为什么这么做、和工具默认行为不一样的约定，留。

「从来没被调用过」通常不是「用不上」

这一条值得单独说。

一个技能装了三个月一次没被触发，可能有两种原因：

1. 确实用不上 → 删掉
2. 描述写得不对，触发不了 → 改描述

第二种比第一种常见。 你写描述时用的是自己脑子里的说法，但你实际提问时用的是另一套说法。

验证办法：直接输入 /技能名 手动跑一次。 跑出来的结果是对的，那就是描述的问题，不是内容的问题。

技能清单是有预算的

这一条决定了「留着不用也没关系」这个想法不成立：

技能清单本身占的地方有上限——默认是上下文窗口的 1%。超了会从最少用的开始丢描述。

丢了描述的技能，它就想不到该用。

所以：装的没用技能越多，你真正常用的那几个越可能失效。

用 /skills，按 t 按占用大小排序，用空格把不用的关掉。

一份季度自检

每隔两三个月做一次，二十分钟：

第 4 步有个好用的判断：

如果你想不起来这条规则是为了防什么问题，那它多半可以删。

一个反面案例

一种常见的演化路径，值得避开：

第 1 个月：CLAUDE.md 二十行，很好用
第 2 个月：加到六十行，还行
第 3 个月：一百五十行，开始觉得「它好像没那么听话了」
第 4 个月：又加了三十行去强调那些不生效的规则
第 5 个月：两百行，大部分规则都是概率生效

第 4 个月那一步是关键的错误。

规则不生效的时候，加更多规则去强调它，是在往反方向走。 更多内容意味着每一条的权重更低。

正确的动作是删掉别的，让这一条突出来。

全手册到这里

五章三十八节，从「Claude 是什么」到「怎么让这套配置自己维持下去」。

如果只留三句话：

① 换引擎能解决的问题，不要靠调提示词去解决。 见六个使用入口与三套系统提示词引擎。

② 交办任务时，把「怎么验收」也说出来。 这是终端版相对网页版最大的优势——它能真的跑一遍去核对。见任务交办的六个要素。

③ 配置越少越好用。 定期删，比不停加更重要。

手册讲的是怎么用工具。 具体到某一类工作该怎么做——录音怎么处理、长文档怎么拆、结论怎么核——那些在文章里。

本节事实查证日期：2026-08-05。 依据：官方 Commands 中 /doctor 与 /skills 的说明， 以及 Extend Claude with skills 的清单预算部分。