业务系统里的 AI 切口
原文就一句话：优先选高频、重复、规则相对清楚的环节。下面把这句话展开成判断标准——什么地方值得接 AI，什么地方不值得接，以及 AI 应该怎么进原有业务流程。
这不是企业 AI 场景大全，也不是项目交付报告。
为什么不是所有业务都适合接 AI
传统业务系统擅长的事情很明确：规则、确定性计算、存数据、走状态、控权限、管事务。这些本来就不该让模型去「猜」。
模型更擅长另一类工作：读一段说明、抽关键信息、做摘要、给分类建议、按资料回答问题、用自然语言当入口。
所以：
AI 不应该替代整个业务系统，而应该进入流程里适合它的那一截。
把整套 CRM / OA 换成聊天框，通常不是落地，是把确定性工作重新变回不确定。
我怎么判断一个场景值不值得接
1. 有没有大量信息处理
文档、制度、工单描述、申请说明、沟通记录——人读得慢、抄得烦的地方，模型才有用武之地。如果输入已经是几个下拉框和数字，传统校验就够了。
2. 有没有明确业务目标
「让 AI 帮忙」不算目标。比较像样的说法是：某类申请先被压缩成可读的摘要；某类工单先分到正确队列；制度问题先给出带来源的草稿。目标越具体，后面越好验收。
3. 能不能人工复核
我更认这条链：
AI 建议 → 人工确认 → 业务系统执行而不是：
AI → 直接改库 / 直接过审人复核不是保守，是把错误拦在不可逆之前。
4. 出错成本是否可控
低风险：摘要、分类建议、检索、辅助分析。
高风险：财务拍板、自动审批、改核心数据、执行不可逆操作。
自动化程度要和错误成本匹配。错了能改、能回滚、能被人拦住的，才适合先上。
5. 能不能嵌进已有流程
单独做一个「AI 聊天页」，同事用两次就回去点原来的按钮。真正有用的是：原流程走到某一环，弹出 AI 处理，人点确认，系统接着走。
哪些场景可以优先看
不必列十个。结合常见企业系统，我先看这几类：
审批辅助。 总结申请、抽出金额/时限/异常点、提醒风险。过不过，仍是人点。
工单辅助。 归纳问题、分类、抽关键字段、给处理建议。关单和改状态仍走原系统。
企业知识问答。 按已有制度/手册回答，并带来源；答不上来就说不确定。没有资料就不要硬答。
业务信息整理。 客户跟进摘要、会议纪要、从长文本里抽字段。本质是减阅读量。
业务 Agent（概念上）。 从「回答问题」再往前一步：理解任务 → 调业务接口 → 得到结果 → 核对。这里只作为方向，不写成已经落地的产品。
原文里的审批摘要、工单分类、制度问答，仍然是我认为最顺的三个切口。
哪些地方先别急着接
规则已经写死的。 几行 if 就能算准的，不必为了 AI 而 AI。
高风险且没法复核。 模型一判断就自动执行、无法撤回的，先不要接。
没有上下文和数据。 没有制度、没有工单、没有历史记录，接模型多半只是聊天。
收益盖不住维护。 费用、延迟、Prompt、评测、失败重试、权限，都要算进去。省不了人时间，就只是多一个不稳定环节。
AI 怎么进传统业务系统
更接近现实的形状是：
用户
↓
业务系统
↓
业务上下文（当前单据、权限、制度、历史）
↓
AI 能力
↓
AI 结果
↓
人工确认 / 规则校验
↓
业务系统（写回、流转、落库）AI 是业务系统里的一个能力节点，不是整套系统。
我以前做 Java / 全栈企业系统，主要解决的是数据、流程、权限、状态、事务。模型能做的变化是：以前必须人先读懂的信息，可以先让它出一稿。但业务规则、最终决策、数据一致性和能不能上线，还是工程系统的责任。不是「AI 改变一切」，是信息处理这一段可以前移。
我的判断
我更愿意把 AI 看成业务系统新增的一种能力，而不是再做一套并行的「AI 系统」。
传统系统：数据 + 规则 + 流程
接上 AI 之后：数据 + 规则 + 流程 + AI 能力 + 人工验证高频、重复、规则边界清楚、出错可拦——这才是切口。看起来很炫、但一旦错了就伤数据或伤人的，先放一放。
关于本文
本文是基于企业软件开发经验的判断和方案思考。审批、工单、知识问答等仍偏设计和探索，不代表已经在生产里大规模落地。没有项目名、没有准确率、没有省了多少人天——那些要等真做了再写。