上周看到一个帖子，有人用 vibe coding 做了个 vibe 项目展示小站，一开始充了10块，软件送了6块，心想一个小站能用多少。结果十几分钟就提示充值，又充了10块才把站搞起来。
说真的，这个坑我也踩过。不是 token 贵，是你在让 AI 反复改一些本来不该放在那里的东西。
问题出在哪里
用 vibe coding 做 HTML 小工具，最容易犯的错是：**把所有逻辑都堆在前端，然后发现不对，再让 AI 一遍一遍改**。
每次改动，AI 要读懂你现有的代码，理解上下文，生成新版本，再处理你反馈的 bug。上下文越长，token 消耗越快。
如果你的 HTML 文件已经写了几百行，每次对话都要把整个文件喂进去，这个成本是指数级的。
更要命的是，有些逻辑天生就不适合放前端，放了之后调试起来极其痛苦，你会陷入一个循环：改了前端 → 发现新问题 → 再改 → 再发现问题。token 就这么烧掉了。
前端能做什么，不能做什么
我自己的判断标准很简单：**前端只做「展示」和「交互」，不做「计算」和「存储」**。
具体来说，这些放前端没问题：
- 表单收集、输入验证（格式检查、必填项）
- 纯展示逻辑：排序、筛选、分页（数据量小的情况下）
- UI 状态管理：折叠、展开、tab 切换
- 本地缓存（localStorage）存一些用户偏好
这些就别放前端了：
- 需要读写持久化数据的操作
- 涉及 API 密钥的调用（密钥放前端等于公开）
- 复杂的数据处理、格式转换
- 任何需要跨用户共享状态的功能
那个做展示小站的朋友，如果他的项目数据是硬编码在 HTML 里的，每次加新项目都要让 AI 改文件，这就是在用最贵的方式做最简单的事。
一个具体的切法
假设你要做一个「工具收藏夹」页面，用户可以提交工具、浏览列表、按分类筛选。
**错误做法**：全部写在一个 HTML 文件里，数据也硬编码在里面。每次加工具就让 AI 改 HTML。
**正确切法**：
- HTML 负责渲染列表、处理筛选交互、提交表单
- 数据存在后端，用Python在线运行写一个简单的接口，读写 JSON 或数据库
- 如果数据量不大，用SQLite编辑器直接管理工具数据，不用写复杂的 ORM
这样切之后，前端的 HTML 文件基本稳定，你改数据不需要动代码。AI 的上下文保持干净，每次对话成本可控。
调试成本也是 token 成本
还有一个容易忽略的点：**路径问题**。
那个帖子里也提到了，本地用绝对路径测试，样式加载不上；上传服务器又得改路径。这种问题如果反复让 AI 帮你改，每次都要重新解释上下文，非常浪费。
解决方案很简单：开发阶段直接用HTML在线运行预览，环境和最终托管环境一致，路径问题在开发阶段就暴露，不会等到上线才发现。
本地环境和线上环境不一致，是 vibe coding 阶段最容易产生「无效 token 消耗」的地方之一。你让 AI 修的那些 bug，有相当一部分根本不是代码问题，是环境问题。
动手之前先想清楚这三个问题
在开始 vibe coding 之前，花10分钟想清楚：
- **数据从哪来，存在哪里？** 如果答案是「存在 HTML 文件里」，基本上就是错的。
- **有没有需要保密的东西？** API 密钥、数据库连接信息，一律不能出现在前端。
- **用户操作会不会改变数据？** 如果会，就需要后端，不要用前端硬撑。
想清楚这三个问题，你给 AI 的第一个 prompt 就会准确很多。prompt 准确，AI 生成的代码方向对，后续修改少，token 自然省。
vibe coding 降低了写代码的门槛，但没有降低「想清楚再动手」的必要性。那20块钱的教训，本质上不是 token 贵，是前期没想好架构，让 AI 在错误的方向上反复迭代。
现在就可以做的一件事：下次开始一个新的 HTML 小工具之前，先在纸上画一下数据流——数据从哪来、存在哪、谁来读写。这一步不需要 AI，但能帮你省掉一半的 token。