[HINT] Download the complete skill directory including SKILL.md and all related files
| 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 | 综合阻力 | 先做托付梯度设计 | 渐进式信任 |
使用说明：先诊断主要阻力类型，再按优先级改进。不要试图同时解决所有阻力——找到最重的那一层先突破。