القائمة
修正判断路径，而不是堆更多观点——拆解判断链，区分前提/证据/推理/情绪
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p12a-contemplation-right-thinking |
| description | 修正判断路径，而不是堆更多观点——拆解判断链，区分前提/证据/推理/情绪 |
| stage | discovery |
| tags | ["正思维","判断拆解","推理路径","情绪识别"] |
| source_book | 观照 |
| source_chapter | 第4章 正思维 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| judgment_statement | 判断/结论陈述（如"这个功能应该做"） |
| reasoning_path | 得出该判断的推理过程（若有） |
| emotional_tags | 伴随的情绪感受（焦虑/兴奋/担忧等） |
"探索模式会问：如果我错了，最可能错在哪？辩护模式只会问：我还能找什么证明自己没错？这个区别看起来细，后果却完全不同。"
书稿在第四章指出，很多组织的判断失真并不是因为信息太少，而是因为信息进入判断之前，已经被角色、经验、情绪和立场过滤过了。一个团队越成熟、越专业，有时反而越难纠偏——因为每个人都有框架，都会用逻辑和数据把解释包装得很像"理性结论"。判断路径一歪，后面的分析再多，也只是更漂亮的偏差。AI 时代会让这种偏差更隐蔽：一个带着立场的判断在 AI 帮助下很快就能变成"滴水不漏的分析"。
在产品决策中，正思维要求从辩护模式切回探索模式。Cisco 案例中，团队最初判断路径是"单点效率有没有提升"——补全准不准？界面顺不顺？但 Cisco 面对的是复杂代码库、跨团队协作的真实工程世界。他们真正做的不是在"更强补全"上继续打磨答案，而是把问题路径改了：从"工具聪不聪明"改为"能不能在真实约束下持续工作"。先改"我们究竟在判断什么"，再改"我们怎样把它放进真实工作"。
"人会用很多看起来很像思考的东西，拖延自己真正该面对的东西。明明该先处理的是箭伤，却把力气花在证明、归责、维护自我、满足控制感上。"
书稿引用佛教"毒箭喻"来说明判断优先级的错位：一个项目数据不佳，真正该先处理的也许是用户价值是否成立，但组织更容易先讨论是谁没执行好、哪个团队没配合好。一个方向已经越来越站不住，真正该处理的也许是最初假设是否需要重来，但团队更容易忙着证明市场还没成熟、竞品太不讲武德。这些讨论不是完全没意义，但它们常常不是那支箭。
在产品复盘中，正思维要求"先问箭在哪，再问谁射的"。当 AI 客服功能只能处理 35% 的问题且满意度低于人工时，团队不应该先讨论"谁的 prompt 写得不好"或"知识库谁负责维护"，而应该先面对最直接的判断：初始假设"AI 可以替代 80% 人工客服"是否已被证伪？如果答案是肯定的，那么继续优化 prompt 只是在给旧系统打补丁，而不是重看方向。
"一个判断背后至少有四样东西混在一起：我们一开始默认了什么？我们真正看到了什么？我们怎样把证据连成结论的？我们为什么特别想让这个结论成立？"
书稿提出将判断拆解为前提、证据、推理、情绪四个独立成分。只要四件事混在一起，讨论就很容易变立场对撞。拆开后才能看见团队真正站得最虚的是哪一层。有人不是证据不足，而是前提没重看；有人不是逻辑不通，而是情绪太重；有人不是不知道风险，而是不愿意面对如果这个方向错了自己要承担什么心理代价。
在产品团队中，当负责人说"应该先做 agent，因为行业都在做"时，正思维要求拆解这个判断：前提——"行业都在做 = 我们也应该做"未验证，行业共识可能是集体盲区；证据——全来自外部观察，没有用户验证；推理——跳过了"用户是否需要"这一层；情绪——"怕落后"的焦虑驱动了跟随倾向。拆开后才发现，团队处于辩护模式（找理由做 agent）而非探索模式（先问用户需要什么），判断链最薄弱的环节是完全没有用户层面的需求验证。
Cisco 在评估是否引入 Codex 时，团队最初的判断路径是"单点效率有没有提升"——补全准不准？界面顺不顺？能不能少写几行代码？但 Cisco 面对的是复杂代码库、跨团队协作、安全治理、代码评审的真实工程世界，问题不只是"工具聪不聪明"，而是"它能不能在真实约束下持续工作"。
judgment_statement: "Codex 在补全效率上有提升，但幅度有限，建议暂缓引入"
reasoning_path: "补全准确率测试 → 与现有工具对比 → 效率提升约 15% → 不足以改变工作流"
emotional_tags: ["对新技术的谨慎", "对现有流程稳定性的偏好", "怕引入新工具带来混乱"]
=== 判断链拆解报告 ===
【判断】Codex 效率提升有限，建议暂缓引入
【拆解】
- 前提：AI 价值 = 单点效率提升 → 过窄，应扩展到"流程适配性和能动性"
- 证据：补全准确率 15% 提升 → 可信但不完整，缺少"真实工程工作流"测试
- 推理：效率提升有限 → 暂缓 → 跳跃。"效率不够"不等于"不值得引入"
- 情绪：对流程稳定的偏好可能让团队更倾向找理由不引入
【薄弱环节】
- 判断维度过窄（只看效率，不看能动性）
- 证据覆盖不全（只测了单点，没测流程）
- 情绪可能驱动了保守倾向
【修正后判断】
不应仅凭"单点效率"决定是否引入。Cisco 的真正问题是：Codex 能不能进入真实工程工作流、接受真实约束、承担真实工作、不破坏治理边界？这需要把 Codex 直接放进真实工作里重新判断。置信度：需要补充真实工作流测试数据后才能做最终决策。
一个团队在讨论 AI 产品方向时，负责人说"应该先做 agent，因为行业都在做"。但这个判断背后的前提、证据和推理路径没有被拆开过。团队需要检查：这个判断是怎么长出来的？
judgment_statement: "我们应该先做 AI agent，行业趋势明确，竞品都在做"
reasoning_path: "行业报告 → 竞品分析 → 头部公司都在布局 agent → 我们也应该做"
emotional_tags: ["怕落后", "对行业趋势的焦虑", "想快速行动"]
=== 判断链拆解报告 ===
【判断】应该先做 AI agent
【拆解】
- 前提："行业都在做 = 我们也应该做" → 未通过。行业共识可能是集体盲区
- 证据：行业报告、竞品分析 → 来源单一，全是外部观察，缺少用户验证
- 推理：行业趋势 → 我们应该做 → 跳过了"用户是否需要"这一层
- 情绪："怕落后"的焦虑驱动了跟随倾向，让行业共识变得太像答案
【薄弱环节】
- 没有用户层面的需求验证
- 推理路径是"外部压力 → 跟随"，不是"用户问题 → 解决方案"
- 处于辩护模式（找理由做 agent）而非探索模式（先问用户需要什么）
【修正后判断】
不应直接决定"做不做 agent"。应该先验证：我们的用户真实处境里，自动代理到底解决了什么痛点？又会带来什么新的不安（如可控性、信任）？先做小实验验证判断，再决定方向。置信度：当前判断未经用户验证，置信度低。
| 判断成分 | 检查问题 | 常见偏差 |
|---|---|---|
| 前提 | 这个判断默认了什么假设？ | 默认接受、未经验证 |
| 证据 | 有哪些事实支撑？质量如何？有反证吗？ | 选择性引用、AI 总结当事实 |
| 推理 | 从证据到结论的逻辑是否成立？ | 逻辑跳跃、因果倒置 |
| 情绪 | 什么情绪影响了这个判断？ | 焦虑驱动跟随、不甘心驱动坚持 |
| 维度 | 探索模式 | 辩护模式 |
|---|---|---|
| 核心问法 | "如果我错了，最可能错在哪？" | "我还能找什么证明自己没错？" |
| 对反证的态度 | 认真对待，看是否需要修正判断 | 找理由解释掉或忽略 |
| 对不确定性的态度 | 承认不确定，继续收集信息 | 急于结束不确定 |
| 典型表现 | "我们还需要验证什么" | "数据已经说明了" |
| 最终判断 | 可修正、有置信度标注 | 坚定但可能基于不完整信息 |