caveman

caveman 技能概览

caveman 是做什么的

caveman 是一种超压缩的沟通技能，适合你希望模型少一点废话、更少 token、措辞更紧凑的时候。它会保留技术含义，同时删掉填充语、客套话和冗长过渡。caveman 特别适合已经懂主题、只想更快拿到更高密度答案的人。

适合谁安装

如果你经常让模型帮你做简洁的调试说明、代码解释、摘要或状态更新，而且总要反复追问“短一点”“更直接一点”“别太啰嗦”，那就很适合装 caveman。它尤其适合开发者、运维用户，以及任何回答长度会直接影响效率的重复性技术工作。

它为什么不一样

和普通的“请简洁”提示不同，caveman 会加入明确的输出规则：去掉冠词和填充语，保留准确的技术术语，使用短片段，并原样保留代码和错误信息。这比一次性的风格请求更可靠，因为一旦触发，这种行为会持续生效。

如何使用 caveman 技能

安装并触发它

先在你的 skills 配置中安装 caveman 技能，然后用 caveman mode、use caveman、talk like caveman、less tokens 或 /caveman 之类的短语触发它。这个技能设计上会在激活后保持生效，直到你明确要求停止 caveman 或切回正常模式。

把粗略需求改成高质量 caveman 提示词

一次性把目标、硬性约束和输出形式都交代清楚。比较好的输入会像这样：Use caveman. Explain why this SQL query is slow, include the most likely cause first, keep exact error text, and give 2 fixes. 不好的输入则是 help me with this 这种模糊请求，因为 caveman 压缩的是措辞，不会自动补全缺失上下文。

先看这些部分

先从 SKILL.md 看起，因为它定义了响应风格、持续生效规则、输出规则，以及自动清晰度例外。按 caveman install 的思路，这里没有需要检查的辅助脚本或支持文件，所以实际流程比很多技能都简单：先理解触发方式，再拿一个真实任务测试。

用在压缩最有价值的场景

caveman 最适合技术写作、代码评审备注、事故更新、故障分诊，以及“解释这个输出”这类任务——简洁本身就能提升效率。若你需要的是温和语气、面向客户的润色文案，或结构很完整的长文档，就不太适合，除非你打算后续再改写。

caveman 技能常见问题

caveman 只适合技术写作吗？

不是。caveman 技能对技术写作很强，但也适用于开发者问答、排障和摘要。核心判断标准是：你更看重高密度信息，还是更看重打磨过的表达。

最大的限制是什么？

如果你的需求本身很模糊，或者涉及安全敏感内容，caveman 可能会过于简略。仓库里包含自动清晰度例外，这意味着在安全警告、不可逆操作，以及其他“说得太短会降低安全性或清晰度”的场景下，它应该放宽压缩风格。

我需要它来替代普通提示词吗？

如果你只需要一条简短回复，普通提示词可能就够了。只有在你反复想要紧凑回答、又不想每次重写指令时，才值得安装 caveman；或者当你希望在多轮对话中稳定保持“简短但准确”的模式时，也很适合。

caveman 适合新手吗？

适合，但前提是用户知道现实里“短一点”具体是什么意思。对需要手把手引导的新手来说，它就没那么合适，因为这种风格会去掉解释性铺垫，并且默认提示词已经提供了足够上下文。

如何改进 caveman 技能

优化输入，而不只是要求更短

提升 caveman 输出最快的方法，是一开始就明确目标、受众和输出格式。比如：Use caveman. Explain the bug for a teammate, mention root cause, 1 fix, and 1 verification step. 这样技能就有足够结构可以保持简洁，而不会变得空泛。

注意上下文是否缺失

caveman 最常见的失败方式是信息给得不够：如果你没有提供正在讨论的系统、错误、命令或代码片段，回复可能会压缩到没法真正使用。尽量补上确切代码、日志或约束，因为 caveman 在输入足够精确时，最能保留技术实质。

通过收紧要求来迭代

如果第一次输出还是太长，就要求更严格的格式：只要项目符号、先给一句话总结，或者 max 5 lines。如果回答太稀，就补一句 same caveman style, but include assumptions and next step。这样既能保持 caveman 技能的紧凑优势，又不会丢掉它最有价值的信息密度。