当前位置:首页>java>为什么低代码AI平台不如直接让AI写代码

为什么低代码AI平台不如直接让AI写代码

  • 2026-10-16 10:20:37
为什么低代码AI平台不如直接让AI写代码

今天想聊聊这个事情:为什么这些所谓的"低代码AI应用构建平台"、"拖拽式Agent开发工具",最后都会让你怀疑人生。

90%陷阱

先讲个故事吧,虽然不是AI领域的,但道理差不多。

2023年有个叫Coding with Dee的开发者想做移动应用。他本身是会写代码的,但不想学新语言,就选了个叫FlutterFlow的无代码平台,还挺流行的。

看了文档,刷了YouTube教程,画了wireframe,一切看起来都很美好。

做到20-30%进度的时候,他想加个挺简单合理的功能。

做不了。

平台不支持。想写个自定义组件试试,发现也跑不起来。

后来他在Reddit上看到个帖子,有个哥们经历跟他一模一样:

"项目从10%做到90%,挺顺利的。但到了最后10%,我才发现,这个平台本身只完成了90%。"

前面90%真的爽,最后10%真的很痛苦。

那个Reddit用户说:

"我们两周就能重写。"
"这差点把我们的创业公司搞黄了。"

用无代码搞了几个月,最后还是得重写。两周就能重写的东西,折腾这么久图什么。

这让我想起软件开发的一条铁律:抽象泄露定律。

Joel Spolsky说过:

"所有非平凡的抽象,在某种程度上,都是会泄露的。"

不管怎么封装,底层的问题总会以某种方式"泄露"到上层。

低代码AI平台想把LLM的复杂性封装起来,但最后你还是会撞墙:

要么平台不支持你要的功能,要么生成的代码你看不懂也维护不了。

代码一团糟

很多低代码AI平台都说可以"导出代码"。

但你真的导出过吗?

那个Coding with Dee把他FlutterFlow的代码下载下来后,说了句话:

"那个代码库太糟糕了,简直是一团糟。说它是意大利面条式代码都算是轻的。"

他甚至都不会Flutter,但看代码就能看出问题:

"错误太多了...看起来就不对劲。"

这不叫代码,这叫意大利面,也不叫工程,叫灾难。

你想想那些可视化的节点、工作流,底层生成的是什么代码?没人知道。

或者更准确说,知道的人都不敢看。

因为一旦看了,你会意识到:几个月拖拖拽拽,最后生成了一坨没人能维护的屎。

关键是"维护"这两个字。

低代码平台告诉你"能导出代码",但没告诉你:

导出的代码没人能看懂,出了bug你不知道怎么修,要加功能你不如直接重写。

"拥有代码"和"控制代码"是两回事,你想要的是后者。

调试很痛苦

API key失效后,提交工单,对话24次,没人回。

最惨的是什么?他连日志在哪都不知道,连怎么调试都不知道。

唯一能做的就是改个参数,重新部署,看结果不对,再改,再部署...

这哪是在开发,就是在赌博。

Pragmatic Engineer分享过一个真实案例。

有个初创公司用了Devin($500/月的自主AI代理),结果:

"它引入了个bug,还多花了我们$700,因为有600万次透传事件。"

花了,引入,还多花了700。

我要澄清一下:Devin也在写代码。

它失败的原因不是"不写代码",而是你失去了对代码的控制权。

你看不到它的思考过程,无法调试它的中间步骤,不知道它为什么引入bug。

这就是黑盒化的代价。

低代码AI平台和自主AI Agent,本质上都在做同一件事:把复杂性藏在黑盒里,让你用"简单"换取"控制"。

软件开发的核心就是应对复杂性。你放弃了复杂性,也就放弃了应对问题的能力。

抽象的讽刺

有个低代码AI平台做了个挺有意思的事情:把LangChain从代码库里移除了。

Medium上有篇文章说得很直白:

"这个平台已经移除了LangChain,因为'拖慢了平台开发'。"

看起来是好事?不,这是讽刺。

连做低代码平台的,都嫌LangChain的抽象"太重"、"太复杂"。

但他们反手做了什么?造了个更大、更封闭、更不可控的抽象——这个平台本身——然后卖给你。

这像什么?

就像一个人说:"这个工具箱太重了,所以我造了个集装箱,把你和工具箱都装进去。"

你不仅失去了工具箱,连自己都关进去了。

Octomind写了篇博客,《为什么我们不再使用LangChain》。

他们说的是:

"LangChain帮我们早期快速启动,但长远来看,我们本来应该做得更好...
它不稳定,接口频繁变更,文档经常过时,抽象过度复杂。"

这些批评,对那些试图"封装一切"的低代码AI平台同样适用。

Reddit上有人问:"为什么开发者正在远离LangChain?"

高赞回答只有一句话:

"抽象过度复杂。"

抽象本身不是坏事,过度抽象是灾难。

你在某个平台的节点里想塞自定义逻辑,你会发现:这个节点只支持A、B、C。你要的D操作?抱歉,等下个版本吧。

或者你去改源码?那还不如直接写代码。

看起来在开发,其实在配置

低代码AI平台的宣传语是什么?

"零门槛"、"无需编程"、"快速搭建"。

真相呢?

你放弃了控制权,换来的只是"初期看起来很快"。

看起来你在"开发",实际上你只是在"配置"。

配置和开发的区别是什么?

配置就是在预设选项里选A、B、C,开发是当A、B、C都不满足时,你能创造D。

开发是掌控,配置是赌博。

无代码平台的通病:

  • • 有用户说"这个平台本身只完成了90%"
  • • 导出的代码"说它是意大利面条式代码都算是轻的"
  • • 专业开发者说"我们两周就能重写"
  • • "这差点搞垮了我们的创业公司"

真实世界的AI工具使用情况(Pragmatic Engineer调研的):

AI工具初创公司:

  • • Anthropic 90%的Claude Code产品用Claude Code写
  • • Windsurf 95%的代码用AI写
  • • Cursor 40-50%

大厂:

  • • Google的SRE准备应对10倍代码量
  • • Amazon内部几乎全用Amazon Q Developer Pro
  • • 有人吐槽说"到处都在用生成式AI工具,因为这样才能拿到投资"

看出来了吗?

成功的公司都在用AI辅助写代码,而不是用平台替代代码。

Anthropic、Google、Amazon,哪个在用低代码AI平台?一个都没有。

风险与挑战

黑盒平台最大的问题,是你不知道它什么时候会坑你。

API key失效、内存泄漏、代码是一团乱麻...

这些问题在你自己的代码里,5分钟能定位到。在可视化平台里,5天都不一定解决。

商业上的风险也得考虑。

你用某个平台做了个产品,客户觉得不错。但有一天,平台改了API,你的工作流跑不起来了。

你怎么办?

改工作流?但原来的逻辑你自己都不记得了。

重写?那不如一开始就用代码。

还有人才风险。

新来的工程师不懂这个平台,他得花时间学习平台的"概念"和"操作"。

但这些"概念",其实就是代码里的if-else、for循环。

他在学什么?

在学一个只有这个平台用的"方言"。

有个平台用户说:

"我开始学习Flutter,只是为了理解平台生成的代码。"

为了理解平台的代码,最后还是得学真正的代码。

那为什么不一开始就走正道?

不同的人不同的建议

对不同的人,我的建议不一样。

如果你是AI创业者,别碰这类低代码AI平台。

Pragmatic Engineer采访了那么多公司,发现个规律:成功的AI公司都在用AI辅助写代码,而不是用平台替代代码。

你需要快速迭代、深度定制、极致性能。

拥有源码控制权才是你的护城河。

如果你是传统企业的CTO,可以用低代码AI平台做POC(概念验证)。

可以用低代码AI平台做POC(概念验证)。

但记住那个用户的教训:

"到了最后10%,我意识到这个平台本身只完成了90%。"

POC之后,请立即迁移到代码,否则技术债会压垮你的团队。

如果你是个人开发者,学习某个平台的使用,不如学习提示词工程和基本的LLM调用。

学习某个平台的使用,不如学习提示词工程和基本的LLM调用。

前者是"怎么用这个工具",后者是"怎么解决问题"。

工具会变,思维不会。

就像Coding with Dee最后说的:

"我不想学新编程语言。"
"但最后还是学了,为了理解平台生成的代码。"

你绕了一大圈,最后还是得回来。

那为什么不一开始就走正道?

最后想说的话

AI是工具,不是替代品。代码是手段,控制是目的。

好的工具应该让你忘记它的存在。

低代码AI平台让你记住的,是它自己的存在。Vercel AI SDK让你忘记的,是它自己的存在。Claude Code让Anthropic工程师每天都用。

区别不在于"写不写代码",而在于"拥不拥有控制权"。

低代码平台让你你不写代码就能搭建应用,但拿走了控制权。AI变成能让你不写代码就能开发应用,也能让你保留控制权。

社会上有坏人啊。

他们想让你相信,只要用他们的平台,你就能"零门槛"开发AI应用。

真正用过的人都知道:无代码开发是个陷阱,我掉进这个陷阱,损失惨重。

别信那些漂亮的界面,别信那些花哨的宣传。

信代码,信你自己。


谢谢你看到这里, 如果你对低代码平台有想法和我讨论,欢迎在评论区分享。

我是正在努力Vibe Coding的AI君,我们下次见!

最新文章

随机文章