摘要：V2EX 上关于“深度 Vibe Coding 两个月、三百多亿 Token”的分享，真正有价值的不是用量数字，而是一套严肃项目中的 AI 编程组织方法。
V2EX 上这篇“深度 Vibe Coding 2 个月，用了三百多亿 Token”的帖子，表面上最抓眼球的是数字：两个月、三百多亿 token、上百个会话、多个模型协作。但真正值得讨论的，不是“谁更能烧 token”，而是这套工作方式暴露出的一个趋势：Vibe Coding 正在从个人玩具变成一种需要工程管理方法的开发范式。
过去大家说 Vibe Coding，常常想到的是“用自然语言让 AI 写代码”。但在稍微严肃一点的项目里，这远远不够。AI 不是一个万能程序员，而更像一组能力不稳定、记忆有限、但并行度极高的数字工程师。能不能把它们用好，取决于人是否能提供目标、判断、约束、复盘和收敛。
一、长期 session 的价值：不是上下文越长越好，而是上下文要连续
帖子里最重要的工程信号之一，是长期 session 和高缓存命中率。作者提到 Codex 长期主会话承担主要开发工作，review 则由其他模型或其他会话并行完成。长期 session 的好处不是“模型能记住一切”，而是它能保持项目惯性：知道最近改了什么、为什么改、哪些坑刚踩过、哪些设计已经被否掉。
对 AI 编程来说，频繁开新会话会带来一种隐性成本：每次都要重新解释项目背景，每次都要重新校准风格，每次都可能重复提出已经否定过的方案。长期 session 则更像一个持续工作的主程，虽然会因为 compact 损失一部分细节，但至少保留了任务线索和工程脉络。
这给普通团队的启发是：不要把 AI 会话当一次性聊天窗口，而要把它当工作线程。一个复杂项目可以有“主开发会话”“审查会话”“重构会话”“安全审查会话”，每个会话有自己的职责，而不是让一个聊天框包办所有事情。
二、Vibe Coding 的核心配置：一个主程，多个 reviewer
这篇帖子最值得借鉴的不是模型排名，而是角色分工。作者的做法接近“Main Coder + 多个 Reviewer”：一个主会话负责持续推进代码，多个 reviewer 从不同角度找问题。
这比单 Agent 自写自查可靠得多。因为同一个模型在同一个上下文里，很容易沿着自己的错误前提继续解释。多个 reviewer 的价值不只是“多看几遍”，而是引入不同模型、不同会话、不同上下文里的反对意见。
更实用的流程可以是：
- 主程会话根据任务和现有代码制定实现方案。
- 主程完成第一版修改。
- 开干净会话做代码审查，不给太多过程解释，只给目标、diff 和验收标准。
- 至少让两个 reviewer 独立输出 findings。
- 人合并 findings，去掉重复项和幻觉项，形成 tracking 文档。
- 主程按 tracking 文档逐项修复。
- 再做一轮 reviewer 复查。
这种方式看起来“古法”，但它符合工程常识：重要代码不应该只靠作者自证正确，AI 写的代码也不例外。
三、真正消耗时间的不是写功能，而是重构、找漏洞和降复杂度
帖子里有一句很关键：大量时间花在重构、找逻辑漏洞、找 bug、降低复杂度上。这恰好戳中了 Vibe Coding 的核心矛盾。
AI 很擅长把功能堆出来，也很擅长在局部补丁上快速前进。但它常常会把系统推向复杂化：多加一层抽象、多造一个配置、多引入一个兼容分支、多写一组看似通用的工具。短期看功能跑了，长期看维护成本升高。
所以 Vibe Coding 的成熟用法，不是不断对 AI 说“继续实现”，而是反复插入三类任务：
- 降复杂度：删掉不必要的抽象，合并重复路径。
- 清理过度工程：把为假想未来设计的结构收回来。
- 找逻辑漏洞：让 reviewer 专门攻击边界条件、状态流转、并发、权限和错误处理。
如果没有这些任务，AI 会越写越多；有了这些任务，AI 才可能越写越清楚。
四、人类最重要的价值：工程判断和收敛
Vibe Coding 最容易被误解成“人只负责提需求，AI 负责实现”。这在玩具项目里可能成立，在严肃项目里不成立。
AI 最缺的不是代码能力，而是工程判断。它不知道做到什么程度就该停；不知道什么时候该重构，什么时候该忍受局部不完美；不知道一个看似优雅的架构会不会拖慢交付；也不知道某个边缘问题是不是值得投入一整天。
人的作用不是和 AI 比谁写代码快，而是做选择：
- 这个方案是不是符合产品阶段？
- 这个抽象是不是值得？
- 这个 bug 是架构问题还是局部补丁？
- 这个安全风险是不是必须马上处理？
- 这个 reviewer finding 是真实问题还是模型过度联想？
- 这个任务是否应该停止扩散，先交付可用版本？
AI 可以提供候选项，人必须做收敛。没有人类判断的 Vibe Coding，很容易变成无限重构和无限解释。
五、Tracking 文档是 Vibe Coding 的操作台
帖子里提到一种做法：新增 feature 后，用干净 session 生成多组 findings，再合并成一个 tracking 文档，由主程逐项处理。这一点非常重要。
很多人用 AI 写代码失败，不是因为 AI 写不出代码，而是因为任务状态丢失。这个 bug 改了吗？这个 reviewer 意见是真是假？这个边界条件有没有测试？这个重构是不是已经完成？如果这些信息只存在聊天窗口里，项目很快会失控。
Tracking 文档的价值，就是把 AI 的多轮对话变成工程可管理对象。它至少应该包含：
- 问题编号。
- 来源 reviewer。
- 严重程度。
- 涉及文件或模块。
- 复现方式或风险描述。
- 主程处理状态。
- 验证命令或测试结果。
- 人工判断结论。
这相当于给 Vibe Coding 加了一个轻量 issue tracker。AI 可以生成、更新、执行，但最终状态应该由人确认。
六、模型差异重要，但流程比模型更重要
帖子里比较了 Codex、Claude Code、Fable、Gemini、OpenCode 等工具的体验。不同模型确实有差异：有的更适合作主程，有的更适合 review，有的注释风格啰嗦，有的安全审查更敏感，有的容易夸夸式输出。
但真正稳定的做法，不是押注某一个模型永远最强，而是把模型放进流程里。
一个模型写代码，另一个模型审查；一个模型做功能，另一个模型专门找 over engineering；一个模型看安全，另一个模型看业务逻辑。模型能力会波动，产品也会更新，但“主程 + reviewer + tracking + 人类收敛”这套结构可以长期复用。
这也是为什么只讨论模型排名意义有限。模型排行榜回答的是“谁更聪明”，工程流程回答的是“系统如何在模型不稳定时仍然可靠”。
七、安全和自动审查：能参考，不能迷信
帖子里也提到 Codex Cloud Security、GitHub Copilot AI 这类自动审查能力。它们能发现一些问题，但不能全信。
自动安全审查适合做第一层筛查，尤其是明显的凭据泄露、危险依赖、权限配置、注入风险、越权访问等。但它不一定理解业务语义，也不一定知道某个内部接口在真实场景里意味着什么。
所以更稳的做法是分层：
- 自动工具做基础扫描。
- AI reviewer 做上下文审查。
- 人类做风险判断。
- 关键路径用测试和真实环境验证闭环。
安全问题尤其不能让 AI 自己“解释通过”。凡是涉及权限、数据、资金、外部接口、生产环境的改动，都应该有明确的人类闸门。
八、Vibe Coding 的经验清单
结合这篇帖子和实际项目经验，一套可执行的 Vibe Coding 工作法可以概括为十条：
- 保留一个长期主程 session，不要每个小任务都重开。
- 给 reviewer 使用干净 session，减少被主程思路污染。
- 复杂 feature 至少两轮 review，一轮找 bug，一轮降复杂度。
- 把所有 findings 合并到 tracking 文档，不靠聊天记录记忆。
- 不要只让 AI 加功能，要定期让 AI 删代码、降复杂度、清理过度工程。
- 重要架构决策由人收敛，AI 只提供候选方案。
- 自动安全审查可以用，但不能替代人工判断。
- 每次任务结束写工作日志，记录改了什么、为什么、还剩什么风险。
- 对不同模型做角色分工，而不是只问哪个模型最强。
- 用测试、build、lint、真实运行结果证明完成，不接受“我已经完成”的口头声明。
结语
Vibe Coding 的成熟形态，不是一个人对着 AI 说“帮我写个功能”，而是把 AI 当成一个高并发但需要管理的工程团队。
它需要主程，需要 reviewer，需要 tracking，需要测试，需要安全审查，也需要人类工程判断。Token 消耗只是表象，真正的成本是上下文管理、质量控制和决策收敛。
未来的软件工程师，不一定要比 AI 写得更快，但必须比 AI 更会判断：知道什么时候推进，什么时候停下；什么时候接受复杂度，什么时候砍掉复杂度；什么时候相信模型，什么时候要求证据。
这才是 Vibe Coding 从“爽感”走向“生产力”的分界线。
参考链接：
- V2EX 讨论：深度 Vibe Coding 2 个月，用了三百多亿 Token