前端 Token 节省实战心得
前端 Token 节省实战心得
从前端转向 AI Native 开发已经有一段时间了，现在基本全程使用 Cursor 或 CodeBuddy 写代码。
刚开始的时候，3k 刀的预算真的感觉随便用。直到有一天 Token 预算突然开始打折，额度肉眼可见地往下掉，我才被迫认真思考：平时到底有哪些 Token 是花在了真正有价值的地方，哪些只是被浪费掉了？
今天就分享一下我最近总结的几条 Token 节省心得。
Token 不是用得多，而是浪费得多
一开始我以为，节省 Token 的方法就是少用 AI。但实际用下来发现，这个方向完全搞反了。
很多时候，Token 不是因为任务太复杂才消耗得多，而是因为上下文不断膨胀、重复信息反复传输，导致每一轮真正用于解决问题的内容只占很小一部分。
以 Cursor 为例，每轮对话有相对固定的基础成本，会话越长，历史上下文带来的额外消耗越明显。到了后期，一轮输入可能是前期的很多倍，但真正解决问题的内容并没有增加多少。
第 5 轮：上下文较短，主要处理当前问题 |
很多 Token，其实花在了重传历史、重复解释和重新读取文件上。
我项目里的 Token 消耗分布
回头检查项目消耗之后，我发现最主要的开销集中在三个地方：
- Figma UI 还原：约 30%
- 长会话后期的对话：约 25%
- Mock 数据反复修改：约 15%
这三块加起来已经占了大约 70%。也就是说，只要先解决这三个问题，就能节省掉大部分不必要的消耗。
后来我主要摸索出了三个动作，实际使用下来效果比较明显。
一、会话拆分：一个会话只做一件事
以前我很喜欢在一个会话里持续追加任务：先让 AI 写页面，再让它接接口，然后改一个交互，最后顺便修几个无关的 Bug。
这样做一开始很方便，因为上下文都在。但随着会话变长，前面所有功能的历史也会被不断带入后续对话。AI 需要在一大段旧内容里寻找当前问题，Token 消耗和理解成本都会上升。
现在我的做法是按功能点拆分会话：
会话 A：还原登录页面 |
每个会话尽量只解决一个明确问题。遇到 Bug 时，也会单独开一个调试会话，不把排查过程污染到主开发会话里。
另外，一个会话如果已经超过较多轮次，我通常不会继续往里面加新任务。长会话的历史收益会越来越低，重新开一个会话，重新提供必要上下文，往往更便宜，也更容易让 AI 保持清晰。
这部分是我感受到最明显的节省方式，大约可以减少 20% 到 40% 的消耗。
二、上下文精准化：引用真正需要的内容
上下文越多不代表效果越好。很多时候，给 AI 的内容太多，反而会让它在大量无关代码里寻找重点。
我现在会有意识地区分不同场景使用不同的上下文方式：
用精准文件代替全库扫描
如果已经知道问题发生在哪个组件，就直接引用具体文件或目录，不随手使用全库上下文。全库扫描适合探索未知问题，但不适合每一轮都使用。
优先：@src/components/UserCard.tsx |
用搜索结果代替重复阅读
需要查找某个函数、接口或配置时，先用 Grep 定位关键位置，再把相关片段交给 AI，而不是让它反复读取整个项目。
Figma 使用精准 node-id
做 UI 还原时，我会尽量直接提供需要实现的节点，而不是让 AI 反复探索整个 Figma 页面。节点越精准，布局信息、样式信息和组件关系就越集中。
方案可以贴链接，就不要重复描述
如果已经有设计稿、接口文档或技术方案，就直接提供链接或文件位置。反复用自然语言描述同一份内容，既浪费时间，也会产生不同版本的理解。
调研和编码分开
跨模块调研时，可以让 explore 子 Agent 先完成探索，只返回结论、关键文件和风险点。调研完成后，再开一个新的会话写代码。
探索会话：找到相关模块、依赖关系和风险 |
上下文精准化的改动成本很小，但效果通常很明显，大约可以减少 15% 到 30% 的 Token 消耗。
三、Mock 延迟生成：协议没定不要急着造数据
这部分是我踩坑最深的地方。
以前接口协议还没有完全确定时，就先让 AI 根据当前理解生成一套 Mock 数据。后端接口一改，前端字段就跟着改，之前生成的大段 JSON 也要重新修改。
更麻烦的是，AI 需要反复读取旧 Mock、对比新协议、修正字段，再重新检查页面。这相当于同一份工作做了两遍，甚至更多遍。
现在我会把顺序调整成：
确认接口协议 |
先确认 proto 或接口协议，再生成 DTO，最后根据 DTO 填充示例数据。这样 Mock 只需要做一次，后续接口变化也更容易定位。
这部分大约可以减少 15% 的消耗，更重要的是能减少很多没有价值的返工。
两个止损小技巧
Figma 同一个问题不要无限重试
如果 Figma 还原连续几轮都没有达到预期，我现在会把重试次数控制在三轮以内。三轮之后，如果 AI 还是无法理解具体偏差，就直接自己写 CSS，把精确的尺寸、间距和颜色值告诉它。
让 AI 继续猜，通常只会重复消耗 Token，并不会自动产生新的信息。
根据任务选择模型
如果任务可以用一两句话描述清楚，而且执行路径比较明确，我会优先使用 Auto 或成本更低的模型。
需要“帮我想怎么做”、分析复杂架构、排查跨模块问题时，再切换到更强的模型，并且尽量在新会话中开始。
模型选择不是越强越好，而是要和任务的不确定性匹配。简单任务用强模型，很多时候只是用更贵的方式完成相同结果。
最后总结
现在我把节省 Token 总结成四句话：
会话要短，引用要准，Mock 要晚，模型要选对。
节省 Token 并不是抠门，也不是刻意少用 AI。真正的目标是让每一轮推理都花在该花的地方，减少无意义的历史重传、重复解释和返工。
当 AI 的执行能力越来越强之后，开发者需要做的可能不是减少使用它，而是更好地组织任务、控制上下文，并且知道什么时候该继续交给 AI，什么时候应该自己做决定。