上周一开周会一个下属在投屏上展示他写的 Skill洋洋洒洒翻了五页还没翻完。三千多字。PDF 解析原理、Python 库对比、编码规范、错误处理策略……应有尽有。写完以后他特别得意说这是他花了一整个周末打磨出来的“以后 AI 就不会犯错了”。我看着那份 Skill突然想起了十年前的一件事。那时候我刚做技术主管接手了一个烂摊子项目。前任留下了一份 200 页的操作手册从如何启动开发环境到数据库备份策略事无巨细应有尽有。我当时觉得这家公司太规范了捡到宝了。入职第三个月线上出了一个事故。我翻遍了那 200 页手册没有答案。后来是一个干了六年的老运维叼着烟看了一眼报错日志说了句哦这个啊把那个配置改成 false 就行了。三分钟搞定。那个瞬间我明白了一件事。那 200 页手册里真正有用的东西其实不超过十页。其余一百九十页都是正确的废话——写的人图个安心看的人图个心理安慰但对真正解决问题毫无用处。而现在我看着公司里一群人疯狂写 Skills那种熟悉的荒诞感又回来了。我先把话说在前面。我不是反对 Skills。正相反我们团队可能是国内最早一批在生产环境里大规模用 Skills 的。我自己也写也维护也踩坑。但问题在于大多数人在用写 GPT-3.5 时代经验的方式来写 2026 年的 Skill。这是完全搞错了对象。你问一个 2026 年 7 月的主流模型——GLM-5.2、Claude Opus 4.8、GPT-5.5、DeepSeek V4 Pro——“怎么解析 PDF”、“怎么写 React 组件”、“SQL 注入怎么防”它不需要任何 Skill 就能答得比你详细。根据最近的数据Claude Opus 4.8 在 SWE-bench 上达到了 69% 到 80% 以上DeepSeek V4 Pro 在 LiveCodeBench 上达到了 93.5%。这些模型的知识储备早就不是瓶颈了。Skill 真正需要解决的只有四个问题什么时候触发、按谁的规矩来、用什么工具按什么顺序、什么不能做。其他的全是冗余。但现在的现实是很多人写的 Skill正好反过来。不该写的写了一堆该写的没写清楚。我见过最离谱的几个案例有人在一个 PDF 解析 Skill 里花了 300 字解释 PDF 文件结构是什么、Header 和 Body 怎么区分、常用的 Python 库有哪几个。模型知道这些。你写进去除了浪费 context window唯一的作用就是让你自己觉得我写得真详细。还有人喜欢写正确的废话——“注意代码质量”“遵循最佳实践”“写出优雅的代码”。这就像你跟一个高级工程师说你要写好代码哦。说了等于没说反而稀释了真正重要的指令。更典型的是一种叫事无巨细的步骤分解——“首先你要创建文件然后你要写入内容接着你要检查是否存在”。这种手把手的东西适合 GPT-3.5 时代。对 2026 年的模型来说它不仅没用还有害——它限制了模型根据实际情况灵活调整的能力。还有一种我称之为超级全能 Skill的东西。一个 Skill 里管 PDF 解析、Excel 生成、Word 文档、图片处理、邮件发送——触发条件模糊行为约束冲突最后什么都没约束住。而最可怕的是那些永远不更新、永远不废弃的 Skill。项目规范变了、工具升级了、模型换代了但 Skill 还躺在那里写着两年前的旧约定。过时的 Skill比没有 Skill 更危险。为什么长 Skill 会出问题其实不是什么玄学。三年前Stanford 和 UC Berkeley 发了一篇论文叫《Lost in the Middle》——翻译过来就是丢在中间。他们发现语言模型在处理长文本时有个很诡异的特性对开头和结尾的信息记得特别清楚对中间的信息严重遗忘。就像一个 U 形曲线——两头高中间塌下去。后来越来越多的研究证实了这件事。2024 年 MIT 和 Google 找到了根因模型的注意力机制天然偏向开头和结尾这不是 bug是数学结构决定的。2026 年普林斯顿大学的最新测试更吓人——在超长上下文中中间 40% 篇幅的信息召回率只有首尾段的 23%。这意味着什么你写了一个 3000 字的 Skill塞进了系统提示词里。对话刚开始的时候它还在开头位置模型还能看到。但随着对话越来越长——五轮、十轮、二十轮——你的 Skill 被越来越深地推进了中间地带。然后它就开始消失了。不是真的消失是模型的注意力已经不在它身上了。不仅如此当多个长 Skill 同时加载时注意力被进一步稀释。就像一个经理同时管三十个人——人数越多每个人分到的关注就越少。一个 3000 token 的长 Skill在长对话中的有效遵循率会跌到只有 10%。你辛辛苦苦写了一个周末的东西模型只看到了十分之一。而一个 300 字的 Checklist同样的场景下遵循率是它的五倍。这就引出了我想说的核心。Skill 真正的未来形态不是操作手册而是Checklist。这两个东西的区别不止是长度。它们的底层假设完全不同。操作手册的假设是你不会做我需要手把手教你。Checklist 的假设是你会做我只是提醒你别忘了关键点。对 2026 年的模型来说第一个假设已经过时了。你不需要教一个高级工程师怎么写代码你只需要提醒他这个项目的命名用 camelCaseAPI 返回格式是{ code, data, msg }删文件之前必须确认。就这些。没了。我给你看一个具体的对比。这是我见过的一个典型的手册型 Skill大概 1200 字“PDF 是由 Adobe 公司开发的文档格式……PDF 的结构包括 Header、Body……常用 Python 库有 pdfplumber……首先确认文件路径……然后打开文件……检查是否加密……逐页提取……注意代码质量……确保可读性……处理异常……”而同样的功能改成 Checklist180 字就够了“触发条件用户要求解析 PDF。约束文件路径必须由用户提供加密文件必须询问密码表格用 extract_tables 不用 extract_text中文指定 encodingutf-8超过 50 页分批处理。输出文件路径 页数 摘要。”删掉了什么PDF 格式原理模型知道、Python 库介绍模型知道、“注意代码质量”正确的废话、详细步骤分解模型自己会规划。保留了什么什么时候触发、哪几条规则不能违反、输出长什么样。这就是 Checklist——只保留模型无法自行推断的关键信息。这个结论背后其实是一个更大的趋势。过去三年模型能力的变化完全改变了 Skill 的定位。2023 年 GPT-3.5 时代模型弱需要手把手教Skill 像操作手册。2024 年 GPT-4 和 Claude 3 时代模型开始能自己规划Skill 可以精简到关键约束。2025 年推理模型时代模型能深度推理和编排工具Skill 只需要触发条件和核心约定。到了现在2026 年GLM-5.2、Claude Opus 4.8、GPT-5.5、DeepSeek V4 Pro 这些模型在大多数场景下已经不需要你教了。Skill 的价值从指导完全变成了约束。模型越强Skill 越短。这是一个不可逆的趋势。如果你是团队的管理者或者你正在公司里推行 Skills 体系我有几个很具体的建议第一先问需不需要再问怎么写。大部分场景其实不需要 Skill。模型已经很聪明了别给它加多余的枷锁。第二写 Skill 的人必须是一线实践者。脱离一线的人写的 Skill大概率是正确的废话。只有天天用模型干活的人才知道模型在哪里会犯错、哪里需要约束。第三用对比实验验证。同一个任务有 Skill 和无 Skill 各跑十次对比成功率和输出质量。没有显著提升的直接废弃。第四定期做减法。每季度审查一次所有 Skills问自己这个 Skill 删了会怎样如果答案是没影响那就删了。第五警惕Skill 工程师这个角色的出现。如果公司开始设专人大量产出 Skill这几乎一定是过度工程。Skill 应该是实践的副产品不是专门的产出物。说到工具我自己团队现在主要在用的是 TRAE。选择它的原因很简单——它的内置 Skills 就是精简的web-dev、pdf、xlsx每个都是触发明确、约束精准、不废话。以平均 400 token 的长度在长上下文下保持 50% 的有效遵循率是主流工具里表现最好的。而且它把 Skill 和 MCP 分开了——MCP 负责能力扩展Skill 负责行为约束。各司其职互不混淆。配合 Claude Opus 4.8、GPT-5.5 这些强模型精简 Skill 强模型本身就是最优组合。这就是我想说的。最后回到开头那个故事。十年前那本 200 页的操作手册其实不是被看完的是被忘掉的——每天都有新的问题出现每天都有旧的页面过期最后所有人都只用那十页真正有用的内容剩下的扔在抽屉里接灰。Skills 也一样。当公司里有人开始鼓吹我们要写一百个 Skills的时候你应该问的不是怎么写而是——“这一百个里面有多少是模型本来就会的”删掉那些。剩下的用 Checklist 写。那才是真正有价值的 Skill。以上。如果觉得有用欢迎转发给那个正在写三千字 Skill 的同事。