题图
（题图由AI生成）

工作这些年，我越来越相信，很多人和我一样：很多事情，其实是有固定流程的。写代码要遵守代码规范，跑命令要按命令用法来，做研究有一套从检索调研、筛选精读，到设计实验、分析数据，再到解读结果、总结结论，最终到成文的方法。这些流程，是我照着自己踩过的坑，为自己量身定制的——有的正好能作为通用经验，拿出来当建议分享；有的却是我自己的内部信息，换成别人未必适用。它们是多年里一次次踩坑、复盘、沉淀出来的。以前它们只能记在我脑子里，顶多写进备忘；当 Skill 这个概念出现时，我当即意识到，这正是专门存放这些“规范”的地方。

今天看到一个 Hacker News 的讨论——Ask HN: How do you manage skills files?——几十个重度用户在里面聊自己是怎么管理这些 skill 文件的。这篇就当作一个记录：把我觉得重要的经验摘出来，配一点我自己的真实实践感受。

整场讨论里我最认同的一句是：“Skills are workflow caches”。它就像一份操作手册（runbook），或者一个宏——把一次性的摸索，固化成一整套可复用、可版本化、可测试的指令。也许你跟我一开始一样，以为 skill 是让模型变聪明的快捷方式，塞进去一个它就能超常发挥。其实不是——它不是在给模型灌知识，而是在省掉它重复探索的时间。 同一件事，模型第一次可能要搜半天、试好几轮才做对；有了 skill，它照着走就行。它省下的是“重新找、重新摸索”的力气，而不是替它写出它本来想不出来的东西。

这一点我很有体会。我平时用的是 Zed 编辑器，日常会挂着一套 skill 当自己的“使用手册”。以我最常用的 terminal-usage 为例，它记的是跑命令前先做的那套自检：把 head_lines 这种工具参数当成 shell 命令写进命令串里、把和 /tmp 一起的命令拼在一起导致中间文件被清空、读 git 忘了加 --no-optional-locks。这几条其实更像这个 harness 当前版本的“脾气”——具体会在哪个环节栽跟头，跟版本关系很大。我把它们整理成一条发命令前的自检清单，放进 skill 里，让 Agent 跑命令前先看一眼。有了它，这些坑便很少再发生。这就是缓存的意思——不是让模型变聪明了，是让它不用再从头探一遍。

第二个我想记录的经验，是值得建 skill 的时机。 讨论里说：一个 skill 只该记录模型自己“做不到、或做得很差”的行为；更稳妥的测法是拿一个它失败的案例，写好 skill，再用同一个案例去测它。判断句式则是这篇文里最好用的一条——能用“how to do X”说清楚的，值得沉淀；说不出来的，通常别建。

我的实践感受是，“猜不到”往往比“做不好”更值得建。做不好的事，多半是它能力边界内的平庸，写个 skill 让它照做即可；可“猜不到”的，是它再聪明也永远不知道的东西——比如我自己给博客定的那些私人约定：文件名要用 YYMMDD-标题、题图要用 SVG 别转 PNG、正文里的中文引号要用全角、结尾要附 AI 注记、发布前必须跑 hugo 和 check_slugs.py。这些它无从揣测，因为写在我的个人流程里。这类东西我明确写进了项目 AGENTS.md。反而是“写一段排序、调个参数”这种，我从不建 skill，它本来就擅长。

说到用失败案例来测，这是判断一个 skill 立不立得住最直接的办法。我写完或让 Agent 沉淀完一个 skill，更常用的验证方式是直接开个新会话，把当初让它失败的那个场景原封不动再丢一次，看它这次能不能一遍过。能过，这个 skill 才算真的实用；一遍过不了，就是它还没吃透我的流程，还得改。

但有一点常常被忽略，也是我最想补的：skill 并不是各种模型都通用的。 换个模型，它“能不能自己做到”的边界就不一样。于是同一个 skill 换个模型，需要描述得多细、侧重强调哪一点，都得重新掂量。若照搬原来的描述，反而可能让 AI 降智。有些事你不说，它反而做得更好；可你偏要把它们写进 skill，于是总在跟它反复拉扯。你框定的那些说辞，作为自然语言并不能精确描绘你想要的边界；框定之后，反而把它的思考和推理局限住，容易钻死胡同。所以我现在的环境，其实是固定在一个特定组合上的：模型是 deepseek-v4-flash-vision-exp，框架是 Zed 的 harness。这些描述针对它来写，适配它的粒度和边界，才免得“写得太细”反而变成“束缚”。

第三个我想记录的经验，关于怎么写好一个 skill。 讨论里强调两点：只记录“怎么”和“为什么”，把“是什么”留给模型——API、语法它早就学会了，你要写的是“在本仓库里加一个接口要走哪几步”这种项目特有的流程；以及把能确定的部分固化到脚本里——能用代码确定性表达的，就写成脚本让 Agent 调，别让它一步步自己来。

这块我深有体会。博客这套东西，最省我心的不是告诉 Agent“怎么建站点”，而是直接给它 scripts/ 里那几个确定的脚本：check_slugs.py、check-images.py、generate-og-image.sh、build.sh。这些是确定性的——跑得通就是跑得通，Agent 不用猜，我也不用反复交代步骤。脚本负责确定的部分，文字负责判断的部分，这是我这几年来最认可的分工。

但我也想补一个自己的教训：确定性硬标准，不能只靠 skill。 skill 本质是“建议”，模型可能遵循也可能跑偏。真正“必须满足”的，比如 slug 不能重复、hugo 必须无警告，我是靠脚本和构建命令来兜底，而不是靠 skill 的“良好意愿”。讨论里说这类要靠 hooks，我现阶段的做法，是把校验写进 build/check 脚本，让 Agent 每做完一件事必须跑一遍才算完。skill 用来指路，脚本用来卡底线——两者我都不省。

第四个我想记录的经验，是 AGENTS.md 和 skill 的分工，以及渐进披露。 讨论里说，AGENTS.md 每次请求都加载、还享受 prompt 缓存，适合放小而稳的高层“事实”；内容多、只在特定场景才需要的，放 skill 按需加载；也可以做“路由”写法，让 AGENTS.md 指向一堆小的 .md。

这段话我认同它的方向，但落到自己身上，边界其实没那么泾渭分明。我能想到的、也是自己一直这么做的，是给它一个朴素的坐标：那些高频且“无论如何都不想犯的错”，我放在每次都会加载的地方——它们就该一直生效，而不是“按需再想起来”；而那些又专又深的，才放进按需加载的 skill，比如我那一套小企业会计准则的规则，还有做研究的流程，因为它们太细、太偏，不可能每次请求都背着。

更重要的是，这个坐标不是一成不变的，而是跟着我一起进化的。用久了我越来越适应 AI：慢慢知道哪里该多写几句、哪里干脆放开让模型自己发挥。同样的场景，我刚上手时恨不得逐字逐句交代清楚，现在却常在几个关键点上画个圈、其余放它去试。这个边界，会随着模型和框架的更新、随着我和它的磨合，一趟趟被重新校准。我现在的环境就局限在单一模型（deepseek-v4-flash-vision-exp）和单一框架（Zed harness）上，正因为够窄，磨合起来也更快——每天大量地用它，它便越来越“懂”我。

第五个我想记录的经验，有关skill 的进化和维护。 讨论里说，遇到卡点就是该建 skill 的信号；别自己“找”skill，而是让 Agent 生成、你再亲自验证；还可以在全局 AGENTS.md 里加一条自改进指令；并强调 less is more，多数重度用户只留 3~9 个高价值 skill，且定期修剪、删旧。

“让 Agent 生成、你亲自验证”这点我很认同。我自己现在几乎不“起笔写”skill——因为亲手写很容易写成一份理想化的说明书，跟真实用法脱节。我更喜欢让 AI 先做成一件事，做对了，就让它把过程沉淀成 skill，然后清空会话单独验证，直到它零样本能用为止。

有意思的是，这一步并不只在“创建”时发生，日常的维护，其实也是 AI 自己在做。 那些临时的调整、新踩的坑、旧写法被推翻的瞬间，AI 自己就能总结、提炼，把它们整理成适合作为规则的一段文字——它比谁都清楚什么东西值得沉淀成规则、该怎么措辞才不会被它自己反噬。我要做的，往往只是把它得出的那几条过一遍，剔除不想保留的，然后收下来。这比让我亲手去维护一份操作手册要省心得多，毕竟这些规则最终要喂回给它自己，它知道怎么把自己描述得更准。

至于自改进，我这边恰好有个与之相像的习惯：项目 AGENTS.md 里有一条“规则维护”——凡是解决问题时得到的、可复用的经验，都问一句“要不要加进 AGENTS.md 或全局 AGENTS.md”，确认后才加。这让我的积累不是临时的，而是真正沉淀了进去。

关于“只留 3~9 个”，我这边其实是“按需加载”在帮忙——多数 skill 只在被触发时才进上下文，所以我即便攒得多，也不至于把上下文撑爆。但“多”终究有代价：那些从没再触发过的，留着只是心理安慰。定期删一删，反而轻省。这一点我还是认同讨论里的说法。

最后一条，是别把 skill 当万能药，也别照搬。 讨论里说，那种“通用能力”型 skill（设计评审、code review、落地页制作）会随模型变强而越来越没用；反而信息密集的内部知识——比如“连哪个内部服务该用哪组 key、登哪个账号”——永远比让模型瞎猜一遍省。另外要警惕 all-in-one skill pack（多为营销），对模型自己生成的 skill 也要审查——skill 仓库里的错误，会扩散到你用 Agent 写的所有新代码里。

这点我很有感。模型自己生成的 skill，我从来不会照单全收——让模型沉淀完，我最后还是会扫一眼最终产物，确认它没夹带我不想保留的决定。这一点跟我在《做研究需有自证清白的觉悟》里讲的其实是同一件事：AI 给的东西，得自己验一遍才算数，不能因为“是 AI 生成的”就默认可靠。

还有个更底层的区分，我觉得是全场最值得记录的一句：规则告诉 AI 何时做某事，skill 告诉 AI 如何做某事。 tool 调用和 MCP 的限制、Agent 配置、harness 扩展，是帮它“留在正轨”；skill 是在留下来之后，告诉它这一步具体怎么走。两者定位不同，别混为一谈。

顺着效率这条线，还有一层更远的地方值得想一想。现在我的这些 skill，基本都是平铺着的，靠 AI 按需来取。对上下文空间足够大的模型来说，把内容都搁在上下文里、随时取用关键信息，至少是“可行”的——可“可行”不等于“合适”。人脑其实也差不多，没法同时装下太多事，说穿了就是一个有限的“上下文窗口”；而 AI 的上下文窗口，同样不是无限的。

所以，提高信息的使用效率，迟早是绕不过去的事。眼下还能靠“按需加载”兜住，可当 skill 越攒越多、彼此还开始交叉的时候，怎么让它们之间更有序、查找更快、占用更省，大概会成为 skill 这种形态下一个真正值得摸索的方向。

所以绕来绕去，我想说的其实落到一句话上：别让自己反复重复，尤其是反复重复某几句提示词、某几处强调。 那些固定流程所以值得进 skill、进 AGENTS.md，不就是因为它们老被重复吗？把重复的沉淀下来，剩下一次性的判断，才值得你亲自开口去说。Skill 不是让模型变聪明的补丁，而是替你把“说过的话”收好，让它别再让你说第二遍。

它也更像是一套和我一起长大的顺手工具——我越来越知道哪里该写细、哪里该松手。我会继续用，但也会给自己加一条：别让它堆成负担。

如果你也在跟 Agent 相处，可以试试从你最常重复交代的那一句话开始，把它变成一个最小的 skill，然后开个新会话，用当初的失败场景测一次。跑通了，你大概就会明白：省下来的不只是 token，更是你一遍遍复述的耐心。

--- END ---

注：本文由AI辅助润色，文章内容与观点均由作者本人提出并复核。