Caveman 不是省 Token 的技巧，而是 AI Coding 的成本警报

观察日期：2026 年 7 月 4 日。

Caveman 这件事看起来像一个笑话：为了省 Claude 的 token，有人开始让模型用“原始人语法”交流，把完整句子压成更短、更粗糙的指令。

比如把“Please analyze this Android app and identify potential issues”压成类似“你看 APK，找问题”。

表面上，这是一个关于提示词压缩的小聪明。

但我觉得它真正暴露的，不是某个开发者会不会写 prompt，而是 AI Coding 正在进入一个更现实的阶段：当模型能力变成日常生产力，成本、配额、上下文和表达质量就会开始反过来塑造人的工作方式。

这不是笑话，是价格机制进入工程现场。

一、Caveman 为什么会出现

Business Insider 5 月报道过一个很典型的案例：Salt Lake City 的开发者 Alexander Huso 因为 Claude token 消耗太快，尝试让 Claude 用更短的“caveman speak”工作。他最初不是为了娱乐，而是想降低使用成本，尤其是在用 Claude Code 分析 Android APK、尝试安全研究和 bug bounty 方向时。

结果很直接：它确实更短，也更有传播性，但输出质量明显变差。他最后的判断是，这种方式不适合严肃代码工作。

这个结论一点也不意外。

软件工程不是“把一句自然语言压成最短命令”。软件工程依赖上下文、约束、假设、边界条件、失败路径和验证标准。你省掉的那些词，很多不是废话，而是模型理解任务所需的结构。

人类读“帮我看看这个 bug”时，会自动补全很多背景：这是哪种 bug、在哪个模块、有什么复现路径、不能破坏什么行为、应该跑哪些测试。

模型不会天然知道这些。你把表达压成 Caveman，它可能还能猜出方向，但会更容易丢掉细节。

所以 Caveman 的问题不是“语法好不好看”，而是：你把工程意图压缩成低分辨率信号，却期待模型输出高分辨率结果。

这在简单任务里可能没事，在复杂任务里会很快反噬。

二、为什么大家会想省 token

如果 AI 只是偶尔问答，token 成本不太容易被感知。

但 AI Coding 不一样。

Claude Code 官方文档对产品的定位很明确：它可以读代码库、编辑文件、运行命令，并接入 terminal、IDE、桌面端和浏览器。它不是聊天框里的补全工具，而是会跨文件、跨工具、跨步骤行动的 agent。

这意味着它天然会吃更多 token：

它要读代码。
它要理解历史上下文。
它要规划步骤。
它要写补丁。
它要解释修改。
它还可能跑测试、读报错、再修一轮。

传统 IDE 补全像是“每次多写几行”；agentic coding 更像是“把一个小任务外包给一个会读仓库的同事”。后者的上下文成本当然高得多。

这也是为什么 token 经济学会突然变重要。

Barron's 最近讨论 AI token 定价时提到，企业客户越来越难预测 AI 使用成本。高级模型和 agent 工作流会把 token 消耗拉得很高，而不同厂商的计量和套餐方式又不总是透明。对个人用户来说，这种压力表现为“今天额度怎么又没了”；对企业来说，则是预算、ROI 和工程效率之间的算账问题。

这就是 Caveman 的土壤。

当一个工具足够有用，人就会高频使用；当高频使用遇到配额和成本，人就会开始优化输入；当优化输入变成压缩语言，就会出现 Caveman。

它不是孤立的 meme，而是 AI Coding 成本结构的一种自然反应。

三、Caveman 也暴露了 AI 依赖

还有一层更有意思。

Business Insider 3 月报道 Claude 服务中断时，很多开发者突然意识到自己已经把一部分工作习惯交给了 AI。有人开玩笑说，Claude 挂了，只能像 Caveman 一样写代码。

这句话本身很讽刺。

过去“像 Caveman 一样写代码”指的是不用工具、手工硬写。后来 Caveman 又变成一种和 AI 说话的压缩语法。两个意思放在一起，正好说明开发者和 AI 的关系已经变了：

以前 AI 是加速器。

现在 AI 正在变成开发环境的一部分。

它不只是帮你补一个函数，而是帮你读陌生模块、定位 bug、写测试、解释 CI、重构代码、整理 PR。Claude Code 文档里列出的工作流，包括写测试、修 lint、解决 merge conflict、更新依赖、写 release notes、创建 commit 和 PR。这些都不是“玩具任务”，而是工程日常。

所以一旦它不可用，人的主观感受就不是“少了一个工具”，而是“工作流断了一截”。

这不是说开发者真的不会写代码了，而是工作记忆和操作路径已经被重新分配。人负责目标、判断和验收，AI 负责大量中间操作。

问题在于，如果人为了节省 token，把目标表达也压扁，那么整个分工就危险了。

你不能一边把执行权交给 agent，一边把意图表达压成片段。

四、Caveman 为什么会降低质量

模型不是越少字越聪明。

在 AI Coding 里，好的 prompt 不一定长，但一定要有结构。它至少要说明四件事：

目标是什么。
哪些文件、模块、行为不能破坏。
怎么验证。
遇到不确定时怎么处理。

Caveman 省掉的，常常正是这些东西。

比如“fix bug”比“修复移动端滚动自动加载时重复触发的问题，保留桌面端手动按钮，并跑 typecheck/lint/build”短得多。

但前者会让模型自由发挥，后者会让模型进入工程约束。

再比如“make URL short”比“允许 frontmatter 自定义公开 slug，保留文件名派生 sourceSlug，旧 URL 永久重定向，related 同时支持新旧 slug，检查 slug 冲突”短得多。

但后者才是可维护设计。

这就是 Caveman 的核心损失：它把工程问题重新退化成“命令问题”。

AI Coding 真正有效的时候，不是人给一个粗糙命令，模型魔法般完成一切；而是人把需求、边界和验证方式表达清楚，让模型在可控空间里加速。

Caveman 省的是 token，损失的是约束。

五、成本优化不等于语言退化

但我不想把 Caveman 简单嘲笑掉。

它提出的问题是真的：AI Coding 成本需要优化。

只是优化方向不应该是把人类语言变粗糙，而应该是把上下文管理变专业。

更合理的做法有几类。

第一，减少无效上下文，而不是减少关键约束。

比如不要每次把整段历史都塞给模型，而是维护清晰的项目说明、架构约定、测试命令和当前任务边界。让模型少读废话，多读规则。

第二，把重复意图沉淀成文件和技能。

像 AGENTS.md、项目脚本、review checklist、写作 skill、测试脚本，本质上都是把反复出现的上下文结构化。它们比每次临时用 Caveman 语法省 token 更可靠。

第三，分层使用模型。

不是所有任务都需要最贵模型。探索、格式化、简单重命名、机械迁移，可以用便宜模型或本地脚本；架构判断、安全边界、复杂调试，再用强模型。

第四，把验证前置。

真正贵的不是多写几句 prompt，而是模型理解错以后反复返工。一次清楚的约束，加上自动化测试，往往比三轮短 prompt 更省钱。

第五，学会让 agent 少动。

很多时候应该先让模型读、总结、列方案，而不是立刻改代码。先建立共同地图，再执行修改，反而更省 token 和时间。

所以成本优化不是“说话变原始”，而是“工作流变清楚”。

六、企业会怎么处理这个问题

个人用户遇到 token 成本，会发明 Caveman。

企业遇到 token 成本，会发明预算、权限、审计和 KPI。

arXiv 上 7 月 1 日发布的一篇关于 Microsoft 早期 2026 年推广命令行 AI coding agents 的研究，观察了数万名工程师使用 Claude Code 和 GitHub Copilot CLI 的情况。论文的核心发现之一是，采用者合并的 PR 数量大约比预期高 24%，但作者也提醒，合并 PR 不等于真实业务价值。

这个结果很重要。

它说明 AI coding agents 确实可能带来产出提升，但也说明组织不能只看“用了没有”和“PR 多了没有”。企业真正要回答的是：

多出来的 PR 是不是更有价值？
review 成本有没有上升？
bug 和返工有没有变多？
token 成本是否低于节省的人力时间？
junior 工程师有没有失去训练机会？
团队是不是更依赖少数懂 AI workflow 的人？

在企业环境里，Caveman 式压缩不会成为主流，因为它太不可控。

企业更可能走向相反方向：更标准的 prompt template、更强的权限控制、更细的日志、更严格的预算、更明确的验收标准。

个人用 Caveman 是为了省 token。

企业反而会花更多 token 来买可控性。

这听起来矛盾，但很合理。因为企业最怕的不是 token 贵，而是便宜 token 生成了昂贵事故。

七、对开发者的真正提醒

Caveman 给开发者最大的提醒，不是“不要省 token”。

而是：不要把表达能力误当成可以随便压缩的成本。

AI Coding 时代，开发者的价值会从“亲手敲每一行代码”转向几种能力：

定义问题。
切分任务。
设计约束。
判断输出。
建立验证闭环。
管理上下文和成本。

这些能力都依赖表达。

如果一个开发者为了省 token，把需求压成几个残缺动词，他可能短期省了一点额度，但长期会训练自己放弃精确表达。

这比多花 token 更危险。

因为未来更稀缺的不是“会不会让 AI 写代码”，而是“能不能把复杂问题表达成模型可以可靠执行的结构”。

这里的表达，不是文学表达，而是工程表达。

它包括前提、边界、验收、风险、优先级、回滚方式和不该做什么。

这也是 AI Coding 和 Vibe Slop 的分界线。

前者是加速工程闭环。

后者是用速度掩盖缺少闭环。

八、我的判断

Caveman 会作为 meme 留下来，但不会成为严肃工作流。

它真正有价值的地方，是把一个隐蔽问题讲得很直白：AI 的“语言成本”已经变成软件工程的一部分。

以前开发者关心 CPU、内存、网络、构建时间、云账单。

现在还要关心上下文窗口、token 消耗、模型层级、agent 步数、重复推理、工具调用成本。

这不是坏事。

任何技术进入生产，都会从魔法变成成本项。数据库如此，云计算如此，AI 也会如此。

真正成熟的 AI Coding，不会靠 Caveman 省钱，而会靠流程省钱：

把背景写进项目文件，把重复工作变成脚本，把验收变成测试，把复杂任务拆成小步，把高价值判断留给强模型，把低价值机械动作交给便宜工具。

所以 Caveman 的结论不是“少说话”。

恰恰相反。

越是昂贵的模型，越需要高质量表达。越是自动化的 agent，越需要明确边界。越想省 token，越不能省掉工程判断。

这才是 Caveman 这个小笑话背后的大问题。