还在堆规则写长 Prompt？Claude 5 官方：80% 的约束都是负优化

不知道你有没有过这样的体验：

为了让AI输出达标，系统提示词越写越长，规则列了十几条，恨不得把输出格式抠到标点符号。结果呢？要么AI转头就忽略核心要求，要么几条规则打起架，出来的东西不伦不类。难道规则还不够细？于是再补五条例外场景，三句重点强调，可效果反而越来越差。

最近Anthropic发布的Claude 5系列上下文工程新规范，直接把他们自己Claude Code里80%的系统提示词给删了——结果在全套编码评测里，性能没出现任何可测量的下滑。

换句话说，我们往上下文里塞的大部分规则、约束、注意事项，不仅没用，反而在拖模型的后腿。

今天就结合官方指南和实战经验，把这件事聊透。

---

别只盯着用户Prompt，真正拉开差距的是上下文工程

很多人到现在还觉得，提示工程就是把用户提问写得更专业。但实际上，不管你用Claude Code做项目，还是自己搭AI智能体，用户单次输入的Prompt，只占模型收到的全部上下文里很小一块。

系统提示词、Skill技能文件、项目里的CLAUDE.md、历史记忆、工具定义……这些跨会话、全局生效的内容，才是决定AI输出上限的核心。

打理这套全局上下文的工作，就是

，也是现在高阶玩家真正在卷的能力。

早几年模型能力弱，我们必须靠密密麻麻的规则“扶着AI走”，怕它删错文件、怕它乱输出、怕它犯低级错。但到了Claude Opus 5、Fable 5这一代，模型本身的理解能力和判断力已经上了一个大台阶，那套“堆规则、加约束”的老玩法，反而成了绑住模型的枷锁。

Anthropic自己复盘内部使用记录时都发现，一个请求里经常撞着好几条冲突指令：系统提示说“默认不写代码注释”，Skill里要求“核心逻辑要补说明”，用户又补了句“代码写得易读点”。模型本来能直接给出最优解，结果大半精力都花在权衡这些冲突规则上了。

说真的，很多人做提示工程，陷进了一种“监工思维”：总怕AI犯错，所以把每一步都框死。可你管得越细，AI就越像戴着镣铐跳舞，上限早被你锁死了。

---

老思路该扔了，上下文工程的玩法全变了

官方总结了好几个曾经奉为圭臬、现在已经完全过时的“最佳实践”，每一条都踩中了很多人的日常操作。

从“定死规则”到“交给模型判断”

以前的写法是一刀切：“绝对不许写多行注释”“禁止生成中间规划文档”，用死规则规避所有风险。现在只给原则：“代码风格跟现有仓库保持一致，匹配注释密度和命名习惯”，把决策权交回去。

这本质是对模型定位的底层变化。以前我们把AI当流水线操作工，每个动作都要规定死；但今天的Claude 5，已经是能独立判断的资深执行者。你给老工程师定一堆“不许写注释”的死规矩，反而耽误他处理复杂场景；但你告诉他“跟着项目风格走”，他自己会根据代码复杂度拿捏分寸。

很多人写提示词的误区，就是永远在“防出错”，为此不惜牺牲能力上限。可新一代模型的容错能力早就超出预期了，

从“堆使用示例”到“做好接口设计”

以前默认工具配的示例越多，AI用得越准，恨不得把所有场景都举一遍。现在官方明确说：示例太多反而会限制模型的探索空间，让它困在示例的框架里，想不到更灵活的用法。

真正高效的做法，是把工具的参数、枚举值、边界定义清楚，靠接口本身引导使用。以前拼的是谁文案写得细、例子举得多；

。比如一个待办工具，你不用写三五个使用案例，只要把状态定义成「待办/进行中/已完成」，补一句“同一时间只留一个进行中任务”，模型自然就懂怎么用。

把精力从“写示例”转到

上，才是下一代上下文工程的核心能力。

从“一次性全加载”到“渐进式披露”

以前总求全：所有规范、所有工具、所有说明全塞进系统提示，一上来就把上下文填得满满当当。现在的思路是分层：非核心内容拆成独立Skill，做成延迟加载，真正用到的时候再载入对应内容。

这是整篇里最有实战价值的一点，也是90%的人都在踩的坑。很多人做Agent，一上来把十几个工具说明、全套开发规范、项目历史全堆在系统提示里，上下文窗口近一半都是大概率用不上的信息，真正处理核心任务时，模型注意力分散，有效token也被严重浪费。

官方的做法很值得参考：核心身份规则放系统提示；代码审查、校验这类低频需求，做成独立Skill按需调用；甚至工具本身都可以“延迟加载”——先告诉模型有这个工具，具体定义等它要用的时候自己检索。

放到我们自己的项目里也一样：别总想着写一个万能CLAUDE.md包打天下，

，核心信息放首页，细节藏在子文件里按需读取，效果远比堆一整页长文好。

顺带提两个细节调整：一是别再重复强调同一件事，工具说明就放工具定义里，不用在系统提示里再复述一遍；二是不用手动往CLAUDE.md里塞记忆，现在模型会自动沉淀相关信息，我们管好项目特有的约定就行。

---

照着这四点改，快速落地新规范

说了这么多，落到自己的项目里该怎么动？给大家整理了四个核心调整方向：

核心是说清AI是谁、要做什么。用Claude Code的基本不用改内置提示；自己搭Agent的，把精力放在身份定位和核心边界上，别塞细碎的执行规则。

像“这是XX项目，用XX技术栈”这种AI扫一眼文件结构就知道的内容，纯浪费token。真正有价值的是只有你们项目才有的坑，比如“类型定义统一放在types/index.ts，不许零散新建”。

把团队独有的最佳实践、领域规范做成Skill，别全塞进全局上下文。长内容尽量拆分，按需加载。

给AI喂参考，永远优先代码、HTML原型、测试套件这类内容。一个可运行的页面原型，比一千字的设计描述都准确。

---

Claude 5新出的这套规范，让提示工程早就告别了“玄学咒语”的蛮荒时代，也在告别“堆字数、堆规则”的蛮力时代。

最早大家拼谁的“咒语”灵，后来拼谁的格式更严谨，而到了今天，真正的比拼已经变成了

。

能不能给模型搭一个舒服的协作框架？能不能在合适的时候递对信息？能不能守住底线又不束缚能力？这才是下一代上下文工程的核心命题。

总有人说模型越来越强，提示工程师会失业。但事实上，不是提示工程没用了，是对我们的要求变高了——你不用再死磕每一个措辞，但

毕竟，

---

你写过最长的系统提示词有多少字？有没有过“规则加得越多，效果反而越差”的时候？欢迎在评论区聊聊你的实战心得。