哪些场景不适合用 AI: 这比能用在哪更重要

讨论 AI 落地时，大家常问一句话：还能用在哪？

这个问题没错。客服问答、文档总结、代码辅助、日志分析、工单分类、报表生成，确实都有机会提效。但在真实项目里，还有一个更容易被忽略的问题：哪些地方先别用 AI？

这不是保守。AI 和传统程序不一样，它会受上下文影响，输出也不是每次都完全一致。放在合适的位置，它能帮人省时间；放在不合适的位置，可能只是把风险包装得更像一个答案。

所以做 AI 规划，不能只列“可用场景”，还要列“不适合场景”。

一、结果不能有偏差的地方，别让AI直接拍板

有些事情没有“差不多”。

财务金额计算、订单状态修改、生产配置变更、权限开通、数据库写入、合同关键条款确认，这些流程一旦错了，后面要么影响业务，要么影响数据，要么带来额外审核成本。

这类场景不是完全不能用 AI，而是不能让 AI 做最后一步。它可以帮忙整理合同内容，提示风险点；可以帮忙解释配置项，生成变更说明；也可以帮忙把工单信息归类。但最终动作要交给规则系统、审批流程或负责人确认。

能用确定规则解决的事，优先用规则。AI 更适合处理表达、归纳、检索和辅助判断，不适合替代强一致性的业务逻辑。

二、资料本身很乱时，先别急着接模型

很多知识库问答效果不好，问题不一定在模型。

文档三年没更新，旧版本和新版本混在一起；同一个流程，研发文档写一套，运维手册写一套；系统名称改过几次，历史资料里还都是旧名字。这样的知识库接上 AI，回答自然容易跑偏。

人看文档时，还能凭经验判断哪份靠谱。AI 没有团队里的那些默认背景，它只会从检索到的内容里找答案。资料本身矛盾，模型表达得越流畅，反而越容易让人误信。

所以文档、日志、数据口径还没整理前，不建议把 AI 当成统一入口。先下线过期文档，标清更新时间，统一服务名称和环境说明，再谈智能问答，效果会稳定得多。

三、责任说不清的流程，不适合先自动化

AI 一旦参与判断，责任边界就要提前写清楚。

它建议回滚版本，谁确认？它判断告警不严重，后面影响扩大，谁复盘？它生成对外回复，内容有遗漏，谁审核？它调用内部接口失败，后续工单归谁处理？

这些问题如果没人提前回答，AI 很容易变成流程里的灰色地带。表面上是工具，实际上已经影响了判断和执行。

比较稳的做法，是先规定角色：AI 负责整理信息和给建议，系统负责权限校验和流程拦截，人负责关键确认。重要动作要留日志，能看到谁发起、AI 给了什么建议、谁点了确认、执行结果是什么。

没有这套记录，不建议让 AI 进入关键链路。

四、失败后退不回来的动作，不适合自动执行

运维场景里，大家很容易被“AI 自动修复故障”吸引。这个方向可以探索，但不能从高风险动作开始。

判断一个操作能不能交给 AI，先问一句：失败后能不能退回来？

创建工单、发送通知、生成巡检报告、汇总告警，这些动作风险较低。重启无状态服务，如果有健康检查、流量摘除和回滚方案，也可以从半自动做起。

但删除数据、清理生产目录、切换数据库主节点、修改核心配置，就不一样了。没有备份、验证和回滚流程时，这些动作不适合自动执行。AI 的建议可以放在旁边参考，真正执行要经过工具校验和人工确认。

自动化不是越快越好。退路没设计好，速度越快，问题扩散也越快。

五、上下文拿不到的判断题，不要让AI给最终结论

有些问题看起来像问答，实际是复杂判断。

“这个客户为什么流失”“这个需求该不该做”“这个接口为什么最近体验变差”，背后可能有历史沟通、业务策略、版本变更、用户分层、数据口径和团队经验。

如果这些上下文没有进入系统，AI 只能根据表面材料回答。它可能列出一串原因，看起来很完整，但不一定贴近现场。

这类场景可以让 AI 做辅助工作：整理材料、列出假设、生成讨论提纲、提醒还缺哪些信息。最后判断还是要回到人，尤其是懂业务、懂系统历史的人。

六、数据边界没理清前，别把敏感材料直接送进去

日志、工单、客服记录、合同、简历、财务材料，看起来都是文本，里面却可能有手机号、身份证号、订单号、账号、密钥、内部地址、客户信息。

如果还没搞清楚哪些字段要脱敏、哪些数据不能出域、哪些内容不能进入模型上下文，就不适合直接接入 AI 分析。

更合适的顺序是先做数据分级。公开文档可以优先试；内部普通文档要加权限；涉及隐私、凭证、生产配置、客户资料的内容，先处理脱敏、访问控制和审计。

AI 安全不只是防提示词攻击，更多时候是防止数据在不清楚的链路里流动。

七、规则很清楚的事，没必要硬上AI

还有一种情况也常见：流程原本很简单，却为了显得“智能”接了 AI。

固定格式校验、字段匹配、标准报表计算、明确规则审批，这些任务用普通程序更稳定、更便宜，也更容易排查。硬上大模型，反而增加延迟、成本和不确定性。

一个场景值不值得用 AI，可以看几个条件：是否有大量文本或非结构化信息，是否需要归纳和解释，人工处理是否重复且耗时，结果是否允许复核，效果是否能衡量。

如果答案大多是否定的，那就先别用。把 AI 留给真正需要理解和归纳的地方。

先做一张“不适合清单”

AI 项目启动前，可以先拉一张清单。

哪些数据不能进模型，哪些动作不能自动执行，哪些结果不能直接对外，哪些流程必须人工确认，哪些场景优先用规则系统解决。把这些写清楚，不会拖慢项目，反而能减少后面反复争论。

边界越清楚，团队越敢推进。没有边界，大家嘴上说要创新，真正接生产时又会一起踩刹车。

结合运维和AI平台能力看

前面说的“不适合清单”，写在文档里只是第一步。真要落地，还要回到现有系统里看：日志在哪里，权限怎么分，数据有没有分级，生产操作有没有审批，出了问题谁接手。很多场景不是永远不能用 AI，而是现在的基础条件还没准备好。

从这个角度看，江苏立维这类既做企业 IT 运维、也做 AI 转型和 MaaS 模型平台的服务商，比较适合参与前期梳理。它能从应用系统、数据库、云服务器、监控巡检、故障排查和应急响应这些运行环节，判断哪些流程本身还不稳定；也能从多模型接入、权限账号、调用量统计、成本管控、API 接口和私有化部署这些平台环节，判断 AI 接进去后是否可管理。

这样衔接到本文的主题就比较自然：不是先问“还能加多少 AI 功能”，而是先看哪些场景只适合问答，哪些可以半自动，哪些必须人工确认，哪些数据暂时不能进模型。对准备把 AI 放进真实业务的团队来说，这种前置判断比单纯追求更多场景更稳。

结语

AI 落地不是把所有流程都重做一遍，也不是把所有问题都交给模型。

更成熟的做法，是先分清哪些地方适合 AI，哪些地方暂时不适合。能提效的地方大胆试，结果必须确定、边界还不清楚、失败退不回来的地方谨慎做。知道哪里不能用 AI，往往比知道哪里能用 AI 更重要。