AI 这个词正在成为企业表达里最容易注水的词之一。我在一次内部评审会上见过一个典型场景产品经理指着页面说系统已经用 AI 完成自动分析前端同学打开接口日志发现后端只是把几个关键字段套进了一段写好的模板再用 if-else 选了个口径。你说它完全没用到 AI似乎也不是毕竟调用了一个文本分类接口。你说它真的是 AI 驱动整个流程里没有一个环节在动态适应新数据也没有任何推理链路。这种“不能说完全撒谎但绝对严重夸大”的叙事正在大量存在。这不是某一家公司的问题而是一种系统性的行业现象。从融资路演到内部周报从产品发布到供应商招标人们太容易把“演示能力”和“生产能力”混为一谈把“营销语言”直接当成“工程结论”。我想写这篇文章的目的不是站在道德高地上指责谁而是想提供一个多元视角企业为什么会夸大 AI夸张抹掉了哪些真实信息对技术人有什么影响以及当我们自己动手做 AI 项目时要怎么避免成为下一个“注水者”。真正需要关心的不是“他们撒谎了”而是“我们为什么这么容易被说服”。当 AI 成为新一代基础设施学会识别水分、理解边界本身就是一种工程能力。1. 为什么“撒谎”在 AI 行业里会成为常态要理解企业为什么喜欢夸大 AI不能把原因归结为“道德差”。更常见的驱动力是商业压力、组织激励、认知偏差三者的合谋。单独看每一个都算不上十恶不赦但叠加在一起就形成了行业性的叙事膨胀。1.1 商业叙事需要确定性融资、销售、客户汇报都需要明确结论。投资人和老板问“AI 到底能做多少事”时最让人舒服的答案不是“我们有个模型在某些分布上效果不错但需要持续调优”而是“系统已经能够自动完成某类任务准确率达到了 95%”。后者听起来更像一个可投资、可售卖的能力。问题在于任何真实系统都不只包含模型。一个 AI 功能上线至少需要数据管道、特征处理、模型推理、后置规则、人工审核、反馈闭环。如果只把模型准确率当成产品能力一定会出现“技术演示很精彩真实业务跑不动”的情况。为了让叙事成立企业会不自觉地把链条中所有非 AI 环节比如人工标注、规则兜底也一并算成 AI 的功劳。1.2 内部决策缺乏可验证标准在传统软件工程里功能是否完成相对容易验证按钮能不能点接口返回什么日志有没有报错。但 AI 项目的验收标准要模糊得多。模型准确率只是离线指标真实环境里的用户行为、数据漂移、失败案例很难拆成一串明确的验收项。当标准不清晰时讲故事的空间就变大了。一个做推荐系统的团队可以说自己“提升了用户停留时长”却不提实验组只跑了一周、样本量很小、显著性没有通过一个做客服机器人的团队可以说“回答了 90% 的问题”却不提剩下的 10% 消耗了最多人力。不是大家想撒谎而是很多决策者根本没有要求对方提供可证伪的证据。这也是为什么我特别建议在 AI 项目立项时先把“成功长什么样”写下来。这条看起来像废话但大多数团队做不到。因为你一旦写下“每周处理 1000 条请求其中 30% 需要人工介入”后面就很难再用“AI 完全自动化”这种话去汇报。1.3 竞争压力下的“必须说”当同行宣布“我们已经全面应用大模型”你很难在融资材料里写“我们还在实验阶段”。于是为了不掉队企业会采用一种“技术前瞻式表达”把内部一个很小的 AI 试验单元包装成产品级能力把实验室里的一个 Demo说成已经投产的功能。这种表达的初衷可能是“我们正在朝这个方向走”但传到市场里就变成了“我们已经做到了”。竞争焦虑还带来一个副作用就是大家都去抢“首发”“首个”“领先”这类词。用户被教育成只看新概念不看真实收益。最后老老实实说自己“用规则引擎解决了大部分问题”的团队反而显得不够性感。这种环境会鼓励更多人加入夸大行列。1.4 认知偏差把“能力”和“可靠性”画等号很多人拿到一个大模型发现它能写代码、能总结文档、能回答常识问题就默认它“很聪明”。但大模型的能力是概率性的同一个问题换一种问法答案可能完全相反。企业里做决策的人一旦体会过几次惊艳效果很容易把“它能做到”当成“它总能做到”。这就涉及到 AI 幻觉问题。模型会一本正经地生成看起来合理、实际错误的内容。当宣传话术里把“生成内容”说成“专业答案”把“概率输出”说成“智能决策”本质上是把概率模型包装成了确定性系统。这种包装在商业上短期有效但在工程上会埋下大坑。如果让我总结这一节的核心就是企业夸大 AI往往不是某个人的品德问题而是商业叙事、组织激励和认知偏差共同推动的结果。理解这一点不是为了原谅而是为了知道从哪里下手纠正。2. 企业最常见的几种“AI 水分”形态光知道“为什么”还不够技术人更需要能够识别“水分在哪里”。我把它拆成四种最常见的形态每一种背后都有清晰的工程逻辑。水分形态常见说法工程真相识别切入点规则引擎当模型“AI 已能自动分类”本质是 if-else / 模板匹配输入变化后系统是否还能正确处理人工兜底当模型进步“准确率持续提升”大量失败由人工修正指标被人为拉高查人工介入率看端到端自动化比例演示集当真实效果“效果非常好”只在精选样例上表现好换场景立刻失效要求看失败案例试新输入隐藏幻觉“内容生成完全可靠”模型会输出看似合理但错误的信息构建包含陷阱问题的测试集下面展开讲。2.1 “规则引擎”与“AI”的边界模糊并不是所有自动化都能叫 AI。企业中大量“智能客服”“智能审核”“智能推荐”就是基于关键词、正则表达式、业务规则实现的。它比人工操作快但它没有学习能力也不会在新场景下迁移。识别方法很简单改变输入的表达方式看输出是否还成立。如果只是换了同义词规则引擎可能就失效而真正基于语义的模型还能保持功能。这里需要注意我不是说“规则引擎不好”相反很多业务场景用规则更稳定、更快、更容易排查。问题是不能为了叙事把规则说成 AI因为这样做会让后续维护者走错方向他们以为数据越来越多模型会更好实际却只是不断追加规则。2.2 “人工兜底”被包装成“模型进步”有些 AI 产品看起来指标漂亮背后是大量人工在后台默默修数据。比如一个表单识别系统识别不了就转人工人工修正后再返回结果。系统对外展示的是“识别成功率 98%”但这 98% 里可能有一半是人工录入后被算成“系统识别正确”的。这种水分最隐蔽因为它不直接撒谎只是选择性统计。要识别就去看端到端自动化率也就是“输入到最终输出完全没有人工介入”的比例。如果这个比例很低那真正智能的部分并不多。实际落地时团队应该主动把“人工介入率”列入核心监控指标因为它比准确率更能反应系统的真实价值。2.3 “演示集”被当成“真实效果”很多 AI Demo 是在几十条精心挑选的样例上录制的恰好覆盖了最友好的输入避开了所有模糊边界。产品发布时这些高光片段被剪成短视频观众很容易被震撼。但真实用户不会按照你准备好的提问模板说话数据也不会一直保持同样的分布。识别方式最直接要求演示者提供一个没见过的输入现场测试或者提供一份过去一周用户的真实请求日志看模型在这些日志上的表现。如果对方拒绝或者总是用“需要清洗数据”来拖延基本说明真实效果远没有演示时那么光鲜。2.4 “幻觉被隐藏”导致误判风险大模型能说会道但也会一本正经地胡诌。企业为了不让用户恐慌很少在产品文案里主动写“这个系统可能出错”。于是用户会把生成的内容当成专业建议用在一个本不该直接使用的场景里。技术人在评估一个 AI 产品时必须带着“它一定会出错”的前提去看错误出现的形式和频率。比如给一个医疗问答 AI 输入“感冒了可以吃抗生素吗”这种带陷阱的问题看它会不会给出危险回答给一个代码生成 AI 输入依赖不完整的项目看它是否会坚持一个很自信但编译不过的答案。这些测试不是刁难而是最基本的可靠性检查。3. 为什么这种水分对工程实践伤害很大企业夸大 AI不只是市场和公关层面的问题。它会影响技术选型、资源分配、团队信任甚至最终决定一个项目能不能真正落地。3.1 选错方案浪费大量时间如果决策层相信“AI 已经能解决大多数问题”团队在技术选型时就会天然倾向用大模型处理一切包括那种用简单规则成本更低、更稳定的任务。结果就是把一个本来可以在百度上搜到答案的问题变成了一次“等待大模型生成、再人工核对、错了再调 prompt”的低效循环。我见过不少团队为了“显得 AI”把本来非常稳定的统计报表改成了大模型生成。结果模型要额外处理格式、口径、单位偶尔还会把数值写错。最后又要写一堆校验规则把输出拉回正轨。这本质上是在给自己制造不可控变量。3.2 掩盖数据短板后续无法迭代AI 系统的迭代依赖数据、标注、评测、反馈。如果宣传时故意掩盖短板真实需求就无法被正视。比如某个客服机器人大量简单问题由 FAQ 匹配解决复杂问题转人工。如果对外说“AI 已经理解用户意图”产品方向就会聚焦在提升模型意图识别上而真正需要投入的或许是构建人工兜底的知识库管理流程。说不清楚失败场景就无法设计针对性改进。长期下来系统停在演示水平数据质量越来越差别说“自我进化”连稳定复现旧版本的效果都难。3.3 技术人的信用被透支当产品宣传说“AI 很可靠”但用户使用三天就发现错误百出第一反应不是骂公司而是觉得“搞技术的人又在吹牛”。技术团队内部的信用资产会快速流失。以后你再提出什么方案别人会用怀疑的眼光看你需要在解释上花更多时间而真正应该投入的改进时间被不断压缩。这也解释了为什么我写这篇文章要强调“工程诚实”。因为技术人最值钱的不是写代码能力而是判断力。如果你为了配合一个不切实际的宣传不断降低自己的判断标准长期下去你的职业判断力也会被侵蚀。3.4 真正该做的“工程化”被推迟一个 AI 功能要稳定运行必须考虑日志、监控、版本、回滚、权限、数据合规、成本优化。这些工程化工作不性感不会出现在发布会演示里但决定系统能不能长期存活。当所有人都在忙着“让 demo 更惊艳”时这些最基础的工程能力一定会被无限推迟。等到用户量上来问题暴露团队才发现连“最近一周模型回答了多少次、错了几次、错在哪里”都说不清楚。这时候要补的不是模型而是整个工程基础设施。4. 识别“AI 谎言”的五步排查法如果你要在项目中判断一个新 AI 方案是否靠谱或者要识别外部供应商有没有夸大能力可以用下面这五步框架。它不是万能的但能大概率帮你避开最明显的坑。4.1 第一步问输入输出边界不要先问“用的什么模型”先问“这个系统接受什么输入输出什么输入超出边界时会发生什么”。对方如果能清楚说出边界说明他们在生产环境里思考过如果只说“我们用了大模型很智能”基本就是在讲概念。实操时可以准备 3 组输入一组正常样例一组边界样例一组明显乱写的内容。看系统对第三组的反应。好的系统会拒绝回答、提示纠错、转人工坏的系统会强行生成一个看起来合理的答案。4.2 第二步看评估集和验证方法询问“这个系统上线前做了哪些验证”如果答案只有“准确率 95%”没有说明测试集来源、分布、与真实请求的差距那么没有一个指标是被真正验证过的。要让对方提供最近一段时间的真实请求日志哪怕脱敏也能看出用户实际在问什么、系统表现如何。特别要看失败案例。一家诚实的团队会准备一个“known failure”文档记录常见错误输入、错误原因、后续计划。只有营销驱动的团队才会把所有案例都包装成成功。4.3 第三步检查工程成熟度AI 功能不等于模型文件。一个达到生产级标准的系统通常需要具备请求日志和全链路追踪模型版本管理和回滚机制输出内容的安全校验和格式校验异常时的降级方案可观测的指标面板延迟、调用量、人工介入率如果对方只给你看模型的结构图和几个准确率曲线说明还处于实验阶段。不是说实验阶段不好而是不能把实验阶段说成生产可用。4.4 第四步评估资源和成本约束大模型不是免费玩具。一次推理的算力成本、GPU 资源的吞吐上限、高并发下的延迟表现都会影响真实可用性。如果方案里没有评估这些指标那你真正落地时会发现成本远超预期甚至在高峰期直接打满资源。排查时我会让对方给出并发估计值预计每秒多少请求、平均延时要求是多少、批处理能不能满足。算不出来就说明没有做过压测做过压测通常能给出一个范围。4.5 第五步查找人工兜底的真实位置几乎所有 AI 系统都需要人工介入区别只是多少、在哪个环节。诚实的做法是在流程图里明确标注“这里需要人工审核”“这里失败会转到人工处理”。如果对方画出的流程全是自动箭头没有任何人工介入点那要么是他们没想过失败场景要么就是故意隐瞒。这一步对判断“水分”非常有效人工介入率越高AI 实际承担的比例就越低。识别时不要问“AI 能做到什么”要问“不靠人工它能独立完成哪些任务”。这些任务加起来才是系统真正的自动化能力。5. 做 AI 项目时怎么避免自己成为“撒谎者”识别别人的水分只是第一步更关键的是在自己动手做 AI 项目时建立起一套避免自我欺骗的工作方法。以下是我觉得最有效的几条实操检查。5.1 先明确“AI 边界”再开始做在项目启动文档里首先要写清楚哪些环节真正依赖模型推理哪些环节用规则或逻辑判断哪些环节必须人工介入。不要用“智能”“自动”这种模糊词概括整个流程。具体可以这样做画一张简单的流程图每个环节标注“模型 / 规则 / 人工”。这样所有人都能一眼看到真正的模型能力只是其中很小一块。哪怕这块很小也值得单独评估哪怕大部分是规则也不是缺点它意味着系统更可控。5.2 建立可复现的评估集评估集不能只在模型训练时用还要在每次上线前跑一遍。我一般会把数据集分成三份一份正常场景一份带噪声的对抗场景一份记录过失败案例的回归场景。每次修改 prompt、切换模型、调整参数都要在完整评估集上重新跑一遍而不是只看几个典型例子。这里最容易踩的一个坑是模型在评估集上分数提升了但真实业务没变化。原因往往是评估集太“简单”和真实请求分布差距大。所以我建议定期从线上日志里抽取新样本加入评估集让评估集保持“新鲜”。5.3 把失败案例写进文档坦诚地记录失败看起来会拖慢进度但在工程上价值极大。一个失败案例胜过十个成功案例因为它能告诉你边界在哪里。具体落地时每发现一个明显错误就把它加入一个“badcase 库”内容包括输入、期望输出、实际输出、错误类型分析。这个库不仅帮助迭代还能作为向业务方解释“为什么不能承诺百分之百”的依据。它不是一个遮羞布而是一个工程资产。5.4 先跑通单体别急着上 Agent最近 AI Agent 非常热很多团队一看能做工具调用、任务规划就想一步到位做一个多智能体系统。我的建议是先做一个最小闭环把单次任务的输入输出跑通再考虑复杂的编排和并行。原因很简单Agent 系统引入的不可控点是指数级上升的模型要理解用户目标、要分解任务、要调用工具、要处理工具返回的错误、还要决定什么时候停止。每一步都可能出错而且错误会层层放大。如果只做一个简单的 prompt 调用就能解决问题那就不应该为了“技术先进”而引入 Agent 架构。要等真实场景里出现了“单次调用无法满足必须结合多个工具动态决策”的需求再上 Agent 也不迟。5.5 发布前写清“不适用场景”任何 AI 系统都有不适用场景。发布前把“这个问题不要用本产品解决”写清楚可以省掉大量后期售后和技术答疑。比如一个代码生成助手适合写模板、补齐测试但不适合在没有编译器和运行环境的情况下判断一段代码是否正确一个知识库问答机器人适合回答有据可查的问题但不适合虚构一个不存在的事实。写清不适用场景看起来是自我限制实际上是在建立用户预期也在给系统留出安全边界。这一点对 AI 产品尤其重要因为模型本身就是概率输出。6. 不是所有夸大都是恶意但要分清这几种情况我前面用了大量篇幅讨论“水分”但你也要知道并不是所有夸大都源于恶意。有些情况只是表达习惯和认知偏差的问题。6.1 误区把“愿景”当“现状”产品团队在规划时会说“未来我们可以做到什么”。传到市场部门变成了“我们已经做到什么”。这里不一定是刻意说谎而是在信息传递中丢掉了时态。作为技术人需要格外注意自己的措辞边界。当你负责一个 AI 功能时建议在对外输出前加一个“当前状态”标签是实验、灰度、还是全量上线。这个标签不需要很长但能有效防止演示数据被误传为生产数据。6.2 产品经理与技术人的沟通方式产品经理需要用 AI 做卖点工程师需要控制实现复杂度。两边经常在“什么是 AI”上产生分歧。要避免互相指责最好的办法是把目标从“是不是 AI”转移到“能不能稳定满足用户需求”。我在项目里会用一句话来对齐“这个功能一旦失败最坏情况是什么” 如果回答是“用户要等 5 分钟重新上传”那用不用 AI 影响不大如果回答是“用户的钱会被错误扣除”那么无论用不用 AI都要有强校验和人工兜底。这个讨论比争论“AI 能不能解决所有问题”有用得多。6.3 如何给团队写一份“诚实的 AI 汇报”与其等别人夸大你负责的项目不如主动写一份诚实汇报。汇报里可以包含当前端到端自动化率是多少人工介入的主要场景有哪些最近发现的高频错误 top 3模型在哪些边界条件下明显失效下一步计划优先做什么这份汇报的价值不是自我批评而是建立一个客观基线。下次再有人问“AI 效果怎么样”你不需要用形容词只需要把指标和案例摆出来。6.4 对个人开发者来说工程诚实是长期资产作为一个自己会写代码、自己部署模型的开发者你会发现“工程诚实”会带来很多隐形回报。它能让你在给代码写注释时更负责在写技术文档时更准确在向用户解释产品时更有底气。你不必用夸张词来吸引注意力因为你的功能能实际跑起来你的文档能指导别人复现你的失败案例能帮别人少走弯路。这也是为什么我不建议个人开发者在小项目里过度使用“AI 驱动”的标签。如果你的工具只是调了一个公开 API、做了几层提示词封装那就老老实实写“基于大模型的简单封装”。这不是贬低它同样有价值而且更利于用户信任。回到文章开头那个场景当我们看到产品经理把模板规则说成“AI 驱动”时作为技术人的第一反应不应该是群嘲也不应该是配合演出而是把边界说清楚。AI 这个词因为承载了太多商业想象正在变得越来越不可信。真正能把行业拉回正轨的不是某个更强的大模型而是更多人愿意在汇报、文档、产品说明里写下准确的限制条件标注可能出现错误的位置承认哪些环节还需要人来兜底。下次评估一个 AI 项目前先问三个问题它能稳定处理什么输入它在什么情况下会失败失败之后谁能接住这些问题的答案比任何宣传语都有价值。