我的 Claude 里躺着约 30 个 skill,但说实话,绝大多数是我用一个「skill 生成器」一口气吹出来的,从没被认真打磨过。Anthropic 的 Thariq Shihipar 写了一篇文章,把内部几百个 skill 的经验蒸馏成「好 skill 和平庸 skill 差在哪」。我没停在读后感——把自己那个供应链 skill Replen 搬上手术台,拿他的判准逐条打分。结果有点扎心也有点提气:几条它已经做对了,但信息量最高的那一段,完全缺席。
别被名字唬住。一个 skill 在硬盘上,就是一个文件夹 + 一个文本文件(SKILL.md),有时再加几个附属资料。文件最上面那段说明(name + description)是全局最关键的东西。
打个比方:你雇了 30 个专家,每人门上挂一块门牌。你一开口,Claude 不会把 30 个人全喊进来,而是扫一遍所有门牌,看谁的牌子跟你现在说的事对得上,就敲谁的门。门牌(description)= 什么时候该叫我;门后面的正文,是这位专家干活的手册。所以一个 skill 好不好,一半胜负在门牌写得准不准——牌子写错,专家再厉害也没人叫他。
文章的核心判断很清醒:skill 之所以成了 Claude Code 里用得最多的扩展方式,恰恰因为门槛极低——谁都能写。但门槛低的另一面是,大多数 skill 都很平庸。Anthropic 内部用了几百个,才总结出「好」和「平庸」的分界线。作者先把 skill 分成 9 类,让你先认清自己要做的是哪一种:
讲清某个库或 CLI 怎么用、有哪些边界和坑
测试并验证代码真能跑——文章说这类对产出质量的可测量提升最大
接上你的数据 / 监控栈、凭证和看板
把重复流程自动化,用日志文件保持每次一致
用自然语言的需求,生成框架样板代码
把组织标准落地、辅助 code review
拉 / 推 / 发代码,带自动化测试
系统化地查症状、产出结构化报告
带护栏地做例行维护
文章讲了一大串,我挑出对「会用、想做好」的人最要紧的八条。中间那条被作者原话标成信息量最高——记住它,后面全靠它给我判死刑。
skill 里只放它不知道的东西——你的规矩、你的坑、你公司的习惯。通用知识它自带,写进去是浪费,还稀释信号。好内容要「把它推出惯常思路」。
作者原话:一个 skill 里信息量最高的,就是 Gotchas 段。把 Claude 反复踩的坑写下来——这个表只能追加不能改、那个字段跨系统命名不一致——比写一堆正确流程都值钱。
description 是给 Claude 扫的,不是给人读的。要塞触发词(像 babysit、debug 这种你一说就该激活的词),它才找得到你。
主文件写精华,细节丢到附属文件里,Claude 需要时才去翻。文章叫它 progressive disclosure(按需展开)——把文件夹当成上下文工程的工具。
给它必要信息和判断依据,别写成一步都不能改的死脚本。作者叫「别把 Claude 架在铁轨上」——留点灵活度,它反而干得更好。
靠持久文件给 skill 装记忆:追加式文本日志、JSON、甚至 SQLite。让它跨会话记得「上次怎么定的」,而不是每次从零。
把可复用的函数 / 计算存成脚本,让 Claude 专注在「怎么组合、怎么判断」,而不是每次现场把公式手搓一遍(还容易搓错)。
给危险操作装按需触发的护栏:/careful 挡住 rm -rf、DROP TABLE,/freeze 只允许改指定目录。加上一句:从最小开始,踩坑再补。
Replen 是我把 CPIM 供应链计划知识 + 自己的实战经验熔成的一个「资深计划员」。它长这样:一个 SKILL.md 写角色和规则,一个 references/cpim/ 放各模块细节。拿上面八条量下来——
references/cpim/,规则里写「不确定就查对应模块再答」——教科书式的 progressive disclosure。打完这张表,结论很清楚:Replen 在「门牌 / 分层 / 不写死」这三条上,其实做得不错——这大概是那个生成器的默认模板攒下的底子。但真正把好 skill 和平庸 skill 分开的三样东西:坑、记忆、脚本,它一样都没有。而它们,恰好是生成器吹不出来、只能我亲手喂的东西。
既然 Gotchas 是最高信号、又完全缺席,那这一刀最值。学 skill 最好的方式不是再读一遍文章,是就地把学到的用在自己的东西上。下面这几条,是我从真实供应链工作里刮出来的坑——每一条都符合那句判准:把 Claude 推出它的惯常思路。
安全库存对 lead time 的方差远比对需求方差敏感,可 ERP 里的 lead time 常是个没人维护的过时固定值。算 safety stock 前先问:这个 LT 是真实近况,还是三年前建档时拍的?——别直接信系统默认值。
MOQ / rounding / lot-sizing 会把「净需求 3 个」放大成「订 500 个」。看 MRP 跑出来的建议,先看批量参数再看数量,否则你以为的缺货补货,其实是一柜子呆滞的开始。
老板嘴里的 service level 经常指 fill rate(按量满足率),而安全库存公式里的 service level 是不缺货概率(按周期)。两个不是一回事。先问清是哪一个再动手,不然算出来的 ss 是对着错题解的。
效期品要先出近效期批次(FEFO),但很多 WMS 默认按 FIFO 拣货。这一层最容易在系统里埋雷、到货架上才发现——过期报废时才想起来,晚了。
放大波动的真凶,多是批量订货 + 促销 + 长前置期 + 层层加保险库存,而不是终端需求本身在剧烈跳动。看到剧烈波动先别喊「客户善变」,先查自己这条链上有几层在各自加码。
补完这段坑清单,再顺手做两件小事,判准 06 / 07 就一起补上了:一个 safety_stock.py——输入 LT 的均值和方差、需求的均值和方差、目标 service level,直接吐出安全库存和再订货点,省得每次手算(判准 07);再加一个追加式的参数日志,把每次为某个 SKU 定的参数和理由记一行(判准 06)。三样机器喂不出来的东西,一晌就能亲手喂进去。
生成一个 skill 很容易,
「造」一个不容易.
这篇文章真正点醒我的,不是那 9 个分类,是它逼我看清:我那 30 个 skill 大多是生成的,不是造的。生成器能给你一块像样的门牌、一套还行的分层——但坑、记忆、脚本这三样,它给不了。因为坑是我踩出来的,记忆是我这份工作攒出来的,脚本是我知道该算什么才写得出来。
这和我这个站子一直在讲的是同一句话:认知变免费之后,专业值钱在「你踩过而它没踩过」的那一段。放到 skill 层面,答案朴素得可爱——就是那段 Gotchas。Claude 会所有教科书,但它没在半夜被一个过时的 lead time 坑过,我被坑过。
所以我给自己立了条规矩:以后读到的每一样 AI 新东西,尽量不停在「看懂」,而是就地上手改一件自己的东西。这篇的下一步,就是把补完 Gotchas + 脚本 + 日志的 Replen 真的跑一遍。
—— 这是「AI 学习记录」的第 1 篇。看到什么、动手改了什么,都收在这里。