决策智能热起来之后：FDE 的「综合交付能力」到底指什么

能力清单提出之后，还需要进一步的解释

上一篇讨论的是：AI 时代的 FDE，稀缺的不是多写几行代码，而是综合交付能力——编码、数据技术、大模型深度使用，以及相对特定行业业务的理解；本体项目又处在数据基础设施、多智能体、业务建模的交叉面上。

下面两篇文章以最近很热门的决策智能领域为例，解释这些综合交付能力具体指什么？

本文主要包含两部分：一是企业决策职能体系的组成与运行骨架；二是尝试对以决策为中心的平台能力展开讨论。

一、决策智能在解决什么

决策智能这类说法，核心并不神秘：组织希望把重要业务决定，从散落在报表、会议纪要和聊天建议里的状态，变成可设计、可比较、可批准、可执行、可复核的过程。

它通常要求几件事同时成立：

1. 决策本身能被显式说清楚——对象是什么、目标是什么、约束是什么； 
2. 方案能被编排与执行，而不停在口头建议；
3. 过程可监控，关键步骤可解释、可审计；
4. 执行结果能回来修正下一次判断。

这与「再上一个预测模型」或「再接一个大模型聊天窗口」不是同一个命题。

上一篇说的综合交付能力，正是为了覆盖这类命题里的交叉领域：既要懂业务与约束，又要把数据对齐到业务对象，还要把执行状态写进业务系统，并用模型提高草案与编排效率——同时守住审批与验收这两个关键动作。

二、一个可核对的反例：预测或建议为什么不够

我们以一个供应链中常见的补货场景为例：在促销前夜，我们希望检查一些冷链营养品所在的目标仓库是否缺货。业务人员真正要回答的，往往是一串连在一起的问题：

现在要不要补？补多少？向哪个供应商采购？能否需要调拨？预算与仓容是否允许？谁来批准？写入业务系统后是否真的能创建补货单？事后怎样判断这次决定是否正确？

此时，若系统只给出：

未来七天需求中位数约 980 件，区间约 820–1,180 件。

或聊天界面只给出：

建议补货 1,000 件。

这两类输出都有价值，但这不构成一次完整的决策。原因可以逐条核对：

因此，综合交付能力在决策智能题域里的第一层含义是：

能把一次业务决定，推进到约束可检查、人可批准、系统可回执的阶段——而不是停在预测报表或聊天建议。

三、上一篇文章中提到的各项能力指什么

下表是对上一篇能力清单的解释。每一行都尽量对应可观察产出，便于理解。

除了上面的能力以外，在决策智能里同样关键的综合能力：

重要原则： 业务理解往往是可复用的门槛（因为业务知识通常是相对静态的）；真正长期消耗精力的，仍是数据对齐、编码与验收标准、以及模型使用能力。

四、这些能力的组成与运行主线

现在我们还需要一张系统由什么组成、一次决策怎样跑完的地图，否则能力会重新变成口号。

企业决策智能体系用两条主线描述同一件事：

• 组成主线：决策智能由什么构成

七层自上而下可以读成：业务要决定什么 → 应用如何承载责任 → 决策智能内核如何比较行动 → 智能体如何组织任务 → 模型如何提供理解与预测 → 本体与数据如何描述业务世界 → 计算基础如何支撑表示与约束下的选择。权限、审计、合规与人工审批横切各层。

综合能力并不是漂在系统之外的软实力，而是分别压在这些层上的工程动作。

例如：业务理解主要落在场景与决策定义；数据技术主要落在本体与数据及接入；编码主要落在应用、执行与写回；大模型深度使用主要落在草案、编排与可解释，且必须受下层对象与动作的约束。

• 执行流程：决策智能如何运转起来

九步描述一次决策的运行顺序：触发 → 定义 → 状态理解 → 候选方案 → 后果预测 → 方案评价 → 选择与审批 → 执行与协同 → 反馈与学习。

用它核对很直接：

• 只有触发和预测，没有定义与约束 → 还是报表；
• 有方案文案，没有审批与执行回执 → 还是建议；
• 有执行，没有反馈 → 难以证明这次决定是否有效，也无法改进下一次决策。

上面的两张架构和流程图中的七层结构决定了由什么组成，九步流程图回答了这套结构式如何运行的。综合交付能力，就是 FDE（或承担同等职责的人或团队）能否在现场推动九步跑完，并让七层中的关键缺口被盖住。

多智能体在这里扮演什么角色

决策智能讨论里常出现智能体。上一篇已强调：多智能体不是多个模型自由讨论。下面的任务图，以一个供应链领域的补货场景，把这一点画得更清楚——任务有依赖、结果有契约、工具有权限、失败可转人工。

因此，大模型深度使用这件事儿在决策智能里的可验证含义，至少要包括：

1. 会不会把复杂决策拆成有职责的任务，而不是一轮超长对话；  
2. 会不会让输出接受对象、动作与权限约束；  
3. 会不会在该人工审批的步骤停住，而不是自己生成一段文字描述就完了。

编码能力与验证，在这里表现为：契约校验、权限控制、失败重试与转人工路径是否真的存在。

六、交付检查

行业讨论以决策为中心的平台时，常见能力维度可以概括为六类（表述按工程理解归纳，便于自检）：

这六类不是采购口号，而是一个checklist。上一篇文章说的综合交付能力，正对应谁来盖住这些检查项：一个人能力覆盖越全，小队可以越小；缺哪一块，项目就更容易停在 Demo，无法交付。

也可收成四条更短的业务验收语言：

可解释、可审批、可执行、可反馈。

四条都成立，才比较接近决策智能交付；只满足前两条，多半仍是分析或演示。

结语

上一篇给出综合交付能力的清单与交叉面。本文用决策智能作为题域，做了三件可核对的事：

1. 用补货反例说明：预测与聊天建议不等于交付；  
2. 把四项能力翻译成决策场景中的动作与产出；  
3. 用七层组成、九步运行过程与多智能体任务图，标明这些能力落在系统的何处，以及交卷时应检查什么。

当写代码的成本越来越低，稀缺的仍是能把一次业务决定收敛成可运行系统的人。