文章摘要

AI生成售前方案时，最危险的问题不是文案不够漂亮，而是把系统不存在的功能、没有承诺的接口和尚未验证的性能写进方案。本文从功能基线、证据绑定、声明分类、结构化输出、规则校验和人工审批六个层面，给出一套防止售前方案幻觉的工程方案，并提供功能证据模型、Prompt约束和自动校验示例。

一、售前方案中的幻觉为什么特别危险

普通内容文章出现错误，通常只需要修改。

售前方案中的错误可能直接进入：

  • 客户承诺；
  • 招标响应；
  • 合同范围；
  • 项目报价；
  • 实施计划；
  • 验收标准；
  • 法律责任。

例如，现有系统只支持：

经销商收货
终端扫码
基础库存查询

模型却生成：

平台支持全渠道实时库存预测、自动补货和动态价格优化。

这段话可能很像专业方案，但三个能力都不存在。

一旦客户将其理解为正式承诺，后续会产生：

  • 范围失控；
  • 研发临时插单；
  • 项目延期；
  • 交付成本上升；
  • 验收争议；
  • 客户信任受损。

因此，售前AI系统的第一目标不是“写得快”，而是：

所有能力声明都必须有来源、有状态、可验证。

二、根因一：功能资料本身没有统一口径

企业内部通常同时存在：

  • 产品白皮书；
  • 历史方案；
  • 投标文件；
  • 销售PPT；
  • 研发需求；
  • 客户定制说明；
  • 培训手册；
  • 老版本产品介绍。

这些资料可能互相冲突。

例如同一个功能出现四种描述：

已正式上线
部分客户试点
需要二次开发
未来版本规划

模型如果没有版本和状态信息，只会选择最像答案的一段。

解决方案：建立功能基线库

每个功能至少包含：

{
  "feature_id": "F-WMS-012",
  "product_line": "仓储产品线",
  "feature_name": "批次效期管理",
  "status": "GA",
  "version": "V4.2",
  "available_from": "2026-03-01",
  "standard_or_custom": "STANDARD",
  "description": "支持批次、生产日期和有效期管理",
  "limitations": [
    "不包含自动需求预测"
  ],
  "evidence_ids": [
    "DOC-WMS-042-3.2"
  ],
  "owner": "产品经理"
}

功能状态建议统一为：

GA：正式可交付
BETA：试点能力
CUSTOM：需要定制
PLANNED：规划中
DEPRECATED：已下线
UNKNOWN：尚未确认

只有GA功能可以默认写成“平台支持”。

三、第一层防护：功能白名单

生成方案前，先根据客户需求筛出允许引用的功能。

from dataclasses import dataclass
from enum import StrEnum


class FeatureStatus(StrEnum):
    GA = "GA"
    BETA = "BETA"
    CUSTOM = "CUSTOM"
    PLANNED = "PLANNED"


@dataclass(frozen=True)
class Feature:
    feature_id: str
    name: str
    status: FeatureStatus
    description: str
    limitations: tuple[str, ...]


def can_commit(feature: Feature) -> bool:
    return feature.status == FeatureStatus.GA

Prompt中不要直接提供整个历史资料库，而应提供经过筛选的：

本次允许承诺的功能
本次可作为定制建议的功能
本次禁止写入的功能

四、第二层防护：每一条能力必须绑定证据

不要让模型只输出自然语言段落。

先让模型生成结构化能力声明：

{
  "claim_id": "C-001",
  "claim": "平台支持商品批次和有效期管理",
  "claim_type": "SUPPORTED",
  "feature_id": "F-WMS-012",
  "feature_status": "GA",
  "evidence_ids": [
    "DOC-WMS-042-3.2"
  ],
  "confidence": 0.94
}

生成正文时再把Claim渲染为段落。

如果：

evidence_ids为空

则该能力不能进入正式方案。

校验代码：

def validate_claim(claim: dict) -> list[str]:
    errors: list[str] = []

    if not claim.get("feature_id"):
        errors.append("缺少feature_id")

    if not claim.get("evidence_ids"):
        errors.append("缺少证据")

    if claim.get("claim_type") == "SUPPORTED":
        if claim.get("feature_status") != "GA":
            errors.append("非GA功能不能表述为已支持")

    return errors

五、第三层防护：区分五类声明

售前方案中的文字不应该全部使用“支持”。

1. 已支持

平台支持……
系统提供……

仅适用于GA功能。

2. 可配置

可通过规则配置实现……

前提是现有配置能力确实覆盖需求。

3. 可集成

可通过标准接口与客户ERP对接……

必须明确：

  • 是否已有接口；
  • 数据方向；
  • 调用频率；
  • 认证方式；
  • 对方是否开放接口。

4. 需定制

该能力需要结合客户现有流程进行定制开发。

不能模糊成“平台可灵活支持”。

5. 建议规划

建议在第二阶段建设……

不能写成当前交付范围。

结构化枚举：

from enum import StrEnum


class ClaimType(StrEnum):
    SUPPORTED = "SUPPORTED"
    CONFIGURABLE = "CONFIGURABLE"
    INTEGRATION = "INTEGRATION"
    CUSTOM = "CUSTOM"
    ROADMAP = "ROADMAP"

六、第四层防护：使用严格的输出Schema

方案生成的中间结果可以定义为：

{
  "section_title": "库存与批次管理",
  "claims": [
    {
      "claim": "平台支持批次和效期管理",
      "claim_type": "SUPPORTED",
      "feature_id": "F-WMS-012",
      "evidence_ids": ["DOC-WMS-042-3.2"],
      "limitations": []
    }
  ],
  "unresolved_questions": [
    "客户是否需要与现有ERP进行双向库存同步"
  ]
}

模型必须把不确定问题写入：

unresolved_questions

而不是自己补全。

Pydantic模型：

from pydantic import BaseModel, Field


class ProposalClaim(BaseModel):
    claim: str = Field(min_length=1, max_length=300)
    claim_type: ClaimType
    feature_id: str | None = None
    evidence_ids: list[str] = Field(default_factory=list)
    limitations: list[str] = Field(default_factory=list)


class ProposalSection(BaseModel):
    section_title: str
    claims: list[ProposalClaim]
    unresolved_questions: list[str] = Field(default_factory=list)

七、第五层防护：确定性规则校验

模型Reviewer不能替代程序规则。

至少检查：

是否出现未登记产品名称
是否出现不存在的模块
是否引用非GA功能
是否缺少证据
是否把定制功能写成标准功能
是否出现绝对化性能承诺
是否出现未经确认的项目周期
是否出现未经批准的价格

绝对化词语扫描

RISKY_WORDS = {
    "完全支持",
    "无缝对接",
    "百分之百",
    "绝对准确",
    "零风险",
    "实时同步",
    "无需改造",
    "开箱即用"
}


def find_risky_phrases(text: str) -> list[str]:
    return [
        word
        for word in RISKY_WORDS
        if word in text
    ]

这些词不是全部禁止，但必须有证据和适用条件。

性能承诺扫描

以下内容必须绑定测试报告：

每秒处理10万次请求
准确率达到99.9%
查询响应低于100毫秒
支持千万级数据实时分析

性能数字不能来自模型常识。

八、第六层防护：人工审批

建议按风险等级审批：

内容 审批人
标准功能描述 产品经理抽检
定制范围 产品经理＋研发负责人
系统集成 架构师或接口负责人
项目周期 项目经理
报价 商务负责人
验收指标 产品、实施、法务
安全合规承诺 安全或法务负责人

AI可以生成草稿，但不能自动提交正式投标文件。

审批状态：

DRAFT
AI_REVIEWED
PRODUCT_REVIEWED
TECH_REVIEWED
BUSINESS_APPROVED
FINAL

只有FINAL版本可以对外。

九、Prompt应该如何写

推荐System Prompt：

你是企业售前方案助手。

你只能基于提供的功能清单和证据生成内容。

规则：
1. 不得创造功能、模块、接口、性能和案例。
2. status=GA的功能可以表述为已支持。
3. status=CUSTOM必须明确写为需要定制。
4. status=PLANNED只能写入后续规划。
5. 每一条能力声明必须返回feature_id和evidence_ids。
6. 信息不足时写入unresolved_questions，不得自行补全。
7. 禁止使用“完全支持、无缝对接、零风险”等绝对化表达。

用户Prompt应包含：

客户背景
客户需求
本次范围
允许功能清单
禁止功能清单
证据片段
输出Schema

十、建立“事实—证据—表述”链路

完整链路：

客户需求
→ 检索功能基线
→ 检索证据
→ 生成结构化Claim
→ 规则校验
→ 生成自然语言
→ Reviewer复核
→ 人工审批

任何对外表述都可以反向追踪：

方案段落
→ Claim ID
→ Feature ID
→ Evidence ID
→ 原始文档和负责人

这样客户提出疑问时，不需要重新寻找来源。

十一、如何处理客户提出但系统不支持的需求

错误写法：

平台可灵活满足客户需求。

正确输出应该包括：

需求：自动预测各经销商补货量

当前能力：
系统已支持库存、出库和动销数据采集。

差距：
当前标准版本不包含自动补货预测模型。

建议：
第一阶段完成数据采集和指标建设；
第二阶段基于历史销量、库存和促销计划建设预测模型。

范围属性：
二阶段定制能力，不纳入本次标准产品范围。

诚实说明差距并不会降低专业度，反而能减少后期风险。

十二、建议统计的质量指标

无证据Claim比例
非GA功能误承诺率
绝对化表达命中数
人工退回率
产品经理修改率
定制范围识别准确率
需求待确认项召回率
最终方案事实错误数

目标不是让文章更像人写，而是降低错误承诺。

十三、常见错误做法

1. 直接把历史方案全部丢给模型

历史方案中可能包含过期和定制内容。

2. 让模型自行判断功能是否存在

模型无法访问真实产品状态。

3. 只做一次RAG检索

召回文档不代表表述一定准确。

4. 只使用另一个模型审核

两个模型可能共享相同错误倾向。

5. 没有功能负责人

知识库内容过期后无人修正。

总结

AI生成售前方案的核心风险不是语言质量，而是把不确定信息包装成确定承诺。

生产级防护应该包括：

功能基线
＋证据绑定
＋声明分类
＋结构化输出
＋确定性校验
＋人工审批

只有当每一条能力都能追溯到产品状态和证据，AI售前方案才具备真正的企业可用性。

延伸阅读

如果你正在关注企业级 AI 应用、Agent、RAG、MCP 与大模型工程化落地，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。