Menu
系统性思维——结构化分析、关系映射、反馈回路识别
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p13b-systemic-thinker |
| description | 系统性思维——结构化分析、关系映射、反馈回路识别 |
| stage | p13 |
| tags | ["判断力","系统性思维","结构分析"] |
| source_book | 判断力与直觉力 |
| source_chapter | 第2章 系统性思维：看见看不见的 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| system_description | 系统边界与要素描述 |
| problem_symptom | 问题现象 |
| attempted_fixes | 已尝试的修复措施 |
很多管理者和产品团队之所以误判，是因为看到的是事件，却把事件当成了问题本身。用户抱怨了一句、销售提了一个要求、老板点了一个方向，团队就迅速进入方案讨论。但从更深的视角看：事件之下是持续出现的趋势，趋势之下是流程/结构/激励和协同机制，更深一层是用户的处境、组织的惯性和人们习以为常的思维方式。真正值得优先解决的问题，通常不在表面表达本身，而在其背后的结构性原因。只对事件作反应，团队就会一直救火。
判断一个问题是否值得优先解决的第一层过滤器。"真不真"——把功能语言翻译回问题语言，看有没有可观察的代价（补偿行为、绕路行为、补丁行为）。"痛不痛"——看不解决时用户到底损失了什么。"频不频"——区分戏剧性与普遍性。"急不急"——如果四周不动会怎样，会不会影响收入/试点/关键流程。"值不值"——相对判断而非绝对判断，在有限资源下比较杠杆点。
团队还没把问题看清，就已经开始讨论做法。方案比问题更具体、更容易被想象、也更容易被 AI 放大。一个还没被证实的问题，只要被包装成三页完整文档，就会突然显得像一件"马上就能推进"的事。AI 时代方案太容易做出来了，一个模糊需求半小时就能被整理成完整文档，一个零散想法一下午就能被包装成像样原型。团队会因此产生一种危险错觉：既然已经做出了像样方案，那问题大概就是值得做的。
"我们要不要做一个 AI 生成按钮？"——这是方案语言，它默认方案已被允许存在。"用户当前到底卡在哪一步？他处在什么具体处境里？如果不加这个能力，用户今天是怎么完成任务的？"——这是问题语言，它会迫使团队先判断现状再讨论方案。一个成熟团队的特征，不是会议里方案很多，而是能在方案出现之前先把问题说准。
那些重复确认、手工抄录、额外截图、反复找人复核、自己留一份备忘、会后再私下补发一条说明，都是典型的补偿行为。补偿行为越稳定，越说明系统没有接住某种真实代价。很多高价值问题最初看起来并不大，可能只是用户在某个具体处境里反复多做的一小步，但正是这种微需求比宏大表达更接近优先级真相。
"很多管理者和产品团队之所以误判，是因为他们看到的是事件，却把事件当成了问题本身。" ——书稿第2章
事件是冰山露出水面的部分，天然容易吸引注意力——谁说了什么、老板关注什么、数据最近怎么波动。但真正值得优先解决的问题，通常藏在结构层：流程缺陷、激励错位、协同断裂、用户默认行为模式。团队如果只对事件作反应，就会陷入永远救火的循环。穿透事件层不是为了分析得更深沉，而是为了找到真正的杠杆点。应用：每次收到需求或反馈时，强制做一次四层穿透——这件事背后有没有持续趋势？趋势背后是什么结构？结构背后是什么心智模式？穿透后再判断它配不配占用当前资源。
"一个还没被证实的问题，只要被包装成三页完整文档，就会突然显得像一件'马上就能推进'的事。" ——书稿第2章
AI极大降低了方案产出的门槛。一个模糊需求半小时就能被整理成完整文档，一个零散想法一下午就能被包装成像样原型。这制造了一种危险错觉：方案完成度等于问题成立性。但方案成立不代表问题成立，做得出来不代表值得先做。团队会因此在错误的问题上努力得太快。应用：在方案讨论开始前设置"问题确认关卡"——如果团队不能用五问（真/痛/频/急/值）清楚回答问题本身，就不允许进入方案层讨论。用问题语言开会，而非方案语言。
"那些重复确认、手工抄录、额外截图、反复找人复核、自己留一份备忘，都是典型的补偿行为。" ——书稿第2章
补偿行为之所以比访谈反馈更可靠，是因为它不依赖用户的表达能力，而是直接反映在行为里。用户可能不会说"这个流程有问题"，但他会在系统外多做一步、多确认一次、多留一份备份。补偿行为越稳定，说明系统没有接住的代价越真实。很多高价值问题最初看起来并不大，可能只是用户在某个具体处境里反复多做的一小步，但正是这种微需求比宏大表达更接近优先级真相。应用：到真实环境里做"补偿行为考古"——观察用户在系统外额外做了什么：有没有自己搭过临时脚本？有没有在Excel里留一份备份？有没有反复找人复核？这些微小但稳定的行为，往往指向比宏大需求更真实的优先级。
拿到需求/反馈/点子后，先从事件语言翻译成问题语言。不要问"用户是不是要这个功能"，先问"用户到底遇到了什么障碍，承担了什么成本，卡在了哪一步"。如果这个问题今天不存在，用户是怎么凑合过去的？把功能表达还原成任务障碍和现实代价。
画出问题的四层结构：表层事件（谁说了什么）→ 趋势层（是否持续出现）→ 结构层（流程/机制/协同问题）→ 心智层（用户的默认行为模式和组织惯性）。判断当前讨论停留在哪一层，以及真正需要解决的问题在哪个层。
对问题逐一过五问：真不真（有行为证据还是只有观点）、痛不痛（不解决的损失是什么）、频不频（系统性还是偶发）、急不急（四周不动会怎样）、值不值（是否值得拿走当前最稀缺的资源）。每问给出明确判断和依据。
检查当前讨论是否已经滑入方案语言。如果有人开始讨论功能细节、开发排期、页面结构、交付路径，但没有人能清楚回答"这个问题到底真不真、痛不痛、频不频、急不急、值不值"，那就是方案冲动在作祟。立即把讨论拉回问题层。
把经过五问过滤的问题放在一起比较。优先级不是给问题打道德分，而是在比较有限资源应该先压在哪个杠杆点上。有时候一个不那么漂亮的问题，反而能更直接影响关键指标、用户信任或商业推进。
场景：一款面向中小团队的 AI 协作产品。销售团队不断反馈大客户想要"自动生成周报 PPT"功能。同时用户成功团队提到：很多已开通试点的团队第二周使用频率明显下降，因为管理员不知道如何校验 AI 产出来源。
五问对比分析：
| 维度 | 自动生成周报 PPT | 管理员不敢继续用 |
|---|---|---|
| 真不真 | 可能只是汇报效率低 | 很真，已有行为回退 |
| 痛不痛 | 部分管理者有痛感 | 很痛，直接影响试点继续 |
| 频不频 | 不一定高频 | 多团队都出现，系统性 |
| 急不急 | 不做也能凑合 | 卡在采用关键节点 |
| 值不值 | 可以卖但不解决留存 | 影响整条使用链路 |
结论：真正该优先解决的，不一定是最容易被说服的那个问题，而是最影响产品成立性的那个问题。前者会让团队觉得自己在"向前冲"，后者才真正决定产品能不能留住人。
场景：产品会上有人说"转化率最近下降了"，接着马上有人提议加一个 AI 助手。
冰山分析：
方案冲动检测：当前讨论已经从"转化率下降"直接跳到"加 AI 助手"，中间缺少对问题本身的判断。应先回答：转化率到底在哪一步掉了？为什么掉了？不解决的话四周后会怎样？然后才能讨论该做什么。
更有效的问法：用户当前到底卡在哪一步？他处在什么具体处境里？如果不加这个能力，用户今天是怎么完成任务的？他现在在系统外做了哪些补偿动作？
不要问"用户是不是要这个功能"，先问"用户到底遇到了什么障碍，承担了什么成本，卡在了哪一步"。
关键不是看用户有没有提，而是看不解决时用户到底损失了什么。
区分"戏剧性"与"普遍性"。
急迫性不是情绪，而是时间约束。
永远是相对判断而非绝对判断。
| 补偿行为 | 说明 | 问题信号 |
|---|---|---|
| 重复确认 | 用户做完后还要再检查一遍 | 系统不够可靠或不够透明 |
| 手工抄录 | 在系统外手动记录一份 | 数据不互通或不信任系统 |
| 额外截图 | 保留截图作为凭证 | 缺乏可追溯性 |
| 反复找人复核 | 总要找同事确认 | 判断依据不足 |
| 自己留备忘 | 私下维护一份备份 | 不信任系统持久性 |
| 会后补发说明 | 开完会还要再补一条 | 系统没有接住会后同步 |
从你最近收到的三个需求里，任选一个，写下这五个问题：
最后再补一句：
如果我今天不能讨论方案，只能讨论问题，我会怎么描述它？
这句话会强迫你从"想做什么"退回到"为什么值得做"。这正是优先级判断的起点。
将团队会议从方案语言切换到问题语言的结构化模板：
今天不讨论怎么做，只讨论值不值得做。
我们先回答五个问题，再讨论方案。
1. 事件还原：谁说了什么？什么时候？什么场景？
2. 问题翻译：他真正想完成的任务是什么？
3. 冰山穿透：
- 事件层：____
- 趋势层：是否持续出现？多长时间了？
- 结构层：流程/机制/激励有什么问题？
- 心智层：用户的默认行为模式是什么？
4. 补偿行为：用户在系统外做了什么来弥补？
真不真: [ ] 有行为证据 [ ] 只有观点
证据: ____
痛不痛: [ ] 影响关键指标 [ ] 只是体验优化
损失: ____
频不频: [ ] 高频/系统性 [ ] 偶发/个别
频率: ____
急不急: [ ] 卡在关键节点 [ ] 可以再等等
四周不动会: ____
值不值: [ ] 杠杆点高 [ ] 解法太重
理由: ____
结论: [ ] 优先处理 [ ] 排入待办 [ ] 暂缓 [ ] 放弃
下一步: ____
负责人: ____
为每个判断维度提供量化参考：
| 分数 | 标准 |
|---|---|
| 5 | 有稳定补偿行为、有可观察的流程卡点、有多人反复提到 |
| 4 | 有行为证据但样本较少 |
| 3 | 有间接证据（数据异常、工单堆积） |
| 2 | 只有少数人提到，没有行为证据 |
| 1 | 只有观点和想象 |
| 分数 | 标准 |
|---|---|
| 5 | 影响留存/续费/安全/合规，不解决会持续失血 |
| 4 | 影响关键指标（转化/激活/协作效率） |
| 3 | 影响用户体验但不直接影响核心指标 |
| 2 | 体验优化类，有帮助但不关键 |
| 1 | 锦上添花 |
| 分数 | 标准 |
|---|---|
| 5 | 每天发生，影响大部分用户 |
| 4 | 每周发生，影响核心用户群 |
| 3 | 每月发生，影响特定场景用户 |
| 2 | 偶发但后果严重 |
| 1 | 极少发生且后果可控 |
| 分数 | 标准 |
|---|---|
| 5 | 卡在收入/续费/试点转正式的关键节点 |
| 4 | 四周不动会导致后续动作建立在错误前提上 |
| 3 | 影响当前季度目标 |
| 2 | 可以排入下个季度 |
| 1 | 不紧急 |
| 分数 | 标准 |
|---|---|
| 5 | 直接影响核心指标，投入产出比极高 |
| 4 | 影响关键指标，解法可行 |
| 3 | 有价值但解法较重 |
| 2 | 价值有限或解法太重 |
| 1 | 不值得当前投入 |
总分参考：20-25 分优先处理，15-19 分排入待办，10-14 分暂缓，10 分以下放弃。
AI 时代优先级误判比过去更常见，因为 AI 放大了"做出来"的能力，却放大了"做错方向"的风险。
"我们都做出原型了，说明这个问题值得做。"→ 错。方案完成度不等于问题成立性。AI 让方案更快出来，但也更容易让人误以为方案存在就意味着问题存在。
"这个演示效果很好，用户一定会喜欢。"→ 不一定。演示场景是理想输入、单一路径、人工兜底。真实使用是混乱输入、多种路径、无人兜底。
"AI 是大趋势，我们必须跟上。"→ 趋势不等于你的优先级。行业趋势是背景，你的具体问题是前景。
"大客户一直在要这个功能。"→ 声音大不等于优先级高。大客户的声音可能只是个别场景，而沉默的大多数可能有更系统性的问题。
"这个功能容易演示，对销售有帮助。"→ 容易演示不等于值得先做。对销售有帮助的功能，可能对用户留存没有帮助。
问题描述: ____
事件层（表面现象）:
谁说了什么: ____
什么时候: ____
什么场景: ____
趋势层（是否持续）:
持续时间: ____
频率: ____
影响范围: ____
结构层（深层原因）:
流程问题: ____
机制问题: ____
协同问题: ____
心智层（默认行为）:
用户的默认做法: ____
组织的惯性: ____
习以为常的假设: ____
真正需要解决的问题在: [ ] 事件层 [ ] 趋势层 [ ] 结构层 [ ] 心智层
当多个问题都通过五问过滤后，用以下方法排序：
| 紧迫 | 不紧迫 | |
|---|---|---|
| 影响面大 | 最优先 | 排入规划 |
| 影响面小 | 快速处理 | 暂缓 |
对每个问题估算：
优先做杠杆比最高的。
有些问题解决后会降低其他问题的优先级，或者让其他问题的解决变得更容易。优先解决"解锁型"问题。