p12a-contemplation-view-correction

---
name: p12a-contemplation-view-correction
description: 先修正看法，再调用方法——默认检查、证据校验、后果追问、八种修正视角
stage: discovery
tags:
  - 正思维
  - 视角修正
  - 证据校验
  - 默认检查
source_book: 观照
source_chapter: 第2章 从产品方法到产品观照
version: 1.0.0
---

# 视角修正 Skill（View Correction）

## 适用场景
- 团队对同一事实有截然不同的解读
- 决策基于未经检验的默认假设
- 需要从多个视角审视同一个问题

## 输入
| 字段 | 说明 |
|------|------|
| initial_view | 当前/主流的看法 |
| supporting_evidence | 支持该看法的证据 |
| underlying_assumptions | 隐含的默认假设 |

## 输出
- 证据可信度评估
- 假设检验结果
- 修正后的多视角描述
- 八种修正视角的应用记录

## 工作流程
1. **默认检查**：识别观点中的隐含前提（如"用户是理性的""增长是好的"）
2. **证据校验**：区分事实/观点/推测，检验证据链的完整性
3. **后果追问**：如果这个看法成立，会导致什么行动？会产生什么结果？
4. **八种修正**：应用八种修正视角（反面看、整体看、动态看、关系看、代价看、边界看、历史看、他人看）

## 注意事项
- 此 Skill 在调用任何具体方法之前执行
- "修正看法"不是"和稀泥"，而是让判断建立在更坚实的基础上
- 八种修正视角是启发式工具，不是必须全部使用

## 核心概念

### 1. 默认检查（Default Assumption Check）
- **定义**：识别观点中未经检验的隐含前提和默认假设
- **关键点**：
  - 如"用户是理性的""增长是好的""AI 输出是可信的""行业共识是对的"
  - 默认一旦没被看见，后面的所有认真都可能只是在让那些默认变得更顽固
  - 方法不是没用，问题是连眼前的工作本身都还没有被重新看清
  - 对所有"太顺的答案"保留一点迟疑——迟疑不是拖延，是留给自己重新看见的机会

### 2. 证据校验（Evidence Verification）
- **定义**：区分事实、观点和推测，检验证据链的完整性
- **关键点**：
  - 三层分开：观察（用户在某一步停留很久）、解释（我们推测他是因为流程复杂）、判断（因此应优先优化流程）
  - 不能把解释直接当事实
  - 很多组织里的误判，不是没人看到事实，而是事实一进入集体表达就被熟练地重新命名了

### 3. 后果追问（Consequence Inquiry）
- **定义**：追问一个看法成立后会导致什么行动和结果
- **关键点**：
  - 一个说法之所以危险，往往不是因为它完全错误，而是因为它听起来太合理
  - 如"先把自动化能力全接上，效率会更高"——会不会让一线团队更少追问用户？会不会把判断责任偷偷转移给系统？
  - 问后果，能帮团队摆脱只在表面逻辑里打转

### 4. 八种修正视角（Eight Correction Perspectives）
- **定义**：从八个维度系统性地审视同一个问题/观点
- **关键点**：
  - **反面看**：如果相反的判断成立呢？
  - **整体看**：这个局部放在更大系统里意味着什么？
  - **动态看**：现在成立，三个月后呢？
  - **关系看**：这个判断对谁有利、对谁有代价？
  - **代价看**：接受这个判断，我们要放弃什么？
  - **边界看**：在什么条件下它不成立？
  - **历史看**：类似情境下发生过什么？
  - **他人看**：持不同立场的人会怎么看？

### 5. 迦罗摩经原则（Kalamas Sutra Principle）
- **定义**：对所有看起来太顺、太熟、太像答案的东西，都值得在落地之前再看一眼
- **关键点**：
  - 不要因为一件事出自传统、很多人都在说、写在经典里、AI 说得很有逻辑，就太快相信
  - 要看这个判断放到现实里会导向什么，会不会带来更清楚的理解
  - 把"判断"从服从和反服从里都拉出来——不是逢权威必反，也不是逢新观点就兴奋

## 深入核心概念

### 1. 从方法到观照的转换

> "方法不是没用。问题是，如果连眼前这份工作本身都还没有被重新看清，方法只会帮组织更熟练地在旧地图上跑。"

书稿在第二章以 Microsoft "试点地狱"案例说明：很多组织的 AI 转型开头都差不多——团队做出亮眼 demo，领导点头，项目被贴上"创新、效率、智能化"等标签。但半年后，真正的业务流程没怎么改，核心指标没怎么动，试点始终留在试点。真正该被重看的不是某个功能入口，而是更前面的那层：我们到底以为工作是怎样发生的？LinkedIn 拉开差距的不是多加了一个 AI 功能，而是开始重做产品开发方式。

在产品决策中，视角修正要求在调用任何具体方法之前先执行。不是做一次就够了——重大判断变化时需要重新修正。形成"先检查默认假设，再调用方法"的习惯比偶尔做一次更重要。当团队说"方向正确"时，视角修正会追问：这个"正确"是基于精心控制的 demo 环境，还是基于真实业务流程中的摩擦？

### 2. AI 总结与转述幻觉

> "AI 几秒钟就能生成结构完整、逻辑顺滑的'总结'和'建议'。它们看起来特别像共识，特别适合直接贴进汇报材料里。可越是顺滑，越可能把那些真正关键、但还很粗糙、还没被说顺的信号提前磨平。"

书稿警告"转述幻觉"的危险：AI 总结或他人转述被误当成事实本身。访谈原话、AI 总结、人的判断必须三条线并行。不能把解释直接当事实——很多组织里的误判，不是没人看到事实，而是事实一进入集体表达就被熟练地重新命名了。流畅不等于真实，完整不等于贴近处境，像样不等于值得采纳。

在产品研究中，当把 30 份用户访谈丢给 AI 得到"核心诉求是效率"的总结时，不应直接据此制定路线图。原始访谈中可能有"信任焦虑""失控焦虑""使用负担"等信号被 AI 的"总结能力"提前磨平了。正确做法是建立三条线并行：访谈原话 / AI 总结 / 人的独立判断，回到原始材料验证 AI 提取的是否只是用户最容易说出口的部分。

### 3. 迦罗摩经原则与太顺的答案

> "所有听起来很顺、很熟、很像答案的东西，都值得在落地之前再看一眼。它逼着团队从'这个说法有没有道理'，再往前走一步，去问：这个说法现在为什么会让我这么容易点头？"

书稿引用迦罗摩经的故事，将"判断"从服从和反服从里都拉出来。很多团队最容易轻信的不只是"权威"，还包括行业共识、成熟模板和 AI 自己给出的答案。行业共识可能是集体盲区——大家都说"AI 产品要先做 agent"，于是团队一边点头一边开始规划，却没有先问：我们的用户真实处境里，自动代理到底解决了什么痛点？

在产品规划中，对所有"太顺的答案"保留一点迟疑——迟疑不是拖延，是留给自己重新看见的机会。当竞品都在做某功能时，视角修正要求追问：这个说法靠的是现实，还是靠熟悉感、权威感、行业惯性和表达顺滑感？如果竞品不做这个功能，我们还会做吗？把"判断"从行业惯性里拉出来，才能避免团队在跟随中迷失自己的判断力。

## 分步执行

### 第 1 步：默认检查
1. 识别当前观点/方案中的隐含前提
2. 列出所有未被言明的默认假设
3. 追问：这个默认在今天还成立吗？
4. 特别检查：行业共识、成熟模板、AI 输出是否被当成了天然正确的默认

### 第 2 步：证据校验
1. 将团队的陈述拆分为三层：观察 → 解释 → 判断
2. 检查：哪些是原始事实，哪些是解读，哪些是推测
3. 证据链是否完整？有没有反证？
4. AI 转述和原始材料是否分开了？

### 第 3 步：后果追问
1. 如果这个看法成立，会导致什么行动？
2. 这个行动会产生什么短期结果和长期结果？
3. 会不会有隐性代价？（如：让团队更少追问用户、把判断责任转移给系统）
4. 如果这个看法错了，最可能错在哪？

### 第 4 步：八种修正视角应用
1. 选择最相关的 2-4 种修正视角（不必全部使用）
2. 反面看：相反判断如果成立，意味着什么？
3. 动态看：现在成立，三个月后还成立吗？
4. 关系看：对谁有利？对谁有代价？
5. 边界看：在什么条件下它不成立？
6. 记录每个视角带来的新发现

### 第 5 步：综合修正
1. 基于以上分析，给出修正后的多视角描述
2. 标注哪些默认假设已被挑战、哪些证据需要补充
3. 为"反例"和"迟疑"留正式位置

## 示例 1：Microsoft "试点地狱"的视角修正

### 场景描述
很多组织的 AI 转型看起来开头都差不多：团队做出亮眼 demo，领导点头，项目被贴上"创新、效率、智能化"等标签。但半年后，真正的业务流程没怎么改，核心指标没怎么动，试点始终留在试点。Microsoft WorkLab 称之为"试点地狱"（pilot purgatory）。

### 用户输入
```
initial_view: "我们的 AI 转型进展顺利，demo 反馈好，领导认可，方向正确"
supporting_evidence: "内部试用满意度高、汇报获好评、技术可行性已验证"
underlying_assumptions:
  - "demo 成功意味着产品成功"
  - "领导认可等于方向正确"
  - "AI 可以直接贴到旧流程上"
```

### 执行流程
1. **默认检查**：
   - 隐含默认1："demo 成功 = 真实场景成功" → ⚠️ 未验证。demo 是精心控制的环境，真实场景有治理、权限、监控、回退问题
   - 隐含默认2："工具接进去 = 工作被改变" → ❌ 可能不成立。工作本身还是一团雾，AI 只是贴在表面上
   - 隐含默认3："行业说 AI 重要 = 我们现在就该全面推" → ⚠️ 需要情境化
2. **证据校验**：
   - 观察：demo 反馈好、领导认可
   - 解释：方向正确、转型顺利
   - 判断：应该继续推进
   - 问题：观察只覆盖了"精心控制环境"，未覆盖真实业务流程中的摩擦
3. **后果追问**：
   - 如果"方向正确"成立 → 继续在旧流程上贴 AI → 可能永远停在试点
   - 会不会让组织更少追问"工作本身到底怎么发生的"？
4. **八种修正**：
   - 反面看：如果 demo 成功恰恰掩盖了真实问题呢？
   - 动态看：半年后试点还在试点，说明什么？
   - 边界看：在什么条件下 demo 成功不等于产品成功？

### 输出结果
```
=== 视角修正报告 ===

【默认假设检验】
1. "demo 成功 = 真实场景成功" → 未通过。demo 缺少治理、权限、监控、回退等真实约束
2. "工具接进去 = 工作被改变" → 未通过。根本没看清工作是怎么发生的
3. "领导认可 = 方向正确" → 部分通过。认可的是方向感，不是执行路径

【证据可信度】
- 观察（demo 反馈好）可信，但仅限精心控制环境
- 缺少：真实业务流程中的摩擦数据、用户在日常工作中的实际使用行为

【修正后描述】
AI 转型的 demo 阶段确实验证了技术可行性，但"试点地狱"说明组织跳过了最关键的一步：重新看清工作到底是怎么发生的。真正该被重看的不是某个功能入口，而是更前面的那层——我们到底以为工作是怎样发生的。

【八种修正视角关键发现】
- 反面看：demo 成功可能让组织更不愿面对"工作本身还没被重看"的事实
- 动态看：半年停留在试点说明扩散阶段的问题与 demo 阶段完全不同
- 代价看：继续在旧流程上贴 AI 的代价是永远走不出试点
```

## 示例 2：AI 总结被当成事实的修正

### 场景描述
一个产品团队把用户访谈丢给 AI，AI 生成了一份结构完整、逻辑顺滑的"核心诉求总结"。团队直接把这份总结贴进产品路线图。但原始访谈中那些更含混、更矛盾、更真实的信号，被 AI 的"总结能力"提前磨平了。

### 用户输入
```
initial_view: "AI 总结得很清楚，核心诉求是效率，我们应该优先做效率相关功能"
supporting_evidence: "AI 从 30 份访谈中总结出'效率'是最高频关键词"
underlying_assumptions:
  - "AI 总结 = 事实"
  - "高频关键词 = 核心诉求"
  - "总结比原始材料更可信"
```

### 执行流程
1. **默认检查**：
   - 隐含默认1："AI 总结代表原始材料" → ❌ 不成立。AI 总结是压缩和重述，不是原始事实
   - 隐含默认2："高频出现 = 核心诉求" → ⚠️ 需验证。高频可能是话术惯性，不是真实痛点
   - 隐含默认3："结构完整 = 分析到位" → ❌ 流畅不等于真实，完整不等于贴近处境
2. **证据校验**：
   - 观察：AI 从访谈中提取出"效率"为高频词
   - 解释：用户核心诉求是效率
   - 判断：应优先做效率功能
   - 问题：原始访谈中可能有"信任焦虑""失控焦虑""使用负担"等信号被压缩掉了
3. **后果追问**：
   - 如果只看"效率"→ 忽略信任、可控性、认知负担 → 做出来的功能可能"快"但"不好用"
   - AI 总结是否让团队更少回到原始材料去自己判断？
4. **八种修正**：
   - 反面看：如果"效率"只是用户最容易说出口的词，而真正的问题是更难表达的"不信任"呢？
   - 他人看：用户本人会认同"我的核心诉求是效率"吗？

### 输出结果
```
=== 视角修正报告 ===

【默认假设检验】
1. "AI 总结 = 事实" → 未通过。AI 总结是压缩重述，原始材料中的含混和矛盾信号被提前磨平
2. "高频关键词 = 核心诉求" → 未验证。高频可能是话术惯性，需回到原始语境验证
3. "结构完整 = 分析到位" → 未通过。流畅不等于真实

【证据可信度】
- AI 提取的"效率"高频词有一定依据，但只覆盖了用户最容易说出口的部分
- 缺少：原始访谈中"信任焦虑""失控焦虑""使用负担"等可能更关键但更难表达的信号
- 三条线需要并行：访谈原话 / AI 总结 / 人的判断

【修正后描述】
AI 提取的"效率"可能是用户表层诉求，但原始材料中可能还藏着更深层的信任、可控性和认知负担问题。不应让 AI 总结直接盖过原始材料里那些更含混但可能更真实的信号。

【八种修正视角关键发现】
- 反面看："效率"可能只是最容易说出口的词，真正痛点可能是更难表达的"不信任"
- 代价看：只做效率功能可能忽略信任建设，短期数据好看但长期关系脆弱
- 他人看：用户本人可能不完全认同"我的核心诉求是效率"这种概括
```

## 视角修正速查卡

| 修正视角 | 核心问法 | 适用场景 |
|---------|---------|---------|
| 反面看 | 如果相反判断成立呢？ | 观点高度一致、缺少反对声音时 |
| 整体看 | 放在更大系统里意味着什么？ | 只看局部优化时 |
| 动态看 | 现在成立，三个月后呢？ | 环境快速变化时 |
| 关系看 | 对谁有利、对谁有代价？ | 涉及多方利益时 |
| 代价看 | 接受这个判断要放弃什么？ | 只看到收益忽略代价时 |
| 边界看 | 什么条件下它不成立？ | 普遍化结论时 |
| 历史看 | 类似情境下发生过什么？ | 面对新问题时 |
| 他人看 | 持不同立场的人怎么看？ | 团队内部高度共识时 |

## 常见误区

### 误区 1："八种视角全都要用"
- 八种修正视角是启发式工具，不是必须全部使用
- 选择最相关的 2-4 种即可，关键是质量不是数量
- 全部用反而会变成形式主义

### 误区 2："修正看法 = 什么都说对"
- "修正看法"不是"和稀泥"，而是让判断建立在更坚实的基础上
- 修正后的看法应该更清晰、更有依据，而不是更模糊
- 目标是更接近真实，不是谁也不得罪

### 误区 3："只在决策前做一次"
- 视角修正应该在调用任何具体方法之前执行
- 但不是做一次就够了——重大判断变化时需要重新修正
- 形成习惯比偶尔做一次更重要