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："只在决策前做一次"

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