上周一开周会，一个下属在投屏上展示他写的 Skill。洋洋洒洒翻了五页还没翻完，三千多字。PDF 解析原理、Python 库对比、编码规范、错误处理策略，应有尽有。

写完他特别得意，说这是花了一整个周末打磨出来的，“以后 AI 就不会犯错了”。

我看着那份 Skill，突然想起十年前的一件事。

那时候我刚做技术主管，接手了一个烂摊子项目。前任留下一份 200 页的操作手册，从怎么启动开发环境到数据库备份策略，事无巨细。我当时觉得，这家公司太规范了，捡到宝了。

入职第三个月，线上出了事故。我翻遍那 200 页手册，没有答案。

后来是一个干了六年的老运维，叼着烟看了一眼报错日志，说了句："哦这个啊，把那个配置改成 false 就行了。"三分钟搞定。

那个瞬间我明白了一件事。那 200 页里，真正有用的不超过十页。剩下一百九十页，都是"正确的废话"。写的人图个安心，看的人图个心理安慰，对真正解决问题毫无用处。

而现在，我看着公司里一群人疯狂写 Skills，那种熟悉的荒诞感又回来了。

我先把话说在前面。我不是反对 Skills。正相反，我们团队可能是国内最早一批在生产环境大规模用 Skills 的。我自己也写，也维护，也踩坑。

但问题在于，大多数人在用写 GPT-3.5 时代的经验，来写 2026 年的 Skill。这完全搞错了对象。

你拿现在的主流模型，GLM-5.2、Claude Opus 4.8、GPT-5.5、DeepSeek V4 Pro，问它"怎么解析 PDF"“怎么写 React 组件”“SQL 注入怎么防”，它不需要任何 Skill 就能答得比你详细。模型的知识储备早就不是瓶颈了。

Skill 真正要解决的，其实只有四件事：什么时候触发、按谁的规矩来、用什么工具按什么顺序、什么不能做。其他的，全是冗余。

但现在的现实是，很多人写的 Skill 正好反过来。不该写的写了一堆，该写的没写清楚。

我见过最离谱的几个案例。

有人在一个 PDF 解析 Skill 里，花三百字解释 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 形曲线，两头高，中间塌下去。

后来的研究逐步找到了根因：模型的注意力机制天然偏向开头和结尾，这不是 bug，是数学结构决定的。

这意味着什么？你写了一个三千字的 Skill，塞进系统提示词。对话刚开始，它还在开头位置，模型还能看到。可随着对话越来越长，五轮、十轮、二十轮，你的 Skill 被越推越深，推进了中间地带，然后就开始"消失"。不是真的消失，是模型的注意力已经不在它身上了。

更麻烦的是，当多个长 Skill 同时加载，注意力被进一步稀释。就像一个经理同时管三十个人，人数越多，每个人分到的关注越少。我自己的体感是，长 Skill 在长对话里前半段还记得，越往后越容易被挤到中间、被忽略；而一个几百字的 Checklist，反而一直挂得住。

这就说到核心了。Skill 真正的未来形态，不是操作手册，而是 Checklist。这两个东西的区别不止是长度，底层假设完全不同。

操作手册的假设是：你不会做，我得手把手教你。Checklist 的假设是：你会做，我只是提醒你别漏掉关键点。

对 2026 年的模型，第一个假设已经过时了。你不需要教一个高级工程师怎么写代码，你只需要提醒他：这个项目的命名用 camelCase，API 返回格式是 { code, data, msg }，删文件之前必须确认。就这些，没了。

我给你看个具体对比。

这是我见过的一个典型手册型 Skill，大概一千二百字：“PDF 是由 Adobe 开发的文档格式……结构包括 Header、Body……常用库有 pdfplumber……首先确认文件路径……然后打开文件……检查是否加密……逐页提取……注意代码质量……确保可读性……处理异常……”

同样的功能，改成 Checklist，一百八十字就够了：“触发条件：用户要求解析 PDF。约束：路径必须由用户提供，加密文件必须问密码，表格用 extract_tables 不用 extract_text，中文指定 encoding=utf-8，超过 50 页分批处理。输出：路径 + 页数 + 摘要。”

删掉了什么？PDF 格式原理（模型知道）、Python 库介绍（模型知道）、“注意代码质量”（正确的废话）、详细步骤分解（模型自己会规划）。

保留了什么？什么时候触发、哪几条规则不能违反、输出长什么样。这就是 Checklist，只保留模型无法自行推断的关键信息。

这背后是一个更大的趋势。过去三年，模型能力的变化彻底改写了 Skill 的定位。

2023 年 GPT-3.5 时代，模型弱，需要手把手教，Skill 像操作手册。2024 年 GPT-4 和 Claude 3 时代，模型开始能自己规划，Skill 可以精简到关键约束。2025 年推理模型时代，模型能深度推理和编排工具，Skill 只需要触发条件和核心约定。

到了现在，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，每个触发明确、约束精准、不废话。它把 Skill 和 MCP 分开了，MCP 负责能力扩展，Skill 负责行为约束，各司其职。配合 Claude Opus 4.8、GPT-5.5 这些强模型，精简 Skill 加强模型，本身就是最优组合。

这就是我想说的。

最后回到开头那个故事。

十年前那本 200 页的操作手册，其实不是被看完的，是被忘掉的。每天都有新问题，每天都有旧页面过期，最后所有人都只用那十页真正有用的，剩下的扔在抽屉里接灰。

Skills 也一样。当公司里有人鼓吹"我们要写一百个 Skills"的时候，你该问的不是"怎么写"，而是：这一百个里面，有多少是模型本来就会的？

删掉那些。剩下的，用 Checklist 写。那才是真正有价值的 Skill。

以上。如果觉得有用，欢迎转发给那个正在写三千字 Skill 的同事。