研究

从访谈记录提取需求和证据

把行为、目标、约束和未满足需求追溯到访谈证据，不把请求直接变成需求

9 分钟准备已测试:ChatGPT复核日期: 2026-08-28

补充你的背景

你填写的内容只保留在当前浏览器中，AILesson 提示语不会将其发送给模型或服务器。

访谈记录研究框架分析规则

生成的提示语

未填写的字段会保留为占位符，你仍然可以复制后自行编辑

请从所给访谈记录忠实提取用户需求与证据。

转写或笔记、参与者ID、时间戳、会话背景、提问、纠正、产物、同意和缺口：
[records]

研究问题、样本、招募、决策、术语、假设和排除解读：
[study]

编码单位、需求格式、引语权限、隐私、置信度、最小证据、反例、审核流程和结构：
[analysis]

分开参与者报告、观察行为、产物证据、主持提问、研究者解读和产品请求。提取近期情境、触发、目标、当前行动、替代、故障、约束、后果、决策标准、权宜方法、期望进展和反例，并关联参与者与时间戳或定位。需求陈述应独立于方案且包含情境，不写人口刻板印象或功能愿望。“发送提醒”等请求是拟议方案证据；只有行为和背景支持时才把底层需求写成带标签假设。保留单次与跨会话矛盾、沉默或缺失证据、样本与招募限制及主持诱导影响。一个参与者重复陈述不计为多人。每个主题给出唯一参与者、证据定位、支持与反对案例、置信理由、受影响角色和情境、未知及下一验证问题。遮盖未授权个人或客户数据。最后列出可安全报告的事实、需复核的解读和样本不能支持的主张。

默认保护隐私提示语在浏览器本地组装。除非所在组织明确允许，否则不要把机密信息提交给任何 AI 服务。

从输入到成果

实际案例

看看具体背景如何通过这条配方转化为可使用的成果

实际输入

访谈记录: P01 12:10：近期客户审核Ready三天；P01查看Teams两次并联系项目负责人，因为未显示接收者。15:02说‘一直发邮件直到我回复。’P02 08:40：隔夜Ready是有意的，因为客户在另一时区；10:15说更多邮件会成为噪声。P03 19:22：因为期待@提及而漏掉一次交接；截图显示负责人但无接收者。主持人在20:00问‘自动提醒会解决吗？’P03回答‘可能。’P04只有笔记无时间戳：用每日队列，并说延迟Ready通常在等批准。全部从支持联系人招募；批准短引语，不批准客户名。
研究框架: 问题：什么情境形成长Ready，什么信息让行动成为可能？决策：探索邮件提醒、责任提示或都不做。4名参与者：2名负责人、1名接收者、1名请求者；英国/德国。支持招募可能过度代表问题。接收者指有权确认下一状态者。不得推断市场比例或功能需求。
分析规则: 编码单位为近期交接实例。需求格式：当[情境]时，角色需要[进展]，从而[结果]，证据为[行为]。按唯一参与者计数，至少2人形成跨参与者主题，但保留单案例。含反例。引语少于15词，带参与者/时间。遮盖客户。两名研究者独立复核解读。

示例输出

主题1——识别谁能接收交接，中等置信，2名唯一参与者证据：P01因未显示接收者而两次查看Teams并联系负责人（12:10）。P03期待@提及；产物显示负责人但无接收者（19:22）。需求假设：当交接就绪但接收责任不清时，行动角色需要识别获授权接收者，以便不在人群中搜索就能引导下一行动。行为和产物支持该假设，但角色与频率需确认。反例：P04的延迟通常等审批，可能权限已知而非缺失。

主题2——区分有意等待与错过行动，中等置信，2名不同情境参与者 P02因时区有意等待（08:40）；P04报告等待审批。需求假设：Ready持续时，各角色需要知道原因和预期下一事件，从而决定等待还是干预。这不等于需要提醒。

方案请求与诱导影响 P01的“一直发邮件直到我回复”（15:02）是功能建议，不证明重复邮件满足底层需求。P02是反例：“更多邮件会成为噪声”（10:15）。P03的“可能”紧跟主持人的诱导提醒问题（20:00），作为需求证据质量低，不计为独立验证。

可安全报告事实：2名参与者遇到不显示接收者的产物；1人报告有意时区等待；1人报告审批等待。解读需两名研究者复核。样本不能支持普遍性、细分比较、因果或开发提醒的建议。下一问题：在更广、已同意样本中，近期实例能否按接收者已知/未知、有意等待、外部审批、错过信号和其他原因分类？