AI 写错一次，系统会记很久

AI 销售助手最容易被低估的风险，不是它写了一封不够漂亮的邮件，而是它把一个不该写的内容写进了 CRM 或知识库。

一旦写进去，错误会继续扩散：

其他销售下次会把它当作客户事实；
管理看板会把它当作真实进展；
AI 再次检索时会把它当作上下文；
报价、跟进和客户判断都会被带偏。

所以，AI Agent 进入销售系统以后，真正重要的不是"能不能写"，而是写之前有没有 write plan。

write plan 是什么

write plan 不是一句"我会更新客户资料"。

它应该是一份可审计的写入计划，至少回答 6 个问题：

问题	示例
写到哪里	KnowSales customer profile / customer activity / product knowledge / tracker
写哪个对象	客户公司、联系人、产品知识卡或 activity 记录
写什么字段	机器兴趣、付款条件、下一步、异议话术
依据是什么	哪封邮件、哪段聊天、哪条用户确认
变更类型是什么	新增、追加、替换、删除、回滚
如何验证	写后读回哪个对象、看哪些字段

如果 AI 说不清这些，它就不应该写。

最常见的 4 种错误写入

1. 客户身份错配

行业词、产品词、材料词很容易相似，但它们不是身份证据。

例如两个客户都提到某类材料或机器，并不代表它们是同一家公司。真正的客户匹配至少要看公司名、邮箱域名、联系人、电话、历史订单等硬标识符。

write plan 应该明确写出身份依据。如果只有一个模糊线索，就应该停在"待确认"，不能落库。

2. activity 被写进 profile

客户今天说"这周可能付款"，这是一次沟通事件，不是稳定 profile。

它应该进入 customer activity，而不是变成客户长期画像的一部分。否则几个月后，AI 可能还会把"这周付款"当成当前事实。

3. 一次性事实被写成通用话术

某客户接受某个付款安排，不代表所有客户都适用。某次谈判里的折扣，也不应该沉淀成通用报价规则。

write plan 需要标明这是 customer-specific，还是 reusable knowledge。

4. 未确认判断被写成事实

"客户大概率会下单"是判断，不是事实。

如果这个判断有价值，可以写进 activity 的内部备注，并标注为判断；但不能写成"客户确认下单"。

一个合格 write plan 的样子

下面是一个简化示例：

目标：KnowSales customer activity
对象：客户公司 A（依据：公司名 + 企业邮箱域名 + 已确认联系人）
来源：2026-07-01 WhatsApp 对话
写入内容：
- 客户询问某个具体产品适配需求
- 客户要求确认交期与实施条件
- 当前付款条件未确认
不写入：
- 不更新 customer profile 的稳定需求
- 不写入通用产品知识，等待工程确认
验证：
- 写入后读取客户公司 A 最新 activity
- 核对 activity 时间、来源、三条事实是否存在

这才是 AI 可以安全执行的最小边界。

SalesFlow 和 KnowSales 怎么配合

SalesFlow 的核心纪律是 write-plan-first：先产出销售物料和写入计划，再等用户确认。

KnowSales 则提供可读写的销售记忆层：客户 profile、activity、产品知识、异议话术和 dashboard 都有明确落点。

两者组合起来，AI 写入不再是"模型觉得可以就写"，而是：

SalesFlow 生成计划 -> 用户确认 -> KnowSales 写入 -> 读回验证

这条链路慢半拍，但换来的是系统可信度。

什么时候必须停下

下面几种情况，AI 不应该继续写：

客户身份只有语义相似，没有两个硬标识符；
手上没有原始询盘、邮件或聊天证据；
写入目标不清楚，不知道该进 profile 还是 activity；
事实和判断分不开；
用户没有确认写入计划；
写后无法读回验证。

这些不是繁琐流程，而是销售系统不变脏的底线。

小结

AI Agent 写 CRM 的前提，不是它有工具权限，而是它能给出清楚的 write plan。

目标对象、证据来源、变更类型、用户确认、读回验证、回滚路径都说得清，才允许写。否则，AI 越勤快，系统越危险。

这也是 KnowSales 做销售记忆层时坚持的一点：真正好的 AI 销售助手，不是替你偷偷改数据，而是把每一次写入都变成可确认、可追溯、可读回的动作。