AI 编程省 Token 实战：从 Spec、上下文工程到模型分层的降本策略

上一篇《省 Token 实战手册：从提示词到架构，开发中真正有效的降本策略》，更多是站在 API 调用方的角度，讨论提示词、上下文、缓存、模型选择和架构设计如何影响成本。

但换到 AI 编程场景，问题会更具体，也更容易被忽略。我们每天用 Cursor、Claude Code、Codex 这类工具写代码时，真正烧掉 Token 的往往不是某一次 API 请求，而是一整套开发流程。

一个中等复杂度的功能模块，通常会经历需求澄清、方案设计、代码生成、测试修复、Review、再重构。如果流程不受控，模型就会反复读文件、反复解释上下文、反复修改同一批代码，成本自然会被放大。

所以这篇文章不讨论"提示词少写几个字"这种细枝末节，而是讨论一个更工程化的问题：

在 AI 编程过程中，如何让模型只在需要的时候，读取必要上下文，使用合适能力，消耗合适级别的 Token。

文章会围绕六类策略展开：

Spec 先行：减少需求反复带来的返工
记忆与 Skills：减少跨会话的重复解释
上下文工程：控制模型读取代码的范围
模型分层：让不同任务匹配不同模型
缓存策略：按模型机制设计稳定前缀
Subagent 与工作流：隔离上下文，避免主线程膨胀

一、为什么 AI 编程场景更容易烧 Token

普通问答类应用里，一次请求通常比较简单：系统 / 工具上下文、用户问题、少量补充资料，再加上模型回答。

AI 编程不一样。它通常会引入更多额外消耗：

消耗来源	普通 LLM 应用	AI 编程场景
系统 / 工具上下文	几百到几千 Token	系统指令、工具说明、项目规则、执行策略可能达到几千到几万 Token
上下文文件	通常较少	一次可能读取多个源文件、测试文件、配置文件
工具调用结果	少量检索结果	大量检索结果、文件内容、编辑记录和测试日志会进入上下文
多轮迭代	通常轮次较少	复杂任务可能持续多轮甚至几十轮
推理 Token	按需开启	复杂调试、架构设计、代码审查中经常被启用

⚠️ 注意：成本失控通常不是因为模型单价 一个完整的 RBAC 模块开发，如果没有流程控制，输入侧 Token 很容易达到几十万甚至上百万级别。成本真正失控的原因，通常不是模型单价，而是上下文反复膨胀、文件反复读取、需求反复修正。

开发场景的矛盾很直接：

代码上下文本身就大；
模型为了稳妥，往往会倾向于多读一点；
ReAct 这类"思考 → 调工具 → 观察结果 → 继续执行"的循环，会把前面的工具结果带到后续轮次；
Thinking、Subagent、Review、TDD 都会继续叠加消耗；
一次错误判断，后面可能要用好几轮来修正。

所以 AI 编程降本的核心不是"让模型少干活"，而是：

让模型在合适的阶段，读取合适的上下文，使用合适等级的模型。

二、Spec 先行：用前置设计减少返工 Token

很多 AI 编程成本，并不是花在第一次生成代码上，而是花在"生成错了以后反复改"上。

没有 Spec 时，模型只能根据模糊需求自行补全假设。一旦这些假设和真实需求不一致，后面就会连锁返工：重新读代码、重新改接口、重新调整数据模型、重新跑测试。

1. 直接开发的典型问题

❌ 优化前：直接进入实现

makefile 复制代码

User: 帮我做一个 RBAC 权限系统，NestJS + Prisma。
AI: 生成 user / role / permission 模块。
User: 权限粒度不是接口级，我还需要按钮级权限。
AI: 重新调整权限模型、Guard 和前端权限判断。
User: super_admin 需要绕过所有权限检查。
AI: 再次修改 Guard、Seed、权限判断逻辑。
User: refreshToken 需要落库，并且支持踢下线。
AI: 继续修改 Prisma Schema、AuthService、Token 刷新逻辑。

这里最贵的不是某一次输出，而是每次需求变化都会触发"重新理解现有代码 + 重新修改多个文件"。

2. Spec 先行的更稳流程

✅ 优化后：先收敛边界，再进入实现

diff 复制代码

第一步：需求澄清
- 权限粒度：接口 / 页面 / 按钮
- 是否需要 super_admin 绕过
- refreshToken 是否落库
- 是否需要审计日志
- 是否包含组织、部门、租户维度
- 本次明确不做哪些能力

第二步：输出 SPEC.md
- 数据模型
- 模块边界
- API 范围
- 权限命名规则
- 前端接入方式
- 非目标范围

第三步：输出 PLAN.md
- 按阶段拆分任务
- 每一步有交付物
- 每一步有验收标准
- 每一步尽量只涉及少量文件

第四步：按 Phase 执行
- 一次只执行一个小阶段
- 执行后立即测试
- 通过后再进入下一阶段

Spec 的价值不在于"多写一份文档"，而是提前固定关键决策，减少后续返工。

📌 判断标准：Spec 不是所有任务都值得写。

经验上，如果涉及 3 个以上文件，或者预期会反复沟通 2 轮以上，先写 Spec 通常更划算。
还在摸索方案时，先做一个最小可行实现，往往比先写完整 Spec 更快。
小修改，比如改文案、加字段、调样式，直接动手即可，没必要走完整流程。

3. Spec 也要控制粒度

Spec 不是越长越好。写得太细，反而会变成新的上下文负担。

更实用的结构是：

diff 复制代码

SPEC.md：固定决策
- 范围边界
- 数据模型
- 权限规则
- 接口约定
- 前端接入方式

PLAN.md：执行拆分
- Phase 1：数据库与基础模型
- Phase 2：Auth 与 Token
- Phase 3：Users / Roles / Permissions
- Phase 4：前端权限接入
- Phase 5：联调与验收

对 AI 编程来说，一份好 Plan 至少要满足两个条件：

每一步都能独立完成；
每一步只需要读取有限数量的文件。

markdown 复制代码

❌ 粗粒度任务：
实现用户模块。

✅ 细粒度任务：
1. 设计 User 表的 Prisma Schema。
2. 实现 UsersService.create。
3. 实现 UsersController POST /users。
4. 为 create user 增加单元测试。

拆细任务不是为了把流程弄复杂，而是为了让每次模型调用都只加载真正需要的上下文。

三、记忆与 Skills：把重复解释变成可复用资产

如果说 Spec 解决的是"单个任务不要反复返工"，那么记忆与 Skills 解决的就是"同类任务不要反复解释"。

很多开发者每次开新会话都会重新说明：

项目用 pnpm，不用 npm；
后端使用 NestJS + Prisma；
DTO 使用 class-validator；
错误处理走统一异常过滤器；
文件名使用 kebab-case；
测试使用 Vitest；
不要擅自引入新库。

这些规则单次看起来不长，但每天重复多次，就会变成稳定的 Token 浪费。

1. 三类信息应该分层存放

1. 项目级常驻规则

载体：工具对应的规则文件（选一个就够）
适合存放：技术栈、目录结构、命名约定、测试方式
注意事项：Cursor 用 .cursor/rules/，Claude Code 用 CLAUDE.md，跨工具可以尝试 AGENTS.md，但支持度不完全一致。不要重复维护多份

2. 流程级能力

载体：工具内置的能力扩展机制
适合存放：Brainstorm、写 Plan、Code Review、TDD、收尾流程
注意事项：例如 Anthropic Skills、Cursor Rules + 工作流脚本、自定义 Subagent。没有内置机制时，也可以用 docs/skills/*.md 配合提示词按需引用。关键是按需触发，不要塞进常驻上下文

3. 个人与长期偏好

载体：具备记忆能力的 Agent / 用户级配置
适合存放：个人输出偏好、常用决策、重复任务模式
注意事项：例如 ChatGPT Memory、Claude Projects、Hermes 类系统。不是所有工具都有真正的长期记忆；没有时，可以退化为项目内的 PREFERENCES.md

2. 常驻规则要短，Skills 要按需加载

常见错误是把所有规范都写进 AGENTS.md 或 CLAUDE.md，导致每次会话都自动携带大量低频信息。

更合理的方式是：根据你使用的工具，选择对应的规则文件即可。Claude Code 可以用 CLAUDE.md，Cursor 可以用 .cursor/rules/*.mdc，跨工具场景再考虑 AGENTS.md。

diff 复制代码

规则文件：只放高频规则
- 技术栈
- 包管理器
- 命名规范
- 测试命令
- 禁止事项

Skills / 工作流脚本 / 自定义 Subagent：放流程和专项知识
- 如何写后端 CRUD
- 如何做 TDD
- 如何做安全 Review
- 如何做前端 UI 检查
- 如何写发布说明

判断方法也很简单：

每次都会用到的，放常驻规则；偶尔才会用到的，做成 Skill 或文档按需加载。

3. 长期记忆与经验沉淀的价值

具备记忆能力的 Agent，例如 Hermes 类系统、ChatGPT Memory、Claude Projects，真正有价值的地方不是"记住你说过什么"，而是沉淀"同类任务怎么做更有效"。

例如第一次做"批量迁移 import 路径"时，Agent 可能会经历搜索、试错、修复、验证。完成后，如果能把有效流程沉淀成 Skill：

markdown 复制代码

触发条件：
- 用户要求批量迁移 import 路径
- 涉及多个 TypeScript 文件

执行步骤：
1. 先用当前环境支持的检索工具找到旧路径引用。
2. 只读取命中的文件。
3. 分批修改 import。
4. 运行 typecheck。
5. 如果失败，只修复报错文件。

下一次再遇到同类任务，就不需要重新探索流程。这种节省不是一次性的，而是会随着重复任务累积。

四、上下文工程：让模型只看必要代码

AI 编程里，最直接的成本控制点就是文件读取范围。

模型并不是看得越多越好。无关文件一旦进入上下文，不只增加成本，也可能干扰判断。

1. 三种上下文加载方式

方式	成本	适用场景	风险
全量加载	高	首次理解项目结构、做整体迁移评估	容易把无关信息带入上下文
精确指定文件	中	已知需要修改哪些文件	如果漏文件，可能造成实现不完整
检索后读取	低	定位引用、迁移 API、排查 bug	依赖检索关键词是否准确

2. 用检索工具缩小读取范围

❌ 低效方式：让模型自行浏览目录

复制代码

帮我把所有 oldApiClient 迁移到 newApiClient。

模型可能会先读取项目配置、目录结构、多个入口文件，再逐步寻找引用。

✅ 更好的方式：先检索，再读取命中文件

复制代码

先用当前环境支持的检索工具
定位 oldApiClient 的所有引用，只读取命中的文件。
完成迁移后，再运行 typecheck。

这条思路可以推广到多数代码任务：描述清楚要找什么，让模型自己选择当前环境可用的工具。可以是 Agent 自带的 Grep，也可以是 grep、git grep、IDE 搜索、ast-grep 或 LSP。

bash 复制代码

查引用：functionName 在哪些文件被调用?
查路由：apps/api/src 下注册了哪些 HTTP 路由?
查配置：哪些文件读取了 DATABASE_URL / REDIS_URL / JWT_SECRET?
查类型：User 类型/接口在哪里声明?

能先检索缩小范围，就不要让模型一上来全量浏览目录。

3. 多文件任务要分批处理

一次性读取 20 个文件，看似效率高，实际风险很大：

上下文成本高；
修改范围过大；
出错后难以定位；
容易出现不一致修改。

更稳妥的方式是按模块分批：

复制代码

第一批：schema + types
第二批：service + repository
第三批：controller + dto
第四批：tests
第五批：前端调用与页面

每一批完成后先跑局部验证，再进入下一批。这样即使出错，影响也会被限制在当前批次，不至于把整个任务拖乱。

4. 长会话要主动压缩

一个会话经历了大量工具调用、测试日志和文件读取之后，继续往下做会越来越贵，也越来越容易跑偏。

适合压缩的信号包括：

已经完成一个 Phase；
当前上下文包含大量历史日志；
模型开始重复之前的错误；
每次响应明显变慢；
接下来要进入新的模块。

可以让模型输出一份交接摘要：

markdown 复制代码

请总结当前任务状态，要求包括：
1. 已完成内容；
2. 已修改文件；
3. 关键设计决策；
4. 当前验证结果；
5. 剩余任务；
6. 下一步只需要读取哪些文件。

然后用这份摘要开启新会话或新阶段。

五、缓存策略：不同模型要分开处理

很多文章会把"前缀缓存"讲得很简单：把稳定内容放前面，就能命中缓存，输入成本下降 90%。

这个方向没错，但说得太粗。不同模型、不同供应商、不同接入层的缓存机制并不一样。AI 编程场景里，如果把所有模型都按同一套规则处理，很容易误判成本。

1. 缓存策略的核心原则

不管用哪家模型，想提高缓存命中率，先看三件事：

稳定内容尽量放在前面；
高频变化内容放在后面；
同类任务尽量连续执行，不要频繁切换上下文。

一个更适合开发任务的"可控上下文"顺序是：

markdown 复制代码

1. 稳定系统 / 工具上下文
2. 项目级规则（工具规则文件的核心部分）
3. 当前任务 Spec / Plan
4. 本轮需要读取的少量文件
5. 当前用户指令
6. 动态工具结果

这里说的是可控上下文的组织方式。真实 Agent 框架里，工具调用结果的位置通常由框架决定，但我们仍然可以控制哪些内容稳定、哪些内容动态、哪些内容不要提前塞进上下文。不建议把用户临时输入、错误日志、命令输出放在稳定前缀之前，否则缓存命中率会下降。

2. 不同模型缓存时间不同

下面这张表可以作为判断参考。具体价格和策略可能会变化，工程上还是要以最新官方文档和实际账单为准。

OpenAI GPT 系列

常见机制：多数新模型支持自动 Prompt Caching；部分新模型支持更长保留策略
时间特征：常见内存缓存通常在数分钟不活跃后逐步失效，部分模型或策略可延长到更久
开发建议：适合同类请求连续执行；稳定前缀保持一致；长间隔任务不要假设一定命中

Claude / Anthropic

常见机制：需要显式设置 cache breakpoint / cache_control；缓存读写价格不同
时间特征：显式开启缓存后，短 TTL 常见为 5 分钟；可选 1 小时缓存，但写入成本更高
开发建议：短任务用 5 分钟 TTL；Subagent 或长工具调用超过 5 分钟时，再考虑 1 小时缓存或重新预热

Gemini

常见机制：支持显式 Context Caching，也有平台侧缓存能力
时间特征：显式缓存常见默认 TTL 为 1 小时，并可设置更长或更短
开发建议：适合长文档、代码库片段、视频/文件等大上下文复用；需要管理 cached content 生命周期

中转站 / 聚合平台

常见机制：取决于其是否透传原厂缓存能力，以及是否做了二次封装
时间特征：不同平台差异很大
开发建议：必须看账单中的 cached input / cache read 指标，不要只看模型名判断缓存效果

⚠️ 这里有两个容易踩的坑。

Claude 的缓存不是"放在前面就自动生效"。 直接调 API 时，需要在请求里显式设置 cache_control breakpoint；Claude Code、Cursor 这类 IDE Agent 是否自动管理缓存，取决于工具版本和接入方式。
不少中转站 / 聚合平台并不透传原厂缓存。 有些"低价"来自平台自己的定价策略，不一定是真命中缓存。判断时要看返回或账单里是否有 cached_input_tokens / cache_read_input_tokens 一类字段。如果没有，就不要按缓存命中来估算成本。

3. 缓存策略的工程检查清单

在 AI 编程中，缓存优化不应该只停留在"把稳定内容放前面"。更完整的检查清单是：

当前模型是否支持缓存？
是自动缓存，还是需要显式声明？
默认 TTL 是几分钟还是一小时？
是否有更长 TTL，写入成本是多少？
cache read 是否按 0.1x 或其他比例计费？
Subagent / 测试 / 构建是否会超过缓存 TTL？
中转站是否透传缓存指标？
账单里能否看到 cached input 或 cache read？
稳定前缀是否被动态日志打断？

如果这些问题没有确认，就不要在成本估算中直接写"缓存命中多少"了。

六、模型分层：不同开发任务使用不同模型

模型分层是 AI 编程里最直接的降本手段之一。

不是所有开发任务都需要最强模型。真正需要强模型的，通常是决策类任务，而不是机械执行类任务。

1. 开发任务复杂度分层

L1：机械操作

例子：重命名、格式化、整理 import、生成提交信息
推荐模型：小模型 / 快模型

L2：模式套用

例子：按现有模板写 CRUD、补 DTO、补测试样板
推荐模型：小模型或中模型

L3：业务实现

例子：实现接口、写复杂查询、接入权限判断
推荐模型：中模型

L4：架构与计划

例子：需求澄清、Spec、Plan、技术方案比较
推荐模型：强模型

L5：复杂调试与审查

例子：疑难 bug、安全审计、性能瓶颈、跨模块重构
推荐模型：强模型 + 必要时开启推理

2. 一套更实用的模型路由

css 复制代码

需求澄清 / Spec       → 强模型
Plan 拆解             → 中模型或强模型
普通代码实现          → 中模型
模板化代码 / 批量修改  → 小模型
测试样板生成          → 小模型或中模型
复杂 bug 定位         → 强模型
最终 Code Review      → 强模型
提交信息 / README 小改 → 小模型

可以把它简单理解为：

贵模型负责判断，便宜模型负责执行。

💡 现实约束：大多数 IDE Agent 并不支持逐任务自动切换模型。

Cursor、Claude Code 等工具，通常只能按会话或项目选择模型。更可执行的做法是：

按会话选择模型：Plan / Review 类会话用强模型，日常实现会话用中模型。
简单任务关闭推理：机械修改默认不启用 thinking / extended reasoning。
需要精细路由时再建设工作流：比如自研 Agent、LangGraph、Cline、OpenRouter 路由策略；如果工具支持，也可以通过自定义 Subagent 为不同任务指定模型。

3. 本地模型适合低风险简单任务

对于提交信息生成、简单重命名、格式整理、注释补全这类低风险任务，如果本地模型质量足够，也可以交给本地模型处理。但本地模型不一定总是更省：还要考虑硬件成本、响应速度、上下文长度和结果质量。如果修出来的代码还要反复返工，反而不划算。

4. Thinking / Extended Reasoning 要按需开启

推理模式适合复杂问题，但不适合所有问题。

适合开启的场景：

多模块 bug，原因不明确；
架构方案需要权衡；
安全边界需要推演；
性能问题涉及多层调用链；
需要审查设计是否存在隐藏风险。

不适合开启的场景：

改变量名；
补简单 DTO；
整理 import；
写提交信息；
按现有模式补一份类似代码。

推理 Token 通常不会直接出现在最终回答里，但会进入计费。简单任务默认开启推理，往往只会增加成本和延迟。

七、Subagent 与工作流：隔离上下文，而不是盲目并行

Subagent 的主要价值，不是"让任务天然更省 Token"，而是避免主线程被污染。

这一点要说清楚：Subagent 往往会增加调用次数，甚至增加总 Token。但它可以把搜索、文件读取、测试日志、局部试错隔离在子任务里，避免主线程越拖越长。

1. 没有 Subagent 时的问题

markdown 复制代码

主线程：实现 PermissionsGuard

1. 搜索所有 Guard
2. 读取多个 Guard 文件
3. 读取 AuthService
4. 读取 JWT Strategy
5. 读取权限装饰器
6. 实现 PermissionsGuard
7. 跑测试
8. 错误日志进入上下文
9. 读取测试文件
10. 修复
11. 再跑测试

这些中间结果都会留在主线程里。后面每一轮请求，都可能继续带着这些历史包袱。

2. Subagent 的更合理用法

diff 复制代码

主线程只负责调度：

- search-subagent：找出相关文件，返回文件列表和简短判断
- implement-subagent：读取必要文件并完成局部实现
- test-subagent：运行测试，返回失败原因和修复建议
- review-subagent：审查结果，只返回风险点

主线程保留的是摘要，而不是完整过程。

⚠️ 注意：Subagent 不是免费优化。

它适合复杂任务、长任务、多文件任务；不适合小修小补。对于简单修改，直接在主线程完成通常更便宜。

🚫 一个常见反模式：把 Subagent 当成"代读文件"的工具。

让 subagent 读 10 个文件再返回摘要，主线程基于摘要决策，看起来省了主线程 token，但实际问题不少：

subagent 的读取成本一分不少；
摘要可能丢掉结构、变量名、边界条件等关键信息；
主线程发现摘要不够用时，还要重读一遍，等于读了两次。

更合理的做法是让 Subagent 承担一个完整子任务：读取、分析、局部修改、自验证，而不是只帮主线程"代理读文件"。

3. TDD 要控制修复范围

TDD 很适合 AI 编程，但用不好也会放大成本。

低效做法是：测试一失败，就让模型重写整个文件。

更好的做法是：

markdown 复制代码

1. 只读取失败测试和对应实现文件。
2. 只分析当前失败原因。
3. 只 patch 相关函数或少量代码块。
4. 修复后只运行相关测试。
5. 通过后再跑完整测试。

这和 Hermes 中"优先 patch，而不是全量重写"的思路一致。局部修复不仅更省 Token，也更容易保留已经正确的部分。

八、IDE 与工具层：把无效上下文挡在模型外

工具配置是很容易被忽略的一环。很多 Token 浪费不是模型造成的，而是 IDE 自动把不该读的内容塞进了上下文。

不同工具的 ignore 文件名称不一样：有的用 .cursorignore，有的复用 .gitignore，有的提供索引排除设置。重点不是文件名，而是把构建产物、依赖目录、快照、大型 fixture、生成代码排除在 AI 上下文之外。

1. Cursor / 类似 IDE 的配置重点

diff 复制代码

- 避免不必要的 @workspace 全量注入。
- 使用 .cursorignore 排除 dist、build、coverage、node_modules。
- 排除大型 JSON、快照文件、生成文件。
- 大文件默认不要自动读取。
- 项目规则文件控制在 1-3K Token 内。

2. Claude Code / Agent CLI 的配置重点

diff 复制代码

- 为 planning、execution、review 设置不同模型。
- 长会话结束一个阶段后主动 compact。
- 常驻规则只保留核心约定。
- 高频流程做成 Skill，而不是塞进主提示词。
- 批量任务用 Subagent 隔离，但小任务不要过度拆分。

3. `.gitignore` 不等于 AI ignore

很多项目中，以下内容即使不会提交到 Git，也可能被 AI 工具扫描或读取：

构建产物：dist/、build/
依赖目录：node_modules/
覆盖率报告：coverage/
快照文件：*.snap
大型 fixture：*.json
自动生成代码：generated/
历史迁移文件：大量旧 migrations

这些内容应尽量排除在 AI 上下文之外。尤其是大型 JSON 和测试快照，极容易在不知不觉中消耗大量 Token。

4. 明确目标优于模糊请求

scss 复制代码

❌ 模糊请求：
帮我看看 src 里有没有用到 lodash 的地方。

✅ 命令式请求：
用 Grep 工具(或当前环境支持的检索方式)搜索 src 下 "lodash" 的引用，
只返回命中的文件和行号，不要读取无关文件。

能用 Shell、TypeScript compiler、测试框架完成的工作，就不要交给模型用自然语言慢慢推理。

九、综合案例：RBAC 模块的流程对比

这里用一个后台 RBAC 模块作为例子。任务范围包括：

用户、角色、权限模型；
登录与 Token 刷新；
权限 Guard；
super_admin 绕过；
前端菜单与按钮级权限；
初始化管理员与默认权限；
基础测试与联调。

1. 低控制流程

markdown 复制代码

1. 直接让模型开始写代码。
2. 写到一半再补充权限粒度。
3. 再补充 refreshToken 落库。
4. 再补充 super_admin 规则。
5. 前端接入时才发现权限字段不适合。
6. 回头修改后端模型和接口。
7. 测试失败后多次全量重写。

这种流程最大的问题不是"模型不够强"，而是需求边界一直在变，模型只能反复读取和改写同一批文件。

2. 工程化流程

diff 复制代码

Phase 0：需求澄清
- 确认权限粒度、Token 策略、super_admin、审计、多租户边界。

Phase 1：Spec 与 Plan
- 固定数据模型、接口范围、权限命名规则、前端接入方式。
- 拆分后端、前端、联调、测试阶段。

Phase 2：后端模型
- Prisma Schema
- Seed
- 基础类型

Phase 3：Auth 与权限
- 登录
- refreshToken
- Guard
- Decorator
- super_admin 绕过

Phase 4：业务模块
- Users
- Roles
- Permissions

Phase 5：前端接入
- 菜单权限
- 按钮权限
- 页面 Guard

Phase 6：测试与 Review
- 单元测试
- 权限场景测试
- 安全边界 Review

这种流程的好处很直接：

关键决策集中在前面；
每个阶段的上下文有限；
每一步都有验收标准；
出错时只影响局部；
强模型只用在关键决策和审查上。

3. 成本估算要更保守

如果直接按固定"缓存命中后的等效 Token"来估算，很容易过于理想化。更稳妥的写法，是按区间估算：

模式	输入 Token	输出 / 推理 Token	主要风险
低控制流程	高，且随轮次持续增长	高，返工多	需求漂移、全量重写、长上下文污染
工程化流程	中等，按阶段控制	中等，局部修改为主	前期需要花时间写 Spec 和 Plan
工程化 + 缓存优化	取决于模型缓存 TTL 和命中率	输出侧仍需单独控制	不能假设所有模型都有相同缓存表现

更稳妥的结论是：

对于复杂、重复度高、上下文容易膨胀的开发任务，通过 Spec、上下文控制、模型分层和缓存策略，成本有机会显著降下来；理想情况下甚至可以接近一个数量级。但能不能达到 90% 以上，要看任务重复度、模型缓存机制、工具链是否透传缓存，以及执行阶段能否持续保持小上下文。

十、策略优先级

落地时，可以先从这些低成本动作开始：

优先级	策略	实施成本	收益来源
🥇 立即做	写好工具对应的规则文件	低	减少重复解释
🥇 立即做	配置 AI ignore	低	减少无效文件进入上下文
🥇 立即做	明确模型分层	低	避免所有任务都使用高价模型
🥈 优先建立	Spec → Plan → Execute 工作流	中	减少返工和需求漂移
🥈 优先建立	阶段结束后主动压缩上下文	低	避免长会话持续膨胀
🥉 持续优化	沉淀高频 Skills	中	复用流程经验
🥉 持续优化	按模型设计缓存策略	中	提高稳定前缀复用率
🏅 长期建设	Subagent 工作流	中高	隔离复杂任务上下文
🏅 长期建设	本地模型处理简单任务	中高	降低高频简单任务成本

十一、结论：省 Token 的核心是流程设计

AI 编程里的省 Token，本质上不是提示词技巧，而是工程流程设计。

Spec 先行，减少返工 Token；
项目规则与 Skills，减少重复解释 Token；
上下文工程，减少无效读取 Token；
模型分层，减少高价模型滥用；
缓存策略，减少稳定前缀重复计费；
Subagent，减少主线程上下文污染；
工具配置，减少无关文件进入模型。

这些策略最终指向同一件事：让模型在每个阶段只处理当前真正需要的信息。

但降本不能以质量下降为代价。每一项优化都应该同时观察三类指标：

功能是否仍然正确；
bug 率是否上升；
Review 与测试是否仍然充分。

成本下降只是结果之一。更值得追求的是：在质量可控的前提下，让 AI 编程流程更稳定、更可复用，也更可预测。

写在最后🧪

这里是言萧凡的 AI 编程实验室 。我会在这里持续记录和分享 AI 工具、编程实践 ，以及那些值得沉淀下来的高效工作方法。不只聊概念，也尽量分享能直接上手、能够复用的经验。希望这间小小的实验室，能陪你一起探索、实践和成长。2026 年，一起进步。
有兴趣的话可以添加我的微信号 Cookieboty 一起交流，不仅是编程也可以是畅谈人生

AI 编程省 Token 实战：从 Spec、上下文工程到模型分层的降本策略

一、为什么 AI 编程场景更容易烧 Token

二、Spec 先行：用前置设计减少返工 Token

1. 直接开发的典型问题

2. Spec 先行的更稳流程

3. Spec 也要控制粒度

三、记忆与 Skills：把重复解释变成可复用资产

1. 三类信息应该分层存放

2. 常驻规则要短，Skills 要按需加载

3. 长期记忆与经验沉淀的价值

四、上下文工程：让模型只看必要代码

1. 三种上下文加载方式

2. 用检索工具缩小读取范围

3. 多文件任务要分批处理

4. 长会话要主动压缩

五、缓存策略：不同模型要分开处理

1. 缓存策略的核心原则

2. 不同模型缓存时间不同

3. 缓存策略的工程检查清单

六、模型分层：不同开发任务使用不同模型

1. 开发任务复杂度分层

2. 一套更实用的模型路由

3. 本地模型适合低风险简单任务

4. Thinking / Extended Reasoning 要按需开启

七、Subagent 与工作流：隔离上下文，而不是盲目并行

1. 没有 Subagent 时的问题

2. Subagent 的更合理用法

3. TDD 要控制修复范围

八、IDE 与工具层：把无效上下文挡在模型外

1. Cursor / 类似 IDE 的配置重点

2. Claude Code / Agent CLI 的配置重点

3. .gitignore 不等于 AI ignore

4. 明确目标优于模糊请求

九、综合案例：RBAC 模块的流程对比

1. 低控制流程

2. 工程化流程

3. 成本估算要更保守

十、策略优先级

十一、结论：省 Token 的核心是流程设计

写在最后🧪

3. `.gitignore` 不等于 AI ignore