title: "Data Analysis Requirement Clarification — Best Practice" date: 2026-09-02 purpose: "ChatGPT-assisted requirement clarification + human mental model"

Data Analysis Requirement Clarification — Best Practice

目标不是让 ChatGPT 多问几个问题，而是让它在分析开始前，先把模糊的 Data Request 还原成一个 可回答、可验证、可决策的 Analysis Question。

最快的使用方式：把整个这个文档直接丢给 GPT，让它自己搭。

提示词：

请基于当前文档，为我搭建可用于正式工作的 Project 环境。

使用顺序：

先直接用起来 → 再理解它为什么这样工作 → 最后把这套机制内化成人自己的能力。

Part I — 先在 ChatGPT 里直接用起来

1. 推荐使用方式：建一个长期 Data Analysis Project

对于反复出现的数据分析需求，最适合的形态不是每次重新写一大段 Prompt，而是建立一个长期的 ChatGPT Project。

建议结构：

ChatGPT Project: Data Analysis

├── Project Instructions
│   └── Requirement Clarifier 的行为规则
│
├── Project Sources / Knowledge
│   ├── requirement-clarification.md
│   ├── metric-contract.md
│   ├── 公司 Metric Dictionary
│   ├── Event / Data Schema
│   ├── 产品与业务定义
│   └── 常见数据口径 / Analyst Gotchas
│
└── Chats
    ├── Retention 分析
    ├── 渠道质量分析
    ├── PQL 分析
    ├── Pricing / Paywall 分析
    └── 临时业务需求

这里最重要的区分：

Instructions
= GPT 应该“怎么工作”

Knowledge / Sources
= GPT 工作时“应该知道什么”

不要把所有数据分析知识都硬塞进 Instructions。

核心行为规则保持短、明确、稳定；详细的业务定义、Metric、Schema、PLG 分析方法放进参考材料，需要时再使用。

2. Project Instructions：可直接复制（闭眼贴）

下面这一段可以直接作为 Requirement Clarifier 的核心 Instructions。

You are my Data Analysis Requirement Clarifier.

Your first job is not to analyze the data.
Your first job is to determine whether the request is sufficiently defined for analysis.

When I give you a data-analysis request:

STEP 1 — Reconstruct the decision
Identify:
- Business Decision: what decision will this analysis support?
- Analysis Question: what exactly must be answered?
- Trigger: why is this question being asked now?

STEP 2 — Define the analytical object
Determine, when relevant:
- Population
- Analysis Grain
- Primary Outcome
- Metric Definition
- Comparison / Baseline
- Time Window / Cohort
- Core Hypotheses
- Key Segments
- Data Constraints
- Decision Boundary
- Deliverable

STEP 3 — Decide whether to ask
Ask a clarification question ONLY when the missing information would materially change:
- the population,
- the analysis grain,
- the metric definition,
- the comparison,
- the analytical method,
- the interpretation,
- or the resulting business decision.

Do NOT ask:
- for information already present in the conversation or project context;
- for details that would not materially change the analysis;
- for information that can be safely handled through an explicit assumption.

When a reasonable assumption is safe:
- state the assumption clearly;
- continue instead of blocking the analysis.

Ask no more than 2–3 high-value clarification questions at a time.

STEP 4 — Know when to stop
Stop clarifying once the remaining uncertainty is unlikely to materially change:
- the analysis method,
- the interpretation,
- or the business decision.

Do not try to complete a checklist for its own sake.

STEP 5 — Run a short Red Team / Developer Challenge
Before declaring the request ready, temporarily act as a skeptical developer / data engineer.

Challenge the proposed analysis on:
- whether the requested metric can actually be computed from available data;
- whether entity / event / metric definitions are ambiguous;
- whether joins, IDs, filters, eligibility, attribution, or cohort maturity could break the result;
- whether the requested analysis quietly assumes unavailable tracking or impossible implementation;
- whether an edge case could materially change the interpretation;
- whether a developer reviewing this requirement would reasonably ask for a missing definition.

Return only the 1–3 most material challenges.

If a challenge exposes a material ambiguity:
- resolve it through clarification or an explicit assumption.

If no material blocker remains:
- proceed.

Do not invent blockers merely to perform the challenge.

STEP 6 — Produce a Requirement Contract
Before analysis begins, summarize:

Business Decision:
Analysis Question:
Trigger:
Population:
Grain:
Primary Outcome:
Metric Contract:
Comparison:
Core Hypotheses:
Key Segments:
Data Constraints:
Decision Boundary:
Deliverable:
Deadline / Decision Owner: if relevant

Then conclude with one of:
- READY TO ANALYZE
- CRITICAL INFORMATION STILL MISSING

If READY TO ANALYZE, proceed with the analysis when the required data or sources are available.

3. 整体架构：三道 Gate + 三层脑子

如果真的让 GPT 长期参与数据分析，最好不要只给它一份“数据分析方法论大全”。

更稳的结构，是让整个 workflow 有三道 Gate。

Gate 1 — Before Analysis

Am I answering the right question?

核心检查：

Decision
Grain
Population
Metric
Comparison
Material Unknowns

这一关主要由 Requirement Clarifier 负责。

它不是为了把信息问全，而是为了确认：

当前的问题定义，是否已经足够支持一次正确的分析？

Gate 2 — During Analysis

Am I measuring reality correctly?

核心检查：

Data Quality
Segment
Bias
Cohort
Maturity
Attribution
Downstream Validation

这一关主要由 PLG Analyst 负责。

它要避免：

• Aggregate 被当成 mechanism；
• Mix Shift 被当成产品变差；
• Predictor 被当成 causal driver；
• 不成熟 Cohort 被当成 churn；
• Sales / Channel / Attribution 污染被忽略。

Gate 3 — Before Delivery

Does the evidence justify the conclusion and action?

核心检查：

Correlation vs Cause
Confidence
Sample / Uncertainty
Business Impact
Decision Readiness

这一关主要由 Analysis Reviewer 负责。

分析结果不能因为“SQL 跑出来了”就直接交付。

在真正发给 Stakeholder 前，要再问一次：

这些证据，真的足够支持我现在写下的结论和建议吗？

三层脑子

可以把 GPT 理解成三层相互独立的脑子：

① Requirement Clarifier
先确保问题问对
        ↓
② PLG Analyst
按 Funnel / Cohort / PQL /
Monetization / Expansion / Experiment 分析
        ↓
③ Analysis Reviewer
在交付前专门找自己的错

三个角色关注的问题不同：

这比让一个 Prompt 同时“澄清、分析、验证、推荐”更稳。

4. Red Team Challenge：先假装被开发 Challenge 一遍

三层脑子之外，再加一层 Challenge Layer。

它不是第四个长期角色，而是一段刻意加入 workflow 的 adversarial pass。

推荐位置：

Requirement Clarifier
↓
Requirement Contract
↓
🔴 Red Team / Developer Challenge
↓
READY TO ANALYZE
↓
PLG Analyst
↓
Analysis Reviewer

它解决的是一个很现实的问题：

Requirement 在业务上听起来合理，不代表到了开发 / 数据工程那里仍然没有漏洞。

所以在正式开工之前，让 GPT 临时站到一个比较挑剔的 Developer / Data Engineer 视角，主动 challenge 一遍。

Developer Challenge 重点看什么

① 这个指标真的算得出来吗？

例如：

“统计真正看懂报告的用户。”

开发很可能会问：

“看懂”对应哪个 Event？我们埋了吗？

如果没有直接 Event：

• 是不是要使用 Proxy？
• Proxy 的边界是什么？
• 结论的 Confidence 是否应该降低？

② Grain / Entity 有没有歧义？

例如：

“看客户的留存。”

开发可能直接 challenge：

这里的 Customer 是 User、Workspace 还是 Account？

如果这个问题没锁，后面数据 Join 和 denominator 都可能错。

③ Join / ID / Eligibility 能不能成立？

例如：

把 Marketing Channel 和 Paid Account 直接连起来。

应该先 challenge：

• User ID 和 Account ID 怎么映射？
• 多 User Account 怎么归因？
• Anonymous → Signup 身份是否能串起来？
• Sales-created Account 是否属于这条 self-serve 路径？

④ 时间逻辑有没有问题？

例如：

看本月用户的 D30 Retention。

Developer / Analyst 应该马上 challenge：

本月 Cohort 已经成熟到 D30 了吗？

⑤ Requirement 有没有偷偷依赖不存在的数据？

例如：

分析用户为什么不满意结果。

但目前只有：

generate_success
download
copy

没有：

satisfaction
quality_rating
reason_not_used

这时必须把：

“为什么不满意”

降级成：

“哪些行为信号与不继续使用相关”

或者明确需要新增 tracking / research。

⑥ 有没有容易翻车的 Edge Case？

例如：

Paywall Hit 用户付费率更高，所以 Paywall Hit 是 PQL。

Challenge：

• Paywall 是否只会对高 usage 用户出现？
• Paid 后继续 hit Paywall 的行为有没有被算进去？
• Paywall Hit 是否发生在 Activation 前？
• 是否存在 Pricing page 被主动浏览但没有 Value Realized 的用户？

Challenge 的输出不要很长

建议固定输出：

Developer Challenge

1. [Blocking / Non-blocking]
   Challenge:
   Why it matters:
   Resolution:

2. ...

Verdict:
READY
or
REVISE REQUIREMENT CONTRACT

最多保留 1–3 个最 material 的问题。

目的不是挑刺。

而是：

提前模拟真实协作方会提出的 challenge，把容易返工的漏洞在开工前暴露出来。

可直接复制（闭眼贴）：Developer Challenge Prompt

Before we begin the analysis, red-team the Requirement Contract.

Act as a skeptical but practical developer / data engineer who will need to implement or support this analysis.

Challenge only issues that could materially affect feasibility, correctness, or interpretation.

Check:
- entity / grain ambiguity;
- metric computability;
- event availability;
- IDs / joins;
- eligibility and exclusions;
- attribution;
- cohort maturity and time windows;
- missing tracking;
- hidden implementation assumptions;
- edge cases likely to change the conclusion.

Return at most 3 material challenges.

For each:
- Challenge
- Why it matters
- Proposed resolution

Do not invent blockers just to be adversarial.

End with:
READY
or
REVISE REQUIREMENT CONTRACT

这个 Challenge Layer 也可以在复杂分析交付前再跑一次，只是问题换成：

“如果我是负责实现下一步动作的开发，我会从这份结论里 challenge 什么？”

这样可以提前暴露：

• Recommendation 不可实现；
• Metric 和产品逻辑没有对应；
• 分析结论依赖未验证假设；
• 建议缺少可执行边界。

5. 平时怎么用：直接把业务方原话丢进去

不需要把业务需求重新包装成“专业 Prompt”。

业务方原话：

最近注册转化掉得挺厉害，帮忙看看什么原因。

直接交给 ChatGPT。

一个合理的 Requirement Clarifier 不应该马上开始切 Channel、Device、Country。

它应该先把需求重建成类似：

当前理解

Business Decision
判断注册转化下降后，下一步应该优先修流量质量还是注册路径。

Analysis Question
最近 Signup Conversion 下滑，主要来自流量结构变化，
还是相同类型流量下注册路径效率下降？

当前有两个信息会明显改变分析：
1. “注册转化”的分母是 Landing Page Visitors，还是进入注册流程的 Users？
2. 最近是否有明显的渠道投放、注册流程或流量结构变化？

若暂无更多信息：
先假设比较周期为最近 4 周 vs 前 4 周，
第一轮按 Channel × ICP 做 decomposition。

重点不是它问得“全面”。

重点是：

它只问了会改变分析的东西。

6. 一个需求已经足够清楚时，GPT 应该直接开工

例如：

帮我比较 7 月和 8 月 self-serve ICP 用户的 D30 retention。
我主要想确认是不是 8 月 Paid Search 放量以后把用户质量拉低了。

这时其实已经知道：

Decision
→ 判断优先修 acquisition 还是 product retention

Question
→ Retention decline 是 mix shift 还是 within-segment decline？

Population
→ self-serve ICP users

Outcome
→ D30 retention

Comparison
→ July vs August

Hypothesis
→ Paid Search mix shift

如果公司已有统一 D30 Retention Metric Contract，

GPT 不应该继续机械追问：

• 你的目标用户是谁？
• 你想看哪个渠道？
• 你想分析哪个时间段？
• 你希望得到什么结论？

这些信息已经存在。

正确动作：

复述 Requirement Contract → 声明少量必要假设 → 开始分析。

7. Ask / Assume / Ignore：需求澄清的核心决策器

所有缺失信息都先过一个判断。

Missing Information
        │
        ▼
Would this materially change...
        │
        ├─ Population?
        ├─ Grain?
        ├─ Metric?
        ├─ Comparison?
        ├─ Method?
        ├─ Interpretation?
        └─ Decision?
        │
     ┌──┴──┐
    YES    NO
     │      │
     ▼      ▼
    ASK   Can a safe assumption be made?
             │
          ┌──┴──┐
         YES    NO
          │      │
          ▼      ▼
       ASSUME   IGNORE
       + STATE

可以把行为压成三个词：

ASK
ASSUME
IGNORE

ASK

缺失信息会实质改变分析。

例如：

“客户留存”里的客户指 User 还是 Account？

这会改变：

• Grain
• denominator
• SQL
• retention definition
• interpretation

必须确认。

ASSUME

信息缺失，但有安全、透明、容易被纠正的默认值。

例如：

“最近”没有明确时间范围。

如果只是 exploratory diagnosis，可以写：

先按最近 4 周 vs 前 4 周比较；如果业务周期需要别的窗口再调整。

然后继续。

IGNORE

这个信息不会改变分析。

例如：

最终 Dashboard 用什么颜色？

与当前 root-cause analysis 无关。

不问。

8. 只问 2–3 个 High-value Questions

需求澄清很容易犯另一个错误：

为了显得专业，一次问 12 个问题。

结果业务方还没回答，沟通成本已经爆炸。

更好的原则：

每一轮只问最可能改变分析的 2–3 个问题。

优先级通常是：

Decision
↓
Metric / Grain / Population
↓
Comparison
↓
Major Context / Trigger
↓
Everything Else

不是每次都严格照这个顺序，而是优先寻找当前最大的 uncertainty。

9. Quick Mode：一句话就能用

不想建 Project 时，可以直接发：

先别分析，先帮我做需求澄清。

只问那些缺失后会实质改变：
分析对象、指标口径、比较方式、分析方法或业务结论的问题。

已经从上下文知道的不要再问；
能合理假设的请明确声明假设后继续；
每轮最多问 2–3 个最重要的问题。

当剩余不确定性已经不足以改变分析方法或决策时，停止追问。

最后给我一份 Requirement Contract，再判断是否可以开始分析。

10. Requirement Contract：开工前的最小共识

需求澄清的最终产物不是“聊清楚了”。

应该形成一份 compact contract。

Business Decision:
最终要支持什么决策？

Analysis Question:
这次具体要回答什么？

Trigger:
为什么现在问？

Population:
分析哪些人 / Account / Workspace？

Grain:
User / Workspace / Account / Logo / Revenue？

Primary Outcome:
主要结果指标是什么？

Metric Contract:
Numerator:
Denominator:
Window:
Anchor:
Eligibility:
Exclusions:
Attribution:

Comparison:
和谁比？
Baseline / Control / Cohort / Segment？

Core Hypotheses:
目前最值得验证的解释有哪些？

Key Segments:
哪些人群可能遵循不同业务机制？

Data Constraints:
缺什么？
哪些只能用 proxy？

Decision Boundary:
结果为 X 时做什么？
结果为 Y 时做什么？

Deliverable:
一次性分析 / Dashboard / Dataset / Experiment Readout？

Deadline / Decision Owner:
如果对执行有实质影响，再记录。

这个 Contract 不一定全部显示给业务方。

它首先是分析师和 GPT 自己的 analysis specification。

11. Metric Contract：把自然语言变成可计算对象

业务讨论里，同一个词经常代表不同东西。

例如：

Activation

可能分别意味着：

• 创建第一个 Workspace
• 完成 onboarding
• 成功生成第一次结果
• 导出第一次结果
• 完成一次完整核心 workflow
• 用户真正获得了第一次可感知价值

所以关键 Metric 最好显式写：

Metric:
Numerator:
Denominator:
Window:
Anchor:
Eligibility:
Exclusions:
Grain:
Attribution:

例如：

Metric:
True Activation Rate

Numerator:
注册后 7 天内完成核心任务，
并且对结果发生 Export / Copy / Reuse 的 Eligible User

Denominator:
Eligible ICP Signups

Window:
Signup 后 7 天

Anchor:
Signup

Eligibility:
有机会完成核心任务的用户

Exclusions:
员工、测试账号、明确 Sales-sourced Account

Grain:
User

Metric Contract 的作用不是增加流程。

它是在消除：

Semantic Ambiguity。

12. Decision Boundary：什么结果真的会改变动作？

这是最容易被省略、但非常重要的一步。

需求澄清时可以问：

如果分析结果是 X，我们会做什么？
如果是 Y，我们会做什么？

例如：

If:
各主要 Channel 内 D30 retention 都稳定，
只是 Paid Search 占比大幅提高

Then:
优先处理 Acquisition Mix / Targeting

If:
各主要 Channel 内 D30 retention 同时下降

Then:
优先进入 Product Retention / Activation diagnosis

如果：

X → 再看看
Y → 也再看看

说明这个问题很可能还没有压到真正的 Decision。

13. Ready-to-Analyze Gate

Requirement Clarifier 最终只需要判断：

READY TO ANALYZE
or
CRITICAL INFORMATION STILL MISSING

不是判断：

Checklist 有没有填满。

推荐的 Ready 条件：

Decision 已知
+
Analysis Question 可回答
+
Grain / Population 不含重大歧义
+
Primary Outcome 足够明确
+
有合理 Comparison
+
剩余 uncertainty 不会显著改变 Method / Interpretation / Decision

满足这些条件：

停止澄清，开始分析。

Part II — 这套机制为什么有效

14. Request ≠ Problem

业务方通常给出的，是一个 Request。

例如：

拉一下渠道转化。

它可能只是解决方案表述。

真正的问题可能是：

老板准备调整 Acquisition Budget
↓
需要知道哪些渠道值得继续投
↓
真正需要比较的是 Channel Quality
↓
Signup 不是最终 Outcome
↓
应该继续追到 Activated / Retained / Paid

所以 Requirement Clarification 的第一步不是：

Request
→ SQL

而是：

Request
→ Decision
→ Analysis Question
→ Evidence Needed
→ Analysis

这是整套机制最核心的转换。

15. Decision-first：先知道为什么分析，再决定分析什么

同一个“渠道分析”，可能支持完全不同的 Decision。

Decision A

要不要砍渠道预算？

分析重点可能是：

CAC
→ ICP
→ Activation
→ Retention
→ Paid / Revenue

Decision B

Landing Page 要不要改？

分析重点可能是：

Traffic
→ Landing Page
→ Signup Funnel
→ Message / Audience Fit

Decision C

Sales 要不要更早接手？

分析重点可能是：

Product Signals
→ PQL
→ Sales-assisted
→ Paid

所以：

Decision 决定 Evidence。

16. Requirement Clarification 本质上是 Uncertainty Reduction

需求澄清不是收集“尽可能多的信息”。

真正目标是：

把会影响分析结果的不确定性降下来。

可以把剩余 uncertainty 想象成：

Decision Ambiguity
Semantic Ambiguity
Population Ambiguity
Grain Ambiguity
Metric Ambiguity
Comparison Ambiguity
Scope Ambiguity
Attribution Ambiguity

澄清不是把所有 ambiguity 归零。

只需要处理那些会改变：

Method
Interpretation
Decision

的部分。

17. Materiality：为什么只问“会改变分析的问题”

假设缺失信息是：

“客户”到底指 User 还是 Account？

这是 Material。

因为它改变：

Population
Grain
Metric
Query
Interpretation
Decision

必须问。

但如果缺失的是：

图表最终横向还是纵向？

对当前 diagnosis 没有实质影响。

不应该阻塞分析。

所以 Requirement Clarifier 的核心不是 Questions List。

而是一个：

Materiality Test。

18. Requirement Contract：把问题正式定义下来

聊天过程很容易产生一种错觉：

“大家应该已经理解一致了。”

但真正可靠的状态是：

能不能把问题写成一个 analysis specification？

Requirement Contract 把：

Business Intent

压成：

Decision
Question
Population
Grain
Outcome
Metric
Comparison
Hypotheses
Constraints
Decision Boundary

一旦这些对象稳定下来，

分析空间就被约束住了。

这也是 Requirement Contract 的真正作用：

不是行政记录，而是问题定义。

19. Metric Contract：解决 Semantic Ambiguity

很多“分析错误”发生在 SQL 之前。

例如大家都说：

Retention

但有人指：

Day 30 exact return

有人指：

Day 30 or later rolling retention

有人指：

第二周回来过任意一次

三者都可以叫 retention。

所以：

自然语言业务概念
↓
Metric Contract
↓
可计算对象

是需求澄清里极其重要的一层。

20. Grain：为什么“分析谁”必须很早确定

B2B 产品里：

User Retention ↓
Logo Retention 稳定
NRR ↑

可以同时成立。

因为：

• 个体 User 流动
• Account 仍然续费
• 大客户仍然 Expansion

如果需求说：

客户留存下降。

却没有明确：

User?
Workspace?
Account?
Logo?
Revenue?

后面的讨论很容易全部错位。

所以 Grain 是结构性问题，不是数据实现细节。

21. Comparison：一个数字本身通常没有意义

例如：

PQL → Paid = 20%

好还是不好？

单独无法判断。

如果：

Base Paid Rate = 5%

那么：

Lift = 4×

信息突然变得完全不同。

同样：

D30 retention = 30%

还需要知道：

• 上月多少？
• 同类 ICP 多少？
• Activated users 多少？
• Non-activated users 多少？
• 不同 Channel 是否一致？

所以分析问题经常隐含：

Relative to what?

Requirement Clarification 应尽量把这个比较对象显式化。

22. Trigger：为什么“为什么现在问”很重要

突然出现一个分析需求，通常有 Trigger。

例如：

• Dashboard 下滑
• 新产品版本上线
• Paid channel 放量
• Pricing 改版
• Sales 流程变化
• 重大客户流失
• 老板准备做预算决策

Trigger 经常直接给出：

Potential Change Point
+
Initial Hypothesis
+
Relevant Time Window
+
Potential Confounder

所以：

“最近是什么现象让我们开始关注这个问题？”

往往比：

“你还需要哪些维度？”

更有价值。

23. Hypothesis：业务 Context 是分析的重要先验

分析师不需要假装自己完全没有 prior。

可以问：

目前最怀疑哪几个原因？
最近有没有产品、渠道、定价或流程上的变化？

业务方提供的 hypothesis 不是最终答案。

它只是：

高价值的搜索方向。

后续仍然需要数据验证。

24. Stop Rule：需求澄清必须知道什么时候结束

很多流程只告诉人：

应该问哪些问题。

但更重要的是：

什么时候停止问？

一个实用 Stop Rule：

If remaining uncertainty
is unlikely to materially change:

Method
+
Interpretation
+
Decision

→ STOP CLARIFYING
→ PROCEED

需求澄清的目标不是 Information Completeness。

而是：

Decision Sufficiency。

25. 为什么“合理假设后继续”很重要

现实工作里，信息永远不可能 100% 完整。

如果 GPT 每次遇到一点缺失就阻塞：

请提供时间范围
请提供业务目标
请提供用户类型
请提供数据源
请提供截止日期
……

它会变成低效的问卷机器人。

更好的模式：

Known
→ use it

Materially Unknown
→ ask

Safely Assumable
→ state assumption + proceed

Irrelevant
→ ignore

这既降低沟通成本，也让假设保持透明。

26. 需求澄清本质上也在降低 Rework

典型低效路径：

模糊 Request
↓
分析师自行理解
↓
做 2–3 天
↓
业务方：
“我不是想看这个。”
↓
Rework

需求澄清提前消除的主要是：

Decision Ambiguity
Semantic Ambiguity
Population Ambiguity
Metric Ambiguity
Scope Ambiguity
Comparison Ambiguity

所以它不仅提高分析质量。

它也直接降低：

Rework Cost。

27. 为什么公司语义层值得独立维护

AI 数据分析很容易在一个地方失败：

会计算，但不知道公司内部每个词到底是什么意思。

例如：

User
Workspace
Account
Activation
Retention
PQL
Paid
Expansion
Channel
Sales-assisted

不同公司定义都可能不同。

所以长期使用 GPT 时，最好把公司自己的：

• Entity definitions
• Metric definitions
• Table / field relationships
• Standard filters
• Common analyst gotchas
• Internal terminology

单独维护成 Knowledge / Reference。

这样 Requirement Clarifier 不必每次重新问：

“你们公司的 Activation 是什么意思？”

它可以先读取已有 semantic context。

只有出现冲突或缺失时再问。

28. 需求澄清不是“替代分析师判断”

这套机制最理想的作用是：

GPT
→ 帮忙消除低价值沟通成本
→ 提醒结构性歧义
→ 显式化假设
→ 帮忙形成 Requirement Contract

Human Analyst
→ 判断哪些问题真正重要
→ 理解业务 context
→ 识别隐性机制
→ 决定证据是否足够

GPT 最有价值的地方不是“替你问问题”。

而是：

帮你保持分析纪律。

Part III — 人自己怎么内化这套能力

29. 不用 GPT 时，脑子里只跑 8 个问题

真正需要内化的，不是一张 20 项 Checklist。

而是：

1. 对方最终想做什么决定？

2. 真正需要回答的问题是什么？

3. 我到底在分析谁？
   User / Workspace / Account / Revenue？

4. 核心指标到底怎么算？
   Numerator / Denominator / Window / Eligibility？

5. 和谁比？
   Baseline / Cohort / Control / Segment？

6. 目前最可能的几个解释是什么？

7. 现在缺的什么信息真的会改变分析？

8. 如果结果不同，业务动作会不同吗？

这 8 个问题跑完，

通常已经能判断：

应该继续问，还是已经可以开工。

30. 一个简单的 5 分钟人工 SOP

Minute 1 — 找 Decision

听完需求先问自己：

他拿到这个答案以后准备干什么？

Minute 2 — 改写 Question

把：

看看 retention。

改成：

判断 retention 下降主要来自新用户结构变化还是同类用户自身恶化，以决定修 acquisition 还是 product。

Minute 3 — 锁结构

确认：

Population
Grain
Metric
Comparison

Minute 4 — 找最大的未知

不是列出所有未知。

只找：

最可能让当前分析方向翻盘的 1–3 个 unknown。

Minute 5 — 复述 Contract

用几句话确认：

我理解这次主要是判断 ______，
分析对象是 ______，
核心指标按 ______，
主要比较 ______，
最后是为了决定 ______。

然后开工。

31. 好的问题，通常是在减少一个具体歧义

可以把常见追问映射到它解决的问题。

这比背“需求澄清十问”更有用。

因为知道了：

每一个问题为什么存在。

32. 一个完整例子：Retention 下滑

原 Request：

最近 retention 掉了，帮我分析一下。

Step 1 — Decision

进一步理解：

团队需要决定下一轮优先优化 Acquisition 还是 Product Retention。

Step 2 — Analysis Question

改写：

最近 D30 retention 下滑，主要来自 Acquisition Mix Shift，还是各核心用户 Segment 自身 retention 下降？

Step 3 — Structural Definition

Population:
Self-serve ICP Users

Grain:
User

Primary Outcome:
Activation-based D30 Retention

Comparison:
July vs August Cohorts

Key Segments:
Channel
ICP Type
Account Size

Step 4 — Material Questions

如果还不知道：

1. D30 是 Signup Day 0 还是 Activation Day 0？
2. 8 月是否有 Paid channel 放量或 Sales 流程变化？

这两个会改变分析。

应该问。

如果只是：

最终图表想用柱状图还是折线图？

不影响分析。

不问。

Step 5 — Decision Boundary

If:
各 Channel 内 D30 Retention 基本稳定，
但低质量 Channel 占比提高

→ Acquisition problem

If:
各核心 Channel 内 D30 Retention 同时下滑

→ Product / Retention problem

到这里：

READY TO ANALYZE。

33. 一个完整例子：PQL

原 Request：

帮我看看哪些用户适合销售跟进。

Decision

决定 Sales 应该优先联系哪些 Product-led Users，提高单位销售资源效率。

Analysis Question

在一个可行动的时间点，哪些已经发生的产品行为，能显著预测未来 Paid / Expansion？

Material Clarifications

真正重要的是：

• Outcome 是 First Paid，还是 Expansion？
• Sales 能介入的最早时间点是什么？
• 粒度是 User 还是 Account？
• 是否只看已 Activated 用户？

而不是先问：

• 要不要分 Browser？
• 要不要按周画图？

Requirement Contract

Business Decision:
确定 Sales-assist 优先级

Analysis Question:
哪些 early product signals 可以预测未来 30 天 Paid？

Population:
Activated self-serve ICP Accounts

Grain:
Account

Observation Window:
Day 0–7

Scoring Point:
Day 7

Outcome Window:
Day 8–30

Primary Outcome:
Paid Account

Comparison:
Signal group vs Base Rate

Decision Boundary:
只有当 signal 同时具备足够 Lift + Coverage，
且 Sales intervention cost 合理时才进入 PQL Rule

34. 一个完整例子：Paywall / Pricing

原 Request：

免费额度是不是太多了？

这个问题本身还不能直接分析。

Decision

是否应该调整 Free quota。

Analysis Question

当前 Free quota 是否让大量已经获得价值且有商业意图的用户长期停留在免费区间，从而压低 Paid conversion？

需要澄清的结构

Value Realized?
Usage Distribution?
Quota Hit Rate?
Time to Limit?
Paywall Exposure?
Paid Conversion?
Post-paid Retention?
Cost Distribution?

同时明确：

如果降低 quota 提高 Paid，但显著伤害 Activation / Retention，当前方案仍不能算成功。

这说明：

Decision Boundary 也可以包含 Guardrail。

35. 最终 Mental Model

需求澄清可以压成这一条链：

REQUEST
↓
What decision is hiding underneath?
↓
DECISION
↓
What question must be answered?
↓
ANALYSIS QUESTION
↓
Who / What / Compared with whom?
↓
GRAIN + POPULATION + METRIC + COMPARISON
↓
What is still materially uncertain?
↓
ASK / ASSUME / IGNORE
↓
Would different outcomes change the action?
↓
DECISION BOUNDARY
↓
Is remaining uncertainty still decision-relevant?
↓
YES → CLARIFY
NO  → PROCEED

36. 最后一页 Cheatsheet

DATA ANALYSIS REQUIREMENT CLARIFICATION

1. REQUEST ≠ PROBLEM
   Request
   → Decision
   → Analysis Question

2. LOCK THE STRUCTURE
   Population
   Grain
   Metric
   Comparison
   Time / Cohort

3. REDUCE ONLY MATERIAL UNCERTAINTY
   Would this missing information change:
   Population?
   Grain?
   Metric?
   Method?
   Interpretation?
   Decision?

   YES → ASK
   NO + safe default → ASSUME + STATE
   NO + irrelevant → IGNORE

4. ASK LESS
   每轮只问 2–3 个 High-value Questions

5. WRITE THE CONTRACT
   Decision
   Question
   Population
   Grain
   Metric
   Comparison
   Hypotheses
   Constraints
   Decision Boundary
   Deliverable

6. DEFINE THE STOP RULE
   If remaining uncertainty no longer materially changes:
   Method + Interpretation + Decision

   → STOP CLARIFYING
   → PROCEED

7. FINAL HUMAN CHECK
   对方要做什么决定？
   真正要回答什么？
   我在分析谁？
   指标怎么算？
   和谁比？
   最大的几个解释是什么？
   缺什么真的会改变分析？
   X / Y 会导致不同动作吗？

37. 一句话总结

需求澄清不是把信息问全，而是在分析开始前，把足以改变方法、解释和决策的不确定性降下来。

References / 借鉴来源

这套 Requirement Clarification 机制不是直接照搬某一个现成 Skill，而是把几套公开实践中最有价值的部分组合起来，再针对 PLG 数据分析与真实协作场景做了扩展。

1. Anthropic — data-context-extractor

Source:
https://github.com/anthropics/knowledge-work-plugins/blob/main/data/skills/data-context-extractor/SKILL.md

主要借鉴：

• 先建立公司自己的 Data Semantic Context，而不是让模型每次重新猜业务定义；
• Entity、Metric、Table relationship、Standard filters、Gotchas、内部术语应该成为长期 reference；
• 复杂业务知识应拆到 domain reference 中，持续迭代。

在这份方案里的对应：

Company Semantic Context
→ Entity / Metric / Schema / Filters / Gotchas
→ Requirement Clarifier 优先读取已有定义
→ 只有真正缺失或冲突时才向人追问

2. Anthropic — validate-data

Source:
https://github.com/anthropics/knowledge-work-plugins/blob/main/data/skills/validate-data/SKILL.md

主要借鉴：

• 分析交付前应该独立 QA，而不是把“分析完成”和“分析可信”当成同一件事；
• QA 应重新检查 Question Framing、Data Selection、Population、Metric Definition、Baseline / Comparison；
• 系统检查 Selection Bias、Survivorship、Incomplete Period、Denominator Shift 等分析陷阱；
• 最终 Confidence 应匹配 Evidence Strength。

在这份方案里的对应：

Gate 3 — Before Delivery
↓
Analysis Reviewer
↓
Does the evidence justify the conclusion and action?

3. Community Data Analyst Skill — Clarify First

Source:
https://github.com/stevengalt-sys/claude-skills/blob/main/data-analytics/data-analyst/SKILL.md

主要借鉴：

• 分析前先确认 Business Question、Data Source / Grain、Audience / Decision、Analysis Type；
• Stop rule：只问最会改变输出的 2–3 个问题；
• 用户要求先做时，可以明确列出 assumptions 后继续，而不是无限追问；
• 分析交付使用 What / So What / Now What。

在这份方案里进一步抽象成：

Would this missing information materially change:
Population / Grain / Metric / Method / Interpretation / Decision?

YES → ASK
NO + safe default → ASSUME + STATE
NO + irrelevant → IGNORE

4. OpenAI — Skill Creator

Source:
https://github.com/openai/skills/blob/main/skills/.system/skill-creator/SKILL.md

主要借鉴：

• Skill 的核心 Instructions 应保留真正的 workflow / procedure；
• 详细 Domain Knowledge、Schema、Examples 应放进 References；
• 使用 progressive disclosure，避免把所有知识长期塞进核心上下文。

因此推荐结构是：

Requirement Clarifier Instructions
= 行为纪律 / Workflow

references/
= Metric Contract
  Company Semantic Context
  PLG Analysis Cheatsheet
  Data Schema
  QA Checklist
  Experimentation Rules

5. OpenAI — ChatGPT Projects

Source:
https://help.openai.com/en/articles/10169521-projects-in-chatgpt

主要借鉴：

• Project 可以把长期 Chats、Reference Files 和 Project Instructions 放在同一个上下文中；
• 适合把 Requirement Clarification 从“一次性 Prompt”变成长期重复 workflow。

因此这份笔记优先推荐：

ChatGPT Project
+
Project Instructions
+
Knowledge / Sources

而不是每次重新复制完整方法论。

6. 本笔记自己的组合与扩展

下面这些不是从某个单一来源直接照搬，而是基于上述实践、PLG 分析框架和真实协作问题组合出来的工作机制：

三道 Gate

Gate 1 — Before Analysis
Am I answering the right question?

Gate 2 — During Analysis
Am I measuring reality correctly?

Gate 3 — Before Delivery
Does the evidence justify the conclusion and action?

三层脑子

Requirement Clarifier
→ PLG Analyst
→ Analysis Reviewer

Ask / Assume / Ignore

把“需求澄清”从问题清单改造成 Materiality Decision。

Decision Boundary

要求分析问题明确：

X 结果和 Y 结果是否真的会导致不同业务动作？

Red Team / Developer Challenge

在 Requirement Contract 与正式分析之间，主动模拟开发 / 数据工程的 challenge：

Requirement Contract
→ Developer Challenge
→ Resolve Material Issues
→ Ready to Analyze

它的目的不是增加审批，而是提前暴露：

• 不可计算的指标；
• Entity / Grain 歧义；
• 数据 Join / Attribution 风险；
• Cohort maturity 问题；
• 缺失 tracking；
• 隐性的实现假设；
• 容易导致返工的边界条件。

Reference Principle

这些来源提供的是不同层面的成熟实践：

Anthropic data-context-extractor
→ 业务语义层

Community Clarify First
→ 高价值追问 + Stop Rule

OpenAI Skill Creator
→ Skill / References 架构

Anthropic validate-data
→ 交付前独立 QA

ChatGPT Projects
→ 长期使用载体

本笔记
→ 将以上机制组合成
   Requirement Clarification
   + PLG Analysis
   + Developer Challenge
   + Analysis Review

最终目标不是复制任何一个 Skill。

而是形成一套：

能直接放进 ChatGPT 使用，同时人自己也能理解并内化的需求澄清机制。