在 AI 应用快速落地的这两年，技术社区里讨论最多的已经不再是“大模型能做什么”，而是“大模型在关键业务里用起来之后，出了问题怎么办”。很多人把注意力放在 Prompt 调优、模型部署和算力成本上，却很少认真审视一个更隐蔽的问题：团队从一线到管理层，正在对 AI 的输出产生一种“默认信任”。

这种信任一旦缺少校验机制，就会演变成组织层面的判断失灵。具体来说，当 AI 生成的结果被直接用于经营分析、客服话术、营销文案甚至代码审查，而人类只负责转发或确认时，我们就需要警惕一种叫“AI 精神病”的工程风险。

本文不讨论临床意义上的精神疾病，而是借这个说法，梳理 AI 应用系统中常见的“看似正常但不可靠”现象，以及它为什么会成为领导者新的盲区。文章会给出一个可落地的最小巡检方案，用代码和配置帮助团队把“对 AI 的信任”变成“可量化的监督”，适合正在推进大模型应用落地的技术负责人、AI 产品经理和一线开发工程师阅读。

1. 背景：AI 正在成为组织决策的“第二大脑”

1.1 从“聊天玩具”到“生产系统”

过去两年，大模型从个人聊天工具快速进入企业生产系统。现在的典型用法已经不再局限于“问一个问题”，而是：

• 基于企业知识库做智能问答；
• 自动生成周报、会议纪要和经营分析摘要；
• 在客服系统中生成用户回复话术；
• 在代码仓库里做代码审查和漏洞初筛；
• 根据用户画像生成商品文案或营销活动策划。

这些场景有一个共同特征：AI 的输出不再只是参考，而是直接进入业务流程，甚至影响到最终决策。也就是说，AI 已经从一个“辅助工具”变成了“第二大脑”。既然是大脑，就有可能产生错误认知，而错误认知如果被执行，损失就会从线上扩散到线下。

1.2 一个容易被忽略的工程异常

传统软件工程里，系统的输出是可预期、可测试的。输入相同参数，输出结果基本稳定。但大模型应用不是这样，它具备生成式能力，同一个 Prompt 在不同时间可能给出不同回答。

这种不确定性并不总是坏事，它让 AI 能处理开放性问题；但它也带来一个工程难题：如何判断输出是否“正常”。

很多团队在初期只关心“接口有没有返回”和“响应时间是否达标”，却忽略了“返回内容是否真实”“是否包含敏感信息”“是否与业务事实冲突”。于是，一些非常荒谬的生成结果就可能在无人拦截的情况下直接触达用户，被用户截图、投诉，甚至被竞争对手放大。

我把这个现象归入“AI 精神病”的范畴，因为问题不在模型本身，而在系统缺少对异常认知的识别与纠偏机制。

2. “AI 精神病”是管理问题，不是医学问题

2.1 为“AI 精神病”下一个工程定义

为了便于后续讨论，我们先给出一个工程定义：

AI 精神病是指：在 AI 应用系统中，模型输出在事实性、一致性、安全性和可控性方面出现偏差，而系统没有有效的检测与干预机制，导致偏差输出被当作正常结果继续流转。

它的核心不只是模型本身，而是“人与系统对模型输出的处理方式”。如果模型的错误答案能被人工审核拦下来，或者被规则引擎标记为低置信度，那就只是一次普通的模型误差；如果错误答案被直接发送、直接展示、直接入库，那问题就升级为系统性的工程风险。

2.2 与“AI 幻觉”有什么区别

很多人听到“AI 精神病”会直接联想到“AI 幻觉”。两者确实相关，但程度不同。

对比维度	AI 幻觉	AI 精神病
问题层面	模型层	模型层 + 应用层 + 组织层
典型表现	事实性错误、编造内容	错误被自动化流程放大并执行
检测难度	通过检索或知识库校验可以拦截	需要指标、日志、人工复核联动
责任主体	模型算法问题	流程设计和管理问题
解决思路	改进 Prompt、微调、RAG	建立监督机制、人工审核、复盘机制

简单说，幻觉是“模型说错话”，AI 精神病是“整个系统把错话当成了正确答案”。

2.3 三种典型症状

在日常项目交付中，我觉得以下三种症状最容易暴露风险。

症状一：直接引用模型生成结论，不做事实校验。
例如让 AI 生成报表解读，AI 把“同比增长 10%”写成“同比增长 20%”，业务人员直接复制到汇报材料里。缺少数字对上渠道。

症状二：缺少不确定性表达。
模型对答案并不确定时，仍然给出非常笃定的语气。比如“该方案一定是当前最优解”“这个 Bug 的根因是 XX”，如果没有置信度提示，用户会把猜测当成事实。

症状三：人工审核流于形式。
有些系统虽然设置了“人工审核”环节，但审核人面对大量 AI 输出，平均花 2 秒钟就点击通过。审核环节变成了合规摆设，起不到纠错作用。

3. 为什么它会成为领导者的能力盲区

3.1 指标看得见，质量看不见

管理者通常关注一组“健康指标”：接口可用率、平均响应延迟、用户留存率、自动回复覆盖率。这些指标能反映系统是否稳定运行，却无法反映“回答是否可靠”“内容是否违规”“结论是否误导用户”。

这就造成了领导力盲区的第一层： 只监控系统的可用性，不监控系统的可信度。

举一个常见场景。一个客服机器人的回答准确率只有 80%，但响应时间非常快，人工转接率也下降了 10%。如果只看效率指标，会觉得项目很成功；但剩余 20% 的错误回答可能已经造成了用户不满，只是这些用户大量流失后的反馈还没有体现在即时数据里。

3.2 反馈回路缺失

传统软件出现 Bug，用户会立刻在界面上看到报错，开发也能通过日志快速定位。但 AI 生成的错误往往不是“报错”，而是一段看起来通顺的文本，用户很难判断它是否正确。

更麻烦的是，用户不会每次都反馈“这个回答是错的”。大部分人会选择重新问、放弃使用或者直接离开。于是，系统缺少负反馈信号，错误会被不断学习、重复使用。

在缺少反馈回路的情况下，领导者看到的永远是“覆盖率高”“响应快”“用户没有投诉”，而真实的质量问题被沉默数据掩盖。

3.3 责任主体不清晰

当 AI 生成了一个错误的营销文案并被发布到公开渠道，责任到底算谁？

• 算模型的？模型只是按概率生成文本；
• 算产品经理？他可能只是配置了 Prompt；
• 算运营？运营可能只负责点击“发布”按钮；
• 算开发？开发没有写错代码，只是把模型输出接到了发布流程。

这种责任边界模糊，会让问题长期得不到修复。每个人都在流程里完成了一部分动作，但没有一个人对“最终输出质量”整体负责。这种情况下，领导者的管理动作容易被架空，形成第三层盲区。

4. 实战：搭建一套最简 AI 输出健康巡检系统

与其等事故发生后四处救火，不如先搭建一套最小可用的输出健康巡检系统。下面这套方案不需要引入重量级平台，用 Python 脚本加配置文件就能跑起来，适合团队快速验证“AI 输出是否存在风险”。

4.1 环境准备与目标

本文示例运行环境如下：

• Python 3.10+；
• 不需要额外安装第三方库，仅使用标准库；
• 需要一个存放样本数据的 JSON 文件。

系统目标有三个：

1. 对每一条 AI 输出计算一个“风险分”；
2. 根据风险分自动标记“需要通过、建议复核、必须拦截”；
3. 输出结果可汇总成报表，供管理者和开发人员查看。

4.2 项目结构

建议按下面的目录结构组织文件：

ai-healthcheck/
├── ai_output_healthcheck.py   # 主脚本
├── config.yaml                # 风险阈值配置
├── samples.json               # 待检测的 AI 输出样本
└── README.md                  # 使用说明

如果团队使用 Java 或 Go 技术栈，代码思路也可以直接平移，核心逻辑是相同的。

4.3 数据样本设计

我们先准备几个示例样本。实际使用时，可以把这些样本替换成线上 AI 接口的返回内容。

[
    {
        "id": "sample-001",
        "scene": "客服自动回答",
        "text": "根据您的问题，我们建议您尝试重启设备。如果仍无法解决，请提供更多信息。"
    },
    {
        "id": "sample-002",
        "scene": "营销文案生成",
        "text": "这款产品大概率能帮助您提升效率，据说能提升30%以上，应该是目前最好的方案。"
    },
    {
        "id": "sample-003",
        "scene": "经营分析报告",
        "text": "本季度营收同比增长约12%，主要原因是新产品线放量。但报告中未提供原始数据来源。"
    }
]

在正式环境里，样本可以来自线上日志抽样，也可以来自人工标注的风险案例。建议至少准备 100 条以上，避免偶然性。

4.4 编写巡检脚本

下面是一个最简版本的 Python 脚本。它会读取 JSON 文件，然后按照规则检查文本。

# 文件路径：ai-healthcheck/ai_output_healthcheck.py
import json
import sys
import re
from collections import Counter

# 不确定表达关键词
UNCERTAINTY_KEYWORDS = [
    "我不清楚", "可能", "也许", "貌似", "据说",
    "大概率", "应该是", "大概", "估计", "猜测"
]

# 敏感信息正则
SENSITIVE_PATTERNS = [
    (r"1[3-9]\d{9}", "疑似手机号"),
    (r"\d{15,19}", "疑似银行卡号"),
]

def load_samples(path: str):
    """读取样本 JSON 文件。"""
    with open(path, "r", encoding="utf-8") as f:
        return json.load(f)

def calc_risk_score(text: str):
    """
    计算单条文本的风险分。
    这里以简单规则为例，实际生产场景可以替换为更加精细的模型评估。
    """
    score = 0
    issues = []

    if not text or len(text.strip()) < 10:
        score += 10
        issues.append("text_empty_or_too_short")

    hit_keywords = [w for w in UNCERTAINTY_KEYWORDS if w in text]
    if hit_keywords:
        score += len(hit_keywords) * 2
        issues.append({"type": "uncertainty_keywords", "detail": hit_keywords})

    for pattern, desc in SENSITIVE_PATTERNS:
        if re.search(pattern, text):
            score += 10
            issues.append({"type": "sensitive_data", "detail": desc})

    # 字符多样性检查：如果文本大量重复，可能是模型复读
    if len(text) > 10:
        diversity = len(set(text)) / len(text)
        if diversity < 0.2:
            score += 4
            issues.append("low_char_diversity")

    return score, issues

def main():
    if len(sys.argv) < 2:
        print("用法: python ai_output_healthcheck.py samples.json")
        sys.exit(1)

    samples = load_samples(sys.argv[1])
    print(f"共读取 {len(samples)} 条样本\n")

    for item in samples:
        text = item.get("text", "")
        score, issues = calc_risk_score(text)
        level = "通过"
        if score >= 8:
            level = "必须拦截"
        elif score >= 4:
            level = "建议复核"

        print(f"[{item.get('id')}] 场景: {item.get('scene')}")
        print(f"风险分: {score}, 处理建议: {level}")
        print(f"风险项: {issues}")
        print("-" * 50)

if __name__ == "__main__":
    main()

脚本逻辑说明：

• uncertainty_keywords 检查文本中是否有不确定表达。AI 在不知道答案时，如果给出“大概率”“应该”这类词，说明它可能并不确定，需要人工谨慎对待。
• sensitive_patterns 检查文本中是否包含手机号、银行卡号等敏感信息，防止模型输出数据泄露。
• low_char_diversity 是一个简单的“是否在复读”的信号，用于发现模型陷入重复生成的异常状态。

这只是一个示例框架，并不代表线上最佳规则。真实项目需要根据业务场景自定义关键词和正则表达式。

4.5 配置风险阈值

为了让业务人员也可以调整规则，我们可以把风险阈值放到配置文件里。

# 文件路径：ai-healthcheck/config.yaml
risk_rules:
  uncertainty_keywords:
    - "我不清楚"
    - "可能"
    - "也许"
    - "据说"
    - "大概率"
    - "应该是"
    - "大概"
    - "有点"
    - "猜测"
    - "估计"

  sensitive_patterns:
    - pattern: "1[3-9]\\d{9}"
      desc: "疑似手机号"
    - pattern: "\\d{15,19}"
      desc: "疑似银行卡号"

  thresholds:
    auto_pass: 3
    suggest_review: 7
    block: 8

  human_review:
    enabled: true
    max_review_per_day: 200

这里说明一下阈值设计的思路：

• 风险分 0 到 3：可视为正常输出，自动放行；
• 风险分 4 到 7：建议人工抽样复核；
• 风险分 8 及以上：必须拦截，不允许直接发布。

阈值不是固定的。团队上线初期可以放宽，先积攒数据；运行稳定后再逐步收紧。不要一开始就追求“百分之百拦截”，否则会产生大量误报，反而降低人工审核效率。

4.6 运行与结果解读

在命令行执行：

cd ai-healthcheck
python ai_output_healthcheck.py samples.json

预期输出大致如下：

共读取 3 条样本

[sample-001] 场景: 客服自动回答
风险分: 0, 处理建议: 通过
风险项: []
--------------------------------------------------
[sample-002] 场景: 营销文案生成
风险分: 8, 处理建议: 必须拦截
风险项: [{'type': 'uncertainty_keywords', 'detail': ['大概率', '据说', '应该']}]
--------------------------------------------------
[sample-003] 场景: 经营分析报告
风险分: 2, 处理建议: 通过
风险项: []

从这个结果可以看出， sample-002 被拦截，是因为文本中出现了“大概率”“据说”“应该”等不确定表达。这类内容如果直接作为营销文案发布，有被判定为虚假宣传的风险，所以需要人工重新撰写，或者补充数据来源。

5. 把技术指标变成领导力仪表盘

5.1 建议关注的核心指标

巡检脚本运行之后，我们还需要把结果汇总成管理指标，否则领导者依然看不到全局。

建议每周统计以下指标：

指标名称	计算公式	说明
输出风险率	风险分 ≥ 4 的样本数 / 总样本数	反映整体质量水位
人工复核率	实际人工复核数 / 应复核数	反映审核流程是否认真执行
拦截命中率	被拦截且确实有问题的数量 / 被拦截总数	反映规则是否合理
误报率	被拦截但实际正常的数量 / 被拦截总数	过高说明规则太严格
反馈闭环率	进入复核流程并完成问题修复的数量 / 拦截总数	反映问题是否真正被解决

这些指标不需要全部做成复杂系统。借助 Excel 或者一个简单的报表页面就能实现。

5.2 报表示例

下面是一张模拟的周报模板：

AI 输出质量周报
本周统计周期：2025-06-02 至 2025-06-08
线上调用总量：120,000 次
抽样检测样本：1,200 条

风险分分布：
0-3 分（自动通过）：1,020 条，85.0%
4-7 分（建议复核）：150 条，12.5%
8 分以上（必须拦截）：30 条，2.5%

人工复核情况：
应复核：150 条
实际完成：120 条
闭环修复：18 条

结论：本周风险拦截率 2.5%，反馈闭环率 15%，仍有提升空间。

管理者看到这张表后，重点不应该只看“通过率”，而要看“闭环修复率”。如果拦截了很多问题却没有后续修复动作，说明团队缺少治理机制。

5.3 管理层动作建议

领导层拿到指标后，需要避免两种极端：

1. 分数焦虑 ：看到风险率升高就要求“全面禁用 AI”；
2. 分数乐观 ：看到通过率 95% 就认为“系统很安全”。

建议的做法是： 关注趋势，而不是单周数值 。如果连续三周“人工复核率”下降，但“输出风险率”上升，说明审核端出现了漏洞，需要增加人力或优化规则。

另外，建议每月抽一次“极端案例复盘”，挑出 2 到 3 个典型 AI 输出错误，分析它的产生链条：是 Prompt 问题、知识库问题、还是流程缺失？这样的复盘比单纯盯指标更有价值。

6. 常见问题与排查思路

在实际使用过程中，团队会遇到一些典型问题。下面给出一个速查表。

问题现象	常见原因	解决思路
脚本运行报错 “FileNotFoundError”	没有把 samples.json 放在当前目录	确认路径是否正确，或使用绝对路径
风险分偏高，大量样本被拦截	关键词表太宽泛，误伤正常表达	减少不确定性关键词，增加白名单
风险分偏低，真实问题漏掉	规则只覆盖表面文本，未覆盖语义	升级为模型评估或检索比对方案
人工复核率低	审核任务量大，操作不便捷	设置审核 SLA，简化审核界面
拦截后没有后续动作	缺少责任分配和跟踪机制	将拦截记录转化成待办任务
输出包含敏感信息但未发现	仅靠正则无法覆盖复杂数据	接入敏感数据检测服务或人工抽检

如果出现大量误报，不要急着上调阈值，要先检查关键词表。举个例子：“这个方案可能适合您的需求”是一句正常表达，但如果系统把“可能”也当作高风险词，就会频繁误报。我们需要根据真实业务语料不断调整规则。

如果出现漏报，优先考虑引入检索知识库做事实校验。例如，让模型回答“2024 年公司营收是多少”，系统可以先从数据库或文档里检索出正确数字，再与模型输出做比对。这条路比单纯堆关键词更可靠。

7. 最佳实践与工程建议

7.1 四条防线

要让 AI 应用稳定可控，建议在架构上设置四道防线。

第一道防线：Prompt 约束。 在系统提示词中增加“不确定性说明要求”，让模型在不确定时主动说明。

你是一个企业知识助手。如果无法从给定资料中找到准确答案，请直接回复“资料中没有找到相关信息”，不要编造数据。回答中如果包含推测内容，必须使用“推测”字样。

第二道防线：输出过滤。 通过规则引擎检测文本中的不确定性关键词、敏感信息、重复内容，对应前面的巡检脚本。

第三道防线：人工审核。 对于高风险场景（金融、医疗、法务、营销），必须在发布前设置人工审核环节，并且审核记录需要留痕。

第四道防线：事后复盘。 定期抽取线上输出错误样本，重新应用到巡检规则中，形成闭环。

7.2 日志与责任追踪

凡是 AI 输出进入生产流程，至少要记录以下字段：

• 请求 ID；
• 用户 ID；
• 场景名称；
• Prompt 版本号；
• 模型版本号；
• 原始输出内容；
• 风险分；
• 审核人；
• 拦截或放行结果；
• 修复备注。

记录这些字段的意义在于：当问题发生时，我们可以准确回答“哪条输出，用了哪个 Prompt，由谁审核，为什么发布”。没有日志，就没有完整的责任闭环。

7.3 敏感信息与权限边界

涉及敏感信息时，建议遵循最小权限原则。具体来说：

• AI 系统默认不读取和输出个人隐私字段；
• 如果需要读取，必须设置严格的权限控制；
• 对输出结果做敏感信息掩码处理；
• 禁止将内部数据直接拼接到明文 Prompt 中。

另外，所有涉及生产环境的数据处理，都应在测试环境验证通过后再上线，并且在变更前做好备份。

7.4 落地节奏建议

建议按照“三步走”推进：

1. 第一步：先跑规则。 用本章节的最小脚本搭好基础能力，收集 2 到 4 周数据；
2. 第二步：再补质检。 根据数据情况优化规则，增加模型评估或知识库校验；
3. 第三步：最后建制度。 明确责任人、审核流程、复盘机制，把技术能力转化为管理制度。

不要试图一步到位建设一个“AI 监管平台”，那样成本高，且不确定性强。先让数据说话，再逐步完善。

8. 总结与下一步学习路线

本文从一个容易被忽略的现象出发，把“AI 精神病”定义为 AI 输出进入生产流程后，系统缺少校验和纠偏机制所导致的管理风险。我们讨论了三层盲区：指标盲区、反馈盲区、责任盲区，并通过一个 Python 巡检脚本演示了如何对 AI 输出进行风险打分和拦截。

下一步，你可以做三件事：

1. 把脚本中的关键词和正则替换成自己业务的真实案例，跑一批历史数据；
2. 根据巡检结果，梳理近期上线 AI 功能最容易出错的场景；
3. 在团队周会上增加一项“AI 输出质量周报”，让问题从隐蔽走向透明。

AI 的能力边界仍然在拓展，但工程化的底线是：它可以帮助我们判断，但不能替代我们负责。真正成熟的团队，不是对 AI 完全信任，也不是完全怀疑，而是建立一套可量化、可追溯、可改进的信任机制。

先把最小巡检系统跑起来，你就已经领先大多数团队了。