user-research

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Simulated User Research — 三阶段用研法

Simulated User Research — Three-Phase User Research Methodology

方法论核心

Core Methodology

传统模拟用研的致命缺陷是先射箭再画靶——在角色 Prompt 中预设痛点和产品态度,导致角色只能说出研究者想听的话。
本方法的解决方案是灵魂设定 + 自由生长 + 产品碰撞
  1. 只定义角色的灵魂(背景、性格、认知方式),不预设任何痛点或产品态度
  2. 让角色自由讲述工作和生活,痛点从内在逻辑自然浮现
  3. 角色带着自己的故事去碰撞产品概念,反应更真实
The fatal flaw of traditional simulated user research is "shooting the arrow first then drawing the target" — predefining pain points and product attitudes in persona prompts, which causes personas to only say what researchers want to hear.
The solution of this methodology is Soul Definition + Free Growth + Product Collision:
  1. Only define the soul of the persona (background, personality, cognitive style), without predefining any pain points or product attitudes
  2. Let the persona freely talk about their work and life, with pain points emerging naturally from their internal logic
  3. The persona interacts with product concepts based on their own stories, resulting in more authentic responses

完整 Pipeline

Complete Pipeline

Step 0 准备 → Phase 1 自由生长 → V1 叙事质量验证
→ Phase 2a 逐角色提取(并行)→ Phase 2b 交叉分析 → V2 分析严谨性验证
→ Phase 3 产品碰撞(并行)→ V3 人设一致性验证
→ Step 4 综合报告 → V4 报告完整性验证
Step 0 Preparation → Phase 1 Free Growth → V1 Narrative Quality Validation
→ Phase 2a Per-Persona Extraction (Parallel) → Phase 2b Cross-Analysis → V2 Analytical Rigor Validation
→ Phase 3 Product Collision (Parallel) → V3 Persona Consistency Validation
→ Step 4 Comprehensive Report → V4 Report Completeness Validation

执行流程

Execution Process

Step 0:准备

Step 0: Preparation

读取用户提供的配置,确定:
  1. 外部数据(可选):如果用户提供了已有的真实用研数据(访谈记录、工单、NPS 反馈、App Store 评论等),读取并整理。这些数据将在 Phase 2 中与模拟数据交叉验证——模拟角色自然浮现的痛点如果在真实数据中也出现,信号强度翻倍;反之则需要标注差异。
  2. 角色列表:如果用户提供了 persona 配置文件(
    $1
    ),读取它。否则询问用户要模拟哪些角色。
    角色设定必须严格遵循灵魂原则——只定义一个真实的人是什么样的,不预设他遇到了什么问题。每个角色需要且仅需要:
    • 基础信息:年龄、性别、城市
    • 职业背景:行业、职位、从业年限、专注领域、工作规模/节奏
    • 性格标签:3-5 个关键词(他的朋友会用来形容他的词)
    • 当前工具栈:日常使用的工具和系统
    • 认知水平:对新技术/新工具的态度和接受倾向
    • 绝不包含:预设痛点、对产品的态度、预设行为模式、付费意愿、功能需求
    判断标准:如果这个人真实存在,他的朋友会不会用这些词描述他?「她性格犀利」✅ 「她觉得现有工具不够智能」❌
    角色组合检查清单 — 确保这组角色之间有足够的差异性:
    必须覆盖的差异轴:
    • 资历梯度:新手(0-2 年)/ 中段(3-7 年)/ 资深(8 年+)
    • 组织规模:个人/自由职业 / 小团队(< 20 人)/ 大机构(> 100 人)
    • 技术接受度:保守型 / 中立型 / 尝鲜型
    建议覆盖的差异轴:
    • 城市线级(一线 / 新一线 / 二三线)
    • 性别
    • 细分领域(如果目标行业有多个细分方向)
    快速自检:「如果这组角色坐在同一张桌子上,他们会不会因为视角不同而吵起来?如果不会,说明不够多样。」
    如果角色列表不满足上述检查清单(例如全部是同一资历层或同一组织规模),应提示用户调整或自动补充差异化角色。
  3. 产品概念:读取用户提供的产品愿景文档(
    $2
    )。
    • 单概念模式
      $2
      指向一个文件,Phase 3 只碰撞这一个概念
    • 多概念模式
      $2
      指向多个文件或一个目录(内含多个概念文件),Phase 3 对每个概念分别碰撞,综合报告增加「概念对比」章节
    如果没提供,Phase 1-2 仍可执行,Phase 3 时再要求。
  4. 输出目录:在项目中创建
    docs/user-research-{日期}/
    目录。

Read the configuration provided by the user and confirm:
  1. External Data (Optional): If the user provides existing real user research data (interview records, work orders, NPS feedback, App Store reviews, etc.), read and organize it. These data will be cross-validated with simulated data in Phase 2 — if pain points naturally emerging from simulated personas also appear in real data, the signal strength doubles; otherwise, the differences need to be marked.
  2. Persona List: If the user provides a persona configuration file (
    $1
    ), read it. Otherwise, ask the user which personas to simulate.
    Persona settings must strictly follow the Soul Principle — only define what a real person is like, not what problems they encounter. Each persona needs and only needs:
    • Basic Information: Age, Gender, City
    • Professional Background: Industry, Position, Years of Experience, Focus Area, Work Scale/Rhythm
    • Personality Tags: 3-5 keywords (words his friends would use to describe him)
    • Current Tool Stack: Tools and systems used daily
    • Cognitive Level: Attitude and acceptance tendency towards new technologies/new tools
    • Absolutely No: Predefined pain points, attitudes towards products, predefined behavior patterns, willingness to pay, functional requirements
    Judgment Criterion: If this person really exists, would his friends use these words to describe him? "She has a sharp personality" ✅ "She thinks existing tools are not intelligent enough" ❌
    Persona Combination Checklist — Ensure sufficient differences among this group of personas:
    Must cover the difference axes:
    • Seniority Gradient: Novice (0-2 years) / Mid-career (3-7 years) / Senior (8+ years)
    • Organization Scale: Individual/Freelancer / Small Team (<20 people) / Large Organization (>100 people)
    • Technology Acceptance: Conservative / Neutral / Early Adopter
    Recommended difference axes to cover:
    • City Tier (First-tier / New First-tier / Second- and Third-tier)
    • Gender
    • Sub-field (if the target industry has multiple sub-directions)
    Quick Self-check: "If this group of personas sat at the same table, would they argue due to different perspectives? If not, it means they are not diverse enough."
    If the persona list does not meet the above checklist (e.g., all are at the same seniority level or same organization scale), prompt the user to adjust or automatically add differentiated personas.
  3. Product Concept: Read the product vision document provided by the user (
    $2
    ).
    • Single-concept Mode:
      $2
      points to one file, only this concept will be tested in Phase 3
    • Multi-concept Mode:
      $2
      points to multiple files or a directory (containing multiple concept files), each concept will be tested separately in Phase 3, and the comprehensive report will add a "Concept Comparison" chapter
    If not provided, Phase 1-2 can still be executed, and it will be requested in Phase 3.
  4. Output Directory: Create a
    docs/user-research-{date}/
    directory in the project.

Step 1:Phase 1 — 自由生长

Step 1: Phase 1 — Free Growth

为每个角色并行启动一个 Agent(使用 Agent 工具,
run_in_background: true
),Prompt 结构:
你是一个用户研究员,正在做一场深度访谈。你的受访者是 {角色名}。

**关于 {角色名} 的全部信息(只有这些,没有更多):**
{仅灵魂设定,不含任何痛点或产品概念}

**你的任务:**
以 {角色名} 的视角,用第一人称,写一份深度自述。不是采访问答格式,而是在一个放松场合自然聊起工作时会说的话。

按以下节奏展开叙述(自然过渡,不要标注段落编号或标题):

**热身**:先随便聊聊最近的状态,最近在忙什么,心情怎么样。让角色进入自己的语境。

**日常流**:一天的工作是怎么过的——信息怎么流动,在哪些环节和工具间切换,跟谁打交道最多,哪些是例行公事哪些要动脑子。

**深潜**:
- 一个最近很挫败的具体案例——要有时间线、有对话、有情绪转折
- 一个最近很得意的具体案例——同样要具体到细节
- 这两个案例之间有没有什么关联或反差?

**远望**:对自己所在行业/职业的观察,觉得这行在往哪走,自己在这个变化中处于什么位置。

**许愿**:如果有一根魔法棒,最想改变工作中的哪一件事?为什么是这件而不是别的?

**关键约束:**
- 绝对不要提到任何具体产品名称或工具概念
- 角色的所有痛点、不满、渴望必须从性格和经历中自然生长出来
- 不要把角色写成一个"有一堆问题等待被解决"的人,写成一个有血有肉的人
- 每个部分自然过渡,不要出现生硬的话题切换

输出要求:中文,3000-4000 字,自然口语化,有角色独特的语气和节奏
每个 Agent 将结果写入
docs/user-research-{日期}/phase1-{角色名}.md
等待所有 Agent 完成后进入 V1 验证。

Launch an Agent in parallel for each persona (using the Agent tool,
run_in_background: true
), with the Prompt structure:
You are a user researcher conducting an in-depth interview. Your interviewee is {Persona Name}.

**All Information About {Persona Name} (Only These, No More):**
{Only soul definition, no pain points or product concepts}

**Your Task:**
From {Persona Name}'s perspective, write an in-depth self-narration in the first person. It should not be in the format of interview questions and answers, but rather what they would naturally say when talking about their work in a relaxed setting.

Unfold the narrative in the following rhythm (transition naturally, do not mark paragraph numbers or titles):

**Warm-up**: First, casually talk about the recent status, what you've been busy with, and how you're feeling. Help the persona get into their context.

**Daily Routine**: How a day at work goes — how information flows, which tools and systems you switch between, who you interact with the most, which tasks are routine and which require thinking.

**Deep Dive**:
- A recent specific case of frustration — with timeline, dialogue, and emotional turning points
- A recent specific case of pride — also with specific details
- Is there any connection or contrast between these two cases?

**Long-term Observation**: Observations about your industry/profession, where you think the industry is heading, and your position in this change.

**Wish**: If you had a magic wand, what is the one thing you most want to change in your work? Why this one instead of others?

**Key Constraints**:
- Absolutely do not mention any specific product names or tool concepts
- All pain points, dissatisfactions, and desires of the persona must naturally emerge from their personality and experiences
- Do not write the persona as a "person with a bunch of problems waiting to be solved", but as a flesh-and-blood person
- Each part transitions naturally, no abrupt topic switches

Output Requirements: English, 3000-4000 words, natural and colloquial, with the persona's unique tone and rhythm
Each Agent writes the result to
docs/user-research-{date}/phase1-{persona-name}.md
.
Wait for all Agents to complete before entering V1 validation.

V1:叙事质量验证

V1: Narrative Quality Validation

启动一个独立的验证 Agent(使用 Agent 工具),Prompt:
你是一个用研质量审计员。读取以下 Phase 1 叙事文件,对每个角色逐一评估,然后做跨角色评估。

**需要读取的文件:**
{所有 phase1-*.md 文件路径列表}

**逐角色检查(每个角色独立判定):**

1. 字数:≥ 2500 字 PASS,< 2500 字 BLOCK
2. 具体性:是否有具体的时间("上周三")、人名/角色("我们组的老张")、对话(直接引语)、数字("8 个需求同时跑")?每类至少出现 2 次 PASS,否则 FLAG
3. 五段覆盖:热身/日常流/深潜/远望/许愿是否都有实质内容?缺失任何一段 FLAG
4. 人设一致性:叙事中展现的性格/工作方式是否与灵魂设定一致?矛盾处 FLAG
5. 预设污染:是否出现了灵魂设定中没有的、像是预设植入的痛点或产品态度?出现则 BLOCK

**跨角色检查:**

6. 差异度:任意两个角色的挫败案例或日常流是否高度相似(主题相同、叙事结构雷同)?相似对 FLAG
7. 视角覆盖:这组角色是否覆盖了不同资历层次和工作模式?全部同质则 FLAG

**输出格式:**
每个角色一个判定(PASS/FLAG/BLOCK)+ 具体问题描述。
跨角色一个判定。
最终总判定:全 PASS → 进入 Phase 2;任何 BLOCK → 列出需要重新生成的角色及原因。

将验证报告写入 {输出目录}/v1-validation.md
处理逻辑
  • PASS:进入 Phase 2
  • FLAG:记录问题但继续(问题会在综合报告的局限性中提及)
  • BLOCK:重新生成对应角色的 Phase 1,在 prompt 中附上具体改进要求(如「字数不足,需要在深潜部分增加更多细节」「出现预设污染,去除以下内容:…」),重新生成后再次验证

Launch an independent validation Agent (using the Agent tool), with the Prompt:
You are a user research quality auditor. Read the following Phase 1 narrative files, evaluate each persona one by one, and then conduct a cross-persona evaluation.

**Files to Read:**
{List of all phase1-*.md file paths}

**Per-Persona Check (Judge each persona independently):**

1. Word Count: ≥2500 words PASS, <2500 words BLOCK
2. Specificity: Are there specific times ("last Wednesday"), names/roles ("Lao Zhang from our team"), dialogue (direct quotes), numbers ("8 requirements running simultaneously")? At least 2 occurrences of each type PASS, otherwise FLAG
3. Five-section Coverage: Does the warm-up/daily routine/deep dive/long-term observation/wish all have substantial content? FLAG if any section is missing
4. Persona Consistency: Is the personality/work style shown in the narrative consistent with the soul definition? FLAG if there are contradictions
5. Predefined Pollution: Are there any predefined pain points or product attitudes that are not in the soul definition? BLOCK if present

**Cross-Persona Check:**

6. Difference Degree: Are the frustration cases or daily routines of any two personas highly similar (same theme, similar narrative structure)? FLAG if similar pairs exist
7. Perspective Coverage: Does this group of personas cover different seniority levels and work modes? FLAG if all are homogeneous

**Output Format:**
One judgment (PASS/FLAG/BLOCK) + specific problem description for each persona.
One judgment for cross-persona check.
Final Overall Judgment: All PASS → Enter Phase 2; Any BLOCK → List the personas that need to be regenerated and the reasons.

Write the validation report to {Output Directory}/v1-validation.md
Processing Logic:
  • PASS: Enter Phase 2
  • FLAG: Record the problem but proceed (the problem will be mentioned in the limitations section of the comprehensive report)
  • BLOCK: Regenerate Phase 1 for the corresponding persona, attach specific improvement requirements in the prompt (e.g., "Insufficient word count, need to add more details in the deep dive section" "Predefined pollution detected, remove the following content: …"), and re-validate after regeneration

Step 2:Phase 2 — 痛点提取与旅程映射

Step 2: Phase 2 — Pain Point Extraction and Journey Mapping

Phase 2 分两步执行,降低单个 agent 的 context 压力,提高分析质量。
Phase 2 is executed in two steps to reduce the context pressure of a single agent and improve analysis quality.

Phase 2a — 逐角色结构化提取(并行)

Phase 2a — Per-Persona Structured Extraction (Parallel)

为每个角色启动一个 Agent(使用 Agent 工具,
run_in_background: true
),Prompt 结构:
你是一个用研分析员。读取以下 Phase 1 叙事文件,提取结构化信息。

**读取文件:** {phase1-{角色名}.md 路径}

**提取以下内容:**

1. **工作流节点序列**:从「日常流」中提取关键节点,每个节点包含:
   - 做什么(具体动作)
   - 用什么工具/系统
   - 和谁交互
   - 情绪标注(正面/中性/负面)
   - 情绪原话证据(如有)

2. **自发表达的痛点**:只提取有情绪支撑的痛点,每个痛点包含:
   - 观察:角色原话或具体行为描述
   - 解读:这可能意味着什么
   - 情绪强度:高/中/低
   - 出现位置:热身/日常流/深潜/远望/许愿

3. **情绪峰值时刻**:叙事中情绪最强烈的 2-3 个片段,标注正面/负面和原话

4. **许愿核心**:魔法棒问题的答案及其背后的深层需求

5. **得意案例要素**:什么条件下角色感到成就感?指向什么潜在 job?

**输出要求**:结构化格式,500-800 字,保留关键原话。不要做跨角色分析,只提取本角色的信息。
每个 Agent 将结果写入
docs/user-research-{日期}/phase2a-{角色名}.md
Launch an Agent for each persona (using the Agent tool,
run_in_background: true
), with the Prompt structure:
You are a user research analyst. Read the following Phase 1 narrative file and extract structured information.

**File to Read:** {Path to phase1-{persona-name}.md}

**Extract the Following Content:**

1. **Workflow Node Sequence**: Extract key nodes from the "Daily Routine" section, each node includes:
   - What to do (specific action)
   - What tools/systems to use
   - Who to interact with
   - Emotion Tag (Positive/Neutral/Negative)
   - Original Emotion Evidence (if any)

2. **Spontaneously Expressed Pain Points**: Only extract pain points with emotional support, each pain point includes:
   - Observation: Original words or specific behavior descriptions of the persona
   - Interpretation: What this might mean
   - Emotion Intensity: High/Medium/Low
   - Occurrence Position: Warm-up/Daily Routine/Deep Dive/Long-term Observation/Wish

3. **Emotion Peak Moments**: 2-3 segments with the strongest emotions in the narrative, mark positive/negative and original words

4. **Core Wish**: The answer to the magic wand question and its underlying deep needs

5. **Key Elements of Pride Cases**: Under what conditions does the persona feel a sense of accomplishment? What potential job does it point to?

**Output Requirements**: Structured format, 500-800 words, retain key original quotes. Do not conduct cross-persona analysis, only extract information of this persona.
Each Agent writes the result to
docs/user-research-{date}/phase2a-{persona-name}.md
.

Phase 2b — 交叉分析与综合(顺序)

Phase 2b — Cross-Analysis and Synthesis (Sequential)

等待所有 Phase 2a Agent 完成后,读取所有
phase2a-*.md
文件(总量约 4-6k 字),进行综合分析:
你是一个高级用研分析师。读取以下结构化提取文件,进行跨角色综合分析。

**读取文件:**
{所有 phase2a-*.md 文件路径列表}
{外部数据文件路径(如有)}
{用户的痛点假设清单(如有)}

**分析任务:**

**第一层:旅程地图叠加**
叠加所有角色的工作流节点序列,找出:
- 痛点在流程中的聚集位置——哪个环节最多角色感到痛苦
- 情绪热力图——哪些节点是集体低谷,哪些是集体高峰
- 工具切换的摩擦点——角色在哪里被迫在工具间跳转

**第二层:痛点聚类**

1. 跨角色聚类:精确量化——写 "N/M 角色" 格式,每个痛点附出处角色 ID 列表
2. 按强度分类:
   - 共性强信号:N/M 角色自然提到(N > M/2)→ 高优先级产品方向
   - 分众信号:特定 1-2 个角色强烈但不普遍 → 特定用户群的差异化价值
   - 新发现:未预设但自由叙事中自然出现 → 重点关注
3. 与已知假设对比(如有):逐条标注——自然验证 / 未出现(可疑)/ 新发现
4. 与外部数据交叉(如有):标注「模拟+真实双重验证」「仅模拟出现」「仅真实数据出现」
5. 每个痛点区分「观察」(角色说了什么/做了什么)和「解读」(我们认为这意味着什么)

**第三层:JTBD 提炼**

从痛点和得意案例上升一层,提炼 Jobs to be Done:
> 当我处于 {情境} 时,我想要 {做到什么},这样我就能 {得到什么结果}。

每个 JTBD 标注:来源角色、支撑证据(原话)、当前替代方案、替代方案的不足。

**分析纪律:**
- 精确量化:所有统计用 "N/M 角色" 格式,禁止"大多数""部分""一些"
- 观察与解读分离:每个痛点先陈述观察事实,再给出解读,用明确标签区分
- 引用带 ID:所有原话标注角色 ID(P1-Pn)
将分析写入
docs/user-research-{日期}/phase2-analysis.md

Wait for all Phase 2a Agents to complete, then read all
phase2a-*.md
files (total about 4-6k words) for comprehensive analysis:
You are a senior user research analyst. Read the following structured extraction files and conduct cross-persona comprehensive analysis.

**Files to Read:**
{List of all phase2a-*.md file paths}
{External data file paths (if any)}
{User's pain point hypothesis list (if any)}

**Analysis Tasks:**

**Level 1: Journey Map Overlay**
Overlay the workflow node sequences of all personas to find:
- Aggregation positions of pain points in the process — which link has the most personas feeling pain
- Emotion Heatmap — which nodes are collective lows and which are collective highs
- Friction points of tool switching — where personas are forced to jump between tools

**Level 2: Pain Point Clustering**

1. Cross-Persona Clustering: Precise quantification — use the format "N/M personas", attach the list of source persona IDs to each pain point
2. Classification by Intensity:
   - Common Strong Signal: N/M personas mentioned it naturally (N > M/2) → High-priority product direction
   - Niche Signal: Strongly mentioned by 1-2 specific personas but not universal → Differentiated value for specific user groups
   - New Discovery: Naturally emerged in free narrative but not predefined → Focus on it
3. Comparison with Known Hypotheses (if any): Mark each one as — Naturally Validated / Not Appeared (Suspicious) / New Discovery
4. Cross-validation with External Data (if any): Mark as "Dual Validation by Simulation + Reality" "Only Appeared in Simulation" "Only Appeared in Real Data"
5. Distinguish "Observation" (what the persona said/did) and "Interpretation" (what we think this means) for each pain point

**Level 3: JTBD Refinement**

Elevate from pain points and pride cases to refine Jobs to be Done:
> When I am in {Situation}, I want to {Achieve What}, so that I can {Get What Result}.

Mark each JTBD with: Source Persona, Supporting Evidence (original words), Current Alternative Solution, Shortcomings of Alternative Solution.

**Analysis Discipline:**
- Precise Quantification: All statistical expressions must use the "N/M personas" format, prohibit vague words like "most" "some" "part"
- Separation of Observation and Interpretation: For each pain point, first state the observation fact, then give the interpretation, distinguish with clear tags
- Cite with ID: All original quotes must be marked with persona IDs (e.g., P1, P2)
Write the analysis to
docs/user-research-{date}/phase2-analysis.md
.

V2:分析严谨性验证

V2: Analytical Rigor Validation

Phase 2b 完成后,启动一个独立的验证 Agent,Prompt:
你是一个用研分析审计员。读取 Phase 2 分析报告,并抽查原始叙事文件进行交叉验证。

**读取文件:**
- {phase2-analysis.md 路径}
- 随机抽取 2-3 个 {phase1-*.md 路径}(作为原始证据源)

**检查项:**

1. 观察/解读分离:每个痛点是否明确区分了「角色说了什么」和「我们认为这意味着什么」?混为一谈的 FLAG
2. 量化准确:统计表述是否全部用 "N/M" 格式?是否存在 "大多数""一些" 等模糊词?违反则 FLAG
3. 引用可溯:原话摘录是否都标注了角色 ID?抽查 3-5 条引用,对照原始 Phase 1 文件看是否准确?篡改或无中生有则 BLOCK
4. JTBD 接地:每个 JTBD 是否有原话证据支撑?是否有脱离证据的过度抽象?悬空的 JTBD FLAG
5. 旅程地图合理性:节点划分是否反映了真实的工作流断点?还是人为切割?不合理的 FLAG
6. 遗漏检查:抽查的原始叙事中,是否有明显的痛点/情绪峰值被分析遗漏?遗漏重要信号则 FLAG

**输出格式:**
每个检查项一个判定(PASS/FLAG/BLOCK)+ 具体问题描述。
总判定:PASS / FLAG(列出问题,综合报告需注意)/ BLOCK(需要重做分析的部分及原因)。

将验证报告写入 {输出目录}/v2-validation.md
处理逻辑同 V1。BLOCK 时重新执行 Phase 2b,prompt 中附上具体改进要求。

After Phase 2b is completed, launch an independent validation Agent, with the Prompt:
You are a user research analysis auditor. Read the Phase 2 analysis report and spot-check the original narrative files for cross-validation.

**Files to Read:**
- {Path to phase2-analysis.md}
- Randomly select 2-3 {paths to phase1-*.md} (as original evidence sources)

**Check Items:**

1. Separation of Observation/Interpretation: Is each pain point clearly distinguished between "what the persona said" and "what we think this means"? FLAG if mixed
2. Accurate Quantification: Are all statistical expressions in the "N/M" format? Are there vague words like "most" "some"? FLAG if violated
3. Traceable Citations: Are all original quotes marked with persona IDs? Spot-check 3-5 citations and compare with the original Phase 1 files to see if they are accurate? BLOCK if tampered or fabricated
4. Grounded JTBD: Does each JTBD have original evidence support? Is there over-abstraction脱离 evidence? FLAG if JTBD is ungrounded
5. Reasonable Journey Map: Does the node division reflect real workflow breakpoints or is it artificially cut? FLAG if unreasonable
6. Omission Check: Are there obvious pain points/emotion peaks in the spot-checked original narrative that are omitted in the analysis? FLAG if important signals are omitted

**Output Format:**
One judgment (PASS/FLAG/BLOCK) + specific problem description for each check item.
Overall Judgment: PASS / FLAG (list problems, note in comprehensive report) / BLOCK (specify parts that need re-analysis and reasons).

Write the validation report to {Output Directory}/v2-validation.md
Processing Logic is the same as V1. If BLOCK, re-execute Phase 2b with specific improvement requirements in the prompt.

Step 3:Phase 3 — 产品碰撞

Step 3: Phase 3 — Product Collision

读取产品概念文档,提炼出中性的产品描述——只陈述功能事实(输入什么、系统做什么、输出什么),不美化、不推销、不使用情感词汇。中性描述模板:
{产品名} 是一个 {一句话品类定义}。它的工作方式是:
1. {输入}——你做什么操作
2. {处理}——系统做什么
3. {输出}——你看到什么
4. {反馈循环}——使用一段时间后怎么迭代
5. {界面形态}——它长什么样
就这些。
单概念模式:为每个角色并行启动一个 Agent。 多概念模式:为每个角色 × 每个概念的组合并行启动 Agent(如 8 角色 × 2 概念 = 16 个 Agent)。每个碰撞在独立 agent 中进行,避免前一个概念影响后一个的判断。
Agent Prompt 结构(
run_in_background: true
):
你是一个用户研究员,正在做产品概念测试。

**第一步**:读取 {Phase 1 文件路径},完全内化角色——他的经历、性格、工作方式、自然流露的困扰。

**第二步**:以角色视角,对以下产品概念做出真实反应:
{中性产品描述}

**反应维度**:
- 完全基于 Phase 1 中展现的性格、工作方式和痛点来反应
- 会在哪里皱眉?在哪里眼前一亮?
- 会把这个工具放在自己已有工作流的哪个位置?替代什么还是补充什么?
- 最大的顾虑是什么?(迁移成本、学习曲线、可靠性、隐私……)
- 会不会试用?在什么条件下?什么会让他放弃?

**价值感知与付费意愿**:
- 觉得这个东西值多少钱?会从什么预算里出?(个人学习预算、团队工具预算、公司采购预算……)
- 和现有替代方案比,觉得值不值得额外花钱/花时间切换?
- 什么条件下会从免费试用升级到付费?什么价格区间可以接受?

**关键约束**:
- 保持角色的说话风格和决策逻辑
- 不要过度热情——真实用户对新产品通常带有怀疑,要有顾虑和犹豫
- 1500-2500 字
单概念模式:每个 Agent 将结果写入
docs/user-research-{日期}/phase3-{角色名}.md
多概念模式:每个 Agent 将结果写入
docs/user-research-{日期}/phase3-{角色名}-{概念名}.md

Read the product concept document and refine a neutral product description — only state functional facts (what input, what the system does, what output, etc.), no beautification, no promotion, no emotional words. Neutral description template:
{Product Name} is a {one-sentence category definition}. It works as follows:
1. {Input} — What operation you do
2. {Processing} — What the system does
3. {Output} — What you see
4. {Feedback Loop} — How to iterate after using it for a period of time
5. {Interface Form} — What it looks like
That's all.
Single-concept Mode: Launch an Agent in parallel for each persona. Multi-concept Mode: Launch an Agent in parallel for each combination of persona × concept (e.g., 8 personas × 2 concepts = 16 Agents). Each collision is conducted in an independent agent to avoid the influence of the previous concept on the next judgment.
Agent Prompt structure (
run_in_background: true
):
You are a user researcher conducting product concept testing.

**Step 1**: Read the {Phase 1 file path} and fully internalize the persona — his experiences, personality, work style, and naturally expressed troubles.

**Step 2**: From the persona's perspective, give real responses to the following product concept:
{Neutral product description}

**Response Dimensions**:
- Fully based on the personality, work style, and pain points shown in Phase 1
- Where would he frown? Where would his eyes light up?
- Where would he place this tool in his existing workflow? Replace something or complement something?
- What are the biggest concerns? (Migration cost, learning curve, reliability, privacy...)
- Would he try it? Under what conditions? What would make him give up?

**Value Perception and Willingness to Pay**:
- How much does he think this is worth? Which budget would it come from? (Personal learning budget, team tool budget, company procurement budget...)
- Compared with existing alternative solutions, does he think it's worth extra money/time to switch?
- Under what conditions would he upgrade from free trial to paid? What price range is acceptable?

**Key Constraints**:
- Maintain the persona's speaking style and decision logic
- Do not be overly enthusiastic — real users usually have doubts about new products, so there must be concerns and hesitations
- 1500-2500 words
Single-concept Mode: Each Agent writes the result to
docs/user-research-{date}/phase3-{persona-name}.md
. Multi-concept Mode: Each Agent writes the result to
docs/user-research-{date}/phase3-{persona-name}-{concept-name}.md
.

V3:人设一致性验证

V3: Persona Consistency Validation

所有 Phase 3 完成后,启动一个独立的验证 Agent,Prompt:
你是一个角色一致性审计员。对每个角色,比较 Phase 1(自由叙事)和 Phase 3(产品碰撞)的输出。

**读取文件:**
{每个角色的 phase1-*.md 和 phase3-*.md 文件路径列表}

**检查项:**

1. 性格一致:Phase 3 的说话方式、决策风格是否与 Phase 1 一致?如果 Phase 1 是犀利直接的人,Phase 3 却变得圆滑客气,则 FLAG
2. 痛点映射:Phase 3 中的反应是否基于 Phase 1 中自然流露的困扰?如果角色对产品某功能眼前一亮,但 Phase 1 中从未表达过相关痛点,则 FLAG
3. 非泛化:Phase 3 的反应是否具有角色特异性?如果多个角色的碰撞反应高度相似(用了类似的措辞和关注点),则 BLOCK
4. 过度热情检测:角色是否对产品表现得不合理地热情?真实用户对新产品通常带有怀疑,如果角色几乎没有顾虑则 FLAG
5. 定价合理性:角色给出的价值感知/付费意愿是否与其职业层次和组织规模匹配?不匹配则 FLAG

**输出格式:**
每个角色一个判定(PASS/FLAG/BLOCK)+ 具体问题描述。
总判定。如果 BLOCK,指出需要重新碰撞的角色及原因。

将验证报告写入 {输出目录}/v3-validation.md
处理逻辑同 V1。BLOCK 时重新生成对应角色的 Phase 3,prompt 中强调差异化和保持怀疑。

After all Phase 3 is completed, launch an independent validation Agent, with the Prompt:
You are a persona consistency auditor. For each persona, compare the outputs of Phase 1 (free narrative) and Phase 3 (product collision).

**Files to Read:**
{List of phase1-*.md and phase3-*.md file paths for each persona}

**Check Items:**

1. Personality Consistency: Is the speaking style and decision-making style in Phase 3 consistent with Phase 1? If Phase 1 shows a sharp and direct person, but Phase 3 becomes smooth and polite, FLAG
2. Pain Point Mapping: Is the response in Phase 3 based on the naturally expressed troubles in Phase 1? If the persona's eyes light up at a certain product feature, but no related pain points were expressed in Phase 1, FLAG
3. Non-generalization: Does the response in Phase 3 have persona specificity? If the collision responses of multiple personas are highly similar (using similar wording and focus), BLOCK
4. Over-enthusiasm Detection: Does the persona show unreasonably high enthusiasm for the product? Real users usually have doubts about new products, so FLAG if the persona has almost no concerns
5. Pricing Reasonableness: Is the value perception/willingness to pay given by the persona matching his professional level and organization scale? FLAG if not matching

**Output Format:**
One judgment (PASS/FLAG/BLOCK) + specific problem description for each persona.
Overall Judgment. If BLOCK, point out the personas that need re-collision and reasons.

Write the validation report to {Output Directory}/v3-validation.md
Processing Logic is the same as V1. If BLOCK, regenerate Phase 3 for the corresponding persona, emphasizing differentiation and maintaining doubt in the prompt.

Step 4:综合报告

Step 4: Comprehensive Report

读取所有 Phase 1-3 文件及验证报告(v1-v3-validation.md),写最终综合报告
docs/user-research-{日期}/SYNTHESIS.md
,包含:
  1. Executive Summary(3-5 句话概括最重要的发现,回答:最重要的发现是什么?对产品意味着什么?最大的不确定性在哪?——放在最前面)
  2. 方法论说明(三阶段法的逻辑、参与角色数量、是否有外部数据交叉验证、验证关卡结果摘要)
  3. 旅程痛点叠加图(所有角色的工作流节点汇总,标注每个节点的痛点密度和情绪强度)
  4. 痛点对照表(预设假设 vs 自然浮现 vs 新发现,每条附带角色 ID 的原话证据,每条痛点明确区分「观察」和「解读」)
  5. JTBD 清单(从痛点抽象出的用户任务,标注当前替代方案和未满足程度)
  6. 产品碰撞反应汇总
    • 谁最想用、跨角色一致信号、分众信号、试用/放弃条件
    • 价值感知与付费意愿分布:按角色层次和组织规模分析定价接受区间、预算来源、升级条件
  7. 概念对比(仅多概念模式):
    • 每个概念在每个分群中的接受度对比
    • 角色在概念间的取舍逻辑(首要考虑因素是什么)
    • 概念间是否互补而非互斥
    • 方向建议
  8. 用户分群表(Segment | 特征 | 核心需求 | 覆盖角色 | 采用信号强度 — 结构化呈现)
  9. Impact/Effort 矩阵(功能建议按「痛点强度 × 预估实施复杂度」二维排列:Quick Win / Big Bet / Fill / Money Pit)
  10. Highlight Reel(关键行为观察、决策转折点、情绪峰值时刻、可用于品牌素材的原话——每条标注角色 ID 和出现阶段)
  11. 知识缺口与后续研究问题(本次研究未能回答的具体问题清单,包含验证关卡中 FLAG 的问题。每条标注:具体问题 / 建议方法 / 建议对象 / 为什么本次未回答)
  12. 方法论局限(AI 模拟的固有局限性声明)

Read all Phase 1-3 files and validation reports (v1-v3-validation.md), write the final comprehensive report
docs/user-research-{date}/SYNTHESIS.md
, including:
  1. Executive Summary (3-5 sentences summarizing the most important findings, answering: What are the most important findings? What does it mean for the product? What are the biggest uncertainties? — Place it at the top)
  2. Methodology Description (Logic of the three-phase method, number of participating personas, whether there is cross-validation with external data, summary of validation checkpoint results)
  3. Journey Pain Point Overlay Map (Summary of workflow nodes of all personas, marking pain point density and emotion intensity of each node)
  4. Pain Point Comparison Table (Predefined Hypotheses vs Naturally Emerged vs New Discoveries, each with original quote evidence marked with persona ID, each pain point clearly distinguishes "Observation" and "Interpretation")
  5. JTBD List (User tasks abstracted from pain points, marking current alternative solutions and unmet needs)
  6. Product Collision Response Summary:
    • Who is most willing to use it, cross-persona consistent signals, niche signals, trial/abandonment conditions
    • Value Perception and Willingness to Pay Distribution: Analyze pricing acceptance range, budget source, upgrade conditions by persona level and organization scale
  7. Concept Comparison (Only for Multi-concept Mode):
    • Comparison of acceptance of each concept in each segment
    • Persona's trade-off logic between concepts (what is the primary consideration factor)
    • Whether concepts are complementary rather than mutually exclusive
    • Direction Suggestions
  8. User Segmentation Table (Segment | Characteristics | Core Needs | Covered Personas | Adoption Signal Strength — Presented Structurally)
  9. Impact/Effort Matrix (Functional suggestions arranged in two dimensions: "Pain Point Intensity × Estimated Implementation Complexity": Quick Win / Big Bet / Fill / Money Pit)
  10. Highlight Reel (Key behavior observations, decision turning points, emotion peak moments, original quotes usable for brand materials — each marked with persona ID and occurrence phase)
  11. Knowledge Gaps and Follow-up Research Questions (List of specific questions not answered in this study, including problems flagged in validation checkpoints. Mark each with: Specific Question / Recommended Method / Recommended Object / Why Not Answered This Time)
  12. Methodology Limitations (Statement of inherent limitations of AI simulation)

V4:综合报告完整性验证

V4: Comprehensive Report Completeness Validation

SYNTHESIS.md 写完后,启动一个独立的验证 Agent,Prompt:
你是一个研究报告审计员。检查综合报告的质量和完整性。

**读取文件:**
- {SYNTHESIS.md 路径}
- {phase2-analysis.md 路径}(作为证据源)

**检查项:**

1. Executive Summary 准确性:3-5 句话是否准确概括了正文的核心发现?是否有正文不支持的结论?不准确则 BLOCK
2. 章节完整:报告是否包含所有要求的章节(单概念 11 章 / 多概念 12 章)?缺失任何章节 BLOCK
3. 证据链完整:每个结论/建议是否能追溯到具体的痛点和原话?悬空的结论 FLAG
4. 内部一致性:报告各部分之间是否有矛盾?(如痛点对照表说某痛点是「可疑信号」,但 Impact/Effort 矩阵中又基于它给出了高优先级建议)矛盾则 BLOCK
5. 量化一致:Phase 2 分析中的数字(N/M 角色)是否在综合报告中被准确引用?数字不一致则 FLAG
6. 知识缺口诚实度:是否有明显的分析盲区没有被列入知识缺口清单?验证关卡 FLAG 的问题是否都被纳入?遗漏则 FLAG

**输出格式:**
每个检查项一个判定(PASS/FLAG/BLOCK)+ 具体问题描述。
总判定。如果 BLOCK,指出需要修正的具体段落和原因。

将验证报告写入 {输出目录}/v4-validation.md
处理逻辑同 V1。BLOCK 时修正 SYNTHESIS.md 中的具体问题并重新验证。

After SYNTHESIS.md is written, launch an independent validation Agent, with the Prompt:
You are a research report auditor. Check the quality and completeness of the comprehensive report.

**Files to Read:**
- {Path to SYNTHESIS.md}
- {Path to phase2-analysis.md} (as evidence source)

**Check Items:**

1. Executive Summary Accuracy: Do the 3-5 sentences accurately summarize the core findings of the main text? Are there conclusions not supported by the main text? BLOCK if inaccurate
2. Chapter Completeness: Does the report include all required chapters (11 chapters for single-concept / 12 chapters for multi-concept)? BLOCK if any chapter is missing
3. Complete Evidence Chain: Can each conclusion/suggestion be traced back to specific pain points and original quotes? FLAG if conclusions are ungrounded
4. Internal Consistency: Are there contradictions between different parts of the report? (e.g., the pain point comparison table says a certain pain point is a "suspicious signal", but the Impact/Effort matrix gives a high-priority suggestion based on it) BLOCK if contradictory
5. Consistent Quantification: Are the numbers (N/M personas) in Phase 2 analysis accurately cited in the comprehensive report? FLAG if numbers are inconsistent
6. Honesty of Knowledge Gaps: Are obvious analysis blind spots not included in the knowledge gap list? Are problems flagged in validation checkpoints all included? FLAG if omitted

**Output Format:**
One judgment (PASS/FLAG/BLOCK) + specific problem description for each check item.
Overall Judgment. If BLOCK, point out the specific paragraphs to be revised and reasons.

Write the validation report to {Output Directory}/v4-validation.md
Processing Logic is the same as V1. If BLOCK, revise the specific parts in SYNTHESIS.md and re-validate.

关键约束

Key Constraints

  • Phase 1 的角色 Prompt 中绝不能出现任何产品概念、预设痛点、或暗示角色应该感受到什么
  • Phase 3 的产品描述必须中性——陈述功能事实,不使用营销语言
  • 所有 Phase 1 Agent 必须并行启动以节省时间
  • 所有 Phase 2a Agent 必须并行启动
  • 所有 Phase 3 Agent 必须并行启动
  • 综合报告必须明确区分「假设验证」「假设可疑」「新发现」三类信号
  • 精确量化:所有统计表述必须用 "N/M 角色" 格式,禁止使用 "大多数""部分""一些" 等模糊词
  • 观察与解读分离:每个痛点/发现必须先陈述观察事实(角色说了什么、做了什么),再给出解读(我们认为这意味着什么),二者用明确标签区分
  • 引用带 ID:所有原话摘录必须标注角色 ID(如 P1、P2),确保可溯源
  • 验证关卡不可跳过:每个 V1-V4 验证步骤必须执行,BLOCK 判定必须处理后才能进入下一阶段
  • Absolutely No product concepts, predefined pain points, or hints of what the persona should feel in the Phase 1 persona Prompt
  • Product description in Phase 3 must be neutral — state functional facts, no marketing language
  • All Phase 1 Agents must be launched in parallel to save time
  • All Phase 2a Agents must be launched in parallel
  • All Phase 3 Agents must be launched in parallel
  • The comprehensive report must clearly distinguish three types of signals: "Hypothesis Validated" "Hypothesis Suspicious" "New Discovery"
  • Precise Quantification: All statistical expressions must use the "N/M personas" format, prohibit vague words like "most" "some" "part"
  • Separation of Observation and Interpretation: Each pain point/discovery must first state the observation fact (what the persona said/did), then give the interpretation (what we think this means), distinguish with clear tags
  • Cite with ID: All original quotes must be marked with persona IDs (e.g., P1, P2) to ensure traceability
  • Validation Checkpoints Cannot Be Skipped: Each V1-V4 validation step must be executed, and BLOCK judgments must be processed before entering the next phase

迭代模式

Iteration Mode

整个 pipeline 支持局部重跑,避免重复已有的有效工作。新产出放在
docs/user-research-{日期}/iteration-{n}/
子目录下(追加角色场景除外)。
The entire pipeline supports partial re-running to avoid repeating effective existing work. New outputs are placed in the
docs/user-research-{date}/iteration-{n}/
subdirectory (except for adding persona scenarios).

场景一:换概念重跑 Phase 3

Scenario 1: Re-run Phase 3 with New Concepts

适用于:产品概念有更新,但目标用户群不变。
  • 复用:Phase 1 全部文件、Phase 2a 全部文件、Phase 2b 分析
  • 重新生成:Phase 3 全部文件 → V3 验证 → SYNTHESIS.md → V4 验证
  • 文件位置:iteration 目录下,phase1/phase2 通过路径引用原始目录
Applicable to: Product concept updated, but target user group remains unchanged.
  • Reuse: All Phase 1 files, all Phase 2a files, Phase 2b analysis
  • Regenerate: All Phase 3 files → V3 Validation → SYNTHESIS.md → V4 Validation
  • File Location: In the iteration directory, Phase 1/Phase 2 reference the original directory via path

场景二:追加角色

Scenario 2: Add Personas

适用于:发现角色覆盖有盲区,需要补充新角色。
  • 复用:已有角色的全部 Phase 1-3 产出
  • 新角色流程:Phase 1 → V1 验证(仅验证新角色 + 与已有角色的跨角色差异度检查)→ Phase 2a → 合并新旧 Phase 2a 重跑 Phase 2b → V2 验证 → Phase 3 → V3 验证
  • 重新生成:phase2-analysis.md、SYNTHESIS.md(因为有新数据)
  • 文件位置:新角色的文件直接放在原始目录下,更新的 phase2-analysis.md 和 SYNTHESIS.md 覆盖原文件(旧版本通过 git 保留)
Applicable to: Found blind spots in persona coverage, need to add new personas.
  • Reuse: All Phase 1-3 outputs of existing personas
  • New Persona Process: Phase 1 → V1 Validation (only validate new personas + cross-persona difference check with existing personas) → Phase 2a → Merge old and new Phase 2a to re-run Phase 2b → V2 Validation → Phase 3 → V3 Validation
  • Regenerate: phase2-analysis.md, SYNTHESIS.md (due to new data)
  • File Location: Files of new personas are directly placed in the original directory, updated phase2-analysis.md and SYNTHESIS.md overwrite the original files (old versions are retained via git)

场景三:换假设清单重跑 Phase 2b

Scenario 3: Re-run Phase 2b with New Hypothesis List

适用于:产品方向有调整,想用新假设清单重新分析已有数据。
  • 复用:Phase 1 全部文件、Phase 2a 全部文件
  • 重新生成:Phase 2b(用新假设清单对比)→ V2 验证 → Phase 3(如需)→ SYNTHESIS.md → V4 验证
  • 文件位置:iteration 目录下
Applicable to: Product direction adjusted, need to re-analyze existing data with new hypothesis list.
  • Reuse: All Phase 1 files, all Phase 2a files
  • Regenerate: Phase 2b (compare with new hypothesis list) → V2 Validation → Phase 3 (if needed) → SYNTHESIS.md → V4 Validation
  • File Location: In the iteration directory

参考文件

Reference Files

  • 方法论原理与示例:@references/methodology.md
  • Methodology Principles and Examples: @references/methodology.md