Solo 实战记录

在写 PRD 之前，先用 Solo 做 Demo

最近我们团队在做一个「自动化任务」功能——用户可以设定定时任务，让 Solo 在每天特定时间自动执行某些操作，比如每天早上汇总竞品动态、每周五生成周报、每 6 小时做一次代码安全扫描。类似 Claude、Codex Automation 在做的事情。

按传统流程：写文字描述发给设计师，设计师理解 70%，出图、改图；再找前端排期做交互原型；中间但凡冒出新想法，改个按钮位置都得再走一轮沟通。一个简单的 Demo，从脑子里到别人眼前，中间隔着无数次「你理解一下我的意思」——一圈下来少说两周。

但这次我换了个思路：先不写 PRD，先用 Solo 把 Demo 做出来。

做出来之后回头看，发现整个过程天然形成了五个阶段——

先搞清楚用户要什么，再把构想具象化，再用 Mock 把动态流程演出来，然后用 Solo 审视自己的盲区，最后从代码倒推出文档。每一步都是在对话中完成的。

第一步：搞清楚用户场景 / 让 Solo 帮你做调研

做新功能最怕的事情是什么？拍脑袋。

我没有急着画页面，而是先问了一个产品经理真正该问的问题：用户会拿「自动化任务」做什么？什么场景最高频？他们偏好什么样的执行频率？

Solo 自动搜索了多个社区和资料源，把场景拆成了两类。非研发类的高频场景包括每日新闻摘要、股价监控、会议前准备、邮件摘要；研发类则集中在 PR Review、安全扫描、CI 状态检查、Release Notes 汇总。

更有价值的是频率分布：「每天早上」是绝对的第一触发频率，占比超过 60%。「每周固定时间」排第二，「每 N 分钟监控」排第三。

这些数据直接决定了后面 Demo 里放什么模板、默认什么触发时间、新建表单的频率选项怎么排列。不是我拍脑袋决定「做 9 个模板」，而是有真实的场景输入在支撑。传统做这种调研，翻社区、看竞品、整理归类，少说一两天。这次从提问到拿到结构化结论，一次对话。

第二步：从一张截图开始 / 让 Solo 帮你搭骨架

起点：先把空壳还原出来

要说清楚一件事：这个 Demo 不是截图扔给 Solo 就自动蹦出来的。自动化任务这个功能在我们产品里压根不存在，我手里只有一张现有产品首页的截图——一个对话界面，左边是侧边栏，右边是聊天区，仅此而已。

第一步我把这张首页截图扔给 Solo，让它 1:1 还原。Solo 把布局、侧边栏、聊天框都复刻出来了，但这只是一个空壳——长得像我们产品的静态页面，里面没有任何 Automation 相关的东西。

接下来才是真正的搭建。从一个空壳到完整 Demo，靠的是一轮一轮的对话。下面挑三个有代表性的轮次。

第一轮：先搭三块核心面板

动手之前我先想了想，「自动化任务」这个功能至少要有三块东西：

• 配置列表——让用户能看到自己配了什么任务，这是基础。
• 执行历史——自动化任务最大的特点是后台默默跑，用户不可控。一旦出问题必须能回溯，所有正经的自动化产品都得有这玩意。
• 模板引导——新用户根本不知道自己要配什么。没有模板，整个产品就是个空盒子；得有几个开箱即用的例子帮他起步。

把这三个想法直接告诉 Solo。我顺手提了一句：执行历史「做成时间轴瀑布流的感觉，按日期分组」，模板列表「做成九宫格便于浏览」——具体 UI 怎么实现 Solo 自己看着办。几分钟后三块面板全填好了。

第二轮：搭出来之后，问题才开始冒出来

骨架做出来之后，真正的问题才开始浮现——这些是隔着脑子根本想不到、必须看到实物才会发现的：

• 执行历史一旦平铺起来数据量太大，得加筛选——按时间维度（今天 / 本周 / 本月）组织，用户才不会一进来就被信息淹没。
• 失败的记录比成功的更值得被关注——跑成功的没人需要管，状态筛选里「失败」要明显凸出来，让用户第一时间看到哪些任务出了问题。
• 任务列表里云端任务和本地任务混在一起也不对——本地任务非常依赖电脑不休眠，得在列表上做一个明确的快捷开关，引导用户把电脑设成不休眠，不然本地任务等于白配。

每发现一个问题，跟 Solo 说一句，几秒钟改完。我再看，再发现下一个——这就是「看到 → 想到 → 改掉 → 再看」的循环。

第三轮：一次出 3 版交互，挨个对比

最有产品决策含量的一轮，是任务列表怎么呈现。

自动化任务有一个特性——「一个模子刻出 N 个样子」。同一个任务每天都跑、每天都生成一条记录，本质上是高度重复的。如果跟普通任务一样一条一条平铺，列表很快就会被几十上百条同质内容淹没。

所以一定要聚类。但具体怎么聚是个真正的产品决策——

• 按云端 / 本地分组？
• 切成多个页签？
• 默认折叠成一行，下钻一级再展开详情？

过去这种问题靠脑补、靠静态原型、靠会议室里争论。现在我直接让 Solo 一次性做出 3 版可点击的交互方案，挨个切换演示——每一版都是真实可交互的实物，不是图也不是描述。下面是其中两版的对比：

我们边看边推演：哪种最符合用户认知？哪种对现有框架改动最小？哪种 ROI 最高？最终选定一个方案。这个决策不是猜出来的，是真切体感得到的。

收束：60+ 轮对话，一步一步堆出来

上面三轮只是节选。整个 Demo 经历了 60 多轮这样的对话——同样的修改量放在传统流程里，意味着 60 多次「沟通 → 排期 → 修改 → 验收」的循环。在 Solo 里，这只是 60 多句话的事。

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

• 不需要一开始就想清楚所有细节，先有个大致方向就够了
• Solo 帮你做出来之后，看到实物，脑子里会冒出新的想法
• 立刻跟 Solo 说，它立刻帮你改，你再看、再想、再改
• 整个 Demo 就是在「看到 → 想到 → 改掉 → 再看」的循环中长出来的

这种工作方式的前提是：Solo 的响应速度足够快，快到你的思考不会被打断。想到什么就说什么，不需要写文档、不需要排期、不需要等人，想法和实现之间的延迟被压缩到了几乎为零。

第三步：用 Mock 把动态流程演出来 / 让 Solo 帮你讲故事

骨架搭出来之后，我发现一件事——静态 Demo 没法表达动态体验。

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

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

那怎么演？用 Mock 把动态流程「播」出来。

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

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

• 用户气泡自动浮出：「帮我设一个每天提醒写日记的任务」
• 停顿一秒，Solo 气泡浮出：「好的，希望几点提醒你？」
• 用户气泡浮出：「晚上 10 点」
• Solo 气泡浮出，下方滑出一张任务卡片：「已为你创建任务，每天 22:00 触发」

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

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

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

• 场景一：多轮对话创建任务（用户说「提醒我写日记」，Solo 追问时间，最终生成卡片）
• 场景二：对话查询执行历史（用户问「最近任务跑得怎么样」，Solo 输出结构化执行记录列表）
• 场景三：对话调整已有任务（用户说「把竞品追踪改成每天 8 点」，Solo 确认并更新卡片）

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

顺手一步：让 Solo 把 Demo 部署到线上

Demo 做完，最后还差一件事——部署。要真把这个东西发给老板、发给同事，得有一个能直接点开的链接，不能只在我本地跑着才能演示。

这一步我跟 Solo 说了一句话：

它就搞定了：项目构建 → 修复编译错误 → wrangler 部署。几分钟之后，一个可以直接分享的静态线上链接生成出来。从一张首页截图开始，到一个所有人都能点开的可交互 Demo，整个流程没有离开过对话框。

第四步：审视完备性 / 让 Solo 帮你找盲区

Demo 做出来之后，不是就完了。

做产品本质上是刻画一个又一个用例。主线很容易讲清楚——比如「自动化任务怎么创建」——但支线和边界情况就容易漏。这是 PM 日常最头疼的部分，也是评审会上最容易被研发挑出来追着问的部分。

过去这件事靠脑子里反复推演、靠同事 Review、靠评审会上被人挑刺。现在 Demo 已经在了，整个项目代码 Solo 都读过——你完全可以让它反过来审你的 Demo。这一步我做了两件事。

1用例覆盖率审计：边界情况 PM 容易漏，Solo 不会

主线我都想清楚了，但 corner case 永远是另一回事。比如——

• 自动化任务执行失败了怎么办？用户怎么知道、怎么处理？
• 自动化任务关联的本地文件夹被用户删除了，下一次执行该如何报错、如何提示用户？
• 用户在配置列表里删除了一个任务，它过往的执行历史记录该怎么处理——保留？归档？还是一并删除？

这些都不是主线，但每一个都是真实会出现的边界。Solo 在已经有完整 Demo 代码的情况下，可以基于产品逻辑做更系统的推演。

我让 Solo 从产品视角扫一遍代码，列出「目前 Demo 已经覆盖的用例」和「应该覆盖但没覆盖的用例」。结论是覆盖率约 70-75%，找出了 3 条关键路径上的用例缺失（运行中状态的展示、失败后的处理链路、创建数据不落地），加上 10 多个边角 corner case。

2实体属性矩阵：信息层级该怎么呈现

这一步比上一步更偏"PM 思维"。

「自动化任务」是这次新引入的一个实体。这个实体身上有大量属性——触发时间、上次执行时间、下次执行时间、当前状态（运行 / 暂停 / 取消）、是云端还是本地任务、所属设备、累计执行次数……粗略一数差不多 16 个。

同时，这个实体在产品里的呈现场景也有很多——对话流里的卡片、配置列表里的卡片、详情页、执行历史的列表项、对话回放……粗略一数差不多 10 个。

那问题来了：同一个属性，在每个场景里都该呈现吗？哪些是必现、哪些可省、哪些浅层不展示但深层必须有？

从产品设计的原则上来讲，层级越深，信息应该越丰富。我把这个原则告诉 Solo，让它基于此梳理 16 个属性 × 10 个场景的呈现情况，输出一份 16 × 10 的交叉矩阵，每个单元格标注「已展示 / 未展示 / 应有但缺失」。

结果确实发现了一些深层信息反而比浅层欠缺的情况。比如列表卡片上有「累计执行次数」，点进详情页反而看不到了——明显违反"层级越深信息越丰富"的原则。

第五步：沉淀文档 / 让 Solo 帮你写 PRD

Demo 都在了，最后一步是把它沉淀成给研发看的 PRD。具体做法：

• 提前给 Solo 配好 飞书 CLI / MCP，让它能直接调飞书 API 创建文档
• 把过往写 PRD 的规范包装成一个 PRD Writer Skill，让 Solo 产出的文档风格和我一致
• 基于这个 Skill + 当前对话上下文 + 项目里的 Demo 代码，让 Solo 生成 PRD 并写入飞书文档

最终产出：9 个 Story、10 个 CornerCase，覆盖管理面板、新建弹窗、任务模板、任务详情、执行历史、对话回放等完整链路。从代码反推 PRD 比从零写 PRD 多一个优势——代码是最细的，每个交互路径、每个条件分支它都知道。人脑写可能漏 corner case，代码里写了什么就是什么。

全流程产出清单

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