为什么很多真正做企业系统的人，对 “Vibe Coding” 没那么兴奋
这两年，关于 AI 编程的话题越来越像一种情绪。
每天都有人在发新的 Demo。
新的 Agent。
新的“一句话生成系统”。
新的“一个人顶十个人”。
很多视频看起来确实挺震撼。
输入一句需求。
十分钟后，一个页面出来了。
再过一会儿，数据库、接口、后台、部署也一起生成了。
如果只看这些，很容易产生一种感觉：
软件开发里最难的部分，好像已经快被解决了。
但有意思的是，真正长期做企业系统的人，很多并没有那么兴奋。
尤其是那些长期做 ERP、工单、审批、财务、供应链、客服、风控的人。
他们当然也在用 AI。
只是很少会觉得：
“以后开发基本就靠聊天了。”
因为他们知道，企业里的麻烦，很多时候根本不在代码。
前段时间看到一篇关于 “Why I Don’t Vibe Code” 的文章，里面有个观点我印象很深。
作者说：
AI 确实在消灭很多“写代码本身的摩擦”。
但企业系统里真正困难的东西，其实一直都不是这些。
这个判断我很认同。
现在很多人讨论 AI 编程，默认有一个前提：
开发的核心问题，是“代码生产效率”。
但企业现场里，大部分项目卡住的时候，通常代码都不是第一问题。
真正的问题往往是：
这个流程到底是谁负责。
这份数据到底能不能信。
这个权限到底归谁。
这个规则到底哪个版本算数。
这个异常出现以后谁来兜底。
出了错以后日志怎么追。
自动处理到什么程度必须停下来交给人。
这些东西，和模型参数关系不大。
很多没真正进过企业现场的人，会低估“组织摩擦”这件事。
他们会觉得：
既然模型已经能理解语言了，那剩下的不就是接 API 吗？
但真实情况通常不是。
举个特别常见的场景。
很多企业都想做内部知识问答。
一开始想得都很简单：
“把文档喂进去，员工提问就行。”
但真正开始做以后，问题马上就会冒出来。
制度有三个版本。
销售部和法务部用的不是同一个口径。
老系统里的附件没人知道是不是最新的。
有些资料理论上能看，但其实不能给所有人开放。
很多历史文档连整理都没整理过。
更麻烦的是：
企业内部大量知识，其实从来没有真正文档化。
它存在于：
- 老员工经验里
- 微信上
- 邮件回复里
- 工单备注里
- 某个共享盘角落里
- 某个人的脑子里
这时候你会发现：
问题根本不是“AI 会不会回答”。
问题是：
企业自己都还没真正知道，哪些知识算有效知识。
工单场景也是一样。
很多人第一次看智能客服 Demo，会觉得这事已经差不多成熟了。
因为回答确实已经挺像回事。
但真正上线的时候，难点马上会变。
比如：
退款到底谁能批。
赔付超过多少必须升级。
什么情况属于投诉。
什么情况需要保留人工记录。
什么内容不能自动回复。
什么用户属于高风险用户。
哪些系统里的状态才算最终状态。
这些东西，才是真正影响系统能不能上线的部分。
很多 AI Demo 默认世界是干净的。
但企业现场不是。
企业现场里最常见的状态，其实是：
规则不完整。
系统不一致。
数据有缺口。
流程有历史遗留。
部门之间理解不同。
真正负责的人很忙。
很多事情靠默认习惯运行。
而这些恰恰是最难“生成”的部分。
我一直觉得，现在很多关于 AI 编程的讨论，有点过于聚焦“生成能力”本身。
但企业系统长期真正痛苦的地方，其实一直是“维护”。
一个系统能跑起来，不代表它能长期运行。
很多东西，只有真的上线以后才会出现：
为什么这个月突然大量异常。
为什么大家开始绕开系统。
为什么审批越来越慢。
为什么一线不愿意用。
为什么日志没人看。
为什么知识越来越旧。
为什么模型回答开始漂移。
为什么最后又回到 Excel 和微信群。
这些问题，本质上都不是 Prompt 能解决的。
它们是组织问题。
还有一个很容易被忽略的问题：
很多经验丰富的工程师，其实是依赖“摩擦”工作的。
听起来有点反直觉。
但真做过复杂系统的人会明白。
有时候，当一个功能越来越难写，不一定是自己水平不够。
可能是在提醒你：
架构已经开始不合理了。
或者：
这个业务本身根本没被定义清楚。
以前很多人接手老系统，第一件事不是改代码。
而是花几天时间看：
为什么当年这么设计。
为什么这里不能动。
为什么这里有特殊分支。
为什么这个字段名字这么奇怪。
为什么这个流程绕了一圈。
这个过程其实很重要。
因为企业系统大量真实约束，都藏在这些“奇怪细节”里。
AI 最大的问题之一，是它会让人太快跳过“理解系统”这个阶段。
代码是生成了。
但人不一定真的理解系统了。
这件事短期看问题不大。
时间一长，维护成本会变得很重。
现在很多人喜欢说：
“以后程序员只负责提需求。”
我一直觉得这句话特别互联网。
因为真正企业里的需求，本来就不是一句完整的话。
大量需求本身就是模糊的。
甚至互相冲突。
业务部门说的“自动化”，可能只是想少填一个表。
管理层说的“提效”，可能其实是在压缩人力。
IT 说的“能做”，和安全部门理解的“能上线”，经常不是一回事。
很多时候，真正困难的工作，不是实现需求。
而是先把需求解释清楚。
所以我其实不太相信：
企业软件会完全进入一种“纯聊天开发”的时代。
AI 一定会改变开发方式。
这已经发生了。
很多重复劳动会消失。
很多基础代码没人再手写。
很多脚手架会自动生成。
很多简单系统开发成本会下降。
但复杂性不会消失。
它只是从“写代码”转移到了：
流程理解。
系统治理。
组织协同。
风险控制。
长期维护。
最后你会发现：
企业真正缺的，从来不是“能生成代码的人”。
而是：
真正理解业务现场的人。
因为问题很多时候不在模型。
问题一直都在业务现场本身。