从文档驱动到 Demo 驱动，TRAE 产品经理如何用 SOLO 重塑工作流

本文作者：CC，TRAE 产品经理
Demo 不是 PRD 的产物，是产品经理想清楚的过程。

做产品经理这几年，有一件事一直让我很难受：脑子里的想法，没办法快速变成别人能看到的东西。

最近在 SOLO 独立端，我们上线了「自动化功能」：用户可以设定定时任务，让 SOLO 在每天特定时间自动执行某些操作，比如每天早上汇总竞品动态、每周五生成周报、每 6 小时做一次代码安全扫描。

传统流程一般是：

1️⃣ 写文字描述发给设计师，设计师理解 70%，然后出图、改图

2️⃣ 和前端沟通排期做交互原型，中间但凡冒出新想法，改个按钮位置都得再走一轮沟通。

一个简单的 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 版可点击的交互方案，并挨个切换演示：每一版都是真实可交互的实物，不是图也不是描述。

以下是其中两版的对比：

边看边推演：哪种最符合用户认知？哪种对现有框架改动最小？哪种 ROI 最高？三版点完，心里就有数了。

这一步我感受最深的是：方案对比从"猜"变成了"点击"。过去 PM 决策最大的成本就是"猜"：猜哪种交互更好用、猜用户怎么走。

现在所有备选的方案都能直接选择 AI 给我提供的方案，看完就知道选哪个，节省了很多争论。

继续交互 60+ 轮对话，逐渐完善

整个 Demo 的实现不止4轮对话，一共经历了 60 多轮 这样的对话：但是同样的修改量放在传统流程里，意味着 60 多次「沟通 → 排期 → 修改 → 验收」的循环。在 SOLO里，这只是 60 多句话的事。

这些对话背后有一个共同的模式：

1. 不需要一开始就想清楚所有细节，先有个大致方向就够了

2. SOLO 帮你做出来之后，看到实物，脑子里会冒出新的想法

3. 立刻跟 SOLO 说，它立刻帮你改，你再看、再想、再改

4. 整个 Demo 就是在「看到 → 想到 → 改掉 → 再看」的循环中长出来的

第三步：用 Mock 演示动态流程

Demo 骨架搭出来之后，我发现静态 Demo 没办法表达用户的动态体验。

有些功能本质上是「过程」，不是「界面」。比如我想给同事演示一个理念：自动化任务的所有管理操作（创建、修改、查询），都可以通过对话完成。光说这句话太抽象，截图也表达不出来。用户看不到「我说一句、SOLO 回一句、卡片在对话流里被实时生成」这一连串动作。

但要让它真的跑起来，需要完整的服务端接口、AI 模型调用、状态管理逻辑，这是个纯前端 Demo，不可能搭那一整套真的东西。

应该如何演示呢？我们用 Mock 把动态流程「播」出来。

把对话做成可以播放的动画

我跟 SOLO 说：在对话区上方加一个「演示模式」按钮。点击之后整个对话流会自动播放：

• 用户气泡自动浮出：「帮我设一个每天提醒写日记的任务」

• 停顿一秒，SOLO气泡浮出：「好的，希望几点提醒你？」

• 用户气泡浮出：「晚上 10 点」

• SOLO气泡浮出，下方滑出一张任务卡片：「已为你创建任务，每天 22:00 触发」

整个过程用户不需要敲任何字、点任何按钮。所有的对白、所有的卡片，都是预先写死的剧本，本质上跟 PPT 翻页是一回事，但视觉上呈现的就是一个真实的对话流。看完那几秒的播放，立刻能 get 到「原来动起来是这个样子」。

三个场景，做成可切换的演示标签

我让 SOLO 一口气做了 3 个演示场景，做成对话区顶部可切换的标签，想给同事演示什么就点什么：

• 场景一： 多轮对话创建任务（用户说「提醒我写日记」，SOLO追问时间，最终生成卡片）

• 场景二： 对话查询执行历史（用户问「最近任务跑得怎么样」，SOLO输出结构化执行记录列表）

• 场景三： 对话调整已有任务（用户说「把竞品追踪改成每天 8 点」，SOLO确认并更新卡片）

每一个都是几秒钟的自动播放，比任何静态截图、任何文字描述都直观。同事看完三个场景，对「对话式自动化任务」这个理念已经有了完整的体感。

「演示模式」自动播放的多步对话流------从「每天提醒我写日记」到生成任务卡片

让 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。我的具体做法：

• 提前给 SOLO 配好 飞书 CLI ，让它能直接调飞书 API 创建文档

• 把过往写 PRD 的规范包装成一个 PRD Writer Skill，让 SOLO产出的文档风格和我一致

• 基于这个 Skill + 当前对话上下文 + 项目里的 Demo 代码，让 SOLO生成 PRD 并写入飞书文档

最终产出：9 个 Story、10 个 CornerCase，覆盖管理面板、新建弹窗、任务模板、任务详情、执行历史、对话回放等完整链路。

从代码反推 PRD 比从零写 PRD 多一个优势：代码是最细的，每个交互路径、每个条件分支它都知道。人脑写可能漏 corner case，代码里写了什么就是什么。

全流程产出清单

全程没有设计师参与，没有前端开发介入。从场景调研到部署上线，都是一个不会写代码的产品经理通过对话独立完成的。

写在最后

回头看这个过程，最大的感受不是「 SOLO 帮我省了多少时间」，而是它让我意识到：脑子里的方案永远是模糊的。很多判断、很多边界、很多 corner case，只有当你看到一个真能点的 Demo，它们才会冒出来。

过去我习惯把方案先想清楚，再写文档、再等人实现。

现在会先让 SOLO 帮我把想法做出来，看到实物再校准------很多时候你以为想清楚了，等真看到 Demo 那一刻才发现"不对，这里得换个方式"。

在写 PRD 之前，先用 SOLO 做 Demo。

我现在做新功能基本都这么走。你要是也是 PM，下个需求不妨试一下吧！

如果你觉得本文不错，欢迎大家点赞、在看、转发三连呀！