8.0
热点
AI SCORE
编程提效2026-09-11 03:35
企业 AI 自动化：集成层才是价值所在
dev.to · AI#AI落地#集成#企业自动化
Editor brief · 编辑速览
通过多个行业案例说明 AI 自动化项目中，真实工程难点在遗留系统对接、数据治理和人机审批流程，而非模型选型。
企业在 AI 项目中有一个反复出现的错误：
人们花太多时间问该用哪个 AI 模型，却花太少时间问 AI 需要连接什么。
GPT vs Claude。RAG vs 微调。Agent vs 工作流。
这些都是有趣的工程问题。
但在为律师事务所、制造商、保险公司、会计事务所和家政服务公司构建自动化系统的过程中，我们发现最难的问题通常出在别的地方。
AI 往往是最简单的部分。
杂乱的收件箱、遗留软件、不一致的文档、人工审批步骤和缺失的 API，才是真正的工程挑战。
这改变了你做 AI 自动化的方式。
"AI 项目"通常不是 AI 项目
看一个看似简单的请求：
"我们能把保险证书流程自动化吗？"
乍一看，这听起来像是一个文档 AI 问题。
理解请求，找到证书。
但生产系统需要回答的问题远不止于此：
请求从哪里来？我们如何识别客户？哪些信息缺失？应该使用哪个保单？我们如何验证证书？当文档不明确时怎么办？结果写回到哪里？谁审批例外情况？当底层系统不可用时怎么办？
LLM 只是其中一个组件。
实际系统更像是这样：
Email → 文档/请求解析器 → 客户识别 → 业务规则 → AI 分类 → 验证 → 人工审批（如需要）→ 记录系统回写 → 客户响应
这个区别非常重要。
集成层才是价值所在
我们的一个保险自动化项目很好地说明了这一点。
排名靠前的财产险和意外险代理机构，处理保险证书的速度比中等水平的机构快得多。在一个项目中，我们为一家营业额 4200 万美元的经纪商构建了一套定制接收工作流，实现了大约 6 倍的提升。
有趣的部分不仅仅是"AI 读取 PDF"。
该系统需要三个关键部分：
邮件收件箱前的解析器；针对传入请求的结构化接收流程；回写到 AMS360，以便流程可以继续，无需经纪人手动处理每个请求。
这是一个与把 PDF 丢进 ChatGPT 提问截然不同的工程问题。
模型提供智能，集成提供效用。
不要替换记录系统
这是另一个很快变得显而易见的教训。
企业已经有它们依赖的系统。
会计事务所有税务平台，保险公司有管理系统，制造商有报价和 ERP 系统，家政服务公司有现场服务平台。
构建 AI 软件的本能通常是：
"让我们构建一个新的 AI 系统。"
通常，这是错误的起点。
更好的问题是：
"我们如何让现有系统变得更有用？"
例如，一家会计事务所可能已经在使用 CCH Axcess。替换它不现实，但你可以在它周围构建一个智能层。
在一个 PBC 工作流中，一个定制接收层用一个结构化门户替代了繁重的邮件流程，该门户可以预先验证上传文件。合伙人与 PBC 的比例从 1:4 提高到 1:11。技术工作包括基于历史请求的文档分类，以及截止日期回写到事务所的税务工作流。
AI 没有替换会计平台，它填补了它周围的空白。
最有价值的自动化往往是无聊的
这可能是关于企业 AI 最不令人兴奋的事情。
最好的自动化并不总是一个炫目的自主 Agent。
"别让合伙人手动追文件了。"
"别让经纪人重复录入同样的信息了。"
"别让销售人员等六个小时等报价了。"
这些问题不会制成精彩的演示视频，但它们有可衡量的经济价值。
在一家定制金属制造商那里，一个自动化项目将报价周转时间从大约 6 小时缩短到 11 分钟，同时基于速度 alone（不改变定价）的情况下胜率提高了 22%。
这才是企业真正关心的 AI 结果。
不是系统处理了多少 token，不是 Agent 能否进行巧妙的对话，而是我们从工作流中消除了多少时间。
工作流应该在模型之前
这是我们发现的更有用的方法。
第一步：找到重复性决策
"我们可以在哪里使用 AI？"
"人类在哪里反复查看信息并做出同类决策？"
这就是你的候选场景。
第二步：绘制现有工作流
写下每个步骤。
客户发送请求 → 员工打开邮件 → 员工识别客户 → 员工打开另一个应用程序 → 员工搜索信息 → 员工检查文档 → 员工做出决策 → 员工更新系统 → 员工发送响应
哪些步骤真正需要人工？
你可能会发现只有一到两个。
第三步：识别系统边界
这是许多 AI 原型崩溃的地方。
原型在笔记本里可能运行得完美无缺。
API → 认证 → 数据库 → 现有 SaaS → Webhooks → 队列 → 重试 → 日志 → 人工升级
模型只是该架构中的另一个服务。
第四步：给 AI 一个窄小的职责
不要让 LLM 运行整个业务流程。
{
"document_type": "certificate_of_insurance",
"customer": "Acme Manufacturing",
"request_type": "additional_insured",
"confidence": 0.96,
"requires_human_review": false
}
然后让确定性应用代码处理后续结果。
这种分离非常强大。
AI 不应该是你的业务逻辑
这是最大的架构教训之一。
如果一条业务规则可以用确定性方式表达，就不要让 LLM 去琢磨它。
LLM："这个客户符合条件吗？"
LLM："提取客户的收入。"
代码：if revenue > threshold: continue_workflow() else: escalate()
模型处理模糊性，应用程序处理规则。这让系统更容易测试、调试和信任。
为异常而构建，而不是为演示
演示通常是这样的：
输入 → AI → 完美输出
生产环境是这样的：
输入 → AI → 缺失信息 → 重试 → 意外文档 → API 超时 → 重复请求 → 人工审查 → 更正后的信息 → 最终输出
第二张图才是大部分工程工作应该投入的地方。
生产 AI 系统需要回答这样的问题：
这些不是 AI 问题，它们是软件工程问题。
真正的 AI 栈比模型大得多
一个有用的心智模型是：
┌──────────────────┐
│ AI / LLM │
│ Classification │
│ Extraction │
│ Reasoning │
└────────┬─────────┘
│
┌───────────▼───────────┐
│ Orchestration │
│ Workflows / Queues │
│ Retries / State │
└───────────┬───────────┘
│
┌──────────────────▼──────────────────┐
│ Integration Layer │
│ APIs • Webhooks • Databases • SaaS │
└──────────────────┬──────────────────┘
│
┌───────────▼───────────┐
│ Human Workflow │
│ Approval / Exceptions │
└───────────────────────┘
如果缺少某一层，系统通常还没准备好投入生产。
所以，你应该用哪个模型？
当然，模型选择仍然重要。
上下文窗口重要，结构化输出重要，工具调用重要。但这些通常是优化问题，而不是根本问题。
如果你的工作流没有可靠的数据源、没有集成、没有错误处理、没有清晰的业务规则，那么从一个前沿模型切换到另一个不会拯救项目。
一个设计良好的工作流中的普通模型，比世界上最好的模型连接到空无一物，能创造更多业务价值。
AI 自动化实际上不是把智能放入业务，企业已经有智能，它存在于员工的头脑中、邮件里、电子表格中、PDF 里、CRM 记录中、会计系统里，以及多年积累的流程中。机会在于把那些智能连接到实际发生工作的系统上。
这就是为什么最有意思的 AI 工程不一定是构建下一个自主 Agent。有时候它是构建一个小小的层，连接：
一封邮件 → 一份文档 → 一个 AI 决策 → 一个 API → 一个数据库 → 一个人。
当那个小小的层消除了六个小时的等待、消灭了重复的数据录入、或者让合伙人不再追文件，突然之间，"无聊"的自动化变成了公司最有价值的软件。
模型不是产品，工作流才是产品。