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 | p13j-organizational-judgment |
| description | 组织判断力——将个人判断转化为团队判断能力的系统方法 |
| stage | p13 |
| tags | ["判断力","组织能力","团队判断"] |
| source_book | 判断力与直觉力 |
| source_chapter | 第11章 从个人判断到组织判断 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| team_decisions | 团队重要决策记录 |
| judgment_outcomes | 决策结果与预期对比 |
| team_structure | 团队决策流程与角色 |
很多团队一听到用户说"不想用 AI"，就默认是观念问题或对新技术的天然保守。其实很多时候不是——用户并不是抽象地排斥 AI，他只是很清楚：如果这一步做错、失控、说不清、或者最后要我来背锅，那我为什么要把它交出去？采用阻力的底层不是意见，而是风险感知。只有把风险感知拆开，产品才有机会真正对症。
(1) 怕错——结果一旦错会影响客户、错误很难被及时发现、错误会扩散到后续流程、用户没有低成本复核手段。用户关注的不是平均表现而是最糟时刻能不能收住。(2) 怕失控——不知道系统下一步会做什么、不能轻易修改或撤销、高风险动作没有确认点、系统把太多决定打包自动完成。用户怕的不是自动化本身，而是自己被排除在控制链之外。(3) 怕担责——如果 AI 给建议但最后还要我签字，这建议是帮我还是多一个我得解释的东西？责任感知常常比能力表现更直接影响采用。(4) 怕看不懂——结果为什么这样？依据是什么？看不懂会让人失去判断自己该不该信的能力。
访谈中最有效的转法。"你觉得这个功能怎么样""你会不会用"这些问题很难触及真正阻力。更有效的问法：你会停在哪一步？哪一步你会想再确认一下？哪一步你绝不会交出去？如果它在这里出错你最担心什么？你最不想替它承担什么后果？一旦这样问，很多"模糊不放心"就会变成可以诊断的问题。
画一张最朴素的地图：这一步如果错了谁先发现？谁先受影响？后果会停在这里还是继续扩散？用户能不能轻易纠正？最后谁来解释？很多采用阻力一画这张图就会突然清楚——用户的害怕不是空穴来风，而是和真实责任链、协作链、后果链紧紧连在一起。
"用户不用自动生成邮件"不要只理解成"生成质量还不够高"，也要追问：他是不是怕发错对象？怕口气不对？怕承诺过头？怕发出去之后要自己解释？功能问题解决的是"它能不能做"，心理阻力问题解决的是"用户为什么不敢交"。后者的诊断往往比前者更接近采用卡点的真实原因。
"用户并不是抽象地排斥AI，他只是很清楚：如果这一步做错、失控、说不清、或者最后要我来背锅，那我为什么要把它交出去？采用阻力的底层，不是意见，而是风险感知。" ——书稿第10章
很多团队一听到用户说"不想用AI"，就默认是观念问题或对新技术的天然保守。其实很多时候不是——用户只是在评估具体后果。只有把风险感知拆开，产品才有机会真正对症。怕错、怕失控、怕担责、怕看不懂——这四种恐惧各自对应不同的产品设计需求，不能笼统用"建立信任"一笔带过。应用：对每个采用率低的AI功能，先不要猜"模型不够强"，而是做四怕诊断——逐项检查用户到底在怕什么，然后把心理阻力转化为具体设计需求。
"更有效的问法：你会停在哪一步？哪一步你会想再确认一下？哪一步你绝不会交出去？一旦这样问，很多'模糊不放心'就会变成可以诊断的问题。" ——书稿第10章
"你觉得这个功能怎么样""你会不会用"这些问题很难触及真正阻力。而"你会停在哪一步""如果它在这里出错你最担心什么""你最不想替它承担什么后果"——这些问法会把模糊态度变成具体诊断点。用户不是在抽象评估技术，而是在评估：这件事出了问题，最后落到谁身上。应用：设计用户访谈时，把所有"喜不喜欢"类问题改写成"哪一步不敢"类问题。记录每个"停"的位置，那就是托付边界所在。
"画一张最朴素的地图：这一步如果错了谁先发现？谁先受影响？后果会停在这里还是继续扩散？用户能不能轻易纠正？最后谁来解释？" ——书稿第10章
很多采用阻力一画错误后果地图就会突然清楚——用户的害怕不是空穴来风，而是和真实责任链、协作链、后果链紧紧连在一起。后果最重的步骤必须保留人工确认，后果中等的可以让AI先给建议但需要附带依据，后果轻的可以让AI自动处理。应用：为关键步骤画后果地图：错了谁先发现→谁先受影响→后果会不会扩散→能不能纠正→最后谁来解释。用这张图决定AI在每一步的进入策略。
观察用户的实际行为：嘴上说还不错但行为上一直绕过你？会让 AI 起草但不会让 AI 发送？会看 AI 总结但不会拿它做会议结论？这类静默绕过比抱怨更值得警惕——它说明表层功能可能成立了，但托付结构并没有成立。
逐项检查：(1) 怕错——这个场景里最严重的错误是什么？用户有没有低成本复核手段？(2) 怕失控——用户知不知道系统在做什么？能不能修改/撤销/停止？(3) 怕担责——出了问题最后谁来面对客户/老板/合规审查？责任边界清不清楚？(4) 怕看不懂——用户能解释结果为什么这样吗？系统有没有给依据和来源？
画出关键步骤的后果地图：错了谁先发现→谁先受影响→后果会不会扩散→能不能纠正→最后谁来解释。这张图会帮助你理解用户为什么在某些步骤上特别保守。
把诊断出的心理阻力转化为具体的产品设计需求。怕错→需要校验机制和来源标注。怕失控→需要确认点和回退机制。怕担责→需要责任边界清晰化。怕看不懂→需要解释性和可追溯性。
设计能触及真实阻力的访谈问题。不要问"你喜不喜欢"，要问"你会停在哪一步""哪一步你绝不会交出去""如果它出错你最担心什么""你最不想替它承担什么后果"。
场景：AI 招聘初筛助手可根据岗位要求和简历内容给出候选人优先级建议。从能力角度看表现不差，但推到用人经理和 HR 手里时使用率很低。
四怕诊断：
结论：问题不是一句"模型还要再强一点"就能解决的。真正需要的是：(1) 可解释的筛选依据；(2) 允许用人经理调整权重和标准；(3) 明确哪些判断是建议哪些必须人工确认；(4) 出问题时有清晰的回溯路径。
场景：把常见心理阻力映射到具体设计需求。
| 心理阻力 | 典型表现 | 产品设计需求 |
|---|---|---|
| 怕错 | "万一错了客户会投诉" | 来源标注、不确定项标记、风险句高亮、关键步骤人工确认 |
| 怕失控 | "它做了我不知道的事" | 动作日志、可暂停、可撤销、自动化边界设置 |
| 怕担责 | "出了事谁来背" | 责任边界清晰化——哪些是建议/哪些自动做/哪些必须人工确认/哪些异常升级 |
| 怕看不懂 | "不知道它怎么得出的" | 推理依据展示、来源引用、结果与原始输入对照、关键假设标注 |
设计原则：不要一句"建立信任"了事，而要把信任需要的条件——依据、控制、回退、责任——变成可以拆、可以改、可以设计的产品结构。
场景：为一个 AI 合同审查产品绘制错误后果地图。
关键步骤分析：
| 审查步骤 | 如果错了谁先发现 | 谁先受影响 | 后果扩散性 | 纠正难度 | 最后谁解释 |
|---|---|---|---|---|---|
| 关键条款遗漏 | 法务审核时 | 公司 | 高（可能损失权益） | 高（合同已签） | 法务负责人 |
| 风险等级误判 | 执行时 | 业务方 | 中（影响决策） | 中（可补充条款） | 法务 + AI 产品 |
| 格式错误 | 合同流转时 | 行政 | 低（可修正） | 低 | 行政 |
| 法规引用过期 | 合规审查时 | 合规团队 | 高（合规风险） | 高 | 合规负责人 |
地图结论：
产品设计映射：
场景：为一个 AI 财务报告生成产品设计用户访谈问题。
低效问题（得不到真实阻力）：
高效问题（触及真实阻力）：
访谈记录模板：
| 问题 | 用户回答 | 诊断 |
|---|---|---|
| 哪部分最不放心？ | 收入预测那块 | 怕错——后果最重 |
| 能解释数字来源吗？ | 有时候说不清 | 怕看不懂——缺乏依据 |
| 会直接用吗？ | 不会，会再核一遍 | 怕担责——责任不清 |
| 最不想承担什么？ | 数字被老板质疑 | 怕担责——责任链缺失 |
核心问题：这个场景里最严重的错误是什么？ 检查清单：
诊断输出：如果错误后果重 + 发现晚 + 纠正难 + 无复核手段 = 用户一定怕错
核心问题：用户知不知道系统在做什么？ 检查清单：
诊断输出：如果系统不透明 + 无暂停 + 无撤销 + 高风险无确认 = 用户一定怕失控
核心问题：出了问题最后谁来面对后果？ 检查清单：
诊断输出：如果责任模糊 + 用户背锅 + 无回溯路径 = 用户一定怕担责
核心问题：用户能解释结果为什么这样吗？ 检查清单：
诊断输出：如果无依据 + 无来源 + 无不确定标记 = 用户一定怕看不懂
| 阻力类型 | 用户行为信号 | 产品设计需求 | 设计示例 |
|---|---|---|---|
| 怕错 | 反复手动检查 | 校验机制 + 来源标注 | 不确定项标黄、来源可点击 |
| 怕失控 | 手动备份/留台账 | 确认点 + 回退机制 | 暂停按钮、撤销操作、日志 |
| 怕担责 | 不愿推荐给团队 | 责任边界清晰化 | 审批链、角色权限、责任声明 |
| 怕看不懂 | 不用结果做决策 | 解释性 + 可追溯性 | 推理过程展示、来源引用 |
| 怕错 + 怕担责 | 只用低风险场景 | 分级执行策略 | 低风险自动、高风险人工确认 |
| 怕失控 + 怕看不懂 | 私下留人工台账 | 透明度 + 控制权 | 实时状态、可干预、可修改 |
使用说明：先观察用户行为信号，判断主要阻力类型，再对应用设计需求。注意：多种阻力往往同时存在，需要综合设计。
用户不用 AI
│
├─ 行为：试了几次就不用了
│ └─ 诊断：功能价值不足或体验摩擦大
│
├─ 行为：用了但反复手动检查
│ └─ 诊断：怕错——校验成本高
│
├─ 行为：只用低风险场景
│ └─ 诊断：怕错+怕担责——信任有边界
│
├─ 行为：私下留人工台账
│ └─ 诊断：怕失控——托付结构没成立
│
├─ 行为：不推荐给团队
│ └─ 诊断：怕担责——责任边界不清
│
└─ 行为：用了但从不拿结果做决策
└─ 诊断：怕看不懂——缺乏依据和可追溯性
| 优先级 | 阻力类型 | 改进方向 | 预期效果 |
|---|---|---|---|
| P0 | 怕错（后果重+无法复核） | 校验机制+来源标注+风险提示 | 降低错误恐惧 |
| P0 | 怕担责（责任完全在人） | 责任边界+审批链+角色权限 | 降低责任焦虑 |
| P1 | 怕失控（无法干预） | 暂停/撤销/确认点 | 增加控制感 |
| P1 | 怕看不懂（无依据） | 推理展示+来源引用 | 增加透明度 |
| P2 | 综合阻力 | 先做托付梯度设计 | 渐进式信任 |
使用说明：先诊断主要阻力类型，再按优先级改进。不要试图同时解决所有阻力——找到最重的那一层先突破。