有一天，我盯着屏幕上那个刺眼的红色提示——"Token limit exceeded"，心里只有一个念头：完了，明天又要从头来过了。

        事情是这样的。我之前在重构一个参数标定的项目，几千行代码，"应该很快"。我自信满满地把整个代码库丢给 Claude Code："帮我把...进行实现。"

        第一轮，Claude 说"好的，我明白了"，分析了 8K tokens。第二轮，它改错了文件，我纠正它，累计 12K。第三轮，它开始给我讲解"什么是参数标定"以及"为什么 XXX方法 更好"——大哥，我是要你改代码，不是写论文啊！——这一轮飙到 18K。

       第四轮，红灯亮起。对话中断，上下文清零。

        我算了笔账：38K tokens 花出去，相当于几十块钱，产出为零。更重要的是，我明天得重新建立上下文，重新解释需求，重新纠正它的"误解"。那个"很快"的任务，变成了一个无底洞。

        那天晚上我想：这不对。不是 Claude 笨，是我的用法有问题。还得调用Skill。

第一个坑：我以为喂越多，它越聪明

        说实话，我一开始真的以为，给 AI 越多上下文，它就越聪明。所以我把整个代码库、需求文档、甚至 Slack 记录都贴进去了。

         结果呢？它像是被信息淹没的学生，反而抓不住重点。有一次我让它优化工具函数，它却去改了配置文件——就因为我提到过一次。

         更惨的是账单。单次请求动辄 15K+ tokens，一个月够吃好几顿火锅。

顿悟时刻：AI 不需要知道整个世界，它只需要知道"现在该干什么"。

第二个坑：AI 的"失忆症"和我的"复读机"模式

        你有没有遇到过？聊了几轮后，AI 突然开始给你上课，而不是改代码。

        我一开始当复读机："请直接修改"、"不要解释"、"执行即可"。累，且低效。

        后来懂了——上下文太长，AI 开始"迷失"，分不清指令和讨论。于是它选"安全"做法：解释，而不是行动。

顿悟时刻：问题不在 AI，在我没有给它一个清晰的"任务边界"。

第三个坑：断点噩梦——明天从头再来

         最绝望的是断点。

        一个简单的任务，我想当天搞定。结果 Token 耗尽，对话中断，上下文清零。第二天，我要重新描述背景、解释目标、提供示例...我称之为"上下文建立税"，每次重启都要交一遍。

顿悟时刻：我需要一个"存档点"，让任务可以中断、恢复、接力执行。

我的笨办法进化史

意识到问题后，我开始试验各种"土办法"。

阶段一：手动删减（累且蠢）

我尝试手动删除历史消息里的"废话"。但什么叫废话？昨天的讨论今天还相关吗？我删着删着，就把关键信息也删了，AI 开始问"你昨天说的那个约束是什么来着"。

这条路走不通。

阶段二：给每个任务写"小抄"

于是我换了个思路。每次开新对话前，我手动写一张"小抄"：

• 这次要干什么
• 怎么算完成
• 有什么红线不能碰
• 需要看哪些文件

效果好了很多！AI 终于有了焦点。但小抄的格式不统一，有时候漏写关键信息，有时候写太多又超 Token。

阶段三：三件套成型（终于对了）

经过几天的折腾，我现在用这套方法，把那个 38K tokens 的血案降到了 8K，而且再也不会"跑偏"了。

第一招：TCP——我的标准化"小抄"

我不再随便写小抄，而是用固定格式：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(linetask_goal: "一句话说清楚要干什么"acceptance_criteria:   - "怎么算完成，一条条列出来"hard_constraints:  - "什么绝对不能碰"dependencies_in:  - "只需要看这些文件的关键信息"

这招叫 TCP（Task Context Pack，任务域上下文包）。核心就一点：只给 AI 它需要知道的，不多不少。我强制自己把上下文压缩到 600-1200 tokens，就像给 AI 戴上了聚焦镜。

第二招：Compression Gate——学会"说重点"

但有时候我必须给 AI 一些背景信息，比如需求文档。这时候我先用"压缩闸门"处理一遍：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line### Key Facts（≤7条）- 必须带数字：响应时间≤200ms，并发≥5000 QPS- 版本号：React 18.x，MySQL 8.0
### Dependencies（≤5条）- 只列对本任务有影响的依赖
### Risks（≤3条）- 可能导致返工的风险

硬规则：每一条关键事实必须带数字、阈值、单位或版本号。不说"要快"，说"P99 ≤200ms"；不说"很多人用"，说"5万 DAU"。

这样压缩后，2000 字的需求文档变成 15 条结构化信息，AI 再也不会误解。

第三招：RGS——终于能"存档"了

最关键的突破是 RGS（Rolling Global Summary，滚动摘要）。这是一个我维护的全局状态文件，长这样：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line## 模块处理状态| 模块ID | 状态 | 关键发现 ||--------|------|----------|| auth | 完成 | JWT 方案通过测试 || payment | 进行中 | 回调重构中 |
## 累积风险- 数据库迁移回滚方案待确认

严格限制在 400-800 tokens。每次任务结束，我更新这个"存档点"。下次开新对话，我只需要给 AI 这个摘要，它就能接上进度，不需要重新建立上下文。

第四招：Budget First——花钱要有计划

最后，我开始给每个任务分配 Token 预算：

• 25% 用于理解需求
• 55% 用于实际干活
• 20% 用于输出结果

如果"干活"部分快超预算了，我就触发"收敛模式"——让 AI 跳过中间推导，直接给结论和关键证据。这样至少保证任务能完成，不会"烂尾"。

整个流程就是：

我现在的工作流程（送你直接用）

说了这么多，你可能想问：具体怎么用？

这是我现在的标准操作流程，你可以直接拿去改着用：

Step 0: 创建"存档点"新建一个 rolling-global-summary.md，写入项目目标和当前阶段。

Step 1: 写"小抄"（TCP）每次开任务前，按这个格式写：

ounter(lineounter(lineounter(lineounter(linetask_goal: "一句话目标"acceptance_criteria: ["完成标准1", "完成标准2"]hard_constraints: ["红线1", "红线2"]dependencies_in: ["相关文件的关键事实≤7条"]

Step 2: 自我检查（Scope Lock）问自己：这个目标超范围了吗？剥离无关需求。

Step 3: 信息分级给 AI 的信息分四级：

• L0（指令和标准）：全保留
• L1（背景要点）：压缩到 1-2 句
• L2（参考资料）：只留索引
• L3（废话）：删掉

Step 4: 固定输出格式我强迫 AI（和自己）按这个结构输出：

ounter(lineounter(lineounter(lineounter(lineounter(lineresult: [核心结论]assumptions: [我假设了什么]evidence: [关键证据，带数字]local_summary_update: [要更新到存档点的信息]open_questions: [有什么阻塞问题]

Step 5: 更新"存档点"任务结束，把 local_summary_update 合并到 RGS，删掉旧信息保持精简。

这些都是我血和泪的教训

最后，送你一张"失败模式速查表"——都是我踩过的坑：

讲在最后

说实话，Token 管理这件事，本质上不是"克扣"，而是"尊重"——尊重 AI 的注意力，也尊重自己的钱包。

我现在每次开复杂任务前，都会花 5 分钟初始化 RGS 和 TCP 模板。这 5 分钟的前置投入，往往能省下几倍的时间和 Token。更重要的是，我再也不用经历那个晚上的绝望了。

如果你也用 Claude Code、Cursor 或者 Windsurf，不妨试试这套方法。有问题随时找我聊——相信我，我踩过的坑，比你想象的要多。

下次，我打算写写多 Skill 协作的血泪史。那又是另一个故事了。