本文来自微信公众号： 小盖fun ，作者：小盖，原文标题：《很多提示词和 Skill，都已经过时了。》
Anthropic的工程师发了一篇文章，提到他们针对Claude Opus 5、Claude Fable 5这一代新模型，团队把Claude Code的系统提示词删掉了80%以上，结果在代码评测里没有看到明显损失。
这件事至少说明，在AI快速变化的节奏里，很多所谓的最佳实践，保质期可能非常短。
模型能力一直在提升，一些过去必须反复强调的规则，今天可能已经没有价值，甚至会限制模型的表现。
我也想借这个机会，写一下最近关于提示词和Skill的一些真实经验和思考，希望能够给大家一些启发。
一、提示词依然重要
现在很多人会觉得，提示词已经没有什么意义了。
这话对了一半。过去那种八股文式的提示词，价值确实越来越低。比如先给AI设定一个复杂角色：
你是一位资深的新媒体编辑，熟悉互联网行业，拥有十年写作经验，请帮我优化这篇文章。
这类角色预置，在新模型上的作用已经没有过去那么明显。模型本身知道编辑是怎么工作的，也知道一篇文章大概要怎么修改。
但这不代表提示词不重要。
如果把提示词换成另一个词，它其实就是：我们怎么跟AI沟通。
就像我们和人沟通一样，同样让一个人完成一件事，不同的沟通方式，最后得到的结果也可能完全不同。
所以，我现在更愿意把提示词理解成一种沟通思路。
你怎么描述问题，怎么拆解任务，怎么告诉AI你真正关心什么，这些依然无比重要。
我通常会告诉它：
这篇论文主要解决了什么问题？作者是怎么解决的？这个方法和过去的方法相比，真正的变化是什么？
这样问之后，AI的回答通常会更容易抓住论文的主线。
因为我没有只给它一个模糊的动作，而是告诉了它，我想从哪些角度理解这篇论文。
二、少做角色预置，把任务说清楚
过去写提示词，大家喜欢铺垫很多背景。
先设定角色，再描述能力，然后补充语气、风格、工作流程，最后才说真正要完成什么。提示词写了几百字，核心任务可能只有一句。
现在我觉得，这些铺垫很多时候已经没有必要。
提示词里真正重要的，是把几件事情分开说清楚。包括这次要达到什么目标，规则或者流程是什么，怎么才算完成。
比如，整理一段语音底稿，可以这样写：
把下面的语音底稿整理成一篇可以继续修改的公众号初稿。删除重复的口头禅，合并意思相近的内容，调整明显跳跃的段落。
注意保留原来的核心判断，不主动增加新的观点、案例和结论。
完成标准是读者能够看清文章在讨论什么，作者的核心判断是什么，以及这些判断之间有什么关系。
我现在越来越觉得，好的提示词不需要写得复杂，先把这几件事情想清楚，已经解决了大部分问题。
其实就像把一件事交代给同事，你怎么说，他才更容易理解。
三、规则需要有，但不要太多
有一段时间，我看到特别长的提示词，会觉得非常专业，恨不得马上保存下来。
现在的感受刚好相反。
一条提示词特别长，很多时候说明写提示词的人自己也没有完全想清楚。他只是把可能遇到的问题全部堆了进去，希望模型自己处理。
规则当然需要。
比如我在写作时发现，模型经常大量使用单字动词，文章读起来会比较硬。
我不喜欢这种表达，就会明确告诉它尽量使用更准确的双字动词，但不要为了凑字显得生硬。
这属于稳定的个人偏好，告诉模型是有价值的。但规则太多就会出现问题。
比如你同时要求语言简洁、内容详细、不要长句、不要太口语、不要调整原文节奏、同时优化文章结构......
这些规则很容易打架。
毕竟模型必须先花费大量精力理解哪一条规则优先，最后可能每一条都照顾了一点，但整体效果反而下降。
新模型已经具备比较强的推理和判断能力。提示词不需要提前规定每一个动作，只需要保留那些真正重要的规则。
规则越多，不一定代表控制越精确，也可能代表人没有完成取舍。
四、要不要提供示例，要具体情况具体看
以前写提示词，还有一个非常常见的做法，就是提供大量示例。
这个方法当然有效，但我现在越来越谨慎。
因为示例一方面能够帮助模型理解我们的要求，另一方面也会限制模型的探索空间。
尤其是模型能力越来越强以后，它有时候会过度模仿示例，最后只能在示例附近生成答案。
所以，要不要提供示例，我觉得不能一概而论。需要自己结合具体的情况去试。
现在，我大部分的情况下，都默认不提供示例。
比如让AI帮忙写文章开头，我提供了示例，它基本就照猫画虎了，很刻意。其实这时候，我们可以把自己思路说的更具体点，比如：
这个开头可以考虑从一个具体故事进入，也可以从一组反常的数据进入，或者从我最近的一个真实感受进入。
这并没有规定开头必须怎么写，但给了模型几个明确的思考方向。
所以，仍然是那句话，思路非常重要。
五、告诉模型，什么样才算完成
这也是我最近非常重视的一点。
我们经常告诉AI要完成什么，却很少告诉它，什么样的结果才算完成。
比如让AI总结一篇文章，最简单的提示词是：
总结这篇文章。
但你也可以写成：
总结这篇文章。完成后，我希望能够回答三个问题：作者发现了什么变化？为什么会发生这种变化？这件事对普通从业者有什么影响？
这相当于给模型提供了一个简单的验收标准。
再比如，让AI完成一份产品分析，可以说：
最终结论需要能够帮助团队做出产品决策，不能只介绍产品有哪些功能。
这个要求就比请深入分析这个产品清楚很多。
深入是一个非常模糊的形容词。什么叫深入，每个人的理解都不一样。但能不能支持产品决策，是一个可以检查的标准。
说完提示词，再说Skill。Skill就是一份按需加载的小型工作手册。
但并不是每一个提示词、每一个场景，都适合做成Skill。
一、经常发生、流程稳定的事情，才适合做成Skill
我觉得一类任务想要做成Skill，至少要满足几个条件：
第一，它经常发生。第二，它的工作流程相对稳定。第三，里面包含一些模型本身不知道的个人经验、团队经验或者业务知识。
这些事情会反复出现，处理方式也相对稳定，适合慢慢沉淀成Skill。
但某一篇文章的具体观点和材料，没有必要放进Skill。它们只和当前任务相关，直接作为参考材料提供给模型就可以了。
没必要把所有东西都做成Skill。
Agent在运行时，即便没有加载Skill的全部内容，通常也需要先读取它的名称、简介和适用范围。这些基础信息同样会进入上下文，对模型的判断产生影响。
Skill越多，不代表Agent越强。大量边界模糊的Skill，也可能让模型不知道该调用哪一个。
二、Skill里要放独特经验
我觉得一个Skill最有价值的地方，绝对不是那些网上随便就能找到的常识。
比如你在写作Skill里写文章要有逻辑、标题要有吸引力，这些内容模型本来就知道，写进去不会带来太大帮助。
真正有价值的是你自己的经验。
比如，修改语音底稿时，要保留口语里的活人感，每个核心判断最好有一个事实、数据或者亲身经历支撑。
这些内容代表了我们的个人品味、工作经验和业务知识。把这些经验编码进Skill，才是Skill真正的价值。
三、Skill需要控制抽象程度和边界
很多Skill的问题，是解决问题的范围太大。
比如一个叫写作的Skill，边界就非常模糊。写作包括选题、资料阅读、形成观点、整理初稿、修改结构、优化语言、生成标题、检查错别字。每一个环节需要的经验和评价标准都不一样。
把所有东西都放进同一个Skill，最后这个Skill只会越来越长。
所以我觉得，Skill最好只解决一个相对明确的问题。比如口述内容整理Skill、标题生成Skill、事实核查Skill。
Skill的边界越清楚，模型越容易判断什么时候调用，也越容易把它做好。
四、Skill的主文件应该尽量短
Skill通常是一个文件夹。
里面可以包含主文件、参考案例、常见问题、风格规范、检查清单，以及其他辅助材料。
所以没有必要把所有内容都写进主文件。
主文件只需要告诉模型：这个Skill什么时候使用、它主要解决什么问题、有哪些核心原则、默认按照什么思路推进、遇到具体问题时，可以继续读取哪些参考文件。
至于详细示例、风格要求、常见错误，可以放进单独的文件，等模型真正需要时再加载。
主文件是一张地图。模型先看地图，判断这次任务需要哪些内容，再继续读取相应的文件。
这就是渐进式加载。
不需要的内容不要提前塞给模型。这样既能减轻上下文负担，也能够减少不同规则之间的冲突。
五、Skill最好包含检查环节
这一点和提示词非常接近。
只告诉模型怎么生成，往往还不够。一个好的Skill，最好包含一套简单的自检标准。
比如产品体验稿Skill，可以检查：有没有写清楚真实使用场景、有没有说明过去的方法有什么问题、有没有只有功能，没有判断。
这些自检标准，也是在告诉模型什么样才算完成。
一个Skill的价值，不能只体现在生成过程，还要体现在它能够帮助模型判断结果是否合格。