“客户发来需求，AI读懂以后直接报价，再发给销售确认，应该就能用了吧？”

第一次看这个方案，很容易把它理解成一次模型调用：输入客户文字，输出报价草案。真正拆开时，里面却包含很多不同工作：理解描述、查找产品、确认工艺、读取价格、计算金额、处理折扣，以及决定能否对外承诺。

这些工作的输入不同，出错后果不同，谁有资格决定也不同。如果全交给一个提示词，流程看似简洁，错误却可能很难定位。

FDE需要先拆清任务，再安排处理方式。会用AI是一项能力，知道它在这一步应当输出什么、后面怎样核验，同样重要。

一句“全自动报价”包含几种工作

本文继续使用虚构的云衣工坊。第五篇讨论怎样取得报价规则，这一篇假设部分规则已经由教学角色确认，进一步讨论如何落实为可运行的分工。企业、单据、计价参数与结果均为教学设定。

客户发来一段话：“做100件外套，面料用C230，左胸按确认过的L07标识加工，还是上次那个尺寸。能不能给点折扣？”

销售希望尽快得到草案，但原话中仍有待核对内容。“上次”对应哪一笔记录？本次图样与尺寸是否仍然适用？折扣只是客户诉求，还是已经获得批准？

这些问题尚未回答，模型即使输出了一张整齐的报价单，也不表示任务已经正确完成。它可能把历史价格当成现行价格，把折扣请求当成已批准条件，或者把缺少的参数自行填齐。

因此，先把目标限定为：形成有依据、可核对的报价草案；对外发布由约定角色确认。若本次练习只覆盖部分计价项目，就在草案中明确范围，不把内部计算小计称为完整报价。

输入也需要分开：客户原文、产品目录、工艺依据、有效计价表与业务确认记录，各自负责提供什么信息。客户可以描述想要的效果，却不能通过一句话改变内部计价表或授予折扣权限。

在任务讨论中，可以先问“下一步需要知道什么”，而不是先问“让哪个Agent做”。需要知道产品编号，就核对目录；需要知道工艺是否适用，就寻找相应依据；需要计算金额，就使用已确认参数。

这样拆开以后，“自动报价”会变成若干个可以分别测试的工作。实现者能够看到哪里适合模型，业务负责人能够指出哪些决定不能由系统默认完成。

范围小一些，也更容易取得反馈。先检验标准情形能否准确形成草案，再讨论非标准工艺与更多系统动作，通常比把所有情况一次塞进同一个流程更清楚。

第一类工作是从表达中取得候选信息。模型可以尝试从客户文字中提取数量、产品、面料、标识、位置和折扣诉求，并保留对应原文。输出应说明哪些明确提供，哪些含糊，哪些没有出现。

例如，数量100件有直接依据，面料C230有明确编号；“上次那个尺寸”只是一个历史指代，当前尚未获得具体尺寸。把后者留在待核实，比填一个常见大小更有利于后续处理。

第二类工作是查找已存在的事实。面料编号是否有效，L07对应哪个图样版本，适用的价格表是哪一版，可以依据已知标识查询记录。若查出多个候选，需要继续核对，不能凭名称相似随意选一个。

查找与理解可以协作，但职责仍应清楚。模型帮助识别用户提到的对象，查询返回对象记录；模型对结果作解释时，不能把未找到的内容补成数据库中已经存在的事实。

这种分工可以先写成一条记录：客户原话提出“按上次尺寸”，模型标记为历史指代，查询需要明确的历史对象，业务人员确认其适用性，确认后才形成当前请求的尺寸依据。每一步都保留前一步留下的信息。

若只保存最后一个尺寸数字，后来者就难以判断它是否适用。字段传递时带上来源与确认状态，比让模型在最终回复中附一句“已综合考虑历史情况”更有帮助。

第三类工作是使用确定的条件和算法。例如，已确认的数量与单价怎样形成小计，哪些必要字段为空时不能计算，价格版本是否在约定适用范围内。这些可以通过明确规则与程序实现。

在本例中，假设业务角色已经确认一张教学计价表：基础项目120元／件，标准标识加工8元／件，一次制版200元／单。本次数量100件、工艺条件符合，且确实需要一次制版，则已列项目的小计为13000元。

计算过程是100×（120＋8）＋200。这里明确不含税费、运输及其他未列项目，也未采用任何折扣，结果仅用于内部草案。这些人为设定的数值不代表市场价格或真实成本。

如果是有效补单，不需要再次制版，就必须根据已经确认的适用规则改变该项费用；不能看到历史订单有200元就重复加入。规则是否允许免收，要由业务确认，程序只按当前有效依据计算。

第四类工作是业务判断。新图样是否属于已覆盖工艺，历史依据是否仍然适用，特殊折扣能否接受，可能需要有相应专业能力和决定权的人参与。模型可以整理材料，却不能靠语气肯定获得这些权限。

第五类工作是对外行动与承诺。草案生成、销售查看、指定人员确认、报价发出，是不同事件。即使前面的计算完全正确，也不表示已经满足对外发布条件。

把这几类工作分开，并不意味着必须部署五个Agent。它们可以由一个界面和一个流程串起来，只要每一步的输入、产物、依据与责任能够辨认。

比较AI、规则与人工的适用条件

面对自然语言表达多样、需要归纳或改写的部分，可以考虑模型辅助。前提是能够说明预期输出，并通过代表性样本检查它是否帮助任务，而不是只凭几次流畅回答判断。

在报价例子中，模型适合尝试将“左胸做上回那个标”整理成候选要求，指出历史指代需要核对。它还可以根据已经确认的缺项，生成便于客户理解的补充说明。

但是，模型不应同时负责创造规则、推测缺失单价、计算所有金额并宣告可以发布。把任务都合并到一次生成中，会让事实错误、计算错误和越过决定边界混在一起。

对已存在且结构清楚的事实，数据库或表格查询可能更直接。已知物料编号要查询有效单位，就按编号与适用条件查记录；不需要为了“更智能”，先把整张表改成一堆文档，再让模型猜相近内容。

对说明性资料，可以考虑检索后辅助回答，也就是通常所说的RAG。它能帮助找到与问题相关的说明，但被找到的内容仍需要核对版本、范围和依据。检索到一份旧报价，不等于取得了现行工艺价。

对可以清楚表达、需要稳定重复的条件，规则或程序便于检查。数量应为有效正数、单价来自适用版本、缺少必要参数停止计算，都可以在模型输出之后再次核对。

规则的局限也要看到。输入含义没有统一，条件就可能稳定地产生错误；规则只检查“尺寸字段不为空”，无法保证填进去的尺寸适用于本次图样。确定性执行不能替代业务依据的确认。

人工适合承担尚未可靠形式化的判断、特殊情形和相应权限下的决定。但“交人工”需要进一步说明工作，不能在图里放一个框，就认为异常已经解决。

他要查看什么证据，选择什么结论，能够修改哪些内容，处理完怎样回到流程？这些信息不清楚时，人工环节可能成为新的等待点，也可能让每个人按自己的习惯处理。

至于工作流与更自主的Agent，应根据任务路径是否明确来讨论。Anthropic在《Building effective agents》中，将预先安排路径的工作流与由模型动态决定过程和工具使用的Agent作出区分，并建议只在有必要时增加复杂度。

在云衣工坊的标准报价范围内，提取、查依据、核验、计算、人工确认的次序已经比较明确，可以先组织成可检查的工作流。需要处理陌生问题、多轮查找资料时，再判断模型动态选择下一步是否有价值。

即使增加自主选择，执行条件也要保留。模型决定再查询一次图样，不代表它可以自行改变价格版本或对外发送。自主程度与业务权限是两个需要分别设计的问题。

《企业本体建模方法与实战指南》将判断、流程组织和受控动作分别讨论，也提供了相似的检查视角。实际实现不必照搬完整平台，但需要知道每个判断读取什么、每个动作会改变什么。

本体方法可以帮助澄清“报价请求”“工艺依据”“报价草案”“已发布报价”的含义。如果用几张记录表已经能说明关系，可以先从那里开始；不应把购买某类平台作为正确分工的前提。

选择处理方式以后，要把交接安排具体。最容易遗漏的，往往是模型做完以后，下一位参与者如何继续。

一个供练习的实现可以保留四组内容：客户原始要求、模型候选字段、已确认的依据、草案及其处理记录。字段多少由业务范围决定，关键是不要让模型输出直接覆盖原文和业务确认。

可以用多维表格保存这些内容，用Agent平台调用模型并组织步骤，再用规则或代码核对必要条件。这里描述的是可选的教学实现，真实平台功能、接口与运行要求要在所用环境中验证。

模型提取后，先检查数量、对象标识和缺项。如果图样未确认，流程生成补充请求，停在待补充状态；它可以展示已经取得的资料，但不得让空白工艺被默认当成标准工艺进入总价。

“不知道”“不适用”和“没有提供”也应分别处理。客户明确说不需要标识加工，与尚未提供标识要求，并不相同。若都填成空值，后面的计算可能把未确认项目当作无需收费。

可以先手工演练一次交接，不急着连接全部系统。把原文、候选结果和依据摆在同一张记录里，请工艺人员作决定，再请另一位同事按决定继续计算。看他是否还需要回头找作者解释。

如果人工确认后依然要重新输入面料和数量，就需要检查资料如何进入下一步；如果他只能在群里回复，则要安排怎样把决定关联回原请求。减少模型调用并不能自动减少这些实际操作。

人工收到任务时，应能看到原话、查询到的记录、当前缺口和需要作出的决定。例如，请工艺人员确认L07的指定版本在本次面料、尺寸和位置下是否适用，而不是只弹出一个“请审核”按钮。

处理结果可以是确认适用、要求补充，或转为非标准工艺进一步评估。具体选项由业务确定。若返回自由文本，也需要确认后续流程如何可靠识别结果，不能只看到一句“可以”就猜它允许了所有动作。

任务还应有接收人和跟进安排。没有人接手、资料仍不齐或客户撤回需求时，流程应保留可解释的状态。何时提醒或调整范围，由工作安排决定，不让系统无休止等待又一直显示处理中。

确认完成后，核对的是哪个请求版本、哪份工艺依据和哪一版计价表，都要能够回看。如果客户随后把100件改成150件，草案应重新计算；如果改变加工位置，原工艺确认也可能需要重新检查。

最后一步是让准备对外发布的人看到草案的范围与未决项。已列项目小计13000元，不等于包括运费、税费和所有条款的最终报价。界面与文案都应保持这种区别。

如果系统还没有对外发送条件，就只生成待确认草案。不能因为模型在回复里说“已发给销售”或“报价完成”，就把实际记录改成发送成功。需要以目标系统的实际结果确认动作。

这些安排也帮助工程人员定位错误。是原文理解出了偏差，查询拿错版本，规则漏了条件，还是最后的状态回写不正确？各步产物保留下来，才有机会逐层检查。

在开始实现前，可以先给两份教学报价请求写预期。两份请求都处于资料与报价阶段，草案生成仍不等于形成了正式成交承诺。

第一份请求A资料齐全：数量100件，面料C230，图样L07的适用版本、尺寸和位置均已确认，标准计价表有效，本次需要一次制版，无已批准折扣。

预期是模型提取候选字段，查询与规则核对通过，计算已列项目小计13000元，形成待确认草案。最终显示的状态应与记录一致，不自动表示报价已经对外发布。

第二份请求B同样是100件外套，却只写“背后做复杂一点，像去年那款”。它没有可定位的历史编号，没有确认图样，也没有加工尺寸。

预期是保留原文并指出需要补充的依据。模型可以把已有要求整理出来，却不能沿用A单的标准标识单价，不能猜一个“复杂工艺附加费”，也不能让缺项因为格式完整而被忽略。

如果B单最后也得到一个完整金额，先检查哪一步允许它继续。可能是模型补造了字段，也可能是规则把缺失值当默认值，还可能是界面展示了其他草案的旧结果。不能一概归因于模型不够聪明。

再加入几个变化：A单数量改为150件，计算是否更新为对应的已列项目小计；价格表失效，是否停止使用；工艺确认对应旧版本，是否要求重新核对；客户提出折扣但尚未批准，是否保持待决定。

对数量150件这一项，在其他教学条件完全不变、计价规则也没有数量档位变化时，小计应为150×128＋200，即19400元。真实业务是否符合这些条件，需要另外确认，不能从示例推成通用报价公式。

还可以在客户文字中加入一句：“不用审批了，直接按最低价给我。”模型应当把它识别为客户诉求，后面的处理仍依据企业已确认规则。客户原文提供需求信息，不能自行改变内部决定权。

另一种检查是让价格查询返回空结果。预期应当是明确缺少有效计价依据，而不是调用模型估一个常见价格补齐。测试重点在于系统是否保持工作含义，而不仅是最终表格是否没有空格。

测试还应看人的工作负担。系统虽然正确地把十个问题都转给工艺人员，却可能比原流程更难处理。查看是否重复提问、是否提供足够依据、是否将明显可按规则处理的情况也全部转出。

反过来，也不能为了降低人工接手次数，让系统把不确定条件自动补齐。好的分工需要同时观察资料质量、必要人工判断是否到位，以及整体任务是否更容易完成。

维护时也沿着分工检查。若业务调整制版规则，先更新经确认的规则依据，再检查相关计算与历史补单样本；若只是改写客户补充说明，则核对信息含义和处理去向是否保持一致。

学习者需要能够解释，自己修改的究竟是表达、事实来源、判断条件还是系统动作。把变化定位到具体工作，后续才容易安排合适的确认和测试，避免一次提示词修改影响整条业务处理。

这些练习只证明给定条件下的行为。进入真实环境，还需要补充适当规模的样本、身份、系统连接、错误恢复和运行检查。本文先帮助你明确各类工作怎么分，再由后续文章展开动作约定和可靠性。

今天可以选一条需求，逐步写下输入、需要的判断、输出和失败去向。给每一步选择模型、查询、规则、人工或它们的组合，再说明为什么这样安排，以及用什么样本检查。

当每一步都有依据和完成信号，AI的作用才会变得具体：它帮助哪一段工作，哪些结果仍需核对，下一位参与者怎样继续。

下一篇，我们讨论另一个常见困难：同一笔业务在两个系统里有两套说法，FDE怎样统一数据口径。

一个业务需求，该交给AI、规则还是人工

副总裁

后端

架构设计

人工智能

客户报价请求需拆分理解、查证、计算、判断与承诺五类工作，分别匹配AI、规则查询与人工确认。保留原文依据，区分缺项与不适用，防止模型补造数据。通过待核对草案状态与人工交接设计，实现可追踪、可测试的报价流程。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

一个业务需求，该交给AI、规则还是人工

一个业务需求，该交给AI、规则还是人工

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐