Menü
先修正看法，再调用方法——默认检查、证据校验、后果追问、八种修正视角
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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 总结直接盖过原始材料里那些更含混但可能更真实的信号。
【八种修正视角关键发现】
- 反面看："效率"可能只是最容易说出口的词，真正痛点可能是更难表达的"不信任"
- 代价看：只做效率功能可能忽略信任建设，短期数据好看但长期关系脆弱
- 他人看：用户本人可能不完全认同"我的核心诉求是效率"这种概括
| 修正视角 | 核心问法 | 适用场景 |
|---|---|---|
| 反面看 | 如果相反判断成立呢？ | 观点高度一致、缺少反对声音时 |
| 整体看 | 放在更大系统里意味着什么？ | 只看局部优化时 |
| 动态看 | 现在成立，三个月后呢？ | 环境快速变化时 |
| 关系看 | 对谁有利、对谁有代价？ | 涉及多方利益时 |
| 代价看 | 接受这个判断要放弃什么？ | 只看到收益忽略代价时 |
| 边界看 | 什么条件下它不成立？ | 普遍化结论时 |
| 历史看 | 类似情境下发生过什么？ | 面对新问题时 |
| 他人看 | 持不同立场的人怎么看？ | 团队内部高度共识时 |