FDE 落地手记 · 02
在业务现场，很多工作看起来只是一张表、一份简报或一个设计结果。真正开始自动化时，才会发现结果背后藏着大量没有写下来的判断。
财务知道某一笔费用为什么不能这样分摊，运营知道某个渠道的订单状态需要特殊处理，设计师知道产品信息应该以什么顺序呈现。这些经验需要被逐步解释、验证并转成可执行的工作流。
我把这个过程理解为 FDE 的一项核心工作：和业务人员一起，把隐含的判断整理成可检查、可维护的交付过程。下面以财务结算和商品详情页策划两个场景说明具体方法。
一、先收集真实完成过的样本
需求访谈可以从三份材料开始：一份正常完成的结果、一份被退回修改的结果、一份需要人工特殊处理的结果。
正常样本说明合格交付是什么样；退回样本说明哪些错误不能接受；特殊样本暴露流程边界。只看成功样本，容易把业务规则理解得过于简单。
以结算表为例，除了表头，还需要追问：
- 金额来自交易订单、资金流水还是最终结算单？
- 合同适用哪个主体、哪个时间段，期间是否发生变更？
- 退款、补贴、税额和差额调整分别如何处理？
- 总表怎样追溯到明细，明细怎样追溯到原始记录？
- 哪类异常允许继续生成草稿，哪类必须停止？
这些答案应由对应业务负责人确认。技术人员负责把规则变得明确，不能独自替财务决定业务政策。
二、把专家判断拆成四种规则
| 规则类型 | 例子 | 合适的实现方式 |
|---|---|---|
| 事实规则 | 合同主体、佣金率、生效日期 | 来自受控数据源，保留版本 |
| 计算规则 | 金额汇总、税额、分摊、舍入 | 确定性的程序与校验 |
| 判断规则 | 条款含义、异常文本分类 | AI 辅助，提供依据并允许复核 |
| 决策规则 | 是否确认结算、是否对外发送 | 明确到有权限的业务人员 |
这样拆分后，模型可以帮助理解自然语言和组织结果，精确金额则由规则计算。模型输出“看起来正确”的总额，不能替代逐项计算和对账。
货币计算还应明确单位、精度、舍入时点和尾差处理。逐单四舍五入后求和，与先求和再四舍五入，可能得到不同结果，必须沿用确认过的业务约定。
三、为每一步写清输入、输出和失败状态
一个可复用流程至少需要以下契约。下面是设计示例，不是某个特定软件的配置语法：
workflow: settlement_draft
version: 1.0.0
input:
entity_id: required
period: required
source_snapshot: required
contract_version: required
steps:
- load_authorized_records
- validate_entity_and_period
- match_effective_contract
- calculate_amounts
- reconcile_summary_and_details
- create_draft_and_exception_list
output:
- summary
- account_details
- order_details
- exceptions
- provenance
gate:
missing_contract: stop
unresolved_difference: require_review
external_release: require_authorized_confirmation
关键在于流程能明确地表达“此处不能继续”。如果合同未匹配，却用默认佣金率生成了一份完整表格，自动化只是把问题隐藏得更深。
四、让错误在中间步骤暴露
可以在流程中设置三道检查：
- 输入检查：必填字段、时间范围、主体与数据权限是否满足。
- 转换检查：匹配数量是否异常，是否出现重复订单、未知 SKU 或不适用的合同。
- 输出检查：汇总与明细能否勾稽，异常是否完整列出，交付物是否包含来源版本。
例如，结算总表金额应当能够追溯到分账明细，分账明细应当能够追溯到纳入计算的订单集合。对不上时，应输出差异记录，而不是让模型重新解释一个总额。
对于长时间运行的流程，每一步还应保存状态。失败后从已经验证的步骤恢复，可以减少重复取数和重复生成。
五、商品内容工作流，也需要同样清晰的检查点
在商品详情页策划中，我关注的一条路径是：产品资料、信息核实、策略整理、黑白线稿、视觉制作、人工验收。
黑白线稿的价值在于先暴露信息结构。卖点证据不足、模块顺序不合理、使用场景不明确，都可以在投入最终制作前调整。
| 阶段 | 主要产物 | 需要检查的内容 |
|---|---|---|
| 产品资料整理 | 事实与证据清单 | 型号、参数、检测依据、适用范围 |
| 策略整理 | 人群、问题与卖点关系 | 卖点是否回应真实需求，有无过度推断 |
| 黑白线稿 | 页面模块和信息层级 | 首屏重点、证明顺序、重复和遗漏 |
| 视觉制作 | 页面图片及可编辑素材 | 产品细节一致性、文字和画面准确性 |
| 验收 | 修改记录与采用版本 | 是否满足品牌与发布要求 |
生成图片时，产品结构、参数和功效信息需要单独核实。视觉表现可以探索，事实依据应当来自确认过的资料。
六、把流程封装成 Skill，需要同时交付维护办法
一个成熟的流程包可以包含：用途、适用范围、输入格式、规则来源、步骤、输出模板、检查条件、异常样例、依赖接口、权限要求和版本记录。
“在另一台电脑上也能运行”只是可迁移的一部分。还需要确认接口兼容、身份权限和数据版本。共享一份提示词，不能保证所有人生成的是同一口径的结果。
业务人员可以修改个人表达和模板样式；影响计算和事实判断的变更，应当进入共同维护的规则版本。
七、怎样验证这份经验被有效复用了
可以选一组正常、边界和异常样本，让业务人员先确认预期结果，再运行流程比较：哪些结果直接接受，哪些需要修改，哪些应该停止却继续了。
评估不应只统计生成时间，还要统计复核时间、返工原因和错误类型。一个生成很快、但需要专家逐项重做的流程，还没有实现稳定复用。
当非原开发者能够按照说明完成任务、识别异常、找到维护人，这套工作流才开始具备组织能力。FDE 在其中交付的，既包括可运行的软件，也包括业务经验被解释、验证和维护的方式。
