// 需求考古五步法。用户说出来的需求只是冰山一角，真正的需求往往埋在历史决策、组织结构和业务演化中。 这个 Skill 教你如何挖掘深层需求。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p0d-needs-archaeologist |
| description | 需求考古五步法。用户说出来的需求只是冰山一角，真正的需求往往埋在历史决策、组织结构和业务演化中。 这个 Skill 教你如何挖掘深层需求。 |
用户说出来的需求是最新的土壤层，真正的需求往往埋在历史决策、组织结构和业务演化中。用考古的方法一层层挖下去。
一个需求线索 + 可获取的业务背景信息。
示例输入：
场景: 客户成功团队反馈说"客户总是说系统不好用，但具体哪里不好用又说不清楚"
背景: SaaS 企业软件，客户续费率下降
五步考古结果 + 深层需求报告 + 历史约束分析。
任务：不要立刻分析问题，先描绘当前的"正常状态"是什么。
关键问题：
输出格式：
当前正常状态:
process: "现在的流程是什么"
roles: ["涉及角色及其行为"]
artifacts: ["产出的文档/数据/交付物"]
when_started: "什么时候开始的"
who_defined: "谁定义的这个正常"
任务：追溯当前流程的历史演化，找出"为什么会变成这样"。
关键问题：
输出格式：
历史演化:
previous_state: "之前是什么"
trigger_event: "什么事件导致改变"
decision_maker: "谁做的决定"
decision_context: "当时的约束和信息"
was_reasonable_then: "当时是否合理"
任务：识别当前流程背后的约束条件，找出"为什么大家都知道不好但还在这么做"。
关键问题：
输出格式：
约束条件:
organizational: ["组织结构约束"]
procedural: ["流程/制度约束"]
technical: ["技术约束"]
human: ["人员/能力约束"]
hard_vs_soft: "哪些是硬性约束，哪些是软性约束"
if_removed: "如果消失会怎么做"
任务：查找之前解决这个问题的尝试，分析失败原因。
关键问题：
输出格式：
历史尝试:
attempts:
- what: "尝试了什么"
how: "怎么做的"
why_failed: "失败原因"
legacy: "遗留影响"
collective_memory: "团队对这个问题的共同记忆是什么"
defense_mechanism: "有没有因此产生的防御机制"
任务：综合前四层，提取真正的深层需求。
关键问题：
输出格式：
深层需求:
surface_problem: "表面问题"
deep_need: "真正的需求"
why_hidden: "为什么被埋住"
productizable: "能否被产品化"
if_solved: "解决后表面问题会怎么变"
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: ["可以先做的小胜利"]
线索：
"客户总是说系统不好用，但具体哪里不好用又说不清楚"
考古结果：
| 层次 | 发现 |
|---|---|
| 现状层 | CS 团队每月打电话回访，客户说"还行"，但续费时却说"要考虑"。这个"还行"是 CS 团队定义的正常。 |
| 历史层 | 3 年前产品简化了界面，但把高级功能藏得更深了。当时的决策是"降低新手难度"。 |
| 约束层 | 产品团队不能改界面（因为上次改版被老用户抗议），CS 团队不能说"产品不好"（KPI 是续费率）。 |
| 失败层 | 1 年前尝试做过"用户成功指南"，但没人看，因为内容是产品写的，不是用户语言。 |
| 深层需求 | 客户真正想要的不是"更好用的界面"，而是"能让他们在内部证明产品价值的证据"——他们需要向老板解释为什么买这个。 |
重定义：
用户说出来的需求是最新的土壤层，真正的需求往往埋得更深。
需求考古不是为了听起来神秘。它只是承认一个朴素的事实：真正的需求很少直接躺在表面等你收集，它更像一层层被压住的结构——最上面是表达，再往下是场景、关系、情绪、补偿动作、责任缝隙和长期代价。
考古这个比喻强调三件事：
来源：《AI rebuild product needs》第22章第1节——为什么"考古"比"总结"更准确。
AI 最擅长的不是把表达整理得更好看，而是在许多尚未被完全解释的痕迹之间工作：
但有一个前提不能跳过：AI 只能放大你已经采回来的痕迹，不能替你下到现场。没有现场，模型就只能消费平台化输入；没有处境材料，模型再强也只能对着表达层工作。
来源：《AI rebuild product needs》第22章第2节——AI 真正擅长什么。
在 AI 时代，一个人的优势越来越不只是"会不会用 AI"，而是"他手里有没有 AI 不知道的东西"。
那个东西可能是：在行业里长期浸泡形成的判断力、只有真正去了现场才能看到的补偿行为、组织从不公开表达的真实摩擦、或只有长期贴近用户才能养成的微妙辨别力。没有这些，一个漂亮的 prompt 仍然只能让模型在公共知识的平均值上打转。
来源：《AI rebuild product needs》第22章第2节——人的优势是什么。
很多团队用 AI 做需求分析失败，不是因为模型不好，而是因为输入太扁平。他们通常给 AI 的是：访谈逐字稿、工单摘要、评论合集、问卷答案——然后期望模型直接产出"真实需求""产品机会""优先方向"。
更成熟的输入应该包含：
一旦这些材料进入模型，AI 才能真正做拆层，而不仅仅是让摘要更好看。
来源：《AI rebuild product needs》第22章第3节——给 AI 的输入必须先重写。
LLM 有一个团队非常容易误读的结构性特征：它们通常不会真正说"不"。
更准确地说，它们更像是建议生成器，而不是天然的批评者。很多时候，只要你的问题前提已经有偏差，模型就会顺着这个前提不断组织语言、补全逻辑、扩展方案，让整个东西看起来越来越完整、越来越像答案。但"越来越像答案"不等于做过反向质疑、价值校验和方向修正。
这就是为什么越依赖 AI 直接做决策的团队，风险越大。AI 放大的不只是效率，还有你的假设、你的偏差和你的误判。
来源：《AI rebuild product needs》第22章第2节——LLM 不会真正说不。
输入：一个需求线索 + 可获取的业务背景信息
处理：
输出：现场观察记录（场景/关系/补偿动作/代价）
输入：Step 1 的现场观察记录
处理：
输出：分层记录 + 伪信号过滤结果
输入：Step 2 的分层记录（不要只给表达层！）
处理：
输出：AI 拆层报告（假设形式，非结论形式）
输入：Step 3 的 AI 拆层报告
处理：
输出：现场验证结论（假设成立/不成立/需修正）
输入：Step 4 的验证结论
处理：
输出：系统边界设计文档（三列分类）
输入：Step 1-5 的全部产出
处理：
输出：深层需求报告（表面问题/深层需求/为什么被埋住/能否产品化/连锁效应）
线索：
"各部门都在抱怨知识库搜索不好用，我们想升级语义搜索。"
五步考古：
| 步骤 | 发现 |
|---|---|
| Step 1 人进现场 | 先看谁最容易搜不到——结果发现是入职头两周的新人 |
| Step 2 人做初筛 | 把"搜索不好用"拆开：召回问题、命名问题、入口问题、新人不懂默认路径 |
| Step 3 AI 做拆层 | 喂入访谈、工单、使用记录，让模型比较新人和老员工的差异。模型发现：新人搜不到的核心原因不是召回率，而是他们不知道该用什么关键词（行话/缩写/默认路径） |
| Step 4 人回现场 | 验证假设：新人确实不知道该搜什么词，老员工知道但没觉得这是"搜索问题" |
| Step 5 定义边界 | 重点不只是搜索算法，而是知识入口设计 + 命名体系 + 新人引导 |
深层需求：
来源：《AI rebuild product needs》第22章工具卡示例。
线索：
"客户成功团队反馈说'客户总是说系统不好用，但具体哪里不好用又说不清楚'。"
五步考古：
| 步骤 | 发现 |
|---|---|
| Step 1 人进现场 | CS 团队每月打电话回访，客户说"还行"，但续费时却说"要考虑"。这个"还行"是 CS 团队定义的正常 |
| Step 2 人做初筛 | 3 年前产品简化了界面，把高级功能藏得更深了。当时的决策是"降低新手难度" |
| Step 3 AI 做拆层 | 产品团队不能改界面（上次改版被老用户抗议），CS 团队不能说"产品不好"（KPI 是续费率）。1 年前做过"用户成功指南"，但没人看——内容是产品写的，不是用户语言 |
| Step 4 人回现场 | 客户真正想要的不是"更好用的界面"，而是"能让他们在内部证明产品价值的证据"——他们需要向老板解释为什么买这个 |
| Step 5 定义边界 | 不改界面，增加"成功案例生成器"和"价值报告自动化" |
深层需求：
启示：
如果直接让 AI 总结"客户反馈"，得到的会是"界面需优化""功能需增强"——这些都是表达层的整理。只有人先进现场、带回处境和补偿行为材料，AI 才能帮你拆出更深层的结构。