AI psychosis:领导层认知偏差如何影响AI项目落地与决策
AI psychosis 这个词最近在管理层讨论里出现得越来越频繁。它不是说 AI 模型自己“疯了”也不是在描述某个工程师因加班精神崩溃而是指一类更隐蔽的现象领导者在面对 AI 时把“对 AI 的想象”当成了“AI 的真实能力”进而做出脱离一线、脱离数据、脱离投入产出比的决策。换句话说AI 没有疯人对 AI 的认知先出现了系统性偏差。这恰恰是当下最容易被忽略的领导力盲点。这篇文章适合正在推动 AI 落地的管理者、技术负责人、产品负责人也适合那些被上级要求“搞 AI”但不知道如何判断值不值得投入的人。我会先拆解这个盲点到底是什么再给一套可以照做的识别、排查和纠偏方法。按经验来看真正的问题通常不在技术而在决策链条上的信息失真和激励错位。1. AI psychosis 到底在说什么领导层的认知错位集合先给一个比较完整的理解框架。AI psychosis 不是一个医学诊断而是一组可以观察到的决策行为模式。它通常表现为领导者在 AI 相关决策中反复出现与事实不符的判断并且这种判断会直接影响资源分配、团队方向和业务结果。1.1 不是“AI 疯了”是“人对 AI 的认知疯了”很多管理文章讨论 AI 时焦点都在模型能力上能不能推理、会不会幻觉、参数多大、效果多好。但真正让项目失败的往往是“人对 AI 的期望出了问题”。我见过一个典型的场景公司高层参加完一场行业峰会回来就要求技术团队“一个月内全面接入大模型”。技术团队问要解决什么问题高层说“先接上再说”。结果项目做完了没有用户场景没有验收标准只有一张“我们已经拥抱 AI”的汇报 PPT。这种决策不是基于业务需求而是基于对 AI 的某种想象。这就是 AI psychosis 的核心领导者不是根据实际情况做判断而是根据自己对 AI 的焦虑、兴奋或恐惧做判断。长期看这种认知错位会让组织陷入大量无效投入甚至让一线团队失去对管理层的信任。1.2 领导者在 AI 问题上的三种典型错位根据我接触过的团队领导层的认知错位大致可以分成三种。第一种是过度乐观型。这类领导者认为 AI 是万能药什么问题都能解决。他们的典型表达是“用 AI 把所有流程都自动化”“AI 肯定比人做得好”。他们不关心错误率、不关心边界条件、不关心数据质量只关心有没有用上最热门的技术。第二种是防御焦虑型。这类领导者并不真正理解 AI但他们害怕被同行落下、被上级问责。他们的表达通常是“别人都在搞我们也必须搞”“不搞 AI 就会被淘汰”。他们的决策动机是避险而不是创造价值。这种情绪最容易导致盲目跟风和重复建设。第三种是判断外包型。这类领导者会把 AI 的输出当成不可质疑的结论。比如直接拿大模型的回答做战略决策不做交叉验证或者把某个 AI 产品的演示结果当成生产环境的真实效果。他们把 AI 从“工具”抬升成了“决策主体”等于放弃了管理者最基本的求证责任。1.3 为什么这个盲区以前不明显现在越来越要命过去几年信息化系统的边界很清楚上 ERP、上 CRM、做数据中台领导层通常知道自己买的是什么、解决什么问题。但 AI 不同尤其是大模型出现之后工具的边界变得模糊。一个模型既能写文案也能分析数据还能写代码甚至能扮演客服。边界模糊带来一个直接后果领导者很难判断“它到底能做到什么程度”。再加上供应商的包装和行业热词的轰炸“AI 能力”变得像一个可以随意填充的黑洞。这个盲区以前不明显是因为传统软件很少给决策者造成“它什么都懂”的错觉。而现在一个对话式界面就能让非技术人员觉得“AI 已经很成熟了”。这种错觉在管理层会议上会被不断放大最后变成不切实际的战略目标。2. 领导力盲区产生的四个现实驱动因素知道 AI psychosis 是什么还远远不够。要避免它必须搞清楚它为什么会出现。我在真实项目里观察到的驱动因素至少有四个。2.1 信息差管理层离一线太远又不敢暴露不懂这是最基础的原因。一线工程师每天都在处理 prompt、微调、评测、数据清洗、模型幻觉、上下文长度这些问题。他们知道 AI 的能力边界在哪里。但管理层往往只看到演示视频和行业报告接触不到那些琐碎、肮脏、充满 dirty work 的落地细节。按理说管理层可以直接问一线。但现实中很多管理者担心暴露自己“不懂技术”于是选择不问。不问的结果就是靠会议室的二手信息做判断。二手信息经过层层过滤往往只剩下最乐观的部分成功案例、漂亮指标、高光截图。失败案例、资源消耗、试错成本通常被选择性忽略。2.2 预算与汇报压力AI 变成了“不得不讲”的叙事第二个驱动因素来自组织内部的预算和汇报机制。很多团队发现在年度规划里写上“AI”“大模型”“智能体”这些词立项会更容易通过预算也更容易批下来。即便项目的核心问题根本不是 AI 能解决的也要硬加一个“AI 模块”。这种压力会导致两个后果。一是项目立项理由与真实需求脱节AI 成了给汇报材料镀金的道具。二是团队被迫用 AI 去解决本不该用 AI 解决的问题比如简单的规则判断非要套一个模型结果成本更高、速度更慢、还不好维护。长期看组织的 AI 项目越多真正产生业务价值的比例反而越低。2.3 供应商和热词的筛选作用新概念太多没有筛选标准AI 领域的概念更新速度太快。今天聊 RAG明天聊 Agent后天聊多模态再后来又是端侧模型、小模型、推理优化。每个新概念都配着一套新话术。供应商不会主动告诉你他们的方案在哪些场景下不适用只会不断强化“用了它就能领先”的暗示。领导者如果缺少一个稳定的筛选框架就很容易被概念牵着走。今天觉得 RAG 必须上明天觉得 Agent 是未来后天又听说某个开源模型效果更好。每一次概念切换都意味着团队要重新调研、重新测试、重新调整技术路线。到年底一看技术栈换了好几轮核心业务指标却没什么变化。2.4 组织惯性老流程与 AI 工具的节奏冲突最后一个驱动因素是组织惯性。AI 项目的推进节奏和传统软件项目很不一样。传统项目通常是需求、设计、开发、测试、上线按部就班。AI 项目则更接近“探索型”任务需要在真实数据上反复试错模型效果可能因为一个 prompt 的变化就产生明显波动评测标准也需要动态调整。如果领导者还在用传统的里程碑式管理方式要求 AI 团队就会出现节奏错配。团队可能需要两周时间做数据清洗但管理层要求第一周就拿出准确率指标。团队发现需要调整模型方案但管理层要求必须按原计划上线。这种节奏冲突一旦持续团队就会变得要么过度承诺要么消极应付。而领导者感受到的是“AI 项目不受控”进而可能进一步收紧管控形成恶性循环。3. 用一份自查清单给组织做“AI 认知体检”识别 AI psychosis最有效的方法不是靠感觉而是做一次结构化的“认知体检”。我不建议一上来就买咨询方案先自己花半天时间拉上核心负责人按下面的检查点逐项过一遍。3.1 个体层面的检查点领导者的 AI 认知是否与现实相符先看个人再看组织。以下六个问题可以作为基础检查项我能不能说出公司目前在 AI 上花了多少钱、多少人、多少时间我能不能说出一个已经上线并产生实际价值的 AI 场景我最近一次亲自查看 AI 项目的真实输出是什么时候我是否知道团队当前遇到的最大技术瓶颈是什么我有没有因为看到外部新闻或同行动态临时要求团队改变方向我在决策时更依赖一线反馈还是更依赖汇报材料和行业报告每个问题都不需要复杂回答但只要有三个以上答不上来就要警惕了。答不上来不代表你能力不行而是说明你离真实项目太远正在用想象代替事实做判断。3.2 团队与项目层面的检查点项目目标是否清晰且可验证领导者的认知会直接传导到团队。所以还需要从项目维度检查每个 AI 项目是否有一句话能讲清楚的业务目标这个目标是否能用数量、时间、成本或质量指标衡量项目是否有明确的验收标准还是“先做出来看看效果”团队是否知道什么情况下应该停止当前方案并换路项目上线后是否有持续监控和效果评估机制如果没有达到预期是否有预案如果项目目标含糊验收标准缺失那么这个项目大概率还没开始就已经在消耗组织资源了。很多团队做的不是 AI 项目而是“AI 表演项目”目标是为了证明自己做了而不是证明自己解决了问题。3.3 组织决策层面的检查点激励机制是否鼓励诚实反馈这一层最容易被忽略但也是最关键的。领导层需要检查组织是否允许员工说“AI 不适合这个场景”。现实中很多团队不敢如实汇报 AI 项目的失败因为汇报失败意味着预算可能被砍、绩效可能受影响。于是大家会包装结果准确率超过 90%但没人提那是在测试集上而不是真实数据上上线了智能客服但没人提用户满意度没有变化甚至因为答非所问而下降。如果一个组织的激励结构不允许失败反馈那么 AI psychosis 就不仅是领导者的个人认知问题而成了系统性问题。所有健康的信息都会被过滤掉剩下的全是“AI 很棒”的声音。这种状态下再多的技术投入都无法弥补决策信息的失真。3.4 信号分级与判断标准为了便于快速判断我习惯把体检结果分成三个等级等级信号特征建议动作轻度个别项目目标模糊但团队仍有主动反馈抽时间做一次项目目标梳理和验收标准补齐中度多个项目无清晰验收标准团队汇报以“进展”代替“结果”暂停新项目集中复盘存量项目补指标和失败预案重度汇报材料全是成功叙事负面反馈被压制决策只凭概念和热词先调整激励和沟通机制再造技术策略否则越投入越危险这里要注意信号分级不是用来给团队定罪的而是用来决定下一步该干什么。轻度情况只需要局部纠偏中度情况要暂停投入并进行复盘重度情况则需要从组织机制入手而不是继续加人加预算。4. 从诊断到落地把 AI 议题拉回真实业务指标诊断出问题之后最重要的事情是建立一套可落地的纠偏机制。以下四个做法是我认为在各种规模的组织里都适用的。4.1 把“要不要用 AI”改成“解决什么业务问题”这是最简单、也最容易被忽略的一步。在项目讨论中只要有“我们要不要上 AI”“别人都在做 AI我们是不是也要做”这类表述就说明讨论已经偏离了方向。更稳妥的提问方式是我们现在哪个流程最慢慢在哪里哪个环节错误率最高人工处理成本是多少有没有一种任务规则固定、重复度高、但量很大如果有一项工作能节省 30% 的时间对业务结果有什么影响先回答这些问题再决定要不要引入 AI。很多时候你会发现最合适的解决方案根本不是 AI可能只是改一下流程、优化一下数据表结构、写一个简单的规则脚本。硬上 AI 反而是最小题大做的做法。4.2 给技术负责人配一个“翻译角色”领导层不懂技术细节一线工程师又觉得管理层听不懂技术语言。这个信息差如果只用普通会议去弥合往往会变成“管理层听不太懂工程师降低表达精度结论继续走偏”。更有效的做法是让技术负责人或产品经理承担一个“翻译角色”。这个角色的任务不是写代码而是把模型效果、技术瓶颈、资源消耗、测试结果翻译成管理层能做决策的语言。翻译角色要回答的关键问题包括这个功能预计需要多少开发成本模型在什么情况下会出错发生率大概多少如果上线需要什么样的数据支持和监控机制如果要达到某个效果需要哪些前置条件当管理层能够用“成本、风险、前置条件、验收标准”来理解 AI 项目时很多想象中的焦虑和狂热都会自然消退。4.3 建立可验证的试点闭环不要跳过小规模验证很多 AI 项目失败不是因为技术选型不对而是因为没有经过小规模验证就急着全面铺开。正确的做法是先选一个边界清晰、价值可衡量的场景做试点。试点的选择标准有三条价值能算清楚比如节省了多少小时、提升了多少准确率、降低了多少成本。数据能拿到不能是“理论上我们有数据”而是当前就能导出并清洗。范围可控最多影响一个团队或一条业务线不要把整个部门都拉进来。试点周期我一般建议控制在 2 到 4 周。周期太短可能看不出真实效果周期太长又容易让团队陷入无休止的打磨。试点结束时必须输出一份包含“结果数据、失败案例、原因分析、下一步建议”的复盘记录而不是只汇报漂亮数字。4.4 用“失败预案”代替“成功承诺”重新设计决策机制很多领导者在审批 AI 项目时习惯要求团队做出某种成功承诺。这种做法表面上很理性实际上会逼着团队隐瞒风险、夸大效果。项目启动那一刻信息就已经不真实了。更好的方式是要求团队在上项目时同时提交“失败预案”。内容包括但不限于什么情况下我们判定这个方案不适用如果模型效果达不到预期我们的备选方案是什么这个项目停止后团队已有的数据、代码和积累还能复用到哪里有哪些外部信号或内部指标是表示该止损的当“停下来”和“继续做”都被纳入审批逻辑团队的反馈就会更诚实领导者的决策也更有依据。不要小看这一步它能把“表演 AI”的项目数量压下去一大截。5. 最容易踩的三个坑以及对应的纠偏动作抛开理论实际推进 AI 项目时领导层通常会踩到三个非常具体的坑。每一个我都见过不止一次下面给出对应的纠偏动作。5.1 坑一把工具能力当成组织能力这个坑非常隐蔽。很多公司引入了大模型 API找供应商做了 demo团队也跑通了几个用例于是管理层觉得“我们的 AI 能力很强”。但工具可用不等于组织具备持续使用、迭代和维护的能力。判断方法很简单问一句“如果这个 demo 要变成一个每天被内部员工使用的工具需要哪些人参与多久能响应一次需求变更模型出问题时谁能排查”如果答不上来说明组织还没有形成相应的能力。纠偏动作不要只考核“是否接入了 AI”要考核“是否具备持续运营 AI 的能力”。具体看团队是否具备数据准备、效果评测、版本迭代、异常监控四个环节中的至少两个。缺哪个补哪个不能只停留在调用接口的水平。5.2 坑二把演示效果当成生产效果供应商演示时通常使用精心挑选的输入数据工程师测试时也常常使用最干净的样例。这些输入能展示模型最好的一面但真实业务里的输入往往是脏的、乱的、模糊的、充满歧义的。一个常见的翻车场景是智能客服在演示时能流畅回答问题但在真实用户问题上经常答非所问。不是模型不够好而是真实场景的输入分布和演示场景完全不同。如果管理层只看演示结果就做上线决策大概率会得到糟糕的用户体验。纠偏动作要求团队用至少 100 条真实输入做一轮评测并输出错误案例。不需要多高深的评测体系把真实输入跑一遍把失败案例整理出来按错误类型统计就能在短时间内看清模型在真实场景中的上限。5.3 坑三把“大家都在做”当成“我们必须做”看到竞争对手上线了 AI 功能或者行业峰会上到处都在讲大模型就立刻焦虑这种情绪可以理解但它不应该成为决策依据。别人做 AI 的真实投入、真实效果、真实失败教训你通常看不到。看到的只是对外宣传的那一面。一个更冷静的提问是如果我们不做这个 AI 功能用户的哪个核心需求无法被满足如果我们不追这个大模型热点哪些业务指标会受影响如果两个问题都没有明确答案那这个项目很可能不是业务驱动而是情绪驱动。纠偏动作给所有 AI 项目增加一个“如果不做”的评审环节。项目立项时必须写清楚“不做的代价”是什么。如果代价写不出来说明这个项目在业务层面可有可无。把这一条做成硬性要求能直接过滤掉大量跟风型项目。6. 边界与常见问题别把问题全甩给“AI 认知偏差”写到这里要补充一个边界说明。AI psychosis 是一个有用的分析框架但它不是万能标签。不是所有 AI 项目失败都叫 AI psychosis也不是所有领导层的不懂技术都需要被解读为认知偏差。6.1 什么情况下不应该使用这个概念如果团队遇到的是纯技术难题比如模型效果达不到某个指标、推理速度太慢、数据质量太差这些问题属于工程问题用“管理认知偏差”去解释反而会掩盖真正的原因。另外如果组织只是暂时缺乏 AI 人才或者预算确实有限那也不是 psychosis而是资源约束问题。把资源约束问题强行归因到“领导认知有问题”只会让团队和管理层之间产生更多对立。AI psychosis 更适合描述这样一类情况技术可行、资源具备、场景也存在但决策者在“知道事实”和“做出判断”之间出现了系统性偏差。判断标准是事实清楚之后决策是否仍然明显偏离事实。6.2 常见误判与反例有一种反对意见是既然 AI 发展这么快领导者如果不激进一点会不会保守过头错过机会这个问题很现实但它和 AI psychosis 并不矛盾。AI 探索确实需要一定的乐观和冒险精神尤其是在技术早期。关键区别在于稳妥的冒险是有边界的会在投入、时间、人才上设置止损线而 psychosis 是无限的会持续追加资源同时不接受失败信号。另一个常见反例是有的项目看起来没有明确的 KPI但最终确实孵化出了有价值的能力。这种情况确实存在但它通常需要更严格的探索型项目管理机制比如独立的创新预算、阶段门评审、快速原型验证。随意立项但不能验证不能算作健康探索。6.3 领导者长期应该盯住的三个信号最后我给领导者留一个长期监控清单。不需要每天都检查但在季度复盘、重大项目立项、技术路线切换时至少看一遍一线团队是否愿意向管理层如实汇报失败案例如果这个问题答案是“不确定”或“不太愿意”组织的 AI 决策信息一定是失真的。管理层最近三次 AI 相关决策是基于具体业务指标还是基于概念热度如果大多数是后者需要立刻调整信息输入方式。团队是否过度依赖少数几个明星项目而忽视了对基础设施、数据质量、评测体系和管理机制的投入工具可以快速切换但组织能力必须稳定沉淀。这三个信号比单看“我们的 AI 项目数量”和“我们用了多少个模型”更有意义。真正决定 AI 项目成败的不是工具多先进而是整个决策链条是否始终与真实业务保持一致。回到标题那句话AI psychosis 听起来像一个新名词但它背后的问题其实早就存在人在面对还不完全理解的力量时最好的做法从来不是神化它也不是恐惧它而是给它设定清晰的问题边界、可验证的指标和体面的退出路径。领导者的职责不是成为最懂 AI 的人而是成为那个不让组织被幻觉牵着走的人。