AI编程工具上线之后，"vibe coding"这个词彻底火了。但说实话，网上九成文章要么在吹，要么在骂，真正聊怎么把它塞进日常工作的没几个。这篇不是教程，是我用了3个月、烧了2000多美金token之后的实际 workflow——7个具体坑，哪些设置能省40%费用，什么时候该打断 AI，什么时候该自己动手。

先泼一盆冷水：不是每个项目都适合 vibe coding。如果你跑本地大模型，随便玩。但如果用商业工具，第一步是确认项目能不能这么搞——客户说了算。没批准？自己私下搭着玩。客户点头了，再正式上。

打开网易新闻 查看精彩图片

我把它拆成三种场景：从零开始的项目、核心功能开发、小 bug 修复。下面说的都基于实际工具使用，但思路应该能迁移到其他平台。

我的基础配置

先说几个固定习惯，不复杂但省很多事：

用 Skills 来组织上下文。把常用规则、项目结构、代码规范写成 skill 文件，随时调用，不用每次都重新交代一遍。

@ 符号引用文件。比粘贴代码块干净，AI 也能直接看到完整上下文。

Esc 随时打断。AI 生成到一半发现方向不对，立刻停，比生成完再改省 token。

Plan mode 做决策。让 AI 先出方案，不急着写代码，对比完再动手。

Session 命名和管理。一个功能一个 session，方便回溯，也方便清理上下文。

Hooks 保护敏感文件。配置好规则，防止 AI 不小心动到密钥、配置这些不该动的东西。

手动命令留后路。有些操作我自己敲命令比让 AI 猜更放心。

场景一：从零开始的项目

主流说法是"初始架构最关键，让 AI 从头规划"。我的做法相反：初始架构太关键了，不能完全交给 AI。

流程是这样：我先自己写一份计划，基于需求文档。同时把需求整理成项目文档或者单独的 skill，看复杂度决定。然后进 plan mode，让 AI 也出一份方案。接下来是对比环节——我研究 AI 的建议，质疑不合理的部分，最后选我的、选 AI 的，或者融合两者。

这个"辩论"过程通常能发现我自己漏掉的边界情况，也能防止过度设计。比如上次一个数据同步功能，AI 的方案里加了消息队列，但我确认需求后知道数据量根本用不上，直接砍掉了。

场景二：核心功能开发

大功能的流程和上面类似：先 plan debate，输出存成新的 skill。

这里有个省 token 的技巧——用独立的 skill 文件存不同功能的上下文，而不是全塞在一个对话里。上下文越长，幻觉越严重，这是实打实的成本。

方案确定后，我让 AI 开始实现，但手不能离开键盘。任何看不懂的改动，Esc 打断，问清楚为什么。不同意就提出我的做法，让它按我的来。

这个"打断-质疑-修正"的循环，既能防止 sloppy code，也能控制 token 消耗。我见过太多人把 AI 当黑盒，生成什么 accept 什么，最后代码债堆成山。

场景三：Bug 修复

分三种情况处理：

简单 bug：先自己找，边缘情况搞不定再找 AI。这个顺序很重要——自己的排查过程本身就是对代码的理解，全丢给 AI 会越修越懵。

复杂 bug：让 AI 定位原因并报告，但不让它直接修。我验证诊断结果，自己规划修复方案，再让 AI 执行。多这一步，能避免"症状对了但病根没找对"的伪修复。

完全没头绪：这时候才全权交给 AI，但保留手动 approve 每一步。是慢一些，但比 AI 乱改一通之后回滚要快。

最后说一个省 token 的具体技巧：报错信息别全贴。复制核心异常类型 + 出错的行号，就这两样。响应速度更快，准确度反而更高，token 能省一半。

就这么简单。没有魔法，没有捷径。vibe coding 的核心不是让 AI 替你写，而是你保持控制，让 AI 干重活。很多人把这个关系搞反了，结果要么不敢用，要么用废了。

如果你也在用这类工具，上面这些应该能帮你少踩几个我踩过的坑。