给Claude写100页说明书，不如写对一行坑点：Anthropic第一性原理

六月，Anthropic发了一篇博客，讲他们团队在 Claude Code 里搭建技能系统这一年踩过的坑、验证过的假设、以及那些反直觉的发现。标题朴实到几乎劝退——《Lessons from Building Claude Code: How We Use Skills》。但读完之后，我在屏幕前安静了大概三十秒。

不是因为技术有多复杂。恰恰相反，是因为里面的核心洞察简单到你忍不住怀疑：「这么明显的事，为什么我们花了这么久才说清楚？」

那就是：给AI塞更多知识，很多时候不是在帮它，是在烦它。

我们解读最新技术，文末有相关信息。

作者：张长旺，图源：旺知识

「重复Claude默认就会做的事，只会增加上下文，不增加价值（adds context without adding value）。」

换句话说，你辛辛苦苦写的长篇提示词，有相当一部分不仅没用，还占用了AI真正的「思考空间」。

这让我想起大学时考前突击，借了同学整理的「超全复习笔记」，厚厚一叠，事无巨细。结果翻开之后发现真正帮我答对题的，往往是页边用铅笔潦草写的那几句「老师说过这题必考」「此处公式与教材第三版不同，用新版」。剩下的内容，教材上都有。

Anthropic的技能系统，本质上就是在做这件事：不是给Claude写更多说明书，而是告诉它——哪些地方「教材上写的和实际不一样」。

九类技能，一个共同答案

在深度使用了数百个内部技能之后，Anthropic团队把这些技能归纳成了九个类别。

有做代码审查的（比如那个会派「新鲜眼光」子智能体来挑刺的 adversarial-review），有做产品验证的（用 Playwright 或 tmux 实际跑应用、录视频、做断言），有做数据拉取和分析的，有做 CI/CD 部署的一套流程，甚至还有给 on-call 工程师用的排障手册——从一个告警出发，调用多个工具交叉排查，最后产出一份结构化的排查报告。

读到这里我其实没什么感觉。技能分类嘛，哪个大厂内部没有几套「最佳实践」文档库？

但让我突然坐直的是接下来的那句话——对这九类技能做了一个评价排序。

产品验证类技能「对Claude的输出质量有最可衡量的影响」。

注意，不是代码生成类，不是架构设计类，不是代码审查类——而是验证类。

你仔细想想这个结论的分量。

它意味着，在知道怎么写代码这件事上，Claude已经足够好了。真正拉开输出质量差距的，是它能不能「亲眼看到自己的代码跑起来，然后根据真实反馈修正」。

这多像一个刚入职的初级程序员：代码能力不差，但如果不给他一个能跑起来的本地环境、让他亲眼看报错日志、亲手调试——他写出来的东西就是「看起来对但实际跑不通」。你给他配一台能跑项目的电脑，比给他买十本编程书管用。

原文甚至直白地建议：「花一周时间把验证技能打磨到极致。」

一周。不是优化推理能力，不是升级模型版本——就是让AI能自己跑代码、自己看结果、自己判断对不对。这种投入产出比，和大多数人直觉里的「AI提升路径」完全是反的。

最高信号的信息，叫「这里不一样」

博客里有一个表述我反复看了好几遍：「任何技能里信号密度最高的内容，是『坑点』（Gotchas）部分。」

什么叫坑点？就是那些「文档上写的和实际行为不一致」的地方——比如某个数据表是只追加不修改的，比如跨服务的字段名表面一样其实含义不同，比如预发布环境和生产环境在某个配置上的默认值差了一行。

读到这我突然理解了为什么「不要重复AI已知的东西」是这篇博客的第一设计原则。因为AI就像一个记忆力超群但缺乏实战经验的实习生——它把公开文档背得滚瓜烂熟，却不知道你公司那套内部框架有个边缘情况是文档里从没写过的。

而技能系统真正在做的事，不是教AI「怎么做事」，是教它「哪些事和你预想的不一样」。

这个洞察让我想起认知心理学里的一个概念：元认知（Metacognition）。它不是「知道什么」，而是「知道自己不知道什么」——以及「知道自己以为知道的东西在什么条件下会失效」。

人类专家和新手的核心区别，往往不在于知识的数量，而在于专家能精准识别「这里是个坑」。新手看到一段代码，觉得「都看懂了」；专家看到同一段代码，会指着其中一行说「这里在并发场景下会出问题」。

Anthropic的技能系统，本质上是在用人类的「坑点经验」补齐AI的元认知短板。

你不需要教Claude怎么写Python。它本来就会。你需要告诉它的只有一句：「这个项目中所有的时间字段用的不是UTC，是美东时间，别问为什么。」

一百页说明书，不如一行坑点。

把技能装进文件夹：一个被低估的架构决策

还有一个容易被忽略但极其重要的设计选择：技能不是一份文档，是一个文件夹。

听起来像技术实现细节，对吧？但这里面藏着一个影响深远的架构哲学。

技能文件夹里可以放脚本、放模板、放示例文件、放参考文档，甚至可以放动态钩子——那些只在特定技能被调用时才激活的临时规则。

为什么要这样设计？因为真正的专业能力从来不只是一段「说明文字」。它是一整套工具箱。

一个做数据分析的技能，不只是告诉Claude「请使用数据分析方法」，而是在文件夹里放好了取数用的辅助函数、常用的看板ID、标准的分析模板。Claude拿到手之后，不用从头写取数脚本，而是直接组合这些现成工具——用原文的话说，「把精力花在组合和决策上，而不是重复造轮子（spend its turns on composition, deciding what to do next rather than reconstructing boilerplate）。」

这让我想起一个完全无关的领域：烹饪中的「备菜」（mise en place）。

专业厨房和家庭厨房的区别，往往不在于厨师的刀工或火候，而在于开工之前，所有需要的食材已经洗净、切好、分装、按使用顺序排列。正式开火时，厨师只需要做一件事——组合与判断（先下哪个、火候多久、什么时候翻面）。

技能文件夹，就是给AI提前做好的「备菜」。

这个设计还有一个更精妙的地方：渐进式信息加载（progressive disclosure）。因为技能是一个文件夹，Claude可以在需要的时候才去读具体文件——主要指令在 SKILL.md 里，详细的API参考放在 references/api.md 里，需要时才翻。这样一来，99%的细节信息不占上下文窗口，但需要时触手可及。

这不就是我们人类的工作方式吗？你不会把所有知识都装在工作记忆里。你只是「知道去哪里找」。

钩子的哲学：什么时候该加一道「安全网」

博客里还有一个让我觉得特别有启发性的设计：按需钩子（on-demand hooks）。

原文举了一个例子：/careful 技能。当你调用它时，它会激活一个 PreToolUse 钩子，拦截所有带有 rm -rf 或 DROP TABLE 之类破坏性操作的命令，先让你确认再执行。

但关键是——这个钩子不是一直开着的。它只在你想碰生产环境时手动激活，用完就关。

为什么这个设计值得单独拿出来讲？因为它解决了一个微妙但普遍的问题：「安全」和「效率」的永恒拉锯。

如果全局禁止所有破坏性操作，在开发环境里每删一个测试文件都要确认，那AI的体验就废了。但如果完全不设防，碰生产环境时神经又绷得太紧。按需钩子的巧妙之处在于，它不追求「一刀切」的安全策略，而是让安全成为一个「可切换的上下文」。

这个设计让我想到开车——你不会在高速公路上一直踩着刹车，但在进入学校区域时，你会主动降速、提高警觉。好的安全机制不是让车一直慢，而是让你在「需要谨慎的场景」里切换状态。

没有审批团队的「技能市场」

聊到技能的分发和管理时，原文提到一个让我意外的细节：Anthropic内部没有一个集中审批技能的中心化团队。

技能的流转方式是——作者上传到 GitHub 的一个沙盒文件夹，然后在 Slack 或论坛里分享。一个技能用的人多了、口碑好了，作者提一个 PR，把它从沙盒移到官方市场。

这本质上是一个「社区驱动」的演化模型，而不是「顶层设计」的规划模型。

坦诚说，读到这我是有疑问的。没有审批，质量怎么保证？万一有人上传了有问题的技能怎么办？

但转念一想——这恰恰是系统设计上的自信。技能本身是「信息」，不是「执行代码」（虽然技能可以包含脚本）。AI拿到技能后，不是盲目执行，而是理解、判断、再行动。一个质量差的技能，AI在使用中会暴露问题，用户的反馈会让它自然淘汰。

这让我想到哈耶克那句被引用过无数次但依然深刻的话：「社会中真正重要的知识，从来不是以集中化的方式存在的。」

一个足够聪明的智能体系统，也许不需要一个全知全能的「中央审批者」。它需要的是一个让好经验能够浮现、传播、优胜劣汰的机制。

结尾：从「给AI写指令」到「帮AI避坑」

读完这篇博客，我最大的感受不是技术上有多震撼，而是一种视角的转换。

过去一年，整个行业都在疯狂追逐一个方向：让AI更强。更强的推理、更长的上下文、更多的参数、更复杂的智能体框架。这没错。

但Anthropic的这支团队用一年内部实战告诉你一件事：提升AI实际产出质量的最短路径，不是让它「更聪明」，而是让它「少踩坑」。

这不是一个技术判断，这是一个哲学判断。

它意味着，当我们和AI协作时，我们最应该投入精力的地方，不是把通用知识再教一遍，而是把我们作为人类在实战中积累的那些「灰色知识」——那些文档里没有、但实际会出事的东西——系统性地传递给AI。

就像学徒制里，师傅教给徒弟的从来不是「怎么握刀」——那是基础。真正值钱的是那句：「这块木头纹理特殊，下刀的时候你得逆着来。」

这个洞察会不会改变整个行业的方向？我觉得短期内不会。但它指向了一个更可持续的人机协作图景：人类和AI的分工，不是「谁比谁聪明」，而是「人类负责标注这个世界的坑，AI负责在标注好的路上跑得更快」。

写到这里，我忽然觉得「技能」这个词翻译得不太对。

它不该叫「技能」。它应该叫「经验」。

参考资料：

• https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills

• https://code.claude.com/docs/en/skills