把原型说明整理成待确认需求

这个场景能帮你做什么

原型能展示想法，却经常缺少隐藏业务规则。WorkBuddy 可以从可读的原型说明和演示代码提取可见功能，整理成需求草稿，同时明确哪些内容仍需确认。

开始前需要准备什么

提供原型文字、页面清单、交互说明或允许阅读的演示代码，补充产品目标、用户角色和已确认规则。标明模拟数据、占位接口和仅为展示的行为。

具体怎么做

第一步：记录原型实际表达的内容

按页面和用户任务提取入口、操作、展示和状态，附对应说明或代码位置。不从界面字段推断数据库设计，也不把模拟按钮当真实接入功能。

第二步：分开观察与推断

将直接可见功能、已有业务规则和待确认推断分栏。原型未表现的权限、异常、并发、数据保存和审批条件列为缺口。

第三步：形成需求草稿与补问

按任务写使用者、目标、触发、输入和输出，未确定部分保留问题。将“原型这样画”与“业务必须如此”分开，避免展示细节过早约束实现。

第四步：确认后进入正式文档

产品与研发逐项确认规则、边界和可行性，仅把确认结果纳入 PRD。原型与需求有变化时保留差异，不静默同步为已批准。

可以直接交给 WorkBuddy 的完整要求

请从附件原型文字/演示代码提取需求草稿，保留页面或代码出处。
区分真实表达、已确认规则、模拟占位和你的推断。列用户任务、输入输出、状态及待补的权限/异常/数据规则。
不要依据原型推断预算、技术可行性或未展示的业务逻辑。输出待确认需求和具体补问，不宣布正式需求已完整。

完成后会得到什么

一份能进入澄清会议的需求草稿，特别标出“演示有表现、真实实现未确认”的部分。

结果应该怎么检查

选几个完整用户任务回看原型说明，检查模拟能力是否被当成现成能力，推断是否有明确标签，隐藏规则是否留待确认。

遇到这些情况怎么处理

只有图片时先补文字说明。演示代码省略异常时列问题，不直接照抄为产品规则。原型与已确认需求冲突时交产品决定版本。

哪些必须人工决定

产品确认业务意图，研发确认实现条件，设计确认表达。AI 可以整理草稿，不能从演示反推出完整产品规格。