研究关注的是没有写出来的业务规则
FDE-Bench预印本介绍了49个来自客户项目的任务，以需求澄清和迭代交付为评估对象。实验让智能体向模拟客户获取遗漏信息，再由任务评估器检查成果。本文仅据此讨论工作方法，不把实验结果解释为所有模型或所有企业项目的能力排名。
这一设定提醒我们，客户最初的话往往包含业内默认的前提。即使智能体严格执行了文字指令，仍可能做出业务上不能接受的安排。需要补充的信息不是越多越好，而是那些会改变方案选择和验收结果的规则。
先找到一个会产生分歧的具体例子
以下是本站设计的模拟情境：客户希望把同一公司的联系人合并，但销售人员实际需要区分总部与不同分支。若只按企业简称去重，结果看似整齐，却可能丢失负责不同区域的联系关系。这不是论文中的原始任务，而是用于说明问题的工作样例。
与其继续问“还有什么要求”，不如请客户判断两条具体记录是否应该合并，以及允许保留哪些例外。每得到一个回答，就记录它适用的条件、谁有权确认、它会改变什么操作。遇到互相冲突的说法，先找出对应岗位与场景。
将问答结果转成一组可以重复检查的材料
可以把确认过的规则做成短样例：原始输入、预期处理、例外原因和最终确认人。再准备表面相似但结果应不同的记录，检查系统有没有只记住关键词。这样，需求讨论留下的是可以执行的核对条件，而不只是会议纪要。
规则改变时，保存旧条件及改变原因，并重新跑受影响的样例。现场确实可能出现新的信息，交付团队应能说明“为什么这次结果与上次不同”，而不是用模型随机性解释所有差异。
澄清完成后，仍要验证方案能否用起来
知道规则并不保证代码实现正确、数据完整或运行时间可接受。小团队可以把验收拆成三个问题：规则是否被业务方确认，结果是否符合规则，用户是否能按既定步骤使用和接手。每个问题需要对应材料，不能用一张运行成功截图替代。
论文使用特定任务、模拟客户及实验设置，不能直接换算成本地客户满意度。对实际项目，更有价值的是保留从问题、回答到成果的对应关系。可结合FDE交付验收和项目交付记录整理自己的试点材料。