企业 AI Agent 提示词越写越长怎么办？6 步把上下文工程减掉 80%

你的 CLAUDE.md 是不是写了上百条规则——从代码风格到提交规范，从测试流程到安全审查，恨不得把所有注意事项都塞进去？写完之后你以为 AI 这下总该听话了，结果它反而更拧巴了。

答案很简单：对 GPT-5.6、Claude Opus 5 这一代模型来说，你为 GPT-4 时代精心调教的提示词，八成是废话。

微信原文引用了 Anthropic 与 OpenAI 的提示词精简案例。为了避免把二手材料写成未经核验的官方结论，企业落地时应同时参考 Anthropic 关于 agent 上下文工程的工程文章，以及 OpenAI 最新模型指导中关于 leaner prompts 的说明。两个方向传递出的共同信号是：新一代模型不一定需要越来越长的规则清单，更需要清晰、可按需加载、可验证的上下文结构。

---

从 Prompt Engineering 到 Context Engineering

Anthropic 把这种新范式称为「上下文工程（Context Engineering）」。提示词只是你发给 AI 的那一行文字，上下文是模型实际看到的全部信息——系统提示词、CLAUDE.md、Skill 文件、记忆、你 @ 进来的参考文件。模型升级了，整个上下文工程的玩法就得跟着变。

对企业团队来说，提示词治理的重点不是“写得更长”，而是问一个更工程化的问题：这句话有没有可能被模型误解？如果有，应该靠更清晰的接口、测试、检索材料、权限边界和验收标准来消除歧义。

Anthropic 总结的 6 条上下文工程法则

以下六条经验，每一条都配有你可以直接上手的操作。

01 | 别加太多规则，让模型自己判断

以前 Claude Code 的系统提示词里有这么一条：「代码里默认不加注释。永远不要写多段注释块，最多一行。不要自己创建规划文档。」听起来合理，但有些代码确实需要注释，有些用户就是想要规划文档。一条规则写死了，遇到例外模型只能卡住。

砍完后，提示词换成了一句：「写出来的代码要像周围的代码——注释密度、命名习惯、代码风格，和已有代码保持一致。」一句话替代了一整段禁令。模型自己看上下文，自己判断该不该写注释。

实操： 打开你的 CLAUDE.md，搜索「不要」「禁止」「always」「never」。每找到一条，问自己：Claude 看一眼我的代码库，能自己推断出这条规则吗？能推断出来的，果断删掉。

02 | 别给示例，把接口设计好

最反直觉的一条。以前的黄金法则是 few-shot prompting——给 AI 投喂几个示范告诉它想要什么格式。但 Anthropic 发现，给 Claude Fable 5 这种模型看示例，反而限制了它的探索能力。

他们对 TodoWrite 工具做了一次对比：旧版工具描述约 9100 个字符，塞满了使用说明和示例；新版是一段简短的功能描述加上三个状态标签和一条规则。9100 个字符的说明书，被一个设计清晰的接口替代了，效果反而更好。

实操： 与其花精力写示例教模型怎么用工具，不如把工具本身设计得更直观。参数名取好，枚举值列清楚，约束条件写在接口定义里——模型一看就知道该怎么用。

03 | 别全塞进去，按需加载

你的 CLAUDE.md 是不是代码审查流程、部署步骤、验证清单、安全规范全放在一个文件里？Anthropic 自己也这么干过。更优雅的解决方案叫 「渐进式披露」（Progressive Disclosure）——不是所有信息都需要一开始就给 AI。

代码审查流程？拆分到独立的 Skill 文件里，Claude 做代码审查时自己去调用。验证步骤？同样拆出去。有些工具定义甚至是「延迟加载」的，Claude 需要的时候先搜索完整定义再调用。

实操： 把 CLAUDE.md 里超过 5 行的流程性内容拆分出去，变成独立的 Skill 文件，CLAUDE.md 只留一句话指向它。Claude 实际收到的信息有五层：你的提示词、引用文件、系统提示词、CLAUDE.md、Skill 文件——每一层都在消耗上下文窗口。

04 | 别重复说，一遍就够

Anthropic 研究团队翻看自己的对话记录时发现，同一个请求里同时出现了「适当添加注释」和「不要添加注释」——一条来自系统提示词，一条来自 Skill 文件。模型不会聪明地挑一条执行，它会花大量 token 试图两头兼顾，结果两边都做不好。

实操： 把你系统提示词、CLAUDE.md、所有 Skill 文件全打开，搜同一个关键词——「comment」「test」「verify」。有冲突的只留一条，放在最合适的位置。

05 | 别手动记录，让 AI 自己记

以前 Anthropic 鼓励用 # 把项目信息写进 CLAUDE.md。现在不用了——Claude 有了自动记忆功能，自己会把项目相关的信息保存下来。CLAUDE.md 从百科全书变成了项目速查卡。

实操： 简单写一下这个仓库是干什么的，然后把篇幅留给那些 Claude 从代码里看不出来的东西——比如你们团队把所有类型定义放在一个巨型文档里，这个约定光看目录结构推断不出来。「写代码要整洁」「函数不要太长」一律不用写，AI 看一眼你的代码就知道风格。

06 | 别写规格说明书，给 AI 丰富的参考

以前交代需求时你可能习惯写一份 Markdown PRD。Anthropic 发现，Claude 能处理比 Markdown 复杂得多的参考材料：HTML 页面效果 > 截图 > 文字描述。想让它做一个登录页面？直接给它一个 HTML 文件，「照这个做」。

测试用例也是一种参考——给一份详细的测试文件，「跑通这些测试就算完成」，比写一页需求文档更管用。还有一种玩法叫 rubric（评分标准），把「好的 API 设计长什么样」写成一份评分表，让验证 Agent 在 workflow 里去检查输出质量。

---

交互演示：上下文工程检查清单

下面是一个可交互的上下文工程自查流程——点击每一步查看详细说明。

用 /doctor 一键自查

懒得一条条手动检查？Anthropic 在 Claude Code 里内置了一个命令——/doctor。它会自动扫描你的 CLAUDE.md 和 Skill 文件，告诉你哪些内容冗余、哪些规则互相矛盾、哪些信息 Claude 自己看代码就能推断出来。这是目前最省心的上下文工程入门工具。

「大多数系统提示词和 Skill 文件的保质期其实很短。它们本质上是给当前模型的缺点打补丁——但这些缺点，很可能已经被下一代模型训练修复了。」

——Anthropic 博客引用的创业者观点

Hacker News 上有网友戏称现在的传统提示词工程为「Prompt Astrology（提示词占星术）」。但也有开发者反驳说：「可预测性才是工具的基本属性，大语言模型本质上是概率机器。」两边的看法都有道理——新模型虽然更聪明了，但并不意味着你可以什么都不写。Anthropic 自己也没把系统提示词删到 0，他们留下了 20%：那些真正必要的约束规则和产品定义。

---

对企业的意义：AI 工具链需要系统性管理

这 6 条上下文工程法则对个人开发者有用，对企业团队更有战略价值。当一个团队有 10 人、20 人同时使用 AI 编码助手时，CLAUDE.md 和共享 Skill 文件就是团队的「AI 操作规范」。如果这些规范还停留在 GPT-4 时代的写法——堆砌规则、重复指令、全量加载——每一行代码背后的 token 消耗和组织效率损失都是实实在在的成本。

DELine 在企业 AI 落地实践中发现，多数团队的 AI 使用规范面临三个共性问题：

• 规则过载——每个人都在往共享配置里加自己的偏好，最终没人敢删
• 版本脱节——CLAUDE.md 是三个月前写的，模型已经升了两代
• 缺乏审计——不知道哪些规则真正在生效，哪些在浪费 token

这正是上下文工程要解决的核心问题：从「写很多规则让 AI 听话」转向「设计清晰的上下文结构让 AI 自主判断」。

---

DELine 能帮你做什么

DELine 为企业提供 AI Agents 定制部署、本地大模型基础设施建设和企业 AI 工具链治理服务。如果你正在经历以下场景：团队 AI 提示词规范管理混乱、AI 编码助手 token 消耗失控、需要从零搭建企业级 AI 开发平台——我们可以帮你梳理上下文结构、设计分层 Skill 体系、建立 AI 工具链治理流程，让每一分 token 花在刀刃上。