with one click
p0d-needs-archaeologist
// 需求考古五步法。用户说出来的需求只是冰山一角,真正的需求往往埋在历史决策、组织结构和业务演化中。 这个 Skill 教你如何挖掘深层需求。
// 需求考古五步法。用户说出来的需求只是冰山一角,真正的需求往往埋在历史决策、组织结构和业务演化中。 这个 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 才能帮你拆出更深层的结构。