大家好，这里是言萧凡的 AI 编程实验室。在这个小小的实验室里我不仅会记录各种 AI 工具的奇技淫巧，geng想和大家沉淀那些真正Neng落地的、高效的工作方法。毕竟概念聊得再天花乱坠，Zui终还得回归到代码和账单上，对吧？今天咱们不聊虚的，直接来点“硬核”的——怎么在 AI 编程中把 Token 消耗降下来让钱包少流点血。

hen多开发者刚开始用 Cursor、Claude Code 或者 Codex 这类工具时往往会有一种错觉：觉得只要我提示词写得够短，就Neng省钱。但现实往往hen骨感。当你kan着月底那长长的账单，或者发现一个简单的功Neng改来改去消耗了几十万 Token 时那种心痛是真实的。其实AI 编程里的省钱之道，根本不在于“少写几个字”，而在于工程流程的设计。

咱们得明白一个道理：成本失控通常不是因为模型单价太贵，而是因为流程太“野”。一个中等复杂度的功Neng模块，Ru果缺乏控制，模型就会陷入“读文件-解释-修改-再读文件”的死循环。这种反复摩擦，才是 Token 的无底洞。所以今天这篇文章，我想从六个维度，系统地聊聊如何通过架构和流程优化，把 Token 消耗打下来。

一、 别让模型Zuo“无头苍蝇”：上下文控制的艺术

在 AI 编程中，Zui直接的成本控制点就是文件读取范围。模型并不是kan得越多越好，无关文件一旦挤进上下文，不仅增加成本，还容易干扰模型判断，让它产生幻觉。

1. 拒绝全量浏览，先检索再读取

咱们先kan个常见的反模式。当你需要把项目里的 `oldApiClient` 全部迁移到 `newApiClient` 时hen多人的第一反应是让模型自己去“kankan”。

❌ 模糊请求：帮我kankan src 里有没有用到 lodash 的地方，或者帮我找找哪里引用了 oldApiClient。

这种Zuo法极其奢侈。模型可Neng会像个无头苍蝇一样，先去读项目配置，再扫目录结构，甚至把一堆无关的入口文件dou翻一遍。这就像是你让一个装修工去修灯泡，结果他把整个房子的家具dou搬了一遍。

geng高效的方式是命令式的：

✅ 命令式请求：用 Grep 工具搜索 src 下 "oldApiClient" 的引用，只返回命中的文件和行号，不要读取无关文件。

Neng用 Shell、TypeScript compiler 或者测试框架直接搞定的事情，千万别交给模型用自然语言慢慢推理。先用检索工具缩小范围，锁定目标文件，然后再让模型去读取和修改。这条思路Ke以推广到绝大多数代码任务：描述清楚要找什么让模型自己选择工具去定位。

2. 配置好你的“守门员”：Ignore 文件

工具配置这事儿，特别容易被忽视。hen多 Token 浪费其实不是模型造成的，而是 IDE 自作聪明把不该读的内容塞进了上下文。比如 `node_modules`、构建产物 `dist`、覆盖率报告 `coverage`，还有那些巨大的 JSON 快照文件。

hen多项目即使配置了 `.gitignore`，AI 工具依然会扫描它们。因为不同工具有不同的规则，有的用 `.cursorignore`，有的复用 `.gitignore`，还有的需要在索引设置里排除。你得花点时间把这些“垃圾内容”挡在门外。尤其是大型 JSON 和测试快照，它们极容易在不知不觉中吞噬掉大量 Token。

二、 架构先行：Spec 与 Plan 的降本魔力

咱们来聊聊 L4 层面的东西：架构与计划。这里我拿一个后台 RBAC模块来举例。

Ru果你直接上来就扔给模型一句：“帮我Zuo一个 RBAC 权限系统，NestJS + Prisma。” 接下来的流程hen可Neng是这样的：

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

kan出来了吗？这里Zui贵的不是某一次输出，而是每次需求微调dou会触发“重新理解现有代码 + 重新修改多个文件”。这种连锁返工，就是成本爆炸的元凶。没有 Spec 时模型只Neng根据模糊需求自行脑补假设。一旦假设和真实需求对不上，后面就是连锁反应：重读代码、重改接口、重调模型、重跑测试。

1. 先写 Spec，固定决策

geng实用的结构是先收敛边界。我们Ke以分两步走：

第一步：需求澄清
- 权限粒度：接口 / 页面 / 按钮
- 是否需要 super_admin 绕过
- refreshToken 是否落库
- 是否需要审计日志
- 是否包含组织、部门、租户维度
- 本次明确不Zuo哪些Neng力
第二步：输出 SPEC.md
- 数据模型
- 模块边界
- API 范围
- 权限命名规则
- 前端接入方式
- 非目标范围

Spec 的价值不在于多写一份文档，而是提前固定关键决策，减少后续返工。Spec 不是越长越好，写得太细反而会变成新的上下文负担。判断标准hen简单：凡是Neng防止后续反复修改的决策，dou值得写进去。

2. 拆解 Plan，分批执行

有了 Spec，接下来就是 Plan。不要试图一口气吃成个胖子。geng稳妥的方式是按模块分批：

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

每一批完成后先跑局部验证，再进入下一批。这样即使出错，影响也会被限制在当前批次不至于把整个任务拖乱。这种流程的好处hen直接：虽然前期花了点 Token Zuo规划，但后期省下的“返工费”绝对值回票价。

三、 模型分层：好钢用在刀刃上

不是所有开发任务dou需要Zui强模型。真正需要强模型的，通常是决策类任务，比如架构设计、复杂 Bug 定位；而机械执行类任务，比如生成测试样板、批量修改、格式整理，完全Ke以用便宜点的模型。

我们Ke以简单理解为：

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

对于提交信息生成、简单重命名这类低风险任务，Ru果本地模型质量足够，也Ke以交给本地模型处理。但要注意，本地模型不一定总是geng省：还得算上硬件成本、响应速度和结果质量。Ru果修出来的代码还要反复返工，那反而得不偿失。

💡 现实约束：大多数 IDE Agent 并不支持逐任务自动切换模型。 Cursor、Claude Code 这类工具通常只Neng按会话或项目选模型。所以geng可执行的Zuo法是：在脑子里过一遍，这个任务值得开个 GPT-4o 吗？还是用 3.5-Sonnet 就够了？这种判断本身，也是一种成本控制。

四、 Subagent 的正确打开方式：隔离而非代读

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

hen多人觉得 Subagent Neng省钱，于是把 Subagent 当成了“代读文件”的工具。比如让 Subagent 读 100 个文件再返回摘要，主线程基于摘要决策。这kan起来省了主线程 Token，但实际问题不少：Subagent 往往会增加调用次数，甚至增加总 Token。

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

一个会话经历了大量工具调用、测试日志和文件读取之后继续往下Zuo会越来越贵，也越来越容易跑偏。这些中间结果dou会留在主线程里后面每一轮请求dou可Neng带着这些历史包袱。

geng合理的Zuo法是让 Subagent 承担一个完整子任务：读取、分析、局部修改、自验证。主线程只负责调度：

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

主线程保留的是摘要，而不是完整过程。这和 Hermes 中“优先 patch，而不是全量重写”的思路一致。局部修复不仅geng省 Token，也geng容易保留Yi经正确的部分。

五、 缓存策略：别被“前缀缓存”忽悠了

hen多文章会把“前缀缓存”讲得hen简单：把稳定内容放前面就Neng命中缓存，输入成本下降 X%。这个方向没错，但说得太粗。不同模型、不同供应商、不同接入层的缓存机制并不一样。AI 编程场景里Ru果把所有模型dou按同一套规则处理，hen容易误判成本。

这里说的是可控上下文的组织方式。真实 Agent 框架里工具调用结果的位置通常由框架决定，但我们仍然Ke以控制哪些内容稳定、哪些内容动态、哪些内容不要提前塞进上下文。

一个geng适合开发任务的“可控上下文”顺序是：

项目级常驻规则

流程级Neng力

个人与长期偏好

不建议把用户临时输入、错误日志、命令输出放在稳定前缀之前，否则缓存命中率会下降。每次dou会用到的，放常驻规则；偶尔才会用到的，Zuo成 Skill 或文档按需加载。

⚠️ 注意：成本估算要留有余地。 Ru果直接按固定“缓存命中后的等效 Token”来估算，hen容易过于理想化。geng稳妥的写法，是按区间估算。Ru果这些问题没有确认，就不要在成本估算中直接写“缓存命中多少”了。

六、 记忆与 Skills：沉淀经验，拒绝重复劳动

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

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

hen多开发者每次开新会话dou会重新说明：“我们用 NestJS，用 Prisma，测试命令是 `npm run test`，不要用 lodash……” 这些规则单次kan起来不长，但每天重复多次就会变成稳定的 Token 浪费。

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

规则文件：只放高频规则
- 技术栈
- 包管理器
- 命名规范
- 测试命令
- 禁止事项
Skills / 工作流脚本 / 自定义 Subagent：放流程和专项知识
- 如何写后端 CRUD
- 如何Zuo TDD
- 如何Zuo安全 Review
- 如何Zuo前端 UI 检查
- 如何写发布说明

例如第一次Zuo“批量迁移 import 路径”时Agent 可Neng会经历搜索、试错、修复、验证。完成后Ru果Neng把有效流程沉淀成 Skill，下一次再遇到同类任务，就不需要重新探索流程。这种节省不是一次性的，而是会随着重复任务累积。

降本的本质是工程化

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

所以AI 编程降本的核心不是“让模型少干活”，而是：让模型读取合适的上下文，使用合适等级的模型。

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

希望这篇分享Neng给你带来一些启发。Ru果你对 AI 编程、成本优化或者仅仅是想聊聊技术人生，欢迎添加我的微信 Cookieboty 一起交流。这里是言萧凡的 AI 编程实验室，咱们下期见，一起进步！

---