Excel没有打败AI。它只是暴露了昂贵系统从未进入业务动作。
一家企业花了几十万做"智能分析平台"。
演示时很惊艳。页面有大屏，系统能对话，管理者可以输入自然语言查询数据，还能自动生成分析结论。
三个月后，业务人员形成了新的操作习惯：登录平台，点导出，把Excel发到工作群，再用熟悉的公式重新核对。
老板看到后很生气："花了这么多钱，最后还不如Excel。"
供应商也很委屈："需求改了很多次，数据一直不完整，培训做了几轮，用户还是不用。"
业务部门同样有理由："结论不敢直接信，出了问题还得我们负责。"
三方说的都可能成立。
问题通常发生在开发之前。项目没有确认业务要做哪个判断、数据是否支持、收益如何计算、员工为什么愿意改变旧习惯。系统按计划上线，项目却没有进入日常经营。
Excel不是失败，昂贵的多余步骤才是
很多人把"还在用Excel"当成数字化落后的证据。
Excel有很强的生命力，因为它灵活、透明、上手快。面对一次性分析、小规模数据和不断变化的规则，一张表可能就是成本最低的方案。
如果业务人员导出后只做一个简单筛选，企业有必要反问：为什么要建设复杂平台？
AI系统值得投入，通常因为现有方式遇到了Excel难以解决的问题，例如：
- 数据量和更新频率超出人工处理能力；
- 多人协作时版本反复冲突；
- 判断需要同时读取文本、图片和结构化数据；
- 业务规则复杂，人工容易遗漏；
- 决策必须留下权限、来源和审计记录；
- 响应速度直接影响客户与收入。
系统上线后，如果这些业务结果没有改善，导出按钮就成了最诚实的功能。员工用它把数据搬回原流程，绕过那些没有产生价值的新步骤。
所以，评价AI项目不能只看有没有使用模型、页面多漂亮、生成速度多快。要看它减少了哪个动作，改善了哪个判断，避免了哪类错误。
"做一个AI客服"，仍然不是一个需求
企业说想做AI客服，可能面对完全不同的问题。
消息太多、回复不及时，需要的是分流和提醒；客服查资料慢，需要数据连接和知识检索；新人不会判断，需要规则和辅助建议；客户转化低，则可能涉及产品、价格、营销与销售流程。
四种问题都能被包装成"AI客服"。技术方案和投入范围却完全不同。
项目团队收到产品名称后马上进入开发，很容易在后期陷入争论。
客户觉得效果不好，因为销售没有改善；供应商认为功能已经交付，因为机器人确实能回答问题。双方从未对同一个业务结果负责。
一个可开发的需求需要写到具体动作：
当【岗位】处于【业务环节】时，系统依据【数据与规则】，帮助完成【判断或动作】，结果通过【指标】验收，异常由【责任人】处理。
这句话写不完整，项目仍然只是一项产品愿望。
进入开发前，先过四道闸门
企业AI项目可以在立项阶段设置四道闸门。任何一项无法通过，都应该缩小范围或补足条件。
**问题清楚。**
目标必须落到具体岗位、场景、判断与业务结果。"提升效率""建设智能化能力"无法指导开发，也无法验收。
**数据可用。**
确认数据在哪里、由谁维护、是否有权使用、质量如何、多久更新一次。数据清洗需要被列为独立工作，写清工作量和验收标准。
**收益可算。**
列出开发、数据、接口、培训、维护和人工审核成本。收益则对应时间节省、错误减少、转化提升或风险降低。暂时算不准可以给区间，不能完全没有尺度。
**团队会用。**
用户是否参与流程设计，AI输出进入哪个日常动作，谁处理异常，旧流程是否同步调整。培训只能解释按钮，无法替代岗位责任和流程改变。
*图：问题、数据、收益和采用条件全部明确后，开发才拥有稳定起点。*
四道闸门并不要求项目开始前解决所有问题。它们要求团队知道风险在哪里、由谁补齐、什么情况必须停止。
数据乱，系统会把混乱做得更漂亮
参考材料提到一个智能CRM情境：系统功能完成后，团队才发现历史数据长期没有维护，存在大量重复、缺失和过期记录。
具体比例缺少独立证据，不影响这个场景揭示的问题。
模型可以帮助识别异常、合并候选记录、补充分类建议。它无法替企业决定哪条客户记录有效，哪个字段由谁负责，销售离职后的线索如何交接。
数据质量至少包含四层：
- 字段是否完整；
- 定义是否统一；
- 内容是否及时更新；
- 来源和责任人是否可追溯。
只做技术清洗，业务规则不变，脏数据还会继续产生。
因此，数据准备不能被藏在"客户配合事项"里。双方需要共同确定样本、质量阈值、修复方法和持续维护责任。条件达不到时，项目应降低自动化程度，保留人工确认。
"人工复核"不等于AI没有价值
另一个常见抱怨是："说好的智能分析，最后还得人工复核。"
人工复核是否合理，要看错误代价和AI在流程中承担什么任务。
涉及合同、财务、医疗、价格、对外承诺等高风险动作，人类确认本来就是安全设计的一部分。AI如果能完成资料汇总、候选判断和风险提示，复核者只处理关键例外，仍然可能大幅降低工作量。
有问题的情况是，员工需要把AI输出从头重做一遍。此时复核没有缩短任何动作，还增加了检查成本。
项目应该测量：
- AI建议被直接采纳、修改后采纳和完全弃用的比例；
- 人工复核平均需要多长时间；
- 错误主要来自数据、规则还是模型；
- 哪些类型已经稳定，可以降低审核强度；
- 哪些高风险动作必须保持逐条确认。
人工在环并不可耻。没有根据风险和数据调整审核方式，才会让"AI辅助"长期停留在重复劳动。
4到6周小验证，重点是获得决策证据
参考材料建议用4到6周跑一个小验证。这个周期可以作为常见项目节奏，具体长度仍取决于数据、集成和风险。
小验证需要控制五件事。
**选小场景。**
优先选择高频、低风险、数据可获得、结果可衡量的任务。不要同时覆盖多个部门和完整业务链。
**准备样本。**
用真实、脱敏、包含正常与异常情况的历史样本测试。演示数据过于干净，会推迟问题暴露。
**跑通闭环。**
从输入、AI处理、人工确认到结果记录全部走一遍。只验证模型输出，无法证明业务流程能运行。
**指标验收。**
提前确定时间、准确性、人工介入、错误代价和用户采用指标。项目开始后再挑指标，很容易只展示好看的部分。
**继续或停。**
达到标准后扩大范围；数据或流程条件不足时补课；业务收益不成立时停止。暂停错误方向也是验证成果。
*图：小验证的终点是一项继续、调整或停止的明确决策。*
一份有价值的诊断，应该留下什么
"诊断比开发重要"很容易变成顾问式口号。企业是否值得付费，要看诊断交付能否直接减少后续返工。
一份有价值的前期诊断至少应留下：
1. 当前业务流程与关键判断节点；
2. 目标问题、基线数据和业务负责人；
3. 数据源、权限、质量和缺口清单；
4. 候选方案，包括不用AI的轻量替代；
5. 完整成本、收益区间和主要风险；
6. 小验证范围、样本、指标与停止条件；
7. 双方责任、变更流程和验收方式。
如果诊断结束后，企业仍然只得到一份宏观趋势PPT，后续团队依然不知道从哪里开始，这项服务没有完成任务。
诊断需要把不确定性变成可以确认的事项，把大投入拆成可以止损的小决定；仅仅"让懂行的人说得更准"无法完成交付。
企业和供应商，都要放弃"交付幻觉"
企业不能把模糊愿望交给供应商，期待对方自动补齐业务规则。供应商也不能把功能清单做完，就认为业务价值自然发生。
项目需要共同完成几类工作：业务人员提供场景与规则，技术团队评估能力与风险，数据负责人保证来源与权限，管理者调整流程和责任，最终用户参与测试并反馈。
这种协作不意味着需求可以无限变化。
每次变更都要说明触发原因、影响范围、成本和验收变化。新问题如果改变了项目目标，应进入下一阶段，不能悄悄塞进原合同。
共创也不意味着责任模糊。每个结果都需要唯一负责人，每个异常都需要处理路径。
一个简单测试：把AI功能全部遮住
评审项目时，可以暂时遮住所有AI名词，只看业务流程。
用户现在多做了什么，少做了什么？判断速度提高了吗？错误减少了吗？数据更新了吗？负责人能看到异常吗？员工愿意每天使用吗？
如果回答仍然含糊，系统再智能也难以被业务采用。
如果一张Excel已经能低成本完成任务，就先把表格、字段和责任做好。等到数据量、协作、风险或响应速度出现明确瓶颈，再引入AI与系统集成。
几十万系统最终只剩导出功能，最可惜的并非Excel赢了。企业付出的预算，没有换来更快的判断、更少的错误或更顺畅的协作。
一项AI投资是否值得，最后只需要回到业务现场：旧流程里哪个动作消失了，哪个结果改善了，谁愿意持续为它负责。
*案例说明：本文基于参考材料中的企业AI客服、智能CRM和分析平台情境进行结构化重构。材料未提供可独立核验的企业名称、数据质量比例与项目效果，因此相关场景仅用于方法讨论。*