# 哪些工作将成为下一个AI Workflow战场

AI正经能用起来，需要把它变成严肃工程的一部分，现在已经验证了Coding依靠着它得天独厚的工程化优势成为了目前最重要的AI Workflow，那么问题来了，前面解释了不少关于AI的迷思，也灌输了很多对人的要求，但是哪些工作最容易成为下一个 AI Workflow 战场?

这个问题很难回答，因为现在似乎所有人都声称自己已经把AI用起来了，而很多案例深究下来仍然逃不出前面提到过的“产出物幻觉”。这种叶公好龙式的使用方式，当然无法成为可持续和可演进的应用场景。从对于全球token实际消耗的分析入手，我尝试去发现在Coding如日中天背后正在兴起的火苗：除去Chatbot、情感陪伴类、探索/检索/研究类这些同样成熟但是对于我们建设AI Workflow无关的领域以外，我发现剩下来的Workflow场景其实总体消耗的比例也许还不到20%。

这部分场景是个人或者企业在追求AI生产提效的主要阵地，目前的数据说明了它们不像Coding那样猛烈暴发，但是也已经有了丰富的实践结果。这也是我在前面文章中反复提到的，只有针对核心目标、给予足够信息、提供可评测和迭代框架的解决真实问题的Workflow才有机会发展壮大。它们并不是那么容易建设，却是我们必须要投入的AI转型切入点。这篇文章其实就是换一个角度，从已经成型的Workflow中看看它们的共同特点，以此来让每个人找到更多的对于成为AI Workflow Owner的灵感。把目前已经开始产生稳定价值的 Agent 放在一起，我看到三种反复出现的工作模式：Build、Service 和 Operations。

Build很容易理解，各种Vibe Coding的工具和项目层出不穷。Service和Operations我们可以先看看最成功的子场景：Customer Service 已经出现了比较成熟的产品和生产案例，企业内部的 IT Service 与它本质相似，只是服务对象从外部客户换成了员工。Security Operations 也已经开始大量使用 Agent，但继续往外推导，服务器运维、网络、制造设备甚至摄像头监控，其实都有相似的工作结构。

这不是一套需要严格遵守的分类，只是我对于实际使用场景代表的底层原理的粗浅分类。继续往下分析会发现，它们背后都有很长时间的行业积累。即使很多具体流程今天的工程化程度并不高，这些工作本身已经具备了非常好的工程化条件：输入相对明确，结果能够观察，工作过程中有可以调用的工具，做得好不好也有比较清楚的评价方法。

LLM 出现以后，过去最难被程序处理的那一部分理解和判断能力被补了进来，于是这些已经存在多年的Workflow开始真正具备 Agent 化的可能。

## Build：Coding 拥有最完备和最成熟的工程化体系

Coding Agent 是目前最成熟的一类 Agent，这件事已经越来越容易理解。

软件开发本身就是高度工程化的工作。工程师接到需求以后，在已有代码库里完成修改，代码可以编译和运行，测试能够发现大量错误，Diff 可以看出具体改了什么，Review 决定修改是否合适，版本管理又提供了回滚能力。

AI 写代码以前，这套体系已经存在很多年。

LLM 刚好精巧地补上了过去很难通过传统程序完成的一段工作：理解自然语言里的需求，读懂大量已有代码，根据上下文生成修改，再根据测试结果继续调整。

于是 Coding Agent 可以沿着一条已经存在的轨道工作：

> Goal → Understand → Modify → Test → Deliver

模型写错代码并不可怕，因为后面有测试。修改方向不对，可以通过 Review 发现。上线以后出了问题，也有日志和版本管理帮助定位和回退。

这也是为什么我越来越觉得，Coding Agent 的成功并不能简单理解成“LLM 特别会写代码”。更重要的原因是软件工程已经为 Agent 准备好了完整的工作环境。

Cadence 的 AuraStack 也很类似。PCB 和先进封装设计本身已经有成熟的数据格式、设计规则、专业工具和仿真体系，AI 可以用新的方式理解设计目标并调用这些能力。真正支撑结果可靠性的，依然是行业多年积累下来的工程体系。

一个领域过去积累得越深，Agent 今天能利用的东西就越多。

## Service：服务流程标准化提供同样可靠的系统约束

Customer Service 是第二个非常明显的方向。

客服看起来是一项高度依赖人的工作，因为客户说什么完全不可预测。同一个问题可以有几十种不同表达方式，还会混杂情绪、历史背景和各种例外情况。

但如果从 Workflow 的角度看，客服其实已经被企业规范化了很多年。

客户提出请求以后，企业会识别他的身份，读取账户和历史信息，根据知识与业务规则判断应该怎样处理，再调用后台系统完成退款、改地址、查物流或者修改账户。处理不了的问题进入人工升级流程，最后还可以通过 Resolution、CSAT、重复咨询率等指标判断服务效果。

它大致是一条这样的工作链：

> Request → Understand → Context → Policy → Action → Resolution

这里一直以来困扰自动化的恰好是前面几步。

客户不会按照数据库字段提供非AI程序所需要的结构化信息，他只会说：

> “为什么我的钱还没有回来？”

系统却需要理解这句话到底意味着什么，LLM 很擅长补上这部分。

这也是为什么 OpenAI Presence、Fin 以及越来越多 Customer Agent 产品都没有停留在“回答问题”上。客服系统的最终目标是让模型进入一项具体服务，获得必要的知识和系统权限，在明确范围内完成动作，再把例外交给人工处理。

同样在token有效使用上崭露头角的企业内部IT Service 也属于同一种模式。员工会说：

> “我的 VPN 连不上。”

背后仍然是识别身份、读取设备状态、查找知识、执行操作并确认是否解决。服务对象从客户换成员工，Workflow 的结构没有发生根本变化。

因此，Customer Service 与 IT Service 未必需要被理解成两个 Agent 市场，它们都属于更大的 Service Workflow。也许就目前而言，对于大部分抱有“我想要用AI做点什么”想法的准Owner们，Service固定流程的AI化是见效最快最明显的方向。

## Operations：事件触发的处理流程也非常成熟

第三种越来越明显的模式是 Operations。

它和前两类最大的不同，是工作不一定等待一个人发出请求。

服务器延迟突然升高，网络出现大量丢包，某个账户产生异常登录，生产设备振动发生变化，仓库摄像头发现异常活动，这些事情自己就会不断发生。

Operations 的基本工作链大致是：

> Event → Observe → Diagnose → Decide → Act → Verify

Security Operations 是目前比较成熟的例子。安全系统每天产生大量告警，分析师需要查看日志和身份信息，关联其他设备上的行为，判断一个 Alert 是误报还是真实攻击，再决定是否隔离设备、封禁账号或者继续调查。

过去大量时间花在收集和拼接信息上。现在 Agent 可以读取不同系统的证据，把一次安全事件相关的上下文整理出来，甚至根据已有 Playbook 执行部分调查工作。Google 和 Microsoft 都已经把 Agent 用在告警调查和安全运营中。

继续往外看，这种模式远远不只存在于 Security。SRE 面对服务器日志和监控指标，Network Operations 面对设备状态和网络告警，制造业面对传感器和设备状态，物流系统面对车辆和货物位置变化。它们的输入形式不同，工作结构却很接近。

一个很容易理解的例子就是监控摄像头。假设一个园区有几百路摄像头，过去需要保安不断观察屏幕。困难的地方未必是某一个画面有多难理解，而是一个人根本不适合长时间同时观察几百路持续不断的视频。这个场景天然已经具备一条非常清楚的 Workflow。输入是持续产生的视频流，输出是需要进一步处理的潜在风险。AI 可以先从大量画面中找出异常，例如有人进入限制区域、设备附近出现异常活动或者某个区域发生拥堵，再结合时间、位置和其他摄像头的信息判断发生了什么。最终是否属于确切的风险，则告警出来由人工确认。

这样的 Agent 并不需要从第一天开始替代整个安防团队。只要它能够把原来需要人长时间机械观察的几百路视频，压缩成越来越少需要人工关注的事件，价值就已经非常明确。人工确认的结果又可以继续成为反馈，让系统知道哪些告警有意义，哪些属于误报。

这其实已经具备一套非常好的工程化条件：

> 明确的输入，明确的输出，可以持续评价，也天然拥有反馈和迭代机制。

即使过去的处理方式主要依赖人工，它仍然是一条非常适合 AI 进入的 Workflow。

## 关键在于一个工作流程是否具备被工程化的条件

Build、Service 和 Operations 表面上差别很大。

一个人在写软件，一个人在处理客户问题，另一个人在盯服务器和摄像头，但它们具备非常相似的基础条件。

首先，工作都有比较明确的触发。Build 从一个目标开始，Service 从一个请求开始，Operations 从一个事件开始。Agent 知道一轮工作什么时候开始，也比较容易判断什么时候应该结束。

其次，输入和输出已经比较清楚。Coding 的输入是需求和已有系统，输出是一组可以运行的修改；客服的输入是客户请求和账户状态，输出是问题得到解决；Operations 的输入是持续产生的系统状态，输出是异常被发现、处理并恢复。它们当然都有大量复杂情况，但至少可以回答一个最基本的问题：这轮工作做完以后，现实发生了什么变化？

第三，已经存在大量可以复用的工具。Coding 有代码仓库、测试和 CI，Service 有 CRM、知识库和业务系统，Operations 有日志、监控平台、传感器和执行工具。Agent 不需要重新创造企业的软件世界，只需要学会在正确的时候使用这些工具。

第四，也是我认为最关键的一点，它们都拥有比较好的评价和反馈条件。代码到底能不能跑，可以测试。客户的问题有没有解决，可以看 Resolution 和后续反馈。服务器有没有恢复，可以继续观察指标。摄像头发现的风险是不是真的存在，可以由人确认。评价结果又可以返回系统，成为下一轮修改的数据。这正是工程体系能够长期迭代的基础。

所以我现在越来越觉得，我们以前所说的“工程化”，并不仅仅意味着企业已经建立了一套漂亮的 SOP，或者某个系统已经高度自动化。更重要的是，这项工作本身是否具备被工程化的条件。

有明确输入和输出，有持续发生的任务，有工具可以执行，有结果可以评价，也能够根据反馈继续改进。只要这些条件存在，哪怕今天大量步骤仍然依赖人，AI 都有机会逐渐进入其中。

反过来，有些工作看起来非常重要，也非常适合发挥人的智慧，却很难回答结果到底怎样才算正确，也缺少持续反馈。这样的工作当然可以使用 AI，但要建设成能够长期自主运行的 Agent，就困难得多。

## 从AI的工具化属性找到合适的Workflow场景

回到我们一直以来的质疑，如果倾向把AI当作人，那么很可能是在放大AI智能的操作空间并产生难以预知的结果。（类似于“产出物幻觉”，我以后用“拟人化幻觉”来表述这个认知偏差）

比如面对一个企业部门，自然而然很容易提问：能不能做一个 AI 财务？能不能做一个 AI HR？能不能做一个 AI 销售？

但一个岗位通常同时包含很多完全不同的工作。HR 里，员工咨询休假政策属于 Service；新员工入职触发账号和设备准备，更接近 Operations；如果需要修改某个数字系统或配置，又可能是一种 Build。所以部门和岗位并不是特别好的 Agent 建设角度。应该寻找的是那些已经存在多年、持续发生，而且有机会关闭回路的 Workflow。

对于企业如此，对于个人的实际生产能力增强其实也一样。一个人可以观察自己的工作：有没有需要不断 Build 的数字对象，有没有持续收到并处理的 Service Request，有没有值得长期监控的 Operations。然后再梳理几个更实际的问题：输入在哪里？一轮工作结束时应该产生什么结果？AI 可以调用什么工具？做得好不好如何判断？出错以后谁能发现？人工修改能不能成为下一次的反馈？如果这些问题已经有比较清楚的答案，Agent 才开始有了发挥自身优势的位置。

Build、Service 和 Operations 已经共同展示了一个规律：Agent 最先产生稳定价值的地方，往往不是模型看起来最聪明的地方，而是那些经过多年积累，已经具备良好工程化条件的工作。LLM 带来了过去很难获得的理解和判断能力，但让这些能力持续产生价值的，依然是它周围那条能够运行、评价和不断改进的 Workflow。