“把知识库搜索做得更智能。”如果接到这句话就开始画页面，产品经理可能在想搜索框，销售在想自动回答，研发在想接入模型，大家讨论的其实不是同一件事。
把模糊需求变成原型，先把原话收敛成“谁在什么场景下，要完成哪件事”，再确定资料和业务限制，最后用少量页面试走主路径与异常。以销售在客户沟通中查询退款政策为例，目标不是做一个会聊天的页面，而是让他找到有权限、仍有效的答案，并打开依据。本篇沿着这个任务，完成一张需求证据卡、四类页面状态、一段可复制的生成指令和一份试走记录。
先把“更智能”换成一项业务任务
模糊需求最危险的地方，是团队把各自的猜测当成共识。先不要问“需要几个页面”，改问下面五件事：
- 谁在什么场景下行动？本例是销售在客户通话中查询政策，使用电脑，已登录企业账号。
- 现在怎么做？在多个文档里搜索标题，再找同事确认哪一份有效。这个现状需要通过观察或访谈确认，不能仅凭一句抱怨推断。
- 卡在哪一步？找到文档却不知道能否对外引用，与完全搜不到，是两个不同的问题。
- 什么动作算完成？找到对应政策、确认版本仍有效、打开来源中支持答案的段落。
- 哪些条件不能改变？原有资料权限、有效期和政策审核规则不能因为增加搜索功能而被绕过。
将回答压成一句需求陈述：
销售在客户通话中查询退款条件时，可以在自己有权限的有效资料中找到答案，看到来源及更新时间，并打开对应段落；没有依据时，可以修改问题或返回搜索。
这句话已经能排除几项容易被顺手加上的功能：自动承诺退款、跨部门查看未授权资料、把所有历史文件都作为当前答案。先排除什么不做，通常比先列十个功能更能缩小原型范围。
用证据卡分清事实与未知项
需求证据卡不是更长的PRD。它只负责把已确认的信息和仍需决策的事项分开。下面的内容可以直接复制，再替换成自己的材料；“退款处理说明”中的文字用于本例任务，不代表任何企业的现行政策。
| 字段 | 知识库搜索的填写结果 | 还要向谁确认 |
|---|---|---|
| 原话与来源 | “知识库搜索要更智能”；记录提出者、日期和对应会议或访谈 | 需求提出者确认具体受阻情境 |
| 使用者与权限 | 销售和客服；只检索本人有权访问的资料 | 资料管理员确认权限范围 |
| 主任务 | 查询退款条件，找到答案并打开政策原文 | 业务负责人确认答案使用场景 |
| 成功信号 | 能指出答案来自哪一段、当前是否有效，而非只看到一段流畅回答 | 和真实使用者走一遍任务 |
| 第一版范围 | 搜索、结果、来源详情及无结果/访问受限状态 | 产品与研发确认实现范围 |
| 不做的内容 | 自动处理退款、推荐系统、多轮追问、跨部门权限扩展 | 需求提出者确认不会误解范围 |
| 待确认项 | 来源有效期由谁维护；检索失败日志由谁处理；查询记录保留多久 | 分别指定负责人，写上决定日期 |
准备三份小样本，便能让抽象约束在原型里变得可见：
- KB-01 当前退款处理说明：有效、销售可读；内容为“先收集订单号，由客服根据订单状态确认是否受理，不在搜索结果中承诺到账时间”。
- KB-02 旧版退款流程：已失效；即使关键词匹配，也不进入当前答案。
- KB-03 内部争议处理备忘：销售无权查看；不在结果中泄露标题、摘要或正文片段。
遇到未知项，用“未知 → 会影响什么 → 谁决定”写下来。例如，“是否允许展示无权访问的文档标题”会影响结果列表，必须先确认；“下个月要不要增加推荐问题”不影响当前搜索主路径，可以暂缓。这样不会因为所有问题还没答案就停止画原型，也不会把关键规则偷偷补成假设。
只验证一个行为假设
证据卡解决“目前知道什么”，行为假设解决“这版原型要回答什么”。本例先验证：把答案、来源和有效时间放在一起，能否让销售判断这条信息可不可以用于回复客户。不要把“搜索更快”“回答更准”“页面更好看”混成一次无法解释的验证。
对应的页面决策是：结果上方先呈现问题与简短答案；紧接着显示来源名称、更新时间和“查看来源”；反馈入口放在答案之后。这里并不需要先做复杂的聊天历史侧栏。
如果来源尚未确认，页面应呈现“还没有找到可引用的资料”，而不是给答案加一个含糊的“仅供参考”就算完成。无法确定答案时怎样继续，是这个功能本身的一部分。
用主路径收敛页面与异常
先写下主路径：输入问题 → 检查可访问且有效的资料 → 看答案和来源 → 打开对应段落 → 返回结果。再补无结果、访问受限与请求失败。四类页面可以包含多个状态，不需要为每种提示另建一个导航页面。
| 页面或状态 | 必须看见什么 | 下一步到哪里 |
|---|---|---|
| P01 搜索 | 问题输入框、当前检索范围、搜索按钮；全空白不能提交 | 有效输入进入加载状态，再到结果或无结果 |
| P02 结果 | 简短答案、KB-01来源、更新时间、“查看来源” | 点击引用进入P03；修改问题可再次搜索 |
| P03 来源详情 | 政策名称、有效状态、引用段落、返回入口 | 返回P02时保留原问题与结果 |
| P04 无结果/访问受限 | 无结果显示“未找到可引用资料”；直接打开无权访问链接显示“无法访问” | 可换个问法或返回搜索；权限问题由资料管理员处理 |
| P01 请求失败状态 | 保留问题，显示“搜索未完成，请重试” | 原地重试；不清空输入、不跳到空白页 |
权限错误与无结果不要混为一谈。搜索列表里不应先暴露KB-03，再用“权限不足”遮住正文；而用户从旧链接进入一份已失去访问权限的资料时，才需要一个不泄露内容的访问受限页面。两条路径的提示可以不同。
在墨刀白板上先摆出这些状态，或者直接在墨刀原型里建立低保真页面。第一版用灰阶框、真实问题和真实长度的文案即可，重点是来源入口能找到、异常后有出口。
在墨刀AI中生成第一版结构
有了证据卡和样本资料，再打开墨刀AI输入需求。AI生成原型图可以帮助起草页面和交互；业务规则仍来自刚才的约定。把“做个智能知识库”替换成以下完整指令：
为企业知识库搜索生成可编辑的桌面端低保真原型。
使用者：已登录的销售，在客户通话中查找政策。
本期目标：找到有权限且有效的答案，打开来源，返回后继续查询。
资料：
KB-01《退款处理说明》：有效、销售可读，更新时间09-01。
内容：先收集订单号，由客服根据订单状态确认是否受理，
不在搜索结果中承诺到账时间。
KB-02《旧版退款流程》：已失效，不进入当前答案。
KB-03《内部争议处理备忘》：销售无权限，不显示标题或摘要。
页面：P01搜索、P02结果、P03来源详情、P04无结果/访问受限。
P01输入“客户退款条件”，搜索后进入P02。
P02展示KB-01支持的答案、来源和更新时间。
P03高亮支持答案的原文，返回后保留问题和结果。
另补：空输入不可提交、加载反馈、无结果、请求失败重试。
无结果显示“未找到可引用资料”，提供修改问题和返回搜索；
访问受限不显示文档内容，提供返回搜索。
失败时保留输入；不得展示KB-02或KB-03内容。
不做：自动退款、跨部门权限扩展、推荐问题、多轮对话。
未明确的规则单独列为待确认，不能自行补成确定规则。
先列页面与状态清单，再生成主路径；不要用大段宣传文案填充页面。生成后先做三次实际点击：搜索问题能否到结果，来源能否打开，返回后问题是否还在。接着核对无结果、请求失败和无权限三种状态。只有画面，没有跳转或反馈的部分，需要继续在原型中补齐交互。
如果生成结果混入旧政策，可以这样追问，而不是重新生成整个项目：
仅修改P02及关联搜索状态：当前答案只能使用KB-01。
移除KB-02的摘要、引用和推荐，不改变P01布局及P03返回行为。
当可访问的有效资料均不能支持问题时，进入P04无结果状态。
请列出修改的页面和状态，其他内容保持不变。如果资料还不足以形成上面的指令，先停在证据卡；需要把范围、规则和待确认项写进文档时，接着使用AI生成产品文档教程里的资料包与PRD写法。
让参与者找答案，再找来源
低保真原型的价值，是用低成本暴露理解差异。把原型交给一位符合目标角色的人，给任务，不教路径：
你正在回复客户关于退款条件的咨询。请找出当前可以采用的政策说明，确认它是否有效，再打开支持你回复的原文。找到后，请说出你会怎样回复客户。
不要提醒“点这里看来源”。记录参与者实际上做了什么：是否直接复制答案、是否主动确认来源日期、是否能从原文返回。再给一个资料中没有答案的问题，观察他是否能继续行动。最后尝试直接打开无权访问的资料链接，检查是否泄露了文档内容。
| 任务 | 期望看见的行为 | 如果没发生，先改哪里 |
|---|---|---|
| 查找当前退款政策 | 找到KB-01并识别更新时间；不会采用旧资料 | 调整答案与来源的邻近关系，去掉过期资料入口 |
| 解释答案依据 | 打开来源并指出支持答案的段落 | 增加段落定位；让“查看来源”比弱灰色脚注更明显 |
| 查询资料未覆盖的问题 | 知道没有依据，并能修改问题或返回搜索 | 写清原因与下一步，不只显示“暂无数据” |
| 失败后重新搜索 | 问题仍在，点击重试可继续 | 补输入保留和重试状态，避免回到初始页 |
第三个任务的提问应来自知识库业务，例如“某地区的退款到账时限”，且样本资料里不含该答案。不要用明显无关的问题测试，否则难以判断真实业务下的无结果处理是否有效。
每次记录“任务—观察—修改—复查”，不要把主观意见直接当事实。例如下面这条是记录格式的填写样本：
任务：确认政策是否有效。
观察：参与者看完答案就准备回复，没有打开折叠的来源。
修改：将来源和更新时间移到答案下方的可见区域。
复查：换一个政策问题，再看参与者是否能自行说明依据。
这里的“通过”不等于整个产品已经验证完。它只表示这版原型里，回答和依据之间的路径足够清楚，值得继续细化。
把意见改成下一版能执行的改动
原型评审可以分三轮，避免讨论颜色时反复改业务范围：
| 轮次 | 本例讨论什么 | 结束时留下什么 |
|---|---|---|
| 结构 | 搜索、答案、来源和兜底路径是否齐全 | 页面范围与待确认规则 |
| 交互 | 返回、加载、失败、权限变化后怎样继续 | 状态表、按钮去向与具体提示文案 |
| 视觉 | 来源层级、正文阅读、间距与组件一致性 | 可继续交接的页面和明确的修改记录 |
当收到“结果页太复杂”时，追问“哪项任务因此受阻”；当收到“能不能再加个聊天入口”时，回到本期目标，判断它是否是完成查政策的必要条件。可以使用评论与版本记录保留决定，但每条决定仍要对应页面、负责人和后续动作。
本例完成后应有三份可用材料：写清范围的需求证据卡、列出正常与异常的状态表、能从任务观察落到修改动作的试走记录。下载知识库搜索工作表与完整生成指令，也可以使用页面状态与试走任务CSV直接分配工作。
已有第一版页面后，下一步是按反馈做小范围修改，可接着读AI原型迭代方法。不要因为一处来源展示不清，就重新生成整套页面。
需求不清楚时，几个常见取舍
需求不清楚，先写PRD还是先画原型？
先写最小证据卡，再让文档和原型并行。文档沉淀业务规则，原型暴露流程与状态问题。已有较完整文档时，可以参考需求文档怎么转成原型图提取页面，而不必重新从一句话开始。
能否直接用一句话生成原型来讨论？
可以把它作为收集问题的起点，但不要据此认定范围已确认。至少将生成结果中新增的角色、权限、数据和异常规则列出来，请对应负责人确认后再深化。
没有用户访谈材料，还能继续吗？
可以做低成本草稿，但把“用户需要”改成“当前假设”。先向需求提出者追问最近一次发生的具体事件，再找一个代表性任务试走；如果连任务和资料都没有，应先补材料，而不是用更精细的界面掩盖缺口。
多人协作时怎样避免版本分散？
把规则文档链接、原型和决策记录放在同一项目中，评审时明确版本与范围。需要整理完整协作入口时，可查看产品经理工具工作流；这一步最重要的是让团队能找到当前讨论的同一份方案。
