烧额度的从来不是模型， 是没有边界的任务 和没有结构的对话。

AI 编程的成本不等于模型单价乘以调用次数。真实的成本曲线是 —— 每一次"模型走神 / 重复踩坑 / 推翻重来 / 改错回滚"，背后都是几万到几十万 token 的浪费。 这些浪费绝大部分不是模型的问题，是使用方式制造出来的。

真正烧额度的不是模型本身，
是没有边界的任务、没有结构的提示词、没有校验的压缩。
把它们变成有边界、有结构、有校验的工程动作 —— 额度自然就省下来了。

所有"省额度"的具体技巧，背后都是三条原则。先把原则吃透，技巧才用得对。

拆分让 AI 做对的事， 节制让 AI 在清醒状态下做事， 校准让 AI 做的事真的能用 —— 这是省额度的根，所有技巧都长在这根上。

"拆分"不是抽象口号，是有具体执行步骤的。下面以"给项目加一个登录注册功能"为例，演示一个真实可复用的拆分流程。

让 AI 列出：
- 涉及的数据库表和字段
- 涉及的接口和请求/响应结构
- 涉及的前端页面和组件
- 关键技术选型的可选项（让你选，不要它替你选）
- 已知的风险点和边界情况

基于需求文档，让 AI 写：
- 数据库迁移
- 注册 / 登录 / token 校验接口
- 中间件
- 单元测试（自验证用）

后端接口先用 mock 数据，让前端独立开发：
- 登录页 / 注册页
- 表单校验
- 状态管理
- 路由守卫

- 切换前端到真接口
- 跑通完整流程
- 回归验证原有功能（用户中心、订单页等可能被中间件影响的地方）

通用拆分公式：
大功能 → 需求梳理 → 后端 → 前端 mock → 真接口接入 → 回归
每个阶段独立 commit，每个阶段结束让 AI 输出"阶段交付摘要"。

很多人把 /compact 理解成"清屏续命" —— 上下文要满了，按一下就能再聊半天。这是个根本误解。 压缩不是延长聊天，而是给后续 AI 留一份可靠的工作交接文档。

下表所有数字均来自工具的官方文档或开源代码，每条事实在表尾附完整出处。 不要把一个工具的命令直接套到另一个工具上 —— 这是客户最常踩的坑。

同一份方法论，不同的工具按钮。
团队选定工具后，把"压缩动作"沉淀成内部 SOP，写进 onboarding 文档 ——
不要让每个新人自己摸索每个工具的默认行为，否则同样的坑会被踩 N 遍。

压缩本身有成本（要消耗 token 生成摘要、要承担丢失关键信息的风险），所以 不是越早越好，也不是拖到爆才压。掌握时机，比掌握命令更重要。

不要等上下文快爆才压缩 —— 要在阶段性节点上主动压缩。
前者是"灭火"，后者是"工程动作"。

什么时候压、压完之后怎么校验，这两件事比"按哪个命令"重要。下面把整个压缩流程拆成 3 步，每一步都是必做项。

📝 Step 01 提示词模板

复制压缩前先列一下当前任务状态：
1. 当前任务目标
2. 用户明确的约束 / 禁止项
3. 已读的关键文件（带路径）
4. 已改的关键文件（带路径 + 改动点）
5. 已排除的方案（避免重复踩）
6. 当前未解决的问题
7. 下一步计划
8. 必须回归验证的功能

先列，不要动代码，不要压缩。

🛠️ Step 02 两大工具执行方式

🔍 Step 03 校验模板

复制基于刚才的压缩摘要，请复述以下内容：
1. 当前任务目标
2. 已完成的工作
3. 已修改的文件
4. 禁止修改的内容
5. 当前未解决的问题
6. 下一步计划
7. 必须回归验证的功能

先复述，不要修改代码。

判断：复述准确 → 继续干活；复述有偏差 → 立刻纠正再继续。 摘要里漏掉的硬约束只有这一步能发现，一旦放过、直接继续，可能要花几十万 token 修被 AI 误改的代码。

整理 · 执行 · 校验 —— 缺任何一步，压缩就从"工程动作"退化为"赌运气"。
省 token 的方式不是少压，而是每次都压对。

真实工作中场景不同，需要不同的模板。把模板沉淀成 3 个标准版本 —— 任务交接版 / Bug 修复版 / 代码生成版。日常 95% 的压缩场景都能套上。

复制/compact 请生成一份高质量的任务交接摘要，后续模型要能无缝继续当前工作。

请严格按以下结构输出：

【当前任务目标】
说明当前要解决什么问题、最终交付物是什么。

【用户明确需求】
列出用户已明确提出的需求，不要遗漏。

【用户明确约束与禁止项】
列出所有不能修改、不能破坏、不能重构、不能影响的内容。

【当前项目背景】
说明当前项目技术栈、相关模块、当前任务所在业务范围。

【已读关键文件】
列出已经查看过的文件路径,并说明每个文件的作用。

【已改关键文件】
列出已经修改过的文件路径,并说明每个文件改了什么。

【当前采用的技术方案】
说明当前决定采用什么实现方式、以及为什么采用这个方案。

【已经排除的错误方向】
说明哪些方案、原因、猜测已经验证过不可行,避免后续重复踩坑。

【当前未解决的问题】
说明目前还剩哪些问题、Bug、报错、风险点。

【下一步执行计划】
按优先级列出后续应该继续做什么。

【必须回归验证的功能】
列出修改完成后必须验证的功能,避免修 A 坏 B。

要求:
1. 文件路径必须完整
2. 用户约束必须完整
3. 不要保留无关闲聊
4. 不要遗漏已确认的结论
5. 不要把不确定内容写成事实
6. 不要重复已经排除的方案
7. 后续继续任务时,必须严格遵守这份摘要

复制/compact 请生成一份 Bug 修复任务的上下文交接摘要,后续模型要能继续定位和修复问题。

请严格按以下结构输出:

【问题现象】
描述用户看到的 Bug 是什么。

【复现路径】
说明如何复现这个问题。

【影响范围】
说明这个 Bug 影响哪些功能,不影响哪些功能。

【相关文件】
列出已经读取或分析过的关键文件路径,并说明每个文件的作用。

【已排查内容】
说明已经检查过哪些逻辑、接口、组件、状态、数据流。

【已排除原因】
说明哪些方向已经确认不是根因,后续不要重复尝试。

【当前判断】
说明目前最可能的根因是什么,如果不确定,要明确标注"不确定"。

【已修改内容】
列出已经修改过的文件和具体修改点。

【禁止修改内容】
列出用户明确要求不能改的文件、模块、逻辑、接口字段及历史兼容逻辑。

【必须保持不变的功能】
列出所有不能被影响的功能。

【下一步计划】
说明后续应该做什么、验证什么、排查什么。

要求:
1. 优先最小改动
2. 不要扩大修改范围
3. 不要重复尝试已排除方案
4. 修复后必须做回归验证
5. 特别注意不要出现"修 A 坏 B、修 B 坏 C"的问题

复制/compact 请生成一份代码开发任务的上下文交接摘要,后续模型要能基于这份摘要继续开发。

请严格按以下结构输出:

【项目背景】
说明当前项目、技术栈、业务模块和开发目标。

【当前需求】
列出本次需要实现的功能点。

【需求边界】
说明哪些属于本次范围,哪些不属于本次范围。

【关键约束】
列出所有不能改、不能破坏、不能重构的地方。

【已读文件】
列出已经查看过的文件路径,并说明每个文件的作用。

【已改文件】
列出已经修改过的文件路径,并说明具体改动。

【核心实现方案】
说明当前采用的实现方式,包括组件设计、状态管理、接口调用、数据处理等。

【兼容性要求】
说明哪些旧功能、旧接口、旧数据结构必须保持兼容。

【风险点】
说明当前改动可能影响哪些地方。

【未完成内容】
列出还没有完成的部分。

【下一步计划】
给出后续开发清单,按优先级排序。

【回归验证清单】
列出开发完成后必须验证的页面、功能和边界场景。

要求:
1. 不要遗漏文件路径
2. 不要遗漏用户限制
3. 不要擅自扩大需求范围
4. 不要反复重构
5. 后续开发必须围绕当前方案继续

3 个模板不是 3 种"格式"，是 3 种工程动作：
任务交接版 → 保证下一个会话能"无缝接班"；
Bug 修复版 → 保证已排除方向不再重复踩；
代码生成版 → 保证已生成内容不被反复重写。

压缩管的是上下文，Git 管的是代码。两者必须同时到位 —— 否则 AI 错了就只能"让 AI 自己改回去"，而这正是烧额度的重灾区。

git status
git diff
git add .
git commit -m "checkpoint: before fixing order pagination"
git commit -m "checkpoint: before refactoring user profile"

git switch -c feature/ai-auth-module

# 阶段性 checkpoint commit
git commit -m "checkpoint: backend api done"
git commit -m "checkpoint: frontend mock done"

# 验证完毕后 squash merge
git switch main
git merge --squash feature/ai-auth-module
git commit -m "feat(auth): add login/register module"

cd ~/projects/my-app

# 给 AI 开个并行 worktree
git worktree add ../my-app-ai feature/ai-refactor

# 主目录正常工作 / ../my-app-ai 让 AI 全权负责
# AI 任务完成后清理
git worktree remove ../my-app-ai

AI 编程的安全感不来自"AI 不犯错"，
来自"AI 犯错后能秒级回滚"。
省 token 的第一步，是让"撤销"变成 1 秒的操作，不是 10 万 token 的对话。

方法论再好，没人执行也是白搭。把以下 10 条写进团队 onboarding 文档 / Code Review 检查清单，让"省额度"从个人习惯变成团队 SOP。

• 禁止一句话让 AI 做整个功能 —— 必须先做需求拆分
• 大功能必须先用阶段 0 输出 需求文档，由人审阅修正后再动手
• 每阶段独立 commit，前缀用 checkpoint:，AI 错了能 1 秒回滚
• 长任务一律开独立分支，不要在 main / dev 直接让 AI 跑
• 禁止裸用 /compact，必须带 Section 08 的结构化模板
• 压缩前必须先让 AI 复述当前状态，错了立刻纠正
• 压缩后必须先让 AI 复述摘要内容，对了再继续
• 修 Bug 时必须记录已排除方向，避免重复踩坑
• 任何代码改动完成后必须做回归验证（本次功能 + 可能被影响的旧功能）
• 关键约束写进项目级配置文件（CLAUDE.md / AGENTS.md），不要只写在 chat 里