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）

适用场景

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

输入

输出

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

工作流程

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

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