模糊需求最危险的地方，不是它不完整，而是团队会把各自的猜测当成共识。原型的第一任务也不是把页面画漂亮，而是让猜测尽早暴露出来，变成可以讨论、修改和验证的方案。
把模糊需求变成原型，建议按六步走：需求证据卡 → 行为假设 → 任务流程 → 低保真结构 → 交互与视觉收敛 → 评审验证。这套方法适合“做得更简单”“提升体验”“做得更智能”这类没有角色、触发条件和验收标准的需求，也适合在使用AI生成原型前整理输入。
30秒先看结论：不要从页面开始，要从可验证任务开始
一句“把搜索做得更智能”还不是原型需求。它至少缺少五个信息：谁在使用、什么时候触发、要完成什么动作、受到哪些约束、怎样判断做对了。
可以先把原话改写成这句话：
在某个场景下，某类用户需要完成一个主动作，系统提供可观察的反馈；当出现无结果、权限不足或操作失败时，用户仍然知道下一步怎么做。
有了这句话，原型才有明确的页面范围。没有这句话，团队很容易在颜色、按钮和页面数量上反复争论，却没有验证真正的产品假设。
第一步：把模糊原话装进需求证据卡
需求证据卡不是一份更长的PRD，而是把一句话中的事实、判断和未知项分开。建议用以下字段记录：
| 字段 | 要回答的问题 | 示例 |
|---|---|---|
| 原话与来源 | 谁提出的？来自访谈、数据还是会议判断？ | “知识库搜索要更智能”，来自客服复盘会 |
| 用户与权限 | 谁会用？他能看到什么？ | 销售、客服；只能看到所属团队资料 |
| 触发场景 | 用户在什么时刻需要它？ | 客户沟通中，需要快速查政策 |
| 行为目标 | 用户必须完成哪个动作？ | 找到可引用答案，并打开原文来源 |
| 失败代价 | 做错或找不到会发生什么？ | 误答客户、转人工、延长处理时间 |
| 业务约束 | 哪些规则不能凭空补充？ | 权限、文档有效期、审计记录 |
| 待确认项 | 目前不知道什么？ | 是否允许跨部门检索、答案是否需要引用段落 |
一个关键原则：未知项要明确标记“待确认”，不能用产品经理的直觉填空。原型可以帮助团队发现未知项，但不能把未经确认的业务规则伪装成确定需求。
第二步：用五问法把口号改成行为假设
证据卡解决“我们知道什么”，行为假设解决“我们准备验证什么”。每个需求只保留一个主行为，连续回答五个问题：
- 谁在什么场景下行动？不要只写“用户”，写清角色、设备、权限和触发时机。
- 他现在怎么完成这件事？记录现有流程和替代方案，避免把“没有功能”等同于“没有需求”。
- 哪一步卡住了？把“体验不好”改成等待、找不到、看不懂、无法确认或无法继续。
- 成功时能观察到什么？例如完成一次查询、打开来源、保存结果或提交申请。
- 哪些条件不能改变？包括权限、合规、数据来源、设备能力和已有系统接口。
例如，把“搜索要更智能”改成：
当销售在客户通话中输入一个业务问题时，他能在有权限的资料范围内找到一条可引用答案，看到来源文档和更新时间；没有可信结果时，系统说明原因并给出转人工或提交反馈的入口。
这句话已经隐含了原型需要验证的内容：输入、权限范围、结果可信度、来源、更新时间、无结果处理和反馈入口。
第三步：先画任务流，再画页面
页面是任务流的可视化结果。先画页面，往往会遗漏返回、取消、加载、错误和权限状态。建议先用一条主路径描述用户如何完成任务，再补三类异常：
- 无结果：没有匹配内容时，用户能否换一种问法、扩大范围或提交问题？
- 权限不足：结果存在但用户不能查看时，是否说明原因和申请路径？
- 操作失败：网络、解析或服务异常时，是否保留输入、允许重试并给出反馈？
以知识库搜索为例，最小可验证流程可以收敛成四个页面状态：
- 搜索页：输入问题、选择范围、提交搜索。
- 结果页：答案摘要、引用来源、更新时间、继续追问。
- 来源详情：打开原文、查看上下文、反馈答案。
- 无结果或权限不足：解释原因、修改条件、转人工或申请权限。
如果这四个状态还没有被确认，就不应急着扩展首页、推荐卡片或复杂的视觉效果。
第四步：用低保真原型先确认结构
低保真原型的价值是控制讨论范围。第一轮只回答“页面是否齐全、路径是否走得通、信息顺序是否合理”，暂时不讨论颜色、插画和品牌风格。
评审时可以让参与者完成一个具体任务：
请查找“客户退款条件”，确认答案更新时间，并打开对应的原文来源。
观察四个信号：
- 参与者是否知道从哪里开始；
- 是否能区分答案和来源；
- 遇到权限或无结果时是否知道下一步；
- 是否能判断答案是否足够可信。
每条评审意见都改写成“假设—任务—信号—决策”。例如：“结果页太复杂”不是可执行结论；“用户在寻找来源时忽略了更新时间，因此把更新时间移到答案摘要旁边，下一轮继续验证”才是可执行结论。
第五步：让墨刀AI起草结构，但不要替你做业务判断
当证据卡和主路径已经确认后，可以用墨刀AI快速生成第一版结构。墨刀AI支持根据文字、截图或草图生成可编辑原型，生成后仍需要在墨刀原型中继续修改、补充交互和组织评审。具体能力和当前入口以墨刀AI官方说明为准。
可以使用下面的提示词起草示例中的四个页面：
你是产品经理助理。根据以下已确认的需求证据卡，输出用户、触发场景、主路径、异常状态和待确认问题。禁止补充未给出的业务规则，未知项统一标记为“待确认”。随后生成可编辑的低保真原型，只覆盖：搜索页、结果页、来源详情、无结果/权限不足状态。生成后要逐项核对：
- 用户角色和权限有没有被AI擅自扩大；
- 结果是否提供来源、更新时间和反馈入口；
- 无结果、权限不足、失败重试是否真的可操作；
- 页面是否超出了已确认的需求范围；
- 哪些内容仍然属于“待确认”，不能直接交付研发。
独特但容易被忽略的判断：AI最适合把已确认的信息组织成可讨论的第一版，不适合替团队补齐业务规则。原型越快生成，人工复核越要前置。
第六步：用三轮收敛避免评审变成审美争论
建议把原型评审拆成三轮，每轮只回答一个问题：
| 轮次 | 关注点 | 通过条件 |
|---|---|---|
| 结构轮 | 页面、任务流、信息层级 | 主路径走通，页面范围没有明显遗漏 |
| 交互轮 | 状态、反馈、返回、权限和异常 | 用户知道每一步发生了什么以及下一步怎么做 |
| 视觉轮 | 组件、文案、间距、品牌和真机展示 | 方案可以被准确理解，并具备交付所需的视觉细节 |
把三轮混在一起，会议很容易变成“这个按钮颜色不好看”。分轮的意义不是增加流程，而是让每条意见都能回到一个明确的产品问题。
一个完整示例：从“更智能的知识库搜索”到四个可评审页面
下面是教学示例，不代表某个客户项目。假设团队收到一句需求：“我们需要给企业用户做一个更智能的知识库搜索。”
证据卡：用户是销售和客服；触发场景是客户沟通中查政策；目标是找到可引用答案并打开原文；约束包括权限、文档有效期和无结果兜底；待确认项包括跨部门检索和答案引用范围。
行为假设：如果结果同时展示答案、来源和更新时间，用户就能判断是否可以对外引用；如果没有可信结果，用户可以修改问题或转人工，而不是停在空白页。
原型范围：搜索页、结果页、来源详情、无结果/权限不足状态。
验证任务：给参与者一个真实业务问题，让他找到答案并打开来源，记录他是否知道下一步、是否能判断答案是否可信。不要在没有实测数据时写完成率、节省时间或“提升多少倍”。
这套方式的重点不是一次画出完整产品，而是用最少页面验证最关键的假设。验证通过后，再扩展筛选、推荐、历史记录和多轮追问等能力。
原型交付前检查清单
- 需求是否写清了角色、触发场景、主行为和约束？
- 每个页面是否对应一个明确任务，而不是为了“看起来完整”增加页面？
- 主路径是否可以从开始走到结果？
- 是否覆盖无结果、权限不足、错误和重试？
- 重要业务规则是否来自已确认信息，而不是原型作者猜测？
- 评审意见是否能转成任务、信号和继续/修改/暂缓的决策？
- 交付给研发的页面、文案、状态和交互是否可以被逐项核对？
常见问题
需求不清楚时，应该先画什么？
先画任务流和状态表，再画页面。至少确认用户、触发、主动作、反馈和异常状态；如果这些仍然未知，原型应当用来暴露问题，而不是替团队做决定。
可以直接让AI把一句话生成原型吗？
可以用AI起草结构，但输入至少要包含已确认的用户、目标和约束。生成后必须人工复核权限、来源、异常状态和待确认规则，不能把初稿当成可直接上线的方案。
原型和PRD哪个应该先做？
先形成最小需求证据卡，再让PRD和原型并行迭代。原型帮助团队发现流程和状态问题，PRD负责沉淀规则和验收条件，两者不必等到“全部写完”才开始验证。如果你手头已经有较完整的需求文档，可以继续阅读需求文档怎么转成原型图，了解从文档提取页面、流程和状态的方法。
如何避免原型评审变成审美争论？
把结构、交互和视觉拆成三轮，每条意见都关联到一个任务和可观察信号。第一轮不讨论颜色，第三轮也不要重新争论已经确认的业务目标。
多人需要共同评审和沉淀版本怎么办？
可以将需求证据卡、流程和原型放入同一个墨刀项目，使用评论和版本记录保留决策过程；需要先了解产品经理工作流的读者，可以查看产品经理工具工作流。
从今天开始：先做一张证据卡，再做第一版原型
真正高效的原型不是“画得快”，而是更早发现团队对需求的不同猜测。先用证据卡收敛范围，再用任务流补齐状态，最后用低保真原型验证主假设，团队会更容易在同一份可讨论方案上继续推进。
如果你已经有一段需求文字、会议纪要或草图，可以先用墨刀AI生成可编辑的结构草稿，再回到墨刀原型中补充交互、组织评审和沉淀版本。需要梳理竞品、用户旅程或需求优先级时，也可以先在墨刀白板上把信息铺开。
