给Claude松绑：Claude 5上下文工程的六组变革
近期，针对Claude 5系列模型的上下文工程实践出现了一项颠覆认知的调整：相关团队删除了Claude Code中超过80%的系统提示词，但在编码评测中并未出现可被观测到的性能损失。这一变化背后，是对大模型能力演进下上下文工程逻辑的全面重构。
在使用Claude Code或搭建自定义智能体时，我们所说的上下文并不仅仅是用户发送的单条Prompt，它还包含系统提示词、Skills、CLAUDE.md文件、记忆模块等多个部分，这些内容共同决定了模型的输出表现。针对具体任务的Prompt可以灵活调整，但通用上下文需要适配多变的用户需求，如何设计这类通用指导曾是一个棘手的问题。
团队在复盘内部使用记录时发现，过往的上下文设置存在大量不必要的约束，这些约束来自系统提示词、CLAUDE.md文件和Skills模块。不少场景下会出现指令冲突：比如一处要求“在合适的位置保留文档注释”，另一处又规定“绝对不要添加任何注释”，系统提示词、技能配置和用户请求相互重叠甚至矛盾。虽然Claude通常能理解用户真实意图，但处理这类冲突会额外消耗模型的思考资源。
过往这些约束确实有其必要性，用于帮助模型规避删除文件、过度注释等潜在问题，但随着Claude 5系列模型的能力大幅提升，大部分硬约束已经不再必要。如今的模型可以根据上下文和自身判断做出合理决策，同时Claude Code也新增了memory、artifacts等工具，能够以更灵活的方式在会话间加载和共享上下文。
上下文工程的新旧范式对比
从强制规则到自主判断
Claude Code刚推出时，为了避免模型做出删除文件、过度注释等错误操作，团队会设置非常强硬的指导规则，比如早期系统提示词中要求“默认不写注释，绝对不要编写多段落文档字符串或多行注释块，仅允许保留一行短注释；除非用户明确要求，否则不要创建计划、分析类文档，直接基于对话上下文工作，不依赖中间文件”。
在代码中：默认不写注释。绝对不要写包含多个段落的 docstring，也不要写多行注释块，最多只能有一行短注释。除非用户明确要求，否则不要创建计划、决策或分析文档；请直接基于对话上下文工作，不要依赖中间文件。
但这类规则并不适配所有场景：比如用户可能有特定的文档编写偏好，复杂代码也确实需要多行注释来提升可读性。对于旧模型来说，移除这些约束很容易导致输出质量下降，但Claude 5系列模型的判断能力已经足够强，无需硬约束也能做出合理选择。因此新的系统提示词被简化为“编写与周围代码风格一致的内容：匹配现有代码的注释密度、命名方式和惯用写法”。
写出与周围代码读起来一致的代码：匹配现有代码的注释密度、命名方式和惯用写法。
从示例依赖到接口设计
过去使用工具的最佳实践是为模型提供详细的使用示例，但在最新模型上，这类示例反而会限制模型的探索空间，让它只能按照示例的逻辑执行任务。
与其花费精力编写大量示例，不如优化工具、脚本和文件的设计：明确模型可使用的参数，通过参数的语义和枚举值来传递使用逻辑。比如任务列表工具，只需将状态定义为pending、in_progress和completed三种枚举值，再补充“同时只能有一个任务处于进行中”的说明，就能清晰定义工具的使用规则，无需额外示例。
从全量加载到渐进披露
早期的系统提示词会将所有相关信息，比如代码评审、验证流程等，全部塞进上下文里，但这些内容并非每次任务都需要，反而会占用宝贵的上下文窗口。如今Claude Code已经能够很好地实现渐进式披露，也就是在需要的时候才加载对应的上下文。
团队将代码评审和验证流程拆分为独立的Skills模块，让模型在需要时才选择性调用。这种思路也可以延伸到工具和文件管理中：部分工具可以采用延迟加载模式，智能体需要先通过搜索获取完整定义后才能使用，这样可以在不占用额外上下文的前提下提供更多工具。同样的逻辑也适用于CLAUDE.md和SKILL.md文件，不必将所有已知实践都塞进一个文件，而是建立文件树，让相关内容在合适的时机被加载。
从重复说明到简洁描述
早期的Claude模型更容易关注上下文窗口末尾的指令，而忽略开头的内容，因此团队经常会在系统提示词和工具描述中重复说明工具的使用方法。但现在这种重复已经没有必要，工具的使用规则只需要在工具自身的描述中写清楚即可，无需再塞进系统提示词中。
从手动存储记忆到自动记忆
过去用户需要通过特定快捷键将内容手动存入CLAUDE.md文件来保存记忆，但现在Claude 5系列模型已经可以自动保存与当前工作相关的记忆，无需用户手动干预。
从简单规格到丰富参考材料
在计划模式下，Claude Code过去依赖简单的Markdown格式的计划文件来保存上下文，团队也会将规格说明存入代码库方便查阅。但如今Claude已经能够处理更复杂的参考材料：除了基础的Markdown文件，还可以引用新的artifacts功能生成的HTML产物，甚至可以直接将代码本身作为参考，比如用详细的测试用例或是其他代码库中的函数作为规格说明，让模型参考移植。
评价标准（Rubric）也是一种优质的参考材料，它可以表达团队或产品的特定品味和标准，比如“优秀的API设计应该遵循的原则”。模型可以通过动态工作流，启动带有这些评价标准的验证智能体，自动检查输出结果是否符合预设标准。
落地到你的上下文工程实践
当你需要搭建适配Claude 5系列模型的上下文时，可以参考以下几个核心部分的优化思路：
系统提示词（System Prompt）
系统提示词与产品场景高度绑定，它会告诉模型当前运行的产品环境和任务目标。对于Claude Code来说，系统提示词通常不需要频繁修改，但如果你正在搭建自定义的智能体框架，则需要投入足够的时间来打磨系统提示词。
CLAUDE.md文件
让CLAUDE.md保持轻量简洁：可以简要说明仓库的核心用途，但大部分内容应该用于记录代码库中的特殊规则，比如团队约定“所有类型定义必须放在单个单体文件中，其他位置不得新增类型定义”。无需重复描述模型可以通过文件系统或仓库结构自行获取的“显而易见”的信息。
对于复杂的验证流程或专属实践，可以创建独立的verification Skill模块，再从CLAUDE.md中引用，通过渐进式披露的方式加载相关内容。
Skills模块
Skills可以看作是轻量的指南，帮助模型在需要时获取特定信息。除非涉及安全性等关键领域，否则不要给Skills添加过多的硬约束。对于较长的Skills模块，建议采用渐进式披露的思路拆分为多个文件，让不同部分在需要时分别加载。
Skills的最佳使用场景是承载团队、产品或个人特有的观点、知识和最佳实践，这类专属内容能够让模型的输出更贴合实际需求。
参考材料（References）
你可以通过@提及文件的方式，将相关内容加入参考材料，让模型能够查阅与当前任务相关的深入信息。
参考材料可以是规格文件、原型设计稿，甚至整个代码库。通常优先选择代码形式的文件，因为模型能够以熟悉的代码语言获取清晰且高保真的指令。比如在设计任务中，一份HTML原型文件通常比文字描述或截图能带来更准确的输出结果。
主动做减法的实践建议
无论是系统提示词、Skills模块还是CLAUDE.md文件，你都可以参考团队的经验主动做减法。团队推出了名为claude doctor的工具，在Claude Code中使用/doctor命令，可以自动帮助你调整Skills和CLAUDE.md文件的体量，简化上下文配置。
如果想要进一步了解针对先进大模型的提示词编写技巧，可以查阅相关的官方指南。
