今年上半年我陆陆续续和十几位负责 AI 落地的技术负责人聊过同一个话题你们最担心的风险是什么答案出乎意料地一致——不是模型能力不够不是算力成本太高也不是缺乏应用场景而是团队开始无脑信任 AI 的输出。有人把大模型生成的错误数据直接写进了周报有人让 AI 自动回复了客户投诉邮件然后又生成了一个看起来很有道理的道歉还有人基于 AI 的面试评价真的发了一封拒信。更麻烦的是这些动作在发生时几乎没有人觉得有问题。大家都默认了一个前提AI 给出来的东西应该是对的。我把这种现象称为AI psychosisAI 精神病态。它不是指某个模型出了故障而是指一个组织——从管理者到执行层——在不知不觉中建立了一套“AI 输出默认正确”的决策机制。这是当前 AI 落地过程中最隐蔽也最危险的一个领导力盲区。这篇文章不是来说教的更不是要劝大家放弃 AI。相反我认为 AI 能带来的效率提升是实实在在的。但技术负责人要想避免翻车就必须先看清这个盲区是怎么形成的然后在工程层面和组织层面同时建立防线。后面我会给出判断依据、可落地的审查机制、最小示例代码以及一套可以直接抄走的排查清单。1. 先定义清楚AI psychosis 到底是什么关于“AI psychosis”这个词目前并没有一个严格的学术定义。在技术语境里它更多是一种比喻用来描述当 AI 输出被大规模、无差别地采信时组织逐渐丧失对信息真实性的判断力。从技术层面拆解它至少包含三个递进的现象。第一个现象是“AI 幻觉”。这是大模型的已知缺陷指模型生成了一段流畅、自信、但事实上错误的内容。幻觉不是 bug而是当前语言模型的工作方式决定的。第二个现象是“AI 灌装”AI slop。指组织内部大量出现由 AI 生成、但没有人真正复核的中低质量内容。这些内容看起来格式工整、逻辑通顺但细节经不起推敲。它们会进入文档库、知识库、邮件、周报甚至产品代码里形成事实地层。第三个现象是“自动决策疲劳”。当 AI 承担了越来越多的事实核查、初步判断、客户回复甚至代码审查工作人的警觉性会逐步下降。管理者看到 AI 给出的结论越来越“合理”就会越来越不愿意花时间做二次验证。这三个现象叠加结果就是一个组织开始在错误的事实上做正确的决策。这可能比模型崩溃更可怕。模型崩溃你能发现系统不可用你能报警但一份语法完美、逻辑自洽、唯独关键数字完全错误的 AI 报告会在组织内部流传很久直到某个环节因此产生真实损失。这里要特别强调AI psychosis 不是技术故障而是治理问题。它发生在模型输出进入人类决策流程之后。所以解决它的手段不能只在模型层更要在流程层和权限层。2. 为什么大模型会“自信地胡说”技术机制不可回避要设计防线先得理解模型为什么会产生幻觉。很多管理者把幻觉当成“偶尔出错”但实际上幻觉是由大模型的生成机制决定的无法被彻底消除只能被约束和检测。大模型本质上是一个“依据统计规律预测下一个 token 的机器”。在生成回复时它做的不是查数据库也不是执行规则而是从训练时学到的概率分布里采样一段最合适的文本。这个机制有两个直接后果。第一模型没有内置“我知道自己不知道”的能力。它只会根据上下文生成一个看起来最合理的续写至于这段续写是否对应现实世界的事实模型内部其实没有验证通道。当训练数据里关于某个问题的信息不足、过时或者互相矛盾时模型多数情况下不会说“我不确定”而是会编造一个最通顺的答案。在信息缺失时通顺往往比正确更容易做到。第二模型的优化目标是“让人类满意”而不是“精确匹配事实”。在 RLHF基于人类反馈的强化学习阶段模型会被调整得更顺从、更有帮助。一个直接副作用就是当模型无法判断正确性时“给出一个自信的答案”比“承认不知道”更容易获得人类评分者的好感。这不是模型的责任而是训练目标带来的偏差。所以从工程角度看一个只靠“提示词”无法根治幻觉的模型在一个允许它直接输出给用户的业务系统里本质上就是一杆没上保险的枪。你只能通过技术手段把发生伤害的概率压低压到可控范围。3. 组织里最典型的三种 AI 精神病态表现3.1 数字幻觉看起来精确实际全错大模型对数字的处理能力非常不稳定。它擅长生成看起来很专业的统计格式比如“同比增长 17.3%”“用户满意度达到 92.1%”但这些数字往往没有任何数据源支撑。真相是模型只是根据训练数据里的常见模式拼凑出一组看起来合理的数字。如果一位管理者在周会上看到了格式完整、来源不明的统计数据并把它当成真实业务数据带入决策这就成了典型的 AI 精神病态。更麻烦的是AI 生成的数字通常比人工编造的数字更精致它自带“因为所以”的推理链让人很难立刻反驳。3.2 事实幻觉编造案例、客户和引用我曾见过一个团队在做竞品分析时用 AI 生成了报告里面详细描述了一个“竞品最近刚刚上线的功能”。后来联系对方公司才发现这个功能根本不存在。这种情形的危害不在于“出错”而在于出错的方式。错误信息混在结构完整、表述专业的框架里识别成本极高。哪怕中间有明确标注“本报告由 AI 辅助生成”也没有谁会逐条去核实每一段话。3.3 自我强化的反馈循环当 AI 生成的内容进入组织的知识库再被另一个 AI 系统当作训练语料或检索资料时第二轮的输出会把错误进一步放大。这不是科幻电影而是已经在发生的事有人用 AI 生成技术方案方案被同事复述进文档文档又被人用 RAG检索增强生成系统当作权威知识源喂给下一个 AI于是模型对错误信息的置信度反而升高了。在这种循环里错误不是一次性的而是不断沉淀、反复引用的。组织的“事实底座”开始由 AI 的生成结果——而不是真实业务事件——来填充。4. 为什么这成了一个领导力盲区而不是普通技术问题传统软件工程能治理掉大量故障是因为我们有变更控制、代码审查、灰度发布和回滚机制。核心逻辑是任何修改进入生产环境前必须经过可验证的审批环节。AI 的引入破坏了这条链路。原因在于AI 系统的“变更”发生得非常分散而且很难被定义为一个可回滚的版本。举个例子。传统下发一条优惠券规则要走配置审批改完有版本号上线后有监控。但 AI Agent 在回答用户“当前有哪些优惠活动”时可能会自己从知识库里挑选一段描述再补充一些它推测的细节组合成一个看起来不错的回答。过程中没有任何人下达“修改规则”的指令可系统的实际行为已经变了而且这个变化是不可预测的。管理者面临的问题是他们过去擅长的审查手段全都建立在“对象可以被明确标识、可以被版本化”的前提上。而 AI 输出的内容恰恰是动态生成、逻辑各异、无明显版本边界的。于是管理者很容易出现两种极端反应要么过度信任 AI 的“平均正确率”要么走另一个极端干脆禁用 AI。过度信任等于把决策权悄悄交给了概率模型全面禁用等于拒绝了效率红利。真正的领导力是在两者之间建立一套针对 AI 输出的新型审查机制。这套机制不要求管理者变成模型专家但必须督促团队建起四个东西高质量的知识边界、可靠的事实核查节点、可观测的日志链路、以及人工抽检制度。下面逐个拆解。5. 工程侧防线用可控约束和人工节点给 AI 系上安全带5.1 知识边界尽量让 AI 回答“有参考答案”的问题实践中最有效的幻觉抑制手段不是更长的提示词而是用 RAG 把一个“事实狭窄但可靠”的知识库交给模型。当模型被强制在给定文档里找答案时它编造的空间会小很多。这里需要明确一个原则让 AI 负责组织语言不要让 AI 负责创造事实。事实必须来自检索到的文档语言组织可以交给模型。关键操作是为每个知识片段加上源标识例如文档 ID、段落编号或更新时间。为了便于理解我写一个最小示例演示“无 RAG 的空白回答”和“有 RAG 的受限回答”之间的差异。以下代码使用 Python 和 OpenAI SDK 风格的接口实际项目以你使用的 SDK 为准。# 文件路径rag_demo.py from openai import OpenAI client OpenAI() knowledge_base [ { source: 内部产品手册 v2.3, content: 企业版套餐付费后支持 90 天无理由退款但仅限尚未超出上传流量配额的用户。, }, { source: 内部客服手册 v1.8, content: 退款请求需在 48 个工作小时内处理超过时限需升级至值班负责人。, }, ] def retrieve(query: str) - str: # 这里简化检索逻辑实际项目建议用向量检索 for doc in knowledge_base: if 退款 in query or 退 in query: return doc[content] return def ask_without_rag(prompt: str) - str: response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], ) return response.choices[0].message.content def ask_with_rag(prompt: str) - str: context retrieve(prompt) system_prompt ( 你是一个客服助手。只能根据以下内部资料回答问题。 如果资料中找不到答案请直接回答未找到相关资料请转人工处理。\n f内部资料\n{context} ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: prompt}, ], ) return response.choices[0].message.content question 企业版套餐可以退款吗退款额度是多少 print( 无 RAG 回复 ) print(ask_without_rag(question)) print() print( 有 RAG 回复 ) print(ask_with_rag(question))这段代码的核心逻辑并不复杂。ask_without_rag让模型自由发挥它很可能编出“退款额度不超过订单金额的 80%”一类没有出处的规则。ask_with_rag则把内部手册内容直接放进系统提示词并要求模型“资料中没有就转人工”把生成的自由度约束在可控范围内。在没有 RAG 的情况下如果模型没有在训练数据里见过贵公司的退款政策它大概率会编一个看起来合理的政策。而在有 RAG 的情况下模型至少会引用你给定的原文即使它换了一种说法事实依据也基本可控。不过要注意RAG 不是万能药。如果检索到的资料本身过时或者检索命中错误文档模型同样会把错误信息当作权威来源。所以 RAG 的质量取决于知识库的维护质量而不是单纯的技术选型。5.2 引入事实核查节点在关键输出上强制附加验证RAG 能抑制一部分幻觉但不能拦截所有错误。尤其当 AI 生成的是代码、数据摘要或客户回复时你需要额外的规则层。以代码生成为例现在不少团队已经接受 AI 生成的代码直接进入代码库。但如果没有强制约束AI 写出来的代码很可能包含不存在的 API、错误的算法逻辑或者安全隐患。一个折中方案是所有 AI 生成的代码必须通过静态检查和必要的单测才能进入人工审查环节。静态检查和单测在这里不是形式而是把“AI 的自信”翻译成“可持续验证的客观证据”。再以数据摘要为例如果 AI 要基于业务数据生成报表最稳妥的方案是让 AI 生成 SQL 语句而不是让 AI 直接生成最终数字。SQL 可以被单独执行和核对执行结果才是权威数字AI 只负责写查询逻辑不负责创造统计值。# 文件路径guardrail.py import re def check_for_placeholder_number(text: str) - bool: 检测文本是否包含模型可能编造的百分比数字 # 示例规则数字后紧跟百分号需要人工复核 return bool(re.search(r\d(\.\d)?%, text)) def filter_output(text: str) - str: # 如果检测到数字强制追加复核提示 if check_for_placeholder_number(text): text \n\n[注意] 以上数字结果需要进行人工复核后方可对外发布。 return text这种规则层不需要很复杂它的作用是打破“模型输出即终稿”的惯性。只要有明确的复核点存在管理者至少有机会在看到数字时多问一句“这个数怎么来的”。5.3 可观测性让 AI 的每一次决策都能被追溯组织和领导层面最需要补的是对 AI 决策路径的观察能力。传统系统通过日志和监控能回答“发生了什么”AI 系统不仅要回答这个还要回答“它为什么这么说”。在技术层面建议至少记录三件事第一输入信息。用户指令、模型版本、检索到的知识片段、上下文窗口内容。第二输出结果。全文内容、敏感信息标记、规则层是否触发。第三抽检结果。人工或自动评估员是否复核过复核结论是什么。下面的代码演示了一个简化的审计日志记录示例。# 文件路径audit_log.py import json import datetime def record_ai_call( user_prompt: str, context_sources: list, model_output: str, review_status: str none, ) - dict: log_entry { timestamp: datetime.datetime.now().isoformat(), user_prompt_hash: str(hash(user_prompt)), context_sources: context_sources, model_output: model_output, review_status: review_status, } with open(ai_audit_log.jsonl, a, encodingutf-8) as f: f.write(json.dumps(log_entry, ensure_asciiFalse) \n) return log_entry if __name__ __main__: record_ai_call( user_prompt企业版套餐可以退款吗, context_sources[内部产品手册 v2.3], model_output企业版套餐付费后支持 90 天无理由退款但仅限尚未超出上传流量配额的用户。, review_statuspending, ) print(审计日志已写入 ai_audit_log.jsonl)有了日志后续的问题排查才有依据。如果某条 AI 回复引发投诉你可以快速回溯它参考了哪些文档用了哪个模型版本当时有没有规则触发有没有人工复核记录。没有这些日志你只能两手一摊说“这个我也不知道它是怎么想的”。6. 完整示例为 AI 客服系统加上三重防线前面说的内容比较分散这里我把它们组合起来给出一个可运行的 AI 客服系统的简化架构示例。这个示例不是生产级代码而是用来展示三件事检索约束、规则拦截、人工复核回调。# 文件路径customer_service_demo.py import json from openai import OpenAI client OpenAI() knowledge_base { refund: { doc_id: KB-001, content: 企业版套餐付费后支持 90 天无理由退款但仅限尚未超出上传流量配额的用户。, }, invoice: { doc_id: KB-002, content: 发票通常在企业版套餐支付成功后 7 个工作日内开具支持电子发票和纸质发票。, }, } def retrieve_docs(query: str): if 退款 in query: return [knowledge_base[refund]] if 发票 in query: return [knowledge_base[invoice]] return [] def guard_check(text: str) - list: alerts [] if in text or ; in text: alerts.append(检测到疑似 SQL 注入字符建议转人工) if 100% in text or 永远 in text or 绝对 in text: alerts.append(检测到绝对化表述请人工复核) return alerts def reply_with_pipeline(query: str): sources retrieve_docs(query) if not sources: return { final_reply: 未找到相关资料请转人工处理。, sources: [], alerts: [], needs_human: True, } context \n.join([doc[content] for doc in sources]) system_prompt ( 你是一个企业客服助手。只能根据以下内部资料回答不得补充资料之外的规则。\n f资料\n{context} ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: query}, ], ) raw response.choices[0].message.content alerts guard_check(raw) needs_human len(sources) 0 and len(alerts) 0 return { final_reply: raw (\n\n[提示] 该回答命中风险规则已同步给人工客服。,) if needs_human else raw, sources: [doc[doc_id] for doc in sources], alerts: alerts, needs_human: needs_human, } if __name__ __main__: question 企业版套餐可以退款吗之前有人说发票也要一起处理。 result reply_with_pipeline(question) print(json.dumps(result, ensure_asciiFalse, indent2))运行这个脚本后你会看到一个结构化的返回结果包含最终回复、命中的知识库文档 ID、风险预警列表以及是否需要人工介入的标记。这个结构本身就是对“AI 输出默认正确”的最佳抵抗。你可以看到这里真正有价值的不是某一行代码而是它背后体现的流程设计AI 生成内容规则层拦截风险技术手段不足以兜底时就把问题交回给人。7. 运行结果与效果验证以customer_service_demo.py为例预期你会看到类似这样的 JSON 输出具体模型输出可能不同但结构一致{ final_reply: 根据内部资料企业版套餐用户可以在付费后 90 天内申请无理由退款但需确保尚未超出上传流量配额。发票处理与退款流程相互独立如需发票可联系客服单独处理。, sources: [ KB-001, KB-002 ], alerts: [], needs_human: false }如果查询内容包含绝对化词汇比如“有没有绝对不被封号的方法”guard_check会命中“绝对”关键词needs_human会被置为true提醒人工介入。这个机制可以让管理者和开发者在验证阶段就确认AI 的输出不是直接对外发布而是经过了一层可观察、可干预的管道。如果你运行后遇到问题有几点可以参考第一确保 Python 环境和 SDK 的版本兼容。代码里的openai库以及client.chat.completions.create调用以官方最新 SDK 为准如果接口有调整先查文档再运行。第二确认模型有权限调用。如果使用公司内部部署的模型需要把base_url等参数配置好回调地址和密钥也要核对。第三如果返回结果里没有sources请检查retrieve_docs里的中文匹配逻辑。中文关键字匹配在真实场景里不可靠建议替换为更健壮的检索方案比如基于向量数据库的语义检索。8. 常见问题与排查思路问题现象可能原因排查方式解决方案AI 回复依然出现明显幻觉知识库内容缺失或检索命中错误检查命中的文档 ID 和相关性扩充、更新知识库优化检索排序在 prompt 中约束“查不到就转人工”规则层过度拦截正常内容正则规则过于宽泛查看审计日志中 rule 命中记录缩小规则范围增加白名单对规则做 A/B 测试人工复核环节形同虚设流程上没有强制推动统计抽检率检查每个环境的状态设置自动抽检比例超过阈值自动提醒负责人新增“必须人工确认”的节点模型在输出中给出错误引用训练数据中不存在该引用RAG 检索未命中核实检索内容确认引用是否来自知识库强制要求模型只引用给定文档不在 prompt 之外开放自由引用团队对 AI 输出盲目信任缺乏“复核”意识抽查典型错误案例作为内部分享建立“AI 输出可信度”培训让成员清楚 AI 生成内容的边界如果团队在实践一段时间后发现错误率依然很高我建议优先检查两件事一是知识库是否有专人维护二是审计日志是否真的有人在看。工具做得再好如果组织流程上没有支撑它也只是摆设。9. 工程侧之外的领导力动作之前讲的都是工程手段但 AI psychosis 本质上是组织问题所以领导层还需要做三件“非技术”的事情。第一件事明确划定 AI 的决策边界。在哪些场景下 AI 可以自动执行在哪些场景下必须有人工审批应该被写成书面规则而不是靠团队成员各自判断。比如“AI 生成的客户回复只能作为草稿”“AI 生成的代码必须通过 CI 和人工审查才能合并”这类边界越清晰出事的概率越低。第二件事建立一个真实的错误案例库。很多团队把 AI 跑起来之后只关注准确率指标却忽略了对错误样本的收集和复盘。建议每周抽一次线上或测试环境的 AI 输出挑选几个典型错误组织团队一起讨论错误为什么发生哪条链路没拦住怎么补。错误库的价值不是惩罚模型而是帮助组织建立对 AI 局限性的共同认知。第三件事重新定义 KPI。如果团队的目标只是“AI 回答的数量”那么大家会自然地倾向于让 AI 多答、快答而不关心回答的质量。建议在指标里加入“需要人工介入的比例”“人工复核后的修正率”“高置信错误数”等质量指标因为当质量被量化时它才会被管理。10. 给不同角色的建议技术负责人和架构师重点做两件事。第一把 AI 系统当成一种新的“外部依赖”来治理给它加上可观测性、权限控制和审计日志第二主动向上级和管理层解释 AI 的能力边界让决策者明白 AI 输出不是天然可信的。产品经理和业务负责人重点做一件事在所有 AI 生成内容的界面上设计好用户预期。不是所有内容都要标注“AI 生成”但高风险场景——比如医疗建议、法律建议、财务数据、客户承诺——必须给用户一个明确的“仅供参考”或“人工审核”的提示。普通开发者最需要做的是改变自己的默认思维。拿到 AI 生成的代码时先问三个问题这段代码依赖的 API 存在吗它的边界条件覆盖了吗它在真实数据上能跑吗把这三个问题的答案写进 PR 描述里而不是直接把 AI 输出复制粘贴。11. 总结真正该警惕的不是 AI而是被放大的“信任惯性”AI 的幻觉问题会一直存在但一个组织如果能把 AI 输出的验证环节、可观测性和人工审查节点建立起来幻觉造成的实际损失是可以被压到很低的。真正的风险在于当 AI 的生成能力越来越像人组织的信任惯性也会越来越大。管理者会逐渐忘记追问数据的来源程序员会逐渐忘记验证代码的逻辑客服主管会逐渐默认 AI 已经把客户安抚好了。回归到开头的那个判断AI psychosis 是新出现的领导力盲区不是技术缺陷。应对它的方式不是抵制 AI而是用工程手段给组织装上“冷静装置”——让 AI 告诉我们它有多确定让我们自己决定要不要采信它。这份警觉需要从每一个用到 AI 输出的人做起。希望这篇文章里的框架、代码和排查清单能帮你和你的团队少踩一些坑。建议先挑一个风险最高的业务场景把最小防线搭起来跑通流程再逐步扩展。这样比空谈“AI 治理”要实用得多。