Token 这么用最夯 —— 培训材料（实操版）

精选文章

核心章节

60+

实战技巧

97%

最高可省成本

核心理念

Token 是 AI 编程时代的"燃料"——用得好是生产力倍增器，用不好是吞金兽。Token 不是省出来的，是用出来的。真正值得追求的是：让模型少走冤枉路，把 Token 花在判断上，而不是花在搬运上。

1 认知升级 —— Token 不是省出来的，是用出来的

理解 Token 消耗的底层机制，建立正确的成本认知

AI 编程 Token 经济学：理解消耗机制，让同样的额度多干 3 倍活

认知升级

中心思想：深入解析 Token 消耗机制，帮助开发者理解成本构成并提供优化策略，实现同样的 Token 额度完成更多工作。

用户输入只占 1%-5%：真正的大头是 System Prompt 和对话历史
缓存机制是省钱关键：缓存命中 Token 价格仅为全价的 1/10，维护一个持续 Session 能大幅节省成本
四类配置加载策略：Memory（全量常驻）、Rules（常驻+触发式）、Skills（按需加载）、MCP（Schema常驻）
Sub-Agent 核心价值是防膨胀：不是省钱，而是防止主上下文被工具结果无限膨胀
保护缓存链：一个 Session 干到底、不中途改配置、不频繁切模型

落地步骤：检查你的 Token 消耗构成

打开 CodeBuddy 设置，查看当前使用的 System Prompt 大小（通常在 5k-25k Token）
在对话中使用 /context 命令，查看当前上下文的 Token 明细分布
识别占比最高的部分：是 Rules？是 MCP 工具描述？还是对话历史？
优先优化占比最高的部分，通常 Rules 和 MCP 工具描述最容易压缩

原始文档

2 实战技巧 —— 立即可用的省 Token 大法

从 Prompt 设计到上下文管理，立即可用的具体操作方法

我以为只是问了一个问题，账单说它跑了 38.8 万 Token

实战技巧

中心思想：Token 消耗的大头不是模型输出，而是 Agent 为回答问题而"搬运"的上下文信息。优化提问策略可大幅节省成本。

两大步提问法：第一步让 AI 只做"地图"（低成本定位相关文件），第二步再读"房间"（确认范围后读取指定片段）
精准提问 vs 开放式探索：同一任务，精准提问可省 52.3% Token（38.8万 → 18.5万）
五大漏损点：全仓搜索、臃肿 Rules、MCP 工具描述、长对话历史、冗余输出
15 分钟账单体检：定期检查单次请求 Token 量、输入/输出比例、同类任务差异
输出只要三样：关键结论、修改点 diff 摘要、需要确认的风险

落地步骤：两步提问法实操

场景：要在项目中找到并修改用户登录相关的逻辑

第一步（地图模式，低成本）：
"项目中哪些文件涉及用户登录认证？只列出文件名，不要读取内容。"
消耗约 2-5k Token
第二步（精读模式）：
"请读取 src/auth/login.js 和 src/middleware/auth.js，分析登录流程中 token 校验的逻辑，找出可能的漏洞。"
消耗约 8-15k Token
对比反面教材：
"帮我看看登录相关的代码有没有问题" → Agent 会全仓搜索、读取十几个文件，消耗 30-50k Token

原始文档

上下文单一信源与 Token 节约 Tips

实战技巧

中心思想：通过"审计-瘦身-运行时压缩"的优化方案，解决上下文窗口膨胀导致的 Token 浪费和性能下降问题。

单一信源配置：Skills、Rules、MCP 统一 Git 管理，各 IDE 通过软链接引用，一处修改四处同步
CodeGraph + ccc 检索分工：符号/调用链走 CodeGraph（省 47% Token），概念/语义走 ccc（省 70% 检索 Token）
Headroom 压缩工具输出：代码搜索 Token 压缩率达 92%，准确率基本不掉
Caveman 压缩 Agent 回复：极简风格回复，可节省 65-75% 输出 Token
定期审计上下文：用 /context 或 Context Sync 查看 Token 明细，按占用从高到低优化

落地步骤 1：单一信源配置（软链接方案）

将 Rules、Skills、MCP 配置统一放到一个 Git 仓库，各 IDE 通过软链接引用

Bash 命令示例
# 1. 创建统一的配置仓库mkdir ~/ai-configs && cd ~/ai-configs
git init

# 2. 目录结构
~/ai-configs/
  rules/# 通用 Rules 文件skills/# 共享 Skillsmcp/# MCP 配置# 3. 在 VS Code 的 CodeBuddy 中创建软链接# macOS/Linux:ln -s ~/ai-configs/rules ~/.codebuddy/rules
ln -s ~/ai-configs/skills ~/.codebuddy/skills

# 4. 在 Cursor/Windsurf 中同样链接ln -s ~/ai-configs/rules ~/.cursor/rules
ln -s ~/ai-configs/skills ~/.cursor/skills

# 效果：修改 ~/ai-configs/rules 下的文件，所有 IDE 自动同步

落地步骤 2：CodeGraph + ccc 检索分工

根据查询类型选择最合适的检索工具，避免"大炮打蚊子"

查询类型	推荐工具	原因	示例命令
找函数定义、调用链、类继承关系	CodeGraph	结构化索引，精准定位	`@codegraph find-caller UserService.login`
找概念、语义相似代码、业务逻辑	ccc	语义向量匹配，理解意图	`@ccc "用户登录后如何生成 JWT"`
全文搜索特定字符串	grep	最简单直接	`grep -r "login" src/`

Prompt 示例：指导 Agent 使用正确工具
"先使用 CodeGraph 找到 UserService 的所有调用者，
然后使用 ccc 搜索与 'session timeout handling' 语义相关的代码片段。
不要一次性读取整个 src 目录。"

落地步骤 3：Headroom 压缩工具输出

在 Rules 中配置 Headroom 压缩，自动压缩工具返回的大段输出

.codebuddy/rules/headroom.md
# 配置 Headroom 自动压缩
- 当工具返回的代码/日志超过 200 行时，自动使用 Headroom 压缩
- 压缩规则：保留前 5 行和后 5 行，中间用 "... [N lines omitted] ..." 替代
- 文件搜索返回时，只显示文件路径和匹配行，不显示完整内容

# 效果：一次代码搜索从 15k Token 降到 1.2k Token

落地步骤 4：Caveman 压缩 Agent 回复

在对话开头或 Rules 中加入压缩指令，让 Agent 用极简风格回复

Prompt 示例
"请以极简风格回复（Caveman 模式）：
只输出结论和必要的代码 diff
不要解释已知的前提条件
不要输出'好的，我来...'等礼貌用语
列表用 - 而非数字编号
代码块只包含修改的部分，用 // ... existing ... 标注未修改区域"

原始文档

用模型，讲卫生

实战技巧

中心思想：Token 消耗差异源于使用习惯。通过"多快好省"的策略，可以显著缓解"Token 焦虑"。

锁死推理档位：关闭自适应思考，固定 effortLevel 和 MAX_THINKING_TOKENS，避免模型偷偷加码
固定内容写好别动：SOUL.md、项目背景写好后不要修改，任何字词改动都会导致缓存失效
PPT 是脏东西：复杂格式文件先转 Markdown 再喂模型，推荐 MarkItDown 或 Fire-PDF
及时开新对话：任务换了、跑偏了、间隔超 1 小时，果断开新对话
精准指定：用 @ 精准引用文件或函数，不要让 AI 自己扫一片
把"想"和"干"拆开：SOTA 模型输出方案，便宜模型执行代码替换，成本差 3-5 倍

落地步骤 1：锁死推理档位

CodeBuddy 配置（settings.json）

{
  "codebuddy.model.effortLevel": "low",
  "codebuddy.model.maxThinkingTokens": 2000,
  "codebuddy.model.adaptiveThinking": false
}
# 说明：low 模式足够处理 80% 的日常编码任务
# maxThinkingTokens 限制模型自我反思的 Token 上限
# 关闭 adaptiveThinking 防止模型根据问题复杂度自动加码

落地步骤 2：PPT/Word 转 Markdown

命令行转换
# 安装 markitdown（微软出品）pip install markitdown

# 转换 PPT 为 Markdown（Token 减少 60-80%）markitdown design-spec.pptx > design-spec.md

# 转换 PDFmarkitdown api-doc.pdf > api-doc.md

# 在 Prompt 中引用转换后的文件"请基于 @design-spec.md 中的需求，实现用户注册功能"

落地步骤 3："想"和"干"分开

分阶段执行示例
# ===== 阶段 1：思考（用强模型，如 Claude/GPT-4）====="请分析这个需求的实现方案，输出：
1. 需要修改的文件列表
2. 每个文件的修改要点（自然语言描述）
3. 潜在风险点
不需要输出代码。"# ===== 阶段 2：执行（用便宜模型，如 GPT-3.5/国产模型）====="请按照以下方案修改代码：
[粘贴阶段 1 的方案]
只输出修改后的代码 diff。"

原始文档

额度变少以后，我对 AI 用法做了几处调整

实战技巧

中心思想：额度变少并非坏事，它倒逼用户从"随手问模型"升级为"会调度模型"，将有限资源投入到真正高价值的任务上。

明确问题再提问：先写清楚目标、已知事实、边界和期望输出，避免 AI 在错误方向上浪费 Token
分层使用模型：简单任务用便宜模型，复杂任务才用强模型——"该用强模型时就用，不该用时别默认用"
保持上下文干净：阶段性结论写入文件，让 AI 按需读取，而非所有历史塞在同一个对话里
沉淀可复用资产：将重复经验沉淀为 checklist、模板、Skill，减少每次从零开始的消耗
克制使用多 Agent：线性任务强行拆分反而浪费 Token 在分工、复述和合并上

落地步骤：提问前自检清单

提问模板（在记事本里先写好再粘贴）
【目标】我要实现什么功能/解决什么问题

【已知事实】
- 当前使用的框架/库版本：___
- 相关文件：@file1, @file2
- 已经尝试过的方案：___

【边界条件】
- 不能修改的文件/模块：___
- 必须兼容的版本：___
- 性能要求：___

【期望输出】
- [ ] 只需要修改思路
- [ ] 需要完整代码
- [ ] 只需要代码 diff
- [ ] 需要风险评估
                        

原始文档

CodeBuddy 高级模型 Token 节省技巧

实战技巧

中心思想：从输出端、输入端、处理端三个维度提高信噪比，科学提效而非盲目省钱。

Rules 防御边界：禁止无效输出（文档、测试代码、废话），按任务复杂度分级解释
需求结构化拆解：单次对话明确边界条件，多说"要怎么做"，少说"不要做什么"
技术方案预确认：复杂需求先让 AI 用自然语言描述修改计划，确认无误后再生成代码
上下文动态管理：精准引用、对话隔离、/compact 压缩、Skill 按需加载
模型分级调用：高级模型处理复杂逻辑，免费模型承担简单任务
利用 Prompt Caching：固定 Rules 放对话开头，缓存命中后价格降至 1/10

落地步骤：编写高效的 Rules 文件

.codebuddy/rules/coding-rules.md（推荐写法）
# === 防御边界（禁止项）===
- 不要输出单元测试代码，除非明确要求
- 不要输出 JSDoc/Docstring，除非接口有变化
- 不要解释显而易见的代码逻辑
- 不要输出 "以下是修改后的代码" 等过渡语

# === 输出格式要求 ===
- 使用代码 diff 格式展示修改
- 未修改区域用 // ... existing ... 占位
- 多文件修改时，按文件分组输出

# === 任务分级（根据复杂度自动调整）===
- 简单任务（改bug、重命名）：直接给代码，不解释
- 中等任务（新功能）：1-2 句话说明设计思路 + 代码
- 复杂任务（架构调整）：先输出方案概述，确认后再给代码
                        

落地步骤：技术方案预确认

对话流程示例
# 第 1 轮（低成本确认方案）"我需要在项目中添加 Redis 缓存层，用于缓存用户会话。
请先描述你的实现方案，包括：
1. 需要新增/修改哪些文件
2. 缓存 key 的命名策略
3. 过期时间设置
4. 异常降级策略
先不要写代码，我确认方案后再继续。"# 用户确认方案后...# 第 2 轮（执行编码）"请按照刚才确认的方案实现代码，只输出 diff。"

原始文档

CodeBuddy 上下文管理简明教程

实战技巧

中心思想：主动管理上下文可以显著降低 Token 消耗，同时提升 AI 的响应质量。

及时开启新会话：回答质量下降、对话过长、话题多次转换时，直接开新会话
压缩当前会话：使用 /summarize 将核心信息压缩至原本的 15% 以内
巧用 Rules 和 Memory：固化长期偏好，避免每次重复说明；Rules 支持 always/agentic/manual 三种加载策略
优先使用 Skills，谨慎使用 MCP：Skills 显式调用、定义不占上下文；MCP 隐式调用、工具定义占用大量上下文
精准引用文件：有针对性地使用 @file、@folder，只引用真正相关的内容
CodeBuddy 已优化：缓存命中率提升至 90% 以上，Sub-agent 分离高消耗操作

落地步骤：会话管理决策树

什么时候该开新对话？

对话长度 > 20 轮？
├─ 是 → /summarize 总结关键信息，然后开新对话
└─ 否 → 话题是否已切换？
    ├─ 是 → 开新对话，旧结论写入 @summary.md
    └─ 否 → 是否超过 1 小时未互动？
        ├─ 是 → 开新对话（缓存可能已失效）
        └─ 否 → 继续当前对话

# 实用命令/context查看当前上下文 Token 明细/summarize压缩当前对话历史/compact精简上下文，保留关键信息

落地步骤：Rules 加载策略选择

策略	适用场景	配置方式
always	编码规范、输出格式要求（每轮都需）	Rules 文件头部加 `mode: always`
agentic	复杂项目背景、架构说明（AI 自主决定何时加载）	Rules 文件头部加 `mode: agentic`
manual	参考资料、文档索引（用户主动 @ 才加载）	Rules 文件头部加 `mode: manual`

原始文档

尝试省点 Token：谁知盘中 Token，粒粒皆辛苦

实战技巧

中心思想：模型"看到"的内容远比你输入的多。系统性地剖析 AI 模型实际处理的内容，揭示隐藏的巨大 Token 消耗。

固定内容放前面，动态内容放后面：最大化 Prompt Cache 命中率
Rules 放长期规则，不放百科全书：无关规则持续消耗 Token 并稀释注意力
AGENTS.md 放地图，不放小说：告诉模型"去哪找"，详细内容放 Reference 按需读取
命令行输出先过滤再给模型看：用 --short、jq、head/tail 或 chop/RTK 压缩
MCP 不要全量暴露：能用 CLI / typed client 转就转，避免搬运完整数据
输出也要省：因为输出会变成下一轮的输入，要求"只输出结论、依据和下一步"
该开新对话就别硬续：按需总结后开新对话，或回到分叉点重新编辑

落地步骤：AGENTS.md 地图化写法

AGENTS.md（正确示例）
# 项目导航地图## 核心架构
- 前端：Next.js 14 (App Router)，位于 apps/web/
- 后端：NestJS，位于 apps/api/
- 共享包：位于 packages/## 按功能找文件
| 功能 | 位置 |
|------|------|
| 用户认证 | apps/api/src/auth/ |
| 数据库 Schema | packages/db/schema/ |
| API 路由定义 | apps/api/src/routes/ |

## 详细文档（按需读取）
- 开发环境搭建：@docs/setup.md
- API 设计规范：@docs/api-guidelines.md
- 数据库迁移流程：@docs/migration.md

# 错误写法：把 setup.md 的全部内容直接贴进 AGENTS.md

落地步骤：命令行输出过滤

过滤后再给模型看
# 错误：直接把完整日志给 AInpm test → 5000 行输出，直接粘贴到对话# 正确：先过滤npm test 2>&1 | grep -E "(FAIL|PASS|Error|AssertionError)" | head -20
→ 只保留失败的测试和错误信息，约 20-50 行# JSON 数据用 jq 过滤curl api/users | jq'.data[] | {id, name, email}'→ 只保留需要的字段

原始文档

代码没写几行，额度全被"偷"光：如何把 Token 效率翻一倍

实战技巧

中心思想：通过精准的上下文控制和输出格式优化，在不降低工作质量的前提下，将 Token 使用效率提升一倍。

文件粒度控制：不要 @folder，精确到具体文件甚至函数
行号范围引用：大文件中只引用相关行范围
关闭自动读取：禁止 Agent 自动读取未引用的文件
diff 格式输出：要求 AI 只输出变更部分，不输出完整文件
禁用自动补全注释：JSDoc 和行内注释会大量消耗输出 Token

落地步骤：精确引用示例

精准 vs 粗放引用对比
# 粗放（浪费 Token）"请看看 src 目录下的代码，优化一下性能"→ AI 可能读取 20+ 个文件，消耗 50k+ Token# 精准（高效）"请分析 @src/services/user.js:45-78 的 getUserList 函数，
这个查询在数据量大时很慢。请只输出优化后的该函数代码，
使用 diff 格式。"→ AI 只读取 1 个文件的 33 行，消耗 3-5k Token

原始文档

CodeBuddy 没额度？国产模型省钱实践指南

数据评估

中心思想：通过标准化评估框架对比国产模型，筛选效果接近但成本更低的替代方案。

场景化选型：测试开发选 DeepSeek-V3.2/GLM-4.7，代码生成选 Kimi-K2.5，UI 自动化选 Kimi-K2.5
SubAgent 标准化：为各模型配置统一角色、输出格式的 Agent 文件，确保公平对比
五维评估模型：完整性(20%)、准确性(25%)、实用性(25%)、规范性(15%)、专业性(15%)
快速交付选 Kimi：15 分钟完成、零重试、100% 成功率
专业深度选 DeepSeek：功能质量最高、与 Claude 最相似

落地步骤：国产模型选型速查表

任务类型	推荐模型	预估成本	备注
代码补全/简单重构	DeepSeek-V3.2	极低	速度快，适合日常编码
复杂逻辑/架构设计	Kimi-K2.5 / GLM-4.7	中	推理能力强
UI/前端代码生成	Kimi-K2.5	中	对 Tailwind/React 支持好
代码 Review	DeepSeek-V3.2	低	能发现潜在问题
文档/注释生成	任意免费模型	免费	无需强模型

原始文档

3 架构进阶 —— 工程化让 Token 用得值

通过工程化架构和团队协作，实现大规模成本优化

Beggar · 赛博乞丐：组建丐帮开发团队，成本不到一折

架构进阶

中心思想：将一次完整开发拆成多个阶段，每个阶段由不同 Agent 角色负责，贵的只用在关键决策，便宜的用于跑测试和归档。

8 人 Agent 团队分工：Leader 管流程、Architect 出方案、Senior/Standard/Lite Coder 按难度分级、双 Reviewer 交叉验证、Tester 跑构建、Recorder 写归档
三种预设模式：Economic(~x0.03 省 97%)、Balanced(~x0.12 省 91%)、Quality(~x1.05 省 56%)
双 Reviewer 交叉验证：主审看代码质量，辅审看架构设计，跨厂商并行运行
升级兜底机制：审查不通过自动升级 Coder 级别重写
Leader 不写代码：只负责调度，所有代码修改必须走 Coder Agent

落地步骤：丐帮团队配置示例

.codebuddy/agents/beggar-team.json（团队配置）

{
  "mode": "balanced",
  "team": [
    {
      "name": "Leader",
      "model": "claude-sonnet-4",
      "role": "负责拆分任务、调度各 Agent、合并结果",
      "canWriteCode": false
    },
    {
      "name": "Architect",
      "model": "claude-sonnet-4",
      "role": "输出技术方案，不直接写实现代码"
    },
    {
      "name": "SeniorCoder",
      "model": "gpt-4o",
      "role": "处理复杂模块",
      "trigger": "difficulty > 3"
    },
    {
      "name": "StandardCoder",
      "model": "deepseek-v3",
      "role": "处理常规功能",
      "trigger": "difficulty 1-3"
    },
    {
      "name": "Reviewer-A",
      "model": "claude-haiku",
      "role": "检查代码质量、潜在bug"
    },
    {
      "name": "Reviewer-B",
      "model": "gemini-flash",
      "role": "检查架构一致性"
    },
    {
      "name": "Tester",
      "model": "deepseek-v3",
      "role": "运行构建和测试，报告结果"
    }
  ]
}
                        

三种模式选择指南

模式	成本倍率	适用场景
Economic	x0.03（省 97%）	原型开发、内部工具、探索性编码
Balanced	x0.12（省 91%）	日常业务功能开发（推荐）
Quality	x1.05（省 56%）	核心模块、支付/安全相关代码

原始文档

Agent Runtime：经济型模型也能扛长难任务

架构进阶

中心思想：通过 Runtime 架构让经济型模型也能稳定执行复杂生产级任务，将 Token 成本降低高达 90%。

Harness + Schema + Skill 三件套：确定性代码层 + 数据契约 + 自由发挥层
Agent 解耦：三件套与模型解耦，可随意更换模型或厂商，业务不被锁定
经济型模型 + Runtime = 29元：一次跑通；无 Runtime = 444元，平均 7-8 次才通过 1 次
高规格模型 + Runtime = 386元：比无 Runtime 省 60% Token（193万 vs 312万）
可自迭代：Skill 层接收外部信号并自我反思，Agent 越跑越聪明

落地步骤：Runtime 三件套架构

架构分层说明

┌─────────────────────────────────────────────┐
│  Skill 层（自由发挥）                          │
│  - 自然语言理解、决策、生成                    │
│  - 由 AI 模型驱动                             │
│  - 输入/输出受 Schema 约束                    │
├─────────────────────────────────────────────┤
│  Schema 层（数据契约）                         │
│  - JSON Schema / Zod / Pydantic               │
│  - 定义输入输出格式、字段类型、校验规则        │
│  - AI 的输出必须能通过 Schema 校验             │
├─────────────────────────────────────────────┤
│  Harness 层（确定性代码）                      │
│  - 流程控制、错误处理、重试逻辑                │
│  - 工具调用编排、结果聚合                      │
│  - 纯代码，不依赖 AI 能力                     │
└─────────────────────────────────────────────┘

# 核心原则：Harness 保证流程正确，Schema 保证数据正确，
#          Skill 负责需要智能决策的环节

落地步骤：Runtime 工作流示例

harness.py（确定性流程）
import json
from schema import CodeChangeSchema
from skill import generate_code_change

defrun_code_generation_task(task_description):
    # Step 1: 解析需求（确定性）
    parsed = parse_requirement(task_description)

    # Step 2: 调用 AI Skill（智能决策）
    raw_output = generate_code_change(parsed)

    # Step 3: Schema 校验（确定性）try:
        validated = CodeChangeSchema.model_validate_json(raw_output)
    except ValidationError as e:
        # 自动重试，将错误反馈给 AIreturn retry_with_feedback(e, parsed)

    # Step 4: 执行变更（确定性）
    apply_changes(validated.file_changes)

    # Step 5: 运行测试（确定性）
    test_result = run_tests()
    if not test_result.passed:
        return retry_with_feedback(test_result.errors, parsed)

    return"Success"

原始文档

一键生成 AI 工作流帮我省下 90%+ Token

架构进阶

中心思想：将确定性环节固化成脚本管道，只在真正需要思考的地方让 AI 介入，实现"脚本骨架 + AI 灵魂"。

三分法拆分：FIXED（固定环节脚本化）、AI（智能决策）、HUMAN（人工介入）
一条铁律："把 AI 删掉，这个流程还能不能正常跑完？"能则为 FIXED
效果对比：说明型 Skill 7522 Token/3分钟 → 脚本型 Skill 704 Token/30秒
Box-CLI 媒介：脚本执行到 AI 节点时通过 CLI 精准唤醒 Agent
行业共识：Anthropic 建议优先用确定性工作流，78% 企业级任务坚持确定性管道

落地步骤：三分法拆分实操

场景：自动生成代码变更并创建 PR

工作流拆分分析
# 原始做法（全 AI 驱动，7522 Token）"请读取需求文档，分析需要改哪些文件，
生成代码，创建 commit，推送到远程，创建 PR。"# 三分法拆分后（704 Token）# ===== FIXED 层（脚本化，0 Token）=====#!/bin/bash# pipeline.sh# 1. 解析参数
TASK_FILE=$1
BRANCH_NAME=$(generate_branch_name $TASK_FILE)

# 2. 创建分支（纯脚本）
git checkout -b $BRANCH_NAME

# 3. 读取需求（纯脚本）
TASK_CONTENT=$(cat $TASK_FILE)

# 4. 调用 AI 节点（唯一需要 AI 的环节）codebuddy skill generate-code \
  --input "$TASK_CONTENT"\
  --context @src/"$BRANCH_NAME".json \
  --output /tmp/changes.json

# 5. 应用变更（纯脚本）apply-changes /tmp/changes.json

# 6. 测试 + 提交（纯脚本）
npm test && git commit -am "feat: $BRANCH_NAME" && git push

# 7. 创建 PR（纯脚本）
gh pr create --title "$BRANCH_NAME" --body "$(cat $TASK_FILE)"

判断 FIXED vs AI 的 checklist

自检问题

□ 这个步骤的输出是否 100% 可预测？→ FIXED
□ 这个步骤是否只涉及文件/数据的搬运和格式转换？→ FIXED
□ 这个步骤是否需要理解业务语义并做出判断？→ AI
□ 这个步骤如果做错了，代价是否很高？→ HUMAN（人工确认）
□ 这个步骤是否涉及外部系统的不可控因素？→ HUMAN

原始文档

Mermaid 无限画布 × 上下文卸载

架构进阶

中心思想：通过上下文卸载 + Mermaid 无限画布实现短期记忆压缩，让 Agent 学会"一语胜千言"。

四级分层存储：Raw 原文 → JSONL Summary → MMD Node → Metadata，逐层变轻
上下文卸载：将暂时不需要的原始信息搬到外部文件系统，上下文只保留摘要/索引
Mermaid 无限画布：用 Flowchart 将离散工具调用组织成任务拓扑图，保留结构不丢失
实验效果：WideSearch 省 61% Token + 通过率提升 52%；SWEbench 省 33% + 完成率提升 10%
层次化注意力：Overview → 聚焦 → 下钻，Agent 像人类一样分层查看信息

落地步骤：四级分层存储实现

存储层次结构
# 原始数据（最完整，但最占 Token）memory/raw/tool-results-2026-06-10.jsonl→ 包含完整的工具输出，约 50k Token# 第一层压缩：JSONL Summarymemory/summaries/tool-results-summary.jsonl
{
  "tool": "search_code",
  "query": "auth middleware",
  "results_count": 5,
  "top_files": ["src/auth.js:45", "src/middleware/auth.js:12"],
  "key_finding": "JWT 校验在 auth.js 第 45 行，缺少过期时间验证"
}
→ 约 500 Token# 第二层压缩：Mermaid Nodememory/mermaid/task-state.mmd
flowchart TD
    A[搜索 auth 相关代码] --> B[发现 src/auth.js:45]
    B --> C[发现缺少过期验证]
    C --> D[待修复：添加 exp 检查]
→ 约 200 Token# 第三层压缩：纯 Metadatamemory/index/task-index.json
{
  "current_focus": "auth.js JWT exp validation",
  "pending": ["fix exp check", "add tests"],
  "completed": ["locate auth code"]
}
→ 约 100 Token

落地步骤：上下文卸载触发条件

何时卸载？
# 自动卸载规则（在 Agent 配置中设置）when context_token > 100000:
    unload oldest_raw_data to memory/raw/
    keep summary + mermaid + metadata in context

when task_stage == "completed":
    archive all_raw_data
    promote summary -> metadata

# 需要原始数据时按需加载"我需要查看刚才搜索的完整结果，
请从 memory/raw/tool-results-2026-06-10.jsonl 加载。"

原始文档

总核心要点总结

一句话心法

把 AI 当作按字数收费的顶级外包专家，需求给准、资料给对、废话不说。Token 成本不在于你说了多少，而在于配置侧精简系统税 + 对话侧保护缓存。

配置侧优化

Rules 按需加载、禁用无用工具、精炼 Memory 和 CODEBUDDY.md，将 System Prompt 从 25k 压到 12k，每轮省 1.3k 等价 Token

对话侧优化

一个 Session 干到底、不中途改配置、不频繁切模型。长对话缓存命中率高（×0.1），新窗口才是最贵的操作

提问策略

先低成本定位找出最相关的 3-5 个文件，确认范围后再读取指定片段。"你自己找"可能多花 20 万 Token

模型分级

简单任务用便宜/免费模型，复杂判断才用强模型。"分层使用 AI"而非默认上最强

上下文卫生

任务换了/跑偏了/超 1 小时 → 开新对话。阶段性结论写入文件，让 AI 按需读取

工程化固化

验证过的固定流程脚本化，AI 只在需要智能决策的环节介入。确定性工作流比 Agent 自主决策更稳更省

多 Agent 协作

按任务复杂度分级分派，双 Reviewer 交叉验证，升级兜底机制保证质量

记忆压缩

上下文卸载 + Mermaid 画布实现四级分层存储，让 Agent"少背负"而非"少知道"

省 Token 口诀

固定放前面，动态放后面。规则要短，知识要散。AGENTS.md 放地图，不放小说。命令别喷泉，日志先压缩。MCP 少暴露，结果再过滤。SubAgent 隔离探索，别把小事外包。输出别作文，废话会复利。

核心理念

1 认知升级 —— Token 不是省出来的，是用出来的

落地步骤：检查你的 Token 消耗构成

2 实战技巧 —— 立即可用的省 Token 大法

落地步骤：两步提问法实操

落地步骤 1：单一信源配置（软链接方案）

落地步骤 2：CodeGraph + ccc 检索分工

落地步骤 3：Headroom 压缩工具输出

落地步骤 4：Caveman 压缩 Agent 回复

落地步骤 1：锁死推理档位

落地步骤 2：PPT/Word 转 Markdown

落地步骤 3："想"和"干"分开

落地步骤：提问前自检清单

落地步骤：编写高效的 Rules 文件

落地步骤：技术方案预确认

落地步骤：会话管理决策树

落地步骤：Rules 加载策略选择

落地步骤：AGENTS.md 地图化写法

落地步骤：命令行输出过滤

落地步骤：精确引用示例

落地步骤：国产模型选型速查表

3 架构进阶 —— 工程化让 Token 用得值

落地步骤：丐帮团队配置示例

三种模式选择指南

落地步骤：Runtime 三件套架构

落地步骤：Runtime 工作流示例

落地步骤：三分法拆分实操

判断 FIXED vs AI 的 checklist

落地步骤：四级分层存储实现

落地步骤：上下文卸载触发条件

总 核心要点总结

一句话心法

配置侧优化

对话侧优化

提问策略

模型分级

上下文卫生

工程化固化

多 Agent 协作

记忆压缩

省 Token 口诀

总核心要点总结