Vibecoding 半个月反思：AI 编程效率狂飙后，为什么人的瓶颈反而更致命

旧的规则正在崩塌，在这个范式转移的奇点，我们必须成为那个拿起锤子重塑世界的人，而不是伴随旧规则一起沦为时代的废墟。

最近半个月，我在一个体量完全达到商业级的食品安全项目里，没有亲手写过一行代码，全部使用 AI 生成。疯狂 Vibecoding 之后，有几个扎心的反思，不吐不快——再不调整，感觉人真要废了。

主要想法

• 编程工具及模型的选型问题：GLM5.2 + Claude Code
• 工作效率加倍：Claude Code 里开多个 session，同时推进多项任务
• 验证周期疯狂增长：从设计到开发、测试，AI 生成速度已经远远超过人检查验收的速度
• 软件开发流程的思考：在老流程上套新工具，是不是该对旧流程本身发起改进？
• 关于人的思考：最大卡点和最终负责的仍然是人，必须保持判断力
• 编程技术不再是最重要的护城河：懂业务的经理也能轻松跨界，实现业务到技术的落地

编程工具及模型的选型问题

• 火山引擎 Codingplan
  最开始用的是火山引擎里购买的 Codingplan，赶上 49.9 的 Pro 套餐月付优惠。主要感觉：卡、token 消耗极快，稍微大一点的任务就能把 5 小时的分配量吃完。

• DeepSeek
  接着用 DeepSeek 模型，生成质量很不错。项目里一天用量也就 10 元左右，DeepSeek 确实把大模型普惠往前推了一大步。虽然任务完整性稍差一点，但只要人多参与几次，问题基本也能解决。

• GLM
  公司买下 GLM 之后，体验完全不同。长流程执行和任务完整性上的表现都非常优秀。目前我用过最好的国内模型就是 GLM 系列。
  5.2 版本出来前还在用 5.1，但 5.2 上线这几天明显有卡顿，响应速度变慢。下午 token 消耗极快，官网说的 3 倍额度真不是吹的。
  他们自家出的 ZCode 我也深度体验过，同类长任务下 token 消耗量明显少很多。但模型卡顿导致出现过几次重连，好在还能接受。

工作效率加倍

目前仍处在 Prompt Engineering 的阶段：将模块的概要设计、数据库设计、接口文档位置交给大模型，先走 Plan 模式确认问题、制定计划，再执行 auto 模式开发。Claude Code 里开多个 session，同时进行多项任务；在验证 ZCode 期间，甚至把一部分任务分给它去并行执行。  

问题随之而来：多端开发，需要人去验证的产出量剧增，验证速度根本跟不上生成速度。而且涉及小程序的部分，还没有打通从小程序到后端的自动化验证闭环。

验证周期疯狂增长

从设计到开发、测试，AI 的生成速度已经远远把人检查验收的速度甩在身后。设计阶段产出的巨量设计稿，加上开发阶段涌出的海量代码，全都需要人工审核、验证。理论上这个环节也可以交给 AI，但必须先打通验证闭环。而距离上线，终究还缺一次人为的绝对信任。

软件开发流程的思考

目前我们仍然沿用常见的需求 – 设计 – 开发 – 测试流程，而且需求、UI 设计本身也在不断变化，这就暴露出一系列问题：

• 需求基本靠空想  
• 原型设计跳出了 mastergo，直接拿 html 出原型，这一步我觉得已经进步不少  
• 功能设计、数据库设计、接口设计在原型过程中就开始了，导致后面需要对着原型重新梳理，两次对不上  
• 开发阶段又得重新为 AI 分配模块  
• 测试阶段大量问题提到禅道，堆在手工流转里，极度拖拽节奏

整个流程就像给老马车装上了喷气引擎，效率是快了，可马车本身还是太老了。

我预想的方式应该是：

1. 整个设计过程一开始就为 AI 输出服务  
2. UI 设计直接输出可用的页面 + mock 数据的项目  
3. 在设计阶段就定好 mock 数据、接口、模块业务描述、接口逻辑描述等约束  
4. 全部约束到位后，启动 Plan 模式确认细节  
5. 再启动自动模式、subagent 模式进行开发  
6. 多个业务线开启多个会话并行推进  
7. 测试阶段直接提 issue，让 AI 自动检查问题、自动修改并提交 PR，再由人工审核决定是否合并

关于人的思考

随之而来的是全新的焦虑：

• 速度焦虑：模型越来越快，人的学习与验证速度被彻底甩开。  
• 瓶颈转移：流水线上最大的卡点，竟然成了自己。  
• Token 枷锁：现在下班的标志，几乎就是当日 token 额度耗尽。仿佛额度一空，我也就不会开发了。

但人仍然有不可替代的价值：

• 最终做决定：判定业务流程形态，裁决 AI 生成结果的有效性。  
• 最终负责：为功能上线、小程序上线、发版以及商业价值承担终极责任。  
• 最大的“Harness”还是人：每一次 Prompt 的输入，都是在给失控的 AI 注入物理世界的约束边界。  
• 在业务场景里思考，解决物理世界中的真实问题，这是我们当下绝不可替代的终极防线。

也因此，还需要死磕判断力和专注力：

• 对 AI 生成效果做判断  
• 对实际场景做判断  
• 对是否启用做判断  
• 扎根自己的业务领域，成为业务专家  
• 保持自己的精力不被外界干扰分散

编程技术不再是很深的护城河

在环境与 AI 的加持下，从没写过代码的业务经理，实际落地开发的效果已经丝毫不逊色于专业程序员。技术壁垒已不再是阻挡跨界的护城河。真正懂业务的才是 AI 时代的中坚力量——熟悉业务场景、热爱业务场景的人，才能开发出能用、好用的软件系统。就像最近比较火的张雪、董路，掌握价值锚点的人，不需要靠语法和编译错误证明自己。

旧的规则正在崩塌，我们应该做那个拿锤子的人，而不是和旧规则一起沦为废墟。
各位同行，共勉！