Menü
把问题看准，而不是把现象说圆——三层看问题法（现象层/情境层/关系层）
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p12a-contemplation-right-view |
| description | 把问题看准，而不是把现象说圆——三层看问题法（现象层/情境层/关系层） |
| stage | discovery |
| tags | ["正见","三层分析","问题定义","关系层洞察"] |
| source_book | 观照 |
| source_chapter | 第3章 正见 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| observed_phenomenon | 观察到的现象/表象 |
| stakeholder_claims | 各利益相关方的说法 |
| attempted_solutions | 已经尝试过的解决方案 |
"同一句用户反馈，产品经理容易听成需求问题，技术负责人容易听成可靠性问题，增长负责人容易听成路径问题，运营负责人容易听成教育问题。每个人听到的都不是假的，可每个人听到的都带着自己的位置。"
书稿在第三章深入分析了"问题定义偏差"的根源：问题不是天然摆在那里等人去发现，很多时候问题是被命名出来的。你站在哪个位置，负责什么结果，平时被什么指标追着跑，你就更容易把眼前的现象命名成某一种熟悉的问题。组织在时间压力下天然朝熟悉的问题定义收敛——评审流程惩罚模糊，KPI 语言锁定了解释框架，历史归因习惯触发防御性归因。这三种力量让人不是看不见场景层和关系层，而是不敢、也不被允许在那里停留。
在产品分析中，这意味着"看错问题"比"没有答案"更危险。没有答案，团队至少还会继续探索；看错了问题，团队反而会很投入、很专业、很有效率地往前做，但整体问题没有被碰到。正见要求在命名问题之前，先给不确定留一点位置——不急着把现象解释成问题，本身就是一种判断力。
"不要急着问'缺什么功能'，先问'用户在这个场景里到底承担了什么成本'。是迁移成本、学习成本、信任成本，还是协作成本？很多问题一旦换成成本来理解，团队就不会那么容易被功能表层牵着走。"
书稿提出用"场景成本"替代"功能命名"来理解问题。同一个表面需求，底下可能藏着完全不同的真实任务。Scout24 案例中，用户找房子时频繁调整条件、反复搜索——如果叫"搜索问题"，团队会继续优化召回和排序；如果叫"决策引导问题"，产品就会往帮助用户澄清条件、理解取舍的方向走。两种定义看起来只差一点，后面的动作却完全不同。
在产品实践中，当面对"用户在某一步停留很久"的现象时，不要急着下结论说"流程需要优化"。先问：用户在这个场景里承担了什么成本？是迁移成本（已有工具链）、信任成本（不敢把关键流程交给不完全可控的系统）、还是认知负担（选择太多不知道怎么收窄）？很多问题一旦换成成本来理解，就不会被功能表层牵着走，而是能触及更深层的关系变化。
"每个人一旦把自己摸到的那一部分当成全部，就会开始争。摸到腿的人觉得别人荒唐，摸到尾巴的人也确信自己有证据。争到最后，大家离真相不是更近，而是更远。"
书稿用盲人摸象的佛经故事映射产品团队的现实：产品摸到需求和抱怨，技术摸到实现和稳定，增长摸到路径和转化，运营摸到激活和使用习惯。每个人都握着一部分真相，也都容易在时间压力里把这部分真相直接升级成"真正的问题"。AI 时代会把这种偏差放大——信号更多，解释也更多，但信息越多并不自动等于更接近问题，它只是让我们有更多材料更快地为自己原本就偏好的问题定义找证据。
在团队协作中，正见要求不要直接争谁的解释是对的，而要先提高问题定义的质量。可以固定一个动作：让产品、技术、增长、运营分别写下他们认为的问题，再要求每个人替别的角色复述一次。这个动作会暴露：团队不是没有信息，而是太习惯只从自己的入口看信息。先把各自那部分真实放到桌上，再一起看，别急着把局部宣布成整体。
Scout24（德国找房平台）面对一个表面上很熟悉的问题：用户找房子时希望搜索结果更准、更快、更相关。但团队后来意识到，用户真正缺的未必是更像搜索框的东西，而是需要一个会澄清、会引导、会帮用户逐步收敛选择的助手。
observed_phenomenon: "用户在找房过程中频繁调整条件、反复搜索、选择疲劳，很多搜索最终没有转化为看房预约"
stakeholder_claims:
- 产品经理："搜索结果相关性不够"
- 技术："召回率和排序算法需要优化"
- 增长："结果页转化率太低"
attempted_solutions: "优化了搜索算法、改进了过滤器、重做了结果页"
=== 三层分析报告 ===
【现象层】
- 用户频繁修改搜索条件，搜索量高但看房预约转化率低
- 用户反馈"搜了很多，但定不下来"
【场景层】
- 找房是高决策成本场景：预算、通勤、学区、空间、便利性多重因素冲突
- 用户卡住不是因为"搜不到"，而是"不知道怎样继续收窄选择"
- 工具给的是 results，用户需要的是 guidance
【关系层】
- 平台与用户的关系需要从"信息检索"升级为"决策辅助"
- 问题定义变化："搜索问题"→"决策引导问题"
【问题陈述（修正版）】
用户需要一个会澄清、会引导、会帮助逐步收敛选择的助手，而不是一个更精准的搜索框。
某 AI 产品内部测试反馈很好，但正式上线后用户使用率一直起不来。产品说是"用户教育不够"，技术说是"稳定性不足"，增长说是"激活路径太长"，运营说是"用户没感受到价值"。
observed_phenomenon: "产品内部试用评价很高，正式上线后日活跃使用率仅 12%"
stakeholder_claims:
- 产品经理："用户教育不到位，需要更好的引导教程"
- 技术负责人："系统偶有延迟，稳定性还需提升"
- 增长负责人："新用户激活路径太长，中间流失太多"
- 运营负责人："用户在试用期没有建立起使用习惯"
attempted_solutions: "做了新手教程、优化了性能、缩短了激活路径、增加了使用提醒"
=== 三层分析报告 ===
【现象层】
- 试用满意度高（4.5/5），日活跃使用率仅 12%
- 用户试用时积极，正式使用后逐渐沉默
- 原话："产品很强，但没进日常流程"
【场景层】
- 用户已有稳定工具链，新产品面临迁移成本和信任成本
- 用户对 AI 系统存在"可控性焦虑"——不确定它能否在关键场景中稳定工作
- 不是某个局部体验有问题，而是"值不值得纳入日常"的整体信任未建立
【关系层】
- 问题本质：产品与用户日常工作流之间的信任关系未建立
- 四个角色各自摸到了一部分真相，但没有人从"信任关系"这个整体视角看
【问题陈述（修正版）】
产品的核心挑战不是教育、性能或激活路径中的任何一个，而是如何建立足够的信任基础，让用户愿意把它纳入日常工作流。需要解决的是"可控性"和"可靠性信任"问题，而非功能演示问题。
| 层级 | 问什么 | 典型答案示例 | 常见陷阱 |
|---|---|---|---|
| 现象层 | 发生了什么？（不带解释） | "用户搜索量高但转化率低" | 把解释混入现象描述 |
| 场景层 | 什么约束下？用户承担什么成本？ | "找房是高决策成本场景，多重因素冲突" | 跳过场景层直接到方案 |
| 关系层 | 背后变化的是什么关系？ | "平台应从'给结果'转向'帮决策'" | 停在现象层不继续往下看 |
| 维度 | 正见 | 视角修正 |
|---|---|---|
| 关注点 | 问题是否被正确看见 | 看法是否需要多角度审视 |
| 触发时机 | "问题定义模糊/争论不休" | "团队对同一事实有截然不同的解读" |
| 输出 | 三层分析 + 修正后的问题陈述 | 证据评估 + 八种修正视角应用 |
| 核心动作 | 从现象层深入到关系层 | 从默认检查到多视角修正 |
| 两者关系 | 正见解决"看到了什么" | 视角修正解决"从多少个角度看" |