Claude Code削减80%提示词的启示：少即是多的提示词工程

引言：当提示词工程走向反直觉

在AI编程助手日益普及的今天，如何设计和优化系统提示词（System Prompt）成为决定产品体验的关键因素。Anthropic 的 Boris Cherny 在一场技术分享中抛出了一个反直觉的观点：他们将 Claude Code 的系统提示词削减了整整 80%，而产品表现不仅没有下降，反而变得更好。

Claude Code 是 Anthropic 推出的终端环境AI编程助手，采用Agent架构——模型不仅生成文本回答，还能自主决定调用文件读写、终端命令、代码搜索等工具，形成"思考-行动-观察"的自主循环。在这种架构中，系统提示词定义了Agent的行为边界、工具使用策略和安全约束，其重要性远超普通对话场景。更关键的是，每一轮工具调用都会重复携带系统提示词，这意味着累积的Token消耗极为可观，削减提示词在此场景下风险更高但收益也更大。

这一做法挑战了许多人对提示词工程的固有认知——长期以来，行业普遍相信「更详细、更冗长的指令能带来更精确的模型行为」。Boris 的实践则揭示了一个正在被越来越多团队验证的趋势：随着底层模型能力的提升，繁琐的提示词反而可能成为负担。

为什么冗长的提示词会成为累赘

提示词膨胀的历史包袱

AI 编程工具在发展初期，往往需要通过大量的规则、示例和约束来「教导」模型如何完成任务。开发者会在系统提示中写入各种边界条件、格式要求、行为规范，试图覆盖所有可能的场景。随着时间推移，这些提示词不断累积，形成了庞大而臃肿的指令集。

然而，这种做法存在几个根本性问题：

• 占用上下文窗口：冗长的提示词会占用宝贵的上下文窗口（Context Window），挤压真正用于处理用户任务的空间。上下文窗口是大语言模型在单次推理中能够处理的最大Token数量——Token是模型处理文本的基本单位，一个英文单词通常对应1-2个Token，中文每字约1.5-2个Token。以Claude为例，系统提示词、用户历史对话、当前输入（包括项目代码文件内容）以及模型生成的输出，全部共享这一有限空间。当系统提示词占据过多空间时，留给代码上下文和多轮对话历史的空间就会被严重压缩，直接影响模型对复杂编程任务的理解深度。

• 规则相互冲突：过多的规则之间可能产生歧义，让模型在决策时陷入混乱。例如，一条规则要求「优先生成简洁代码」，另一条要求「确保所有边界条件都有显式处理」，当两者冲突时模型的行为就变得不可预测。

• 与模型能力重复：随着模型自身能力的迭代升级，许多曾经必要的「手把手指导」已经变得多余。现代大模型经历预训练（海量文本学习）、监督微调（SFT，学习指令遵循）和人类反馈强化学习（RLHF/RLAIF）三个训练阶段。在后两个阶段，模型已经内化了大量关于代码规范、安全约束、输出格式等知识。当系统提示词重复这些已被训练内化的规则时，实际上是在给模型发送冗余信号，这可能导致模型过度关注这些显式规则而忽视用户意图的细微差别，产生类似"过拟合"的僵化行为。

模型能力提升带来的范式转变

Boris Cherny 的核心洞察在于：当基础模型（如 Claude 系列）本身已经具备强大的推理和代码理解能力时，过度的提示约束反而会限制模型发挥其固有能力。削减 80% 的提示词，本质上是对模型「信任度」的一次重新校准——从「事无巨细地告诉模型该做什么」转向「给模型足够的自由度去发挥」。

这与大模型领域的一个普遍规律相呼应：随着模型规模和训练质量的提升，「少即是多」的原则愈发显现。这一规律在学术界被称为"涌现能力"（Emergent Abilities）——当模型参数规模跨越某个阈值后，它会突然展现出在较小规模时完全不具备的能力，如复杂推理、代码生成、多步规划等。这意味着曾经需要通过提示词"补偿"的能力缺陷，在新一代模型中可能已经不复存在。精简的提示词不仅降低了推理成本，还能让模型的输出更加自然和灵活。

削减提示词的实践意义

对产品性能的直接影响

削减系统提示词带来的好处是多维度的：

1. 降低 Token 消耗

对于像 Claude Code 这样每天处理海量请求的产品而言，系统提示词是每次调用都会附带的固定成本。将其削减 80%，意味着在大规模应用场景下能够节省相当可观的计算资源和费用。以一个具体场景为例：如果原始系统提示词为5000 Token，每天处理100万次请求，削减80%意味着每天节省40亿Token的输入处理量。按照API定价，这可能对应每月数十万美元级别的成本节约。更重要的是，在Agent架构中，一次复杂任务可能涉及数十轮工具调用，每轮都携带完整系统提示词，削减效果会被成倍放大。

2. 提升响应质量

精简后的提示词减少了模型的「认知负荷」，让它能够将更多注意力集中在用户的实际需求上，而非纠结于满足一堆预设的规则。从Transformer架构的注意力机制角度理解，模型的注意力资源是有限的——当系统提示词过长时，模型需要在这些指令Token和用户实际输入之间分配注意力权重。精简提示词相当于减少了"竞争"注意力的噪声Token，让模型能更准确地捕捉用户意图中的关键信息。这也解释了为什么削减后产品表现反而更好——去掉了那些干扰模型判断的冗余信息。

对提示词工程方法论的反思

Boris 的分享为整个行业提供了一个重要的方法论启示：提示词优化不应该是「做加法」，而更应该是「做减法」。

当遇到模型表现不佳时，工程师的第一反应往往是添加更多的指令来「修补」问题，但这可能只是掩盖了症状，甚至引入新的问题。这种模式在软件工程中被称为"技术债务"的累积——每一条新增规则短期内可能解决了一个特定case，但长期来看增加了系统复杂度，使得整体行为更难预测和调试。相反，定期审视并精简提示词，剔除那些已经被模型能力覆盖、或者实际上从未生效的部分，是一种更健康的工程实践。

这需要团队具备对模型能力边界的深刻理解，以及大量的 A/B 测试来验证每一次删减的效果。在AI产品场景中，A/B测试的实施比传统软件更为复杂。由于大模型输出具有随机性（受temperature等采样参数影响），单次对比往往不具统计意义。团队需要在大量真实用户请求上运行对照实验，使用多维度指标进行评估：代码正确性（通过单元测试通过率衡量）、用户接受率（edit acceptance rate）、任务完成步数、Token效率等。此外还需要区分不同难度的任务类型，确保精简后的提示词在简单任务和复杂推理任务上都不会退化。这种严谨的验证流程，正是大规模删减提示词的信心基础。

对开发者的启示

重新评估你的系统提示词

对于正在构建 AI 应用的开发者而言，Claude Code 团队的经验值得借鉴。你不妨审视一下自己产品中的系统提示词：其中有多少内容是真正必要的？有多少是历史遗留、从未验证过效果的「安全网」？

一个可行的做法是进行系统性的消融实验（Ablation Study）——逐步移除提示词中的不同部分，观察模型输出质量的变化。消融实验这一方法源自神经科学，最初指通过移除大脑特定区域来研究其功能。在机器学习领域，它被广泛用于评估模型各组件的贡献度。将这一思路应用于提示词工程，意味着系统性地删除提示词中的特定段落或规则，然后通过自动化评测量化其影响。具体操作上，建议先对现有提示词进行功能分类（如安全约束、格式要求、行为引导、领域知识等），然后逐类别进行删除测试，记录每次变更对核心指标的影响。你可能会惊讶地发现，很多自认为「不可或缺」的指令，删掉后其实毫无影响，甚至效果更佳。

与模型能力共同演进

更深层的启示在于，提示词工程不是一劳永逸的工作。随着底层模型的持续升级，昨天必要的提示词今天可能就成了多余。以一个具体的演变轨迹为例：在GPT-3时代，你可能需要在提示词中明确写出"请使用Python的列表推导式而非for循环"这样的代码风格指导；到了GPT-4时代，模型已经能自行判断最适合的代码风格；而到了最新一代模型，甚至连"请写出高质量、可维护的代码"这样的泛化指令都可能是多余的，因为这已经是模型的默认行为。

开发者需要建立一种「与模型能力共同演进」的思维方式，定期回顾和调整自己的提示策略，而不是让提示词随着时间不断膨胀、僵化。一个实用的建议是：每当底层模型发生版本升级时，将其视为一次"提示词重审"的触发点，重新运行消融实验，主动寻找可以删减的部分。

结语

Boris Cherny 分享的「削减 80% 提示词」实践，看似只是一个技术细节，实则折射出 AI 应用开发正在经历的深刻转变。随着模型能力的飞跃，我们对提示词的理解也需要与时俱进——从繁琐的规则堆砌，走向对模型能力的信任与放手。

这一趋势也暗示着提示词工程师这一角色的未来演变方向：从"编写尽可能详尽的指令"转向"理解模型能力边界并设计最小有效指令集"。未来优秀的提示词工程，可能更像是一门关于"知道什么不该写"的艺术。

对于所有在 AI 时代构建产品的团队来说，这或许是一个值得铭记的原则：最好的提示词，往往是那些你敢于删掉的部分。 当然，这一切的前提是有一个足够强大的基础模型作为支撑，以及一套严谨的验证机制来确保每一次「减法」都是有依据的优化。