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搭个“工位”开始之前，咱们需要做一点准备工作：
安装一个AI Agent产品。比如QoderWork、Trae、CodeX、Claude Code等。我的案例使用的是门槛偏低的QoderWork + QCoder。购买一个套餐或模型Key。比如直接购买QoderWork的会员，或者购买一个按需付费的DeepSeek V4 API，配置到Trae里使用。准备一个本地目录。这一步很关键！目的是确保基础上下文（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执行”的循环，官网的开发基本就成型了。
最后，做个特别说明：*
关于交付物：在这整个闭环流程中，AI输出的所有文档（商业故事、PRD等）不仅可以直接在Agent里预览查看，它们其实也真实地保存在你本地电脑的目录里。这意味着你可以非常方便地进行二次分发，比如一键同步到团队的Wiki、飞书或钉钉文档里，完全不打破现有的协作流。原型 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的第一版大概率都不完美。关键在于你要有耐心去“调试它”，而不是“抛弃它”。你调试它的过程，其实也是在重塑自己逻辑思维的过程。
本文由人人都是产品经理作者【产品方法论集散地】，微信公众号：【产品方法论集散地】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash炒股的杠杆，基于CC0协议
文章为作者独立观点，不代表配资365_配资巴士_手机股票配资观点
