你把 40 分钟用户访谈录音转写稿丢给 Claude：「帮我提炼洞察。」回来的是漂亮的三点结论，可产品经理追问「用户原话是哪句」，你翻全文找不到对应——原话被抽象成「用户希望更高效」。第二天评审会上，没有原话支撑的洞察立刻被质疑。
丢原话通常因为你只要求「总结」，没要求「引用归档」。正确做法是：先抽主题，再强制每条洞察绑定可检索的原话与时间戳，最后才允许上升为洞察表述。
直接结论
访谈提炼必须采用「原话卡片 → 主题标签 → 洞察表述」三层，而不是直接写结论。每条洞察至少挂 1–2 句原话（尽量带时间码），并区分「用户原话 / 我的推断」。没有原话的洞察一律降级为待验证假设。
具体做法
1. 粘贴转写稿时保留说话人与时间码，告诉 Claude 不得改写引号内文字。
2. 先要求输出原话卡片，再聚类主题，最后写洞察。
3. 规定输出字段：主题、原话、说话人、时间、洞察、置信度。
你是用户研究助理。请处理下列访谈转写（保留原话，禁止润色引号内文字）。
输出顺序：
A. 原话卡片（至少12条）：字段=时间码/说话人/原话/初步标签
B. 主题聚类（5–7个）：每个主题下列出支撑原话编号
C. 洞察列表：每条必须含「洞察表述 + 支撑原话编号 + 推断边界」；无原话支撑的不得写成洞察
规则：洞察句避免空洞词（更好、赋能、体验升级）；若转写含糊，标注「听不清/需回听」。
转写稿：
{粘贴}
4. 抽查：随机点开 3 条原话回原文核对，防止模型拼接「假原话」。
注意点
第一，先写洞察再找原话，极易发生「结论驱动引用」，把不相干句子硬凑进去。
第二，合并多位用户原话时必须标注人数与冲突点，否则会把个例写成共识。
第三，模型会润色口语导致失去证据力；引号内必须保持原貌，注释另写。
可直接套用的完整提示词
角色：严谨的用户研究员。
任务：从访谈转写生成「可回溯」的洞察包。
输入：转写稿（含时间码/说话人）、研究问题：{…}
硬性输出：
1) 原话卡片表（Markdown）
2) 主题-原话映射
3) 洞察卡：每条含原话引用、适用边界、反例/矛盾点、建议验证方式
4) 给产品的一页结论（不超过8条子弹）
禁令：不得编造原话；不得把推断写成用户说过；空洞形容词删除。
若信息不足，先列需要回访的问题清单。
实操上可以建一个「原话库」表：编号、原话、标签、是否可对外引用。Claude 负责初填，你只审「像不像原话」与「能不能公开」。评审材料里只贴编号与短引，完整原话留在库中，既保留证据又控制篇幅。若同一主题下原话互相矛盾，必须并排呈现，而不是悄悄删掉反对意见——那会让洞察看起来更顺，却更假。
当你需要把洞察同步给设计或研发，再追加一列「对产品含义」与「建议验证实验」。这样提炼成果不是一页漂亮总结，而是能进入迭代排期的输入。定期回听 10% 的高权重原话，能显著降低模型幻觉引用的风险。