组织判断力 Skill

适用场景

• 个人判断无法形成组织能力
• 团队决策质量不稳定
• 想建立可持续的判断沉淀机制

输入

字段	说明
team_decisions	团队重要决策记录
judgment_outcomes	决策结果与预期对比
team_structure	团队决策流程与角色

输出

• 组织判断Checklist
• 决策会议模板
• 判断沉淀机制设计

工作流程

1. 判断显性化：要求团队在决策时明确记录判断依据与置信度
2. 多元化输入：确保决策集合了不同视角（引入反对者/外部顾问）
3. 决策仪式设计：设计结构化的决策会议流程（如"预读-讨论-表决-记录"）
4. 复盘机制：定期对照结果回溯判断质量
5. 原则沉淀：将有效的判断经验抽象为团队原则

注意事项

• 组织判断 ≠ 民主投票——要明确决策责任人
• 判断沉淀是长期过程，需要持续记录与复盘

核心概念

1. 采用阻力不是"不信 AI"，而是"不敢承担某种后果"

很多团队一听到用户说"不想用 AI"，就默认是观念问题或对新技术的天然保守。其实很多时候不是——用户并不是抽象地排斥 AI，他只是很清楚：如果这一步做错、失控、说不清、或者最后要我来背锅，那我为什么要把它交出去？采用阻力的底层不是意见，而是风险感知。只有把风险感知拆开，产品才有机会真正对症。

2. 用户四怕

(1) 怕错——结果一旦错会影响客户、错误很难被及时发现、错误会扩散到后续流程、用户没有低成本复核手段。用户关注的不是平均表现而是最糟时刻能不能收住。(2) 怕失控——不知道系统下一步会做什么、不能轻易修改或撤销、高风险动作没有确认点、系统把太多决定打包自动完成。用户怕的不是自动化本身，而是自己被排除在控制链之外。(3) 怕担责——如果 AI 给建议但最后还要我签字，这建议是帮我还是多一个我得解释的东西？责任感知常常比能力表现更直接影响采用。(4) 怕看不懂——结果为什么这样？依据是什么？看不懂会让人失去判断自己该不该信的能力。

3. 别问"喜不喜欢"，要问"哪一步不敢"

访谈中最有效的转法。"你觉得这个功能怎么样""你会不会用"这些问题很难触及真正阻力。更有效的问法：你会停在哪一步？哪一步你会想再确认一下？哪一步你绝不会交出去？如果它在这里出错你最担心什么？你最不想替它承担什么后果？一旦这样问，很多"模糊不放心"就会变成可以诊断的问题。

4. 错误后果地图

画一张最朴素的地图：这一步如果错了谁先发现？谁先受影响？后果会停在这里还是继续扩散？用户能不能轻易纠正？最后谁来解释？很多采用阻力一画这张图就会突然清楚——用户的害怕不是空穴来风，而是和真实责任链、协作链、后果链紧紧连在一起。

5. 把功能问题翻译成心理阻力问题

"用户不用自动生成邮件"不要只理解成"生成质量还不够高"，也要追问：他是不是怕发错对象？怕口气不对？怕承诺过头？怕发出去之后要自己解释？功能问题解决的是"它能不能做"，心理阻力问题解决的是"用户为什么不敢交"。后者的诊断往往比前者更接近采用卡点的真实原因。

深入核心概念

1. 采用阻力的底层不是意见，而是风险感知

"用户并不是抽象地排斥AI，他只是很清楚：如果这一步做错、失控、说不清、或者最后要我来背锅，那我为什么要把它交出去？采用阻力的底层，不是意见，而是风险感知。" ——书稿第10章

很多团队一听到用户说"不想用AI"，就默认是观念问题或对新技术的天然保守。其实很多时候不是——用户只是在评估具体后果。只有把风险感知拆开，产品才有机会真正对症。怕错、怕失控、怕担责、怕看不懂——这四种恐惧各自对应不同的产品设计需求，不能笼统用"建立信任"一笔带过。应用：对每个采用率低的AI功能，先不要猜"模型不够强"，而是做四怕诊断——逐项检查用户到底在怕什么，然后把心理阻力转化为具体设计需求。

2. 别问"喜不喜欢"，要问"哪一步不敢"

"更有效的问法：你会停在哪一步？哪一步你会想再确认一下？哪一步你绝不会交出去？一旦这样问，很多'模糊不放心'就会变成可以诊断的问题。" ——书稿第10章

"你觉得这个功能怎么样""你会不会用"这些问题很难触及真正阻力。而"你会停在哪一步""如果它在这里出错你最担心什么""你最不想替它承担什么后果"——这些问法会把模糊态度变成具体诊断点。用户不是在抽象评估技术，而是在评估：这件事出了问题，最后落到谁身上。应用：设计用户访谈时，把所有"喜不喜欢"类问题改写成"哪一步不敢"类问题。记录每个"停"的位置，那就是托付边界所在。

3. 错误后果地图：比功能优化更有用的诊断工具

"画一张最朴素的地图：这一步如果错了谁先发现？谁先受影响？后果会停在这里还是继续扩散？用户能不能轻易纠正？最后谁来解释？" ——书稿第10章

很多采用阻力一画错误后果地图就会突然清楚——用户的害怕不是空穴来风，而是和真实责任链、协作链、后果链紧紧连在一起。后果最重的步骤必须保留人工确认，后果中等的可以让AI先给建议但需要附带依据，后果轻的可以让AI自动处理。应用：为关键步骤画后果地图：错了谁先发现→谁先受影响→后果会不会扩散→能不能纠正→最后谁来解释。用这张图决定AI在每一步的进入策略。

分步执行

步骤 1：采用阻力识别

观察用户的实际行为：嘴上说还不错但行为上一直绕过你？会让 AI 起草但不会让 AI 发送？会看 AI 总结但不会拿它做会议结论？这类静默绕过比抱怨更值得警惕——它说明表层功能可能成立了，但托付结构并没有成立。

步骤 2：四怕诊断

逐项检查：(1) 怕错——这个场景里最严重的错误是什么？用户有没有低成本复核手段？(2) 怕失控——用户知不知道系统在做什么？能不能修改/撤销/停止？(3) 怕担责——出了问题最后谁来面对客户/老板/合规审查？责任边界清不清楚？(4) 怕看不懂——用户能解释结果为什么这样吗？系统有没有给依据和来源？

步骤 3：错误后果地图绘制

画出关键步骤的后果地图：错了谁先发现→谁先受影响→后果会不会扩散→能不能纠正→最后谁来解释。这张图会帮助你理解用户为什么在某些步骤上特别保守。

步骤 4：阻力→设计需求转化

把诊断出的心理阻力转化为具体的产品设计需求。怕错→需要校验机制和来源标注。怕失控→需要确认点和回退机制。怕担责→需要责任边界清晰化。怕看不懂→需要解释性和可追溯性。

步骤 5：访谈问题设计

设计能触及真实阻力的访谈问题。不要问"你喜不喜欢"，要问"你会停在哪一步""哪一步你绝不会交出去""如果它出错你最担心什么""你最不想替它承担什么后果"。

示例 1：AI 招聘初筛助手——为什么使用率低

场景：AI 招聘初筛助手可根据岗位要求和简历内容给出候选人优先级建议。从能力角度看表现不差，但推到用人经理和 HR 手里时使用率很低。

四怕诊断：

1. 怕错：HR 怕错过合适候选人，后果很实际。
2. 怕失控：用人经理不想让系统把人选节奏带偏。
3. 怕担责：一旦有人质疑筛选标准，最后需要解释的人不是 AI，而是 HR 和用人经理。
4. 怕看不懂：如果系统只给一个分数却不给可解释依据，没人愿意真的依赖它。

结论：问题不是一句"模型还要再强一点"就能解决的。真正需要的是：(1) 可解释的筛选依据；(2) 允许用人经理调整权重和标准；(3) 明确哪些判断是建议哪些必须人工确认；(4) 出问题时有清晰的回溯路径。

示例 2：心理阻力→产品设计需求映射

场景：把常见心理阻力映射到具体设计需求。

心理阻力	典型表现	产品设计需求
怕错	"万一错了客户会投诉"	来源标注、不确定项标记、风险句高亮、关键步骤人工确认
怕失控	"它做了我不知道的事"	动作日志、可暂停、可撤销、自动化边界设置
怕担责	"出了事谁来背"	责任边界清晰化——哪些是建议/哪些自动做/哪些必须人工确认/哪些异常升级
怕看不懂	"不知道它怎么得出的"	推理依据展示、来源引用、结果与原始输入对照、关键假设标注

设计原则：不要一句"建立信任"了事，而要把信任需要的条件——依据、控制、回退、责任——变成可以拆、可以改、可以设计的产品结构。

示例 3：错误后果地图——以 AI 合同审查为例

场景：为一个 AI 合同审查产品绘制错误后果地图。

关键步骤分析：

审查步骤	如果错了谁先发现	谁先受影响	后果扩散性	纠正难度	最后谁解释
关键条款遗漏	法务审核时	公司	高（可能损失权益）	高（合同已签）	法务负责人
风险等级误判	执行时	业务方	中（影响决策）	中（可补充条款）	法务 + AI 产品
格式错误	合同流转时	行政	低（可修正）	低	行政
法规引用过期	合规审查时	合规团队	高（合规风险）	高	合规负责人

地图结论：

1. 关键条款遗漏和法规引用过期的后果最重，这两步必须保留人工确认
2. 风险等级误判可以由 AI 先给建议，但需要附带依据供法务判断
3. 格式错误可以让 AI 自动处理，风险低且易纠正

产品设计映射：

• 高后果步骤 → AI 给建议 + 人工确认 + 依据展示
• 中后果步骤 → AI 执行 + 标注不确定 + 可修改
• 低后果步骤 → AI 自动处理 + 日志记录 + 可回退

示例 4：访谈问题设计——从"喜不喜欢"到"哪一步不敢"

场景：为一个 AI 财务报告生成产品设计用户访谈问题。

低效问题（得不到真实阻力）：

• "你觉得这个功能怎么样？"
• "你会不会用？"
• "你喜欢这个体验吗？"

高效问题（触及真实阻力）：

• "生成的报告你会直接用，还是会自己再算一遍？"
• "哪一部分你最不放心交给它？"
• "如果报告里有个数字错了，你最担心谁先发现？"
• "老板问你这个数字怎么来的，你能解释吗？"
• "如果系统在这里出错，你最不想承担什么后果？"
• "你会把哪个步骤完全交给它？哪个步骤绝对不行？"

访谈记录模板：

问题	用户回答	诊断
哪部分最不放心？	收入预测那块	怕错——后果最重
能解释数字来源吗？	有时候说不清	怕看不懂——缺乏依据
会直接用吗？	不会，会再核一遍	怕担责——责任不清
最不想承担什么？	数字被老板质疑	怕担责——责任链缺失

四怕诊断详细框架

怕错诊断

核心问题：这个场景里最严重的错误是什么？ 检查清单：

• 列出最严重的 3 种错误及其后果
• 评估当前错误率是否可接受
• 用户有没有低成本复核手段
• 错误发现的时间窗口有多长
• 错误一旦发生，纠正成本有多高

诊断输出：如果错误后果重 + 发现晚 + 纠正难 + 无复核手段 = 用户一定怕错

怕失控诊断

核心问题：用户知不知道系统在做什么？ 检查清单：

• 用户能看到系统正在执行什么吗
• 用户能在任意点暂停或停止吗
• 用户能修改或撤销结果吗
• 高风险动作有没有确认点
• 自动化边界是否清晰

诊断输出：如果系统不透明 + 无暂停 + 无撤销 + 高风险无确认 = 用户一定怕失控

怕担责诊断

核心问题：出了问题最后谁来面对后果？ 检查清单：

• 责任边界是否写清楚了
• 用户知不知道自己在替系统承担什么
• AI 给的建议是帮忙还是多了一层解释负担
• 出了问题有没有清晰的回溯路径
• 合规审查时能不能说清楚依据

诊断输出：如果责任模糊 + 用户背锅 + 无回溯路径 = 用户一定怕担责

怕看不懂诊断

核心问题：用户能解释结果为什么这样吗？ 检查清单：

• 结果附带推理依据吗
• 来源是否可追溯
• 不确定项是否有标记
• 关键假设是否标注
• 结果与原始输入是否可对照

诊断输出：如果无依据 + 无来源 + 无不确定标记 = 用户一定怕看不懂

阻力→设计需求转化矩阵

阻力类型	用户行为信号	产品设计需求	设计示例
怕错	反复手动检查	校验机制 + 来源标注	不确定项标黄、来源可点击
怕失控	手动备份/留台账	确认点 + 回退机制	暂停按钮、撤销操作、日志
怕担责	不愿推荐给团队	责任边界清晰化	审批链、角色权限、责任声明
怕看不懂	不用结果做决策	解释性 + 可追溯性	推理过程展示、来源引用
怕错 + 怕担责	只用低风险场景	分级执行策略	低风险自动、高风险人工确认
怕失控 + 怕看不懂	私下留人工台账	透明度 + 控制权	实时状态、可干预、可修改

使用说明：先观察用户行为信号，判断主要阻力类型，再对应用设计需求。注意：多种阻力往往同时存在，需要综合设计。

访谈问题库

通用问题（适用所有场景）

1. "你会停在哪一步？" —— 定位托付边界
2. "哪一步你绝不会交出去？" —— 识别不可让渡的控制权
3. "如果它在这里出错，你最担心什么？" —— 识别后果类型
4. "你最不想替它承担什么后果？" —— 识别责任焦虑
5. "你会把它推荐给同事吗？为什么不会？" —— 识别组织扩散障碍

怕错场景专用

6. "这个结果你一般会检查几遍？" —— 评估校验成本
7. "你上次发现它错是什么情况？" —— 了解错误模式
8. "错了之后你怎么收场？" —— 评估纠正成本

怕担责场景专用

9. "如果老板问这个数字怎么来的，你怎么说？" —— 评估解释能力
10. "出了问题谁来面对客户？" —— 评估责任结构
11. "你会在什么情况下把它写进你的正式报告？" —— 评估信任深度

怕失控场景专用

12. "你能随时停下来吗？" —— 评估控制感
13. "它做了你不知道的事，你会怎么办？" —— 评估透明度
14. "你希望在哪些地方多一个确认？" —— 识别确认需求

阻力诊断流程图

用户不用 AI
    │
    ├─ 行为：试了几次就不用了
    │   └─ 诊断：功能价值不足或体验摩擦大
    │
    ├─ 行为：用了但反复手动检查
    │   └─ 诊断：怕错——校验成本高
    │
    ├─ 行为：只用低风险场景
    │   └─ 诊断：怕错+怕担责——信任有边界
    │
    ├─ 行为：私下留人工台账
    │   └─ 诊断：怕失控——托付结构没成立
    │
    ├─ 行为：不推荐给团队
    │   └─ 诊断：怕担责——责任边界不清
    │
    └─ 行为：用了但从不拿结果做决策
        └─ 诊断：怕看不懂——缺乏依据和可追溯性

采用阻力→产品改进优先级

优先级	阻力类型	改进方向	预期效果
P0	怕错（后果重+无法复核）	校验机制+来源标注+风险提示	降低错误恐惧
P0	怕担责（责任完全在人）	责任边界+审批链+角色权限	降低责任焦虑
P1	怕失控（无法干预）	暂停/撤销/确认点	增加控制感
P1	怕看不懂（无依据）	推理展示+来源引用	增加透明度
P2	综合阻力	先做托付梯度设计	渐进式信任

使用说明：先诊断主要阻力类型，再按优先级改进。不要试图同时解决所有阻力——找到最重的那一层先突破。