p0d-needs-archaeologist

---
name: p0d-needs-archaeologist
version: 1.0.0
description: 需求考古五步法。用户说出来的需求只是冰山一角，真正的需求往往埋在历史决策、组织结构和业务演化中。 这个 Skill 教你如何挖掘深层需求。
  基于《AI rebuild product needs》工具卡。
author: Max
tags: p0, 需求发现, 需求考古
- book-skill
- needs-discovery
- deep-research
- archaeology
- ai-product
requires: []
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p0d-needs-archaeologist
stage: p0d
source_book: AI rebuild product needs
source_chapter: 第4章 需求考古

---


# 需求考古五步法

## 一句话定位

用户说出来的需求是最新的土壤层，真正的需求往往埋在历史决策、组织结构和业务演化中。用考古的方法一层层挖下去。

## 何时触发

- 表面需求和深层问题明显不匹配
- 用户自己也说不清楚到底想要什么
- 需要理解业务的历史演化和组织约束
- 多个利益相关者的需求相互矛盾

## 输入

一个需求线索 + 可获取的业务背景信息。

**示例输入**：
```
场景: 客户成功团队反馈说"客户总是说系统不好用，但具体哪里不好用又说不清楚"
背景: SaaS 企业软件，客户续费率下降
```

## 输出

五步考古结果 + 深层需求报告 + 历史约束分析。

## 五个步骤

### Step 1: 现状层挖掘（描绘当前的"正常"是什么）

**任务**：不要立刻分析问题，先描绘当前的"正常状态"是什么。

**关键问题**：
- 现在大家都是怎么做的？
- 这个"正常"是从什么时候开始的？
- 谁定义了这个"正常"？

**输出格式**：
```
当前正常状态:
  process: "现在的流程是什么"
  roles: ["涉及角色及其行为"]
  artifacts: ["产出的文档/数据/交付物"]
  when_started: "什么时候开始的"
  who_defined: "谁定义的这个正常"
```

### Step 2: 历史层追溯（这个"正常"是怎么来的）

**任务**：追溯当前流程的历史演化，找出"为什么会变成这样"。

**关键问题**：
- 之前是怎么做的？为什么改了？
- 这个改变是因为什么事件/决策/人员变动？
- 当时的选择在当时是否合理？

**输出格式**：
```
历史演化:
  previous_state: "之前是什么"
  trigger_event: "什么事件导致改变"
  decision_maker: "谁做的决定"
  decision_context: "当时的约束和信息"
  was_reasonable_then: "当时是否合理"
```

### Step 3: 约束层识别（是什么让大家不能做更好）

**任务**：识别当前流程背后的约束条件，找出"为什么大家都知道不好但还在这么做"。

**关键问题**：
- 是什么组织结构/制度/技术/人员约束导致了现状？
- 如果这些约束消失，大家会怎么做？
- 这些约束是硬性的还是软性的？

**输出格式**：
```
约束条件:
  organizational: ["组织结构约束"]
  procedural: ["流程/制度约束"]
  technical: ["技术约束"]
  human: ["人员/能力约束"]
  hard_vs_soft: "哪些是硬性约束，哪些是软性约束"
  if_removed: "如果消失会怎么做"
```

### Step 4: 失败层分析（之前尝试过什么，为什么没成功）

**任务**：查找之前解决这个问题的尝试，分析失败原因。

**关键问题**：
- 之前有没有人尝试解决过？怎么做的？
- 为什么没成功？是方案问题、执行问题还是时机问题？
- 那些失败留下了什么遗产（负面印象、防御机制）？

**输出格式**：
```
历史尝试:
  attempts:
    - what: "尝试了什么"
      how: "怎么做的"
      why_failed: "失败原因"
      legacy: "遗留影响"
  collective_memory: "团队对这个问题的共同记忆是什么"
  defense_mechanism: "有没有因此产生的防御机制"
```

### Step 5: 深层需求层提取（真正要解决的是什么）

**任务**：综合前四层，提取真正的深层需求。

**关键问题**：
- 如果所有约束都消失，用户真正想要的是什么？
- 这个深层需求是否能够被产品化？
- 如果解决了这个，表面的问题是否自然消失？

**输出格式**：
```
深层需求:
  surface_problem: "表面问题"
  deep_need: "真正的需求"
  why_hidden: "为什么被埋住"
  productizable: "能否被产品化"
  if_solved: "解决后表面问题会怎么变"
```

## 综合输出格式

```yaml
needs_archaeology:
  input: "原始线索"
  background: "业务背景"
  
  step1_current:
    normal_state: "当前正常状态"
    roles: ["角色"]
    artifacts: ["产出物"]
    origin: "起源"
    definer: "定义者"
  
  step2_history:
    previous: "之前状态"
    trigger: "触发事件"
    decision: "决策"
    context: "当时约束"
    was_reasonable: "当时是否合理"
  
  step3_constraints:
    organizational: ["组织约束"]
    procedural: ["流程约束"]
    technical: ["技术约束"]
    human: ["人员约束"]
    hard_soft: "硬软性分析"
  
  step4_failures:
    attempts: ["尝试列表"]
    legacy: "遗留影响"
    defense: "防御机制"
  
  step5_deep_need:
    surface: "表面问题"
    deep: "深层需求"
    hidden_reason: "为什么被埋住"
    productizable: "能否产品化"
    cascade_effect: "解决后的连锁效应"
  
  recommendation:
    approach: "建议方法"
    risks: ["风险"]
    stakeholders: ["需要拉通的人"]
    quick_wins: ["可以先做的小胜利"]
```

## 快速使用法

1. 找一个具体的需求线索（不要抽象）
2. 逐层走完五步
3. **每一步都要找到具体证据，不要靠推断**
4. 第五步的结论要能解释第一步的"正常"为什么会导致问题

## 示例：完整走一遍

**线索**：
> "客户总是说系统不好用，但具体哪里不好用又说不清楚"

**考古结果**：

| 层次 | 发现 |
|------|------|
| 现状层 | CS 团队每月打电话回访，客户说"还行"，但续费时却说"要考虑"。这个"还行"是 CS 团队定义的正常。 |
| 历史层 | 3 年前产品简化了界面，但把高级功能藏得更深了。当时的决策是"降低新手难度"。 |
| 约束层 | 产品团队不能改界面（因为上次改版被老用户抗议），CS 团队不能说"产品不好"（KPI 是续费率）。 |
| 失败层 | 1 年前尝试做过"用户成功指南"，但没人看，因为内容是产品写的，不是用户语言。 |
| 深层需求 | 客户真正想要的不是"更好用的界面"，而是"能让他们在内部证明产品价值的证据"——他们需要向老板解释为什么买这个。 |

**重定义**：
- 表面需求："改进界面易用性"
- 深层需求："提供价值证明工具，帮助客户在组织内部推广"
- 方法：不改界面，增加"成功案例生成器"和"价值报告自动化"

## 常见误判

- **急于分析**：还没描绘清楚"正常"就开始批判
- **忽视历史合理性**：当时的决策在当时可能是合理的
- **忽视失败遗产**：之前的失败可能留下了防御机制
- **深层需求过大**：提取出来的深层需求可能超出产品能力范围

## 一句判断

> 用户说出来的需求是最新的土壤层，真正的需求往往埋得更深。

## 核心概念

### 概念一：为什么"考古"比"总结"更准确

需求考古不是为了听起来神秘。它只是承认一个朴素的事实：真正的需求很少直接躺在表面等你收集，它更像一层层被压住的结构——最上面是表达，再往下是场景、关系、情绪、补偿动作、责任缝隙和长期代价。

考古这个比喻强调三件事：
1. 你面对的不是答案，而是痕迹
2. 你要做的不是直接判断，而是分层挖掘
3. 你必须尊重上下文，不能把痕迹从原来的关系里拔出来单独解释

> 来源：《AI rebuild product needs》第22章第1节——为什么"考古"比"总结"更准确。

### 概念二：AI 真正擅长的是跨痕迹拆层

AI 最擅长的不是把表达整理得更好看，而是在许多尚未被完全解释的痕迹之间工作：

- 在不同用户的跟访笔记中找到重复出现的补偿行为
- 比较不同角色承担的代价是否指向同一个结构性问题
- 把"用户说的"和"用户做的"分成两张不同的地图
- 把相似的风险跨场景聚类成更稳定的假设
- 帮你提出边界问题：哪些该系统承担，哪些自动化本身会制造新风险

但有一个前提不能跳过：AI 只能放大你已经采回来的痕迹，不能替你下到现场。没有现场，模型就只能消费平台化输入；没有处境材料，模型再强也只能对着表达层工作。

> 来源：《AI rebuild product needs》第22章第2节——AI 真正擅长什么。

### 概念三：人的优势是"AI 不知道的东西"

在 AI 时代，一个人的优势越来越不只是"会不会用 AI"，而是"他手里有没有 AI 不知道的东西"。

那个东西可能是：在行业里长期浸泡形成的判断力、只有真正去了现场才能看到的补偿行为、组织从不公开表达的真实摩擦、或只有长期贴近用户才能养成的微妙辨别力。没有这些，一个漂亮的 prompt 仍然只能让模型在公共知识的平均值上打转。

> 来源：《AI rebuild product needs》第22章第2节——人的优势是什么。

### 概念四：给 AI 的输入必须先重写

很多团队用 AI 做需求分析失败，不是因为模型不好，而是因为输入太扁平。他们通常给 AI 的是：访谈逐字稿、工单摘要、评论合集、问卷答案——然后期望模型直接产出"真实需求""产品机会""优先方向"。

更成熟的输入应该包含：
- 用户角色和角色关系
- 问题发生的具体场景
- 重复出现的补偿动作
- 哪一步被多做了一遍
- 如果没人补位会怎样
- 为什么这件事让人疲惫而不只是烦躁
- 哪些部分涉及责任、信任、解释权和判断权

一旦这些材料进入模型，AI 才能真正做拆层，而不仅仅是让摘要更好看。

> 来源：《AI rebuild product needs》第22章第3节——给 AI 的输入必须先重写。

### 概念五：LLM 的结构性倾向——不会说不

LLM 有一个团队非常容易误读的结构性特征：它们通常不会真正说"不"。

更准确地说，它们更像是建议生成器，而不是天然的批评者。很多时候，只要你的问题前提已经有偏差，模型就会顺着这个前提不断组织语言、补全逻辑、扩展方案，让整个东西看起来越来越完整、越来越像答案。但"越来越像答案"不等于做过反向质疑、价值校验和方向修正。

这就是为什么越依赖 AI 直接做决策的团队，风险越大。AI 放大的不只是效率，还有你的假设、你的偏差和你的误判。

> 来源：《AI rebuild product needs》第22章第2节——LLM 不会真正说不。

## 分步执行

### Step 1：人先进现场——看场景、关系、补偿动作和代价

**输入**：一个需求线索 + 可获取的业务背景信息

**处理**：
1. 不是先收集平台上反复出现的反馈，而是先走进现实
2. 观察场景：问题在什么时间、空间、动作链路里发生
3. 观察关系：谁在等谁、谁握着解释权、谁承担后果
4. 观察补偿动作：用户在系统外多做了什么
5. 观察代价：什么东西在被持续消耗

**输出**：现场观察记录（场景/关系/补偿动作/代价）

---

### Step 2：人先做初筛——区分表达、场景、处境和代价

**输入**：Step 1 的现场观察记录

**处理**：
1. 把观察到的内容分层：哪些是表达、哪些是场景、哪些是处境、哪些是代价
2. 过滤明显伪信号：哪些是一次性情绪、哪些是平台放大、哪些是技术兴奋
3. 压缩值得深挖的问题范围
4. 标记需要进一步验证的假设

**输出**：分层记录 + 伪信号过滤结果

---

### Step 3：AI 做拆层——比较、聚类、找重复补偿行为、提假设

**输入**：Step 2 的分层记录（不要只给表达层！）

**处理**：
1. 把访谈笔记、跟访记录、补偿行为清单一起喂给 AI
2. 提问格式要改：
   - ❌ 不要问："请总结高频需求"
   - ✅ 要问："请识别用户在系统外重复执行的补偿行为。这些行为分别在弥补什么风险？哪些风险适合被系统辅助，哪些风险如果由系统直接替代，可能制造新的误判？"
3. 让模型比较不同角色、不同场景的痕迹
4. 让模型提出假设，而不是下结论

**输出**：AI 拆层报告（假设形式，非结论形式）

---

### Step 4：人回现实验证——假设是否解释了持续代价

**输入**：Step 3 的 AI 拆层报告

**处理**：
1. 模型给的是假设，不是结论
2. 带假设回到现场，验证：用户是否确实在为这些风险持续付出代价？
3. 不再主要问"用户喜不喜欢这个功能"，而是问"补偿行为背后的假设是否成立"
4. 如果假设不成立，回到 Step 2 重新分层

**输出**：现场验证结论（假设成立/不成立/需修正）

---

### Step 5：团队定义边界——哪些劳动进系统，哪些判断留给人

**输入**：Step 4 的验证结论

**处理**：
1. 问题已经足够清晰，现在回答：系统到底该接住哪一段劳动？
2. 将白板分为三列：
   - **系统直接承接**：录音转写、重点提炼、候选待办生成
   - **系统辅助判断**：责任是否真正成立、事项是否成熟到可以推进
   - **必须留给人**：谁来拍板、共识是否算成立、现在推会不会太早
3. 用"做了以后会发生什么"替代"还能不能再自动一步"

**输出**：系统边界设计文档（三列分类）

---

### Step 6：提炼深层需求——真正要解决的是什么

**输入**：Step 1-5 的全部产出

**处理**：
1. 综合前五步，提取真正的深层需求
2. 对比：表面问题 vs 深层需求
3. 验证：如果深层需求被满足，表面问题是否自然消失？
4. 评估：深层需求能否被产品化？
5. 确定：需要拉通哪些利益相关者

**输出**：深层需求报告（表面问题/深层需求/为什么被埋住/能否产品化/连锁效应）

---

## 示例 1

### 场景：企业知识库——"搜索不好用"

**线索**：

> "各部门都在抱怨知识库搜索不好用，我们想升级语义搜索。"

**五步考古**：

| 步骤 | 发现 |
|------|------|
| Step 1 人进现场 | 先看谁最容易搜不到——结果发现是入职头两周的新人 |
| Step 2 人做初筛 | 把"搜索不好用"拆开：召回问题、命名问题、入口问题、新人不懂默认路径 |
| Step 3 AI 做拆层 | 喂入访谈、工单、使用记录，让模型比较新人和老员工的差异。模型发现：新人搜不到的核心原因不是召回率，而是他们不知道该用什么关键词（行话/缩写/默认路径） |
| Step 4 人回现场 | 验证假设：新人确实不知道该搜什么词，老员工知道但没觉得这是"搜索问题" |
| Step 5 定义边界 | 重点不只是搜索算法，而是知识入口设计 + 命名体系 + 新人引导 |

**深层需求**：

- 表面需求："升级语义搜索"
- 深层需求：帮助新人在不了解内部术语和默认路径的情况下，也能可靠获取信息
- 为什么被埋住：老员工已经习惯了，不觉得这是问题；新人不敢说"我搜不到"
- 产品化方向：新人常用文档推荐、热门搜索路径展示、行话与正式名称关联

> 来源：《AI rebuild product needs》第22章工具卡示例。

---

## 示例 2

### 场景：SaaS 续费——"客户说系统不好用但说不清楚"

**线索**：

> "客户成功团队反馈说'客户总是说系统不好用，但具体哪里不好用又说不清楚'。"

**五步考古**：

| 步骤 | 发现 |
|------|------|
| Step 1 人进现场 | CS 团队每月打电话回访，客户说"还行"，但续费时却说"要考虑"。这个"还行"是 CS 团队定义的正常 |
| Step 2 人做初筛 | 3 年前产品简化了界面，把高级功能藏得更深了。当时的决策是"降低新手难度" |
| Step 3 AI 做拆层 | 产品团队不能改界面（上次改版被老用户抗议），CS 团队不能说"产品不好"（KPI 是续费率）。1 年前做过"用户成功指南"，但没人看——内容是产品写的，不是用户语言 |
| Step 4 人回现场 | 客户真正想要的不是"更好用的界面"，而是"能让他们在内部证明产品价值的证据"——他们需要向老板解释为什么买这个 |
| Step 5 定义边界 | 不改界面，增加"成功案例生成器"和"价值报告自动化" |

**深层需求**：

- 表面需求："改进界面易用性"
- 深层需求：提供价值证明工具，帮助客户在组织内部推广产品
- 为什么被埋住：CS 团队的 KPI 是续费率，不敢说"产品不好"；客户的痛点不在使用层面，在组织政治层面
- 产品化方向：成功案例生成器、价值报告自动化、内部推广工具包

**启示**：

如果直接让 AI 总结"客户反馈"，得到的会是"界面需优化""功能需增强"——这些都是表达层的整理。只有人先进现场、带回处境和补偿行为材料，AI 才能帮你拆出更深层的结构。