考察点
这道题看的是工程判断力，面试官不喜欢两种极端答案：一味贬低低代码的「技术洁癖」，或者觉得低代码包打天下的「跟风派」。好的回答要能讲清楚这类平台真实的价值场景和硬性边界，以及从低代码迁移到代码框架的触发条件。追问常往「迁移成本多大」「低代码应用怎么做质量保障」走。
参考答案
这类平台是什么
扣子（Coze）是字节跳动的 bot 搭建平台：可视化编排 workflow、插件市场、知识库、消息卡片，搭好一键发布到飞书、微信等渠道。同类还有开源的 Dify、FastGPT，以及更偏自动化的 n8n。共同特点是把 prompt、工具、流程都变成画布上的节点，非工程师拖拖拽拽也能搭出能跑的东西。理解它们的定位，要先承认一个事实：它们服务的核心用户不是工程师，而是「想把一个 AI 想法快速变成可用产品」的人。
真实优势
低代码平台最大的优势是验证速度，这一点被工程师群体普遍低估。半天时间搭出一个能用的 demo 给业务方看，快速确认「这件事值不值得做」，能避免大量「写了一个月代码发现需求是错的」的悲剧。其次是基建现成：IM 渠道接入、文档解析切片、插件市场，自己搭一套要几周，平台上是勾选的事。第三是协作门槛低，运营和产品可以直接进画布改 prompt、调流程，不用走代码评审和发版，对运营活动类场景这是刚需。对内部工具、POC 验证、短周期运营活动，低代码是正确选择，用代码框架反而是过度工程。
边界和代价
短板同样明显，而且是结构性的，不是靠平台迭代能轻易补上的。
复杂控制流表达力差。条件嵌套、循环、异常分支、动态工具选择，在画布上很快就变成一坨没人看得懂的面条图。代码至今仍是表达复杂逻辑的最优抽象，画布不是——画布在「节点少、线性流」时是优势，超过那个复杂度拐点就变成负债。
工程化缺失。应用配置存在平台里，没有 code review、没有 diff、没有版本回滚，质量保障基本靠手点。多人同时改一个 workflow 互相覆盖是常态。这些东西在代码世界里是几十年沉淀下来的基础设施，低代码平台要么没有，要么是简化版。
黑盒与锁定。模型怎么调、prompt 最终怎么拼、检索怎么切分，用户不完全可控，出了问题没法深挖；数据和逻辑绑定在平台上，想导出迁移基本等于重写。成本和性能也不透明：节点粒度的 token 消耗看不细，高并发时受平台配额卡脖子。
一句话总结我的看法：低代码平台适合「流程短、变化快、生命周期短」的应用；核心业务、复杂逻辑、需要长期演进的项目，画布迟早成为瓶颈。
怎么选
我的判断维度有四个：流程复杂度——条件和循环嵌套超过两三层就上代码；工程要求——需要版本管理、自动化测试、灰度发布的，上代码；生命周期——活动页性质用低代码，长期产品用代码；团队构成——没有专职工程师的团队，低代码可能是唯一选项。
务实的路线是混合打法：先用低代码快速验证需求，验证成立、逻辑变复杂之后，用 LangGraph 这类代码框架重写核心链路，低代码继续承担运营侧的简单机器人，两者长期共存。Dify 这类开源平台介于中间：可以私有化部署、能导出配置、有 API，缓解了锁定问题，但深度定制时一样会撞到框架自身的抽象边界。
迁移的信号
什么时候必须把低代码重写成代码？几个明确的信号：流程图已经复杂到没人能看懂了；需要接入内部权限和审计体系；出现线上问题却无法定位根因；业务量上来后平台配额或成本顶不住了。出现任意一条，就该启动重写，而且越早重写成本越低。
可能的追问
- 低代码平台上的应用怎么做质量保障？ 平台自带测试能力弱，可以外挂：把 bot 的 API 当黑盒，维护一套问答 eval 集，每次改完画布跑一遍回归。
- 低代码会取代 Agent 工程师吗？ 它吃掉的是简单问答式 bot 的搭建工作；复杂 agent 的难点在上下文工程、评估体系和稳定性，这些反而更需要工程能力。
- Dify 私有化部署是不是就没锁定问题了？ 缓解了数据和可用性的锁定，但你的流程仍然长在它的抽象模型里，深度定制超出框架边界时迁移成本依然在。