秒哒3.5来了:普通人做App,真正的门槛变了

图片来源：百度智能云公开文章

秒哒 3.5 发布后，最容易被记住的标签是“不会写代码，也能把 App 装进 iPhone”。

这句话足够吸引眼球，但如果只看到 iOS 打包，就会低估这次更新。

读完整份发布信息，我更强烈的感受是：秒哒正在从一个“帮你快速生成页面的 AI 工具”，变成一套覆盖应用完整生命周期的创作平台。

从想法输入，到生成 Web、App 和小程序；从多人共用一套后端，到开发与线上环境隔离；从搜索优化，到测试、分发、扩容和回滚，这一次补上的不是一个按钮，而是一整条链路。

按照百度智能云披露的数据，秒哒已经累计服务超过 3500 万用户，生成了约 350 万个具有商业价值的应用，每天有接近 20 万人在使用这些应用解决实际问题。这些数字来自官方发布信息，具体统计口径仍应以平台披露为准，但至少可以说明一件事：AI 无代码开发已经不只是少数人尝鲜的 Demo。

它开始进入真实的工作场景。

从 3.0 到 3.5，变化的不只是版本号

此前的 3.0 版本解决了一个很直接的问题：普通人能不能通过自然语言，把一个想法变成可以运行的应用。

3.5 继续往前问：应用做出来以后怎么办？

有人能从搜索引擎找到它吗？能不能装到 iPhone 上？Web、App、小程序能不能共用一套数据？开发时改坏数据库，会不会直接影响线上用户？流量增长后，后端资源能不能跟着升级？做过一次的能力，下次能不能直接复用？

这些问题听起来没有“十分钟生成一个 App”那么酷，却决定了一款产品究竟只能用来展示，还是能够真正交付。

所以，在我看来，秒哒 3.5 的核心并不是“更会生成”，而是“更接近完成”。

一、SEO Agent：做出来以后，先解决谁能看见

很多创作者第一次做网站或应用时，会把全部精力放在页面和功能上。等到产品上线，才发现搜索引擎里显示的标题很模糊，摘要是一段默认文字，关键词也没有体现用户真正会搜索的内容。

传统 SEO 并不是改一个标题那么简单。它涉及页面结构、标题层级、描述、关键词意图、可抓取性和内容质量。专业团队会系统处理，但对普通创作者来说，这些概念往往出现得太早、太碎。

秒哒 3.5 把这部分能力做成了 SEO Agent。

第一步是预览。应用正式上线之前，用户可以先看到页面在搜索结果中可能呈现的标题、摘要和链接，提前判断别人能否看懂这个页面解决什么问题。

第二步是诊断。Agent 会检查页面标题、描述、关键词等基础要素，并把问题翻译成相对直白的建议。例如标题没有表达核心功能、描述太短、搜索摘要信息不足。

第三步是修复。用户既可以逐项处理，也可以让系统批量修复，再重新检查修改结果。

这套流程的意义，是把“发现问题—理解问题—执行修改—再次验证”放进同一个闭环里。过去需要在多个工具之间切换，现在至少基础工作可以在产品内部完成。

但边界也要讲清楚：SEO Agent 能提高页面的基础规范，不等于自动带来流量。搜索引擎最终仍然关心内容是否解决真实问题、页面是否值得停留、其他网站是否愿意引用。一个没有价值的应用，不会因为标题写得更标准就突然获得用户。

工具能帮助你表达价值，不能替你创造价值。

二、iOS 打包：真正解决的是交付的最后一公里

很多 AI 开发工具都可以快速做出一个网页或 Demo，但“能在浏览器里打开”和“能交给真实用户使用”一直是两回事。

传统 iOS 交付流程需要一台 Mac、安装 Xcode、准备 Apple 开发者账号、管理证书和签名，再决定通过 Ad Hoc、TestFlight 还是 App Store 分发。任何一个环节出错，都可能让没有开发经验的人停下来。

秒哒 3.5 把 iOS 构建、测试和分发集中在一套流程里，并给出了两种路线。

图片来源：百度智能云公开文章

第一种是个人测试路线。

按照官方说明，没有 Apple Developer Program 账号的用户，也可以在线生成 IPA 文件，再根据指引安装到自己的 iPhone。这条路线适合验证功能、展示 Demo 或个人体验，但它不是公开上架方案。截图中也明确提示：测试包可能需要第三方工具签名，签名存在有效期，并且更适合少量个人设备。

第二种是正式分发路线。

拥有 Apple Developer Program 账号的用户，可以配置 API Key，让平台协助完成证书申请、在线构建与签名打包。之后可以选择 Ad Hoc 做指定设备测试，也可以通过 TestFlight 邀请更多用户内测，最终把安装包提交到 App Store Connect，等待苹果审核。

图片来源：百度智能云公开文章

这里最值得肯定的是流程被简化，而不是规则被取消。

正式公开上架依然需要开发者账号，依然需要满足苹果的内容、隐私、支付和审核要求。秒哒可以帮你少处理证书与构建细节，但不能保证任何应用都能通过审核，也不能代替开发者承担合规责任。

换句话说，它降低的是操作门槛，不是平台规则。

对想快速验证产品的人来说，这已经很有价值。过去一个想法常常卡在“我没有开发环境”；现在你可以先把可安装版本交给几位真实用户，让他们使用，再根据反馈决定是否继续投入。

三、共享后端：比多做几个页面更重要

这次更新里，我个人最关注的不是打包，而是多应用共享后端。

一个真实业务很少只有一个页面。电商需要用户购买端和商家管理端；企业管理需要员工端和管理员后台；内容平台需要创作者入口和读者入口；一个 SaaS 产品可能同时拥有网页后台、移动 App 和小程序。

如果每个终端都单独建立数据库和接口，会发生两个问题：一是重复建设，二是数据割裂。用户在 App 修改了资料，网页后台却看不到；商家在管理端调整库存，小程序还在显示旧数据。

秒哒 3.5 允许多个应用复用同一套数据库、接口和文件存储。不同终端可以拥有独立界面，但业务数据统一管理。

图片来源：百度智能云公开文章

创建新应用时，可以选择已有项目作为共享后端，不必再从头搭建数据库和接口。比如先做出一个活动报名网页，后续需要增加工作人员核销 App，只要复用报名项目的后端，就能直接读取相同的用户和订单数据。

项目管理也会随之变化。共享同一后端的应用可以集中归类，管理者能够看到哪些终端连接了同一套数据、后端是否运行，以及资源是否需要持续保活。在编辑器中切换 Web、App 或小程序时，也不必反复退出项目。

这才是无代码平台从“做一个能看的页面”走向“搭一个能运行的业务”的关键一步。

不过，共享后端也带来了更高的治理要求。数据集中后，权限必须更清楚：普通用户、商家、运营和管理员分别能看到什么？某个终端修改数据结构，会不会影响其他终端？接口暴露给多个应用后，如何防止越权访问？

没有写代码，不代表不需要理解业务结构。平台可以帮你生成数据库，但表与表之间是什么关系、谁应该拥有哪种权限，仍然需要人做判断。

四、自定义 Skill：把一次成功变成可重复的方法

秒哒 3.5 还把“制作 Skill”放进了对话流程。

官方技能可以覆盖支付、视频、语音、图像、搜索等通用场景，但每个团队都会有自己的特殊需求。有人需要调用内部库存接口，有人需要把报名数据同步到表格，有人希望自动生成日报并发送通知。

第一种，直接用自然语言描述。用户可以在首页选择技能创建，也可以在项目对话中说明需求，让系统生成一个专属技能。后续还可以继续对话修改。

第二种，导入已有技能包。如果手里已经有 ZIP 文件或 SKILL.md，可以直接上传，不必重新配置。

第三种，接入第三方 API。把 API 文档链接或接口说明交给系统，让它理解请求方式、参数和返回数据，并生成可以调用的技能。

图片来源：百度智能云公开文章

我认为 Skill 最有价值的地方，不是又多了一个 AI 名词，而是把一次性的操作沉淀成可以重复使用的能力。

例如，你第一次完成“读取客户表格—筛选重点客户—生成跟进摘要—发送提醒”可能需要不断沟通和调整。如果这套流程能够保存为 Skill，下次遇到相似任务，就可以直接调用，而不是重新解释一遍。

这才是 AI 提高长期效率的方式：不是每次都更快地从零开始，而是让做对过的事情能够复用。

当然，把外部 API 变成技能时也要注意安全。密钥由谁管理、接口能够读取哪些数据、执行失败是否会重复扣费、一个技能能否删除或修改生产数据，这些都应该在正式使用前检查。越容易调用的能力，越需要明确权限边界。

五、环境隔离：决定它只能做 Demo，还是敢接真实业务

AI 生成应用最危险的时刻，往往不是生成失败，而是修改成功后直接影响了线上数据。

假设一个报名系统已经有几千条真实记录。你只是想增加一个字段，却意外修改了数据库结构；或者测试删除功能时，操作到了线上用户。对于正式业务，这种错误比页面不好看严重得多。

秒哒 3.5 增加了单环境与多环境选择。

图片来源：百度智能云公开文章

单环境模式下，开发和线上共用同一套数据库。修改数据会直接反映到线上，配置相对轻量，适合个人项目、活动页、原型验证、待办清单等风险较低的场景。

多环境模式下，开发环境与线上环境使用独立数据库。开发者可以先在测试数据上修改、验证，再通过发布流程把结构变化合入线上。这更适合持续迭代的电商、CRM、ERP、企业后台和团队项目。

多环境真正麻烦的地方，是数据库结构合并。如果开发环境增加了字段，线上环境同时存在真实数据，发布时可能出现 Migration 冲突、SQL 执行错误或存储结构不兼容。过去这类问题需要开发者阅读日志、理解数据库迁移，再手动修复。

按照官方介绍，秒哒 3.5 会让 AI 分析失败原因，把报错转换成更容易理解的说明，并提供可以执行的修复方案。官方同时表示，这类发布合入修复不会消耗秒点，最终规则仍应以平台实时页面为准。

另一个重要能力是版本快照。开发环境发生版本变化时，平台会记录数据库结构和业务数据的状态。如果新版出现接口不兼容、功能异常或数据结构问题，可以回到之前的稳定版本。项目阶段改变后，多环境也能够切回单环境。

这类能力没有生成 App 那么吸引眼球，却直接决定一个工具能不能进入生产环境。因为真正的业务不是“生成一次”，而是不断修改，又不能把已经运行的东西改坏。

六、资源分级：应用有用户以后，后端能不能跟上

一个刚创建的个人工具，可能每天只有几十次访问；一个活动突然传播开，访问量可能在几小时内增长数十倍；企业系统还会持续产生数据库和文件存储需求。

如果所有项目一开始都购买大容量资源，成本太高。如果始终使用最低配置，业务增长时又可能出现响应变慢、存储不足或并发受限。

秒哒 3.5 提供从基础版到不同容量等级的后端资源选择，覆盖并发数、数据库容量、对象存储等维度。

图片来源：百度智能云公开文章；截图中的套餐与额度以平台实时页面为准

创作者可以先用较小资源验证需求，用户增长后再升级。平台提供资源使用情况展示，并在接近额度时提醒扩容。理想情况下，升级不需要重新搭建后端，也不必搬迁现有数据。

这说明秒哒不只想帮助用户把应用做出来，也开始覆盖应用被看见、被使用和持续扩容的阶段。

但选择套餐时不能只看“能不能升级”。还要考虑真实成本、访问峰值、数据库备份、文件增长速度和停机影响。尤其是正式业务，最好提前弄清楚超出额度后会限流、停写还是自动计费。

如果真的用秒哒做一个项目，可以怎样开始

假设我们要为一场线下活动做报名系统。

第一步不是马上说“做一个报名 App”，而是先明确场景：参与者需要查看活动信息、填写姓名和联系方式、选择场次、接收确认结果；工作人员需要查看名单、导出数据，并在现场完成核销。

第二步，用自然语言生成面向参与者的报名页面。先只完成最小闭环：用户能提交，后台能看到，错误信息能被理解。

第三步，增加工作人员使用的管理端，并让它与报名页面共享后端。这样两个终端读取的是同一套报名数据，不需要人工复制表格。

第四步，如果需要移动端体验，再生成 App 或小程序版本。界面可以不同，但用户、场次和核销记录继续复用同一套数据。

第五步，在开发环境里测试修改。使用虚拟名单检查重复报名、名额已满、取消报名和现场核销等边界情况，确认后再合入线上。

第六步，检查搜索标题和摘要。如果活动允许公开报名，可以使用 SEO Agent 检查页面表达；如果只面向内部成员，则无需为了搜索排名增加不必要的信息暴露。

第七步，选择分发方式。个人测试先走测试包；需要公开 iOS 分发，再准备 Apple 开发者账号并进入 TestFlight 或 App Store 流程。

第八步，上线后观察实际访问和资源用量，再决定是否升级后端，而不是一开始就为想象中的百万用户付费。

这一套过程里，AI 可以帮助生成页面、数据结构和操作流程，但“报名需要哪些字段”“谁可以导出手机号”“核销后能否撤销”仍然需要人决定。

这就是新的开发分工：机器承担越来越多实现，人承担越来越多定义、验证和责任。

哪些人最适合关注这次升级

第一类是独立创作者和产品经理。他们通常有很多想法，却缺少完整开发团队。秒哒可以帮助他们快速做出可操作版本，拿给用户使用，而不是停留在文档和原型图里。

第二类是小商家、运营团队和内容团队。活动报名、客户管理、内部工具、内容后台和简单交易流程，都可能通过共享后端连接多个入口。前提是先把业务规则说清楚，不要一开始就追求大而全。

第三类是企业里的业务部门。他们可以更快验证内部需求，但一旦涉及客户隐私、财务数据、核心生产系统或复杂权限，就应该让安全、法务和专业开发团队参与。无代码适合降低协作成本，不适合绕过企业治理。

真正的门槛，已经变成这五个问题

工具越来越简单，不代表做产品也会自动变简单。

第一，你能不能找到一个真实而具体的问题，而不是只说“帮我做一个厉害的 App”？

第二，你能不能给出清楚的边界：谁来使用、需要哪些数据、什么情况下算成功？

第三，你有没有能力判断 AI 生成的结果是否正确，而不是看到页面能打开就默认业务逻辑没有问题？

第四，你是否理解数据、权限、隐私和平台审核仍然由应用运营者负责？

第五，你愿不愿意持续测试，用真实用户反馈决定下一步，而不是把所有功能一次性堆进去？

所以，我不会把秒哒 3.5 理解成“程序员不再需要了”。

更准确的说法是：原型和轻量应用的制作成本继续下降，普通人获得了更完整的交付工具。大家可以先把想法做出来，用真实反馈证明价值，再决定什么时候需要专业开发、设计和运维力量。

这对个人和小团队的意义很直接。

以前，你要先证明自己会开发，才有机会验证想法。现在，你可以先证明这个想法有没有价值。