如何为 Claude 5 设计更有效的上下文
减少重复规则，改进工具接口，并让信息在需要时出现
上下文工程 · 规则、工具、记忆与渐进式披露
摘要
与 Claude 交互时，用户输入的提示词只是模型所接收信息的一部分。系统提示、Skills、CLAUDE.md、自动记忆和任务参考资料会共同组成上下文，并在多次请求中持续影响模型的判断。
Claude 5 一代模型具备更强的判断能力和上下文调用能力，过去依赖大量规则、示例和重复提醒的做法开始显得冗余。更有效的方向，是减少不必要的长期约束，设计清晰的工具接口，并通过渐进式披露让模型在正确的时机加载正确的信息。
01 · 提示词只是上下文的一部分
提示词通常针对当前任务，可以写得非常具体。上下文工程处理的范围更大：系统提示决定产品环境和基本角色，CLAUDE.md 保存仓库级信息，Skills 提供可复用的工作方法，记忆记录持续有效的经验，参考资料则补充当前任务所需的细节。
这些信息经常跨多个请求复用，因此不能像单次提示那样只针对一种情况。如果长期上下文写得过细、互相重复或彼此冲突，模型就需要先判断哪些要求适用于当前任务，再决定如何行动。
上下文工程的目标不是尽量填满上下文窗口，而是建立一套信息分工：哪些内容必须始终存在，哪些内容只在特定任务中加载，哪些内容可以从代码和工具接口中直接推断。
要点：提示词解决当前任务，上下文工程决定模型长期能够看到什么，以及何时看到。
02 · 减少过度约束，让模型结合环境判断
为 Opus 5、Fable 5 等模型调整 Claude Code 时，系统提示词被删去了超过 80% 的内容，内部编程评测没有测得明显损失。这说明不少过去必需的规则，已经可以由新模型根据周围环境和用户意图自行判断。
旧式上下文经常为避免最坏情况而写下强硬限制。例如，要求默认不写注释、禁止多段文档字符串、不得创建计划或分析文件。这些规则能够抑制旧模型的一些错误行为，却也会在复杂代码确实需要详细注释时产生错误约束。
更合适的写法，是要求生成的代码匹配周围代码的注释密度、命名方式和惯用写法。它给出了目标和判断依据，却没有提前规定所有场景必须采用同一种处理方式。
减少规则并不意味着取消边界。安全、合规、权限和不可逆操作仍然需要明确约束。应当删除的是过时、重复、相互冲突，以及模型可以直接从项目环境中推断的内容。
要点：保留真正重要的边界，把可以根据代码环境判断的细节交给模型。
03 · 少堆调用示例，多设计表达清楚的工具接口
早期模型学习使用工具时，通常需要多个调用示例。对新模型而言，示例可能反过来限制探索范围，使模型更倾向于复制已展示的路径，而没有充分利用工具的其他能力。
新的重点是接口设计：参数是否表达清楚，允许哪些取值，状态之间如何变化，哪些约束必须满足。一个待办工具把状态定义为 pending、in_progress 和 completed，并规定同时只能存在一个 in_progress，就已经向模型传达了主要用法。
清晰的接口既能约束不合法操作，也保留了解决问题的空间。相比在系统提示中堆叠调用范例，更值得投入的是参数名称、类型、枚举、错误信息和工具返回结果。
要点：工具接口应该表达能力和边界，而不是让模型机械复制少数示例。
04 · 不要一次加载全部内容，改用渐进式披露
过去会把代码审查、验证流程和各类项目规范全部写进系统提示或 CLAUDE.md，因为担心模型在需要时找不到它们。代价是每一次请求都携带大量与当前任务无关的信息。
渐进式披露将这些内容拆成独立 Skill。只有当任务涉及代码审查时，才加载审查方法；需要验证时，再读取验证流程。模型保留了找到信息的路径，但不必让所有细节长期占据上下文。
同样的方法也适用于工具。部分工具可以只公开名称和用途，等模型通过 ToolSearch 找到它们时再加载完整定义。这样可以提供更多工具，同时控制每次请求的上下文开销。
CLAUDE.md 和 Skill 也可以组织成文件树。入口文件保持简短，只说明何时应该读取下一级资料；具体规则放在对应文件中，随任务逐步展开。
要点：常驻上下文只保留导航和关键约束，详细方法在真正需要时再加载。
05 · 删除重复说明，把记忆放到合适的位置
旧模型有时需要反复提醒，或者更容易关注上下文末尾的要求，因此同一项工具说明可能同时出现在系统提示和工具描述中。新模型对指令位置的依赖降低后，这类重复可以删除。
工具如何使用，最好集中写在工具自己的描述中。系统提示只负责产品级行为，避免再次解释每个工具。这样既能减少 token，也能降低多个版本的说明逐渐不一致的风险。
记忆也需要重新分工。过去可以通过快捷方式把大量信息追加到 CLAUDE.md；现在自动记忆能够保存与工作和个人偏好有关的持续经验。CLAUDE.md 更适合保留仓库自身的稳定信息，而不是成为所有历史经验的汇总文件。
要点：每类信息只保留一个主要归属，工具说明和个人记忆不要反复写进 CLAUDE.md。
06 · 用高保真参考资料代替简单规格说明
长任务过去常依赖简单的 Markdown 计划和规格文件。新模型能够处理更复杂的参考资料，包括 HTML 产物、代码实现、测试套件、其他代码库中的函数，以及用于验收结果的评分标准。
参考资料越接近最终产物，歧义通常越少。对于界面任务，可运行的 HTML 原型往往比文字描述或截图提供更明确的结构和行为；对于迁移任务，现有代码和测试比抽象说明更容易验证。
评分标准也是一种参考资料。它可以描述什么样的 API 设计、界面或文案才算符合团队品位，并由验证 agent 根据这些标准检查结果。这让难以写成固定规则的判断，也能进入可重复的工作流程。
要点：优先提供能够直接执行、比较或验证的资料，而不是只增加描述篇幅。
07 · 不同信息，应放进不同的上下文载体
系统提示与产品环境紧密相关，用来说明 agent 正在什么产品中运行、承担什么角色。Claude Code 用户通常不需要修改这一层；自行开发 agent 运行框架时，则需要认真设计。
CLAUDE.md 应保持轻量，简要说明仓库用途，并把主要篇幅留给代码库中不容易直接发现的特殊约束。例如，类型必须统一放在一个文件中，就是值得记录的项目陷阱；目录结构和语言类型等显而易见的信息没有必要重复。
Skills 是按需加载的轻量指南，适合编码团队或产品特有的观点、知识和最佳实践。除非涉及高度重要的领域，否则不宜写得过度刚性。较长的 Skill 应拆成多个文件，通过入口说明逐步加载。
参考资料服务于当前任务，可以通过文件引用加入上下文，包括规格、原型、代码库和测试。代码是模型熟悉的精确表达形式，通常比纯文字描述具有更高的信息密度。
要点：系统提示管产品，CLAUDE.md 管仓库，Skills 管方法，参考资料管当前任务。
08 · 定期审计上下文：删除、迁移、拆分、保留
上下文不会因为曾经有效就永久正确。随着模型能力、工具和产品功能变化，旧规则可能失去必要性，新记忆与 Skill 也可能承担了原来由 CLAUDE.md 负责的工作。
一次实用的审计可以依次检查四类动作：删除重复或显而易见的说明；把工具用法迁回工具描述；把过长的 Skill 拆成按需文件；保留安全边界、项目陷阱和真正独特的团队经验。
Claude Code 的 /doctor 命令可以辅助检查 Skills 和 CLAUDE.md 的规模是否合适，但最终仍需要结合实际任务判断。删减后应使用真实工作负载验证，确认质量没有下降，再继续简化。
上下文工程的衡量标准不是规则数量，而是模型能否在较少冲突和较低上下文成本下，稳定找到完成当前任务所需的信息。
要点：持续删减和重新分工，让上下文随着模型能力和工具体系一起演进。