从AI聊天到AI干活：生产级工作流搭建与落地指南

最近经常听到一种焦虑：聊天AI火了一年多，新鲜感过去了，下一步该怎么办。我个人的感受恰恰相反——聊天只是热身，真正能构成行业价值、能改变工作方式的机会，正是从“AI会聊天”迈向“AI能干活”这一步开始的。聊天是回答一个问题，干活是交付一个结果，这两件事之间的缝隙，才是大多数想动手的人还没看清、也没做透的地方。

这个判断不是拍脑袋。过去大半年我参与搭了好几个从对话式模型到生产级工作流的项目，迭代了很多轮，踩了不少坑。这篇文章想把三件事讲透：聊天和干活到底差在哪里、一个能让AI“干活”的最小系统该怎么搭、以及真正值得投入的机会长什么样。适合想用大模型做实际业务自动化的人、正在研究智能体落地的开发和产品同学，也包括刚入门准备做AI应用的初学者。

如果我们把话讲得直白一点：如果你只会调一个聊天接口，或者只会写提示词，那这篇文章能帮你把“能干活”的骨架搭起来。真正的机会，不在模型本身，而在模型外面那层看不见的工程。

1. 会聊天不等于能干活：先认清AI的两种能力

1.1 聊天模型擅长的是“生成”，不是“完成”

先说一个很多人不愿意听的事实：今天的大语言模型，本质上是一个非常强的“下一段文字预测器”。你给它一段上下文，它根据统计规律和语义关联，把最有可能接下去的话写出来。这件事的完成度确实高得惊人，尤其在客服对话、文案起草、知识问答这些场景里，已经可以做到以假乱真。

但“会生成回答”距离“能完成工作”还很远。打个比方：一个熟读千万菜谱的人，不等于一个好厨师。菜谱背得再流利，你让他站到灶台前，他可能不知道火候怎么控制、油温怎么看、菜切多细合适。因为做菜这件事，除了“知道怎么说”，还需要“动手做、看结果、调参数”。

AI干活也是同一个逻辑。聊天模型的能力边界，是它在“语言符号空间”里工作；而干活要在“现实世界空间”里产生结果。以生成一段客服话术为例，聊天模型可以写得很好；但真正处理一个用户投诉，需要查订单状态、判断责任方、根据赔付规则决定补偿方案，最后把结果同步给用户和后台系统。这里面的每一步，光靠“会说话”是远远不够的。

1.2 干活还需要三块模型没有自带的拼图：感知、执行、验证

我在实战中总结过一句话：一个模型能聊天，是因为它自带语言能力；一个模型能干活，是因为有人给它补上了三块拼图。

第一块是感知。干活必须有输入信号，来自数据库、文件、API、传感器，而不是停留在用户敲进来的那几句话。比如一个做售后工单处理的AI，它需要自己去查订单系统的物流状态、去商品库调价格和规格、去客户关系系统看历史沟通记录，这些数据模型不会自动知道。

第二块是执行。感知之后要动手，也就是实际去调用外部系统，比如把一条工单的状态从“待处理”改成“已回复”，给用户发一封通知邮件，向仓库系统发起一次退款申请。这类会改变世界状态的操作，纯靠模型自己做不到，它得通过工具和接口去完成。

第三块是验证。执行完动作之后，要确认结果是否真的符合预期。接口返没返回成功？数据库里那条记录改没改？通知发出去之后对方有没有收到？如果没有验证环节，AI就会在出错时浑然不觉，然后一本正经地把错误的中间结果接着往下传，最后得到一份“流畅但全错”的交付。

有个非常直观的对比，我用下面的表格整理过：

这个表格每次讲给团队听，大家都会点头，但真正动手做的时候，最常犯的错仍然是把80%精力花在“把prompt写得更好”上。Prompt当然重要，但它只是AI干活系统里很小的一层皮。真正决定成败的，是感知、执行、验证这条外挂链路。

1.3 “有手有脚”的代价：你绕不开工程问题

让模型能感知和执行，技术实现上现在很成熟，这一层不再是什么秘密武器。但代价是：你从一个“写提示词的”，变成了“写系统的”。

什么意思？以前做一个聊天机器人，你把API一接，把系统提示词一写，基本就能跑。用户问什么，模型答什么，出问题了大不了改改话术。现在要让AI干活，你需要考虑权限控制、接口稳定性、数据脱敏、失败重试、任务队列、日志审计……每一个都是正经的后端工程问题。

有一段时间我很抗拒这件事，觉得这不是在做AI应用，而是在做传统软件。后来想明白：AI能干活的本质，就是把一个“聪明的脑仁”装进一套“严谨的身体”里。脑仁再聪明，身体不健全，依然是一个动不了的病人。而这个身体，就是要用传统工程的方式去搭建的。

看清这一层，后面做方案设计就会少很多幻想，多很多务实。

2. 让AI能干活的最小系统：从“一句话”到“一套循环”

2.1 计划—执行—验证：AI干活的骨架

如果把所有能真正干活的AI应用拆开看，内核都长得差不多，是一个循环：理解任务 → 拆解计划 → 调用工具执行 → 观察结果 → 再决策，直到任务完成。你可以叫它Agent Loop，也可以叫工作流循环，名字不重要，重要的是这个闭环是否存在。

我建议第一次动手做AI工作流的新人，不要急着上复杂的框架，先用最原始的方式理解这个循环。拿“自动处理客户退款申请”这个例子来说：

1. 系统收到一条退款申请，附带了订单信息和用户留言。
2. AI阅读申请，判断是否满足退款条件，不满足就直接写拒绝理由，满足就进入下一步。
3. AI调用订单系统的API，查询订单状态、支付方式、是否超过退款时限。
4. 基于查到的信息，AI给出退款金额和退款方式，并调用支付接口发起退款。
5. AI再调用订单查询接口，确认退款状态变成“处理中”或者“已完成”。
6. 最后，AI生成一封通知邮件，发给用户，并在工单系统里留下完整记录。

这六步里，第1、2步是“理解+决策”，第3、5步是“感知”，第4步是“执行”，第6步是“输出+留痕”。当这些步骤串成一个闭环时，AI才算真的“干活了”。如果中间任何一步断了，AI就只是在“嘴上干活”。

2.2 给AI装上“手”和“眼睛”：工具调用不是魔法

过去两年，模型厂商陆续开放了工具调用能力，也就是常说的Function Calling。这个功能让AI模型在收到用户请求后，不是直接输出一段文字，而是先输出一个“结构化动作指令”，比如：

{ "function": "query_order", "parameters": { "order_id": "SO-2024-001234" } }

你的程序看到这个指令后，自己去执行query_order函数，把真实结果拿回来，再塞回给模型，让模型基于真实结果决定下一步。这个“模型出指令、程序做执行、结果回填”的机制，就是AI干活的底层逻辑。

具体代码上，核心就几件事。定义工具函数：

def query_order(order_id: str) -> dict: # 调用订单系统API，返回订单状态、金额等字段 return order_service.get(order_id)

然后把你有哪些工具、每个工具的参数结构告诉模型，老一点的方案用JSON Schema描述，现在多数SDK会直接从函数签名自动生成。比如：

tools = [ { "type": "function", "function": { "name": "query_order", "description": "查询订单基本信息，包括状态、金额、支付方式", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单号"} }, "required": ["order_id"] } } } ]

当模型判断“应该查一下订单”时，它会输出一个query_order调用；你的代码拿到这个调用、执行函数、把结果追加到消息历史再发给模型。模型读到结果后，要么继续调用下一个工具，要么给出最终结论。整个过程本质上是一个由模型驱动的状态循环。

我反复告诉团队一句话：工具调用不是什么魔法，它的本质就是“让模型做选择题，让程序做计算题”。模型负责在有限的动作集合里做选择、产生参数，程序负责把动作真正落地。这样，模型的聪明用在刀刃上，程序的可靠用在执行上。

2.3 哪一步最容易被忽略：验证与兜底

工具循环看起来不复杂，但新手通常会在一个地方栽跟头：以为模型调用了一个工具，事情就成了。

这是想当然了。调用工具只是“发出了动作”，动作是否成功，需要验证。最典型的例子是调用支付接口：接口返回HTTP 200，不代表退款成功了，也可能是请求已经被接受、但还在异步处理中；也可能是接口本身有幂等问题，同一笔订单被退了两次。系统一旦不验证，一个小小的接口异常就会传导成批量事故。

我在项目里给所有工具调用都加了一个“三态验证”规则。

• 成功态：接口明确返回成功，或者数据库回读状态符合预期。
• 失败态：接口返回错误，需要重试或者转人工。
• 不确定态：接口返回超时、无响应、或者返回了不合预期的数据。最好的做法是不要猜，标记为“待人工确认”，宁可慢一步，不要错一步。

另外一个同样重要的原则是兜底。给模型设一条铁律：当工具结果缺失、数据矛盾、权限不足时，默认不往下执行，而是把问题交给人工处理。不要尝试让AI去“编一个合理的中间值”。让AI承认自己搞不定，比让AI硬着头皮蒙一个结果，对生产系统来说安全得多。

3. 机会地图：现在真正值得“动手”的AI角色

3.1 三个落地概率最高的场景

聊完技术底层，回到最关键的问题：机会在哪里。我的判断是，短期最能落地、ROI最明显的方向，不是那些听起来高大上的“通用AGI助手”，而是一批看得见摸得着的具体岗位替代。我目前会优先推荐三类：

第一类是**“客服+工单”场景**。把客服接待、工单分诊、知识库检索、标准话术生成串起来。这个场景的信息基本都在系统里，坐席每天干的活儿高度重复，AI干活的准确率又容易被用户直接感知，是很成熟的一个落地窗口。

第二类是**“数据处理+报表解读”场景**。很多行业每天要从多个系统导数据，清洗、统计、做图表、写分析结论。过去一个数据分析师半天的工作量，现在可以让AI先处理80%，人只负责审核和调整。

第三类是**“跨系统文书流转”场景**。比如合同初审、报销单审核、资质材料校对。AI从邮件或表单里抽取字段，对照规则检查，给出通过/退回意见，再把结果写入下游系统。这类工作逻辑清晰、规则明确，最容易被工具调用流程承接。

这三种类型的共同特征：信息已经数字化、流程相对固定、结果可验证、错判成本可控。它们才是现阶段最好的“AI能干活”切入点。

3.2 判断一个点子值不值得做：“四道筛题”

我见过不少团队兴致勃勃地立项，最后做出来一个没人用的东西。为了减少这种浪费，我总结了一套“四道筛题”，拿来判断一个AI工作流项目值不值得做。

第一题：这事的数据在不在系统里？数据分散在纸质流程、私人邮箱、聊天记录里的需求，虽然市场存在，但现在做成本太高。优先选那些数据已经在数据库和各类业务系统里的场景，否则AI再聪明也只是没有米下锅的巧妇。

第二题：任务的产出能否被客观验证？“写一篇有感染力的文案”这种需求，谁都说自己写得好，很难验收；“将50个字段准确填入报表并把错误率控制在1%以下”这种需求，天然有验收标准。能验证的任务，AI才敢放心去跑，系统才谈得上持续改进。

第三题：人的时间是不是花在重复操作上？如果这个任务需要大量看屏幕、点按钮、复制粘贴，那AI上手的价值就极高。如果任务需要复杂人际关系、线上线下混合操作、不可预测的沟通，那先别急，等下一轮技术成熟。

第四题：错了以后怎么办，能不能兜住？任何一个AI系统都会犯错，关键不是永不犯错，而是错误成本可否承受。投资建议、医疗诊断、法务判断这类高风险场景，短期内更合适做“辅助增强”，而不是“自动执行”。

把四道题全部答完，答案还是“值得做”的场景，基本都能在半年内看到实际收益。

3.3 一个行业里的实际收益结构

为了说清楚收益到底长什么样，我再说一个虚构但非常典型的项目情况。某家电商代运营公司，客服团队有20人左右，每天处理上千条咨询和售后工单，到旺季还得临时雇人。上了一套AI工单助手之后，结果是分层的：

• 简单咨询类，比如查订单、查物流、退换货政策，AI直接处理，占总量60%。
• 中等复杂工单，比如申请退款、修改地址、催发货，AI先起草处理方案，人工一键确认后执行，占30%。
• 疑难和投诉类，AI做好信息汇总和背景摘要，推给资深客服处理，占10%。

对这家公司来说，AI没有把客服团队从20人砍到5人，但把同样的人力从只能处理1000单，提升到可以处理2500单。旺季不用再临时扩编，员工从每天机械重复回复，变成只处理真正需要判断力的case。这种收益不是“省人工”那么粗暴，而是用更少的人扛下了更大的流量，并且服务质量更稳定。

这个结构，我认为是当前AI落地的主流范式：AI负责把体力活干完，人负责把判断活干好。不是人机对立，而是人机分层的流水线。

4. 实战拆解：跑通一个AI工作流的完整过程

4.1 从原始需求到方案设计：先砍掉一半功能

理论讲了半天，现在我把一个具体项目的实施过程完整拆给大家看。为了讨论方便，我给这个项目起名叫“客服工单助手”，背景是一家做跨境零售的公司，每天有几百封英文售后邮件，客服团队需要一封封读、一封封回，效率很低。

客户最初的期望是“AI所有邮件都能自己回”。这个期望一定要打回去——因为一旦AI回复错了，在跨境零售场景里涉及退款赔偿、售后责任，风险很高。我们最后把项目目标定成三个核心能力：自动分类（把邮件分成退款、换货、物流、投诉、咨询五类）、自动检索知识库（在已有产品规则和售后政策中找答案）、自动生成回复草稿（人工确认后贴进系统再发送）。这就是一个合理的最小可用版本。

砍掉的功能包括：自动发送邮件（风险太高）、自动执行退款（涉及资金安全）、自动学习历史邮件（数据量不够，容易引入噪声）。这些功能不是没有价值，而是当前阶段不适合放进第一批交付里。

4.2 关键实现细节：检索、判断、生成三层结构

工单助手的后端，实际上由三个模块协作，结构很清晰：

第一层是分类模块。入站邮件先经过一个轻量模型，做多标签分类，判断属于哪类问题、紧急程度多高、是否需要人工优先。我习惯用便宜的小型号做这步，因为分类任务简单，大材小用纯属浪费钱。

第二层是检索模块。根据分类结果，系统去知识库检索相关规则。这里不一定非要用复杂的向量检索，很多时候用关键词加同义词映射就够了。知识库规模不大时，向量检索反而会召回一堆语义相似但完全不相干的内容。我一直坚持：先试最朴素的方法，不够再上向量。

第三层是书写判断模块。把历史邮件、知识库结果、分类标签全部塞进上下文，调用比较大、能力比较强的模型，生成两样东西：一是给出建议操作，比如“同意全额退款”或“拒绝换货，建议退货”；二是生成一封用英文写好的、语气恰当的回复草稿。这个模块是整个系统的决策核心，要用好模型。

整个流程串起来大概是这样的伪代码：

mail = receive_next_email() category = classify_with_small_model(mail) # 轻量模型分类 rules = search_knowledge_base( query=mail, category=category # 用分类结果缩小检索范围 ) draft = generate_with_large_model( messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"邮件：{mail}\n\n检索到的规则：{rules}"} ] ) # 人工审核通过后才真正落库、发送 queue_for_human_review(mail, category, rules, draft)

注意代码里最后一个动作，是排进人工审核队列，而不是自动提交发送。这是我推荐的默认姿态：初期人机协同，把系统跑顺之后，再逐步放开自动执行的比例。

4.3 评测：怎么证明系统“比原来好”

系统做出来之后，最容易被忽略的问题是：怎么证明它真的好用？不能再凭“我看它写得不错”来判断，要建立一套评测基线。

我们当时做了一个很朴素的评测集，把过去两个月的500封真实邮件抽出来，逐封标注好最终结果，然后给AI系统跑一遍，对比两个核心数字：分类准确率和回复草稿采用率。分类准确率从最初的82%调到97%；回复草稿采用率的意思是，人工审核后原样使用或只改几个字的比例，从75%调到89%。

这里有个经验要分享：每次调整模型或提示词，都要用同一套评测集重跑一遍。否则很容易出现“这个场景变好了、那个场景悄悄变坏了”的回归问题，而你在最后人工抽检时又发现不了。后来我们还加了一个小机制：每周从新邮件里随机抽50封，让一个人专门做“AI结果复核”，把发现的问题按类型统计，什么样的邮件容易错、错在哪个环节，再用针对性数据反哺优化。这套持续评测机制，才是系统真正变强的来源。

5. 从Demo到生产：我对踩过的坑的复盘

5.1 “幻觉”不是玄学，是缺少事实锚点

很多人一提AI就说“会幻觉”，把这当成某种玄学问题。我做了这么多工作流之后，越来越觉得幻觉的根源，80%以上是没有给模型足够的事实锚点。

举个例子，让AI回复退货政策，如果上下文中只有“请根据公司政策回答”这一句话，模型就会自由发挥，编出一个看起来合情合理但实际不存在的政策，这几乎必然发生。但如果你把售后政策原文件、该订单的实际情况、该用户的等级这些事实数据都塞进上下文，模型表达的自由度就被锚住了，它只能依据这些材料推演，幻觉空间大幅缩小。

所以，与其迷信“更强的模型不幻觉”，不如老老实实做检索和上下文搭建。模型回答问题之前，先把相关材料找齐喂给它是关键。把幻觉问题当“事实锚点缺失问题”来治理，远比当“玄学问题”来防更有效。

5.2 流程不是越“自由”越好

早期我做AI工作流，喜欢给模型很大自由度，觉得它自己知道怎么安排步骤。结果在真实业务里被狠狠教育了。

自由度过高时，模型会把简单问题复杂化，比如查完订单状态，还要多调用一个根本不需要的接口；或者自己绕开标准流程，跳过了本该执行的“库存扣减”步骤。最要命的是，这种错误不是每次都会出现，是偶发性的，在你不注意的时候突然来一下。

后来经验是：AI的自主性要分层控制。在关键路径上，流程是写死的，模型只负责在预设动作集合里做决策，不允许自己发明步骤；而在分支路径上，比如生成回复话术、判断客户情绪、整理摘要，可以放开让模型发挥。一句话，把AI当“一个能力强但需要明确边界的执行者”，而不是“一个啥都能自己搞定的全才”。

5.3 成本失控是必然遇到的一课

项目刚开始的几个月，我们的API账单增长很快。复盘下来，问题主要出在三个地方。

一个是日志回填太频繁。每一轮工具调用都把全部历史消息重新发给模型，消息越长，阅读理解成本越高。我们上线了消息压缩：超过一定长度的旧对话，先让一个小模型把它压缩成结构化摘要，再送大模型，成本立刻降下来一截。

二是所有环节都用了最贵的大模型。后来做模型分层：分类、抽取、总结这些小任务，全部换小模型，只有决策、生成核心内容这种任务才用大模型。整体成本下降了35%，效果基本没变。

三是缺少缓存和批处理。相同知识库的内容反复让模型读很多遍，很浪费。引入语义缓存后，几十个高频问题直接命中缓存，压根不需要调模型，成本肉眼可见地下去了。我经常跟人说，成本优化的顺序应该是：先砍没必要的调用，再做模型分层，再上缓存，最后才考虑换更便宜的供应商。

5.4 数据安全与操作审计的底线

最后也是最重要的，是安全底线。AI能干活意味着它拿到了业务系统的操作权限，权限越大，风险越大。

我给自己定了三条铁律。第一条是最小权限：AI系统能读的数据，以完成单个任务为限；能执行的写操作，以预设白名单为限。永远不要给AI开放“管理员”级别的权限。

第二条是操作留痕：AI每一步的决策依据、调用参数、返回结果，都要有审计日志。这样任何一笔操作出了问题，都能快速定位是哪个环节、哪条上下文导致的。

第三条是敏感数据脱敏：模型与外部接口交互之前，凡是涉及个人隐私、密钥、资金账户的信息，一律脱敏处理。不是说模型不可以用这些信息辅助理解，而是要换成一串脱敏后的标识符，让真正的敏感信息不出系统边界。

这三条看起来是传统软件工程的基本功，但很多AI项目因为发展太快，恰恰把这些基本功丢了。一旦出了安全事故，前面的所有效率提升都会瞬间归零，我相信真正成熟的团队会把这一项放在最高优先级。

6. 机会窗口已开：真正稀缺的不是模型，而是“编排能力”

6.1 模型正在变成基础设施，门槛集中在外面那层

现在有一个趋势越来越明显：各家模型的能力在大盘上越来越接近，你对模型的依赖会从一个“核心竞争力”变成“基础设施”。就像电网一样，谁都能接电，但电费本身不构成生意——生意是用电创造的产品和服务。

对AI来说同样如此。会掉接口、会写prompt，很快会像会用搜索引擎一样变成基本技能，不具备独特价值。独特价值在哪里？在把模型和业务之间的那层“编排”做得多好：知识怎么组织、流程怎么设计、边界怎么划、评估怎么做、复盘怎么闭环。这一整套东西，我把它叫“编排能力”。它是个体和小团队真正能建立壁垒的地方。

6.2 今后两年最有价值的能力组合

如果要我给想入局的朋友一个明确的建议，我会推荐三件事同时练：

第一是领域知识。懂一个行业的具体业务痛点、知道那些数据在哪个系统里、了解业务规则里哪些细节是数字化的，这些领域知识无法直接下载，必须扎进业务里，而这恰恰是大部分纯技术团队最短缺的一块。

第二是工作流设计能力。把一个模糊需求切成小步骤，给每一步配上合适的模型、工具、验证标准。这项能力类似写代码，但难度比写代码低的存档AI面流程设计，更为考验业务sense。

第三是系统化的评估与迭代能力。建评测集、跑回归、收集badcase、分析根因、针对性优化，这套从传统软件测试演化来的方法论，用在AI系统上，是决定产品质量上限的关键工程能力。

这三块拼在一起，就是我一直强调的“编排能力”。它比单纯写prompt难，也比从头训练一个大模型容易得多，对新入场的个人和小团队来说，是最合适的发力点。

6.3 从“聊天迁移”到“干活实践”的第一步

最后给想行动的你一个最小启动建议：不要急着追求大而全的“智能体平台”，先找一个你自己工作里最烦、最重复、哪怕只有10分钟就能做完的任务，把它流程化，接上工具，跑通“计划-执行-验证”的闭环。

可以是一个自动整理周报的脚本，也可以是一个根据邮件自动录入台账的工具，甚至可以是一个帮你批量审核文档格式的小流程。把这件事完整地做一遍，你就能真正体会到“AI干活”和“AI聊天”的差别，也才会知道这套系统里的乐趣和痛点都在哪里。

从AI会聊天，到AI能干活，这一步的跨越，表面是技术升级，本质是思维转变：从“生成内容”转向“解决问题”，从“让人阅读”转向“让系统运行”。谁先完成这个切换，谁就真正站在了机会窗口的前沿。

我个人的体会是，过去几个月里最有成就感的瞬间，并不是模型又回答对了一个难题，而是看到一个又一个小任务，在全自动的流水线上跑完，负责它们的人终于不用在深夜加班盯着屏幕上那些等着手动处理的表单。这种从“会聊天”到“能干活”的转变，才是这一轮技术浪潮里真正让人踏实的事情。