No. 28: 我为什么做了一个 AI 产品经理工作台
产品讨论、交互原型和 PRD 不该各自成立。AI PM Workbench 想验证的是，能不能把它们放进同一条可评审的产品链路。
2026.08.08
我在 Codex 里讨论产品需求时，经常会走过一条很熟悉的路径：先聊用户和问题，再拆功能，接着做页面，最后补一份 PRD。
每个阶段都有产物，但它们很快就会分开。对话留在 Codex，流程图在另一个目录，原型跑在浏览器里，PRD 又是单独的 Markdown。等到真正评审时，我得在几个窗口之间来回切换，还要解释页面上的某个按钮对应文档里的哪一段。
我想做的不是另一个原型生成器，而是一张能摆下这些证据的产品工作台。
产品讨论结束后，信息为什么会散掉
产品讨论很适合从对话开始。目标不清楚时可以追问，边界有冲突时可以重排，模糊的描述也能逐步变成结构化需求。但对话本身不适合承担最终评审。
一段讨论里可能同时出现用户场景、功能取舍、页面状态和验收标准。后面开始做原型，这些信息会被翻译成界面；再写 PRD，又会被整理成章节。只要其中一个环节单独修改，三份产物就可能不再一致。
常见结果是页面看起来能操作，评审者却不知道某个交互为什么这样设计；PRD 写得很完整，开发人员也无法确认里面描述的是当前版本，还是讨论过程中已经放弃的方案。
我需要的不是更多文档，而是让讨论、图稿、原型、标注和 PRD 能够互相定位。
原型能演示行为，却解释不了规则
可交互原型很适合回答“用户点下去会发生什么”。它可以呈现页面跳转、状态变化、空状态和错误反馈，比静态线框图更接近真实体验。
但原型很难独立回答另外几类问题：这个区域属于哪个用户任务，数据为什么这样展示，哪些操作只是 Demo，哪些状态必须由系统保存，什么条件才算完成。
AI PM Workbench 给页面区域增加了标注入口。评审者点击角标，可以查看当前区域的交互摘要，也可以直接定位到产品 PRD 的对应位置。右侧边栏同时容纳需求文档和产品架构图，页面仍然可以操作，规则也留在旁边。
这个设计没有试图把 PRD 塞进每个控件。标注负责建立坐标，文档负责完整说明，原型负责验证路径。三者各自承担一件事。
图稿不应该变成固定作业
做产品需求时，很容易把用户旅程、业务流程、信息架构、功能架构和状态图列成一张固定清单。每个项目都照着画，产物看起来很齐，真正参与决策的图却不多。
我把图稿生成改成按需判断。工作流会先看当前问题缺什么证据，再决定某类图稿属于建议生成、条件生成，还是不需要。需要画的图逐张确认，简单业务也可以直接用可交互原型和文字验收，不为了完整感增加一张没人使用的图。
这条规则也限制了工作台自身。它可以展示架构图，但不会假设每个产品都必须拥有同一套图。
PRD 要等核心原型确认以后再写
我以前会在需求刚讨论完时就生成一份很长的 PRD。这样做很快，后面修改也很痛苦。页面一旦改变，文档里的流程、状态和验收标准都要重新找一遍。
AI PM Workbench 把完整产品 PRD 放到核心原型确认之后。前期只维护原型准备简报，记录用户、场景、目标、边界、核心路径和 Mock。等到页面可以操作，关键状态也经过检查，再生成完整文档。
PRD 的范围也被刻意限制在产品层。它描述用户、功能、交互、状态和验收，不代替研发决定数据库、API、框架与部署方案。产品需求和技术设计需要衔接，但不应该借一份文档混成同一件事。
工作台只共享评审能力
一个工作台里可以放很多产品，很容易顺手把它们做成同一套模板：相同布局、相同状态结构、相同组件，只替换标题和数据。
这种复用会让 Demo 做得更快，也会掩盖产品之间的真实差异。后台工具、内容产品和桌面应用面对的任务不同，页面不应该为了迁就工作台而长成同一种样子。
所以不同产品只共享 Claude Cream Token、基础组件、通用动效和工作台评审层。业务页面、布局、状态和交互仍然独立。产品菜单负责切换，标注、文档和架构图负责提供统一评审入口，不干预业务产品怎么组织自己的体验。
本地优先让 Demo 保持诚实
当前工作台没有账号、云端协作和真实后端。它在本机运行，也可以通过局域网交给身边的人评审。每个产品使用一套明确的默认 Mock，刷新后可以恢复，不会把演示数据伪装成生产状态。
这个边界让第一版可以集中验证产品机制：能不能从讨论走到原型，标注能不能解释页面，PRD 能不能与当前交互保持一致。在线评论、审批、权限和公网分享都可能有价值，但它们不是这一轮需要回答的问题。
第一版完成了什么
AI PM Workbench 目前完成了 v0.1 工作台基线和 v0.2 Skill。产品菜单、区域标注、可调宽文档边栏、架构图浏览和状态恢复已经可以运行，React、TypeScript 与 Vite 构成了当前前端基线。
Claude Cream 被用作机制验证样例。它证明工作台可以承载产品页面、标注、文档与架构图，但还不能证明完整业务需求的质量。下一步要放进一个真正需要从需求讨论走到评审 Demo 的产品，检查这套八阶段工作流会在哪些地方失效。
我想验证的不是 AI 能不能一次生成漂亮页面，而是产品讨论留下的每个关键判断，能不能在原型和文档里继续被找到、操作和检查。
Vibe Coding 项目页：AI PM Workbench