Imported from gabrielmoreira/agent-skills-mirror (mirrors/repos/gmaxxxie@ai-native-product-agent-skills/skills/p12a-contemplation-right-view/SKILL.md). Install upstream with npx skills add gabrielmoreira/agent-skills-mirror --skill p12a-contemplation-right-view. Copyright stays with the author.

正见 Skill（Right View）

适用场景

• 被表面现象迷惑，找不到真正的问题
• 争论不休但问题定义模糊
• 解决方案无效，因为问题理解错了

输入

输出

• 三层分析报告（现象层→情境层→关系层）
• 问题陈述（修正版本）
• 潜在的根本原因假设

工作流程

1. 现象层整理：客观描述"发生了什么"，不带解释和归因
2. 情境层还原：该现象发生在什么约束条件下？谁在什么位置？资源/时间/权限如何？
3. 关系层分析：现象与哪些系统要素有关？信息流、决策权、激励机制如何影响？
4. 问题重述：基于三层分析，重新定义核心问题

注意事项

• 现象层不等于"事实"——所有观察都已视角过滤
• 情境层常被忽略，但它决定了"可行解空间"
• 关系层揭示结构性原因，是改变杠杆点所在

核心概念

1. 三层问题分析（Three-Layer Problem Analysis）

• 定义：从现象层到场景层（情境层）再到关系层，逐层深入看清问题的分析方法
• 关键点：
  • 现象层：用户说了什么、数据发生了什么、流程卡在哪里——不带解释和归因
  • 场景层：这个现象发生在什么工作关系里，用户正在承担什么成本（迁移成本、学习成本、信任成本、协作成本）
  • 关系层：背后真正变化的是什么——工具与用户的关系、人与 AI 的分工、组织对某个结果的理解方式
  • 停在现象层最容易，也最容易看错问题

2. 问题定义偏差（Problem Definition Bias）

• 定义：团队基于自己的角色位置和指标语言，把同一现象命名成不同问题的倾向
• 关键点：
  • 同一句用户反馈，产品经理听成需求问题，技术负责人听成可靠性问题，增长负责人听成路径问题
  • "看错问题"比"没有答案"更危险——看错后团队会很投入、很专业、很有效率地往前做，但整体问题没有被碰到
  • 组织在时间压力下天然朝熟悉的问题定义收敛

3. 场景成本替代功能命名

• 定义：不急着问"缺什么功能"，先问"用户在这个场景里到底承担了什么成本"
• 关键点：
  • 成本类型：迁移成本、学习成本、信任成本、协作成本、认知负担
  • 很多问题一旦换成成本来理解，团队就不会那么容易被功能表层牵着走
  • 同一个表面需求，底下可能藏着完全不同的真实任务

4. 过早收敛（Premature Convergence）

• 定义：在还没充分理解问题前，就快速选定一个问题定义并投入行动
• 关键点：
  • 评审流程惩罚模糊——承认"问题还不清楚"比给出"一个可以讨论的答案"更容易被挑战
  • KPI 语言锁定了解释框架——每个角色都习惯用自己的指标命名问题
  • 历史归因习惯触发防御性归因——承认自己看到的是局部，等于承认过去的判断可能有问题

5. 盲人摸象效应（Blind Men and the Elephant Effect）

• 定义：每个人只摸到大象的一部分，却把局部经验宣布成整体真相
• 关键点：
  • 每个人摸到的都是真实的，可没有一个人摸到的是整体
  • 争论让每个人都更相信自己那部分局部经验
  • AI 时代效应放大：信号更多，解释更多，但信息多不等于更接近问题

深入核心概念

1. 问题定义偏差与位置遮蔽

"同一句用户反馈，产品经理容易听成需求问题，技术负责人容易听成可靠性问题，增长负责人容易听成路径问题，运营负责人容易听成教育问题。每个人听到的都不是假的，可每个人听到的都带着自己的位置。"

书稿在第三章深入分析了"问题定义偏差"的根源：问题不是天然摆在那里等人去发现，很多时候问题是被命名出来的。你站在哪个位置，负责什么结果，平时被什么指标追着跑，你就更容易把眼前的现象命名成某一种熟悉的问题。组织在时间压力下天然朝熟悉的问题定义收敛——评审流程惩罚模糊，KPI 语言锁定了解释框架，历史归因习惯触发防御性归因。这三种力量让人不是看不见场景层和关系层，而是不敢、也不被允许在那里停留。

在产品分析中，这意味着"看错问题"比"没有答案"更危险。没有答案，团队至少还会继续探索；看错了问题，团队反而会很投入、很专业、很有效率地往前做，但整体问题没有被碰到。正见要求在命名问题之前，先给不确定留一点位置——不急着把现象解释成问题，本身就是一种判断力。

2. 场景成本替代功能命名

"不要急着问'缺什么功能'，先问'用户在这个场景里到底承担了什么成本'。是迁移成本、学习成本、信任成本，还是协作成本？很多问题一旦换成成本来理解，团队就不会那么容易被功能表层牵着走。"

书稿提出用"场景成本"替代"功能命名"来理解问题。同一个表面需求，底下可能藏着完全不同的真实任务。Scout24 案例中，用户找房子时频繁调整条件、反复搜索——如果叫"搜索问题"，团队会继续优化召回和排序；如果叫"决策引导问题"，产品就会往帮助用户澄清条件、理解取舍的方向走。两种定义看起来只差一点，后面的动作却完全不同。

在产品实践中，当面对"用户在某一步停留很久"的现象时，不要急着下结论说"流程需要优化"。先问：用户在这个场景里承担了什么成本？是迁移成本（已有工具链）、信任成本（不敢把关键流程交给不完全可控的系统）、还是认知负担（选择太多不知道怎么收窄）？很多问题一旦换成成本来理解，就不会被功能表层牵着走，而是能触及更深层的关系变化。

3. 盲人摸象效应与信息过载

"每个人一旦把自己摸到的那一部分当成全部，就会开始争。摸到腿的人觉得别人荒唐，摸到尾巴的人也确信自己有证据。争到最后，大家离真相不是更近，而是更远。"

书稿用盲人摸象的佛经故事映射产品团队的现实：产品摸到需求和抱怨，技术摸到实现和稳定，增长摸到路径和转化，运营摸到激活和使用习惯。每个人都握着一部分真相，也都容易在时间压力里把这部分真相直接升级成"真正的问题"。AI 时代会把这种偏差放大——信号更多，解释也更多，但信息越多并不自动等于更接近问题，它只是让我们有更多材料更快地为自己原本就偏好的问题定义找证据。

在团队协作中，正见要求不要直接争谁的解释是对的，而要先提高问题定义的质量。可以固定一个动作：让产品、技术、增长、运营分别写下他们认为的问题，再要求每个人替别的角色复述一次。这个动作会暴露：团队不是没有信息，而是太习惯只从自己的入口看信息。先把各自那部分真实放到桌上，再一起看，别急着把局部宣布成整体。

分步执行

第 1 步：现象层整理

1. 客观描述"发生了什么"，不带解释和归因
2. 先收原话，再收解释——原话是"产品很强，但没进日常流程"，不是"用户教育不够"
3. 数据是"某个环节流失严重"，不是"入口设计有问题"
4. 将原始事实和解释严格拆开

第 2 步：情境层（场景层）还原

1. 该现象发生在什么约束条件下？
2. 用户正在承担什么成本？迁移成本？学习成本？信任成本？协作成本？
3. 谁在什么位置？资源、时间、权限如何？
4. 用"场景成本"替代"功能命名"来理解问题

第 3 步：关系层分析

1. 现象与哪些系统要素有关？
2. 信息流、决策权、激励机制如何影响？
3. 背后真正变化的是什么：工具与用户的关系？人与 AI 的分工？组织对结果的理解方式？
4. 揭示结构性原因和改变杠杆点

第 4 步：多角色视角校验

1. 让产品、技术、增长、运营分别写下他们认为的问题
2. 要求每个人替别的角色复述一次
3. 暴露：我们不是没有信息，而是太习惯只从自己的入口看信息

第 5 步：问题重述

1. 基于三层分析，重新定义核心问题
2. 同一个现象至少保留三种解释，不急着收敛
3. 不急着把现象解释成问题，本身就是一种判断力

示例 1：Scout24 搜索问题的重新定义

场景描述

Scout24（德国找房平台）面对一个表面上很熟悉的问题：用户找房子时希望搜索结果更准、更快、更相关。但团队后来意识到，用户真正缺的未必是更像搜索框的东西，而是需要一个会澄清、会引导、会帮用户逐步收敛选择的助手。

用户输入

observed_phenomenon: "用户在找房过程中频繁调整条件、反复搜索、选择疲劳，很多搜索最终没有转化为看房预约"
stakeholder_claims:
  - 产品经理："搜索结果相关性不够"
  - 技术："召回率和排序算法需要优化"
  - 增长："结果页转化率太低"
attempted_solutions: "优化了搜索算法、改进了过滤器、重做了结果页"

执行流程

1. 现象层整理：
   • 原话："搜了很多，但定不下来"
   • 数据：搜索量高，看房预约转化率低
   • 行为：用户频繁修改条件、反复搜索、最终放弃
2. 情境层还原：
   • 用户在找房场景中面临多重因素冲突：预算、通勤、学区、空间、生活便利性
   • 用户承担的是决策成本——不是搜不到，而是不知道该怎样继续收窄选择
   • 很多卡住的时刻是"不知道自己真正要什么"，而非"搜索不够好"
3. 关系层分析：
   • 背后真正变化的不是"搜索质量"，而是"平台与用户的决策关系"
   • 用户需要的不是 results，而是 guidance——平台应从"给结果"转向"帮决策"
4. 问题重述：问题不是"搜索还不够好"，而是"用户需要决策引导，不只是搜索结果"

输出结果

=== 三层分析报告 ===

【现象层】
- 用户频繁修改搜索条件，搜索量高但看房预约转化率低
- 用户反馈"搜了很多，但定不下来"

【场景层】
- 找房是高决策成本场景：预算、通勤、学区、空间、便利性多重因素冲突
- 用户卡住不是因为"搜不到"，而是"不知道怎样继续收窄选择"
- 工具给的是 results，用户需要的是 guidance

【关系层】
- 平台与用户的关系需要从"信息检索"升级为"决策辅助"
- 问题定义变化："搜索问题"→"决策引导问题"

【问题陈述（修正版）】
用户需要一个会澄清、会引导、会帮助逐步收敛选择的助手，而不是一个更精准的搜索框。

示例 2：团队内部对"产品很强但没进日常流程"的分歧

场景描述

某 AI 产品内部测试反馈很好，但正式上线后用户使用率一直起不来。产品说是"用户教育不够"，技术说是"稳定性不足"，增长说是"激活路径太长"，运营说是"用户没感受到价值"。

用户输入

observed_phenomenon: "产品内部试用评价很高，正式上线后日活跃使用率仅 12%"
stakeholder_claims:
  - 产品经理："用户教育不到位，需要更好的引导教程"
  - 技术负责人："系统偶有延迟，稳定性还需提升"
  - 增长负责人："新用户激活路径太长，中间流失太多"
  - 运营负责人："用户在试用期没有建立起使用习惯"
attempted_solutions: "做了新手教程、优化了性能、缩短了激活路径、增加了使用提醒"

执行流程

1. 现象层整理：
   • 原话："产品很强，但没进日常流程"
   • 数据：试用满意度高（4.5/5），日活跃使用率低（12%）
   • 行为：用户试用时积极，正式使用后逐渐沉默
2. 情境层还原：
   • 用户在日常工作流中已有稳定工具链，新产品需要迁移成本和信任成本
   • 用户没有足够理由把一个"还不够可控的系统"放进自己的稳定流程
   • 卡住的不是某个局部体验，而是"值不值得把它纳入日常"的整体判断
3. 关系层分析：
   • 背后真正变化的是"产品与用户日常工作流的信任关系"
   • 问题不是"怎么把功能讲清楚"，而是"怎么让产品值得被纳入日常工作"
   • AI 产品天然面临"可控性焦虑"——用户不敢把关键流程交给一个不完全可控的系统
4. 问题重述：问题不是教育/性能/激活路径中的任何一个，而是"产品还没有建立足够的信任基础来进入用户日常工作流"

输出结果

=== 三层分析报告 ===

【现象层】
- 试用满意度高（4.5/5），日活跃使用率仅 12%
- 用户试用时积极，正式使用后逐渐沉默
- 原话："产品很强，但没进日常流程"

【场景层】
- 用户已有稳定工具链，新产品面临迁移成本和信任成本
- 用户对 AI 系统存在"可控性焦虑"——不确定它能否在关键场景中稳定工作
- 不是某个局部体验有问题，而是"值不值得纳入日常"的整体信任未建立

【关系层】
- 问题本质：产品与用户日常工作流之间的信任关系未建立
- 四个角色各自摸到了一部分真相，但没有人从"信任关系"这个整体视角看

【问题陈述（修正版）】
产品的核心挑战不是教育、性能或激活路径中的任何一个，而是如何建立足够的信任基础，让用户愿意把它纳入日常工作流。需要解决的是"可控性"和"可靠性信任"问题，而非功能演示问题。

常见问题定义陷阱

陷阱 1：功能化陷阱

• 把问题翻译成功能缺失："缺 XX 功能"
• 更好的做法：先问"用户在这个场景里承担了什么成本"
• 很多问题一旦换成成本来理解，就不会被功能表层牵着走

陷阱 2：归因外部化陷阱

• 把问题归因于外部因素："市场不成熟""用户素质不够""竞品太强"
• 这些说法把产品/策略/执行问题改写成了环境问题
• 更好的做法：先问"我们自己的假设哪些需要被检验"

陷阱 3：KPI 锁定陷阱

• 用自己最熟悉的指标命名问题：增长说"获客质量"，产品说"功能体验"，技术说"系统稳定性"
• 每个指标都只照到问题的一个面
• 更好的做法：同一现象至少保留三种解释，不急着收敛

陷阱 4：过早收敛陷阱

• 评审流程惩罚模糊——承认"问题还不清楚"比给出"一个可以讨论的答案"更容易被挑战
• 但拍板太早往往不是更清醒，而是更想结束不确定
• 更好的做法：不急着把现象解释成问题，给不确定留一点位置

三层分析深度指南

与视角修正 Skill 的区别