Box CEO Aaron Levie 最近在公开场合给科技圈高管群体下了一个诊断：AI 精神病（AI psychosis）。症状很典型——离一线越远，越觉得 AI 无所不能；离键盘越近，越知道每个百分点提升背后要填多少坑。
这不是一句玩笑。当董事会要求"全面 AI 化"，当竞对发布会上的 demo 让 C-suite 觉得落后一个时代，一种独特的认知偏差就悄悄接管了决策层：用"太大太远"的视角规划落地，用愿景代替验证。
症状清单：你身边可能已经有人发病
Levie 描述的"AI 精神病"有几条可识别的临床表现：
- 把 demo 当产品。看到 GPT 流畅对话，就认为客服系统可以明天切换；看到生成式设计，就要求工程团队下周产出。
- 用投资人的语气谈技术。"AI 将重塑一切"是路演话术，不是技术判断。重塑需要数据管道、评估体系、容错边界、合规审查——这些在幻灯片上不存在。
- 跳过中间态。从"手动流程"直接跳到"AI 全自动"，中间的半自动化、人机协作、渐进替换阶段被一笔带过。结果是系统要么不敢上线，要么上线后事故频出。
- 低估隐性成本。推理费用、延迟、幻觉率、数据清洗、标注人力、模型迭代——这些在 CEO 的脑中权重为零，在工程师的排期里占 80%。
核心机制只有一个：距离一线越远，对"落地难度"的感知就越失真。 这和当年"云精神病""微服务精神病"如出一辙——新技术让决策者兴奋，让实施者头秃。
为什么一线工程师反而更"保守"
不是工程师缺乏想象力，而是他们每天都在和失败率打交道。
一个 CEO 说"AI 将自动处理 90% 的客服工单"，他看到的是节省的人力成本。一个工程师看到的是：10% 的工单会出幻觉、5% 会引用过期政策、3% 会把投诉升级成公关事故——而这些需要人逐条兜底。
保守不是抗拒，是对误差分布的直觉。你跑过一次评估就知道：模型在 benchmark 上 95% 准确率，到了真实业务数据上可能掉到 70%，而那 30% 的失败案例恰好集中在最敏感的客户群体上。
落地难度评估：一个可以跑的框架
对抗"AI 精神病"的方法不是少想，而是多量。下面是一个 Python 脚本，用来对任意业务流程做结构化的 AI 落地难度评估——把模糊的"能不能做"拆成可量化、可追踪的维度。
#!/usr/bin/env python3
"""
ai_readiness_assessment.py — AI 落地难度评估工具
用法:
python ai_readiness_assessment.py
根据提示逐项输入评分（1-5），输出各维度得分和综合评估。
1 = 极难/极差，5 = 极易/极好
"""
import json
from dataclasses import dataclass, asdict
DIMENSIONS = {
"data_quality": "数据质量：数据是否干净、结构化、有标注？",
"task_determinism": "任务确定性：输出是否有明确对错标准？",
"error_tolerance": "容错边界：错误输出是否可被容忍或低成本修正？",
"latency_requirement": "延迟要求：是否需要毫秒级响应？",
"compliance_risk": "合规风险：是否涉及隐私、金融、医疗等敏感领域？",
"integration_complexity": "集成复杂度：是否需要对接多个异构系统？",
"human_override": "人工兜底：是否有现成的人力流程可做 fallback？",
"volume_predictability": "流量可预测性：请求量是否稳定，能否做容量规划？",
}
WEIGHTS = {
"data_quality": 0.20,
"task_determinism": 0.15,
"error_tolerance": 0.15,
"latency_requirement": 0.10,
"compliance_risk": 0.15,
"integration_complexity": 0.10,
"human_override": 0.10,
"volume_predictability": 0.05,
}
@dataclass
class Assessment:
workflow_name: str
scores: dict
weighted_score: float
recommendation: str
def collect_scores():
scores = {}
print("=== AI 落地难度评估 ===")
print("为每个维度打分 (1=极难/极差 … 5=极易/极好):\n")
for dim, desc in DIMENSIONS.items():
while True:
try:
val = int(input(f" [{dim}] {desc} → 评分 (1-5): "))
if 1 <= val <= 5:
scores[dim] = val
break
print(" 请输入 1-5 之间的整数")
except ValueError:
print(" 请输入整数")
return scores
def compute_assessment(workflow_name: str, scores: dict) -> Assessment:
weighted = sum(scores[k] * WEIGHTS[k] for k in WEIGHTS)
if weighted >= 4.0:
rec = "🟢 推荐立即试点 — 条件成熟，可小规模上线验证"
elif weighted >= 3.0:
rec = "🟡 建议渐进引入 — 先做人机协作模式，逐步扩大 AI 覆盖面"
elif weighted >= 2.0:
rec = "🟠 需要基础设施投入 — 先解决数据/合规/兜底流程，再考虑 AI"
else:
rec = "🔴 当前不宜引入 AI — 风险和成本远超收益，保持人工流程"
return Assessment(workflow_name, scores, round(weighted, 2), rec)
def main():
workflow = input("评估的业务流程名称: ").strip() or "未命名流程"
scores = collect_scores()
result = compute_assessment(workflow, scores)
print(f"\n{'='*50}")
print(f"流程: {result.workflow_name}")
print(f"综合得分: {result.weighted_score} / 5.0")
print(f"建议: {result.recommendation}")
print(f"\n各维度详情:")
for dim, score in result.scores.items():
bar = "█" * score + "░" * (5 - score)
print(f" {dim:25s} [{bar}] {score}/5 (权重 {WEIGHTS[dim]:.0%})")
# 保存为 JSON 方便后续追踪
out_file = f"assessment_{workflow.replace(' ', '_')}.json"
with open(out_file, "w", encoding="utf-8") as f:
json.dump(asdict(result), f, ensure_ascii=False, indent=2)
print(f"\n评估结果已保存至 {out_file}")
if __name__ == "__main__":
main()
跑一次试试：
$ python ai_readiness_assessment.py
评估的业务流程名称: 客服工单自动回复
[data_quality] 数据质量：数据是否干净、结构化、有标注？ → 评分 (1-5): 3
[task_determinism] 任务确定性：输出是否有明确对错标准？ → 评分 (1-5): 2
[error_tolerance] 容错边界：错误输出是否可被容忍或低成本修正？ → 评分 (1-5): 2
[latency_requirement] 延迟要求：是否需要毫秒级响应？ → 评分 (1-5): 4
[compliance_risk] 合规风险：是否涉及隐私、金融、医疗等敏感领域？ → 评分 (1-5): 2
[integration_complexity] 集成复杂度：是否需要对接多个异构系统？ → 评分 (1-5): 3
[human_override] 人工兜底：是否有现成的人力流程可做 fallback？ → 评分 (1-5): 4
[volume_predictability] 流量可预测性：请求量是否稳定，能否做容量规划？ → 评分 (1-5): 4
==================================================
流程: 客服工单自动回复
综合得分: 2.75 / 5.0
建议: 🟠 需要基础设施投入 — 先解决数据/合规/兜底流程，再考虑 AI
这个分数会迫使团队承认：客服场景的容错和合规维度太低，不能直接全自动化。 正确路径是先建人机协作——AI 草拟回复，人工审核后发送，同时积累标注数据，逐步提升自动化比例。
从"精神病"到"精神正常"：几条实操建议
1. 强制 CEO 做一次 blind test
让决策者亲自跑 50 条真实业务输入，亲手标注 AI 输出的对错。幻觉率、边界 case、延迟波动——这些只有手指碰到才会产生体感。体感比任何幻灯片都有效。
2. 用评估框架替代愿景陈述
上面的脚本只是一个起点。每个团队应该维护自己的维度权重——金融团队把 compliance_risk 权重拉到 0.25，内容团队把 error_tolerance 放到 0.20。量化不是为了否定 AI，是为了找到正确的切入顺序。
3. 永远保留人工兜底通道
半自动化不是妥协，是工程上的最优解。人机协作模式让你在低风险场景积累数据、验证模型，同时在高风险场景有人兜底。跳过这个阶段直接全自动化，等于在没有安全网的情况下走钢丝。
4. 把 ROI 计算拉到月度粒度
CEO 级别的 ROI 算的是年度节省。工程师级别的 ROI 算的是：这个月推理费多少、标注人力多少、事故修复多少、用户流失多少。两套账必须对齐——如果月度账是负的，年度愿景就是空中楼阁。
5. 设立"反精神病"检查点
每个 AI 项目立项时，要求回答三个问题： - 如果模型准确率只有 80%（而不是 demo 里的 98%），业务还能跑吗？ - 哪 20% 的 case 会出问题，它们集中在什么用户群体上？ - 出问题时，谁来处理、处理成本多少、SLA 能守住吗？
答不上来就暂停立项。这不是保守，是基本的工程纪律。
"AI 精神病"的真正危险不在于过度乐观——乐观是推动行业前进的动力。危险在于乐观脱离了地面：决策层在云端画蓝图，执行层在泥里填坑，中间没有梯子。
作为一线工程师，你的职责不是否定愿景，而是给愿景装上刹车和仪表盘。上面的评估脚本就是一块仪表——它不会告诉你"能不能做"，但会告诉你"先做什么、后做什么、哪些风险必须先解决"。
CEO 们可以继续做梦。但代码不会陪他们做梦。