先看一个现象：这两年 AI 圈最不缺的不是技术突破，而是“AI 能做到什么”的公开说法。有些来自企业发布会，有些来自产品页面，还有些藏在服务条款和隐私政策的角落里。但如果你真正上手去复现那些说法，会发现一部分经得起推敲，一部分说了半句真话，还有一部分属于刻意模糊甚至失真。
Pluralistic 是作家 Cory Doctorow 的博客栏目，经常讨论科技与商业、政治的交汇点。有一期的标题就叫“Why businesses lie about AI”，直译就是“为什么企业要在 AI 问题上撒谎”。这期内容没有停留在吐槽层面，而是把企业撒谎的动机、模式、后果拆开讲了一层。站在技术从业者的角度看，这不是道德审判现场，更像一份“厂商行为分析报告”。我们天天要选型、要评估、要接第三方 AI 服务，看懂企业为什么在 AI 上“说一套做一套”，比盲目相信宣传页要重要得多。
这篇文章会先梳理企业 AI 撒谎的常见类型和动机，再从技术实践角度拆解“为什么这类谎言很难被一眼识破”，最后落到工程侧：作为开发者、技术决策者，怎么通过合同审查、验证测试、灰度发布、隐私风险评估这些动作，降低被不实 AI 宣传波及的概率。这不是劝你“别用 AI”，而是帮你建立一套评估 AI 产品和服务的清醒框架。
1. 先定义：企业在 AI 问题上“撒谎”到底指什么
先说清楚边界。这里说的“撒谎”不是一个道德词汇，而是一种信息偏差行为。企业并不会像反派一样跳出来说“我的模型是人脑”，更多时候，他们在用大量合法的擦边话术让你产生错误预期。常见的表现形式有四类。
第一类是能力夸大。产品页写着“AI 自动生成高质量营销文案”，实际上模型输出的是模板拼贴，稍微复杂的指令就崩。这种夸大不是简单的广告水分，而是把边界能力包装成通用能力。
第二类是数据使用不透明。企业说“AI 不会用你的数据训练”，但服务条款里可能留了后门，或者在某个版本的更新说明中悄悄改了默认设置。这类问题普通用户很难发现，因为要审读条款、对比历史版本、追踪数据流向，技术成本很高。
第三类是“AI 完全替代人力”的暗示。工具类产品强调 AI 能自动完成某岗位的 80% 工作，但落到使用场景里，还是需要大量人工清洗数据、纠正输出、做安全审查。企业把“辅助”说成“替代”，本质上是在制造对能力的错误预期。
第四类是模型的确定性误导。企业宣称“AI 客服 7x24 小时无差错服务”，但大模型幻觉问题根本无法根除，服务质量的方差极大。这种“绝对化表达”在技术圈一看就知道不可能，但普通消费者、甚至部分企业内部业务部门都会信以为真。
如果给这四类撒谎做个体量排序，数据使用不透明往往引发最严重的后果。因为前两类最多是“效果不达预期”，这类涉及的是用户数据泄露、隐私被侵犯、合规风险，是实打实的问题。
2. 为什么企业会“选择”在 AI 问题上撒谎
Cory Doctorow 的分析有一个核心观点，企业撒谎不是因为他们坏，而是因为他们处在激烈的竞争和融资压力之下，产生了系统性激励。
首先是融资压力。AI 公司讲故事的能力直接影响估值。在资本市场热捧大模型的那几年，谁的故事更大、参数更多、场景更广，谁就能拿到更多钱。“严谨”在融资路演里反而不受欢迎，因为投资人想听的是一年十倍增长的故事，而不是技术局限的说明。
其次是市场竞争逻辑。当竞争对手把边界能力包装成通用能力，你如果不跟进，在销售和流量上就会处于劣势。这种“向下竞争”迫使企业不得不把话说满，哪怕知道自己的模型还有很多限制。
再次是产品迭代中的沉没成本。很多 AI 功能是“半成品”就上线了，但企业已经投入了大量营销资源，不可能返回来跟用户说“我们上次宣传错了”。于是只能边改边遮，用版本更新慢慢修复，而不是公开承认错误。
第四点是用户预期的“双向绑架”。企业一方面要满足用户“AI 应该什么都能干”的幻想，另一方面又要避免被用户发现问题后投诉。当幻想和现实差距太大，企业选择先满足幻想，把问题推给“用户使用不当”或“模型还在进化”。
这些机制对技术从业者来说并不陌生。很多 AI 项目，你从外部看宣传是一回事，进入合作流程、拿到 API 文档、看到服务等级协议之后，会发现真实的指标缩水一大截。企业不是想骗人，而是想“先把你拉进来再说”。
3. 从技术角度拆解：为什么 AI 宣传谎言很难被一眼识破
如果是传统软件，功能真假跑一次测试就能判断。但 AI 产品天然有“概率性输出”和“不可复现性”，这使得夸大宣传的识别难度远高于传统软件。
第一，大模型的输出质量不恒定。同一段提示词，在不同时间、不同参数下可能给出完全不同的结果。企业可以拿“效果最好的 10 次输出”做宣传素材，而用户在实际使用中遇到的可能是“效果较差的 90 次”。这种方差不是 bug，而是大模型的固有属性。
第二，评估标准模糊。很多 AI 产品宣称“准确率 95%”，但准确率的定义是什么？是识别单字正确率，还是整句正确率？是测试集上的指标，还是真实场景中的指标？没有标准化基准，准确率就是一个可以随意解释的数字。
第三，提示词工程的隐藏成本。企业演示 AI 功能时，往往使用精心调优的提示词模板。用户拿自己的真实数据、真实问题去测试，效果可能断崖式下降。但企业不会告诉你“这个效果依赖特定的提示词前缀”，因为这会影响“AI 开箱即用”的认知。
第四，数据集的“记忆效应”。一些模型在基准测试集上表现优秀，是因为训练数据中包含了测试集的内容，这在行业里被称为数据污染。评估结果好，不代表真实世界中的泛化能力好。
这些技术特性给了企业在宣传中“留白”的空间。他们不用撒谎，只需要不把话说全。比如，他们可以说“模型支持 100 种语言”，但不告诉你其中 90 种语言的输出质量根本不可用。在法律上,这些话很难构成欺诈，但在实际使用中，它就是误导。
4. 作为技术实践者，我们需要识别哪些高发“AI 撒谎”场景
结合日常 AI 工程实践，有五个高发场景值得重点留意。
第一个场景是智能客服。供应商宣称“AI 能解决 90% 的客户问题”，但你实际接入后会发现，它只能处理标准化、固定流程的问题，稍微复杂的情况就需要转人工，而且转人工的识别逻辑都很粗糙。在采购智能客服系统时，不要只看演示视频，一定要拿你们行业的高频问题集去测试。
第二个场景是内容生成工具。宣称“AI 一键生成高质量文案”的工具，实际输出往往需要大量的人工改写。很多文案工具所谓的“原创”，本质是模板组合加同义词替换，在搜索引擎去重和版权审查面前不堪一击。
第三个场景是数据分析与 BI 产品。“AI 自动生成数据报告”已经泛滥，但这些工具生成的结论经常是因果倒置、忽略统计显著性的初级错误。如果业务部门不核对就直接采用，后果可能很严重。
第四个场景是数字人与视频生成。不少产品宣称“上传照片即可生成逼真数字人”，实际生成的肢体动作、口型同步、表情自然度，跟宣传片差距很大。这个领域的技术进步确实快，但商业宣传永远比技术落地快半年到一年。
第五个场景是人员招聘筛选工具。AI 简历筛选初筛的效率宣称非常诱人，但模型的偏见问题、误杀率很少被诚实披露。如果企业用它做关键决策，可能面临歧视诉讼。
这五个场景不一定是“撒谎”，但都存在明显的宣传失真风险。技术决策者在这个环节的任务不是回避 AI，而是建立一套验证机制，把供应商的“声称”转换为“可验证的指标”。
5. 用工程化思维验证供应商的 AI 能力
前面分析了问题，现在说如何落地验证。无论你是在采购 AI 产品，还是准备接入第三方 API，下面这套流程都能用。
首先是建立“验收基准集”。不要接受供应商提供的演示用例，要自己构建一个覆盖真实业务场景的测试集。这个测试集应该包含典型输入、边界输入、异常输入、长尾场景。如果你要做客服系统，就去找过去一年的真实对话记录，脱敏后作为基准集。
然后是定义客观指标。根据业务目标选择指标：准确率、召回率、F1、端到端任务完成率、人工介入率、输出延迟、成本等。关键是指标必须可以量化，不能是“效果不错”这种主观表述。
接着是设计对比测试。如果有多个候选供应商，用同一个基准集、同样的输入，在不同系统上跑，记录输出结果。测试时要保证输入一致，输出用自动化脚本比对耗时、格式、成功率。
最后是压力测试和长尾场景测试。把并发拉高到预期峰值的 2 倍，观察延迟和错误率的变化。再重点测试长尾场景，例如方言语音识别、专业领域术语、生僻字、多轮对话中的上下文保持等。
在合同层面，要把验收标准和罚则写清楚。比如，供应商声称召回率 90%，合同里就要写明测试方法、测试集来源、达标判定方法，否则达不到指标时没有任何约束力。这一条建议找法务一起推进。
落到代码层面，可以用一段自动化脚本做持续验证。下面给出一个通用示例框架，实际使用时要根据接口文档调整请求格式：
import requests import json import time import statistics # 供应商 API 调用示例，url 和 payload 需要按实际接口文档调整 url = "https://your-ai-vendor.example/api/v1/generate" test_cases = [ {"input": "请总结这段合同的核心条款", "expected_keywords": ["违约责任", "付款条件"]}, {"input": "解释一下什么是过拟合", "expected_keywords": ["训练集", "泛化"]}, {"input": "", "expected_keywords": []}, # 异常输入 ] def call_vendor(prompt): payload = { "prompt": prompt, "max_tokens": 200, "temperature": 0.3 } start = time.time() response = requests.post(url, json=payload, timeout=30) latency = time.time() - start return response.json(), latency latencies = [] success_count = 0 total = 0 for case in test_cases: try: result, latency = call_vendor(case["input"]) latencies.append(latency) total += 1 if case["expected_keywords"]: text = json.dumps(result, ensure_ascii=False) if all(kw in text for kw in case["expected_keywords"]): success_count += 1 except Exception as e: print(f"调用失败: {e}") total += 1 print(f"成功率: {success_count}/{total}") print(f"平均延迟: {statistics.mean(latencies):.2f}s") print(f"P95 延迟: {sorted(latencies)[int(len(latencies) * 0.95) - 1]:.2f}s")这段代码的结构很简单：定义测试用例、循环调用接口、记录成功率和延迟。在实际项目中，还可以加入输出质量打分、语义相似度判断、多轮对话一致性测试等维度。关键是测试要自动化、可重复、可对比，而不是靠人工看几条输出就下结论。
6. “AI 撒谎”背后的版权、隐私与合规风险
对企业撒谎的分析还有一条暗线，就是版权和隐私问题。很多 AI 产品在宣传时不会主动提“训练数据包含什么”，但这里藏着最大的合规风险。
从数据使用角度看，不少企业会悄悄把用户上传的内容纳入模型训练集，直到被媒体曝光或用户投诉才修改条款。Adobe 曾经因为服务条款变化引发大规模争议，就是一个典型的例子。在国内，个人信息保护法、数据安全法已经明确要求，收集和使用个人信息必须取得授权，处理敏感个人信息需要单独同意。如果企业做 AI 训练时没有履行告知义务，用户有权要求删除数据并主张赔偿。
从版权角度看，企业宣传“AI 自动生成设计素材”“AI 一键写论文”时，往往不会主动告诉你生成内容的版权归属和侵权风险。大模型在训练时可能学习了大量版权作品，生成结果与原作高度相似时，使用者可能面临侵权纠纷。企业在宣传中淡化这一风险，实际上是把自己应承担的合规责任转嫁给了用户。
从服务条款角度看，很多 B 端 AI 服务的合同里都有“免责声明”，约定“AI 输出内容仅供参考，不构成任何建议”。这在法律上是合理的，但如果你把 AI 输出直接用于生产、发布或决策，责任只能自己扛。
这给技术决策者的提醒是：接入第三方 AI 服务前，一定要请法务审合同，重点关注数据使用权限、训练数据来源、输出内容版权、责任承担方式这几个条款。在内部使用环节，要对 AI 生成内容做来源标注和合规审查，特别是涉及金融、医疗、法律等强监管领域时。
从实践角度看，最稳妥的做法有三条：一是不向上传包含个人信息的数据，除非明确核对过服务方的数据保护条款；二是对 AI 生成内容进行人工复核，不直接对外发布；三是定期审计模型行为，关注输出内容的合规风险。
7. 资源投入与现实成本：企业夸大 AI 能力为何代价不小
对企业来说，在 AI 问题上撒谎看似短期内有利，长期却要付出几类显性成本。
第一类是信任成本。AI 产品一旦被用户实际使用后发现宣传失真，口碑崩塌的连锁反应非常快。尤其现在技术评测类内容扩散极快，一个“测评翻车”视频可以抵消几个月营销投入。
第二类是合规成本。随着 AI 监管逐步收紧，企业如果被认定存在虚假宣传、未授权使用数据训练，可能面临行政处罚和高额赔偿。在金融、医疗、教育等领域，这种风险还在上升。
第三类是战略误判成本。企业内部如果对 AI 能力产生了错误预期，会向技术团队施压，要求实现产品宣传中的效果。技术团队在能力边界内外疲于应付，真正有价值的研发被拖慢。这种内耗的代价远大于一次营销翻车。
对于使用 AI 服务的企业来说，被上游供应商的夸大宣传误导，同样是有成本的。你可能在采购决策中选择了效果不达标的系统，投入了集成、培训、运营成本，最后发现还要再换一遍。这个过程中的时间成本、人力成本、数据迁移成本，往往超出采购价本身。
所以，识别企业 AI 言论中的水分，不是一个道德洁癖的问题，而是一个基本的风险管理问题。谁评估得力，谁就能规避后续的大量返工和合规风险。
8. 怎么看穿，又不变成“逢 AI 必反”
这里要做一个平衡。拆穿企业 AI 谎言，不等于否定 AI 行业的价值。AI 确实在很多场景中已经落地并产生了实打实的收益：代码补全、质检自动化、OCR 识别、语音转写、智能检索，这些能力早就不是空中楼阁。
问题只出在“宣传与现实的偏差幅度”上。偏差过大，欺骗用户；偏差小，属于正常商业包装。技术从业者需要的是建立一把尺子，测量偏差，而不是一杆子打死。
实操层面可以借鉴一个“三层验证法”。
第一层是信源验证。看企业是否有公开的技术报告、论文、开源代码、第三方评测数据。有独立证据链的声明，可信度高于只有宣传页面的话术。
第二层是实测验证。直接把真实业务数据喂进去，观察表现。实测结果跟宣传数字相差在一个合理范围内的，可以接受；相差一个数量级的，直接淘汰。
第三层是责任验证。看企业是否愿意在合同中承诺具体指标，愿意承担不达标的违约责任。一个对能力有信心的企业不会回避合同约束。
在合作模式上，也建议从“先小额试点”开始，而不是一上来就铺开大规模采购。先用一个业务小场景跑通，验证效果、稳定性、维护成本，再决定是否推广。这样即便踩坑，损失也在可控范围。
9. 给开发者和企业决策者的行动清单
把前面分析落到日常工作中，可以整理成一份检查清单。
技术选型时，先问供应商要模型卡和评估报告。模型卡应该说明训练数据来源、评估方法、已知限制、偏见指标。如果供应商拿不出来，或者只说“内部评测表现优秀”，就要提高警惕。
合作谈判时，把效果指标写成可验证的 KPI。不要用“更好的用户体验”这种模糊表述，要落到响应时间、准确率、任务完成率、人工介入率这些可测量指标。
接入之前，自己准备一套基准测试集。持续用相同输入做回归测试，关注模型升级前后行为变化。很多 AI 服务的隐性风险是模型偷偷升级后表现突然变差，这套回归机制能帮你第一时间发现。
运营期间，对 AI 输出做抽样审计。特别是面向 C 端用户的生成内容，要设置抽样人工审核比例。高风险领域（医疗、法律、金融）建议全量复核。
合规方面，建议建立 AI 使用台账。记录哪些场景用了 AI、用了哪家服务、输入输出数据是什么、保留期限多长。一旦出现隐私或版权投诉，有据可查。
隐私保护方面，默认不向第三方 AI 服务上传未脱敏的敏感数据。如果必须上传，先走完数据安全评估流程，并签订数据处理协议。
最后一条，也是最重要的一条：不要迷信“AI 全知全能”。好的 AI 产品知道自己不知道什么，会在边界处拒绝回答或引导人工介入。一个敢于承认局限的供应商，比一个什么都敢承诺的供应商靠谱得多。
10. 总结与后续思考
Cory Doctorow 的那篇分析，核心观点并不复杂：企业之所以在 AI 问题上撒谎，是因为资本市场奖励讲故事、竞争环境逼迫话术升级、用户又容易被“神奇效果”吸引。这套机制在互联网时代早就存在，AI 只是让它变得更隐蔽、更系统。
作为技术从业者，我们能做的不是愤世嫉俗地拒绝 AI，而是提高信息辨别的能力。用验证代替相信，用合同代替口头承诺，用回归测试代替演示视频。诚实永远是最高效的技术策略——对供应商如此，对我们自己构建的 AI 系统也是如此。
如果你正在做一个涉及 AI 的项目，建议最先做的事不是选模型，而是花半天时间，把项目里所有跟“AI 能力”相关的描述列出来，逐条标注：这条有证据支撑吗？有测评数据吗？有边界说明吗？能做到这一步，你就已经比大多数被 AI 宣传牵着走的人清醒了。
这篇文章可以收藏备用。下次再看到“AI 颠覆一切”的宣传，不用急着转发，也不用急着反驳，先按照这套框架做一次完整的验证。然后你会知道，它到底是真金，还是镀了一层金。
