Demo 不是 PRD 的产物，是产品经理想清楚的过程。
做产品经理这几年，有一件事一直让我很难受：脑子里的想法，没办法快速变成别人能看到的东西。
最近在 SOLO 独立端，我们上线了「自动化功能」：用户可以设定定时任务，让 SOLO 在每天特定时间自动执行某些操作，比如每天早上汇总竞品动态、每周五生成周报、每 6 小时做一次代码安全扫描。
传统流程一般是：
一个简单的 Demo，从脑子里到别人眼前，中间隔着无数次「你理解一下我的意思」，沟通一圈下来少说都要话花费至少两周的时间。
但这次我换了个思路：先不写 PRD，先用 SOLO把 Demo 做出来。
Demo 做出来之后回头看，发现整个过程天然形成了五个阶段：
总的来说，就是先搞清楚用户要什么，把构想具象化，再用 Mock 把动态流程演出来，用 SOLO 审视自己的盲区，最后从代码倒推出产品需求文档。
而这每一步都是在和 AI 的对话中完成的。
下图就是本次设计的产品功能页面。（如果大家还没有开始体验，立即开始吧！）
SOLO自动化·任务模板页
接下来我将为大家演示如何用 SOLO 帮我生成一个 Demo，进而帮我沉淀一份产品 PRD 文档。
本次实践全程使用 SOLO 的 Code 模式。
第一步：让 SOLO 调研用户场景
做新功能最怕的事情是什么？拍脑袋去想。
我没有急着画页面，而是先问了一个产品经理真正该问的问题：用户会拿「自动化任务」做什么？什么场景最高频？他们偏好什么样的执行频率？
我们想让 AI 能够定时定点帮用户处理重复性工作——不需要用户每次都主动发起对话，而是到了时间自动执行。我想知道用户最常见的定时自动化场景有哪些，偏好的执行频率是什么。请你到 Reddit、Hacker News、GitHub、Twitter/X 等渠道看看，把非研发类和研发类场景分开，并附上信息源链接。
SOLO 自动搜索了多个社区和资料源，把场景拆成了两类。非研发类的高频场景包括每日新闻摘要、股价监控、会议前准备、邮件摘要；研发类则集中在 PR Review、安全扫描、CI 状态检查、Release Notes 汇总。
更有价值的是频率分布：「每天早上」是绝对的第一触发频率，占比超过 60%。「每周固定时间」排第二，「每 N 分钟监控」排第三。
这些数据直接决定了后面 Demo 里放什么模板、默认什么触发时间、新建表单的频率选项怎么排列。不是我拍脑袋决定「做 9 个模板」，而是有真实的场景输入在支撑。传统做这种调研，翻社区、看竞品、整理归类，少说一两天。这次从提问到拿到结构化结论，一次对话。
这一步的关键是建立场景认知。哪些任务适合每天跑、哪些适合每周跑、哪些更像监控、哪些只是提醒——这些判断决定了后面所有的产品设计。
第二步：让 SOLO 搭建骨架
先把空壳还原出来
要说清楚一件事：这个 Demo 不是截图扔给 SOLO就自动蹦出来的。
「自动化任务」这个功能属于 SOLO 的新功能，作为产品经理的我，手里只有一张现有产品首页的截图：一个对话界面，左边是侧边栏，右边是聊天区，仅此而已。
最初我把这张首页截图发送给 SOLO，让它 1:1 还原。SOLO把布局、侧边栏、聊天框都复刻出来了，但这只是一个空壳，长得像我们产品的静态页面，但是里面没有任何 Automation 相关的东西。
丢给 SOLO的那张原始首页截图——只有侧边栏 + 聊天区
接下来才是真正的搭建。从一个空壳到完整 Demo，靠的是一轮一轮的对话。下面挑三个有代表性的轮次。
先搭三块核心面板
动手之前我先想了想，「自动化任务」这个功能至少要有三块东西：
我会把这三个想法直接告诉 SOLO。同时告知：“将执行历史做成时间轴瀑布流的感觉，按日期分组，模板列表做成九宫格便于浏览”，具体 UI 怎么实现暂时没有告诉 SOLO，第一轮交互后生成的页面如下：
第一轮搭出来的自动化主面板（已配置 Tab）——任务按云端 / 本地分组，本地区域带休眠提示
发现需要优化的部分
骨架做出来之后，我发现了一些之前未思考过的问题：
每发现一个问题，我都会和 SOLO 进行交互，再进行优化，这就是「看到 → 想到 → 改掉 → 再看」的循环。
一次性出 3 版交互，挨个对比
任务列表怎么呈现，这个是最重要的部分。
自动化任务有一个很重要的特征：「一个模子刻出 N 个样子」。同一个任务每天都跑、每天都生成一条记录，本质上是高度重复的。如果跟普通任务一样一条一条平铺，列表很快就会被几十上百条同质内容淹没。
所以一定要聚类。但具体怎么聚，这个属于产品决策，举例子：
过去在解决这种问题的时候，产品经理一般靠脑补、靠静态原型、靠会议室里争论。
现在可以直接让 SOLO 一次性做出 3 版可点击的交互方案，并挨个切换演示：每一版都是真实可交互的实物，不是图也不是描述。
以下是其中两版的对比： 方案 A · 保留外层双 Tab 切换 方案 B · 自动化下单层呈现
边看边推演：哪种最符合用户认知？哪种对现有框架改动最小？哪种 ROI 最高？三版点完，心里就有数了。
这一步我感受最深的是：方案对比从“猜”变成了“点击”。过去 PM 决策最大的成本就是“猜”：猜哪种交互更好用、猜用户怎么走。
现在所有备选的方案都能直接选择 AI 给我提供的方案，看完就知道选哪个，节省了很多争论。
继续交互 60+ 轮对话，逐渐完善
整个 Demo 的实现不止4轮对话，一共经历了 60 多轮这样的对话：但是同样的修改量放在传统流程里，意味着 60 多次「沟通 → 排期 → 修改 → 验收」的循环。在 SOLO里，这只是 60 多句话的事。
这些对话背后有一个共同的模式：
第三步：用 Mock 演示动态流程
Demo 骨架搭出来之后，我发现静态 Demo 没办法表达用户的动态体验。
有些功能本质上是「过程」，不是「界面」。比如我想给同事演示一个理念：自动化任务的所有管理操作（创建、修改、查询），都可以通过对话完成。光说这句话太抽象，截图也表达不出来。用户看不到「我说一句、SOLO 回一句、卡片在对话流里被实时生成」这一连串动作。
但要让它真的跑起来，需要完整的服务端接口、AI 模型调用、状态管理逻辑，这是个纯前端 Demo，不可能搭那一整套真的东西。
应该如何演示呢？我们用 Mock 把动态流程「播」出来。
把对话做成可以播放的动画
我跟 SOLO 说：在对话区上方加一个「演示模式」按钮。点击之后整个对话流会自动播放：
整个过程用户不需要敲任何字、点任何按钮。所有的对白、所有的卡片，都是预先写死的剧本，本质上跟 PPT 翻页是一回事，但视觉上呈现的就是一个真实的对话流。看完那几秒的播放，立刻能 get 到「原来动起来是这个样子」。
三个场景，做成可切换的演示标签
我让 SOLO 一口气做了 3 个演示场景，做成对话区顶部可切换的标签，想给同事演示什么就点什么：
每一个都是几秒钟的自动播放，比任何静态截图、任何文字描述都直观。同事看完三个场景，对「对话式自动化任务」这个理念已经有了完整的体感。
「演示模式」自动播放的多步对话流——从「每天提醒我写日记」到生成任务卡片
让 SOLO把 Demo 部署到线上
Demo 做完，最后还差一件事：部署。要真把这个东西发给老板、发给同事，得有一个能直接点开的链接，不能只在我本地跑着才能演示。
我和 SOLO 说：
把当前项目部署到 Cloudflare Pages，给我一个可访问的链接。
它就搞定了：项目构建 → 修复编译错误 → wrangler 部署。
几分钟之后，一个可以直接分享的静态线上链接生成出来。从一张首页截图开始，到一个所有人都能点开的可交互 Demo，整个流程没有离开过 AI 对话框。
第四步：让 SOLO帮你找盲区
Demo 做出来之后，并不是结束。
做产品其实就是把一个个用例刻清楚。主线一般好讲：比如「自动化任务怎么创建」，但支线和 corner case 容易漏。
这是 PM 日常最头疼的事，也是评审会上最容易被研发追着问的部分。
过去这件事靠脑子里反复推演、靠同事 Review、靠评审会上被人挑刺。现在 Demo 已经形成，整个项目代码 SOLO都读过，你完全可以让它反过来再审查你的 Demo。
这一步我做了两件事：
① 用例覆盖率审计：边界情况 PM 容易漏，SOLO不会
主线我都想清楚了，但 corner case 永远是另一回事。比如：
这些虽然都不是主线，但每一个都是真实会出现的边界。SOLO 在已经有完整 Demo 代码的情况下，可以基于产品逻辑做更系统的推演。
我让 SOLO 从产品视角扫一遍代码，列出「目前 Demo 已经覆盖的用例」和「应该覆盖但没覆盖的用例」。
结论是覆盖率约 70-75%，找出了 3 条关键路径上的用例缺失（运行中状态的展示、失败后的处理链路、创建数据不落地），加上 10 多个边角 corner case。
SOLO输出的 Demo 用例覆盖度分析报告（节选）
② 实体属性矩阵：信息层级该怎么呈现
这一步比上一步更偏”PM 思维”。
「自动化任务」是这次新引入的一个实体。这个实体身上有大量属性：触发时间、上次执行时间、下次执行时间、当前状态（运行 / 暂停 / 取消）、是云端还是本地任务、所属设备、累计执行次数……粗略一数差不多 16 个。
同时，这个实体在产品里的呈现场景也有很多，例如对话流里的卡片、配置列表里的卡片、详情页、执行历史的列表项、对话回放……粗略一数差不多 10 个。
那问题来了：同一个属性，在每个场景里都该呈现吗？哪些是必现、哪些可省、哪些浅层不展示但深层必须有？
从产品设计的原则上来讲，层级越深，信息应该越丰富。
我把这个原则告诉 AI，让它基于此梳理 16 个属性 × 10 个场景的呈现情况，输出一份 16 × 10 的交叉矩阵，每个单元格标注「已展示 / 未展示 / 应有但缺失」。
结果确实发现了一些深层信息反而比浅层欠缺的情况。例如列表卡片上有「累计执行次数」，点进详情页反而看不到了，明显违反”层级越深信息越丰富”的原则。
第五步：让 SOLO帮你写 PRD
Demo 已经做完，最后一步是把它沉淀成给研发看的 PRD。我的具体做法：
最终产出：9 个 Story、10 个 CornerCase，覆盖管理面板、新建弹窗、任务模板、任务详情、执行历史、对话回放等完整链路。
从代码反推 PRD 比从零写 PRD 多一个优势：代码是最细的，每个交互路径、每个条件分支它都知道。人脑写可能漏 corner case，代码里写了什么就是什么。
全流程产出清单
全程没有设计师参与，没有前端开发介入。从场景调研到部署上线，都是一个不会写代码的产品经理通过对话独立完成的。
写在最后
回头看这个过程，最大的感受不是「 SOLO 帮我省了多少时间」，而是它让我意识到：脑子里的方案永远是模糊的。很多判断、很多边界、很多 corner case，只有当你看到一个真能点的 Demo，它们才会冒出来。
过去我习惯把方案先想清楚，再写文档、再等人实现。
现在会先让 SOLO 帮我把想法做出来，看到实物再校准——很多时候你以为想清楚了，等真看到 Demo 那一刻才发现“不对，这里得换个方式”。
在写 PRD 之前，先用 SOLO 做 Demo。
我现在做新功能基本都这么走。你要是也是 PM，下个需求不妨试一下吧！
本文转载自@TRAE.AI公众号，原文链接
https://mp.weixin.qq.com/s/C4YqUTUB-Q9frjR4qnDozg
这是什么工具