别再堆规则写长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

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

登录后查看剩余 70% 内容