从想法到盈利：Zion让非技术创业者快速跑通产品闭环

如今打造AI产品，最轻松的环节往往是做出一个看似完整的Demo雏形。输入几句需求，借助AI代码工具几分钟就能生成页面，再接入大模型补全交互按钮，一个AI应用的架子就搭好了。过去需要团队花几周完成的工作，现在一个人用Cursor、Claude Code这类Vibe Coding工具，几小时就能搞定。但真正的考验，往往在Demo上线之后。

用户注册后数据存在哪里？不同用户的权限边界如何划分？支付失败怎么处理？大模型能否安全读取并写入业务数据库？当用户从十人涨到十万，系统还能否稳定运行？这些在Demo里被隐藏的问题，恰恰是决定产品能否活下去的关键。据行业观察，函子科技创始人兼CEO蒋耀锴对此有着清晰的判断：前端开发的门槛已经被AI拉平，但产品背后的后端架构、权限控制、数据一致性和长期运营能力，依然是未被解决的痛点。AI只是降低了写代码的成本，却没有自动消解经营软件产品需要承担的责任。

AI搞定了“写代码”，却没解决“跑起来”的难题

蒋耀锴曾在硅谷企业软件公司Medallia担任了八年后端工程师。在职期间，他和合伙人做过不少副业项目：二维码点餐系统、NFC自助结账工具、股票策略回测平台。每启动一个项目，都要从零搭建数据库、编写API接口、对接前端页面、处理各类状态逻辑。重复的工作做多了，他逐渐意识到：软件开发中有大量机械重复的劳动，这些工作未必需要经过多年专业训练的工程师来完成。

更关键的是，很多懂行业、懂用户、能发现商业机会的人，最终没能把想法变成产品，不是因为没有好点子，而是被技术门槛拦住了去路。不会写代码，不该成为无缘参与产品开发的理由。这也是他回国创办函子科技、推出Zion及海外版Momen的初心。

但到了AI Coding爆发的当下，这个问题似乎已经被解决了——不懂代码的人也能让AI生成代码。那为什么还需要无代码平台？蒋耀锴的回答很直接：AI降低了代码生成的门槛，却没有降低普通人理解和掌控代码的门槛。

一个开发者拿到AI生成的代码，可以检查数据库结构、修改权限策略、追踪运行日志、处理线上故障。但一个完全不懂代码的人，只能看到页面能不能打开、按钮能不能点击，根本无法判断底层的数据模型是否合理、权限设置是否安全、业务逻辑是否存在漏洞。

前端出现问题，通常只是页面不够美观、交互不够顺畅；但后端出错，可能导致数据丢失、用户越权访问、账目错误，甚至引发安全事故。因此蒋耀锴认为，AI Coding目前最大的断点，不是“代码写不出来”，而是生成代码之后的后端架构、权限控制、数据一致性和长期可运营性没有被解决。Zion想要填补的正是这个空白：让非技术用户不仅能生成一个产品Demo，还能看懂、修改、验证和维护它。

这也是他提出“AI No Coding”概念的原因。AI Coding是让AI帮助开发者写代码，而AI No Coding则是让AI在一套结构化、可视化的系统中，帮助普通人搭建完整应用。两者的核心区别，从来不是最终是否生成代码，而是谁对产品拥有最终控制权。

无代码的核心价值：不是少写代码，而是躲开高风险责任

长期以来，无代码常被理解为一种更简单的开发方式：拖放几个组件、连接几条流程，不用写代码就能快速做出应用。但在蒋耀锴看来，这种理解只停留在表面。无代码真正提供的，不是“少写几行代码”，而是平台提前帮用户承担了一批普通人很难独立完成的工程责任。

以产品后端为例，它至少包含数据库、用户认证、角色权限、行级/列级权限控制、业务逻辑、API接口、文件管理、部署运维、运行环境和后续扩容等环节。Supabase这类开发者工具也能提供这些能力，但使用者需要掌握PostgreSQL、SQL、RLS权限策略和函数逻辑，门槛依然很高。

Zion同样提供数据库、认证、权限和API接口服务，但它将这些能力转化为可视化的操作界面，并通过平台内置规则减少用户出错的可能。蒋耀锴将两者的区别总结为两个字：控制。对于专业开发者来说，代码本身就是控制工具；但对于非技术用户来说，一堆无法读懂的代码不是控制，而是另一个黑箱。因此无代码的价值，不是给用户无限自由，而是通过预设的安全边界，让用户在平台抽象的范围内，稳定解决真实的业务问题。

这也解释了为什么蒋耀锴不认为AI Coding会完全替代无代码。能读懂代码、处理后端和运维的开发者，使用Cursor这类工具自然合理；也有不少用户会混合使用两种方案：前端交给AI生成，后端放在Zion上管理。但对于不懂技术的人来说，最重要的不是一次生成多少代码，而是生成之后能否持续运营。一个能演示的Demo，和一个能长期稳定收钱的产品，之间隔着大量看不见的工作。

Agent脱离业务，就只是一个会聊天的空壳

类似的问题也出现在Agent平台上。现在搭建一个Agent并不难：配置提示词、选择大模型、添加知识库、连接几个工具，很快就能得到一个可以对话的智能体。但蒋耀锴指出，大量Agent产品都面临一个共同的困境：创作容易，商业化很难。

原因很简单：很多Agent只是一个孤立的对话框。它可以回答问题，却无法读取企业自有业务数据；可以生成内容，却不能将结果写回系统；可以展示功能，却无法接入支付体系、独立上线和持续运营。这样的Agent更像是一个功能演示，而非完整的产品。

Zion对Agent的理解不是单独增加一个聊天入口，而是让Agent生长在完整的全栈应用中。它可以读取应用自有数据库，将结果写回数据表，触发业务流程，调用外部接口，也能接入支付系统。在这个架构里，Agent不是产品本身，而是产品中的一个执行角色。

因此蒋耀锴对Zion Agent搭建器的定位非常明确：可视化只是入口，全栈能力才是本质。真正拉开差距的，从来不是能不能搭建一个Agent，而是这个Agent能否接入真实业务，最终形成完整的商业闭环。

这也解释了为什么他更看好Agentic Workflow，而非完全端到端的自主Agent。端到端Agent的故事很吸引人：给它一个目标，它可以自主规划、调用工具、完成全部任务。但任务步骤越多，错误来源就越难定位——三十个步骤后得到错误结果，问题可能出在第三步，也可能在第二十七步，甚至是两个中间状态共同作用的结果。

工程师可以查看日志、追踪状态、设置断点排查问题，但非技术用户面对黑盒系统，通常只能说一句“结果错了”。这个反馈不足以帮助系统在指数级膨胀的状态空间中找到问题所在。因此，真正能进入生产环境的，更可能是边界清晰的Agentic Workflow：将AI放入确定的流程节点，赋予明确的上下文、工具和权限，每一步都可检查、可回退，必要时可由人工介入。端到端Agent更像一个想象中的全能员工，而Agentic Workflow则更像被纳入组织流程、拥有明确岗位职责和权限范围的数字员工。

开发成本降十倍，小市场终于值得做了

蒋耀锴真正想服务的，从来不是大型企业的IT部门。Zion目前超过八成用户是个人开发者，其余是小团队，企业客户占比很低。2024年之后，公司进一步将目标客户收缩为非技术创始人、独立开发者和OPC。

这个选择看似不符合传统SaaS公司的增长路径——企业客户预算更高、合同更大，为什么不向上做企业级低代码平台？但蒋耀锴看到的机会，不是帮助大型企业优化已有流程，而是让过去根本不会出现的软件产品被真正做出来。

很多真实需求的市场规模并不大：一个行业的特殊计算工具、小圈子的交易社区、地方性活动平台、服务特定商家的管理系统，一年收入可能只有几十万到几百万元。过去这类市场很难成立，不是没有用户，而是开发成本太高——为有限的需求招聘产品、前端、后端、设计和运维团队，投入很难收回。

但如果开发成本下降十倍，市场规模不变，生意模型就会彻底改变。过去“不值得做”的小市场，现在可以由一个人或小团队承接。Zion上有两个被反复提及的案例：一位基金经理最初只是为了管理自己的球星卡收藏做了一个小程序，后来越来越多收藏者使用，产品逐步增加了交易、撮合和代购功能，营收从500万元增长到700万元，全程由个人运营；还有一名大二学生为学校做了资源交易市场，加入注册、商品发布、订单、支付以及AI推荐和客服功能，后来月收入超过一万元。

这些产品未必能成为独角兽，但它们已经不是一次性Demo，而是在服务具体人群、产生真实交易、形成稳定现金流的业务。这才是蒋耀锴最在意的结果：不是平台上发布了多少应用，制造了多少AI创业故事，而是有多少应用依然活着、有人每天使用、产生交易并持续被调用。

不想造融资项目，只想做现金流生意

在AI创业叙事中，融资常被当作成功的证明，但蒋耀锴并不希望Zion用户首先考虑融资。他更希望用户做出Cashflow Business：规模不一定大，但能持续收费、养活自己。

这也决定了Zion的商业模式：平台收取订阅费，AI和云资源按实际使用量计费，不根据用户收入抽成。用户做出产品后，数据、业务逻辑和收入全部属于用户自己。对于个体创业者来说，他们购买的不是普通办公软件，而是生产资料——一套每月几百元的工具，如果能帮助一个人启动原本无法落地的生意，投资回报率并不低。

真正的问题不是个人客户客单价不够高，而是平台能否让足够多有真实动机的人持续使用，并在平台上获得收入。因此函子科技并不服务所有想“做个应用”的人，蒋耀锴将目标用户分为三类：

第一类是行业专家，他们来自土木、制造、医疗、法律等传统行业，懂业务和行业潜规则，熟练使用Excel和流程图，但不会写代码，最看重逻辑准确性，专业计算必须100%正确；第二类是商机变现者，包括连续创业者、大学生和Vibe Coder，商业嗅觉敏锐、资金有限，最看重速度，希望72小时内从想法到收到第一笔支付；第三类是流量和资产拥有者，比如网红、社群主和电商从业者，反感平台抽成和依赖第三方，看重数据和业务的自主权。

这三类人能力不同，但有一个共同点：都想自己动手，愿意长期经营。相反，只想花钱买现成结果、不愿理解业务的人，更适合购买现成SaaS或找外包，而非使用Zion。

下一轮竞争：比谁让结果更可控，而非谁生成更快

AI开发工具还在不断缩短生成时间：从几周变几天，几天变几小时，未来可能只需要几分钟。但当生成速度继续提升，速度本身会逐渐失去区分度。真正决定产品能否进入生产环境的，将是另外几个问题：生成的结果能不能被人理解？数据和权限能不能被验证？出现错误后能不能定位回退？更换模型后产品能否继续运行？用户增长后系统能否持续维护？

这也是蒋耀锴更看好“AI与DSL结合”的原因。DSL即针对特定领域的结构化表达系统，AI不是生成一堆人类无法掌控的黑盒代码，而是在结构化的数据、组件、流程和权限体系中工作。AI负责提升搭建效率，而人依然能看懂系统结构，清楚数据位置、流程逻辑和权限规则。

从这个角度看，无代码和AI Coding并非简单的替代关系：AI Coding降低的是代码生产成本，无代码平台降低的是普通人掌控复杂软件系统的成本。真正值得关注的，不是未来还有没有人写代码，而是谁能让不懂代码的人也能对自己的产品负责。

AI已经让做出及格线Demo变得容易，下一阶段更稀缺的，不是更多漂亮页面、更多Agent入口，或是又一个能生成整套产品的Demo，而是把真实的小需求做成能收费、运营、维护和持续迭代的完整闭环。蒋耀锴给非技术创业者的建议很简单：

访谈精选 Q&A

Q1. 从硅谷后端工程师到创业者，你为什么想要打造一款让不懂代码的人也能开发产品的工具？

蒋耀锴：我从小就立志创业。加入Medallia，本质是为了学习初创公司和工程团队的运作方式。公司上市后，我开始专注于解决自己遇到的真实问题。那几年我一边做后端开发，一边和合伙人做各类副业项目，每一个项目都要从零搭建数据库、API和前端，重复劳动让我意识到，很多软件开发工作不需要资深工程师完成。更重要的是，很多懂业务的人被技术门槛拦住，无法将想法变成产品，不会写代码不该成为他们的障碍。所以Zion不是从程序员转向服务非程序员，而是将我在基础设施和后端开发的经验，转化为一款服务所有想做产品的人的工具。

Q2. 你曾用“机遇、贫瘠、闭塞”形容创业环境，到2026年中，这三个词有什么变化？

蒋耀锴：如果重新排序，我会说：机遇没太大变化，贫瘠依然存在，闭塞比去年好一些。机遇没变是因为结构性社会变化都来自边际成本的量级下降，AI这次降低的是认知边际成本，开发成本降十倍后，大量小市场变得可以赚钱。贫瘠依然存在是因为国内中小企业数字化的动力和能力都受限，需求转化为行动的土壤还很薄。闭塞改善是因为Agentic Coding工具的普及让更多人接触到相关技术，信息差缩小，但现在的信息差变成了“能否理解、验证并接入真实业务”，而非“是否知道这个工具”。

Q3. AI Coding工具已经能快速生成应用，Zion的差异在哪里？

蒋耀锴：Zion是全栈可视化应用搭建平台，正因为它的可视化和结构化，AI才能完成“想清楚需求-生成-验证”的完整循环。真正的难点在验证，不懂代码的人无法只通过前端页面确认底层数据、逻辑和权限是否正确。对开发者来说，前端从来不是难点，后端的权限、一致性和长期维护才是隐藏的痛点，这些在Demo里看不到，却会在用户增长后暴露。Zion要解决的不是多写代码，而是让普通人能看懂、修改、维护和运行产品，真正从Prototype走到Production。

Q4. 有没有用户问“我直接用Cursor写代码，为什么还需要Zion？”

蒋耀锴：当然有，这很正常。如果用户能读代码、承担后端责任，用Cursor完全合理，也有很多用户混合使用两种方案。AI Coding会侵蚀部分无代码市场，但不会完全替代。不懂代码的人从零做完整应用，用Cursor可能需要一个月，用无代码只要一周左右。真正的差别在控制方式：开发者用Cursor没问题，但非技术用户拿到一堆代码根本不知道权限和逻辑是否正确。对他们来说，能看懂、修改、验证和迭代比生成更多代码更重要，很多人最后发现自己做出的只是Demo，而非能长期运营的产品。Zion的价值是帮用户少承担高风险责任。

Q5. Zion作为Vibe Coding的后端，和Supabase的本质区别是什么？

蒋耀锴：本质区别是控制，看得懂才能真正拥有控制权。Supabase的底层是Postgres，服务开发者，但需要用户自己负责数据建模、SQL、RLS策略等，门槛对非技术用户还是很高，尤其是权限设置错误会引发安全事故。Zion的BaaS包含数据库、认证、权限、业务逻辑、API等能力，但都做了可视化和默认安全设置，用户能看懂，平台也减少了出错可能。Supabase是把后端积木交给开发者，Zion则把积木拼成非技术用户也能掌控的完整后端系统。

Q6. Zion的Agent搭建器和其他Agent平台的核心区别是什么？

蒋耀锴：其他Agent平台擅长快速创作Agent，但普遍有“创作容易、收费难”的问题，做出的Agent是孤岛，无法接入自有业务数据、独立建站和运营。Zion的Agent不是单独的聊天入口，而是生长在全栈应用中，能读取数据库、写回数据、触发流程、接入支付，最终形成商业闭环。可视化只是入口，全栈能力才是本质，真正的差距在于能否让Agent接入真实业务。

Q7. 为什么你认为Agentic Workflow比端到端Agent更易落地？

蒋耀锴：端到端Agent适合讲故事和演示，但进入真实业务后会遇到可控性、稳定性、权限边界和错误定位等问题。复杂度是乘性增长，每增加一步状态空间都会扩大，但用户的反馈信号始终有限。非技术用户只能说“结果错了”，无法定位问题。而Agentic Workflow将AI放入有边界的流程节点，每一步都可检查回退，必要时人工介入，更接近真实可交付的状态。端到端Agent像全能员工，Agentic Workflow更像有明确职责的数字员工。

Q8. Zion的核心用户是什么样的人？

蒋耀锴：我们不按个人、小团队、企业划分，而是关注三类用户：第一类是行业专家，懂业务但不会代码，看重逻辑准确性；第二类是商机变现者，资金有限、看重速度，希望快速变现；第三类是流量和资产拥有者，反感平台抽成，看重数据自主权。这三类人都想自己动手、长期经营，共同的痛点是招不起全栈工程师、外包无法修改、依赖第三方平台。

Q9. 用户什么时候会真正相信无代码能跑真实业务？

蒋耀锴：真正的顿悟时刻是第一次看到真实数据动起来：数据变化、API连接成功、页面更新、Agent输出结果。大多数人原本不相信无代码能跑业务，亲眼看到产品运行后，认知会从“我居然做出来”变成“这东西真的能跑业务”。我们衡量用户成功不看注册数或应用数，而是看日活、营业额和API调用数，关注平台上“活着且有用的应用”数量。

Q10. Zion的商业模式是什么？如何避免AI调用成本成黑盒？

蒋耀锴：本质是平台订阅和AI使用计费两条线，我们更像更易用的云服务。定价不按用户收入抽成，而是按订阅和资源使用量收费。我们反感模糊的收费结构，特意做了AI价格计算器，让用户能根据模型、用量预估成本，不用懂技术细节。我们的原则是每一次AI调用都要产生商业价值，不能靠烧钱换用户，必须保证单位经济模型健康。

Q11. Zion上有哪些项目从个人想法变成了持续盈利的小生意？

蒋耀锴：有不少项目从个人想法发展成持续运营的生意，比如球星卡管理工具从个人收藏工具变成营收700万的平台，大二学生的校园资源交易市场月入过万，还有家族工厂的数字化跟单系统、K-pop周边社区等。这些项目未必成为独角兽，但已经不是一次性作品，而是能持续产生收入、服务特定人群的业务。我们最看重的不是融资，而是产品从“做了一个东西”变成“持续创造价值并有人付费”。

Q12. 什么样的用户或项目不适合使用Zion？

蒋耀锴：第一类是只想花钱买现成结果、不愿理解业务的用户，他们更适合SaaS或外包；第二类是需要重度定制或改造复杂存量系统的项目，我们的数据库结构有固定要求，不擅长接入复杂现有系统；第三类是只需要标准化业务模块的用户，直接购买垂直SaaS更合适。工具的价值只在用户有明确动机、愿意动手并长期经营时才会体现。

Q13. 为什么选择All in个体创业者，而非向上做企业级低代码？

蒋耀锴：原因有四点：这个市场几乎没有直接竞争者，我们有长期积累的经验和用户口碑，也符合我个人的服务偏好。大量真实需求市场规模小，不值得养工程团队，开发成本降十倍后这些市场变得可行。企业级低代码更重销售和定制，容易进入大厂竞争区间；Agent应用商店需要先有成熟的工具平台和赚钱的开发者，我们选择先做好基础服务。我们想做屠龙少年的刀，而不是替他们屠龙。

Q14. 你认为大模型泡沫会破裂吗？对应用层意味着什么？

蒋耀锴：大模型泡沫肯定会破裂，类比互联网泡沫高点时的情况。但真正稀缺的从来不是更多模型，而是将模型能力转化为可运营的真实产品。前端Demo容易，后端架构、权限和商业闭环才是难点，这个断层正被越来越多人看清。即使泡沫破裂，过去一年的技术提升不会消失，应用层依然有可用的能力，行业冷静后反而更容易找到有价值的落地方式。我们从一开始就设计了模型可替换的架构，用户最终离不开的是自己的数据、流程和业务体系，模型只是发动机。

Q15. 非技术背景的创业者如何判断想法是否值得立刻做产品？

蒋耀锴：不要先想能不能做出厉害的AI产品，而是先想能不能把真实小需求做成能收费、运营、迭代的闭环。很多人追求大而全的惊艳体验，但真正跑起来的往往是解决具体问题的产品。非技术创业者应该从自己熟悉的场景出发，比别人更懂用户和需求，这比会不会写代码更重要。可以检查三件事：能否用通俗语言讲清用户旅程，能否列出核心数据和关联关系，能否在一两周内做出最小闭环并让第一个用户付费。浓缩起来就是四个问题：用户是谁？最痛的事是什么？完成需要哪几步？最早在哪步能收费？创业公司很少死于做不出来，更多死于没人需要。