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

别再堆规则写长Prompt！Claude 5删80%约束仍性能在线，揭示80%规则实为负优化的真相。
核心内容：
1. 传统提示工程困境：堆规则导致AI输出混乱
2. Claude 5删80%规则的实践与效果
3. 上下文工程新方向：从定死规则到交模型判断

不知道你是否也有过这样的体验：

为了让 AI 输出达标，系统提示词越写越长，规则列了十几条，连输出格式都抠到了标点符号。

结果往往是，AI要么转头忽略核心要求，要么让几条规则彼此冲突，最终产出不伦不类。

是规则还不够细吗？于是又增加五条例外场景和三句重点强调，实际效果却变得更差。

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

其实，塞进上下文的大部分规则、约束和注意事项，不但没有作用，反而会妨碍模型发挥。

今天PEC将结合官方指南与我们的实战经验，把这件事讲清楚。

---

别只盯着用户 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 里塞记忆，现在模型会自动沉淀相关信息，我们管好项目特有的约定就行。

---

按照这四点调整，快速实施新规范

前面说了很多，具体应怎样在自己的项目里改动？这里整理出四个核心调整方向：

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

2. CLAUDE.md：定位为“项目踩坑指南”，不要写废话 诸如“这是XX项目，用XX技术栈”之类的内容，AI查看文件结构便能得知，只会浪费token。真正有价值的是项目特有的坑，例如“类型定义统一放在types/index.ts，不许零散新建”。

3. Skills：建设“专项知识库”，不要堆长文 将团队特有的最佳实践和领域规范制作成Skill，不要全部塞入全局上下文；较长内容应尽量拆分并按需加载。

4. 参考资料：优先选择高保真素材 向AI提供参考时，应始终优先选用代码、HTML原型、测试套件等内容。一个能够运行的页面原型，比一千字设计说明更加准确。

---

Claude 5推出的这套新规范，意味着提示工程不仅早已走出依赖“玄学咒语”的蛮荒阶段，也在告别“堆字数、堆规则”的蛮力阶段。

起初大家比谁的“咒语”更灵，之后比谁的格式更严谨，而到今天，真正的竞争已经转向上下文架构的设计能力。

是否能为模型建立舒适的协作框架，能否在恰当时机提供正确的信息，又能否守住底线而不限制能力？这些才是下一代上下文工程的核心命题。

总有人认为，随着模型越来越强，提示工程师将会失业。我反而觉得，并不是提示工程失去价值，而是要求提高了——你不必继续死磕每个措辞，但必须理解如何与智能体协作，以及怎样建立一套高效的上下文体系。

毕竟，真正高阶的引导从来不是控制AI一步步行动，而是提供足够空间，使它成长为你期待的样子。

---

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

END

往期推荐019个Claude隐藏技能｜消除AI痕迹+复刻个人文风02刚弄懂Loop Engineering，AI圈又出现新词Graph Engineering！03OpenAI 发布 GPT-5.6 Sol 提示词指南：别再把 Prompt 写成规则说明书了

登录查看剩余 70% 内容