乐于分享
好东西不私藏

从软件交付到业务结果:AI 应用构建如何重塑交付方式?

从软件交付到业务结果:AI 应用构建如何重塑交付方式?

2026 年 7 月 15 日至 16 日,由非凡产研主办的「2026 非凡大赏 · 上海 · AI 商业峰会」在上海漕河泾万丽酒店正式拉开帷幕。本届峰会主题聚焦:让智能体进入业务闭环。

在峰会的「Panel 4:从软件交付到业务结果:AI 应用构建如何重塑交付方式?」圆桌论坛上,函子科技创始人蒋耀锴分享了他对于 AI、Agent 以及无代码生态在商业落地的深度观察。

在他看来,AI 带来的绝不仅仅是“用 AI 几秒钟生成一个 Demo”的炫技,而是如何跨越“视觉可用”到“工程严谨”的鸿沟,让真正懂业务的 Owner 能安全、持续地拿到业务结果。

以下是圆桌论坛中,蒋耀锴的核心分享实录。

Q1

QUESTION

请各位先用一句话介绍:你们主要服务哪类用户,他们最核心的痛点是什么,你们最终交付的“结果”又是什么?

蒋耀锴:一句话说,Zion 服务的不是拿 Demo 去融资的人,而是拿产品去收款的非技术创始人;他们明明最懂客户为什么付钱,却经常被代码、外包和后续维护卡住,我们给他的不是一个代做出来的 App,而是自己掌控一门能持续收款、持续迭代的数字生意的能力。

比如有个大二文科生,用 Zion 搭了一个校内资源交易市场,把注册、商品发布、订单、支付以及 AI 推荐和客服都跑了起来,月营收过万。这就是我们定义的结果:不是“我做出了一个东西”,而是它开始服务真实用户、产生真实交易。

Q2

QUESTION

AI 大幅降低开发门槛后,应用交付最困难的部分发生了怎样的转移?新的瓶颈是业务理解、方案设计、产品品味、工程可靠性,还是组织落地?

蒋耀锴:我觉得这个问题漏掉了一个最关键的瓶颈:持续迭代能力。

AI 可以让第一版软件接近免费,但 cashflow business 的价值通常出现在第十版、第一百版。真正的瓶颈是三件事的乘法:你是否理解客户为什么付钱;真实的钱和数据进来以后,系统是否可靠;业务变化时,产品能不能继续跟着变。业务不是一份冻结的 PRD,业务是会变的。

小卡册最早只是一个基金经理给自己做的球星卡收藏工具,后来根据真实需求不断加入交易、撮合和代购,已经有数万用户、数百万 SKU;案例材料最新口径是营收从 500 万增长到 700 万,基本由一个人运营。它的价值不是第一版生成得多快,而是业务变了很多轮,产品还可以继续经营。

人负责理解变化,AI 负责加快迭代,平台负责给变化加上工程护栏。第一版不是产品,能够可靠地变到第十版才是。

Q3

QUESTION

当企业老板、业务人员甚至普通消费者都能直接构建应用时,产品经理、设计师和工程师的角色会发生什么变化?“会表达需求、会判断结果”是否会成为新的门槛?

蒋耀锴:我不同意这是“新的门槛”。会表达需求、会判断结果,本来就是门槛。AI 是放大器,它会放大顶尖能力,也会把无能放大。

未来每个产品会需要更少、但更好的产品经理、设计师和工程师。顶尖能力一直都很稀缺,只是大多数场景不需要、也用不起一个全职的顶尖专家。现在 AI 可以把优秀产品经理的取舍方法、优秀设计师的设计系统、优秀工程师的架构护栏复制到大量项目里,所以顶尖人才的影响力反而会扩大。

例如,我们正在把工程师对最小权限的判断沉淀进权限工具和 Agent review:它可以在不同项目里检查 allowAll、默认全行访问和多角色权限叠加等风险。一个优秀工程师不再只能影响自己手上的一个项目,他的判断可以被重复使用。

真正会迅速归零的是纯粹的模态翻译:如果产品经理的价值只是把会议翻译成 PRD,设计师只是把 PRD 翻译成 Figma,工程师只是把工单翻译成 CRUD,这部分价值 AI 很容易接走。

AI 不会让顶尖产品经理、设计师和工程师变得不重要;它会让他们的能力被复制一万次。

Q4

QUESTION

从一个快速生成的 Demo 到真正可上线、可维护的业务系统,中间还需要跨过哪些关键环节?数据、权限、安全、测试、部署和长期维护应该由谁负责?

蒋耀锴:我认为本质上是从“视觉可用”跨越到“工程严谨”

Demo 只需要跑通一条 happy path;真实系统还要面对多人并发、数据一致性、细粒度权限、异常回滚、外部服务失败以及上线后的持续变化;如果是 SaaS,还要处理租户隔离。

这件事最终必须由搭建者负责,因为他就是 system owner。只有他知道什么订单算正确、谁应该看什么数据、库存不足时应该取消、候补还是拆单。负责人不等于所有事情都要亲手完成,而是必须定义规则、判断结果,并对最终上线负责。

Zion 和 AI 从不同角度给他打辅助:

  • Zion 提供工程护栏,把关系型数据、约束与事务、后端权限、异步任务、安全运行环境、部署和日志追踪等通用工程复杂度产品化。

  • AI 提供第二双眼睛,帮助检查数据模型、权限配置和异常分支。例如我们正在做的权限插件,可以让 Agent 读取角色及表、字段、行和流程权限,在 review 时提醒 allowAll、永真条件和多角色权限叠加等风险;但它不是一键安全审计,也不知道业务本来应该如何设计。

快升贸易就是一个真实例子。没有开发背景的业务负责人自己搭了一套 ERP 小程序,把订货、搜索、下单、仓库进出库和明道云同步串了起来。页面能显示订单只是 Demo;真正上线以后,客户、商品、订单和库存之间的关系是否正确,销售和仓库分别能看到什么,同步失败后如何处理,都需要 owner 定义并验收。

Zion 提供护栏,AI 提供审查,搭建者承担责任。AI 可以是副驾驶,但不能成为 system owner。

Q5

QUESTION

过去几个月,哪一项技术进步真正改变了你们的产品或交付方式?未来半年到一年,你们最关注的产品方向又是什么?

蒋耀锴:过去几个月,真正改变我们的是:AI 从生成内容的工具,变成了能够理解上下文、调用工具、检查结果并继续工作的 Agent。

但我先纠正一个前提:AI 改变了我们的研发方式,也显著降低了 Zion 的使用门槛,但没有改变我们的交付方式。因为 Zion 本来就不是项目制公司,我们没有传统的交付团队;builder,也就是 owner,始终对最终结果负责。

在产品侧,我们开放了 CLI 和 Skills,也把内置助手从基于 LangGraph 的固定流程,升级成类似 Claude Code 的 Agent Loop。它不再机械地执行预设步骤,而是能够根据项目现状决定下一步。比如我们正在做的权限插件,可以让 Agent 读取真实的角色和权限配置,在 review 时发现 allowAll、永真条件等风险,再辅助 owner 修改。

未来半年到一年,我们会重点做两件事:

第一,让 AI 进一步操作前端 Canvas,并进入数据、逻辑、权限、测试、日志和文档等更多切面,让整个 Zion 都能被 Agent 操作。

第二,让无代码和代码更好地融合。同一个项目里,owner 可以用自然语言和可视化界面搭建,AI 可以通过 CLI 和 Skills 工作,工程师也可以在需要时用代码扩展,三者共享同一套数据、权限和部署体系。

我们不是把人工外包换成 AI 外包,而是让 owner 同时使用无代码、AI 和代码三种杠杆。代码也不应该是无代码失败后的逃生舱,而应该是同一个产品的另一种编辑方式。

直播预告

7 月 16 日(周四)晚 18:00,Zion CLI & Plugin 首发直播

点击下方「预约」按钮完成直播预约 👇 
END

我们是 Zion 无代码,一个面向 OPC 和 AI 创业者的无代码开发底座。

如果你觉得今天这篇有收获,欢迎点赞、分享、推荐三连,我们下篇见。

推荐阅读
直播关注#视频号Zion无代码,第一时间获取直播通知

更多用户故事

·烂尾三次、耗资巨大后,这位土木「跑路人」如何用无代码工具自救?

·医学生如何用「无代码」,给中医科普开辟新入口

·在昆山杜克大学黑客松,Hayward 团队用 Zion 无代码 + AI 编程搭建 AI 求职平台

·揭秘 2025WAIC 投资对接小程序,从需求到上线,用 Zion 7 天搞定

·非技术人,也能做出 ESG 数据产品?他用无代码打破了传统开发壁垒

·从贵州高中生成长为中外模联推动者,他用无代码把世界带到更多学生面前

·教育人转行做调酒 AI?他用无代码做出人人都能学的「调酒教练」

·B 站 20 万粉 UP 主的高中生活:在无代码与黑板间游走的少年

开发实战教学

· Zion CLI & Plugin 正式发布,用 AI 搭建可视化后端

·用 Cursor 生成你的 Zion 代码组件(附保姆级教程)

·Zion 已接入 OpenAI 最新模型 GPT-5,只需一键切换即可调用更智能、更高效的模型

·从市场调研到原型设计,用 AI 工具辅助创业的实操要点

·打造「AI 教你搭」的背后:Zion 如何用多 Agent 实现智能产品教练?

更多学习资料

官网functorz.com

教程docs.functorz.com

视频B站:Zion无代码

开发community.functorz.com

案例函子科技

社群Zion 用户群