为CPQ引入AI前，为何需要叙述性数据

大语言模型（LLM）知道什么是卡车，但它不懂*你家*的卡车。很多团队在现有CPQ系统上叠加AI时，都会遇到这个瓶颈。因为传统CPQ的数据只有SKU、属性和规则表，AI生成的答案看似流利，但缺乏深度推理。当销售问系统为什么会推荐某款驾驶室时，系统也说不出个所以然。

我在很多项目研讨会上都见过这种情况。一旦你为模型提供了清晰的上下文，解释了每个选项存在的场景和原因，对话的质量立刻就不一样了。系统不再是猜测，而是真正地提供建议。这背后不是什么AI魔法，而是给数据赋予了“叙事”能力。

你的数据里，缺了什么？

数据表告诉系统哪些组合是“有效的”，但没告诉它为什么某个选择是“明智的”，适用于何时，或在什么情况下是个糟糕的主意。这个信息鸿沟导致销售人员不得不依赖邮件、私人Excel表格和老师傅的经验来做判断，最后我们却把问题归结为“系统推广不力”。

AI推理层需要的不是更多的数据列，而是围绕每个选项、可被机器读取的**“意图”**：

• 用通俗语言解释选项的用途，而不仅仅是罗列技术规格。
• 明确列出优缺点，帮助使用者权衡取舍。
• 提供正反两方面的应用场景，让选项的价值落地。
• 说明该选项对成本、交期、服务或风险的潜在影响。

这是一个核心转变：产品营销内容不再仅仅是网站文案，它本身就是产品配置模型的一部分。当内容被结构化之后，AI才能用它来推理；否则，AI看似自信的回答，实则是在“幻觉”引导下凭空猜测。

从PIM到知识库

大多数产品信息管理（PIM）系统和价格手册在管理标识符、层级和定价方面做得不错。这能保证配置的“正确性”，但无法提供“指导性”。为了支持AI辅助销售，你的PIM系统需要升级成一个可供AI推理引擎查询的**知识库**。

分析师们越来越多地将“检索增强生成”（RAG）视为企业AI落地的一种基础模式。在CPQ领域，这意味着两件事：

• 将硬性约束条件保留在明确的逻辑层，确保系统永远不会生成无效的产品组合。
• 为每个选项补充简短、一致的叙事性字段，让AI能够回答问题、权衡利弊，并生成可解释的推荐。

做好了这两点，聊天机器人或引导式表单就不再是玩具。它会变成一个可被持续训练的销售助手，真正反映你的产品在真实业务场景中的运作方式。

如何构建用于AI推理的叙事性数据

原则是：简单、简短、一致。我们的目标不是写小说，而是为AI提供**可靠的信号**，让它能在不同对话中复用。

模块级字段

• 模块用途：用两句话说清这个模块的功能。
• 选型指南：阐述选择该模块的关键决策点。

选项级字段

• 简要描述：一到两句客户听得懂的话。
• 优点：最多3条，必须是能改变业务结果的好处。
• 缺点：最多3条，销售代表必须了解的真实权衡。
• 适用场景：1至3个具体的使用场景。
• 避开场景：1至3个具体的应避免的场景。
• 潜在影响：成本、交期、服务、兼容性等注意事项。

具体案例

模块：驾驶室

• 用途：为驾驶员提供操作环境，并为休息或存放设备提供空间。
• 选型指南：根据工作循环、法规要求的休息时间、是否过夜和城市准入限制来决定。

选项：卧铺驾驶室

• 描述：带有集成铺位的加长驾驶室，供夜间休息。
• 优点：满足长途运输合规要求；提升驾驶员舒适度；减少酒店开支。
• 缺点：更重；价格更高；可能影响在狭窄市区的机动性。
• 适用场景：单程超过500公里的路线；频繁过夜；长途货运。
• 避开场景：密集的城市配送；严格的限高区域；短途班次。
• 潜在影响：交期增加2周；建议与4x2或6x2驱动形式匹配；不适用于低顶底盘。

来自一线实战的两点提醒：

• 写作对象是一个聪明但从未接触过你产品的销售人员。允许使用术语，但不允许不加解释地使用。
• 每个选项的叙事内容控制在100字左右。过长的文本会稀释信号，干扰AI检索的准确性。

支撑这套方法的架构

叙事性数据只有与规则“护栏”结合时才强大。我推荐的成功模式如下：

• 显式逻辑层：你现有的CPQ规则和约束，保证配置的正确性和确定性。
• 叙事知识库：结构化的描述性字段和精选文档，可通过检索查询，内容聚焦于销售场景。
• 推理接口：通过聊天或引导式表单提问、引用来源并提出替代方案。
• 可解释性：展示哪些规则和叙事内容影响了最终推荐，以便销售代表能为报价辩护。

AI应该叠加在显式逻辑**之上**，而不是取而代之。没有规则约束，你得到的是流利的猜测；而有了规则和紧凑的知识库，你得到的才是可以放心交付给一线团队、并且可解释的指导。

强大的系统会把“正确性”和“叙事”分开。规则保证不出错，叙事让你跑得快。

这个季度，从哪里着手？

你不必推倒重来。你需要的是在产品、市场和CPQ负责人之间建立更紧密的协作闭环。

• 圈定10个最畅销的配置路径：找到那些在多数成功报价中出现的模块和选项。
• 为每个模块撰写“模块用途”：最多两句话。
• 丰富每个选项的叙事内容：包括描述、优缺点、适用/避开场景和潜在影响。
• 记录负面建议：告诉别人“什么时候不该用”往往是最有价值的指导。
• 明确硬性约束：确保逻辑层能阻止任何无效组合，无论AI怎么建议。
• 搭建一个可检索的知识库：利用供应商提供的知识服务或向量索引来存储这些叙事内容和少量精选PDF。
• 开发一个简单的推理界面：哪怕只是针对一条产品线的试点聊天机器人或引导表单，也能让你快速学习。
• 衡量改进效果：对比实施前后，销售代表需要多长时间才能得出一个站得住脚的配置推荐和最终报价。

如果你已经有CPQ系统，不要推倒重来。在现有产品定义中增加叙事字段，然后把它们喂给一个带检索功能的推理层。如果你还没有CPQ，就从叙事内容和几条核心规则开始，逐步扩展。

滚雪球式的优势

投资于叙事性数据的团队会看到两种复利效应：

• 可解释的速度：配置过程不再卡壳，与工程部门的反复沟通减少，向客户解释方案也更快。
• 更优的定价决策：应用场景让高价选项的价值一目了然，客户更容易理解总体拥有成本的优势，而不仅仅关注前期价格。

而且，这套方法是可维护的。当产品更新时，你只需要更新两个地方：保证正确性的硬规则，和提供指导的简短叙事。系统之所以能持续“学习”，是因为它的设计初衷就是为了同时被人类和机器阅读。

当系统既能推理又能解释时，销售手里的那张Excel表，就真的可以扔了。

在过去二十年里，我看到太多团队试图将他们从未书面记录下来的判断自动化。教训很简单：如果你想让AI在CPQ领域真正帮上忙，就得给它一些值得推理的东西。你的产品数据需要叙事。你团队里，谁来负责撰写它？