企业官网建设流程全解析

FDE岗位实务指南 · 第08篇

“客户发来需求，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怎样统一数据口径。