能力清单提出之后，还需要进一步的解释
上一篇讨论的是：AI 时代的 FDE，稀缺的不是多写几行代码，而是综合交付能力——编码、数据技术、大模型深度使用，以及相对特定行业业务的理解；本体项目又处在数据基础设施、多智能体、业务建模的交叉面上。
下面两篇文章以最近很热门的决策智能领域为例，解释这些综合交付能力具体指什么？
本文主要包含两部分：一是企业决策职能体系的组成与运行骨架；二是尝试对以决策为中心的平台能力展开讨论。
一、决策智能在解决什么
决策智能这类说法，核心并不神秘：组织希望把重要业务决定，从散落在报表、会议纪要和聊天建议里的状态，变成可设计、可比较、可批准、可执行、可复核的过程。
它通常要求几件事同时成立：
-
决策本身能被显式说清楚——对象是什么、目标是什么、约束是什么； -
方案能被编排与执行，而不停在口头建议； -
过程可监控，关键步骤可解释、可审计； -
执行结果能回来修正下一次判断。
这与「再上一个预测模型」或「再接一个大模型聊天窗口」不是同一个命题。
上一篇说的综合交付能力，正是为了覆盖这类命题里的交叉领域：既要懂业务与约束，又要把数据对齐到业务对象，还要把执行状态写进业务系统，并用模型提高草案与编排效率——同时守住审批与验收这两个关键动作。
二、一个可核对的反例：预测或建议为什么不够
我们以一个供应链中常见的补货场景为例：在促销前夜，我们希望检查一些冷链营养品所在的目标仓库是否缺货。业务人员真正要回答的，往往是一串连在一起的问题：
现在要不要补？补多少？向哪个供应商采购？能否需要调拨？预算与仓容是否允许？谁来批准？写入业务系统后是否真的能创建补货单？事后怎样判断这次决定是否正确？
此时，若系统只给出：
未来七天需求中位数约 980 件，区间约 820–1,180 件。
或聊天界面只给出：
建议补货 1,000 件。
这两类输出都有价值，但这不构成一次完整的决策。原因可以逐条核对：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
因此，综合交付能力在决策智能题域里的第一层含义是：
能把一次业务决定，推进到约束可检查、人可批准、系统可回执的阶段——而不是停在预测报表或聊天建议。
三、上一篇文章中提到的各项能力指什么
下表是对上一篇能力清单的解释。每一行都尽量对应可观察产出，便于理解。
|
|
|
|
|---|---|---|
| 编码能力 |
|
|
| 数据技术熟悉度 |
|
|
| 大模型深度使用 |
|
|
| 行业业务理解 |
|
|
除了上面的能力以外，在决策智能里同样关键的综合能力：
|
|
|
|
|---|---|---|
| 编码/数据技术/大模型使用/行业理解 |
|
|
|
|
|
|
重要原则： 业务理解往往是可复用的门槛（因为业务知识通常是相对静态的）；真正长期消耗精力的，仍是数据对齐、编码与验收标准、以及模型使用能力。
四、这些能力的组成与运行主线
现在我们还需要一张系统由什么组成、一次决策怎样跑完的地图，否则能力会重新变成口号。
企业决策智能体系用两条主线描述同一件事：
- 组成主线：决策智能由什么构成
七层自上而下可以读成：业务要决定什么 → 应用如何承载责任 → 决策智能内核如何比较行动 → 智能体如何组织任务 → 模型如何提供理解与预测 → 本体与数据如何描述业务世界 → 计算基础如何支撑表示与约束下的选择。权限、审计、合规与人工审批横切各层。
综合能力并不是漂在系统之外的软实力，而是分别压在这些层上的工程动作。
例如：业务理解主要落在场景与决策定义；数据技术主要落在本体与数据及接入；编码主要落在应用、执行与写回；大模型深度使用主要落在草案、编排与可解释，且必须受下层对象与动作的约束。
-
执行流程：决策智能如何运转起来
九步描述一次决策的运行顺序：触发 → 定义 → 状态理解 → 候选方案 → 后果预测 → 方案评价 → 选择与审批 → 执行与协同 → 反馈与学习。
用它核对很直接：
-
只有触发和预测，没有定义与约束 → 还是报表； -
有方案文案，没有审批与执行回执 → 还是建议； -
有执行，没有反馈 → 难以证明这次决定是否有效，也无法改进下一次决策。
上面的两张架构和流程图中的七层结构决定了由什么组成，九步流程图回答了这套结构式如何运行的。综合交付能力，就是 FDE（或承担同等职责的人或团队）能否在现场推动九步跑完，并让七层中的关键缺口被盖住。
多智能体在这里扮演什么角色
决策智能讨论里常出现智能体。上一篇已强调：多智能体不是多个模型自由讨论。下面的任务图，以一个供应链领域的补货场景，把这一点画得更清楚——任务有依赖、结果有契约、工具有权限、失败可转人工。
因此，大模型深度使用这件事儿在决策智能里的可验证含义，至少要包括：
-
会不会把复杂决策拆成有职责的任务，而不是一轮超长对话； -
会不会让输出接受对象、动作与权限约束； -
会不会在该人工审批的步骤停住，而不是自己生成一段文字描述就完了。
编码能力与验证，在这里表现为：契约校验、权限控制、失败重试与转人工路径是否真的存在。
六、交付检查
行业讨论以决策为中心的平台时，常见能力维度可以概括为六类（表述按工程理解归纳，便于自检）：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这六类不是采购口号，而是一个checklist。上一篇文章说的综合交付能力，正对应谁来盖住这些检查项：一个人能力覆盖越全，小队可以越小；缺哪一块，项目就更容易停在 Demo，无法交付。
也可收成四条更短的业务验收语言：
可解释、可审批、可执行、可反馈。
四条都成立，才比较接近决策智能交付；只满足前两条，多半仍是分析或演示。
结语
上一篇给出综合交付能力的清单与交叉面。本文用决策智能作为题域，做了三件可核对的事：
-
用补货反例说明：预测与聊天建议不等于交付； -
把四项能力翻译成决策场景中的动作与产出； -
用七层组成、九步运行过程与多智能体任务图，标明这些能力落在系统的何处，以及交卷时应检查什么。
当写代码的成本越来越低，稀缺的仍是能把一次业务决定收敛成可运行系统的人。
下一篇文章会讨论：七层与九步如何变成现场施工顺序，以及一次补货决策怎样从触发走到回执。
