先把结论甩出来,省得你往下翻:验证想法、做内部小工具、给非技术同事造个能问答的小助手——零代码;要接复杂业务逻辑、改数据库、多服务编排、对响应时延和并发有要求——老老实实写代码。 临界点也很清楚:当你发现自己开始跟低代码平台"斗智斗勇",为了绕一个它不支持的逻辑而拼三四个节点的时候,就该切回 IDE 了。

下面这张表是我自己踩下来的判断,不是抄文档的:

一个真事:我用零代码搭了个"报销政策小助手"

上个月财务那边烦死了,同一个问题一天被问八遍——"打车能不能报""发票抬头写哪个"。我本来想用 Python 撸一个,拉 FastAPI、接向量库、写召回逻辑,脑子里过了一遍流程图,光环境就够我磨一下午。

后来换了个思路。找了个零代码就能配智能体的平台,把财务那份 47 页的报销制度 PDF 传上去,挂个现成的大模型,知识库那栏点几下开了 RAG,发布成飞书机器人。整个过程我没写一行代码,前后大概一个半小时,其中有四十分钟是在等那份 PDF 解析切片。

说实话我当时有点意外的是召回质量。我故意刁难它:"我打车去机场赶飞机,这个能报吗?"——它真就把"差旅交通"和"市内交通"两条政策都拎出来了,还点明了金额上限。第一版我还嫌它答得太干,像在念条文,后来在提示词里加了句"用大白话解释,别直接背制度",语气立马顺了。

它的边界,我也吃过亏

别被我上面说得太美。那个小助手能干的,基本就是"基于文档答个问"这类杂活。我后来想给它加个功能——查到某条政策时顺手调财务系统的接口、把当月已报销额度也带出来。配到一半就卡住了,平台的函数调用节点对鉴权那块支持得很勉强,我拼了俩节点还是不对,折腾半小时果断放弃。

这就是切代码的信号。 凡是涉及"读写业务数据库、串多个内部服务、逻辑分支超过三层",零代码平台就开始变成束缚。你花在"哄平台听话"上的时间,够你自己写完了。

还有个隐性成本:学习曲线。别信"零基础五分钟上手"。零代码不等于零理解——RAG 的分块大小、提示词怎么写、模型选哪个,这些概念你还是得懂,不然搭出来的小助手答得驴唇不对马嘴,你都不知道是知识库的锅还是提示词的锅。我第一版切片设了 512 token,长表格被切碎,召回一塌糊涂,调到 1024 才好。

我现在的分工

简单说,我把它当草稿和杂活外包。要快速给老板演示一个 AI 想法、给某个部门搭个内部问答助手、验证"这个场景到底值不值得做",我先零代码捏一个出来跑跑看。跑通了、确认有价值、又确实需要深度逻辑,再决定要不要正经写代码重做一版。

很多需求,捏完那一版你就发现根本不用上代码了——它已经够用。这才是零代码最香的地方:帮你把"要不要写代码"这个决策本身的成本打下来了。

(模型这块我直接走了讯飞星辰 MaaS,现成 API 调,没自己部署算力,省了搭模型服务的活)

你们团队那些重复问答、政策查询的活,有没有也适合先捏个小助手顶上的?评论区聊聊你卡在哪一步,我帮你看看是该零代码还是该上代码。