首屏结论：产品选型知识库不能只是“把 PDF 丢给 AI”。可靠方案要拆成三层：事实库保存可追溯的产品参数、认证、兼容关系与版本；规则引擎按功率、容量、地区、场景和状态确定性推出型号与 BOM；Agent 负责理解需求、追问缺项、调用检索与规则、解释证据和转人工。资料没覆盖就拒答，规则没覆盖就停止，不用相似产品猜一个答案。
问答和选型，是两种不同问题
“某型号的输入电压范围是多少”是事实检索；“某地区、某功率与容量需求应该配置哪些整机、附件和数量”是规则推理。前者要求找到正确版本的来源，后者还要执行分档、整除、兼容、地区差异、停产状态和必配件规则。
普通 RAG 可以提高找资料效率，但如果知识库里同时存在旧版规格书、图片版参数表、预发布资料和地区不同的手册，检索到相似段落也可能答错。关于 RAG 的基础边界，可先看什么是 RAG：企业知识库先管住知识边界；预算与维护问题可继续看企业知识库 3 档预算与 ROI。
三层结构怎么分
| 层 | 保存或执行什么 | 关键门禁 | 输出 |
|---|---|---|---|
| 事实库 | 型号、参数、单位、认证、兼容、状态、地区、来源 | 版本、适用范围、来源必须完整 | 可引用事实与冲突清单 |
| 规则引擎 | 分档、数量、整除、兼容、必配件、地区配置 | 输入齐全、规则版本确定 | 结构化候选或 BOM |
| Agent 与入口 | 理解自然语言、追问、调用工具、解释和协同 | 权限、拒答、人审、审计 | 带证据回答与受控业务动作 |
不要把三层揉成一个提示词。提示词可以约束回答语气，却不能替代版本关系、唯一料号、金额计算、规则事务和后端权限。
事实库：每条数字都要有出处和语境
处理资料时，不只做全文切片。图片版规格书要经过识别与人工校对；表格要保留行列关系；同一型号的多个版本不能互相覆盖。建议每条事实至少保存：完整型号、字段名、数值与单位、地区/市场、资料状态、版本、生效日期、来源文件、页码或段落、内容 hash 和访问权限。
遇到冲突时，系统先按企业配置的权威级别、版本和适用地区判断。若两份当前资料仍冲突，答案应并列列出数值与来源，创建“待产品确认”对象，而不是让模型挑一个更像真的。
资料状态也必须参与判断。停产、不推荐、预发布、可销售、仅特定地区可用不能只是备注；它们要成为检索过滤和选型门禁。安全、安装和合规信息只引用对应手册与认证材料，不能跨产品类推。
规则引擎：把选型章法写成可测试的规则
选型规则应由产品人员确认，工程化为版本化决策表或代码，并准备标准配置作为回归样本。推荐按以下顺序执行：
- 补齐功率、容量、国家/地区、并离网、室内外等必要条件；
- 筛掉地区不适用、停产和不推荐型号；
- 按确定性分档选择产品族与主机候选；
- 计算数量、容量整除、并机与附件触发条件；
- 校验组件兼容、数量边界和必配件；
- 返回确定、多候选、需补充信息或规则未覆盖四种状态；
- 保存输入、规则版本、每一步命中理由和输出 hash。
大模型不直接生成料号和数量。它可以把客户的自然语言转成结构化需求，也可以解释“为什么需要补问地区”，但最终 BOM 必须由可复算的规则输出。
Agent 的价值：把缺条件和缺证据接住
销售或渠道商说“给我配一套 30kW 左右、欧洲用的方案”时，Agent 先查缺少哪些条件，再发最少必要追问；条件完整后调用选型引擎；结果中的每一行带状态、规则依据和来源。多候选时展示差异，不自行决定商业偏好；规则未覆盖时转产品经理，人工结论经审核后再沉淀为新规则版本。
如果后续连接 CRM 或报价系统，Agent 可以把需求版本、选型结果和证据引用写回商机或技术询盘。正式报价、合同承诺、特殊兼容和合规承诺仍需人工确认。写入后再次读取 CRM/CPQ，确认输入版本、BOM 版本与审批状态一致，才算当前选型业务终态。
用 7 道门验收产品选型知识服务
- 数字是否都能回到具体来源与版本；
- 旧版、预发布和地区资料是否会被正确限制；
- 无依据问题是否明确拒答；
- 标准配置能否逐行稳定复现；
- 新需求是否按规则泛化，而非背答案；
- 规则未覆盖时是否停止并转人工；
- 写入 CRM/报价系统后是否能独立回读一致。
验收方法还可对照AI Agent 项目的 7 个检查点。首期不要追求全产品线，选一个产品族、一组地区资料和若干真实标准配置，把事实审计、规则测试、拒答与回读先做透。需要规划知识与系统底座，可继续查看企业知识中枢和企业 AI 落地五项工程。
