老周是我们团队最资深的售前。上个月给华东一家汽配连锁分销商做方案，他熬了三个通宵，产出一份 80 页的 PPT —— 行业洞察、痛点拆解、架构图、ROI 测算、三个同行的成功案例，一应俱全。客户的财务总监当场说：「这是我见过最懂我们的方案。」单子签了。
四个月后，这个客户在续约评估里打了低分。原因不是产品不好，而是交付团队上线的对账流程，跟老周方案里承诺的「月结 T+1 出报告」对不上 —— 交付的同事根本没看过那份 PPT，他们手里只有一个工单：「给客户 A 部署对账 Agent」。老周写进方案的服务标准，卡在了销售和交付之间那道看不见的缝里。
而那份被财务总监称赞过的 80 页方案，此刻正安静地躺在某个钉盘文件夹里，再没有人打开过。
杀死这一单的不是老周的 PPT —— 它确实很好。杀死它的是： 这份方案在签单的那一刻就死了。
这是一个系列的第一篇。我想拆解的是企业销售流程的 AI 化，它天然分三段 —— 售前出方案、售中讲方案、售后保履约。大多数人会把这三段当成三个独立的 AI 工具来做：一个方案生成器、一个话术质检器、一个 SOP 生成器。但我越做越确信： 销售流程 AI 化真正的胜负手，不在任何单点做一个更好的工具，而在让「解决方案」从一份交付即死的 PPT，变成一个贯穿三段、持续累积上下文的活对象。老周那一单的死法，就是这个判断的反面证据 —— 断点（尤其是销售到交付的断点）才是最大的隐性成本。
这个系列的三篇分别对应三段，但用的是同一个汽配分销的单子，跟着同一个「解决方案对象」走完全程。这一篇先讲售前：怎么让方案从出生那一刻起，就是个能活下去的对象。
「方案生成器」是个陷阱
售前 AI 化，最直觉的做法是做一个方案生成器：输入客户名称、行业、需求，输出一份排版精美的解决方案 PPT。生成得越快、越漂亮，看起来价值越大。
这个方向能做出很好的 demo，但它强化了一个错误的范式 —— 它默认方案是一次性交付物。生成器越好用，老周们就越快地产出一份又一份「交付即死」的 PPT。问题从来不是 PPT 写得不够好，而是：
- 这份方案里的行业理解，下一个销售接手类似客户时，复用不了，只能从零再写一遍；
- 老周对竞对的差异化打法，是他脑子里的经验，他一离职就带走了；
- 方案里引用的成功案例，数据是哪来的、能不能经得起客户追问，没人说得清；
- 最致命的：方案里写的服务承诺（月结 T+1、对账准确率 99.5%），交付团队压根不知道。
我在 企业业务流程 AI 化的决策框架 里提过一个判断：真正的效率跃迁不在「让 AI 帮忙做」，而在「让 AI 来做」—— 围绕 AI 重新设计流程。方案生成器是典型的「帮忙做」：老周的角色没变，他还是那个一次性产出 PPT 的人，AI 只是让他写得快一点。要「让 AI 来做」，得先换掉「方案 = PPT」这个底层假设。
重新定义售前 AI 的目标：装配一个对象，不是生成一份文档
换个目标：售前 AI 不生成 PPT，它 装配一个解决方案对象。
PPT 只是这个对象在某一刻的一个渲染视图 —— 你可以从对象导出一份给客户看的 PPT，也可以导出一页投标书摘要，还可以在交付时导出一份履约 SOP。视图可以有很多份，但底层的对象只有一个，它从售前活到续约。
from dataclasses import dataclass, field
from datetime import date
@dataclass
class ProofCase:
"""一个可引用的成功案例——关键是 source 字段，强制每个数字都可溯源。"""
customer_name: str # 可匿名，如「华东某汽配连锁」
industry_match: str # 与当前客户的行业/规模匹配度说明
metric_before: str # 改造前指标，如「月底对账 3 天」
metric_after: str # 改造后指标，如「对账 4 小时」
source: str # 数据来源：项目验收报告 / 客户访谈 / 标注「示意·经验估算」
@dataclass
class SLA:
"""一条服务承诺——售前写下，售后据此履约。这个字段是断点的高发区。"""
metric: str # 「月结报告出具时效」
target: str # 「T+1」
measurable: bool # 能否被运维数据自动校验
@dataclass
class SolutionObject:
"""贯穿售前售中售后的解决方案对象。售前负责创建并填充上半部分。"""
deal_id: str
customer_id: str
industry: str
# —— 售前装配的四类上下文 ——
industry_insight: str # 行业理解
customer_profile: dict # 客户个性化理解
competitive_edge: list[str] # 领先竞对的差异化论点
proof_cases: list[ProofCase] # 可数据证明的成功案例
commitments: list[SLA] = field(default_factory=list) # 服务承诺——售后 SOP 的源头
# —— 留给后续阶段写入（本篇先留空）——
pitch_scripts: list[str] = field(default_factory=list) # 售中回流的赢单话术（第二篇填）
delivery_sop_ref: str | None = None # 售后编译出的 SOP（第三篇填）
# generated by hugo AI
注意两个细节，它们是这个对象设计的灵魂：
第一， ProofCase 里有一个 source 字段。 任何一个用来打动客户的数字，都必须能说出它从哪来。 没有来源的「降本 40%」不许进对象，要么补上验收报告的出处，要么老老实实标成「示意·经验估算」。把诚实做进数据结构，比靠人自觉可靠得多。
第二， commitments、 pitch_scripts、 delivery_sop_ref 这三个字段，售前阶段要么留空、要么只填一半。这是故意的 —— 它们在提醒你：这个对象还要活下去。 commitments 是后面售后 SOP 的源头， pitch_scripts 等着售中的赢单话术回流， delivery_sop_ref 等着售后编译。售前不是终点，是起点。
四类上下文，AI 怎么装配
老周那份方案之所以好，靠的是四类东西：行业理解、客户个性化理解、竞对差异、可证明的成功案例。这四类恰好就是 SolutionObject 上半部分的四个字段。关键的认知转变是： 这四类上下文，AI 大部分时候不该「生成」，而该「检索 + 装配」—— 从组织已经沉淀的资产里调出来，而不是凭空写。
下面用汽配分销这个单子，逐个看 AI 在每个字段上干什么。客户 A 是华东一家汽配连锁分销商，12 家门店、3 个区域仓，库存和对账靠 Excel 加微信群，月底对账要 3 天，错账还经常引发跟上游供应商的纠纷。我们卖的是钉钉 AI 表格（做结构化中间层）加悟空 Agent（自动对账、库存预警、月结报告）。
行业理解：检索行业资产，不是现编
行业知识库（沉淀资产）
│ 汽配分销的典型痛点：SKU 海量、批次管理、返点结算复杂、增值税专票合规
▼
AI 检索 + 匹配当前客户 → industry_insight 字段
行业理解最不该现场生成 —— 现编的行业洞察经不起内行客户追问。它应该来自组织沉淀的行业知识库：汽配分销这个行业的对账难在哪（SKU 多、批次和返点结算复杂）、合规红线在哪（增值税专票）、同行普遍卡在哪一步。AI 做的是从知识库里检索出跟这个客户匹配的部分，填进 industry_insight。
如果你的组织根本没有这样一个行业知识库，那才是真问题 —— 它意味着每个售前都在用自己脑子里那点行业经验单打独斗。这正是我在 知识库编译查询：让 AI 从「读文档」变成「查数据」 里讲的：行业 know-how 要先编译成可查询的结构，AI 才能稳定调用，而不是每次都去读一堆原始文档现场总结。
客户个性化：个性化 = 检索这个客户的真实上下文
很多人把「个性化」理解成「为这个客户从零定制」。不对。 个性化的本质是检索这个客户的真实上下文，而不是定制化地编造。 客户 A 的真实上下文是现成的，散落在多个系统里：
customer_profile = {
"scale": "12 门店 / 3 区域仓",
"current_system": "Excel + 微信群人工对账",
"existing_tools": "已部署钉钉，组织在钉钉上活跃", # 关键：决定方案落地路径
"decision_chain": ["财务总监（拍板）", "IT 经理（评估可行性）"],
"pain_quantified": "月底对账 3 天，错账引发上游纠纷（客户访谈，2026-05）",
}
# generated by hugo AI
这些信息 AI 从客户在钉钉上的互动记录、CRM、以及售前访谈纪要里检索、归并出来 —— 每一条都标注来源（比如「客户访谈，2026-05」）。existing_tools 里「已部署钉钉」这一条尤其关键，它直接决定了方案的落地路径：客户已经在钉钉上协同，我们就让 AI 适配它现有的协同方式，而不是逼它换一套系统。
竞对差异：从情报库里调出差异化论点
竞对情报库 → 针对客户 A 的现状，调出对比论点 → competitive_edge 字段
客户 A 同时在看传统进销存 ERP（用友、管家婆这类）。差异化论点不该让老周临场发挥，它应该来自组织维护的竞对情报库。对客户 A 来说，最有力的差异点是：
- 传统 ERP 要求客户 改造流程去适应软件，门店得重新学一套系统；
- 我们的方案让 AI 去适应客户现有的钉钉群协同—— 门店该怎么沟通还怎么沟通，AI 在后台把聊天和单据收敛成结构化数据。
这正是 250 那篇里「让 AI 来做」的落点：不是给旧流程加按钮，是让 AI 接管信息搬运，人几乎无感。这个差异点对一个「员工不愿学新系统」的连锁分销客户，杀伤力远大于功能参数对比。
可证明的成功案例：带着来源进对象
proof_cases = [
ProofCase(
customer_name="华东某汽配连锁（已脱敏）",
industry_match="同为汽配分销，门店规模相近（8 店）",
metric_before="月底对账 3 天，3 人投入",
metric_after="对账约 4 小时，1 人复核",
source="项目验收报告（2026-Q1）", # 可溯源
),
ProofCase(
customer_name="区域快消分销商（已脱敏）",
industry_match="分销模式相近，对账逻辑可类比",
metric_before="月结报告 T+5",
metric_after="月结报告 T+1",
source="示意·基于同类项目经验估算", # 诚实标注，不伪装精确
),
]
# generated by hugo AI
成功案例是售前最有杀伤力、也最容易翻车的部分 —— 客户的财务总监很可能就认识那家「同行」。所以每个案例必须带 source：能拿出验收报告的，写来源；拿不出的，标「示意·经验估算」，绝不伪装成精确数字。 宁可少一个精确数字，不可多一个假数字 —— 一旦被客户当场戳穿一个编的数据，整份方案的信任就崩了。
对比：方案生成器 vs 方案对象
| 维度 | 方案生成器（单点工具） | 解决方案对象（贯穿载体） |
|---|---|---|
| 产出形态 | 一份 PPT（交付即死） | 一个结构化对象（活到续约） |
| 行业理解 | 每单现编 | 检索行业知识库，可复用 |
| 个性化 | 从零定制 | 检索客户真实上下文 |
| 成功案例 | 数字来源不清 | 每条带 source，可溯源 |
| 服务承诺 | 写在 PPT 里，无人接收 | 进 commitments 字段，售后可读 |
| 资深销售离职 | know-how 随人流失 | 已沉淀进组织资产 |
| 对下游的价值 | 无（PPT 没人再打开） | 售中可校验、售后可编译 |
最右边这一列的最后一行，就是这个系列后两篇要展开的事。售前把对象建好，售中（拜访讲方案）才有东西可对照，售后（履约 SOP）才有承诺可编译。
一个最强的反方
到这里，最聪明的反驳是这样的：
「客户要的就是一份能打动他的方案，你生成得又快又好不就够了？而且个性化定制本来就是一单一议，每个客户情况都不一样，所谓『沉淀复用』是奢望 —— 真到了关键客户，还是得资深售前一个字一个字抠。」
这个反方一半对，一半错。
对的那一半： 最终呈现给客户的那层包装，确实是一单一议的，需要老周这样的资深售前去打磨语气、调整重点、临场应变。我不主张用模板套出一份冷冰冰的方案。
错的那一半： 一单一议的只是表层包装，底层的四类上下文是高度可复用的资产。汽配分销的行业痛点、对比传统 ERP 的差异化论点、那几个可证明的成功案例 —— 这些不会因为换了个客户就失效。不沉淀它们，结果就是每个售前都从零开始，资深的人一离职，组织的行业 know-how 就清零。AI 的价值恰恰是把这层资产从个人脑子里提取成组织对象，让老周把省下来的时间花在真正需要人的表层打磨上 —— 这又回到了 250 的那个收敛：人从「搬运信息」收敛到「判断和打磨」。
更重要的是，这个对象不只服务本单。它要被售中的拜访质检读取（检验老周有没有把竞对差异讲丢）、被售后的 SOP 编译（把月结 T+1 的承诺变成可执行的运维标准）。一份只为本单服务的 PPT，做得再快也只是「帮忙做」；一个为整条流程服务的对象，才是「让 AI 来做」。
落地：先定义对象，再挂能力
如果你要在售前环节落地 AI，我的建议不是先去买一个方案生成器，而是倒过来：
第一步，先定义你的 SolutionObject 长什么样。 哪四类（或五类）上下文是你这个行业的方案核心？服务承诺有哪些字段？哪些字段必须可溯源？这一步是纯设计，不写一行 AI。
第二步，盘点这些字段的资产来源。 行业知识库有没有？竞对情报库有没有？成功案例的数据可溯源吗？没有的，先补 —— 这是 250 里说的「自己补基础设施，把可行性从低拉到高」。
第三步，再让 AI 去装配。 这时候 AI 干的是检索、归并、按来源标注，而不是凭空生成。产出的对象既能渲染成给客户的 PPT，又能往下游传递。
注意这个顺序：先有对象，再有 AI 能力；先有可溯源的资产，再谈生成。反过来 —— 先上一个炫酷的生成器 —— 做出来的还是一堆交付即死的 PPT，只是死得更快了。
回到老周那一单。如果当初那份方案是个 SolutionObject 而不是 PPT，commitments 字段里「月结 T+1」这条承诺，本可以在交付时被自动读取，编译进运维 SOP，交付团队一开始就知道要对齐什么。断点不会发生，续约评估也不会是低分。
但这是第三篇的事了。下一篇先讲售中： 方案写得再好，销售讲歪了也白搭 —— 怎么用钉钉拜访录音做质检，校验「讲出来的」和「写下来的」是不是一回事，再用这一单的真实方案做陪练脚本。 这里藏着一个反常识的点：拜访质检最大的价值，根本不是给销售打分。
你们的售前方案，签单之后还有人打开过吗？那些资深售前脑子里的行业 know-how，沉淀成组织资产了吗？欢迎留言聊聊。