在大语言模型调用成本持续增长的背景下，提示词的 token 消耗已成为工程团队必须直面的话题。GitHub 用户 JuliusBrussee 开源的 Caveman 项目展示了一种截然不同的思路：不依赖复杂推理优化，而是通过最原始的语言简化手段，将 token 消耗降低约 75%。这一数据背后并非魔法，而是对大语言模型输出特性的深刻洞察与系统化的压缩策略。
语言填充物的系统性剥离
Caveman 项目的核心机制建立在对标准语言模型输出行为的观察之上。训练数据中的语言习惯导致模型倾向于生成大量「礼貌性填充」，包括冠词（a、an、the）、客套语（「I would be happy to」「Glad to help」）以及缓冲性短语（「it might be worth considering」「one could argue that」）。这些表达在人类交流中传递社交信号，但在纯技术任务中并不贡献实际信息。
工程参数层面，Caveman 通过前缀指令激活简化模式，典型触发方式为特定命令或系统级提示词配置。关闭同样简洁，仅需「stop caveman」或「normal mode」即可恢复标准输出。这一设计降低了使用门槛，使团队可以在不同任务类型间灵活切换。
值得注意的是，Caveman 并非不加区分地删除所有修饰成分。代码块保留标准语法，技术术语完整保留，错误信息原样引用。这意味着削减对象经过精确筛选：仅移除不影响技术准确性的语言层，核心信息结构毫发无损。
结构化输出的工程化参数
除去语言层面的压缩，Caveman 项目的实践揭示了另一个关键维度：输出格式的结构化约束。当任务类型可预测时，预先定义严格的输出模板可以同时压缩输入与输出两侧的 token 消耗。
在工程实践中，建议为高频任务定义短格式模板。例如，代码审查任务可限制为「问题位置：行号。类型：缺陷类别。修复建议：一句话。」这种结构消除了自然语言描述中的冗余表达，将每条反馈压缩至确定性字段中。类似地，提交信息生成、API 文档缩写、测试用例生成等场景均适用此原则。
输出长度管理需要显式且紧凑的约束。模糊的「简短回答」不如「不超过三行、每行不超过 20 个词」有效。大语言模型对数值型约束的遵守度远高于描述性约束，这在多个基准测试中得到验证。实施时可在系统提示词中加入「max N bullets; total M words」类硬性限制。
上下文裁剪的阈值策略
在多轮对话或长上下文中，token 消耗呈累积趋势。Caveman 项目的设计哲学隐含了一个重要工程决策：每次交互独立处理最大化，减少对历史上下文的依赖。具体实现涉及三个可量化参数。
上下文窗口利用率阈值建议设置在 60% 至 70% 之间。超过此比例时，系统应触发摘要压缩或关键信息提取，将历史对话凝练为结构化的状态快照。另一参数为「无新信息对话轮数上限」，通常设置为 3 至 5 轮 —— 当连续多轮对话未引入新实体或任务目标时，清理早期上下文是合理的。
示例选择策略同样影响 token 效率。Few-shot 场景中，每个示例应控制在 2 至 3 句话以内，且优先使用与当前任务高度相关的领域特定案例。避免使用冗长的示例演示 ——Caveman 风格的单句示例配合明确的任务描述，往往优于多段落的长示例。
实施监控与回滚机制
Token 优化带来成本下降的同时，也引入了质量波动风险。推荐部署两层监控：上游监控 token 消耗速率与单次调用平均值，设置同比与环比阈值报警；下游监控任务成功率与输出有效性，当质量指标下降超过 10% 时触发人工复核。
回滚策略应设计为渐进式而非全有或全无。当发现特定任务类型质量下降时，可以针对性恢复该类型的语言填充，而非一键切换回完整模式。例如，代码解释任务可恢复技术术语的完整阐述，但保持请求格式的简洁性。这种颗粒度控制需要在提示词管理系统中预留配置化能力。
从成本视角审视，75% 的 token 节省意味着相同预算下的调用频次可提升至四倍，或在固定频次下将上下文窗口扩大至原来的四倍。对于日均调用量超过数万次的中大型系统，这一优化幅度的经济价值极为可观。Caveman 项目证明了一个朴素但常被忽视的真理：在追求模型能力上限的同时，不应忽略最基础的输出效率 —— 有时候，少说一点，效果同样，而成本截然不同。
资料来源：Caveman 项目 GitHub 仓库由开发者 JuliusBrussee 发布，基于 MIT 许可证开源。