人定需求、和 AI对峙把需求逼完整、AI 实现、人验收——这不是"让 AI 写代码"，是工程师在项目里换了一个站位。
同一个需求，两种一天
先不讲道理。同一个需求，两种思维下的一天，长这样：
古法的一天
需求：可拖拽排序、实时小计、支持撤销的明细表格
- 上午：搜 "React DnD vs dnd-kit"，翻 8 篇对比，看 3 个 demo 源码
- 中午：决定用 dnd-kit，通读 API 文档
- 下午：卡在 useSortable 的 transform，翻 issue 到第 4 页
- 下班：能拖了，撤销没做。明天继续
vibe 的一天
同一个需求
- 上午：把需求和边界讲清楚，让 AI 先追问、再出一版
- 3 分钟：能跑的版本出来了
- 一小时 review：发现拖拽没边界、撤销没深拷贝、小计丢精度
- 逐条反馈。下午两点：上测试环境
注意两边的差别不在"快慢"，而在精力花在了哪：左边耗在"实现"，右边耗在"定义问题"和"把关质量"。而这两端，恰恰是决定一个项目成败的、工程师最不可替代的部分。
这个差别背后，是一整套角色分工的变化。
思维的几处迁徙
把两种思维摊开逐项对比——差异比想象的更系统，是整套心智模型。
古法编程 | vibecoding | |
|---|---|---|
我的产物 | 代码本身——每一行都是我敲的 | 判断——需求拆解、方案审查、质量把关 |
启动条件 | 代码本身——每一行都是我敲的 | 描述清意图就动手，边跑边想 |
面对不确定 | 先查文档、读源码、写小 demo | 和 AI 对峙着把问题问清楚，再看产出 |
解决问题 | 定位 → 读源码 → 懂机制 → 改 | 描述现象 → AI 并行探查 → review → 决策 |
学习路径 | 系统学完一门，再上手做 | 边做边补，用到才深学 |
价值锚点 | 我写了多少优雅代码 / 多懂原理 | 我多快验证了想法 / 解决了多少问题 |
所有这些差异，收拢成一句话：人在项目里的位置变了。下面这张图，就是新位置的精确长相。
人与 AI 的角色闭环
这是整篇文章的脊柱——也是 vibecoding 真正的"主思想"。
验收发现问题，回到「对峙 / 实现」，闭环迭代
清楚人在这个闭环里的站位：两端的定向与验收，和中间那个关键的对峙点，都在人手里；中间那段最耗精力、最不产生判断价值的实现，交给了 AI。
人没有失去对产出的控制——验收权始终在自己手里。人只是不再亲手生产每一行代码，把省下来的脑力，全部还给了需求和质量的把关。而这两端，恰恰是工程师真正不可替代的部分。
所以 vibecoding 的本质，不是"让 AI 写代码"，而是"人退到闭环的两端和关键中点，把判断力用在刀刃上"。AI 占据的，只是中间那段执行。
核心：和 AI「对峙」，才能把需求逼完整
整个闭环里，最被低估、也最值钱的一步，是第②步。
很多人理解的 vibe 编程是"我说需求 → AI 写代码"。但真正拉开差距的，是动手写之前的那场对峙。
为什么是"对峙"，不是"配合"？因为需求最危险的地方，不是你写错了，而是你以为自己想清楚了——直到你要把它讲给一个会追问的对象听。
AI 在这一步扮演的角色，根本不是执行者，而是一个不知疲倦的、会反复追问"那如果……呢？"的业务陪练。它不会顺着你，它会质疑你的假设、补全你的盲区、戳穿你的想当然；它的知识面比你广，能从你没想到的角度切入。
// 一场真实的需求对峙（节选） 人 我要一个报价单明细，行可拖拽排序，改数量实时算小计。 AI 数量允许小数吗？比如 0.5 吨这种"半批"。小计精度保留几位？金额四舍五入用哪种规则？ 人 呃……整数为主，但确实有半批。保留 2 位，银行家舍入。 AI 排序后，别处引用的行号要不要同步更新？撤销是单步还是整批？多人同时改怎么合并冲突？ 人 这些我之前真没想过。这场对峙的产物，是一份边界清晰、case 齐全的需求——它的价值，远大于 AI 之后写的任何一行代码。因为绝大多数项目的返工，根本不在代码，而在"需求一开始就没想清楚"。
传统流程里，这个"对峙"的角色由产品经理、测试、同事的评审来扮演，约一次会要等三天。现在，你随时可以拉起一个。这是 vibecoding 给工程师最被低估的礼物。
内心 OS 的变化
最诚实的转变信号，是脑子里那个声音变了。
// 古法思维下，脑子里的声音： "useCallback 的依赖数组加不加 setState？想清楚再写。" "这个库没读过源码，先花两天过一遍再用。" "架构没想完美不能动手，动手就要返工。" // vibecoding 思维下，声音变成了： "先把需求和边界跟 AI 吵清楚，比急着写代码重要。" "两个方案拿不准？让 AI 各实现一遍，我对比着选。" "我先看结果对不对、边界稳不稳，原理待会再深究。"最关键的转变：从"想清楚才能动"到"和 AI 对峙着把它想清楚"。"想清楚"不再是动手的前提，而变成了一个可以借助外力去推进的过程。
这套站位，带给我的五样东西
不谈玄学，只谈这一年多我真切感受到的、可被复盘的好处——每一条都挂在上面那个闭环上。
精力从"实现"转向真正稀缺的东西
"定义问题"和"把关质量"这两端，才是决定项目成败的。把中间那段实现外包给 AI 之后，我终于把最稀缺的脑力，用在了最关键的地方。同样是 8 小时，驾驭的项目复杂度是以前的几倍。
"对峙"在动手前就排掉了大部分需求雷
以前是写完才发现需求理解错，返工一整天；现在是动手前就和 AI 吵清楚边界，返工骤减。需求对了，AI 的实现质量自然就上去了——大多数 bug，在需求阶段就已经不存在了。
执行段交给了一个永不疲倦、不挑活的队伍
样板代码、CRUD、调样式、查 API——这些把人磨没心气的活，交给了一个没有状态起伏、不会累、最不抱怨的执行者。把枯燥腾出去之后，我重新爱上了编程，只留下设计交互、定架构、解难题这些真正有意思的部分。
从"线性死磕"到"并行编排"
以前一个问题只能一条线磨，周末耗在一个 bug 上是常态。现在可以让 AI 分头探路：A 查根因、B 试方案一、C 试方案二。我是决策节点，不再是执行瓶颈，探索带宽被成倍放大。
验收权始终在我手里，我没有失控
vibecoding 不是把代码交给 AI 就撒手，是"知道什么该交、什么该自己把"。控制感一点没少，我只是不再亲手生产每一行——这个心态的转变，治好了我多年的"启动困难"和完美主义拖延。
但古法，没有白练
这段是我最想说的——也是这篇文章最反"营销味"的地方。
———————————————————————————————————————————
古法不是被淘汰了，它下沉成了你在闭环两端的判断力底座。
回到那个闭环：你在「对峙」时问得出对的问题、在「验收」时看得见 AI 埋的雷——靠的都是古法攒下来的内功。你越懂原理，对峙就越准、AI 越不跑偏；你越有品味，验收就越狠、屎山逃不过你的眼。
那些年敲过的每一行、读过的每页源码、踩过的每个坑，没有一样白费——它们只是从"你的产出方式"，变成了"你指挥与审查的能力"。
古法 = 判断力底座 × vibe = 放大判断力的杠杆 → 先有底座，再上杠杆 ！！！
———————————————————————————————————————————
所以有个不太好听但必须说的实话：新手直接 vibecoding 是危险的。没有古法底座，你对峙时问不到点子上、验收时看不出问题，AI 写一坨屎山你都尝不出味道。vibecoding 的门槛不在工具，在你脑子里那把古法淬出来的尺子。
什么时候，我会切回古法
诚实地说，这些场景我仍然老老实实亲手写、亲手读——不是不信 AI，是不敢把判断权交出去。
核心算法 / 性能关键路径AI 常给"能跑但不够优"的实现，热点代码还是得自己抠每一行。
安全敏感逻辑鉴权、加解密、权限校验——AI 一个想当然的边界，就是一个漏洞。
需要深度原理理解的部分你自己都不真懂，就 review 不住，雷埋下去根本看不见。
生产环境的危险操作删数据、改 schema、做迁移——这些必须人脑一步步走一遍。
vibecoding 和古法不是替代关系，是在不同任务上随时切换的两只手。而这个"知道何时切换"的判断，同样来自古法。
———————————————————————————————————————————
vibecoding 的真义，从来不是"让 AI 写代码"。
是人站在闭环的两端——定向与验收——和关键的中点对峙上，把判断力用到了刀刃；而中间那段最不创造判断价值的执行，交给了 AI。
键盘还是那把键盘，控制权一直在自己手里。
变的是：我把最稀缺的脑力，还给了工程师真正不可替代的那部分。
