FDE场景选型：先找可闭环的工作，再决定部署什么

先准备业务证据，不从功能清单开始

深云实施建议：FDE前置部署的起点不是询问哪个模型更强，而是观察一项工作怎样从请求走到结果。企业应先提供经过授权和必要脱敏的任务样本、现行操作说明、参与岗位、系统清单以及近期出现的异常类型。样本既要包含顺利完成的任务，也要包含退回、补资料和需要主管判断的任务。只有成功样本，往往会把真正困难的业务分支隐藏起来。

访谈时把抽象目标改写成可观察的动作。例如，不写提升销售效率，而写销售收到询价后，需要从有效价目表查找产品、核对适用条件并生成待确认的回复草稿。继续问清请求来自哪里、结果交给谁、什么时候算完成，以及哪一步必须由有权限的人作决定。不能明确这些条件的需求，可以先进入流程梳理，而不是直接进入自动化开发。

把候选场景拆成同一种任务卡

每张任务卡至少记录触发条件、必要输入、预期输出、依赖数据、可执行动作、人工负责人和失败处理方式。对于订单查询与订单修改，不要因为都属于客服就放在同一张卡里：前者通常以读取和解释为主，后者涉及业务状态改变，授权与回滚要求不同。拆分后再评估，才能避免一个高风险动作拖住整个试点。

由业务负责人、系统负责人和实施人员分别判断工作量、规则稳定性、资料完备性、结果可检查性及错误后果。评分只用于暴露分歧，不应把所有维度机械相加。即使使用频率很高，只要存在无法隔离的敏感信息访问、不可逆操作或无人负责的结果确认，就应设为暂缓项。优先选择输入相对清楚、输出有人能核验、失败后能够回到原流程的候选任务。

先建立人工基线，再收紧试点边界

对入选任务记录原流程的实际操作步骤、人工处理时间口径、返工原因和结果质量。时间应区分实际操作与等待外部回复，否则把等待时间算作工具节省会造成误判。质量应区分信息是否准确、字段是否完整以及是否符合业务规定。保留原始记录，让后续比较有依据，而不是在演示结束后凭印象判断好用与否。

首轮任务书应明确限定部门、资料范围和允许动作，例如只对指定产品生成回复草稿，不自动发送，不调整报价，不扩展查询到其他部门。若考虑WorkBuddy或腾讯云生态相关能力，应先核实实际版本、权限、接口和部署条件，再决定实现方式。产品名称不能替代能力验证，演示环境能完成的操作也不能自动视为生产环境已具备。

用失败样本判断是否值得继续

小范围验证时主动加入缺字段、相互矛盾的资料、过期资料和越权请求，观察流程是否会停止、补问或转人工。若输出看似完整但依据不明，应视为需要处理的失败，而不是让业务人员凭经验兜底。对失败按输入缺陷、规则不清、权限不足、集成限制和判断困难分类；不同原因对应不同投入，不要统一归因于模型能力。

验收场景选型工作的交付物，不是可演示的聊天窗口，而是经相关负责人确认的任务卡、人工基线、样本目录、风险清单与进入试点的条件。条件不足时也要给出明确结论：补齐知识、协调接口权限、缩减动作范围，或保留纯人工流程。停止一个不合适的场景，同样能避免后续无效建设。

咨询从任务材料开始

深圳市深云科技技术有限公司可围绕WorkBuddy交付、FDE前置部署及腾讯云生态开展需求与实施条件咨询。建议咨询前准备一条完整工作链路、几类脱敏样本和明确的业务负责人，先讨论适不适合做，再讨论采用什么工具。本文属于深云实施建议，不代表已发生的客户案例，也不构成效果或交付周期保证。