说不清需求，正在成为AI落地最常见的难题：FDE如何梳理企业AI需求？

企业开AI需求会时，白板很容易被写满：销售助手、合同审查、经营分析、自动报表。每个方向都有业务价值，也都能找到类似的产品演示。会议继续往下开，问题会落到很细的地方。销售助手要读CRM里的哪些数据，合同审查使用法务部哪一版规则，经营分析的数据口径由谁确认，Agent生成结果之后又交给谁处理，参会者给出的答案往往并不一致。

需求卡住，通常不是因为业务人员没有想法。很多企业工作本来就没有一份完整说明，它分散在系统字段、群聊记录和员工习惯里。同一件事换一名熟练员工来做，顺序可能不同，遇到例外时的处理也没有写进SOP。业务部门能够判断结果能不能用，让他们在项目启动时一次讲清所有输入、规则和异常，确实很难。

模型可以把一句模糊指令扩写成完整方案，这种能力反而容易掩盖需求缺口。Demo能够跑通，不代表工程团队已经知道系统应当如何处理下一笔真实任务。这里的FDE（Forward Deployed Engineer）会进入客户现场，把业务诉求还原成可开发、可验收的任务，需求梳理也从会议讨论转到真实工作中。

“做一个Agent”还不能直接进入开发

软件项目过去常用PRD描述页面、字段和接口，这套方法仍然有效，不过AI任务还要多写一层。Agent拿到的材料可能每次都不一样，模型输出存在波动，长任务还会调用多个工具。工程团队需要提前知道哪些变化可以接受，哪类动作越过了边界，以及结果由谁承担责任。

例如，采购部门提出“让AI审核供应商准入材料”。工程团队还不能据此估算工作量。准入材料从邮件进入还是从采购系统进入，会影响接入方式；审核如果只检查缺件，复杂度并不高，一旦包含主体信息核对和风险提示，就要确认数据源及规则版本。发现问题后，Agent可以生成核验清单，直接退回申请则涉及业务权限。这些差异不会在模型演示里自动消失。

右侧这些内容不太像功能，却直接影响项目能否进入客户测试环境。继续补页面原型没有太大帮助，团队需要找到一笔已经发生的工作，查看它从发起到结束究竟经过了什么。

跟着一笔真实任务走下去

访谈能拿到制度规定的流程，实际操作还会多出不少细节。采购专员收到材料后，也许会先翻看历史供应商记录；遇到股权信息不一致，会在群里找同事确认；采购系统缺少某个字段时，又从共享表格里补数据。这些动作已经成为熟练员工的习惯，一次会议很难完整回忆出来。

FDE会选几笔近期任务，跟着使用者走一遍。员工打开过什么材料，在哪一步停下来判断，判断时参考了哪个来源，处理结果后来交给了谁，都会被记录下来。点击次数只是操作痕迹，真正要写进需求的是决策依据。某项判断高度依赖资深员工的上下文经验，第一版就让Agent整理证据并给出候选结论，确认动作继续由员工完成。

顺利完成的样本能跑通主流程，退回记录更容易暴露缺失的规则。材料不完整时，当前流程究竟是暂停还是继续；内网接口超时后，员工是否会改走线下；两个系统的数据冲突时，哪一个来源具有最终效力。工程团队知道这些情况以后，才能设计任务状态、重试方式和接管位置。

原来宽泛的“采购Agent”，到这里会变成一项更窄的工作：

采购专员提交供应商材料后，Agent读取指定工作区内的文件，依据当前版本规则检查缺失项，生成带来源引用的核验清单；采购专员确认后，结果才进入准入流程。

这段话已经能够支撑工程设计。任务从哪里开始，Agent可以读取什么，交付物长什么样，哪个动作由员工完成，都有了边界。后续要不要增加主体信息核对，可以等第一条链路跑通后再决定，不必提前塞进同一个“大助手”。

第一版交付到真实用户手里

需求逐渐清楚以后，项目还要划定第一次交付的范围。FDE常用MVD，也就是Minimum Viable Delivery。MVP通常用于验证市场假设，MVD面对一个已知客户和已经存在的工作，交付结果要能在客户环境中完成一次真实任务。

工程师在自己电脑上读完几份样例文档，只能确认技术路线大致可行。进入客户测试环境后，问题才会具体出现：依赖包可能无法从外网下载，测试账号看不到目标目录，接口返回字段和样例不一致，日志里还可能写入原始敏感内容。早一点遇到这些问题，项目仍有空间调整；功能做完以后才处理，排期通常会被部署和审批拖住。

供应商材料核验的第一版可以只处理一种供应商类型，只接一个材料入口，也暂时不自动写回采购系统。一名采购专员使用自己的账号提交任务，Agent读取授权材料并生成清单，负责人完成确认，这条链路已经足够检验数据、权限和输出是否可用。批量处理和更多系统接入可以稍后安排。

范围缩小以后，业务人员的反馈也会变得具体。他们不再讨论“AI是否足够智能”，而会指出某个数据源已经过期，某条风险提示缺少出处，或者清单的排序不符合日常处理顺序。这些反馈能够直接进入下一次开发。

验收集要比提示词更早确定

有些项目在任务边界尚未稳定时，就开始反复修改提示词。某一轮输出读起来更完整，换一批材料又出现新的遗漏，团队很难判断迭代到底改善了什么。提示词可以继续调，前提是业务方已经准备好一批固定样本和判断口径。

初始验收集可以从近期任务中抽取。常规样本用于检查主流程，曾经被退回的材料保留下来测试边界，业务负责人再为每条样本标出可接受结果和必须拦截的错误。模型或Skill更新后，工程团队用同一批材料回归，避免只挑对当前版本有利的案例。

验收也不能只看回答内容。任务有没有走到结束，接口失败后能否从原位置继续，人工确认是否真正生效，调用内部系统时使用了哪个身份，这些记录都关系到投产。涉及敏感材料时，还要检查数据流向和日志内容。一次回答很漂亮，但执行过程无法复盘，业务负责人很难批准它进入下一阶段。

这样形成的需求比一份长PRD更容易执行。任务规格约束Agent做什么，验收集判断结果能不能用，运行策略限定它可以访问的数据和动作。三部分可以分别更新，又都关联到同一项业务任务。

现场经验怎样留在企业里

FDE如果只交出一份需求文档和一套定制代码，下一个场景仍会从头梳理。现场记录还要转成企业自己的可维护资产：已经稳定的处理方法封装为Skill，内部接口形成工具适配，业务负责人确认的边界进入任务配置，验收样本则作为后续回归的基准。部署过程遇到的异常，也应留在运行手册中。

凡泰AI的FDE团队可以协助客户完成首个任务的梳理和MVD验证，经过确认的方法再进入FinClaw，以Skill和任务配置的形式保存。产品只承接已经明确的业务约定，场景范围和验收标准仍由客户团队确认。

运行记录还会暴露访谈中看不到的问题。某一类输入反复退回，原因可能是业务规则没写清；任务总停在同一个接口，也可能是系统连接不稳定；规则更新后人工修改明显增多，团队就要检查新版Skill。下一轮工作究竟应该补数据、改规则还是缩小Agent的范围，可以根据这些记录决定。

从一笔真实任务开始

FDE能够把业务语言翻译成工程任务，验收结论仍由业务负责人作出。哪些错误可以接受，某项动作是否允许自动执行，结果出现争议时由谁处理，都需要在试运行中确认。

项目启动不必先向所有部门征集几十个AI场景。候选团队准备几笔近期完成的任务，其中包括原始输入、已经确认的结果和一份退回记录，FDE与实际使用者从中选出一条数据能够取得、结果容易验收的链路，先走完一次。需求在第一次会议上说不完整并不妨碍项目开始，开发之前要留下明确约定：Agent接手哪一段工作，依据什么材料，完成到什么状态，以及出错后由谁接管。