product-research

产品研究

将产品／用户研究作为一项运营规范：选择合适的方法，诚实地确定样本规模，并将研究结果综合为受治理的洞察。核心原则：方法必须与目标相匹配，且洞察需要在不同参与者之间反复出现——单条引述只是轶事。

用途

产品研究员、ResearchOps 团队以及负责开展探索研究的 PM，需要严谨的方法和可信的洞察库。这项技能会帮助你做出三项决策：

三个确定性工具：

1. study_designer.py — 根据（研究目标 × 产品阶段）匹配合适的方法，并生成与方法相匹配的计划框架（目标、参与者标准、访谈指南结构、成功标准）。将实时 A/B 测试转交给 product-team/experiment-designer。
2. saturation_planner.py — 按方法提供样本量建议，并明确标注置信度：Nielsen 问题发现（每个细分组 5 人）、Guest 等人的主题饱和度（约 12 人）以及评估覆盖度。绝不根据小样本可用性测试推断普及率。
3. insight_synthesizer.py — 按标签对编码后的观察进行聚类，统计不同参与者数量，按跨参与者重复出现的情况排序，并将任何低于来源门槛的候选项标记为轶事，绝不将其升级为洞察。

适用场景

遇到以下情况时，请使用这项技能：

• 你正在规划研究，需要让研究方法与目标相匹配（生成式、评估式或验证式）。
• 你需要有依据的样本量／饱和度理由，并明确说明置信度。
• 你有原始编码观察，需要在不过度声称的前提下综合形成洞察。
• 你正在搭建或审查研究库，需要严格区分洞察与观察。

不要将这项技能用于：生成用户画像／用户旅程图（请使用 product-team/ux-researcher-designer）、规划探索冲刺或验证机会（请使用 product-team/product-discovery）、设计或分析正在进行的产品 A/B 实验（请使用 product-team/experiment-designer），或开展市场规模评估／调查（请使用同级的 market-research）。

工作流

1. 明确研究框架 — 填写 assets/research_plan_template.md（研究问题、方法依据、参与者标准、分析计划、知识库标签方案）。
2. 选择方法 — 运行 study_designer.py --goal {discovery|evaluative|validation} --stage {concept|prototype|beta|live} --profile {b2b-saas|consumer-app|enterprise|marketplace|hardware|platform}。如果流程转向 experiment-designer，请遵循该转向。
3. 确定样本量 — 运行 saturation_planner.py --method {usability|thematic|evaluative-coverage} --segments N。记录置信度标签及其局限。
4. 综合分析 — 实地研究完成后，对观察结果进行编码，并运行 insight_synthesizer.py --input observations.json --min-sources 3。将标记为轶事的聚类视为需要进一步探究的信号，而不是可以发布的发现。
5. 录入知识库 — 在综合分析时，按照原子化架构为洞察添加标签，并记录其证据和置信度。

脚本

脚本	用途	配置
scripts/study_designer.py	（目标 × 阶段）→ 方法 + 计划框架	b2b-saas, consumer-app, enterprise, marketplace, hardware, platform
scripts/saturation_planner.py	基于方法的样本量建议 + 置信度	不适用（由方法决定）
scripts/insight_synthesizer.py	对观察进行聚类，标记轶事	不适用（由证据决定）

三个脚本均仅使用标准库，支持 --help、--sample、--output {human,json}。

入门与自定义

开始前先运行一次入门问卷 — 它会记录你的默认设置，让此技能中的每个工具都预先配置好。自定义是重点：答案会实际改变工具行为（例如，洞察的来源阈值）。

python3 scripts/onboard.py            # interactive (also: --defaults, --set key=value, --reset)
python3 scripts/onboard.py --show     # see the questions + current effective config

答案会保存到 ~/.config/research-ops/product-research.json（全局）或 ./.research-ops/product-research.json（--scope project），并由 config_loader.py 自动读取。它们会设置默认的产品档案、洞察来源阈值（一项发现要成为洞察，而非轶事，所需的独立参与者数量）、默认的饱和度方法以及高风险标记。CLI 标志始终优先于已保存的配置；RESEARCH_OPS_NO_CONFIG=1 会忽略该配置。

**四个问题：**产品档案 · 洞察来源阈值 · 饱和度方法 · 高风险标记。

使用 autoresearch 优化（可选启用）

此技能附带一个隔离的、可选启用的桥接工具，连接到 engineering/autoresearch-agent。只有在你要求“优化综合分析”/“运行循环”时，autoresearch 实验才会迭代优化固定证据集的编码/聚类，从而显现更多跨参与者模式。scripts/ar_evaluator.py 是真实情况评估器；它会输出 validated_insights: <int>（数值越高越好）。它优化的是编码，绝不伪造证据。

/ar:setup --domain custom --name insight-synthesis \
  --target observations.json \
  --eval "python3 ar_evaluator.py --target observations.json" \
  --metric validated_insights --direction higher
/ar:loop custom/insight-synthesis

隔离运行：没有硬性依赖 — autoresearch 只会按需运行，且循环只会编辑 observations.json，绝不会编辑评估器。

参考资料

• references/research_methods_canon.md — Portigal 的 Interviewing Users；Christensen/Ulwick 的 JTBD；Rohrer 的 UX 研究方法概览（NN/g）；Sauro 与 Lewis 的 Quantifying the User Experience；Goodman/Kuniavsky。
• references/sampling_and_saturation.md — Nielsen 的“测试 5 位用户”；Guest、Bunce 与 Johnson 的饱和度研究；Faulkner 关于超过 5 位用户的研究；Sauro 的可用性测试样本量；Braun 与 Clarke 的主题分析。
• references/repository_and_synthesis.md — ResearchOps / 原子研究（Tomer Sharon 的“Polaris”）；洞察与观察的区分原则；知识库治理；亲和图法；研究普及化防护措施。

假设

• 方法选择假设你能如实说清目标；如果目标模糊，就先追问清楚（目标决定一切）。
• 饱和度指南基于方法，而非统计效能计算 — 可用性测试用于发现问题，而非测量问题发生率。
• 综合分析器统计你提供的证据；编码质量是它的上游因素。糟糕的标签 → 糟糕的聚类。
• 洞察阈值（--min-sources）默认为 3；对于高风险情况或异质人群，应调高阈值。

反模式

• 方法与目标不匹配。 可用性测试无法发现未满足的需求；访谈无法衡量任务成功率。
• 将可用性问题报告为百分比。 小样本测试揭示的是问题，而非总体发生率。
• 将轶事提升为洞察。 一位参与者提供的是值得进一步探究的信号，而非发现。
• 把访谈问题设计成对功能的反应评价。 应探究待完成的任务和近期的真实行为，而非假设性的观点。
• 未建立知识库方案就进行综合分析。 应在综合分析时打标签，否则洞察会逐渐腐朽，难以查找。

与以下项目的区别

相邻项目	范围	区别
product-team/ux-researcher-designer	与设计产出相关的用户画像、旅程图、可用性框架	它产出成果物；这里关注的是方法 + 仓库规范
product-team/product-discovery	机会验证、发现冲刺规划	它规划发现冲刺；这里设计并综合研究
product-team/experiment-designer	线上产品 A/B 假设 + 样本量	它开展线上实验；这里开展定性／评估性研究
market-research（同级项目）	市场规模测算、问卷、细分	它研究市场；这里研究用户
interview-mapper（同级项目）	逐字稿级编码：逐字引语核验、按维度编码、跨轮次共识	它编码逐字稿本身；这里将已编码的观察综合为洞见——绝不接触原始逐字稿

快速示例

python3 scripts/study_designer.py --sample
python3 scripts/saturation_planner.py --method thematic --segments 3
python3 scripts/insight_synthesizer.py --sample --min-sources 3

综合器示例正确地将“import-confusion”（3 名独立参与者）提升为 INSIGHT，并将“wants-slack”（1 名参与者）标记为 ANECDOTE。

强制提问库（Matt Pocock 式拷问规范）

由 /cs-grill-research-ops 或编排器逐个提问。每个问题都提供建议答案和典范引用。绝不将问题捆绑提问。

1. “这项研究是生成式（发现问题）还是评估式（测试解决方案）？” 建议：先明确类型——方法取决于目标。 典范：Rohrer，《何时使用哪种用户体验研究方法》（NN/g）。

2. “你的样本量和饱和度依据是什么——置信度如何？” 建议：根据方法确定样本量（每个细分群体做 5 次可用性测试；主题饱和约需 12 人），并说明置信度。 典范：Nielsen；Guest、Bunce 和 Johnson（2006）；Faulkner（2003）。

3. “有多少名独立参与者支持每条洞见——还是说这只是单一来源的轶事？” 建议：至少要求 ≥3 个来源中重复出现，才称之为洞见；标记仅出现一次的内容。 典范：原子化研究／ResearchOps；Braun 和 Clarke 的主题分析。

4. “你的访谈／可用性任务是围绕结果（待完成的工作）来设计，还是围绕对功能的反应来设计？” 建议：围绕待完成的工作和近期真实行为来设计，而非假设性的观点。 典范：Christensen／Ulwick 的待完成工作理论；Portigal 的《访谈用户》。

5. “这些内容会存放在仓库的什么位置？如何添加标签以便复用？” 建议：在综合时就按原子化模式添加标签，而不是之后再处理。 典范：Tomer Sharon，《Polaris》／ResearchOps 仓库实践。

按深度优先的顺序推进。先锁定 1–2，再开始 3–5。所有问题回答完毕后，调用 study_designer.py → saturation_planner.py →（实地研究之后）insight_synthesizer.py。