把访谈笔记变成需求简报

访谈做完了，下一步交什么？

访谈笔记里有抱怨、有建议，也有互相冲突的意见。把它们全部交给 AI，再让它“写一份需求文档”，很容易得到一份完整但无法追溯的方案。更好检查的做法是先整理原话，再区分问题、解释和候选方案。

练习材料只有六句话，可以放进已有的文字对话工具，也可以手工整理，不需要懂代码。下文的“排期本”和访谈均为原创虚构材料，不能当成真实用户研究结论。

先准备带编号的笔记

复制下面的材料，保留每行编号。用真实访谈替换时，先确认处理许可，去掉姓名、联系方式、客户名单和内部凭证。编号用于回查原句，不能让模型重新编造。

产品：排期本，虚构的团队活动排期工具。
材料 A：虚构运营者甲
A-01：我每次都要把活动日期从聊天里抄进自己的笔记。
A-02：同事改了日期，我通常到开会时才知道。
材料 B：虚构运营者乙
B-01：我只想看这个星期已经确认的活动。
B-02：还没确认的日期不要发给合作方。
材料 C：虚构项目负责人丙
C-01：暂时不想让所有人都能改日期。
C-02：如果每次改日期都弹出提醒，我可能会关掉提醒。

第一步：只整理原话，暂时不写功能

把材料粘贴到对话里，要求助手逐条列出：编号、逐字原话、这句话明确告诉了我们什么。缺少的信息写“材料未提供”，暂时不要给功能和优先级。

• A-01：原话“我每次都要把活动日期从聊天里抄进自己的笔记。”可确认：甲手工将聊天中的活动日期转抄到笔记。
• A-02：原话“同事改了日期，我通常到开会时才知道。”可确认：甲描述了获知日期变更较晚的情况。
• B-01：原话“我只想看这个星期已经确认的活动。”可确认：乙希望查看本周已确认的活动。
• B-02：原话“还没确认的日期不要发给合作方。”可确认：乙提出了对外提供日期的限制。
• C-01：原话“暂时不想让所有人都能改日期。”可确认：丙不希望当前对所有人开放日期编辑。
• C-02：原话“如果每次改日期都弹出提醒，我可能会关掉提醒。”可确认：丙表达了对逐次弹出提醒的顾虑。

“可确认”是对原话的概括，没有加引号，也不当作用户原话。

逐行对照输入。少一行、编号错了，或者引号里的内容被改写，都先改回来。这里不需要判断 AI 是否“懂产品”。

第二步：把问题和方案分开

看到 A-02，助手可能直接写“必须增加实时推送”。这一步跳得太快：原话没有说明通知为什么缺失，C-02 还表达了对频繁提醒的顾虑。

这条问题可以记成：

证据：A-02 表明甲较晚获知变更；C-02 表明丙顾虑逐次弹出提醒。
暂定解释：变更信息的获取方式可能不适合不同角色，需要进一步确认。
候选方案：变更记录、汇总提醒、按个人偏好通知；尚未选择。
待确认：变更频率、现有通知方式、需要获知的人、可接受的提醒频率。

这里的解释与方案是作者整理出的讨论选项，不能写成“用户已经要求”。有两种意见时先保留差异，不让模型把其中一种删掉，凑成一致结论。

第三步：整理成一页简报

核对完原话，要求助手按“背景、问题、候选需求、待确认事项”整理，每项问题都保留证据编号。

排期本：日期管理讨论稿

背景：虚构练习，材料来自三个虚构角色。当前只讨论日期管理，不代表真实用户验证或已批准的产品方案。

问题清单：

• 日期散在聊天和笔记里，存在手工转抄；实际重复工作量未知。【A-01】
• 获知变更的时间与提醒偏好存在差异；不能直接定为逐次弹窗。【A-02、C-02】
• 乙希望区分本周已确认活动与未确认日期，并限制未确认日期对外提供。【B-01、B-02】
• 当前不宜默认所有人都能编辑日期；具体授权角色未知。【C-01】

候选需求：

1. 活动列表可按“本周”和“已确认”查看。验收草案：筛选后只显示满足这两个条件的活动。确认状态由谁设置、日期以哪个时区计算，仍需讨论。【B-01】
2. 对外提供日期前能够识别未确认项。验收草案：让操作者明确看到确认状态；是否自动阻止发送、允许例外或采用人工核对，尚未决定。【B-02】
3. 对日期编辑与变更获知方式分别讨论。候选做法包括变更记录、汇总或按偏好通知；授权角色和通知形式都保持待决。【A-02、C-01、C-02】

暂不作出的决定：不承诺实时推送，不设计自动对外发送，不给需求编造高、中、低优先级。

下一次要问的问题：日期多久修改一次？谁负责确认日期？现有工具怎样通知变更？哪些人可以编辑？哪些日期可以对外提供？怎样判断“本周”及处理时区？这些答案均为材料未提供。