semantic-compression

语义压缩

压缩是重新编码，而非删除词语。从英文句子中筛掉功能词，只会留下残缺的英文句子（System design: efficient process incoming data, multiple sources）。应改用一种以标点和排版为语法的语体来重述每个论断——这样一来，功能词便无事可做，自然会消失。

目标文本承载着关键信息：工具描述、系统提示词、技能。模型会在没有作者在场、无法求证的情况下直接执行这些内容。迫使模型猜测的压缩是缺陷，不是节省。

流程

0. 密度门槛——动手前先检查。 依次查看两个信号：（a）冠词和系动词是否已接近消失？（b）压缩一个有代表性的部分，并测量 token 数的变化。文本是否已采用这种语体（内部风格提示词、工具文档、规范），或压缩幅度是否低于约 10%？停止。说明文本已经足够精炼，并保留原文。 项目符号的长度只是较弱的信号——API 字面量和枚举会使文本显得更长。在一个真实的内部风格工具提示词中测得：853 → 778 tokens（8.8%），但压缩过程悄无声息地删掉了一条 NEVER assume … 规则、一个抛出条件和一项 full-res 细节。对于已经足够精炼的文本，剩下的词语就是有效信息，预期节省量小于预期损失。
1. 拆分源文本，提取原子论断：每条只包含一个定义、义务、默认值或事实。
2. 先盘点有效信息，再删除任何内容。 列出每个承载关键信息的词项：标识符、错误／异常名称、抛出条件、带单位的默认值、边界，以及每条 MUST／NEVER／PREFER 要求。之后删掉的任何内容，都应是有意声明的损失，而非事后才发现的遗漏。
3. 删掉模型已知的内容。 “JSON 是一种文本格式”“测试能捕获回归问题”→删除。只保留特定于此工具、仓库或领域的内容。
4. 删掉重复表述。 将同一规则的所有重复表述合并为一条规范表述，并放在需要的位置。同一规则的两条陈述若适用范围不同，则不算重复。
5. 为每条论断选定句式——定义 · 义务 · 默认值 · 条件→结果 · 枚举 · 结论。根据句式选择构造方式。
6. 将重复限定条件提到统一作用域中： 三次提到“相对于仓库根目录”→在顶部写一次 All paths repo-relative.。
7. 重新编码，然后执行验证。

表达框架

frame	英文	压缩形式
definition	“name 字段是稳定的启动标识符。”	name: stable launch id.
obligation	“必须先调用 open，才能运行代码。”	MUST open before run.
default	“如果未提供值，超时默认为 30 秒。”	Default 30s.
condition→consequence	“由于导航会重新渲染页面，引用会失效，因此应该再次创建快照。”	Navigation invalidates refs → re-snapshot.
property chain	“z' 是整数，因为 z 整除 x²+y²；它是正数，因为 x²+y²>0。”	z' integer since z divides x²+y²; positive since x²+y²>0.
enumeration	“操作可以是 open、close 或 run。”	action: open, close, run.
exclusion	“既不是 (1,1,1) 也不是 (1,1,2) 的任意三元组”	triple ≠ (1,1,1),(1,1,2)
verdict	“断言 A 为真，断言 B 按其表述为假。”	A true; B false as stated.
precondition	“这要求分支已经检出。”	Requires prior checkout.

其背后的构式：

• 无动词断言 — X true / X false / X required / X unsupported。省略系动词；保留谓语。
• 标签框架 — 用 X: value 表示“X 是 / 意味着 / 由……组成”。每行只用一个冒号，绝不嵌套。
• 连续省略主语 — 只说一次主语，后续用裸谓语串联：Integer since …; positive since …; unique.
• 无连词并列 — 并列项目之间不加连词：articles, copulas, expletives.
• 范围声明 — 一行声明后，其后内容全部按此类型理解：All paths repo-relative. · Times in ms. · All congruences mod 4.
• 惰性说明 — 只说足以作出判断的信息：3·13·34-1 big（超过界限；具体值无关紧要）。要在读者看得到的地方说明界限。
• 转喻 — 用对象代表关于它的命题：y=z implies (1,1,1)。仅在只有一种确切解读时使用。

运算符

标点符号承载连接关系：

• : — 引出、命名、定义（“是”“表示”“如下”）
• → — 导致、产生、变成（“结果是”）
• ⇒ — 因此、得出结论
• — — 释义，或“因此”
• / — 等价地，即
• ; — 下一个步骤，同一话题（“然后”“之后”）
• , — 推理链（“因此”）
• ≠ — 两者都不是，在列表中分配使用
• ✓ — 已验证，义务已履行
• > — 优先级（“arg > env > default”）
• | — 枚举中的备选项（“open | close | run”）

歧义是唯一的淘汰条件，而非陌生感。若某个符号在其所在位置可能有第二种解读——— 可能是插入语破折号，/ 可能是路径分隔符或“每”，, 可能是列表逗号——就改用文字。

符号不会节省 token；结构才会。 测量结果（cl100k_base；Claude 的分词器有所不同，但罕见符号的 BPE 分词数量相近）：→、⇒、≤、·、✓ 各占 1 个 token，≡ 占 2 个，-> 占 2 个，而 gives 占 1 个。因此，用符号逐一替换文字既省不了 token，也会降低清晰度。仅当符号能替代一个多词短语时才使用。上标确实能节省 token：x²+y² = 4 个 token，x^2+y^2 = 6 个。

不要发明私有符号——定制符号需要图例，而图例的成本高于它所节省的内容。

删除

始终删除： 冠词；系动词（is/are/was/be/been）；虚义 there/it；补语标记 that；关系代词；程度副词（very、quite、really、extremely）；填充语（“in order to”→to、“due to the fact that”→because、“it is important to note that”→∅、“in terms of”→∅）；客套用语（“please”、“feel free to”）；带保留意味的表述（“you may want to consider”）。

除非承载关键信息，否则删除： 助动词（have/do/will）；指代对象明显的代词；介词 of/for/to/in/on/at/by；列表关系明显时的连词；动词已隐含其含义的副词（“shout loudly”）。

绝不删除——这些都是有效信息：

• 规范性情态词：MUST、NEVER、SHOULD、MAY。RFC 2119 中的词语 就是 指令。
• 否定和例外：not、no、never、without、none、except、unless。
• 数字、单位、边界、量词：“at least 5”、“≤100”、“max 1 MiB”、“1-indexed”。
• 条件和因果关系：if、unless、because、since、so。
• 真正表达不确定性的词语：“approximately”、“usually”、“appears”——删除其中任何一个，都会把原文未表达的确定性强加进去。
• 精确字符串：标识符、API 名称、标志、路径、正则表达式、格式字面量、错误文本。
• 展示某种结构的示例。压缩示例会破坏它所展示的内容。
• 会改变关系含义的介词：“read from X” ≠ “read to X”。
• 抛出／失败条件，以及关于静默失败的警告（“never assume it landed because no error appeared”）。这些看起来像填充语，实则描述行为。
• 经验教训：某行内容之所以存在，是因为有人已经犯过那个错误。它看似多余，正因为它现在能防止错误。在删掉任何看似显而易见的内容前，先运行 git blame。

私有语域——切勿发布

生成此语域的草稿风格包含一些特征，只有作者和读者是同一个人且相隔几分钟时才有效。请全部剔除：

• 外部指示语——A、B、C、G、“the equation”、“the claim above”。发布的文本必须自足：明确指出所指对象。
• 草稿残留——Hmm、Actually、Wait、just、fine、Good；在句中途修改的目标；放弃的分句。
• 层叠修正——错误值与其修正值并列保留。初次阅读者无法判断哪一版最终生效。删除错误版本。
• 废弃分支——放弃的方案仍与选定方案并列。模型可能会执行已放弃的方案。
• 含义模糊的 ... 和 ?——在笔记中，它们表示省略／放弃／无限，以及猜测／待核查；在发布的文本中，它们毫无意义。两者都删除。
• 嵌套冒号——Step: from X: cases: a,b=1: 3-c: 无法让初次阅读者解析。每行只使用一个冒号。
• 未标记的指令与数据——像 Word limit 1200 - write concisely 这样的独立行放在正文中，无法与正文内容区分。将指令置于带标记的渠道中：标题、标签或 MUST 行。
• 反复修订而非重写——思考时无妨，写入提示词则会造成严重问题。每条规则只保留一个权威表述。

工具和技能描述

正文可以大幅压缩，触发词不行。

• 工具或技能的 description 字段是检索入口，不是文档：它会与用户自己的措辞进行匹配。保留自然且关键词重复的替代表述（“压缩提示词”“减少 token 数量”“token 高效”），即便读者只需要其中一种。压缩正文；绝不要压缩触发词。
• 参数——只有当模型实际看到的 wire schema 暴露了类型、枚举或默认值，并且（如果运行过 tool-prompt-optimization 探测）探测仅从 schema 中恢复了这些信息时，才从说明文字中删除它们。否则保留。**默认值是陷阱：**wire schema 经常完全省略 default；即使存在，它也不包含方向或语义——gitignore: true 并不表示“遵循 gitignore”——因此 tool-prompt-optimization 将默认值及其方向归类为模型无法恢复的内容。没有这类证据时，保留默认值、单位以及任何优先级规则（参数 > 环境变量 > 默认值）。说明文字始终保留 schema 无法表达的内容：交互方式、优先级、失败模式。
• 操作使用祈使句（open before run）；事实使用标签格式（Default 30s.）。
• 划分职责——此技能只负责重新编码机制。工具提示词应包含什么（结构、面向使用者而非内部机制、哪些内容应排除）→ tool-prompt-optimization；它也会在删减前衡量 schema 与说明文字的重叠部分。风格规范（标签词汇、RFC 2119 关键词、位置）→ system-prompts。先让这两者决定要发布什么，再进行压缩。

示例

原文（55 个单词，63 tok）：

timeout 参数决定工具等待进程就绪的时长。如果未提供值，则默认值为 30 秒。请注意，如果同时指定了日志模式和端口，则必须同时满足这两个条件，进程才会被视为就绪。

压缩后（14 个单词，20 tok）：

Readiness timeout: default 30s. Log pattern + port both supplied ⇒ BOTH must pass.

因压缩过度而被拒绝 — timeout 30 log+port both：丢失了单位，丢失了 30 是默认值而非固定值这一信息，丢失了必须满足的要求，而且 both 指代不明。

验证

1. 列出所有删减的信息，再依据清单审查草稿。 逐一列出删去的主张、限定条件、默认值、示例或确切字符串，并说明为何文本即使省去它们仍然正确。明确列出的删减是读者可以审查的决定；未列出的删减则是无声的退化。对照清单进行审查，不要凭对原意的记忆判断。
2. 检查歧义。 对每个 : → — /，都要问：读者是否可能作出另一种解读？如有，就修正。留意源文中不存在的歧义——被删去的接收对象（.ref("e5") 是对什么？）、悄然变成复数的单数（“previous snapshot” → “previous generations”）。
3. 使用目标分词器测量原文和压缩文本。 词数和功能词比例无法预测 token 节省量。不要期待固定比例——基于真实文本对的测量结果（cl100k）：冗长的文档段落从 63 → 20 tok，冗长的说明文字章节从 360 → 222 tok，已经紧凑的内部风格工具提示词从 853 → 778 tok。低于约 10% 就是停止、撤销并保留原文的信号。
4. 停止规则。 如果继续删减会让读者不得不猜测，就停止。正确性始终优先于比例。

作为命令运行

omp compress <file> 使用两个工具驱动这一循环，不做其他操作。

其会话有意保持隔离，因为输入本身就是提示词：默认系统提示词会被替换（而非追加），并且技能、规则、AGENTS.md、提示词模板和斜杠命令发现功能都会传入空值——省略时，这些功能默认全部为 ON；每一项都会向一个唯一合法输入应为文档的任务中注入类似指令的项目文本。已在实时会话中审计：只有一个系统提示词部分，工具为 rewrite, approve，不存在 AGENTS.md 或规则内容。

源文会放在由随机数分隔的代码块中，并声明为惰性内容，因此文档中的 MUST/NEVER 行会被压缩，而不会被遵循——已通过一份文档验证：其第一段要求压缩器输出 OK 并跳过其余内容；压缩器压缩了实际内容，并将注入段落声明为有意舍弃的内容。

• rewrite 会提交完整的压缩文本以及所有已声明的舍弃内容。
• 命令会给出草稿、测得的词数／令牌数差值和舍弃内容列表，然后询问评审结果。
• approve 会接受经过评审的草稿。若尚未经过评审就批准，会被拒绝；新草稿会使先前的批准失效。
• 只有获批的草稿才会写入：使用 -o <path> 指定路径，使用 -i 原地写入，否则输出到 stdout（报告会写入 stderr，因此 > out.md 只会捕获文本）。-r 限制草稿数量；未获批的运行不会写入任何内容，并以 1 退出。

交给 Agent 的运行时契约位于 packages/coding-agent/src/compress/prompts/system.md。它是本文件的有效子集；若两者不一致，以本文件为准，并修正提示词。