销售“下一步行动”：规则、决策模型与生成式模型的分工

下一步该做什么？

规则、决策模型与生成式模型的分工

文章讨论的问题

这篇文章从销售人员每天都会遇到的问题出发：面对一份客户清单，下一步该联系谁、怎么联系。作者用一个基于 Microsoft Foundry 的演示工作台来说明。演示把规则、GPT-4o 和 Microsoft-Decision-1 放在同一份证据上比较。文中的客户和证据都是合成数据，托管模型的响应则是真实调用得到的。

我的理解是，文章真正的重点不在谁胜出，而在“问题形态”如何决定合适的技术。

先划边界，再谈模型

演示里有几类容易误判的情形：金额最大的机会未必该先联系；建筑项目预算不等于软件收入；客户明确暂停联系时，配额压力不能抵消这一要求；身份未核实的申请人需要人工复核。作者的做法是由代码先执行联系限制、证据要求和身份检查，再接受模型建议。

这是文章对开发者最实用的提醒：不可协商的约束应当放在确定性代码里，而不是交给模型权衡。

三种机制各管什么

**规则。** 在例行场景中，三种方法给出了一致的排序和行动。此时规则不消耗模型 token，也最容易检查。事实已经明确、条件有限时，加入模型未必带来额外价值。

**决策模型。** 第二个场景中，两个账户都请求了会议，但一个只是探索性沟通，另一个已有资金到位的试点。固定公式把两者视为同样的信号。文章记录显示，Decision-1 与 GPT-4o 都把后者排在前面，规则则选了前者。Decision-1 的调用方式不同于聊天接口：应用先定义允许的行动与优先级量表，模型返回所选行动和分数，不生成文字理由。

**生成式模型。** 第三个场景要求给出含阶段、日期、成本和剩余预算的推进方案。只有生成式适配器负责产出方案，GPT-4o 借助计算工具处理预算，再由应用代码校验。文章提到，早期尝试出现过排期正确但成本错误的情况，应用拒绝了这些结果，修复办法是提供算术工具，而不是放松校验。

作者分析：怎样用这个框架

我认为文章最有价值的是一张对应关系：显式结构化事实用规则；在已知选项内做情境判断用有界决策模型或结构化输出的 LLM；需要产出方案等内容时用带工具的生成式模型，必要时用专用求解器。文章也承认，这个排期问题用专用调度器同样能解。

对开发者而言，可以这样落地：

选一个用户已在做的决策，列出可选行动。

找出不可协商的边界并写成代码。

先实现最简单够用的方案，再与替代方案对比。

校验输出，而不只依赖输出格式合法。

演示的局限

文章自己强调了几点限制。结果是单次运行观察，不是通用的速度、质量或成本基准；规划任务做了更多工作，与决策任务的延迟不可直接比较。场景使用固定的模拟时间和来自 Azure AI Search 的合成快照，不是实时 CRM 数据；工作台只生成可编辑的草稿，不发送外联，也不修改 CRM。文中的“最优”只是在给定证据和评分标准下的建议，不代表销售成功的预测。

值得继续观察

在真实数据和留出评测集上，决策模型相对规则与 LLM 的收益是否稳定？我目前没有证据，这只是待验证的问题。

没有文字理由的输出，如何满足销售团队的可解释与审批需求？

该模型类别的访问方式、定价和可用范围，需要以官方文档为准。

来源

Microsoft Foundry Blog：Implementing Next Best Action (NBA) in Foundry with Microsoft-Decision-1（2026-10-22），https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/implementing-next-best-action-nba-in-foundry-with-microsoft-decision-1/4565653