Menu
系统性思维——结构化分析、关系映射、反馈回路识别
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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 是大趋势，我们必须跟上。"→ 趋势不等于你的优先级。行业趋势是背景，你的具体问题是前景。
"大客户一直在要这个功能。"→ 声音大不等于优先级高。大客户的声音可能只是个别场景，而沉默的大多数可能有更系统性的问题。
"这个功能容易演示，对销售有帮助。"→ 容易演示不等于值得先做。对销售有帮助的功能，可能对用户留存没有帮助。
问题描述: ____
事件层（表面现象）:
谁说了什么: ____
什么时候: ____
什么场景: ____
趋势层（是否持续）:
持续时间: ____
频率: ____
影响范围: ____
结构层（深层原因）:
流程问题: ____
机制问题: ____
协同问题: ____
心智层（默认行为）:
用户的默认做法: ____
组织的惯性: ____
习以为常的假设: ____
真正需要解决的问题在: [ ] 事件层 [ ] 趋势层 [ ] 结构层 [ ] 心智层
当多个问题都通过五问过滤后，用以下方法排序：
| 紧迫 | 不紧迫 | |
|---|---|---|
| 影响面大 | 最优先 | 排入规划 |
| 影响面小 | 快速处理 | 暂缓 |
对每个问题估算：
优先做杠杆比最高的。
有些问题解决后会降低其他问题的优先级，或者让其他问题的解决变得更容易。优先解决"解锁型"问题。