[HINT] Download the complete skill directory including SKILL.md and all related files
| 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 总结当事实 |
| 推理 | 从证据到结论的逻辑是否成立？ | 逻辑跳跃、因果倒置 |
| 情绪 | 什么情绪影响了这个判断？ | 焦虑驱动跟随、不甘心驱动坚持 |
| 维度 | 探索模式 | 辩护模式 |
|---|---|---|
| 核心问法 | "如果我错了，最可能错在哪？" | "我还能找什么证明自己没错？" |
| 对反证的态度 | 认真对待，看是否需要修正判断 | 找理由解释掉或忽略 |
| 对不确定性的态度 | 承认不确定，继续收集信息 | 急于结束不确定 |
| 典型表现 | "我们还需要验证什么" | "数据已经说明了" |
| 最终判断 | 可修正、有置信度标注 | 坚定但可能基于不完整信息 |