把访谈记录做成洞察摘要，没有永远更稳的一家。每条洞察都要能指回原话，并保留少数意见。材料在对话里偏 Claude，在仓库里偏 Codex，补公开背景才用 Grok。
要点
- 本稿比的是：把用户访谈转写做成洞察摘要。它和技术说明、故障排查 Runbook、会议记录三栏不是同一类活。后几篇见站内旧文。这里说的“稳”，指每条洞察都能指回你提供的原话或时间戳，频次写诚实，少数意见和反例留在正文，指不回的进未知节。不是自行跑分，也不做永远冠军。（三工具对照：写技术说明文档谁更稳、三工具对照：写“故障排查 Runbook”谁更稳、Claude：把会议记录压成“决策／待办／开放问题”三栏）
- Claude 长处是把脱敏后的访谈指南、编码表和转写放进 Project 知识库，用项目指令锁住“禁止编造引语”，再在 Artifacts／Docs 里反复改同一份摘要。项目名和描述 Claude 读不到，关键纪律要写进指令和知识库。Projects 是否对你的账号开放，以登录后现页为准。（How can I create and manage projects?；What are artifacts and how do I use them?）
- Codex 长处是对着仓库里的转写文件做结构化抽取：能读文件、改文档，并跑你机器上已有的命令，把主题、原话、受访者编号和时间戳收成表。它适合先出证据表，再写摘要；不适合在没有编码规则时，直接替你判断“用户到底想要什么”。（Codex CLI；Best practices）
- Grok 长处是实时检索网页和 𝕏。访谈洞察的主证据在你提供的转写里，不在公开检索里。需要核对受访者提到的公开产品或新闻时，可以另开一轮检索；不要把训练记忆或检索到的行业通识，写进“访谈发现”。消费端也可以上传文件，但私有访谈仍以你粘贴或上传的脱敏材料为准。（Grok 产品页；Consumer FAQs）
- 可混用：Codex 先出原话证据表，Claude 按编码表写成洞察摘要，Grok 只补公开背景。人工终核抽几条原话回听或回看转写。上传前按你们团队的规定做脱敏。
正文
场景
你手里有八份用户访谈转写，要对同事交一份洞察摘要。分别丢给三个工具，常出现三种走样。一份写得很满，其中两句原话在转写里找不到。一份把两名用户的抱怨写成“用户都希望立刻做 X”。一份检索了行业评论，结论很完整，你们访谈里真正说过的句子却很少出现。
会议记录要压成决策、待办和开放问题，是另一件事。访谈洞察要回答：人们说了什么，多少人这么说，谁不同意，以及哪些判断还缺少材料。
下面用同一份任务、同一套完成定义对照三家。结论先说清：没有永远更稳的工具；按材料在哪里选型。相对判断来自产品能力和公开资料，不是自行测得的正确率。
可跟做步骤／可抄工作流
1. 统一任务与完成定义（三家共用）
开工具前先把合同贴在提示顶部。访谈材料常含姓名、联系方式和产品未公开细节，先按你们的规定脱敏，再上传或粘贴。
【文档任务】给产品／研究同事看的用户访谈洞察摘要（不是对外稿，也不是会议纪要三栏）
【材料】我提供的访谈转写、访谈指南和既有编码表；未提供的背景不许补进“发现”
【读者】本团队，已有权阅读这些脱敏转写
【必含节】
1. 材料范围（访谈份数、角色、时间范围；只写材料里有的）
2. 主题洞察（每条都写：洞察一句话、支持这条的原话、来自哪些访谈编号、反例或少数意见）
3. 频次与限度（多少人提到、多少人未提及或反对；不要写成全体用户）
4. 未知与待追问（单独一节，禁止删掉）
【禁止】
- 编造原话、受访者、场次或时间戳
- 把两三人的说法写成“用户都……”
- 用公开报道或训练记忆填补转写里没有的动机
- 在摘要里保留可识别的姓名、联系方式或其他未脱敏信息
【完成定义】
- 每一条洞察都能指回转写中的原话或时间戳
- 指不回的必须进“未知与待追问”
- 先给目录再给正文；原话与洞察分开写，不要把转述写成引号里的原话“未知与待追问”删不得。删掉就等于鼓励它把猜想写成发现。
2. 五轴对照（访谈洞察摘要场景）
| 评价轴 | Grok | Claude | Codex／Cursor 改仓 |
|---|---|---|---|
| 1 原话锚点 | 弱在进不了你的私有转写，除非你粘贴或上传；检索到的公开评论不能冒充访谈原话 | 强在你粘贴／上传的转写和编码表；可要求先摘原话再写洞察 | 强在直接读仓库里的转写文件，并抽出带路径的原话表 |
| 2 不过度概括 | 容易把行业通识写进发现，必须靠未知节和“只依据材料”拦住 | 项目指令可写死“禁止写成全体用户”；仍要你抽查频次 | 适合先计数、后下判断；判断句仍要人看 |
| 3 结构稳定 | 提示写清时可用；容易扩成行业综述 | Artifacts／Docs 便于盯着同一份摘要按主题改 | 可按仓库里已有的研究模板续写，并落成可审的文档 |
| 4 公开背景 | 要核对访谈里提到的公开产品或新闻时，这是它的主场 | 需要时再开 Web search；默认仍偏你提供的材料 | 可用实时网页搜索补公开文档；主场仍是本地文件 |
| 5 材料入口与隐私 | 消费端可上传文件；不适合把未脱敏的访谈送去公开检索 | Project 知识库适合反复使用同一批脱敏材料；不要放可识别信息 | 转写已在仓内时最省事；仓本身的权限和脱敏规则仍要你先定 |
读表时先问证据在哪。证据在你粘贴的转写和编码表里，偏 Claude Project。证据已经以文件形式放在仓库里，偏 Codex。只有需要核对公开背景时，才轮到 Grok。
3. 三家怎么开跑（可跟做）
A. Claude（编码表和多轮打磨向）
- 建或打开一个 Project。把脱敏后的访谈指南、既有编码表和转写放进知识库。不要放姓名、联系方式或未公开的密钥。
- 项目指令写入完成定义里的禁止项，尤其是“禁止编造原话”和“未知节不得删除”。关键纪律不要只写在项目名称里，官方写过：Claude 读不到项目的名称和描述。
- 新开聊天，先让它按访谈编号列出拟引用的原话，你抽查几条，再写摘要。要求输出到 Artifacts／Docs，方便按主题改。
- 每轮只改一组主题，改完仍要保留反例和未知节。
B. Codex／Cursor（仓内转写和证据表向）
- 在放着脱敏转写的仓库目录打开 Codex CLI，或 Cursor 里的 Codex。权限保持工作区内读写，不要为了“一次分析完”解开沙箱。
- 先只读：列出转写路径、场次编号，以及拟引用原话所在的文件位置。没读到的原话不许写进摘要。
- 提示可以接在完成定义后面：
先只读：为每份转写列出路径、场次编号，以及与“结账摩擦”“价格疑虑”相关的原话位置。
确认后：在 docs/research/interview-insights.md 写出洞察摘要，遵守上方完成定义。
只改这份文档，不要改转写原文，也不要新增未出现在材料里的受访者。- 看 diff：原话是否还在文件里，有没有把计划中的产品判断写成访谈发现。
C. Grok（公开背景补充向）
- 打开 grok.com 或官方 App。访谈发现只依据你粘贴的脱敏摘录，不要把完整未脱敏转写丢进检索。
- 需要核对受访者提到的公开产品、更新说明或新闻时，另开一轮 Search，要求每条背景都带可点链接。
- 背景节和“访谈发现”分开写。检索来的行业评论，不能写进发现。
- 法律 FAQ 写过，输出可能不准确，用前须核验。原话仍以你手里的转写为准。
消费端精确按钮文案、套餐是否包含搜索或 Projects，以各产品现页为准。
4. 推荐混用，以及人必须留下的那几步
- Codex 先出“原话证据表”：洞察候选｜原话｜访谈编号｜文件位置。
- Claude 按编码表写成摘要，未知节留空位。
- 只有需要核对公开背景时，才让 Grok 补一节外链。
- 你自己抽若干条原话，回到转写或录音核对。频次也要手算一遍粗数。
- 定稿按你们的研究文档规范保存，避免聊天里的“最新版”和仓内摘要各写各的。
一次生成可以交差。能给同事用的洞察，还要有原话锚点、少数意见和至少一次抽查。
真实用户诀窍／反例
- 诀窍：先抽原话，再写洞察。 顺序倒过来，编造和写满会一起出现。
- 诀窍：每条洞察都留反例位置。 没有反对意见，就明确写“材料中未见反对”，不要假装已经形成共识。
- 诀窍：人数写成“8 人中的 3 人”，不要写成“用户普遍”。
- 反例：三家各出一版，挑最顺的当胜者。 最顺的往往掺了找不到的原话。
- 反例：对 Grok 说“根据我们这批用户访谈”。 它看不见，除非你粘贴脱敏摘录。
- 反例：让 Codex 在没有编码规则时直接给战略结论。 先要证据表。
- 反例：把未脱敏的访谈上传到任何消费端工具。 先按团队规定处理。
- 反例：把会议三栏模板套在访谈上。 决策和待办不是这批材料的主产出。
适用边界
- 本稿覆盖：用户访谈转写做成洞察摘要时的工具选型与可抄完成定义。不是编程能力总榜，也不是可用性测试的统计方法评测。
- 不覆盖：合规审计、正式的学术编码可靠性计算，以及对外发布的用户证言。那些还要各自的授权和模板。
- 产品功能名、按钮文案、Projects 和检索是否对你的账号开放，随版本变化，以各产品现页为准。
- “更稳”指在对应材料入口下更少无锚点编造、更少把少数人写成全体用户的工作流倾向，不是正确率百分比。