CPQ实践

“能不能让聊天机器人先顶上？”销售问。“不行，除非它能保证我们卖出去的东西造得出来。”运营答。 双方都对。你需要AI的灵活性来快速捕捉杂乱的需求，也需要规则的确定性来确保每份报价都可制造、可定价、可落地。想同时实现这两点，不是做取舍，而是做叠加。 一个经常被忽略的简单思路是：在确定性的规则层之上，再加一个对话层。让AI负责对话，让规则负责决策。 双层架构为何优于单层 CPQ项目的大多数痛点，不在于界面或功能，而在于信任。销售需要确信配置方案有效，财务需要确信价格算得准，产品部门则需要确信规则不会在项目紧急时被轻易绕过。 生成式AI擅长将邮件、PDF和零散笔记转化为清晰的客户需求。但它对同一问题的回答每天都可能不同。Gartner对此观点明确：生成式系统是概率性的，用于生产流程必须有“护栏”。这种不确定性适合探索，却是报价的风险。 而基于规则的配置器正好相反。它们一致、可审计，但有时也过于死板。它们从不猜测，只会阻拦。 AI收集意图，规则验证可行性。 将两者结合，你就能在不牺牲准确性的前提下获得速度。 双层CPQ架构如何运作 在销售复杂产品的实际项目中，我带队采用这种方法。流程被刻意设计得很“无聊”——当涉及真金白银时，“无聊”意味着可靠。 第一层：对话式捕捉。 大语言模型(LLM)通过对话、阅读和整理，处理前端模糊的需求、限制、偏好和权衡。它能用自然语言提问澄清，并指出矛盾之处，最终生成结构化的需求清单。 第二层：确定性验证。 符号引擎（Symbolic Engine）强制执行硬性约束和定价规则。它根据预设的有效组合、依赖关系和价格逻辑，来检验需求清单，最终返回一个有效的配置方案，或指出需要解决的具体冲突。 这不是AI与规则的对立，而是AI在前，规则在后。 几个设计原则能确保这套方法在真实世界中行之有效： 关注点分离： 需求捕捉是自由的，配置验证则不是。保持两者分离，避免用引擎的特定逻辑污染原始需求。 可解释性追溯： 对每个通过或被否决的选项，都要记录“为什么”。LLM可以将引擎返回的错误信息翻译成用户能懂的语言。没有解释，系统就没人用。 可组合的接口： 在两层之间设置一个轻量级API，便于在不重构整个系统的情况下，更换对话界面、规则引擎或定价模型。 测试套件，而非演示： 像对待代码一样对待规则。进行版本管理、自动化测试，并在每次发布时公布测试结果。演...