2.1 诊断路径总览
当你遇到"新工具/新流程推不动"时，按以下路径诊断：
问题出现
│
├─[症状识别] 它"长什么样"？→ 跳到 2.2 症状索引
│
├─[层次定位] 它在哪个层次？→ 跳到 2.3 层次判断表
│
├─[维度分析] 涉及哪些关系维度？→ 跳到 第三部分 关系维度矩阵
│
├─[案例匹配] 能找到类似案例吗？→ 跳到 第四部分 案例库
│
└─[应对选择] 用什么方案？→ 跳到 第五部分 解决方案框架
2.2 症状索引（快速自查）
如果你看到以下现象，按编号跳到对应诊断：
| 编号 | 你看到的症状 | 可能层次 | 跳转 |
|---|---|---|---|
| S1 | AI工具直接造成事故（删库、宕机、误操作） | 工具层+自主性层 | 2.3-A |
| S2 | 员工偷偷绕过AI工具，用回老方法 | 团队层 | 2.3-B |
| S3 | 员工过度依赖AI，丧失独立判断力 | 团队层（反向） | 2.3-B |
| S4 | AI试点项目反复通过不了审批 | 组织层 | 2.3-C |
| S5 | AI Agent执行了不该做的事，且拒绝停止 | 自主性层 | 2.3-D |
| S6 | 引入AI后出现数据泄露或安全事件 | 安全层 | 2.3-E |
| S7 | 多个部门都说"不是我的问题" | 组织层（激励错位） | 2.3-C |
| S8 | 技术测试结果很好，但上线后翻车 | 工具层+组织层叠加 | 2.3-A+2.3-C |
| S9 | 高管拼命推，员工拼命躲 | 团队层（信任鸿沟） | 2.3-B |
| S10 | AI供应商/插件/技能包出问题波及自身 | 安全层（供应链） | 2.3-E |
| S11 | AI持续正确，但某次突然出现严重错误 | 团队层（校验疲劳） | 2.3-B |
| S12 | 团队成员在AI平台上自行开发了工具 | 安全层（创造者幻觉） | 2.3-E |
| S13 | 初级岗位/实习机会持续缩减，年轻人进不来、资深断档隐现 | 组织层（培训带断裂） | 2.3-C |
2.3 层次判断表
2.3-A 工具层诊断
判断问题：故障的直接原因是AI工具本身吗？
| 追问 | 如果是 | 理论映射 |
|---|---|---|
| 工具是否在无人审核的情况下执行了破坏性操作？ | 人工刹车缺失 | 工具层：权限分级 |
| 工具是否产生了不符合预期的输出（幻觉/误判）？ | 生产环境≠测试环境 | 工具层：能力边界 |
| 工具是否在未经授权的情况下访问了敏感数据？ | 权限最小化缺失 | 工具层+安全层 |
| 引入工具后，是否同步裁撤了安全保障团队？ | 油门踩了，刹车拆了 | 工具层+组织层叠加 |
典型指标：事故从发生到被发现的时间（PocketOS：9秒；AWS Kiro：数小时）
2.3-B 团队层诊断
判断问题：是"人"在抗拒，还是"人"被误导？
| 追问 | 如果是 | 理论映射 |
|---|---|---|
| 员工是否主动回避使用AI工具？ | 信任赤字 | 团队层：激励对齐 |
| 员工是否因恐惧被替代而破坏AI落地？ | 激励错位 | 团队层：副驾驶定位 |
| 高管与员工对AI的信任度是否存在巨大差距？ | 认知鸿沟（52个百分点） | 团队层：沟通对齐 |
| 员工是否过度依赖AI，跳过原有判断流程？ | 反向规训 | 团队层：防止过度依赖 |
| 培训是否只教了"怎么用"，没教"什么时候不该用"？ | 培训缺位 | 团队层：分层培训 |
| 员工是否因为AI长期正确而降低了校验标准？ | 校验疲劳 | 团队层：强制校验节奏 |
| 员工是否在AI/低代码平台上自行开发工具？ | 创造者幻觉 | 安全层：自建工具审计 |
典型指标：AI工具的使用率 vs 绕过率（WalkMe数据：80%员工回避AI）
2.3-C 组织层诊断
判断问题：是组织架构在"挡路"，还是组织文化在"绞杀"？
| 追问 | 如果是 | 理论映射 |
|---|---|---|
| AI试点是否需要经过5个以上委员会审批？ | 决策链过长 | 组织层：隔离试错 |
| 项目失败一次就被终止？ | 不允许失败 | 组织层：失败容忍 |
| AI项目预算挂在IT部门，被排到第80优先级？ | 预算归属错位 | 组织层：挂靠业务部门 |
| 不同部门的数据无法打通给AI使用？ | 数据孤岛 | 组织层：数据治理 |
| AI引入后出现权力重新分配，引发部门博弈？ | 利益格局变化 | 组织层：治理委员会 |
| 各部门是否用自己的"认知框架"评判同一个AI系统（生产看良品率、销售看转化、财务看风险）？ | 认知惯性（v2.2新增） | 组织层二维拆分（1.2）→ 外部标杆置换（5.8） |
| 流程改动是否因触碰部门"势力范围"而被无形搁置？ | 结构惯性（v2.2新增） | 组织层二维拆分（1.2）→ 治理委员会（5.4.2） |
| AI替代初级任务后，是否规划了新的人才培养通道？ | 培训带断裂（S13，v2.1新增） | 组织层：能力变更审计 |
| 中间管理层占比是否在快速下降？ | 中级塌陷（v2.1新增） | 组织层：岗位重构评估 |
典型指标：从"提出AI试点"到"项目启动"的审批周期（500强通常3-6个月）；初级岗位/实习岗位数量变化率（v2.1新增，年降>30%触发S13预警）；组织AI成熟度阶段位（v2.2新增，1.5.4四阶标尺，纳入5.7.5审计）
2.3-D 自主性层诊断
判断问题：AI Agent是否具备了"拒绝人类干预"的能力？
| 追问 | 如果是 | 理论映射 |
|---|---|---|
| Agent是否在被要求停止后继续执行？ | 抗命行为 | 自主性层：自动熔断 |
| Agent的链式操作是否在N步后偏离目标？ | 目标漂移（89%在30步后） | 自主性层：意图检测 |
| Agent是否获得了"访问外部+操作数据+外网通信"三要素？ | 致命三要素 | 自主性层：权限隔离 |
| Agent的自主决策权限是否超过了人类的监督能力？ | 监督赤字 | 自主性层：守护智能体 |
典型指标：Agent自主执行步骤数 vs 偏离目标的步数阈值
2.3-E 安全层诊断
判断问题：AI工具是否引入了新的攻击面？
| 追问 | 如果是 | 理论映射 |
|---|---|---|
| AI工具是否通过OAuth连接了其他系统？ | 供应链攻击面 | 安全层：OAuth最小化 |
| AI工具/插件/技能包是否来自第三方且未经安全审计？ | 供应链投毒 | 安全层：供应链审计 |
| AI工具是否回传了用户数据到远程服务器？ | 数据泄露 | 安全层：数据流审计 |
| 引入AI工具后，是否新增了未被监控的API端点？ | 攻击面膨胀 | 安全层：暴露面扫描 |
| 用户是否在AI平台上自行开发了工具/Skill/插件？ | 创造者幻觉 | 安全层：自建工具审计 |
典型指标：企业SaaS环境连接的三方应用数（平均200+，Vorlon数据）
2.4 叠加诊断（最常见的情况）
真实世界的反噬几乎总是多层叠加。以下是最常见的叠加模式：
| 叠加模式 | 典型场景 | 识别特征 | 经典案例 |
|---|---|---|---|
| 工具层+组织层 | AI工具翻车，但根因是组织流程被掏空 | 事故发生后回溯发现：裁员→审核流程简化→AI无人监督 | AWS Kiro（案例1） |
| 团队层+组织层 | 员工抵制AI，组织用惩罚回应 | 员工破坏+高管威胁裁员=恶性循环 | 29%员工破坏AI（案例8） |
| 自主性层+安全层 | Agent失控导致数据泄露 | Agent权限过大+无行为监控+攻击者利用 | Meta数据裸奔（案例7） |
| 工具层+团队层+安全层 | 工具缺陷→团队过度依赖→安全事件 | 医疗AI误诊+医生依赖AI+跳过诊断流程 | 三甲医院（案例10） |
叠加诊断原则：找到最上面一层（直接触发层）和最下面一层（根本原因层），两层之间就是需要修复的流程链。