Vibe coding正以惊人的速度改变着软件开发的方式，让产品经理只需'说人话'就能生成可运行的代码。但企业级应用的复杂性和严谨性，让这项技术既充满诱惑又暗藏风险。本文深度剖析了如何在原型沟通、模块开发和复杂逻辑处理三个层级中合理运用vibe coding，同时避开技术债、安全合规和团队信任等致命陷阱，为传统软件公司指明了一条AI时代的转型路径。

最近圈子里全在聊 vibe coding，一开始我以为是某种行为艺术，后来上手玩了几次，说实话，挺上头的。你对着屏幕“说人话”，代码就出来了，报错了把红字一贴，它自己修，你全程不用看代码，跟导演一样。那一刻你会有种错觉：以后是不是不用开发团队了？

但作为一个在项目里泡了十来年的PM，我冷静下来之后只想说一句话：这玩意儿用到企业软件上，一半是神器，一半是毒药。关键就看你怎么用，用在哪一层。

这篇文章不打算写论文，就想跟你聊聊我眼中 vibe coding 到底能怎么嵌进传统企业软件公司的干活儿流程里，哪些坑绝对不能踩。

一、Vibe Coding 到底是个啥？我管它叫“意图直通车”

Karpathy 的原话是“你沉浸在氛围里，忘记代码的存在”。

Completely immersed in the vibe, forgetting that code even exists.

我把它翻译下：你说需求，AI 给你跑一个能动的软件，你再跟它说“不对，这里改一下”，它就接着改，直到你觉得“嗯，就是这个味儿”。你不用理解实现，只看结果。

这种“意图即代码”的范式，本质上把沟通成本打到了地板。以前你想给客户验证一个审批流的交互，得画原型、写说明、拉着 UI 和前端开两次会。现在呢？你嘴里描述着，半杯咖啡的功夫一个能点的页面就在那儿了。这对于我们这些天天被需求传递损耗折磨的人来说，简直像空调发明之前的扇子遇上了电风扇。

但电风扇能替代中央空调吗？当然不能。这就引出了企业软件的那堵墙。

二、企业软件有四根承重柱，Vibe 一下容易撞断腰

我见过太多看起来“差不多”的软件上到生产环境就变成灾难。所以别怪我们保守，是因为这行当有几个底线是命。

1. 正确性不能靠“感觉”。财务的借贷、库存的移动，这是要跟审计对账的。你不能跟财务总监说“我跑了一下，看起来账目是平的”。这需要逻辑上可证明的准确。
2. 系统不是活三年就扔。我们交付的很多系统要撑十年、十五年。你今天 vibe 出来的那堆面条代码，半年后你自己都看不懂，维护成本直接爆炸。
3. 安全合规是高压线。银行、政务、医疗，你敢把客户的生产数据贴给公有云大模型让它修bug吗？审计的时候你说“这里是AI自己发挥的，我不清楚”，饭碗就没了。
4. 集成不是玩积木。企业软件屁股后面挂着一堆老SAP、工业协议、异构数据库。AI生成的代码，独立跑跑还行，一跟这些老家伙握手，各种边界条件崩得一塌糊涂。

所以，那些喊着要用 vibe coding 颠覆企业开发的人，大概率没接过客户怒气冲冲的问责电话。我们不能把大厦盖在沙滩上。

三、我的实践：给 Vibe 划地盘，让它在该野的地方野，该收的地方收

我现在的思路很简单：分层放权，带护栏开车。一个系统从想法到交付，可靠性要求是分层的，那我们对待 vibe coding 的态度也应该分层。而且一定要“Human-in-the-loop”。

第一层：原型和方案沟通层，请尽情“Vibe”

这是我目前最爽的用法。以前和客户聊需求，最痛苦的是“你说A，他想B，画出来发现是C”。现在跟客户沟通完以后，我直接“说”给AI听，直接生成demo。第二天就可以问客户“是这个效果吗？”，客户反馈“不是，这里需要先选部门再出现人员”，我立刻说给AI改，当天反馈沟通。这种即时感把需求确认的效率提升了至少三倍，而且极大减少了理解偏差。这层不用管代码质量，它就是个一次性的沟通耗材，用完就扔，非常值。

第二层：标准化功能模块，“生成 + 精修”流水线

这是我们最近在尝试的比较狠的用法。企业软件里有一大堆高度重复的东西，比如单据表单、固定报表、基础增删改查。我们的架构师先把规范和接口契约定死，然后让初级开发甚至业务顾问用自然语言去描述“我要一个带三栏布局的采购入库单，物料编号要带出名称和规格”。AI生成的代码作为“初稿”，然后自动跑一遍静态检查、单元测试，最后由资深开发过一遍代码审查，合入主干。这等于是把 vibe 当成一个超级加速的初稿撰写器，但最终必须经过工程铁网的过滤。人始终在回路里，签字画押的永远是人。

第三层：把AI变成你的“编程搭档”

这是一种更底层的融合，我们还在尝试。团队在写复杂业务逻辑前，先在内部AI助手里把意图扔出去，看看能吐出什么。比如“这段代码要处理一个含税订单入库并触发暂估的流程，遵循我们的科目体系”，AI可能给出一个骨架和几个关键判断点。这不能直接上生产，但能帮工程师打开思路，省掉大量查文档的时间。工程师再在这个骨架上填肉、加防护、处理异常。这有点像你身边坐了一个看过全世界代码但从没在你公司干过活的天才实习生，他的活儿你不能直接交，但他提供的参考价值极大。这层的底线是：每一次意图驱动的生成，都要被审慎地质疑和验证。

四、团队也得进化：搞“双轨制”，培养会说人话的架构师

有了这些分层实践，团队结构也跟着变。我现在倾向于把资源分成两个流：

1. 探索流：由产品经理、业务顾问和少量全栈开发者组成，核心能力是快速把模糊需求转化成可交互的东西，重度使用 vibe。他们允许失败，重视速度。
2. 交付流：由资深架构师、老牌工程师组成，专注于把验证过的意图“硬化”成合格资产。他们掌握着工程规范、安全审查和最终发行权。

同时，我们内部猛推一种新能力：能把业务意图拆解成高精度提示词的人。未来最好的企业软件产品经理，不是画线框图的，而是能用精确的自然语言驱动AI产出符合领域约束的半成品，并具备审视生成物是否“靠谱”的工程直觉。这是新的基本功。

五、前面的坑与心里的话

幻觉问题还是最大的雷，你不能让AI在一个合同审批模块里自由发挥出违约责任条款。所以必须立死规矩：AI建议，人类决策，关键业务环节绝不自动执行。另外，长期依赖 vibe 会让年轻一代看不懂底层代码，技术肌肉萎缩，这就要求我们必须定期搞对抗性代码审查，把核心逻辑讲透。还有数据安全，私有化部署太贵，公有云又不敢用，这是个现实的成本门槛。

最后说点实在的担忧。真正的雷不在代码里，在人心里。我看到一种挺危险的苗头：有些老板把 vibe coding 理解成“裁员加速器”。逻辑粗暴得很——既然产品经理都能直接“说”出软件，还要那么多开发干嘛？于是开始砍人头、压成本，美其名曰拥抱AI。结果是什么？活儿没少，人少了，剩下的工程师一边加班填坑，一边还要被迫用自己不信任的工具，反馈一些不真实的提效降本数据。

这不能全怪工程师保守。换你你也抵抗——你十年积累的架构直觉、排错手感、对某个老系统“咳嗽一声就知道哪要发烧”的体感知识，突然被老板说“这玩意儿AI也能干”，还要你自己教会这个将来可能取代你的人。这是一种被背叛感，不只是技能焦虑，是尊严问题。你知道的，这些工程师可不在马斯洛金字塔的最下层。

而这种组织层面的撕裂，会让 vibe coding 引入彻底变成一场内耗。高管觉得投了AI没见产出是因为底下人抵触，工程师觉得领导被忽悠了拿兄弟们的饭碗献祭。双方越不信任，AI 用得越拧巴，代码质量越差，最后整个转型项目烂尾。圈子里不止一家公司，技术评估上明明可以用AI提效 30%，最后因为人心散了，连 5% 都没落着，反而把核心骨干气走了好几个。

但不管怎样，我坚信一件事：对于我们这些泡在行业里的传统软件公司，最大的护城河是那个“行业 know-how”——你懂会计准则，你懂供应链协同，你懂那个车间主任为什么那样排程。vibe coding 不是来炸掉你城墙的，而是帮你把城墙加高十倍的起重机。用它加速探索层，用它武装内部工具，用它辅助标准化生产，但永远不要交出工程主导权和行业判断的罗盘。

把工具用好，我们这群人会成为 AI 时代最性感的翻译官——既能听懂客户模糊的痛，又能指挥AI快速变成能动的软件，最后还能用工程的锤子把它钉进现实。这才是产品经理该干的活儿。