SaaS产品经理如何用1-2个AI Agent，从0到1手搓一个真实平台？本文以实战案例拆解全流程：从商业故事、产品方案到画原型、写需求文档，再到Vibe Coding，全部在一个聊天窗口完成。没有前端、设计和测试，2人团队如何颠覆传统分工？答案就在Agent驱动的全栈工作模式。

上一篇分享了我用Trae给业务团队做AI培训的经历，算是一次“小试牛刀”。

文章发出去后，有朋友说：“你讲的是培训场景，我不是培训师，跟我的日常工作关系不大啊。”也有朋友问：“你说你会驱动1-2个Agent干活了，到底怎么干的？能不能来点真家伙？”

我是一名SaaS产品经理。过去一年多，我碎片化地分享了不少AI相关内容，从概念到实践再到反思，也分享了一系列用Skills改造产品经理工作流的方法，以及如何用Vibe Coding方式写插件、写网站。可总觉得好像差点什么——就是缺乏系统性和实战价值，一直没有真正用AI系统性完成过一个真实项目。

我想这是很多和我一样的人可能会遇到的困境：AI能力日新月异，发展迅猛，却好像跟自己无关，还是不知道怎么把它真正运用到自己的工作中。

最近，我终于遇到了一个合适的实践案例。今天就带你看看“真家伙”，分享我是如何用1-2个Agent，从0到1手搓一个真实产品的。希望能给你一些启发。

背景：2个人，怎么干出一个平台？

前面我分享过一篇关于手搓插件的文章（可参考：用AI手搓SaaS系统的插件），那是在我们现有SaaS系统之上，通过插件的方式来解决客户个性化需求，使用的也是我们自研的AI伙伴平台。

当时的AI伙伴平台主要是内部人员使用，相对比较粗糙，无法作为正式产品发布给客户。经过一段时间的市场化探索，目前我们的插件市场已经走入正轨，从插件数到营收金额都符合预期。

于是，在技术负责人的授权下，内部组建了一个2人团队（1个PM + 1个后端），准备把这个内部工具当做一款完全独立的平台进行重构，正式推向外部。

相信你也看出来了我们团队的局限性：无前端，无设计，无测试。如果按传统互联网的项目制，根本无法正常推进。怎么办？

答案是：每个成员都需要进入Vibe Work模式，至少驱动1-2个Agent干活，彻底颠覆之前的分工模式。

简单来说，我们两个人需要和Agent组成一个标准团队，包揽从产品方案、产品设计、写代码、测试到上线部署的全栈工作。这次重构至少包括两个核心产品：官方网站和AI插件工作台。

具体分工是：我负责整体产品设计与管理，同时负责官网的全栈自研上线；后端同事负责插件工作台的全栈工作。

今天，我重点分享我从零开始设计产品的全流程，包含：商业方案设计、产品方案设计、画原型、写需求文档，直至最终的Vibe Coding阶段。（如果你着急想了解Vibe Coding，推荐先看：零代码手搓个人官网）。

准备工作：给Agent搭个“工位”

开始之前，咱们需要做一点准备工作：

1. 安装一个AI Agent产品。 比如QoderWork、Trae、CodeX、Claude Code等。我的案例使用的是门槛偏低的QoderWork + QCoder。
2. 购买一个套餐或模型Key。 比如直接购买QoderWork的会员，或者购买一个按需付费的DeepSeek V4 API，配置到Trae里使用。
3. 准备一个本地目录。 这一步很关键！目的是确保基础上下文（Context）环境的一致性。把项目相关资料以及输出结果全放到这一个目录里，AI Agent会把它当做你的“项目空间”进行合理化使用。

开始干活：一个窗口，搞定所有

前期的产品流程与标准互联网产品并无太大差异，只是工作模式完全变了：我不再需要打开Wiki写商业文档或需求文档，不需要打开Axure绘制原型，更不需要打开IDE进行编程。

全部工作流程都在一个聊天窗口里完成——从商业故事到产品方案设计，再到具体画原型和写需求文档，甚至是最后的Vibe Coding。

这里的核心方法，依然是我反复强调的“三个环节闭环法”。每个工作项都遵循这三步：

第一环节：明确诉求与目标。 明确每次需要产出的内容与目标。

第二环节：准备Context。 提前构建AI所需的上下文环境，确保跟AI信息对齐。

第三环节：反复调试验证。 几乎不存在一键成稿的可能，就像做产品一样，都是反复调试、验证、迭代后的结果。

接下来，以QoderWork为例，看看具体怎么操作。

1. 商业方案设计：从一个故事开始

传统互联网产品立项前，都会输出一份商业立项报告。我也不落俗套，开始前需要从商业上梳理清楚思路，输出一份商业文档或PPT，用于内部达成共识。

我先在本地创建了一个目录（把它当做AI研发虚拟员工的工位），打开QoderWork后新建一个会话，选择对应目录作为项目空间和AI的Context（如果有需要参考的文档，可提前粘贴到该目录下）。

跟AI交流时，就像交代任务给同事一样，我会把整体目标和背景信息都告诉它。

我的Prompt：

“我们按一个新故事、新逻辑，把这个事儿包装成一个全新的产品。它至少包含三部分：商业故事、产品方案、技术方案。咱们先来完成第一部分（商业故事）：

1. 为什么需要有XX空间（AI插件平台）？因为SaaS企业的个性化需求必须借助闲置研发资源或AI研发资源。

2. 为什么要成为XX插件平台的开发者？对客户而言，可以用AI Coding自然语言完成插件研发，解决自己的问题；对第三方而言，可以通过研发插件收费，插件上架被购买后还能享受二次销售分成。

3. 企业在这件事里能有什么收益？一方面借助AI解决客户问题，确保留存；另一方面我们提供两种研发模式：本地Agent模式（安装官方Skills和MCP服务）和在线AI插件研发工作台模式（可用自己的模型或购买官方模型）。 请基于以上信息，帮我梳理商业部分的文档。”

AI会根据我提供的上下文和公开信息，自动生成一份商业故事文档。

商业故事-输入信息

第一版效果肯定有偏差，接着进入调试优化阶段。比如我觉得它文字太多、太密，阅读体验差，我就跟它说：

“1. 内容文字过多，不够精炼；

2. 缺少图形化、结构化、数字化的表达，全是文字描述，让人无法清晰看懂。”

商业故事-反复调试

经过3-4轮调试，它就输出了一份符合预期的商业故事文档。如果你面向高层或客户，可以让它直接输出为PPT；如果面向内部，直接输出一份Markdown文档即可。

商业故事-效果图1

商业故事-效果图2

2. 产品方案设计：细化落地框架

商业故事完成后，进入产品方案设计。注意：为了确保上下文共享，一定要继续在刚才的窗口沟通，不要新建会话。

我的Prompt：

“好，商业故事结束了，我们开始第二部分：产品方案设计。

一方面是对外宣传的XX空间官网介绍，让客户和开发者无需登录即可查看商业模式、资源支持和插件市场案例。

另一方面是开发者注册登录后，我们提供两种模式支持：一种是提供Skills和MCP让他们在本地Agent研发；另一种是在线的插件研发平台。”

产品方案-输入信息

如果发现它输出的方案没有明确的产品框架，我会直接给出我的想法进行调试：

“1. 官网页面可分为：首页、插件市场、资源支持、成为开发者（登录/注册等）；

2. 开发者平台包含8个页面（工作台、在线IDE、插件管理、收入中心、模型配置管理等）。”

产品方案-反复调试

同样，经过3-4轮调试，基本就能输出符合预期的产品方案。

产品方案-效果图1

产品方案-效果图2

核心技巧： 调试过程非常重要。提供足够信息的同时，你提的要求或问题一定要清晰、具体。别指望AI是你肚子里的蛔虫，你不说清楚，它就只能瞎猜。

3. 画原型：可视化表达想法

我们都是视觉动物，原型是最佳的表达工具。产品方案定好后，进入原型设计阶段。因为前面的上下文已经足够丰富，我只需简单说一句：

“咱们基于商业部分和产品方案，一起来绘制原型吧。”

原型设计-输入提示词

第一版出来后，直接看预览效果，提出具体修改诉求。比如我发现它把两种研发模式放到了“首页”而不是“资源支持”页，且首页数据夸张了10倍，我就说：

“1、对应两种研发模式，应该放到资源支持部分，根据两种不同研发模式，推荐给用户对应工具：模式一：是本地模式，用自己的AI Agent产品，则需要对应配置MCP和安装插件Skills；模式二：是开箱即用的在线模式，无需安装，可使用自己模型或薪灵模型；2、对应数据有点夸张：比如平均研发周期1-2天；插件总数150＋，累计安装超1000+，不要注册研发者数据。”

原型设计-调试1

发现插件价格不适合对外显示，就说：

“插件先不标记价格。”

原型设计-调试2

经过5-6轮调试，官网的原型就搞定了。接着继续画在线研发工作台的原型。

官网原型-效果图1

官网原型-效果图2

“好，接下来我们一起绘制在线研发工作台（开发者在线研发平台）的原型。”

画原型2-输入信息

它可能会通过确认框问你几个基础问题（比如是否使用经典三面板模式、是否需要IDE等），根据需求直接回复即可。不用怕选错，后面不满意随时可以调，AI不会“埋怨”你。

发现工作台设计多此一举，需要改成项目制，我就继续提要求：

“1. 不要工作台；

2. 插件管理部分改为项目制，每个插件是一个项目；

3. 设置类功能放到用户二级菜单；

4. 不要审批管理、测试环境、收入中心；

5. 整体交互采取类似AI Agent的三栏模式（左菜单、中聊天、右编辑）。”

画原型2-调试

再抠细节：

“1. 模型切换从顶部移到聊天窗口底部；

2. 右侧代码区支持拉伸/隐藏；

3. 去掉‘保存’按钮；

4. 插件项目支持点击预览；

5. 支持添加模型等交互。”

经过几轮细节调试，一份自带预览和交互设计的HTML版本原型就诞生了。

AI插件在线工作台原型-效果图1

AI插件在线工作台原型-效果图1

小贴士： QoderWork输出的原型自带交互，可随时预览调整。它默认使用自带的画原型Skills，如果你想用自定义的，直接告诉它就行。另外，QoderWork还提供了一个专门的设计Agent，封装了常见设计风格并支持在线画布编辑，非常强大。

4. 写需求文档：为Vibe Coding铺路

原型画完，进入写需求文档阶段。如果完全走Vibe Coding，其实可以不写。但为了保存上下文环境和分工协作，我还是让它写了两份。

“好，那你现在帮我写两份需求文档吧：一份是官网部分，一份是在线开发者平台。”

需求文档-输入信息

因为这次需求文档主要是为了给下一步的Vibe Coding做Context（也就是给AI看的，不是给人看的），所以我没有进行过多的调试，差不多就行了。

需求文档-效果图1

需求文档-效果图2

5. Vibe Coding：让想法变成真实产品

产品设计完了，如果是标准流程，下一步就是需求评审、分发给研发和测试。但在我们这个2人（AI驱动）团队里，不可能走老路。

我们需要同时创造两款产品（插件官网、插件研发工作台），于是我和后端各领一个任务。如果只有你一个人，完全可以同时驱动2个Agent并行开发两个项目。

以我负责的“插件官网”为例。

我从QoderWork切换到了QCoder进行Coding（两者共享会员），但操作目录依然是之前的那个“AI虚拟员工”目录，确保上下文一致。

第一步：基于PRD初始化项目

我直接对它说：

“@XX空间-产品方案.md @XX空间-官网PRD.md 基于我的产品方案与需求文档，帮我在当前目录下新建一个目录，并按照对应需求内容研发一个官网网站吧。”

（这里的@文件，就相当于把前面的方案和文档作为Context喂给Coding Agent，就像把PRD交给程序员一样。）

Vibe Coding官网-初始输入

它很快输出了第一版官网（包含首页、插件市场、资源支持以及成为开发者等内容）。接下来就是逐个页面进行调试——看效果，提需求，AI执行——以此往复。

第二步：调试“首页”与“插件市场”

第一版的插件市场里，插件数据都是AI瞎编的。我把真实的插件Excel喂给它：

“@插件名单.xls 这是我们的插件市场的信息，麻烦更新对应插件市场的信息。”

插件市场-提供真实插件信息

这还不够，它还不知道实际的安装使用情况。我继续把对应数据以Excel表提供给它，同时让它优化首页数据：

“1、首页部分，加一个插件研发周期数据，一般是1-2天即可研发一个插件；2、@【考勤】已开通插件管理表.xlsx 是考勤部分实际已开通的企业数，你可以根据对应插件关联真实的安装数，无法关联的插件，则保持现在安装数。”

插件市场-实际安装数据

经过几轮调试后，首页和插件市场页面终于成型。

首页-效果图

插件市场-效果图

第三步：调试“资源支持”页面

继续调试资源支持页面。首先是统一文案描述：

“1、资源支持页面，三种模式，需要有明确说明。比如模式一：xxx、模式二：xxx，让用户清晰看出来是三种独立模式，用户根据实际情况选择模式即可；

2、‘使用你已有的 AI IDE’的统一为‘本地AI Agent’模式。”

资源中心-文案统一

因为AI不知道我们的开发文档长什么样，我就把开发文档的链接全部喂给它，让它自动关联。

资源中心-提供对应开发文档

后来发现，原有的开发者手册内容松散、格式不统一，跟官网风格不搭。我直接让它读取原文内容，在项目里重新生成一份风格统一的全新手册：

“资源支持页面，我提供给你的对应链接文档，整体风格与我们本期设计风格完全不同，你可以把对应内容重新编排一遍，生成新的符合项目设计的网页，即当做项目的一部分吗？”

资源中心-自动转换为统一风格文档

经过几轮调试，资源中心页面也顺利完成。

资源中心-效果图

第四步：调试“登录”与“成为开发者”页面。

最后是打通流程页面：

“1、登录页面就不需要对应步骤，只有注册页面需要；

2、下面对应的MCP_DEV_KEY的说明文案没必要，只有采取本地AI Agent模式才需要它；

3、成为开发者页面（包含登录、注册页面），应该是完全独立的网页更合适，不适合原网页的模式。”

针对导航和交互继续优化：

“1、‘成为开发者’由顶部页签的模式，调整为右上角的按钮，代替‘注册’按钮的作用与位置；

2、‘成为开发者’跟‘登录’页面，一定要是新开一个网页的模式，而不是在原路径下处理。”

登录注册页面-调试

经过“看效果 -> 提需求 -> AI执行”的循环，官网的开发基本就成型了。

最后，做个特别说明：*

1. 关于交付物： 在这整个闭环流程中，AI输出的所有文档（商业故事、PRD等）不仅可以直接在Agent里预览查看，它们其实也真实地保存在你本地电脑的目录里。这意味着你可以非常方便地进行二次分发，比如一键同步到团队的Wiki、飞书或钉钉文档里，完全不打破现有的协作流。
2. 原型 vs 真项目： 单纯从文章的截图看，你可能会觉得“原型设计”跟最终“Vibe Coding的产物”长得差不多（因为看着都是网页）。但实际上，两者有根本的区别：原型只是静态的HTML文件，不可部署；而Vibe Coding出来的，是一个真正的、包含完整前端架构的项目工程。 你只要打开本地文件夹就能一眼看出区别——官网原型可能只是一个单独的 .html 文件，而最终项目是一个包含了 src、components、package.json 等文件的完整前端工程，是可以直接打成镜像、部署到服务器正式上线的。

完整项目文件目录树

下一步，就是打通我们的账号体系并部署到对应服务器上。目前项目还在推进中，等正式上线后，我再把后续的部署经验分享给你。

经验总结：重构工作流的3个真相

复盘这次用1-2个Agent手搓产品的经历，我有几个深刻的体会：

1. 闭环法是最高效的沟通语言。“明确目标 -> 准备Context -> 反复调试”这三个环节，就是你和Agent配合的“标准协议”。Context喂得越准，调试轮次越少；目标越清晰，产出质量越高。

2. 角色边界正在被彻底打破。以前我是产品经理，只管画原型、写文档。现在，在Agent的加持下，我成了集产品、设计、前端于一身的“超级个体”。Vibe Work模式下，你不再是某个流水线上的螺丝钉，而是整个项目的掌控者。

3. 别怕不完美，先跑起来再说。第一次用AI做全栈项目，肯定会遇到各种卡点。不管是画原型还是写代码，AI的第一版大概率都不完美。关键在于你要有耐心去“调试它”，而不是“抛弃它”。你调试它的过程，其实也是在重塑自己逻辑思维的过程。