低代码喊了这么多年从最初的表单引擎到现在的阿里低代码引擎我一直觉得有个问题没被真正回答我们到底是在追求“少写代码”还是在追求“更快地交付”这两个目标看似一致实际上指向两条完全不同的路。直到最近Vibe Coding这个概念火起来我才意识到答案其实早就藏在“速度”这两个字里了。今天不聊概念定义就聊点实在的。我自己的经历是从传统开发到重度使用低代码平台再到今年年初开始把Vibe Coding正式接入日常开发流程。这个过程里最深的体会是低代码试图帮你省掉“打字”的时间而Vibe Coding试图帮你省掉“思考怎么把想法变成代码”的时间。这两者之间的差距就是速度变成资产还是变成负债的分水岭。1. 从低代码到Vibe Coding核心逻辑发生了什么变化1.1 低代码的本质是“约束下的效率”低代码平台的底层逻辑我琢磨了很久最后总结成一句话它把编程从“自由书写”变成了“填空和连线”。你不需要关心数据库连接池怎么配不需要关心HTTP请求的序列化细节你只需要在数据源面板里选好表拖一个表格组件上去绑定字段一个CRUD页面就出来了。这种模式的好处非常明显就是确定性高。平台替你封装了80%的常见场景你在那20%的配置空间里操作出错概率低上手门槛也低。特别是阿里那套低代码引擎的设计思路把数据源面板做成核心入口本质上是在告诉你你别碰代码逻辑你只需要关心数据和组件的关系。这其实就是工业化流水线的思路把复杂的工艺拆解成标准动作让普通工人也能上手。但这种模式有个天然的天花板就是边界感太重了。你在平台框定的范围里效率极高一旦需求超出平台预设比如要做一个不规则布局的复杂交互页面或者要对接一个内部老系统的特殊鉴权协议你立刻会发现所有“便捷”都变成了“束缚”。你得去写扩展脚本、自定义插件而此时你面对的是平台自定义的那套DSL和约定学习成本比直接写代码还高。1.2 Vibe Coding的本质是“意图优先的生成式开发”Vibe Coding的走红表面上是因为AI编程工具的成熟比如Cursor、Copilot甚至更激进的Codex。但真正让它和低代码区分开来的是处理问题的角度彻底换了。低代码是“我给你工具和流程你在里面填空”。Vibe Coding是“你给我讲人话我直接生成结果”。比如你说“这个页面需要一个弹窗点击按钮后从后端拉数据填充到表单里提交后刷新列表”AI直接就把这一套链路生成的整整齐齐。你在描述意图而不是在设计流程。这也是Vibe Coding最颠覆我的地方。以前用低代码我需要理解平台的数据源面板怎么配置才能拿到数据我需要理解组件暴露了哪些事件然后去绑定逻辑。这个过程本质上还是在“翻译”——把业务需求翻译成平台听得懂的语言。但Vibe Coding近乎消灭了翻译成本你直接用自然语言描述你脑子里的画面和业务规则代码由AI去编排。1.3 从“平台定义规则”到“你定义平台”我用低代码时最憋屈的一点就是业务逻辑迁就平台规则。平台说表单校验必须在某个配置文件里写你就得去那儿写平台说这个按钮的点击事件只能触发内置动作你就无法轻易搞一个自定义的复杂联动。这种“规则先行”的模式在小项目上很爽在稍微复杂一点的真实业务场景里就变成了带着镣铐跳舞。Vibe Coding最爽的点是规则由需求动态生成而不是预先定义。我今天需要这个列表支持拖拽排序直接一句话描述清楚UI和逻辑AI会自己思考是用原生拖拽API还是引入Sortable库并生成对应的实现。我不需要预先知道技术选型技术选型是AI基于我的需求现场决策的。这里有个关键转变低代码让你成为平台规则的专家而Vibe Coding让你成为需求表达的专家。哪种能力更稀缺显然是后者。业务的微妙之处、需求的真实意图、边角场景的取舍这些才是一个开发者的核心竞争力。代码怎么写、用的什么库反而变成了次要问题。2. 速度为什么是一种资产拆解交付能力的底层公式2.1 交付速度的本质不是手速而是“反馈循环”的速度我见过很多团队把速度理解为“编码速度快”这其实是个误区。编码只是整个交付链路里最末端的一环真正的速度瓶颈往往在更上游需求澄清的速度、方案确认的速度、前后端联调的速度、问题排查的速度。传统开发里一个需求从产品经理脑子里的想法变成UI稿变成接口定义变成前后端代码变成测试用例最后上线每个环节之间都有巨大的“信息损耗”和“等待时间”。低代码解决了一部分下游问题比如后端接口定义好了前端页面生成确实快但方案设计阶段的速度没有本质提升。Vibe Coding真正提升的就是这个最上游的反馈循环。你有一个模糊的想法直接把它说给AI听AI给你一段可运行的代码你看了之后立刻发现“哦原来这个逻辑有个漏洞”或者“这个交互其实这么做更顺”然后再反馈给AI修改。几分钟内你就在想法和实现之间跑了一个完整闭环。这在以前是不可想象的。2.2 速度资产化的三个关键特征可复用、可积累、可预测光快是没用的快而不稳那是灾难是负债。我理解的速度资产必须满足三个特征。第一可复用。低代码平台最大的资产其实是它沉淀的组件库和模板。一个封装好的数据表格组件新项目里拖过来直接用省掉了重复造轮子的时间。同样的道理Vibe Coding时代的可复用资产不再是组件而是“提示词库”和“代码片段库”。我把一套验证通过的、针对“后台管理系统标准CRUD”的Vibe Coding提示词模板沉淀下来下次新项目直接套用那这个模板就是我的资产。第二可积累。速度如果换来的是堆积如山的代码债务那这种速度毫无意义。低代码平台的积累体现在业务沉淀上使用越久数据模型越完善组件越丰富。Vibe Coding的积累体现在AI辅助下的代码仓库演进上。你会持续地重写、优化、重构AI生成的代码这个过程形成的新逻辑、新库、新架构是下一次更快生成的土壤。第三可预测。这是最容易被忽视的一点。交付速度必须是可预测的才能做承诺才能排期。低代码的优势就在这平台能力边界清晰能做什么不能做什么一目了然估时相对准确。Vibe Coding还没有低代码这么成熟的可预测性因为AI生成结果有随机性。这就倒逼我建立一套规范去控制这种随机性让AI生成的代码质量和风格稳定可控后面会详细说。2.3 交付能力的新公式业务理解 × AI执行效率过去交付能力约等于开发者的编码能力现在我觉得公式变了变成了交付能力 业务理解深度 × AI工具利用效率。业务理解深度代表你能不能把一个模糊的问题定义清楚这是乘法里的“质”。AI工具利用效率代表你能不能快速把理解变成实现这是“量”。以前量受限于码字手速现在量受限于你描述需求的能力和调整AI输出的能力。这个公式有个非常重要的推论业务理解越深的人用上AI工具后的收益越大而不是相反。很多人担心程序员被AI替代恰恰搞反了。AI放大的是你已经具备的业务洞察力和架构能力而不是放大你的打字速度。一个资深架构师有了AI辅助把脑子里那些设计模式、领域模型直接用自然语言表达出来产出是惊人的。而一个只会复制粘贴代码的新手就算用上Vibe Coding也只能生成一堆表面正确、实则漏洞百出的“看起来能跑”的代码。所以我常说一句话Vibe Coding不会降低对开发者的要求反而把要求从“会写代码”提升到了“会精确描述业务并通过代码验证业务”。这个门槛对低代码时代的“配置工程师”来说其实更高了。3. 从低代码到Vibe Coding的实操迁移路线3.1 告别数据源面板从“配置API”到“生成API调用”我用低代码平台的实际体验里数据源面板是最常打交道的地方。它把后端接口返回的字段、类型、默认值、请求参数都可视化呈现你勾勾选选就完成了数据绑定。这个设计对新手友好但问题也很明显它让你停留在“消费数据”的层面无法让你理解“数据流转”的全貌。迁移到Vibe Coding后我做的第一件事就是抛弃这层抽象让AI直接生成API调用代码。比如我以前在低代码里对接一个用户列表接口需要在面板里配置URL、请求方式、参数映射然后再绑定到表格组件。现在我是这么干的// 这是我告诉AI的需求描述 // 帮我写一个用户列表页面接口是GET /api/users支持分页和搜索 // 返回结构是{ data: { list: [], total: 0 }, code: 0 }用React fetch实现 // 加载状态要有错误处理也要有风格参考Ant Design的ProTableAI生成的代码不再是“配置面板里的映射关系”而是完整的逻辑实现loading状态怎么管理、请求参数怎么序列化、列表数据怎么映射、翻页怎么触发新请求。这一步迁移的坎在哪呢坎在你需要理解微前端、状态管理、副作用处理这些在低代码模式里被隐藏的底层概念。如果你连loading和数据请求的时序关系都搞不清楚AI生成的代码你压根看不懂更不敢上线。所以我的建议是如果你决定走Vibe Coding这条路先把低代码帮你隐藏的那些基础知识补回来补齐了再看AI生成的代码就通透很多。3.2 团队协作模式的变化从“平台统一”到“AI约定”低代码时代团队协作高度依赖平台的统一性。所有人都在同一个平台上操作通过平台的权限管理、版本管理、发布流程来保证一致性。这其实是用平台强制约束了团队的秩序是对团队协作能力要求最低的模式。Vibe Coding时代团队协作的秩序则需要靠新的约定来维护。我目前团队里总结的一套打法是这样的提示词规范每个需求必须包含背景、前后端接口约定、UI风格参考、交互边界。AI生成代码的review清单只生成了静态逻辑还是包含交互有没有处理loading/error/empty状态有没有考虑权限和安全性有没有性能隐患用一套固定的review清单去检查AI代码。约定优先而不是AI自由发挥团队内部规定前端必须用项目里已经选定的组件库不许AI自己乱引一个新库后端必须遵循已有的分层架构不许AI把逻辑全堆在Controller里。这些约定要在提示词里显式声明。这里有个踩坑的教训。我之前给AI下指令时没有限制“不许引入新的依赖库”结果一个简单功能AI自作主张引入了好几个工具库代码看着很工整但实际包体膨胀构建时间拉长了近一倍。从那以后“如果现有依赖能满足需求禁止引入新依赖”成了团队里的头号提示词规范。3.3 从“表单配置”到“逻辑生成”一个真实业务模块的拆解说个我亲手做过的实际案例。公司内部有个投诉工单管理系统以前用低代码平台搭过一个V1版本就是典型的数据源面板表单组件模式建了工单表拖了几个组件配置了流程。那时候开发很快一天搞定。但后期需求变化来了客户要求工单要根据不同优先级动态路由到不同部门还要对超时未处理的工单自动提醒——这些需求在低代码平台上实现起来特别痛苦。我后来用Vibe Coding的思维重新做了V2。我直接把需求用自然语言描述给AI让它生成路由策略和提醒调度的核心逻辑代码。比如我对AI说# 需求描述给AI # 工单按优先级分流P0转给值班经理P1转给责任部门主管P2转给一线处理人 # 如果P0工单超过30分钟未接单自动升级给总监升级后超过15分钟仍未处理发企业微信通知到部门群。 # AI生成的核心代码逻辑 def route_ticket(ticket): if ticket.priority P0: assign_to(ticket, VALUABLE_MANAGER) schedule_escalation(ticket, after30min, targetDIRECTOR) schedule_notification(ticket, after30min15min, channelGROUP_NOTICE) elif ticket.priority P1: assign_to(ticket, DEPT_LEADER) else: assign_to(ticket, FRONTLINE_HANDLER)这种代码的低代码实现方式需要我在平台里配置什么路由规则、事件触发器、定时任务平台支持程度还参差不齐。Vibe Coding直接让AI生成了非常清晰的逻辑而且我让AI补充了单元测试。同一件事在低代码平台里是被平台规则死死限制住的但到了Vibe Coding变成了一次相对自由的工程实现。这个案例给我的启示是低代码适合做流程比较固定、平台边界贴近业务需求的系统而一旦需求高度动态化、逻辑复杂化Vibe Coding和AI生成代码表达力上的优势就被彻底释放出来了。低代码是“用平台固化的逻辑去适配业务”Vibe Coding是“用AI生成的代码去贴近业务”后者显然更具生命力和扩展空间。3.4 工具链配置实践从Cursor到Codex的自用方案作为一个已经跑了大半年Vibe Coding流程的人工具链的配置经验也可以聊聊。我目前的主力是Cursor加Claude模型的组合偶尔会用Codex处理一些批量重构和机械性任务。不要误会工具不是越贵越好也不是越多越好关键是找到符合自己工作节奏的组合。我个人的配置习惯是规则文件放第一优先级。在项目根目录放一份.cursor/rules文件内容明确声明了项目的技术栈、架构分层约定、禁止事项。比如“后端禁止生成Service层为空壳的代码”“所有API调用必须走统一的Request模块不能直接写fetch”。这样AI每次生成代码都会先读规则输出风格能保持高度一致。生成代码必须带上下文。我实践中的一条铁律是让AI生成代码前把依赖的接口定义、数据模型、相关文件路径全部贴给它。别指望AI能自己找到所有上下文你需要主动喂。用低代码的时候数据源面板把上下文关系可视化得明明白白而Vibe Coding时代这步必须靠人来做。如果一个小功能关联到5个文件我会把这5个文件的关键代码贴进promptAI生成的代码才真正可用。喂完上下文的AI和裸奔的AI生成质量的差距简直是云泥之别。4. 常见问题与排查技巧实录4.1 提示词写得很好但AI代码总跑偏问题出在“上下文隔离”我见过很多人抱怨Vibe Coding不靠谱说让AI生成一个弹窗结果它把整个页面都改了。这种问题的根源通常是你没有给AI界定清楚它的职责边界。我的排查经验是这样的凡是涉及“改动现有代码”的需求一定要在提示词里写清楚“只修改XXX文件其他文件不要动”。更稳妥的是直接在IDE里选中要修改的函数或者文件让AI在选中范围内生成而不是让它自由发挥。这一点跟低代码平台就很不一样低代码平台天然有边界你只能改你能看到的配置项。Vibe Coding的边界需要你明确地预设。有一次同事让AI给一个列表页加搜索功能结果AI顺手把列表数据结构也改了导致接口对不上排查了半天最后发现是没加“禁止修改数据结构”的约束。从那以后“禁止改动”清单成了必要内容。4.2 正确性焦虑如何保证AI生成代码的质量低代码平台有平台兜底逻辑配置错了会立刻报错AI生成的代码是直接产物没有兜底机制所以安全焦虑特别强。我的应对之策是双人复核加测试兜底。一是分层判断。让AI生成的代码分为两类一类是“低风险展示型代码”比如页面布局、静态组件这部分我直接看整体效果就敢用另一类是“高风险的逻辑和交互代码”比如状态流转、数据提交、认证鉴权这部分必须有明确的数据流和审查标准。二是强制要求AI生成测试。我目前的做法任何核心业务逻辑代码都要求AI同步生成对应的单元测试。在本地跑一遍测试顺便也验证一下AI代码的逻辑。这比肉眼review花的时间多但安全性提升好几个档次。一开始团队成员觉得这就是自己给自己找事后来几次线上问题都是靠测试拦截住的之后大家再也没人质疑这个环节。三是代码评审流程不能省。Vibe Coding不是免检流程。AI写完只是“初稿”合入主干前必须走人工Review。我给团队定了个规矩“用AI生成是指AI帮你写初稿而不是AI帮你做决策”Review关注的核心永远是业务正确性和架构一致性不是代码风格和语法。这些AI做得已经很好了人的精力要集中在机器不擅长的领域。4.3 老代码积累到一定程度为什么越往后越快刚开始用Vibe Coding的头一周体验感其实没那么爽。AI生成的代码经常要反复改一个简单页面来来回回改好久。但用了一个月之后速度明显起来了原因就是项目里的代码模式库越来越厚。AI是基于当前项目上下文生成代码的当项目中已经存在大量符合规范的优秀代码时AI会模仿这些风格和模式生成新代码时质量和一致性都会明显变好。这就像低代码平台的组件库一样本质上都是“积累的力量”。所以我会刻意维护一些“种子代码”比如标准的三层架构示例、统一的状态管理写法、规范的API请求封装等这些代码就像给AI的示范教材它会照着写。务必要注意种子代码质量不高AI生成的代码质量就会被拉低因为AI会在有损的范式上模仿而且模仿得又快又死板。4.4 数据安全与权限的隐性陷阱AI生成的代码经常在数据访问这个环节出问题。我遇到过AI生成的后端接口在查询时没有过滤当前用户的数据权限直接把租户ID给漏了。这种问题如果没有严格的安全审计上线就是安全事故。在低代码时代平台通常内置了完善的数据权限机制你勾选配置一下就行。到Vibe Coding这里数据权限这种非功能性需求的提示词约束变得格外重要。我现在都在团队规则文件里强制加了这么几条所有数据访问除非显式指定否则必须按当前登录用户的组织权限过滤。涉及敏感数据的日志输出必须脱敏手机号、身份证号、银行卡号一律打码。AI生成代码后必须执行一次“安全自查”在review里单独列一个安全检查项看接口是否暴露了不该暴露的字段比如密码Hash、Token、内部ID等。5. 速度变成交付能力之后组织和个人的生存法则低代码平台用得好的人有个核心能力是“熟悉平台规则”那Vibe Coding模式下什么样的人和组织能活得好我认为需要具备几种关键能力。第一是精确表达需求的能力。把所有细节都描述清楚做出正确的信息切片。这听起来简单实则是经验的体现。新人往往只说“做个登录页”资深人会补全“用modal方式做支持单点登录密码加密传输登录后跳转到上次访问页面”等关键信息。信息切片的质量直接决定AI输出质量。第二是批判性验证AI输出的能力。AI生成一段“看起来正确”的代码你怎么判断它真的是错的还是对的我的经验是去读核心逻辑分支去构造边界场景去测试异常路径。这些基本功在低代码模式里被弱化但在Vibe Coding模式下它是你的防身术。第三是快速试错重构的能力。AI生成的代码不如你意根据上下文重新调整思路再让它来一遍。这需要你对自己的系统架构目标有清晰认知知道什么是对的什么是可以妥协的。我不太喜欢那种“AI会替代程序员”的悲伤叙事。低代码出现的时候也有人说要替代程序员结果替代的只是拖拽表单和配置页面的重复劳动留下来的全是需要深度架构思维和复杂逻辑的业务。Vibe Coding这次也一样它替代的是从自然语言到代码的那层翻译工作留给你的是判断你的表达是否真的能闭环业务问题的能力。最后再分享一个我个人的小习惯。我现在遇到任何新需求都会先在脑子里或者文档里用自然语言“讲一遍”给一个虚拟听众听讲得顺畅需求就顺了。然后再把这个故事原封不动地“喂”给AI。我发现这样做的效果比直接把零散的需求丢给AI好很多因为好代码的前提是清晰的逻辑链而清晰的逻辑链从你开口讲第一句话就已经决定了。无论是低代码还是Vibe Coding决定交付质量的永远是你对业务的洞察和对自己意图的精确表达这一点换了多少工具都不会变。
