用AI编程代理从零打造百万美元软件：实战全流程拆解

一位年营收百万美元软件公司的创始人在视频中坦言：他不会写后端代码，整个产品的界面和功能逻辑都是自己借助AI编程代理（coding agent）设计完成的。这不是又一个"AI吹嘘"的空话，而是一套可复制的方法论——从找问题到定价再到交付，把软件创业拆成了普通人能执行的步骤。本文梳理他的完整流程，并剖析其中真正值得借鉴的决策逻辑。

先想清楚：问题、市场、方案，缺一不可

很多人栽在起点。作者强调，动手写代码之前要先完成三件事：找到问题、锁定市场、设计方案。

他本人出身销售行业，熟悉销售团队的管理、招聘、培训、辅导全链条，于是把产品定位在销售团队管理工具（产品名 Kendo）。关键在于他像写论文一样先立下一个"假设（thesis）"——"我相信我能把这件事做得比别人更好"，再去验证。

找市场时不能停留在"销售团队"这个粗颗粒度，而要往下深挖：是什么类型的销售团队？团队里具体卖给谁？这个人的痛点是什么？越细化，产品方向越清晰。

一个有意思的判断是，作者认为 SaaS（软件服务）和 service（服务型业务）正在融合成同一种东西。这也是他反复强调"人人都该学软件"的底层逻辑——哪怕是信息产品、代运营服务，最终都在软件化。

构建 MVP：PRD + 前沿模型 + 反复迭代

方案想清楚后，核心动作是打造最小可行产品（MVP）。作者的路径非常直接：

第一步，写 PRD（产品需求文档）。 把前面想清楚的问题、市场、方案、功能点全部丢给 ChatGPT，让它整理成一份 PRD。这份文档本质上是给编程代理的"操作说明书"。他特别提醒：MVP 阶段只选一两个核心功能，而不是一上来就堆满整个 SaaS。对 Kendo 来说，最初只做了"通话复盘"和"角色扮演训练"两个功能。

第二步，把 PRD 交给前沿大模型。 作者点名 Opus 5.5、Codex 等都可以，强调"用聪明的前沿模型"即可，具体选哪个不是关键。

第三步，接受 v1 一定很烂的现实。 他说得很直白："v1 is going to suck."接下来一周甚至更久，就是不断迭代——v2、v3……而且这个阶段只做清理和优化，不加新功能。他回忆早期版本的 Kendo "烂到会让你震惊"，正是靠反复打磨才有了今天的质感。

整个商业闭环是：做出 MVP → 卖给客户 → 卖不出去说明是坏产品/坏点子 → 卖得出去就把钱再投入（雇真正的开发或买更多 token）→ 做出更好的 MVP → 循环往复。全程 bootstrapped（不融资自力更生），他本人起步时账户里只有 2 万美元。

PRD（Product Requirements Document，产品需求文档） 是软件开发中用于描述产品目标、功能边界和用户场景的文档，传统上由产品经理撰写，供工程师和设计师对齐认知。在 AI 编程代理的工作流程中，PRD 扮演的角色类似于"施工图纸"——越清晰、越具体，AI 生成的代码偏差越小。一份好的 PRD 通常包含：目标用户是谁、要解决什么问题、核心功能列表（及明确排除的功能）、成功指标。对于非技术创始人而言，用 ChatGPT 把自己的思路整理成 PRD 的过程本身也是一次强制验证——如果连文档都写不清楚，产品方向往往也还没想透。

前端、后端、AI 层：软件到底怎么跑起来

作者用大白话拆解了软件的三层结构，这部分对新手尤其友好。

前端：用户看得见的部分

前端就是你眼睛看到的界面。他建议统一用 Next.js（也可用 React），并强调"语言只是语言，像英语和西班牙语的区别"，不必纠结。托管则推荐 Vercel——注册账号、点击连接、让 AI 把前端部署上去即可，成本很低。登录认证（auth）、邮箱验证这类基础功能，也直接让 AI 搭建。

后端：让一切运转的底层

后端包含数据库、存储、API 密钥、客户信息等。MVP 阶段他推荐用 Supabase，或通过 Neon 使用 Postgres。作者坦承这种做法"不会是企业级的，安全性也不会很强"，但对起步阶段"完全够用，别再找借口了"。

AI 层：模型能力的来源

如果产品含 AI 功能，就需要一个 OpenRouter 的 API Key，好处是可以随时切换模型而不用重建基础设施。以 Kendo 的通话评分为例，流程是：拿到通话录音 → 转录 → 向量化（vectorizing，让 AI 易于检索）→ 跑过系统提示词（他们有大约 15 个 system prompt）→ 输出通话摘要、评分卡等结果。他直言目前用的是"便宜的中国模型"或 "GPT 的 Luna"。

理解这三层结构有助于非技术创始人在与 AI 或开发者沟通时不至于完全懵圈。前端负责用户交互，代码运行在用户的浏览器里；后端运行在服务器上，负责业务逻辑、权限控制和数据读写；数据库则是数据持久化存储的地方，Supabase 是一种托管型 Postgres 数据库服务，自带身份验证和实时订阅功能，适合快速起步。这三层之间通过 API（应用程序接口） 通信——前端发请求，后端处理并从数据库取数据，再把结果返回给前端。明白了这个框架，就能理解为什么"后端安全性"是作者后来才补齐的短板：MVP 阶段的 Supabase 配置通常是宽松的开发模式，上线真实客户数据前需要专业开发者做权限收紧和安全审计。

向量化（vectorizing） 是 AI 应用中处理非结构化内容（如通话录音转录文本）的关键步骤。其原理是将文本转化为高维数字向量，语义相近的内容在向量空间中距离更近，从而让模型能够进行语义检索而非单纯的关键词匹配。OpenRouter 是一个聚合多家大模型 API 的路由服务，开发者只需接入一次 OpenRouter 的接口，就可以在 GPT-4、Claude、Gemini、DeepSeek^广告 等几十个模型之间自由切换，而不必为每家服务商单独维护 API Key 和 SDK。这对早期产品尤其有价值：当某个模型降价或性能提升时，可以即时切换，无需改动底层基础设施。System Prompt（系统提示词） 则是在每次用户请求前预置给模型的指令，用于固定模型的角色、输出格式和判断标准——Kendo 使用约 15 个不同的 system prompt 分别处理摘要、评分、建议等不同子任务。

设计系统：区分"AI slop"和真正产品的分水岭

作者花了相当篇幅谈设计，因为这是最容易暴露"AI 垃圾感（AI slop）"的地方。"如果你的产品看起来很烂，没人会信任它、没人想用。"

他的解法是建立 设计系统（design system）——他本人那份文档有 17 页，定义了字体、间距、配色、整体氛围等所有视觉规范。这份 design.md 文件放在项目文件夹里，每次让 AI 改动界面时，它都会自动遵循这套规范，保证全站视觉一致。

如何快速搭建设计系统？他给了几个取巧办法：

• 用 Refero 这类工具，找到喜欢的 Web/AI 应用（比如 Claude 的 UI），直接导出它的 design.md 文件；
• 用 Mobbin 做同样的事；
• 或者干脆截图自己欣赏的软件界面，把这些素材喂给 AI，让它"基于这些 UI 创建一套设计系统"。

值得强调的是，他宣称整套界面"零 Figma、零平面设计"，全靠 AI 配合设计系统完成。

定价与 GTM：用 ROI 把价格变成"无脑选择"

定价是作者认为"第一天就该想清楚"的事。他的两条核心原则：

第一，搞清单位经济（unit economics）。 不管是按席位（seat）、按用量（usage）还是像 Kendo 一样的混合模式，都要知道"卖出一个单位，交付成本最高是多少"。Kendo 基础席位每月 55 美元，捆绑固定用量，用超了可再购买，因此最大成本可控。他的经验法则是每单位尽量做到 80% 毛利率。

第二，用 ROI 反推价格。 他现场算账：假设客户有 10 名销售、每月产生约 1500 通电话，带来三大痛点——复盘时间（一个经理根本看不完 1500 通电话，而请多个六位数年薪的经理成本极高）、成交率（从 20% 提到 30% 可能多出数百万营收）、整体效率。而 10 个席位的 Kendo 每月不过 550–600 美元。"你愿意每月花 600 美元换来这些 ROI 吗？这就叫 no-brainer（无脑选择）。"

至于 GTM（go-to-market，即销售加营销），他的闭环是：线索进来 → 免费试用 → 资格筛选（问有多少销售）→ 预约会议 → 销售"代建账户"的服务 → 成交。靠这套打法，他们在近 30 天内新增了近 20 万美元 ARR，而且"广告都还没开"。

ARR（Annual Recurring Revenue，年度经常性收入） 是 SaaS 行业衡量业务规模最核心的指标，反映订阅制收入的年化总量，排除一次性收入。GTM（Go-to-Market） 指将产品推向市场的完整策略，包括目标客户定义、销售渠道选择、定价模式和获客路径。文中提到的"销售代建账户"是一种常见的 PLG（Product-Led Growth，产品驱动增长）与销售辅助结合的转化策略——销售人员在演示阶段直接帮潜在客户配置好账户，降低试用门槛，缩短从"免费试用"到"付费成交"的路径。单位经济（Unit Economics） 则是指每获取或服务一个客户单位所产生的收入与成本之比，80% 毛利率意味着每收入 1 美元，交付成本不超过 0.2 美元，这是 SaaS 行业投资者和创始人普遍认可的健康基准线。

一个关键的分工观念：你不必什么都会

作者反复传递一个解放心态的观点：你不需要掌握全部技术栈。 他本人完全不碰后端，也不打算学，但他专注于设计产品、定义功能、把控体验与逻辑。真正的脏活累活——企业级的安全、数据 schema——交给他后来雇的两名开发去做。

他甚至不让 AI 全权发明一切，而是"让 AI 给我出主意，由我来判断和执行"。Kendo 的 Deals 面板就是这样诞生的：他以用户视角意识到"我讨厌用自己的 CRM"，于是让 AI 根据每通来电自动更新交易进度。

"这就是软件的全部。"作者总结道。他承认软件是"一英里宽、五英里深"的领域，但在起步阶段，想清楚问题、搭好 MVP、理解软件如何运转、再反复迭代到"好到可以卖钱"，就是整个游戏的核心。

写在最后

这套方法论的价值不在于某个具体工具，而在于它把软件创业从"需要全栈工程师"降维成"懂业务 + 会用 AI 代理 + 有审美"的组合技。当然，作者也诚实地指出 MVP 阶段的安全性和企业级能力都有欠缺，这些终究要靠真正的开发补齐。对想入场的创业者而言，真正该记住的或许是那句话：卖不出去的产品本身就是坏产品——先去找人付钱，再谈其他。