场景单一、源码受限，秒哒如何继续“狂飙”？

撰文 | 曹双涛

编辑 | 杨 勇

题图 | IC Photo

自2024年11月百度世界大会上秒哒首次亮相，并率先提出“多智能体协同”概念后，2025年秒哒迎来加速发展期。

3月24日正式上线的秒哒，凭借“无代码”特性，上线首日吸引超2万用户体验，创建应用数量突破3万个。截至目前仅一个季度，秒哒生成的应用数已突破20万个。2025年世界人工智能大会上，秒哒再度成为行业关注的焦点。

百度加速布局秒哒，背后正是看中低代码/无代码赛道的强劲增长势能。《财富商业洞察》数据显示，2025年全球低代码/无代码应用平台市场价值将攀升至295亿英镑，2032年更将飙升至2085亿英镑，复合年增长率高达32.2%。

同时，低代码/无代码也为互联网企业开辟了新的盈利空间。以云服务领域为例，长期以来因客户迁移成本低，行业深陷价格战泥潭；百度通过秒哒，能同时实现客户新增和留存。且日活作为互联网企业竞争的核心指标，用户通过平台发布的应用越多，越能带动搜索、文库、地图等生态业务的流量增长，进而推动营收增长。

但横亘在秒哒面前的核心矛盾显而易见：平台开发能力仅能支撑简单场景，与多行业业务复杂化的趋势形成尖锐冲突；而源码受限带来的盈利路径收窄、数据隐私安全引发的企业顾虑，更是其突破市场的深层阻碍。想要真正分享行业红利，秒哒显然还有很长的路要走。

一、实测能力短板显著

为精准测试工具边界，我们要求秒哒与GPT同场景竞技——为安徽省高二数学老师生成匹配考情的试卷。对比结果显示，二者差距较大：

• 在题型规范上，GPT生成的试卷严格遵循高中数学试卷题型体系（单选、多选、填空、解答题）与分值梯度。而秒哒后台不仅冗余保留“计算题”等过时题型，核心6道解答题更无法按难度差异化赋分，背离高中考情逻辑，暴露对题型规范的基础认知缺失。

图源：基于公开信息整理 DoNews制图

图源：GPT生成试卷

图源：秒哒官网

• 在知识适配上，核心考点，是高二数学试卷的“必考点”。GPT生成的试卷整体符合高二核心考点（函数性质、导数、数列、立体几何等），仅存在个别题型超标。秒哒则堪称“翻车”：选择题不仅只有函数值代入计算，且将填空题混到选择题中（第9题、10题）；填空题停留在小学加法，初中解方程阶段；证明题、解答题反复堆砌初中算术几何不等式，甚至连最基础的三角函数、数列综合题都未涉及。整张试卷知识体系退化成初中数学“复习册”，与实际教学场景重度脱节。

图源：秒哒官网

• 在功能完整度上，秒哒陷入“错误循环”：填空题第3题正确答案为方程组无解，但仍强行罗列错误计算过程，无纠错逻辑。重复生成试卷时，题型重复、知识点缺失等问题持续上演 ，甚至出现3道证明题完全相同的离谱错误，暴露其题库内容与高中数学要求严重脱节，更无法支撑“试卷自动生成”的教学功能。

图源：秒哒官网（二次生产试卷）

从题型规范到知识适配，秒哒的表现连“符合高中考情”的基础要求都无法满足。这种差距，本质是对垂直场景需求理解能力和知识体系覆盖能力的全面不足——当GPT能服务教学场景时，秒哒还停留在“生成小学初中题凑数”的低水平循环，距离支撑真实教育需求，仍有巨大鸿沟。

测试试卷后，为进一步测试工具在功能性开发场景的表现，我们提升难度，让秒哒开发答题小程序：5个前端页面，以及支撑运行的7大后端板块。或许因需求复杂，秒哒直接反馈“应用生成失败”，连基础开发的“入场券”都没拿到。

图源：DoNews

图源：秒哒官网

测试小程序后，为验证其在复杂业务场景的落地能力，我们再次升级测试，要求秒哒开发OTA机票全流程场景：前端包括搜索展示、价格优惠、返现及关联服务推荐等，后端须匹配用户身份管理、航空信息服务、支付订单处理等多模块，以形成业务闭环。但秒哒暴露出多重问题：

图源：机票场景前端需求

图源：机票场景后端需求

一是前后端脱节：秒哒未按要求生成对应的后端页面，提示建议寻求专业的后端开发支持。但OTA机票场景中，前端的交互操作与后端的模块功能是深度绑定的——前端页面的每一项展示与操作，都依赖后端模块提供的数据与逻辑支撑。缺少对应的后端实现，前端便成了无数据支撑的空架子，整个业务场景无法落地进行。

图源：秒哒官网

二是核心接口缺少：航班时刻、座位库存、票价信息及退改签规则等核心数据，由航司牢牢掌控。OTA 平台若要实现出票功能，必须获取航司的数据授权接口。

但或许和百度航司机票接口受限有关，点击“热门航线”的机票时，无法跳转到对应二级页面；同理，查询航班时也因缺乏数据接口支持，无法获取并展示航班时刻详细信息。

点击“热门航线”功能时无法完成二级跳转；同理，航班数据也因缺乏接口支持，同样无法实现二级跳转，整个业务流程被中断。

图源：秒哒官网

三是交互页面仍需优化：秒哒初始配置为白色界面，导致出发/到达城市、舱位类型等关键信息被遮挡，需手动调整才能完整显示；航班查询、我的订单等核心功能仅能通过对话形式修改，操作路径繁琐且不符合常规逻辑，无疑增加小白用户的使用门槛。

图源：秒哒官网

图源：秒哒官网

图源：秒哒官网

综合来看，从基础内容生成到功能性开发，再到复杂业务闭环搭建，秒哒在梯度测试中暴露出的题型适配偏差、功能开发断层、前后端协同失效等问题，不仅印证了其在垂直场景理解与落地能力上的短板，更清晰划定当前工具的能力边界——距离支撑真实业务需求，仍有难以跨越的鸿沟。

二、复杂性和定制化场景如何满足？

“当前低代码/无代码工具的能力边界，在多场景测试与行业实践中已清晰显现：其仅能适配业务逻辑简单、无需复杂集成的基础场景，难以应对企业日益复杂的定制化需求，这种能力与需求的错位成为行业共性难题。”国内某大厂技术总监李磊（化名）对我们说道。

李磊表示，虽然秒哒应用广场的站点、H5、问卷、小游戏、小工具场景不同，但技术层面却高度趋同：均以“简单逻辑”为核心——数据结构清晰且变化较少，无需复杂的系统集成，交互页面多为信息展示或简单跳转，相对简单。

图源：秒哒官网

比如，社区便民服务本质上是“菜单+信息展示+链接跳转”的模式；小游戏为预设模板，不存在复杂的动态逻辑；邀请函或报名类应用，核心是表单收集与结果展示；读书App、旅行博客等以内容展示为主，交互设计较为简单。

且这类场景不涉及如返现、实名认证、支付系统等复杂接口，因此能实现低成本、快速上线，但也暴露出工具的局限性。

比如，支付系统不仅需要对接支付网关、保障交易安全、处理支付成功后的回调，还需要后端完成用户订单生成、金额校验、退款、异步回调等一系列操作，整体复杂度极高。产品经理若要求用户支付时，增加分期支付、先用后付等功能，系统复杂程度更是飙升。

更关键的是，低代码/无代码多聚焦在前端页面生成，后端能力整体薄弱。比如，秒哒生成的婚纱摄影网站后端，仅支持图片/视频上传、对应文案编辑、内容上下线及展示层级调整等基础操作。这种即插即用的后端服务，虽能让用户聚焦在前端功能和用户体验的打造上，但侧面反映出其难以支撑复杂业务逻辑的局限。

图源：秒哒官网

与之形成尖锐对比的是，业务场景的高度定制化、复杂化已成为横跨互联网、快消、金融、医药等多领域的不可逆趋势。

在电商双11/618等大型活动中，用户诟病的复杂优惠计算逻辑，不仅需开发人员横跨多个系统和数据源实现逻辑，编写大量自定义代码。更需开发人员提前为服务器扩容，以应对大型活动用户访问量激增可能引发的页面加载迟缓、响应时间延长、资源利用率偏低等问题。

低代码/无代码的平台存在的灵活性不足、集成能力薄弱、无法满足复杂业务逻辑等问题，无疑制约着其在中大型互联网企业中的付费率。

再比如，快消品行业东鹏的数字化体系，更是深度绑定行业特性——厂家业务员通过系统跑单下单，经销商按单配送，系统不仅记录订单信息，更将业务员、经销商的操作与业绩、奖惩直接挂钩，形成一套严格的“做假即追溯”的业绩追踪与问责机制。

厂家业务员通过小程序签署陈列协议，适配便利店、商超等多终端标准。兑奖体系按区域、渠道差异化设计：外地中奖本地不兑、连锁CVS渠道为复购红包版、自动售货机渠道为无奖版本、电商直播间同时融合无奖版本和有奖版本。整套系统围绕防窜货、稳定价盘以及适配渠道特性设计，绝非通用低代码/无代码平台的标准化模块可承载。

这种能力短板不仅出现在国内平台，而是全球行业共性。Devum在构建物流系统时，因需集成多第三方系统，面临接口兼容与数据同步难题；Jadu在为政府构建在线账户系统时，如何满足大量市民的个性化需求成为难题；Etty Blocks在服务企业客户时，因标准组件无法适配高度定制化需求，暴露可扩展性不足的问题。

对标SaaS、云服务等大量TOB行业来看，中大型企业才是高营收的核心来源。但低代码/无代码平台既无法满足其复杂需求，又因C端及小型企业付费能力有限而陷入困境。这种“简单场景支撑不起高价值，复杂场景又无力承接”的现状，凸显了低代码/无代码工具在当前阶段的能力瓶颈。

三、数据安全与监管，难以回避的刚性挑战

低代码/无代码平台因能力边界与企业复杂需求的错位而陷入行业性困境后，其在TOB 商业化进程中面临的挑战远不止于此——底层技术控制权的缺失，进一步加剧了这类平台与企业核心诉求的冲突。

正如国内某互联网大厂安卓开发总监刘杨（化名）所言，这种矛盾可以通过一个生动的比喻具象化：低代码/无代码平台确实能制作 “不同亮度、不同尺寸的手电筒”，快速满足用户在差异化场景下的基础需求。

但用户始终无法触及 “手电筒的内部构造”—— 平台不开放底层技术逻辑，不仅导致后期维护时只能依赖厂家、难以自主迭代，更让用户在面对超出预设范围的场景需求时，完全丧失自主拓展的能力。

更关键的是，“手电筒的控制权始终掌握在厂家手中”：用户随时可能面临平台服务中断、功能调整的风险，业务连续性难以保障；且对于本身具备开发能力的企业而言，使用这类平台还可能埋下技术泄露的隐患，核心业务逻辑存在被平台方接触的不确定性。

这种“可用却不可控、能适配简单场景却缺乏拓展能力、暗藏隐性风险”的困境，在实际业务中体现得尤为尖锐。以秒哒为例，其暂不支持导出源码的限制，直接引发一系列连锁反应，对企业经营构成多重潜在威胁：

对于技术团队而言，紧急修复bug并快速上线是日常工作的常态。源码掌握在企业自己手中，开发人员可快速定位问题、完成修复，最大限度减少因系统故障导致的用户流失与经济损失。对于使用低代码/无代码平台的企业而言，源码的缺失意味着修复工作完全依赖平台方，响应速度与解决效率被动受限，给日常运营埋下不确定性隐患。

这一限制的影响远不止于bug修复。源码受限直接导致企业丧失二次开发、功能扩展与系统迁移的自主权。若平台终止服务或调整策略，企业整套系统将面临瘫痪风险，陷入被供应商“卡脖子”的被动局面。

更深层的矛盾在于数据掌控权的旁落。自主开发时，企业可根据业务需求灵活埋点，实现对数据的实时监测、精准分析与动态优化；而低代码/无代码平台提供的数据不仅真实性难以验证，更可能因统计逻辑不透明误导决策。这种信息偏差对企业战略的影响，往往难以估量。

更不容忽视的是，源码作为企业的核心知识产权，是申请著作权、专利的基础，更是构建技术壁垒的关键。一旦因平台漏洞导致源码泄露或安全事件，企业不仅可能遭受商业机密外泄的损失，更可能面临品牌信誉崩塌、法律追责等连锁后果，其代价往往难以承受。

从源码控制权到数据可信度，本质是 “平台主导权与企业自主需求” 的冲突，这是低代码/无代码平台切入TOB赛道的核心障碍。而随着全球监管的持续升级，保护数据隐私已成为企业“刚需”。源码控制权的缺失已埋下安全隐患，而2021年至2025年全球范围内频发的低代码平台安全事件，更印证了这一风险的现实性。

图源：基于公开信息整理 DoNews制图

尽管低代码/无代码平台的市场扩容建立在企业降本增效的需求之上。传统软件开发的全流程往往需要投入大量人力与时间成本：从各业务产品经理梳理需求、评审方案，到UI设计交互页面，再到前后端程序员编码开发，最后经过多轮测试上线，这背后企业投入的人力成本、时间成本、运营成本之高可想而知。

作为对比，低代码/无代码平台通过简化流程、预制组件，能大幅压缩开发周期，同时减少对全链条专业岗位的依赖，这正是其能为企业降本增效的核心逻辑之一。Forrester数据显示，部分组织在三年内获得了超过 500% 的投资回报率，成本回收周期更是短至不到六个月。

但矛盾的核心在于：当企业对数据安全的诉求日益严苛，低代码平台的隐私风险与降本增效价值开始剧烈碰撞。这种碰撞迫使行业思考：在数据主权与安全风险的双重约束下，低代码/无代码平台的 “狂飙式” 增长还能持续吗？对秒哒而言，现有能力不足的问题又要如何快速解决？