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 和代码三种杠杆。代码也不应该是无代码失败后的逃生舱，而应该是同一个产品的另一种编辑方式。