Anthropic 删减了引导 Claude Code 的 80% 系统提示词，并报告称其编写代码的能力并未下降。这项实验表明，随着大语言模型 (LLM) 能力的增强，开发者可以修剪掉用于引导模型的臃肿“脚手架”，而不会损害性能。

为什么提示词最初如此重要

Claude Code 发布时，其系统提示词列出了数十条规则。每当出现 Bug 时，工程师就会添加新行，但很少删除看起来有效的规则。随着时间的推移，提示词变成了一份杂乱且静态的文档。

模型差距正在缩小

那些额外的规则掩盖了“模型差距”——即模型实际能力与应用需求之间的差距。在 2024 年，开发者必须制定严格的约束条件，以防止模型（例如）在代码中添加过多的注释。而今天，同一个模型只需通过“匹配现有代码风格”这样的一条指令，就能推断出所需的风格。规则已从“帮助”变成了“噪音”。

上下文工程正在发生什么变化

Anthropic 的删减反映了开发者构建提示词方式的更广泛转变：

  • 一次性关键指令 – 陈述一次规则，让模型自行保留。
  • 使用工具驱动的参数而非少样本示例 (few-shot examples) – 在工具 schema 中描述输入和输出结构，让模型自行填充。
  • 渐进式披露 – 仅提供当前步骤所需的上下文，并在需要时稍后添加更多。
  • 将静态引导移至工具描述中 – 诸如“变量使用 camelCase”之类的要求应属于工具规范，而非系统提示词。
  • 用启发式方法取代硬编码规则 – 让模型决定规则何时适用，而不是无条件地强制执行。

这些策略之所以有效，是因为模型已经掌握了许多过去需要显式强化的惯例。

过度删减的风险

同样能让前沿模型受益的修剪，可能会损害较小的模型。Anthropic 指出，像 Haiku 这样的模型仍然依赖更丰富的提示词来保持运行轨迹。从能力较弱的模型中剥离过多的引导，可能会重新引入原始提示词试图防止的错误：命名不一致、注释过多或遗漏边缘情况。

如何审计你自己的提示词

如果你维护着一个代码生成流水线，提示词审计可以揭示冗余内容。一个实用的检查清单如下：

  • 重新调整指令密度 – 使引导量与你实际运行的模型相匹配。
  • 删除重复指令 – 如果一条规则同时出现在系统提示词和工具描述中，请仅保留一次。
  • 将已验证的示例转化为更丰富的 schema – 用枚举参数类型或枚举值 (enums) 取代具体的示例。
  • 将情境细节外部化 – 将大型参考块移至模型可以按需获取的独立文件中。
  • 删除针对已消失行为的规则 – 如果模型不再添加多余的注释，请删除“禁止注释”规则。

不要依赖直觉。使用简单的“三项测试规则”：运行五个真实的编码任务，比较每次删除前后的结果，并记录任何性能退化 (regressions)。

  1. 基准 (Baseline) – 使用完整提示词测量性能。
  2. 删除 (Delete) – 移除候选行或代码块。
  3. 重新运行 (Re-run) – 执行相同的五个任务。

如果输出发生了变化，说明你识别出了一行仍具有影响力的指令。如果没有变化，则该行可以安全地省略。

开发者接下来应该关注什么

目前，结论很明确：系统提示词是一个动态文档。请将每一行都视为有“保质期”的，定期进行审计，并让模型不断增长的能力来承担重任。

Source: dev.to/ialijr/your-system-prompt-has-a-shelf-life-maintaining-prompts-as-models-improve-cd9