还在堆规则写长 Prompt？Claude 5 官方：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 里塞记忆，现在模型会自动沉淀相关信息，我们管好项目特有的约定就行。

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

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

• 1. 系统提示：只定身份，不抠细节 —— 核心是说清 AI 是谁、要做什么。用 Claude Code 的基本不用改内置提示；自己搭 Agent 的，把精力放在身份定位和核心边界上，别塞细碎的执行规则。
• 2. CLAUDE.md：做 “项目踩坑指南”，别写废话 —— 像 “这是 XX 项目，用 XX 技术栈” 这种 AI 扫一眼文件结构就知道的内容，纯浪费 token。真正有价值的是只有你们项目才有的坑，比如 “类型定义统一放在 types/index.ts，不许零散新建”。
• 3. Skills：做 “专项知识库”，别堆长文 —— 把团队独有的最佳实践、领域规范做成 Skill，别全塞进全局上下文。长内容尽量拆分，按需加载。
• 4. 参考资料：优先高保真素材 —— 给 AI 喂参考，永远优先代码、HTML 原型、测试套件这类内容。一个可运行的页面原型，比一千字的设计描述都准确。

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

最早大家拼谁的 “咒语” 灵，后来拼谁的格式更严谨，而到了今天，真正的比拼已经变成了上下文架构的设计能力。

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

总有人说模型越来越强，提示工程师会失业。但我反而觉得，不是提示工程没用了，是对我们的要求变高了 —— 你不用再死磕每一个措辞，但你必须懂怎么和智能体协作，怎么搭一套高效的上下文体系。

毕竟，高阶的引导从来不是管着 AI 一步一步走，而是给它足够的空间，让它长成你想要的样子。