最近半个月，我基本都在赶一个项目。
以前大多数时候七八点能回家，这段时间晚上十点以后回家已经比较常见。这个周末连续加班了两天，项目团队目前有三个后端，大家都在大量使用 AI Coding。
但一个让我很困惑的现象是：
AI 用得越来越多，人也越来越忙，项目却没有想象中那么快。
从功能本身看，这个系统甚至算不上特别复杂。核心就是一个业务发起流程和一个审核流程，真正复杂的是财务业务本身比较严谨，还需要和客户不同部门提供的很多外部接口进行对接。
但实际开发过程中，我们经常感觉在原地踏步。
这一周，仅我个人的模型调用成本，粗略统计就已经超过了 2000 美元。
这让我开始重新思考一件事情：
Vibe Coding 到底是在提高开发效率，还是只是在提高“写代码”的速度？
先说结论
这次项目让我觉得，我们踩的坑主要不是模型能力不够，而是下面三个问题。
第一，在没有真正理解业务和现有代码的情况下，就开始让模型大量修改代码。
第二，把一个快速验证 Demo，当成了后续正式工程的基础。
第三，人没有掌握整体设计，导致 AI 每次只能解决眼前的问题，最终大量重复读取、修改甚至推翻之前的代码。
AI 写代码确实很快。
但如果方向、边界和上下文没有先建立起来，它也可以非常快地把错误的东西做得越来越完整。
一、我们其实一直在和一个“黑盒项目”做斗争
这个项目有一个很明显的特点：
业务上下文非常多。
财务流程本身有很多规则，又要对接多个外部系统，而接口提供方分散在不同部门。
真正开发一个功能时，需要同时知道：
业务现在进行到哪个阶段、前面发生过什么、后面还要做什么、哪些接口已经确认、哪些还是 Mock、当前状态怎么流转，以及一些特殊情况应该怎么处理。
这些东西不是一句 Prompt 能描述完整的。
模型每次拿到的往往只是：
帮我把这个接口改一下。
或者：
这里增加一个状态。
或者：
这个流程现在有问题，帮我修一下。
单看这个任务，它可能改得完全正确。
但放回整个系统里，不一定正确。
这也是我们后来越来越明显的感受：
模型知道这次让我改什么，但它并不天然知道这个项目为什么要这么设计。
如果人也没有建立完整的项目认知，那么实际上就是：
人不知道全部上下文
↓
AI 也拿不到全部上下文
↓
先完成一个局部实现
↓
后面发现和其他地方冲突
↓
继续让 AI 修改
↓
新的修改又影响其他地方
最后代码一直在变化，但真正稳定下来的东西并不多。
二、Demo 给了我们一种“已经完成很多”的错觉
项目前期我们先快速做过一个 Demo。
从页面和流程来看，当时感觉：
大部分东西好像已经有了。
流程能走。
接口也有。
状态也有。
看起来距离最终需求已经不远。
但真正开始按照正式需求往里面填东西以后才发现：
差得非常远。
Demo 最大的问题不是代码质量差，而是它的目标本来就不同。
Demo 解决的是：
这个思路能不能跑通？
正式系统解决的是：
这个东西能不能长期正确地跑？
这两者需要考虑的问题完全不一样。
但当 Demo 已经有大量代码以后，人很容易产生一种心理：
已经写了这么多了，在上面继续改最快。
于是一个本来用于验证的工程，慢慢变成了正式项目的地基。
这可能是我们前期比较大的一个误判。
三、前期设计复杂，后面所有人都在还债
原有工程里还有一个比较明显的问题：
过度设计。
实际只有六个左右主要业务步骤，但状态设计一度扩展到了三十多种，再叠加十几种信号和各种转换关系。
同时缺少足够的日志、注释和清晰的模块边界。
这导致一个很现实的问题：
AI 能继续写，但人越来越难理解。
而一旦人理解不了整体设计，就会更加依赖 AI。
于是形成另外一个循环：
代码复杂
↓
人越来越难理解
↓
更多问题交给 AI
↓
AI 基于局部上下文继续修改
↓
代码进一步复杂
所以前期我花了不少时间重新拆模块、整理状态、补日志、调整一些基础结构。
这也确实占用了大量开发时间。
但现在回头看，我依然认为这些事情需要做。
真正值得反思的不是“为什么要重构”，而是：
为什么这些基础问题没有更早解决。
四、两种开发思路发生了冲突
这个项目里还有一个对我个人影响比较大的地方。
团队里有经验非常丰富的工程师，他更倾向于：
先快速验证、快速实现，功能出来以后，再慢慢调整里面的细节。
而我的思路相对保守：
先尽量理解需求，建立基本的领域和流程设计，再开始大规模扩充业务。
其实这两种方式都不是绝对错误。
在 PoC 和探索阶段，第一种方式效率很高。
但如果一个 Demo 很快就要直接进入正式交付阶段，我现在越来越倾向于第二种：
至少先把最核心的业务流程、状态、模块边界和外部依赖弄清楚。
我自己在这件事情上也有很明显的问题。
前期我其实提出过不同意见，但对方不认同以后，我没有继续坚持。
后来因为工期等各种原因，还是选择了在原来的工程上继续修改。
现在项目走到这个阶段再回头看，这件事情对我的提醒反而比技术问题更大：
工程师不能只有判断，还要有能力把自己的判断讲清楚。
如果确实认为一个设计未来会产生很大成本，就应该把依据、风险和替代方案说明白。
最后团队选择什么方案可以讨论。
但不能因为别人暂时不认可，就直接放弃自己的判断。
五、这次 Token 为什么会消耗得这么夸张
这一周还有一个让我非常意外的数据。
仅我个人的模型调用成本，粗略统计就已经超过了 2000 美元。
这个数字确实把我自己也吓了一跳。
后来复盘，其实里面有不少消耗是可以避免的。
例如：
今天让 AI 给整个项目补日志。
明天又让它重新整理某个模块。
后天再单独做异常处理。
之后又做一次比较大的重构。
每一个任务单独来看都合理。
但每做一次大范围任务，模型都需要重新理解大量代码。
等于：
让 AI 一遍又一遍重新阅读同一个项目。
如果这些横切性的改造能够提前统一规划，比如日志、注释、异常处理、结构整理一起设计，再分阶段执行，至少可以减少很多重复理解和重复修改。
另一个更明显的问题是：
我自己对某些代码的整体设计没有完全掌握。
所以遇到问题以后，很容易直接把问题全部扔给模型。
AI 给一个方案，我执行。
发现不对，再让它调整。
再发现新的问题，再继续改。
这种使用方式表面上省掉了思考时间，实际上可能产生非常高的上下文和重构成本。
真正高效的 AI Coding，不应该是：
人负责不断提出问题，AI 负责不断修改项目。
而应该是：
人负责维护系统的整体认知和设计，AI 在明确边界内完成具体任务。
如果连人都不知道系统应该长什么样，那么 AI 再强，也很难持续做出前后一致的设计。
我现在对 Vibe Coding 的几个认识
经过这次项目，我目前比较明确的是：
Demo 可以快，但正式工程不能一直靠“先写出来再说”。
真正进入复杂业务以后，人至少需要掌握核心需求、主要流程、模块边界、状态和外部依赖。
其次，AI Coding 之前最好先建立一份项目级上下文，让模型知道项目的约束，而不是每次从一个零散问题开始重新理解。
日志、注释、异常处理、模块整理这类横切任务，也应该尽量统一规划，避免为了每个问题分别让模型大范围扫描和重构项目。
最重要的一点是：
AI 可以帮我写代码，但不能替我拥有这个系统。
最终知道为什么这样设计、哪里可以改、哪里不能动的人，还是应该是工程师自己。
写在最后
这半个月确实很累。
项目的问题、之前的客户投诉、不断赶进度，再加上大量 AI Coding，让我一度感觉大家已经非常努力了，但事情还是推进得不够快。
以前遇到这种情况，我可能首先想到：
是不是模型还不够强？
但这次我的感觉恰恰相反。
现在的模型已经足够强了。
真正限制效率的，很多时候已经是：
我们有没有把问题想明白。
需求不清楚、设计不清楚、代码没人真正掌握的时候，AI 可以让我们更快地产生代码，也可以让我们更快地产生技术债。
所以我现在越来越觉得：
Vibe Coding 最重要的能力，可能不是如何写出一个更好的 Prompt，而是工程师自己能不能保持对整个系统的理解和判断。
这可能也是这次项目到目前为止，给我最深的一次提醒。
