---
title: "一个人、一个App、700万营收：AI时代的小生意开始成立了"
id: "20260714A0AGHJ00"
publicationAccount: "非凡产研"
originalPublishedAt: "2026-07-14T19:30:52+08:00"
canonical: "https://ffcap.cn/research/20260714a0aghj00"
source: "https://view.inews.qq.com/a/20260714A0AGHJ00"
sourceAccount: "https://news.qq.com/omn/author/21759984"
language: "zh-CN"
tags: ["商业化","收入与 ARR","AI 编程","模型与基础设施","全球化出海","Anthropic"]
---

# 一个人、一个App、700万营收：AI时代的小生意开始成立了

文章中的“非凡产研”是原始发布账号署名，不代表已核实个人执笔作者。引用访谈或圆桌观点时，应按正文标明具体发言人及当时身份；无法确认时不要推断。日期为原始发表日期，历史信息以发布时点为准。

**AI行业观察**

## **AI Coding把Demo做烂了，真正稀缺的是把产品跑起来**

  

"不会写代码，不应该等于没资格做产品。"

  

现在做一个AI产品，最容易的是做出一个看起来很像产品的东西。

输入一句话，几分钟生成页面；再接上大模型，补几个按钮，一个AI应用的雏形就出来了。过去需要一个团队干几周的事，现在一个人用Cursor、Claude Code或者各类Vibe Coding工具，几个小时就能完成。

但接下来呢？

用户注册之后，数据存在哪里？不同用户能看到什么？谁有权修改订单？支付失败怎么处理？模型能不能读取业务数据，又能不能安全地写回数据库？用户从十个变成十万个，系统还能不能继续运行？

这些问题，在Demo里几乎都看不见。

这也是函子科技创始人兼CEO蒋耀锴对这一轮AI Coding浪潮最直接的判断：

**"前端已经不缺了。真正没有被解决的，是产品背后的后端、权限、数据一致性和长期运营。AI正在大幅降低写代码的成本，却还没有自动消除经营一个软件产品所需要承担的责任。"**

  

## **AI解决了"写出来"，没有解决"跑起来"**

蒋耀锴在硅谷企业软件公司Medallia做了八年后端工程师。

在职期间，他和合伙人做过不少Side Project：二维码点餐、NFC自助结账、股票策略回测。每做一个项目，都要重新建数据库、写API、接前端、处理页面状态。

做得越多，他越确定一件事：软件开发里有大量重复劳动，而这些劳动未必必须由受过多年工程训练的人完成。

更重要的是，许多懂行业、懂客户、能发现商业机会的人，最终没能把想法做成产品，并不是因为他们没有想法，而是因为技术门槛太高。

**"不会写代码，不应该等于没资格做产品。"**

这成为他回国创办函子科技、推出Zion和海外版Momen的起点。

但到了AI Coding爆发的今天，这个问题似乎已经被解决了。

不会写代码的人，也可以让AI生成代码。那为什么还需要无代码平台？

蒋耀锴的回答是：AI降低了代码生成的门槛，却没有降低普通人理解和控制代码的门槛。

一个开发者拿到AI生成的代码，可以检查数据库结构、修改权限策略、追踪日志、处理线上故障。

一个完全不懂代码的人拿到同样的结果，只能看页面能不能打开、按钮能不能点击。至于底层的数据模型是否合理、权限是否安全、业务逻辑是否存在漏洞，他很难判断。

前端错了，通常只是页面不好看、交互不顺。

后端错了，可能意味着数据丢失、用户越权、账目错误，甚至直接变成安全事故。

所以蒋耀锴认为，AI Coding目前最大的断点，不是"代码写不出来"，而是生成之后的后端结构、权限、一致性和长期可运营性没有被解决。Zion想补的，正是这半截：让非技术用户不只是生成一个产品，还能看懂、修改、验证和维护它。

这也是他提出"AI No Coding"的原因。

AI Coding是让AI帮助开发者写代码。

AI No Coding则是让AI在一套结构化、可视化的系统里，帮助普通人搭建应用。

两者的区别不只是最终有没有代码，而是谁对结果拥有控制权。

![一个人、一个App、700万营收：AI时代的小生意开始成立了 · 原文图片 1](https://inews.gtimg.com/om_bt/OzqkIy2P48_qKhXPPMNJtPAaD54sETgPwmz-qpIHWnTbcAA/1000)

  

## **无代码真正卖的，不是少写代码，而是少承担高风险责任**

长期以来，无代码经常被理解成一种更简单的开发方式。

拖几个组件、连几条流程，不需要写代码，就能快速做出应用。

但在蒋耀锴看来，这个理解仍然停留在表面。

无代码真正提供的，不是"少写几行代码"，而是平台提前处理了一批普通人很难独立承担的工程责任。

以一个产品后端为例，它至少包括数据库、用户认证、角色权限、行级和列级权限、业务逻辑、API、文件管理、部署、运行环境以及后续扩容。

Supabase等开发者工具也提供这些能力，但使用者需要理解PostgreSQL、SQL、RLS权限策略和函数逻辑。

Zion同样提供数据库、认证、权限和API，但尽量把这些能力变成可视化结构，并通过平台规则减少用户写错的机会。

**"蒋耀锴把两者的区别概括为两个字：控制。对于专业开发者，代码本身就是控制工具。对于非技术用户，一堆无法阅读的代码并不意味着控制，反而可能是另一个黑盒。因此，无代码的价值不是给用户无限自由，而是通过护栏，让用户在一个适合平台抽象的范围内，稳定地解决真实问题。"**

这也是为什么他并不认为AI Coding会完全替代无代码。

能够读代码、能处理后端和运维的人，使用Cursor当然合理。还有不少用户会把两种方式混合起来：前端交给AI生成，后端放在Zion里管理。

但对于不懂技术的人，最重要的不是一次生成多少代码，而是生成之后能不能继续运营。

一个能演示的产品，和一个能长期收钱的产品，中间仍然隔着大量看不见的工作。

  

## **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和云资源按照实际使用量计费，但不根据用户收入抽成。用户做出产品后，数据、业务逻辑和收入仍然属于用户。

对于个体创业者而言，他们买的不是一套普通办公软件，而是一种生产资料。

一套每个月几百元的工具，如果能够帮助一个人把原本无法启动的生意跑起来，它的ROI并不低。

真正的问题不是个人客户客单价不够高，而是平台能否让足够多具有真实动机的人持续使用，并在平台上获得收入。

因此，函子科技并不服务所有想"做个应用"的人。

蒋耀锴把用户分成了几类。

一类是行业专家。他们懂土木、制造、医疗、法律等专业场景，知道通用软件没有覆盖的行业规则，但不会写代码。

一类是商机变现者。他们有点子、资金有限，希望在最短时间内完成从想法到第一笔收入。

还有一类是流量和资产拥有者。他们手里已经有社群、内容或者客户，希望建立自己的产品和数据资产，减少对第三方平台的依赖。

三类人能力不同，但有一个共同点：他们都想自己动手，也愿意长期经营。

相反，只想花钱购买现成结果、不愿意理解业务的人，更适合买SaaS或者找外包，而不是使用Zion。

**"我们服务的是想屠龙的人，不是想吃龙肉的人。Zion想做的不是替创业者完成所有工作，而是成为屠龙少年手里的那把刀。"**

  

## **下一轮竞争，不是谁生成得更快，而是谁让结果更可控**

AI开发工具还在不断缩短生成时间。

几周变成几天，几天变成几小时，未来可能只需要几分钟。

但生成速度继续提高之后，速度本身会逐渐失去区分度。

真正决定一个产品能不能进入生产环境的，将是另外几个问题：

生成的结果能不能被人理解？

数据和权限能不能被验证？

出现错误之后能不能定位和回退？

模型更换之后，产品能不能继续运行？

用户增长之后，系统能不能持续维护？

这也是蒋耀锴更看好"AI与DSL结合"的原因。

DSL可以理解为一套结构化、针对特定领域的表达系统。AI不是生成一堆人类无法掌控的黑盒代码，而是在结构化的数据、组件、流程和权限体系里工作。

AI负责提高搭建效率，人仍然能够看懂系统结构，知道数据在哪里、流程如何运行、权限如何生效。

从这个角度看，无代码和AI Coding并不是简单的替代关系。

AI Coding降低的是代码生产成本。

无代码平台降低的是普通人控制复杂软件系统的成本。

而真正值得关注的，不是以后还有没有人写代码，而是谁能够让一个不懂代码的人，也可以对自己的产品承担责任。

AI已经让做出一个及格线Demo变得非常容易。

下一阶段更稀缺的，不是更多漂亮页面、更多Agent入口，也不是又一个可以生成整套产品的演示。

而是把一个真实的小需求，做成一个能够收费、运营、维护和持续迭代的闭环。

蒋耀锴给非技术创业者的建议也很简单：

**"先别问自己能不能做出一个很厉害的AI产品。先回答四个问题：用户是谁？他现在最痛的一件事是什么？完成这件事需要哪三到五步？哪一步最早可以开始收费？因为创业公司很少死于'做不出来'。更多时候，它们死于根本没人需要。"**

  

## **访谈精选 Q&A**

### **Q1. 你从硅谷工程师转向创业，为什么决定做一款让不写代码的人也能开发产品的工具？**

**蒋耀锴：**我从小就决定要创业。去Medallia，本身也是为了学习一家初创公司、一个工程团队到底该怎么运作。公司上市之后，我就开始"scratch my own itch"，做自己真正想要的东西。

那几年，我一边在Medallia做后端，一边和合伙人做二维码点餐、NFC自助结账、股票策略回测等Side Project。每做一个项目，都要重新建数据库、开放API、连接前端，再处理一堆页面状态和样式。做多之后，我有一个很强的感受：这里面大量是重复劳动，而且未必需要一个受过完整工程训练的人来做。

真正让我坚定的是，我越来越确定，很多聪明、懂业务、有商业嗅觉的人，之所以没有把想法变成产品，不是因为他们没有想法，而是技术门槛太高。不会写代码，不应该等于没资格做产品。

所以Zion/Momen本质上不是我从程序员跳到了非程序员，而是把过去做基础设施、后端和高性能系统的经验，拿来做一把工具。只是这把工具不再只服务工程师，而是服务那些想做产品、但没有花几年时间学习编程的人。

### **Q2. 你之前用"机遇、贫瘠、闭塞"形容创业环境。到了2026年中，这三个词发生了什么变化？**

**蒋耀锴：**如果现在重新排，我会说：机遇没怎么变，贫瘠还在，闭塞比去年好了一些。

机遇没有变，是因为我一直相信，所有结构性的社会变化，都来自某种边际成本的数量级下降。蒸汽机、集装箱、互联网、智能手机都是这样，AI这一次降低的是认知的边际成本。当开发成本降低十倍，大量以前不值得做的小市场，会突然变得可以做、可以赚钱。

贫瘠在中国依然存在。一个小企业想寻找数字化解决方案，不管是动力还是能力，都很受限。不是没有需求，而是把需求转化为行动这一段，土壤依然很薄。

闭塞比去年好了一些。OpenClaw那一波狂欢，以及后来各家推出的Claude Code式Agentic Coding工具，让更多人第一次真正上手了Agentic的使用方式，信息差被拉近了不少。

但信息差并没有消失，只是换了一种形式。过去的问题是"你知不知道有这个东西"，现在的问题是"你能不能理解、验证，并把它接入真实业务"。很多人看到的是Demo，少数人看到的是Workflow；很多人记住了模型名字，少数人真正关注上下文工程、工具调用、记忆、权限和数据源。信息差已经从有没有信息，变成了有没有能力把信息变成结果。

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

**蒋耀锴：**Zion是一个全栈可视化应用搭建平台。正因为它是可视化、结构化的，AI才能在上面完成一个完整循环：先想清楚要做什么，再生成，最后验证。

真正困难的是验证。对于一个不会写代码的人，只看前端跑起来的样子，或者看几个特定输入输出，是远远不够的。你无法确认底层的数据、逻辑和权限到底对不对。

现在对Vibe Coder来说，最难的从来不是前端。前端AI已经可以做得又快又漂亮，但后端才是数据模型、权限、一致性、事务、上线和长期维护真正隐藏的地方。这些东西在Demo里看不见，却会在真实用户增加之后悄悄出问题。

AI Coding解决的是AI帮助你写代码，和它对应的应该有一个"AI No Coding"，也就是AI帮助用户在无代码系统上搭建。Zion要解决的不是多写一点代码，而是让普通人能看懂、能修改、能维护、能运行自己的产品，真正从Prototype走到Production。

### **Q4. 有没有用户说："我直接用Cursor写代码了，为什么还需要Zion？"**

**蒋耀锴：**有，而且很正常。确实有用户迁移到AI Coding。如果他本来就能读代码，也能自己承担后端责任，那么完全合理。也有很多用户混着用，前端用AI搭建和生成，后端放在Zion上。

AI Coding会侵蚀一部分无代码的空间，但不会完全替代它。一个完全不会代码的人，从零做一个前后端完整应用，过去可能要半年，有了Cursor可能缩短到一个月，用无代码很多时候仍然只需要一周左右。

真正的差别不在生成速度，而在控制方式。你是开发者，Cursor很好；你不是技术背景，AI给你生成一堆代码，你根本不知道它在做什么，也不知道权限有没有问题、后端会不会埋坑。

对于非技术用户来说，能看懂、能修改、能验证、能持续迭代，比一次性生成更多东西更重要。如果你真的能稳定地用Cursor把后端、权限、数据库、支付、部署和运维全部处理好，当然可以不用我们。但很多人最后会发现，自己做出来的是一个能演示的东西，不一定是一个能长期运营的产品。

Zion的价值不是帮你多写代码，而是帮你少承担一批高风险责任。

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

**蒋耀锴：**最本质的区别不在服务清单，而在控制。看得懂，你才真正拥有控制。

Supabase是一条非常正派的产品路线，底层是真正的Postgres，数据主权、生态和开发者心智都很强。但它默认服务开发者，数据建模、SQL、RLS策略、Edge Functions、前端对接和线上权限排查，都需要用户自己负责。

对于技术团队没有问题，但对于不会写代码的人，或者主要依靠AI Coding的用户，门槛依然很高。尤其是权限，RLS非常强，但一旦写错，就可能成为安全事故。

Zion的BaaS包括PostgreSQL数据库、用户认证、RBAC角色权限、行级和列级权限、Actionflow可视化业务逻辑、自动生成GraphQL API、文件能力、AI Agent、RAG，以及部署、独立算力和私有化支持。

如果只列服务，双方高度重叠。真正的区别是，在Zion上，这些能力是可视化并且默认生效的。用户看得懂，平台也尽量不给用户写错的机会。Supabase是把后端积木交给开发者，Zion则把它拼成一个非技术用户也能够掌控的产品后端系统。

### **Q6. Zion的Agent搭建器和扣子、百炼等Agent平台相比，核心区别是什么？**

**蒋耀锴：**扣子、百炼这类平台非常擅长帮助用户快速创作一个Agent，不管是对话还是工作流，创作这一段都很方便。但它们有一个共同问题：创作容易，收费很难。

做出来的Agent往往是一个孤岛，接不进自己的真实业务数据，独立建站、收费和长期运营都比较困难。

Zion的Agent搭建器最大的差异是，Agent不是一个单独的壳，而是生长在一个完整的全栈产品里。它能读取用户自己的数据库，能写回数据表，能触发Actionflow，能接入支付，也能独立上线和运营。

别人提供的可能是一个能聊天的Agent，我们希望提供的是一个嵌入真实业务、能够运行、也能够赚钱的Agent。

所以可视化只是入口，全栈才是本质。真正拉开差距的不是能不能可视化搭建Agent，而是这个Agent能不能接入真实业务，最终形成商业闭环。

### **Q7. Agent概念越来越热，你为什么依然认为Agentic Workflow比端到端Agent更接近真实落地？**

**蒋耀锴：**端到端Agent很适合讲故事和做演示。你给它一个目标，它自己规划、调用工具、完成任务，听起来非常诱人。但一进入真实业务，就会遇到可控性、稳定性、成本、权限边界、错误恢复，以及出问题之后如何定位。

最根本的原因是，复杂度是乘性增长，而不是加性增长。每增加一步，状态空间都会相乘地扩大，但"它错了"这个反馈信号的信息量始终没有增加。

一个三十步任务最终产出错误，到底错在第三步、第二十七步，还是第十二步和第十九步的相互作用？对于能读代码的工程师，"它错了"不是信息，只是触发器，他会进一步追踪、查看中间状态和设置断点。但非技术用户只能黑箱评价，这不足以在指数级膨胀的状态空间里找到问题。

真正能够落地的，仍然是Agentic Workflow：把AI放进一个有边界、有上下文、有工具、有流程节点，并且必要时有人在回路里的系统。每一步都能够检查，也能够回退。

端到端Agent像一个想象中的全能员工，Agentic Workflow则像一个被放进组织流程里的数字员工。后者更接近今天真实可交付的状态。

### **Q8. Zion的核心用户究竟是什么样的人？**

**蒋耀锴：**我们内部不会只按照个人、小团队和企业来划分，而是更关注三类用户画像。

第一类是行业专家。他们大多三四十岁，来自土木、地产、制造、医疗、法律等传统行业。他们懂业务，也懂通用软件没有覆盖的"潜规则"，Excel和流程图用得非常熟练，但不会写代码。对他们而言，最重要的是逻辑准确性。专业计算必须100%正确，99%都可能砸掉自己的招牌。

第二类是商机变现者，包括连续创业者、大学生和各种Vibe Coder。他们商业嗅觉强，资金有限，但点子多。App对他们来说是一个变现漏斗，最看重的是速度。从产生想法到收到第一笔微信支付，最好在72小时内完成。他们的成功标准很简单：多快收到第一笔真金白银。

第三类是资产或流量变现的人，例如网红、社群主和电商从业者。他们非常反感平台税和寄人篱下。在其他平台上做到几百万元营收，对方一旦提高抽成、修改规则或者封号，整个业务都会受到影响。所以他们更看重主权：数据是自己的，逻辑是自己的，不抽成，也能够随时迁移。

这三类人的共同点是，都希望自己动手，要求成本低、上线快、系统稳定，也都面临同一批困难：招不起可靠的全栈工程师，外包交付后无法修改，微信生态门槛高，以及AI写完代码之后的维护断层。

### **Q9. 用户在什么时候会真正相信，无代码工具可以跑真实业务？**

**蒋耀锴：**真正的Aha时刻，是用户第一次看到真实的东西动起来。

数据真的发生了变化，API真的连接成功，另一个系统里的数据跟着变化，页面真的改变，Agent也真的输出了结果。大多数人心里其实并不相信无代码可以跑真实业务，所以当他亲眼看到产品真的运行起来，认知会发生一个转变：从"我居然能做出来"，变成"这东西居然真的能跑业务"。

我们服务的是想屠龙的人，不是想吃龙肉的人。用户首先需要有一个具体问题，然后把页面、数据和流程搭建起来。当他发现产品不只是Demo，而是真的可以登录、保存数据、收钱和交付给别人使用，付费意愿才会明显提升。

我们衡量用户成功，也不会只看注册数、应用数或者上线数。真正关注的是应用日活、营业额和API调用数。总结成一句话，就是平台上"活着并且有用的应用"到底有多少。

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

**蒋耀锴：**本质上是平台订阅和AI使用计费两条轴。说得直接一点，我们其实是云的二道贩子，只是做成了一个更易用的云。

定价不是按照用户赚了多少钱抽成，而是更接近云服务。用户为平台能力支付订阅费用，使用更多AI或云资源，再根据用量增加费用。我们的原则是，只要用户做的产品具有明确商业价值，购买Zion应该是一个比较容易做出的决定。

我们非常反感让用户看不懂、算不清，最后突然收到巨额账单的收费结构。平台成本尽量做成可预测的订阅，AI调用单独计费，但需要尽可能解释清楚。

我们还专门做了一个AI价格计算器，帮助用户根据模型、输入输出和业务量预估总成本。用户不需要理解Tokenizer的原理，只需要知道哪些动作会产生AI费用，大概是什么量级，又对应了多少业务价值。

我有一个很明确的原则：每一次AI调用，要么产生商业价值，要么增加收益，要么节省成本。AI创业不能依靠烧服务成本换用户，单位经济上做一个亏一个，规模越大，死得越快。

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

**蒋耀锴：**有不少项目从个人想法发展成了持续运营的小生意，当然也有起有落。

例如一名十年没有写代码的工程师做过虚拟女友小程序，后来被腾讯封了；一名UX设计师给Coze用户制作的变现模板，也随着Coze热度下降而停止。但更多项目活了下来，甚至越做越大。

最典型的是球星卡项目。它最初只是一名基金经理为自己制作的收藏管理工具，后来越来越多人使用，又加入了交易、撮合和代购功能，营收从500万元增长到700万元，基本由一个人运营。

还有大二学生为家族工厂制作的数字化跟单系统，一直稳定运行；也有K-pop周边社区、香港线下活动社区，以及服务AI时代OPC创业者的社区。

它们未必都成长为大公司，但已经不是一次性作品，而是能够持续产生收入、服务特定人群的小生意。我最看重的从来不是有没有融资，而是产品有没有从"我做了一个东西"，变成"这个东西可以持续创造价值，并且持续有人付钱"。

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

**蒋耀锴：**一个业务成熟的表现，不是什么都说可以做，而是知道什么场景不应该接。

Zion最适合的是没有现成工程团队，希望快速做出真实产品，并且愿意自己动手的非技术创始人和OPC。

第一类不合适的用户，是只想花钱、不愿意理解产品和业务的人。他需要的更像是解决方案、外包或者现成SaaS，而不是工具平台。

第二类是从一开始就非常重定制，或者需要改造复杂存量系统的项目。我们对数据库结构有固定要求，如果企业已经拥有一套复杂数据库，希望Zion直接接入并改造，通常不在我们擅长的区间。

第三类是用户真正需要的已经是一个标准化业务模块。他不想搭建，只想购买现成结果，那么直接选择垂直SaaS会更加合适。

工具只有在用户拥有明确动机，愿意动手，也愿意长期经营的时候，价值才最大。

### **Q13. 为什么选择All in个体创业者，而不是向上做企业级低代码平台？**

**蒋耀锴：**如果只能选择一个方向，我会选择"无代码+AI"的个体创业者和非技术创始人。

原因有四点：第一，这个市场几乎没有真正的竞争者；第二，我们已经在这条路上积累了很长时间；第三，我们在这群用户中已经形成了一定品牌认知；第四，这是我自己的个人偏好，我就是想服务这群人。

大量真实需求，并没有大到值得长期养一个工程团队。很多市场一年的收入只有几十万元或一两百万元。过去因为开发成本太高，这些市场不值得做；当开发成本降低十倍，它们突然就能够成立。

企业级低代码当然也是市场，但它更重销售、组织和定制，也更容易进入大厂擅长的竞争环境。AI Agent应用商店我也看好，但它应该是工具和开发平台成熟之后自然形成的结果。如果没有稳定的构建能力，也没有真实开发者在平台上赚到钱，单独做市场很容易空心化。

我们想做的是屠龙少年手里的那把刀，而不是替他屠龙。

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

**蒋耀锴：**我觉得大方向正在被验证。数据中心建设已经开始出现过剩，资本开支不再对应市值增长，Capex效率也在下降，其中很大一部分卡在内存瓶颈上。这个泡沫肯定会破，可以类比互联网泡沫最高点时的情况。

但真正稀缺的从来不是再多一个模型，而是如何把模型能力变成真实、可运营的产品。模型不是终点，真正困难的是把它接入业务流程、权限体系、数据系统、支付和长期运营。

前端Demo很容易，后端结构、权限、一致性、维护和商业闭环才难，这个断层正在被越来越多人看清。

即使模型泡沫破裂，过去一年积累的能力提升仍然存在，不会因为估值回调而消失。对应用层来说，可用的能力依然存在，甚至行业变得更加冷静之后，反而更容易找到真正有价值的使用方式。

我们从一开始就是按照"模型可替换"设计的。哪家模型更好、更便宜，用户就可以使用哪家。用户最终真正离不开的，不是某一个模型接口，而是自己的数据、流程、权限、前后端、支付和运营体系。模型是发动机，不是整辆车。

### **Q15. 对于非技术背景的创业者，怎样判断一个想法是否值得立刻做成产品？**

**蒋耀锴：**不要先想"我能不能做出一个很厉害的AI产品"，而是先想"我能不能把一个真实的小需求，做成一个能收费、能运营、能持续迭代的闭环"。

很多人一开始就追求大而全，或者一个看起来很惊艳的AI体验。但真正能跑起来的，往往不是最炫的产品，而是最先把一个具体问题解决掉的产品。

尤其对于非技术背景的人，更应该从自己真正理解的场景开始。你比别人更了解用户、流程和需求为什么存在，这比会不会写代码重要得多。AI和无代码帮助你缩短从想法到上线的路径，但不会替你决定应该解决什么问题。

具体可以检查三件事。

第一，用户旅程是否说得清楚。能不能不用技术词，只用人话解释：谁来使用，先看到什么，点击什么，提交什么，最后得到什么。

第二，数据结构是否列得出来。至少能写出用户、订单、商品、内容、预约和支付记录等核心数据，以及它们之间如何关联。很多项目不是死在页面，而是死在一开始没有想清楚数据关系。

第三，能否在一到两周内做出最小闭环，交给真实用户使用，并让第一个人付钱。如果不能，通常说明切口仍然太大。

再浓缩一点，只需要回答四个问题：用户是谁？他最痛的一件事是什么？完成这件事需要哪三到五步？在哪一步最早可以开始收费？

创业公司很少死于做不出来，更多时候死于根本没人要。

---

原始发布版本：https://view.inews.qq.com/a/20260714A0AGHJ00

本站阅读页：https://ffcap.cn/research/20260714a0aghj00