别再急着画架构图：FDE 如何把现场说法变成工程证据

本文提出一个六分类框架，用于在 FDE 现场调研中对客户说法进行归类——愿望、事实、约束、风险、未知项和非目标项——强调证据纪律、可追溯性，以及在架构设计之前对未知项和权限的显式管理。

引言：过早架构化的陷阱

客户提出需求：要一个能自动识别异常订单、分析影响并给出处置建议的 AI Agent。技术团队往往立刻跳入方案设计——对接 ERP、MES、WMS、TMS，用大语言模型理解合同，编排工作流——产出架构图、接口清单和排期。然而，这个请求背后隐藏着一系列关键且未确认的问题：什么才算异常订单、哪个交期是权威口径、系统记录冲突如何裁决、谁有权调整排期和客户承诺、AI 建议可以走多远、哪些动作必须人工审批。如果这些问题悬而未决，一份详尽的架构图只会把未经核实的假设固化进系统设计。

核心原则：现场调研不是需求收集

FDE 的现场调研不是把客户的话整理成需求清单，而是把现场说法转化为带有来源、状态、责任人、验证路径，并能约束下游工程决策的证据。

与追问“什么问题值得解决”的业务调研不同，FDE 的证据纪律进一步要求：

这个结论从何而来，能否回溯到原始记录？

它在什么时间、版本和业务范围内成立？

不同角色或系统是否给出相互矛盾的答案？

谁有权确认业务事实、解释规则、批准权限、接受风险？

目前还缺什么证据，这个缺口阻塞了哪个工程决策？

如果暂时无法确认，我们是收窄范围、安排验证、升级上报，还是停下来？

驻场共创缩短了信息距离，但替代不了证据质量。会议次数、时长或响应速度，都不能证明团队已经找到了一个可工程化的问题。

一句话陈述里混着的六类现场信息

最危险的情况不是信息不足，而是性质不同的信息被记进同一份会议纪要，之后统统被当作“已确认需求”。本文提出一个六分类框架（作者的方法，并非行业标准）：

愿望——干系人期望的结果、功能或方案。记录内容：提出人、目标、背景、待验证问题。不能直接转化为架构或交付承诺。

事实——已经发生或当前为真，可通过记录、材料、系统或观察到的行为加以验证。需记录：来源、时间、版本、提供者、确认状态。不能仅凭会议共识或层级关系来确立。

约束——在当前范围内必须遵守的业务、数据、权限、合规、运营或技术边界。需记录：依据、适用范围、授权确认人、例外情况、复审条件。不能自动把习惯性做法变成强制规则。

风险——不确定事件可能造成的影响。需记录：触发条件、可能性、影响、责任人、应对与升级路径。不能只说“存在风险”而不做处理。

未知——缺乏证据、存在冲突或未经授权确认，导致无法做出明确判断。需记录：被阻塞的决策、验证方法、责任人、截止时间、超时处理。不能由 FDE、模型或开发人员自行回答。

非做项——本阶段明确排除、禁止或延后的对象、动作或承诺。需记录：排除依据、批准人、适用期限、复审条件。不能藏在口头协议或计划之外。

这些类别不是静态的文档栏目；它们会随着证据补充而改变状态。例如，“系统自动调整订单排程”最初只是一个愿望；在确认源系统、权限和审批要求后，一部分可能变为允许范围，另一部分可能因高风险而转入非做项。“ERP 交货日期是最终承诺”如果只是口头说法就不是事实；当合同、订单和延期审批相互冲突时，它应进入未知项，而不是让技术团队挑选最方便的字段。

现场发现产出：不只是访谈纪要

访谈纪要记录的是“谁说了什么”，但无法直接支撑架构、开发和上线关卡。FDE 必须产出一份可持续更新、相互可追溯的现场发现证据包，包含五个部分：

现场任务地图——以一个具体任务为中心，捕捉触发与结束、参与角色、使用的系统与材料、关键判断、正常与异常路径以及交接点。有效性的检验标准是：团队能否取一个正常案例和一个异常案例，沿时间线回溯到原始记录。

现场证据台账与领域语言表——每个关键条目都有 ID、类型、来源位置、时间与版本、提供者、确认人和当前状态。同一术语在不同部门/系统中有不同含义时，不得被悄悄合并；同一业务概念的不同名称必须由各自的业务负责人确认，而不是在会后凭经验统一。

未知项、风险与不做事项台账 – 未知项必须说明被阻塞的决策、证据责任人、完成期限和超时处理方式。风险需要触发条件、影响、责任人和应对路径。不做事项需要依据、批准人和复审条件。否则在进度压力下，“稍后确认”就会变成默认确认。

权限、人机协同节点与验证计划 – 系统读取权限不等于授予 FDE 或 Agent 解释业务事实的权力；写入权限不等于授予业务授权。每一项关键判断和行动都必须明确谁负责、谁批准、何时必须由人工接管。对于未确认事项，需定义样本、方法、通过/失败标准、停止条件和验证窗口。

下游可追溯链接 – 证据必须流入后续工程环节：事实、术语和语义冲突进入业务模型；数据/事务权限、系统限制、不做事项进入架构决策；能力未知项进入原型验证；身份、权限、交接节点进入 Agent 集成设计；基线、护栏、停止条件进入生产准入关卡。这套资料包的价值在于让每一个后续工程决策都能回答：它依赖什么、还有什么未确认、以及由谁接受了这个边界。

案例研究：异常订单场景展示证据如何约束工程

使用本系列合成的“制造企业使用 AI 辅助异常订单处理”场景（并非真实客户，尚无生产环境成果），团队进行了现场走查并产出证据片段，而不是立即分解为接口和功能。下表仅展示类型、内容和当前处理方式；实际台账还会记录来源、时间、版本、提供者、确认人和处理期限。

W-01（愿望）：系统自动判断订单能否按时交付并给出处置建议。 → 继续确认目标角色、使用节点、允许的辅助操作。

F-01（事实）：在合成的异常样本中，合同、ERP 订单和延期审批记录显示的交付日期不一致。 → 保留每个来源和版本；不立即选定权威值。

C-01（约束）：对外部客户承诺的变更必须由指定的业务负责人批准。 → 进入人工确认点和操作权限边界。

U-01（未知）：当合同版本、ERP 日期和延期审批发生冲突时，以哪个为准作为当前有效承诺尚未确认。 → 由业务和源系统负责人共同确认；在确认之前阻塞自动结论。

R-01（风险）：使用错误的日期可能导致误报、漏报或未经授权的客户承诺。 → 进入验证计划、风险护栏和停止条件。

N-01（非目标）：第一阶段不会自动修改 ERP 排程、采购计划或客户承诺。→ 纳入范围基线及后续系统边界。

这套证据集尚未回答目标架构问题，但它改变了工程的起点。如果没有证据纪律，团队可能会默认以 ERP 日期为准，开发跨系统聚合和异常判断逻辑，然后在集成阶段才发现合同版本、延期审批和客户承诺无法统一。返工将波及对象定义、判断逻辑、权限边界、评测样本和处置流程。有了证据包，团队保留冲突，明确谁有权解释当前承诺；在确认之前，他们可以验证物料提取和冲突识别，但不能自动生成最终履约结论，更不能修改排程或承诺。未知项变成控制工程范围的对象——触发补充证据、缩减范围、设定临时边界或停止。FDE 的价值不在于快速给出答案，而在于防止未经确认的答案进入生产系统。

什么时候可以开始画架构图？

现场调研无法消除所有未知项。真正的完成标准是：剩余的未知项已被显式管理，而不是伪装成确定的事实。在进入业务建模和架构权衡之前，至少要核实：

是否存在一个有明确起点、终点和排除范围的具体任务？

是否有正常和异常案例，而不仅仅是一个规定的流程？

关键事实是否可以追溯到数据、文档、日志、记录或观察到的行为？

不同角色和系统之间的冲突是否仍然可见？

每个未知项是否都有负责人、验证方法、截止期限和超时处理方式？

业务事实、数据权威、权限边界和风险接受是否已由各自授权方确认？

人机协同环节、失败路径和停止条件是否已记录？

关键证据是否已映射到后续的业务模型、架构决策或验证任务？

只有模板而没有真实内容，不代表现场调研已完成；只有最终结论而没有原始来源、冲突和确认过程，也无法证明其可靠性。AI 可以帮助转录访谈、聚类材料、提取术语、发现矛盾并生成待确认问题——这些都能加速信息处理。但来源可信度、冲突解决，以及哪些未知项会阻塞工程，仍需要 FDE 的判断和授权方的确认。AI 生成的结构完整的文档，不等于完整的现场事实。

现场调研的终点：可信的工程输入

FDE 进入现场，不是为了更快地把客户愿望转化为开发任务，而是为了厘清：哪些可以作为工程依据，哪些仍需验证，哪些必须由有授权的一方来决策，哪些不能进入本阶段的范围。只有这样，团队才有条件讨论下一步：如何把经过确认的现场事实与领域语言，转化为业务专家和工程团队都能追溯的业务源模型。这部分将在系列第 03 部分中展开。

参考资料

别先问用户要什么功能：业务研究如何发现真正的 AI 机会 (https://mp.weixin.qq.com/s?__biz=MzcwNDM2MTg3NA==∣=2247484240&idx=1&sn=36561f6ff06a9efc7a0a840a3176f7a4&scene=21#wechat_redirect)

OpenAI 成立 OpenAI 部署公司

北京市加快 Agent 牵头研发的相关措施

已登录的读者可通过 BestHub 的受保护跳转打开原文来源。

登录以查看来源

本文由原文内容提炼、总结后转载，仅供学习与参考。如您认为侵犯了您的权益，请联系我们，我们将及时处理。