Menu
先修正看法，再调用方法——默认检查、证据校验、后果追问、八种修正视角
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p12a-contemplation-view-correction |
| description | 先修正看法，再调用方法——默认检查、证据校验、后果追问、八种修正视角 |
| stage | discovery |
| tags | ["正思维","视角修正","证据校验","默认检查"] |
| source_book | 观照 |
| source_chapter | 第2章 从产品方法到产品观照 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| initial_view | 当前/主流的看法 |
| supporting_evidence | 支持该看法的证据 |
| underlying_assumptions | 隐含的默认假设 |
"方法不是没用。问题是，如果连眼前这份工作本身都还没有被重新看清，方法只会帮组织更熟练地在旧地图上跑。"
书稿在第二章以 Microsoft "试点地狱"案例说明：很多组织的 AI 转型开头都差不多——团队做出亮眼 demo，领导点头，项目被贴上"创新、效率、智能化"等标签。但半年后，真正的业务流程没怎么改，核心指标没怎么动，试点始终留在试点。真正该被重看的不是某个功能入口，而是更前面的那层：我们到底以为工作是怎样发生的？LinkedIn 拉开差距的不是多加了一个 AI 功能，而是开始重做产品开发方式。
在产品决策中，视角修正要求在调用任何具体方法之前先执行。不是做一次就够了——重大判断变化时需要重新修正。形成"先检查默认假设，再调用方法"的习惯比偶尔做一次更重要。当团队说"方向正确"时，视角修正会追问：这个"正确"是基于精心控制的 demo 环境，还是基于真实业务流程中的摩擦？
"AI 几秒钟就能生成结构完整、逻辑顺滑的'总结'和'建议'。它们看起来特别像共识，特别适合直接贴进汇报材料里。可越是顺滑，越可能把那些真正关键、但还很粗糙、还没被说顺的信号提前磨平。"
书稿警告"转述幻觉"的危险：AI 总结或他人转述被误当成事实本身。访谈原话、AI 总结、人的判断必须三条线并行。不能把解释直接当事实——很多组织里的误判，不是没人看到事实，而是事实一进入集体表达就被熟练地重新命名了。流畅不等于真实，完整不等于贴近处境，像样不等于值得采纳。
在产品研究中，当把 30 份用户访谈丢给 AI 得到"核心诉求是效率"的总结时，不应直接据此制定路线图。原始访谈中可能有"信任焦虑""失控焦虑""使用负担"等信号被 AI 的"总结能力"提前磨平了。正确做法是建立三条线并行：访谈原话 / AI 总结 / 人的独立判断，回到原始材料验证 AI 提取的是否只是用户最容易说出口的部分。
"所有听起来很顺、很熟、很像答案的东西，都值得在落地之前再看一眼。它逼着团队从'这个说法有没有道理'，再往前走一步，去问：这个说法现在为什么会让我这么容易点头？"
书稿引用迦罗摩经的故事，将"判断"从服从和反服从里都拉出来。很多团队最容易轻信的不只是"权威"，还包括行业共识、成熟模板和 AI 自己给出的答案。行业共识可能是集体盲区——大家都说"AI 产品要先做 agent"，于是团队一边点头一边开始规划，却没有先问：我们的用户真实处境里，自动代理到底解决了什么痛点？
在产品规划中，对所有"太顺的答案"保留一点迟疑——迟疑不是拖延，是留给自己重新看见的机会。当竞品都在做某功能时，视角修正要求追问：这个说法靠的是现实，还是靠熟悉感、权威感、行业惯性和表达顺滑感？如果竞品不做这个功能，我们还会做吗？把"判断"从行业惯性里拉出来，才能避免团队在跟随中迷失自己的判断力。
很多组织的 AI 转型看起来开头都差不多：团队做出亮眼 demo，领导点头，项目被贴上"创新、效率、智能化"等标签。但半年后，真正的业务流程没怎么改，核心指标没怎么动，试点始终留在试点。Microsoft WorkLab 称之为"试点地狱"（pilot purgatory）。
initial_view: "我们的 AI 转型进展顺利，demo 反馈好，领导认可，方向正确"
supporting_evidence: "内部试用满意度高、汇报获好评、技术可行性已验证"
underlying_assumptions:
- "demo 成功意味着产品成功"
- "领导认可等于方向正确"
- "AI 可以直接贴到旧流程上"
=== 视角修正报告 ===
【默认假设检验】
1. "demo 成功 = 真实场景成功" → 未通过。demo 缺少治理、权限、监控、回退等真实约束
2. "工具接进去 = 工作被改变" → 未通过。根本没看清工作是怎么发生的
3. "领导认可 = 方向正确" → 部分通过。认可的是方向感，不是执行路径
【证据可信度】
- 观察（demo 反馈好）可信，但仅限精心控制环境
- 缺少：真实业务流程中的摩擦数据、用户在日常工作中的实际使用行为
【修正后描述】
AI 转型的 demo 阶段确实验证了技术可行性，但"试点地狱"说明组织跳过了最关键的一步：重新看清工作到底是怎么发生的。真正该被重看的不是某个功能入口，而是更前面的那层——我们到底以为工作是怎样发生的。
【八种修正视角关键发现】
- 反面看：demo 成功可能让组织更不愿面对"工作本身还没被重看"的事实
- 动态看：半年停留在试点说明扩散阶段的问题与 demo 阶段完全不同
- 代价看：继续在旧流程上贴 AI 的代价是永远走不出试点
一个产品团队把用户访谈丢给 AI，AI 生成了一份结构完整、逻辑顺滑的"核心诉求总结"。团队直接把这份总结贴进产品路线图。但原始访谈中那些更含混、更矛盾、更真实的信号，被 AI 的"总结能力"提前磨平了。
initial_view: "AI 总结得很清楚，核心诉求是效率，我们应该优先做效率相关功能"
supporting_evidence: "AI 从 30 份访谈中总结出'效率'是最高频关键词"
underlying_assumptions:
- "AI 总结 = 事实"
- "高频关键词 = 核心诉求"
- "总结比原始材料更可信"
=== 视角修正报告 ===
【默认假设检验】
1. "AI 总结 = 事实" → 未通过。AI 总结是压缩重述，原始材料中的含混和矛盾信号被提前磨平
2. "高频关键词 = 核心诉求" → 未验证。高频可能是话术惯性，需回到原始语境验证
3. "结构完整 = 分析到位" → 未通过。流畅不等于真实
【证据可信度】
- AI 提取的"效率"高频词有一定依据，但只覆盖了用户最容易说出口的部分
- 缺少：原始访谈中"信任焦虑""失控焦虑""使用负担"等可能更关键但更难表达的信号
- 三条线需要并行：访谈原话 / AI 总结 / 人的判断
【修正后描述】
AI 提取的"效率"可能是用户表层诉求，但原始材料中可能还藏着更深层的信任、可控性和认知负担问题。不应让 AI 总结直接盖过原始材料里那些更含混但可能更真实的信号。
【八种修正视角关键发现】
- 反面看："效率"可能只是最容易说出口的词，真正痛点可能是更难表达的"不信任"
- 代价看：只做效率功能可能忽略信任建设，短期数据好看但长期关系脆弱
- 他人看：用户本人可能不完全认同"我的核心诉求是效率"这种概括
| 修正视角 | 核心问法 | 适用场景 |
|---|---|---|
| 反面看 | 如果相反判断成立呢？ | 观点高度一致、缺少反对声音时 |
| 整体看 | 放在更大系统里意味着什么？ | 只看局部优化时 |
| 动态看 | 现在成立，三个月后呢？ | 环境快速变化时 |
| 关系看 | 对谁有利、对谁有代价？ | 涉及多方利益时 |
| 代价看 | 接受这个判断要放弃什么？ | 只看到收益忽略代价时 |
| 边界看 | 什么条件下它不成立？ | 普遍化结论时 |
| 历史看 | 类似情境下发生过什么？ | 面对新问题时 |
| 他人看 | 持不同立场的人怎么看？ | 团队内部高度共识时 |