读：从写提示词到构建技能——三层技能框架与 Claude Code 的认知升级

一个反直觉的事实

企业搞 AI 的现状很残酷：投入几十亿，95% 的项目没有任何产出。不是模型不行，模型越来越强了，问题是所有人都把注意力放在了工具上，很少有人认真想过自己要往里面塞什么内容。

这个判断背后的逻辑很直接：模型的能力在趋同。今天你用 GPT-4o 还是 Claude Sonnet，差距远没有想象中那么大。真正拉开产出的，是你有没有围绕自己的知识、工作流程和判断标准构建一套上下文系统。往里面喂垃圾，吐出来的是高级垃圾。往里面喂结构化的认知，输出就能放大你的专业能力。

三层模型：大多数人只用了最浅的一层

要理解上下文为什么重要，得先拆开 AI 的调用结构。它分三层，大多数人只用了前两层。

第一层：预训练

这一层决定模型"能干什么"：写文章、写代码、总结文档。模型公司花几十亿训练出来的能力底座。你完全控制不了它，买回来是什么样就是什么样。这一层不是你的竞争力，因为别人也能买到。

第二层：提示词

提示词决定"这一刻你具体问什么"。大多数人就停在这一层，以为把提示词写好就能出好结果。提示词当然重要，但它是一次性的、临时性的指令。每次问不同的问题都要重新写，没有积累，没有复用。

第三层：技能

技能是一个可复用的上下文模块。它定义了你是谁、你怎么工作、你对结果的质量标准是什么。它像一个长期存在的"专业人格说明书"，在你每次调用模型时自动注入进去，让模型知道自己在为谁工作。

同一个模型，加载不同的技能，输出质量天差地别。一个加载了产品经理技能的模型和一个没加载任何技能的模型，写出来的需求文档完全是两个物种。问题在于，绝大多数人根本没有构建这一层。

三种技能类型

技能框架把"经验"这种模糊的东西拆成了三层清晰的结构。

通用技能：定义什么叫好

通用技能不教具体做什么任务，它只定义判断标准。比如产品经理这个角色，本质是平衡用户需求、商业目标和技术约束之间的张力。优秀的产品经理知道一个功能该不该上线、该做到什么程度、优先级在哪。这些判断标准来自经验积累，但平时没人会写下来。

这种东西平时没人会写下来，因为大家都默认"懂的人自然懂"。但你不写清楚，AI 就永远学不到这套标准，团队成员也无法统一工作方式。通用技能的价值就是把判断标准固化下来，让 AI 和团队都有统一的参照系。

项目技能：在冲突中做选择

通用技能太抽象了，放在任何项目上都能用，但也正因为太通用，它落不了地。项目技能告诉你在某个具体环境里，哪些东西优先级更高。比如金融合规项目里，合规的重要性一定压过交付速度。

现实世界里的决策没有一件是在真空中发生的。用户体验和商业目标常打架，交付速度和质量标准互相拉扯，你想创新又怕风险。你不把这些优先级写清楚，AI 就会按自己的"平均理解"来脑补，结果就是一片混乱。项目技能的本质是把模糊的约束变成明确的决策边界。

在 Claude Code 里， CLAUDE.md 就是一个典型的项目技能。它写在项目根目录下，告诉 AI 这个项目用什么语言、什么测试框架、什么编码规范、什么分支策略。每次会话自动加载，不用重复说。

个人技能：真正稀缺的东西

个人技能来自你踩过的坑、交过的学费。什么时候该怀疑一个需求，什么时候该推翻一个定了的方案，这些东西不存在于任何理论课本里，只能靠不断犯错和复盘积累。

问题在于，大多数人从来没有把这些经验写下来。它们存在于你的直觉里、肌肉记忆里，不具备任何可复用性。新人进来，每次都重新踩一遍你当年踩过的坑。

在 Claude Code 的语境里，这就是 skills 目录下的技能文件。比如你写了一个"代码审查技能"，里面包含你对代码质量的判断标准、你踩过的坑、你发现过的典型错误模式。加载这个技能后，AI 在审查代码时就会用你的经验标准来判断，而不是用"互联网平均标准"来审查。

冲突不会消失，但会被显性化

把三层技能同时加载给 AI，就会发生冲突。

比如通用技能说用户体验第一，项目技能说合规优先，这两个目标在很多场景下天生冲突。模型不会替你解决这个冲突，但它会把冲突点摆在你面前：你的通用技能倾向于 A 方案，项目技能要求你必须选 B 方案，请你自己做决定。

这反而是好事。现实世界的决策从来没有什么最优解，只有"在约束条件下的最不坏解"。关键是你清不清楚自己在权衡什么，比能不能找到完美方案重要得多。

技能即代码：不维护就变毒药

很多人犯一个错误：写一次技能就不管了，觉得一劳永逸。结果是上下文过时了。市场变了、产品变了、团队也变了，但 AI 还在执行旧规则。输出的质量已经很差了，但读起来依然流畅自信——你很难发现它已经过时。

技能必须像代码一样持续维护。项目方向变了要改，团队踩了新坑要补充，认知升级了更要迭代版本。不维护的技能比没有技能更可怕，因为它给你一种虚假的安全感。

关键是把维护成本降到足够低。每次项目复盘时顺手更新项目技能，每次发现自己做了一次漂亮的判断，顺手写进个人技能。维护不能是额外的工作负担，它得嵌入日常工作流程里才能长期运转。

扩展心智：信任是前提

心理学里有一个概念叫"扩展心智"：工具可以成为你思考过程的一部分。笔记本就是你记忆的延伸，你不需要把所有事情记在脑子里。但前提是这个工具必须随手可用、稳定可靠、你愿意信任它。

技能也是一样的道理。如果每次调用 AI 前都要手动加载技能文件，或者技能经常过期失效，它永远成不了你的"第二大脑"，你只会把它当偶尔用一下的辅助工具。

只有当加载是自动的、质量是稳定的、更新是无痛的，你才会真正开始信任它，把它纳入你的认知系统。在 Claude Code 里，这就是 CLAUDE.md 和 ~/.claude/skills/ 这两层机制的价值：自动加载、无需手动干预。

AI 的定位：缩短从想法到草稿的距离

AI 最实际的价值，是帮你快速生成第一版草稿。以前花几小时憋一篇文章、写一个方案、搭一个框架，现在几分钟搞定，而且格式工整、逻辑通顺。

但草稿不是结果，只是起点。真正体现你专业能力的部分，是你如何评估、修改甚至推翻 AI 生成的输出。你能看出哪里有问题，能补充它遗漏的关键点，能调整它判断错的优先级。这些判断力才是你真正值钱的地方。

这意味着工作的核心正在转变。写东西这个动作变得不值钱了，但判断什么东西值得写、什么东西写错了、什么东西需要删掉，这些判断能力比以前更值钱。你不再是写方案的人，而是评估方案、选择方案、否决方案的人。

总结

AI 不会自动给你带来任何竞争优势，它只会放大你已经拥有的能力。如果你有清晰的判断力、扎实的专业知识、良好的工作习惯，AI 会让你的产出翻倍。如果你没有这些，AI 不会帮你弥补缺陷，只会把你的缺陷放大成更大的灾难。

真正的分水岭，是谁先跳出"写提示词"的阶段，开始构建自己的上下文系统，给 AI 提供高质量的上下文。这件事短期看是技术问题：怎么写技能、怎么维护技能。长期看是一个认知问题：想清楚自己的专业判断标准是什么，你的经验里哪些真正值钱，你愿意把哪些主动权交给 AI。

那些最终能用好 AI 的人，往往不是技术最牛的。他们对自己专业理解最深、最愿意把自己的经验写成结构，愿意花时间写技能、维护技能，因为他们知道这是在给未来的自己造一个永远在线、永不疲倦的智能分身。