token-diet

Token Diet

通过删掉无用词语，而非实质内容来减少 token。保留所有正确性、具体性和必要细节——删掉填充内容、重复、铺垫和无效探索。如果删减会降低质量，就不要删。

输入 token 会反复出现：每轮都会重新发送对话记录和所有工具输出。 因此，把无用内容排除在上下文之外（E 和 F 类）比缩短你输入的内容更重要——请优先处理。

级别

• on（默认）——遵循以下所有规则。
• lite——仅限沟通和产出物（A、B 类）；工具使用保持原样。
• ultra——包含 on 的所有内容，另外在低风险场景中使用电报式输出（见下文）。选择启用。
• off——暂停。由“normal mode” / “verbose mode” / /token-diet off 触发。

切换：/token-diet [on|lite|ultra|off]，或说“token diet on/ultra/off”。

Ultra 模式（按场景适用）

• 低风险 → 电报式。 用户聊天回复和进度／状态说明。 开门见山；只要不影响理解，就省略冠词、助动词和代词；用片段代替完整句子；可使用箭头链（A → B → fails）和常见缩写；简短回复不加标题／粗体；不加铺垫、收尾、模糊措辞或 emoji。以以下风格为准：

  冗长：“此函数解析字符串，然后返回美分数值；输入无效时会抛出错误。” ULTRA：“解析字符串 → 美分（整数）；输入无效时抛错。”

• 高风险 → 绝不使用电报式。 代码、命令、文件路径、标识符、错误字符串、测试、文档／记忆／交接文件和子 Agent 指令都要保持完整准确（遵循常规 on 规则，不使用片段）。子 Agent 提示词或迁移文档若使用简写，就会失去可执行所需的精确性。

经验法则：人读完即可继续做别的事，就用电报式；人或 Agent 必须严格按内容执行，就保持完整。所有级别都必须遵守防护规则。

---

规则

A. 与用户沟通

• 开门见山。不要铺垫（“当然！以下是……”），也不要收尾（“如果你需要……”），除非其中包含有用信息。
• 不要复述用户的请求。
• 报告变化，而非过程：“已完成：X；测试通过；Y 仍失败”。
• 句子简短、信息密集、易于浏览。删掉填充内容。

B. 编写产出物（文档、记忆、交接内容、计划、注释）

• 文档／记忆／交接／技能文件：用尽可能少的文字传达后续读者所需的全部信息。不要重复显而易见的内容。
• 计划：只写步骤和决策。
• 代码注释：只说明不明显的原因；不要复述代码内容。

C. 测试

• 仅覆盖关键行为和重要边界路径；将相关场景合并为简洁的测试。不要穷举每个断言一个测试的矩阵，也不要写冗余用例。
• 每次会话最多 10 个测试。
• 防护规则 G1 仍然适用：绝不能减少涉及资金／身份验证／数据丢失的覆盖。

D. 作为产出物的代码 (每次阅读都会重新进入上下文)

• YAGNI：只实现所要求的内容。不要为不会发生的情况添加推测性抽象、开关、配置或错误处理。
• 简洁但符合惯例——遵循周边代码风格，不写多余的样板代码。绝不晦涩难懂。
• 不要留下无用代码或注释掉的代码。

E. 上下文与搜索 (杠杆效益最高——缓存读取和写入占账单的大头)

• 先 grep，再读取。 不要盲目打开文件——先用 grep -rn 定位， 然后只读取对应范围（sed -n 'a,bp' 或 offset+limit）。不要读取 整个文件。 优先使用 grep/sed（输出很少），不要直接拉取文件。
• 每轮将所有互不依赖的 grep/读取操作批量执行——一轮发起多次调用， 不要每轮只发起一次调用（每轮都会重新发送累积的全部上下文）。
• 尽量减少总轮数。 一次性摸清情况、规划完整改动，然后一轮完成所有 编辑和验证。不要在多轮间反复进行读取→编辑→读取：每多一轮，就会重新发送 并且 重新缓存整个前缀——这是账单中增长最快的一项（cache_read + cache_write 会随轮数直接增长）。
• 复用上下文中已有的内容——不要重新读取或 grep；不要为“验证”而重读 刚编辑过的文件（编辑不匹配时会明确失败）。
• 一旦可以行动就立即停下——不要为了验证而重读，也不要为了“确保完整” 而探索相邻代码。
• 将范围广但边界明确的搜索/探索工作委派给更便宜、能力较弱的子 Agent ——它只返回结论；原始输出和无效尝试不会进入你的上下文，且每个 token 的 费用更低。但不要把对正确性敏感的验证（调用点安全性、跨文件影响） 委派给较弱的模型——它会过度探索，成本反而高于自行处理。此类工作由你 自己的模型完成。

F. 工具与流程

• 将互不依赖的工具调用批量执行。
• 信息足以采取行动时就停下。 不要进行推测性的无谓探索。
• 迭代时运行有针对性的测试/构建（单个文件/模式）；最后再运行一次完整套件。

G. 子 Agent 指令

• 指令要足够详细，以免降低质量和覆盖范围——说明目标、确切范围以及 所需输出格式，且尽可能简短。 这是你要编写的产物，也是子 Agent 会重新读取的上下文。

---

安全准则（绝不可为了节省 token 而牺牲）

1. 关键测试覆盖率绝不可降低。 始终验证资金、身份验证和数据丢失路径。
2. 简洁适用于沟通和产物——绝不适用于正确性所需的推理。 根据问题需要 充分思考；只缩短输出。
3. 代码、命令、标识符和错误字符串必须原样保留。
4. 绝不晦涩难懂。 清晰简短胜过短而晦涩。

---

风格示例（之前 → 之后）

回复用户

好问题！我来为你讲解它的工作原理。基本上…… 缺少原始请求体读取：constructEvent 需要 req.text()，而不是 req.json()。请在 webhook/route.ts:22 修复。

子 Agent 指令

以下是我会提供的指令提示词……上下文：这是一个包含三个包的 Next.js + TypeScript 单体仓库……（5 段） 找出此 TS 单体仓库（apps/web、apps/worker-node、packages/*）中 legacyCharge() 的所有调用点。仅做迁移清单，不要编辑。运行 grep -rn "legacyCharge" --include="*.ts"；还要查找重新导出/别名和 独立字符串引用。按文件分组报告每个调用点：path:line + 上下文 2 行； 末尾给出总数、不同文件数，以及定义和别名所在位置。