会议结束后，怎样让 AI 帮团队整理客户跟进

把会后整理变成一份能检查的交接

客户会议结束了，销售记下一句“下周演示”，同事记下一句“采购还没定”。晚上补客户记录时，谁来确认演示时间？该更新哪条商机？如果 AI 把这些片段整理得很流畅，却悄悄补上了没有说过的承诺，团队反而要花时间返工。

这里要做的事很具体：把一份会议纪要和一张客户表，整理成“建议改什么、依据是什么、还差谁确认”。客户关系管理系统通常简称 CRM；本文把它当作团队保存客户与商机记录的地方。

下面是 Onevium 原创的虚构练习，客户、姓名、日期和记录都不对应真实业务。我们提供输入和人工核对答案，展示可复现的整理方法；模型回答需要你实际运行并复核，不能把示例答案当成 Onevium 的实测结果。

从官方实践里借用一个有用的顺序

Anthropic 在 9 月 15 日介绍了 Salesforce in Claude：把客户资料用于会前准备，并从会议记录起草 CRM 更新，默认先让销售审核拟议变更。另一篇销售团队指南强调，推广 AI 前要明确负责人、使用范围和衡量方法。

对小团队有用的启发是：先让 AI 把依据和建议摆清楚，再决定是否更新。本文用普通导出文件完成练习，不需要连接 Salesforce。官方插件与连接器属于 Claude 产品，本文没有验证它们可在 Onevium 中直接使用。

先准备一个独立练习目录

下载练习包并解压。crm.csv 是原始客户表；meeting-notes-zh.md 是中文纪要，英文版放在 meeting-notes-en.md。expected-review-zh.md 和英文对应文件是核对答案，先不要把它们交给 AI。

在 Onevium 左侧“项目”旁点击“添加项目”，选择“打开已有文件夹”，选中解压后的目录。从这个项目新建会话，核对当前目录、可用的服务商和文件工具。无需初始化 Git，也不用安装 CRM 插件。

用会话顶部“浏览全部文件”打开两份输入，确认文件内容。对于第一次练习，只有三条商机，一条会话就够了；先看明白结果，再考虑扩大范围。

这四条纪要，为什么不能一视同仁

crm.csv 中 O101 和 O103 都属于 Northstar，O102 属于 Cedar。三条商机的 stage 都是 qualification，意思是仍在初步了解需求。next_step 是下一步动作，due_date 是这个动作的日期，不是预计成交日期。

纪要保留 N1—N4 标记，方便每条建议指回原文。相同公司可以有多条商机，不能只凭名字匹配。

把这段任务发给 Onevium

要求先读取指定输入，在会话里输出两张表。这样同事能先看懂建议，原始文件也有明确的保留边界。prompt 是任务说明，不是权限隔离；出现工具审批时仍要核对实际动作。

只读取当前项目中的 crm.csv 和 meeting-notes-zh.md。
这是虚构教学数据，不访问网络或连接业务系统。
不要读取 expected-review 文件。

先报告实际读取的文件，再在会话输出两张表：
1. 更新建议：商机编号、字段、原值、建议值、
   纪要标记、依据、审核状态。
2. 待确认事项：问题、对应记录、需要谁或什么信息确认。

只按明确商机编号匹配，不能按公司名猜测。
日期未确认、缺少负责人或证据不足时，保留原值并提问。
不要推断商机阶段、成交日期或未说过的承诺。
客户表没有的字段，只写备注，不新增字段。
所有建议标为“待负责人审核”。
不要修改输入、更新 CRM、发送邮件或消息。

逐项核对，而不是只看总结好不好读

在“浏览全部文件”中打开 expected-review-zh.md，对照 AI 输出。N1 可以产生同一条商机的两项字段建议；它们仍然只是建议，不代表已经获得写入批准。

Mina 是 N1 中给出的跟进负责人，但示例 CSV 没有 owner 字段，只应写在复核备注。N2 的日期只是提议，不能把客户未确认的演示变成既定安排。N4 也不能因为排在 O101 后面，就默认归到 O101。

• 所有记录的 stage 保持 qualification；本例没有成交日期字段。
• O102、O103 不产生可写入的字段变更；N2 和 N4 保留在待确认清单。
• 每项建议都有 N1—N4 中的来源；原文没有的信息明确写“未说明”。
• 原始 crm.csv 和纪要没有被改动；没有消息发送或业务系统写入。

让同事接手时，给出决定需要的东西

核对完以后，再明确让 AI 只创建一个新的 review-summary.md，保存建议和待确认项；已有同名文件时先说明，不覆盖。通过“浏览全部文件”检查保存结果。非 Git 目录不一定显示变更计数，能打开文件不等于已经做过 Git 提交。

负责人应该能逐条选择同意、驳回或待补充，并留下决定日期。后来即使有新会议，旧建议的证据仍能找到。只有明确获准后，才在另一个步骤更新客户系统，并重新读取记录检查实际结果；本练习不执行这一步。

例如同事回复“演示改到 9 月 23 日，Kai 负责，客户已确认”，应作为新来源记录，再重新检查 O102 的建议。不要改写 N2 让旧纪要看起来从来没有缺口。

客户多了，再按职责分给队伍

当你有多批纪要、不同客户负责人，而且任务需要持续跟进时，可以考虑 Onevium 的 @Team。先按队伍文档确认 team Skill 与 Sessions 工具可用，审阅成员分工和用量估算，再确认启动。这个三条记录的小练习不需要为了展示功能硬拆队伍。

一种可调整的分工是：成员一只整理来源与记录匹配，成员二读取匹配结果后检查建议字段，负责人汇总待确认事项并验收。第二步依赖第一步，应该顺序执行；只有独立客户批次才适合并行。

各成员写自己的输出文件，共同读取输入。同一商机只交给一个写入者；成员报告完成后，负责人还要检查文件与证据。队伍能组织工作，但不能替业务负责人确认客户承诺。

怎样判断值得在团队里继续用

先用少量已获准处理的脱敏材料做试点，由同一套人工标准复核。分别记录整理耗时、复核耗时、漏掉的明确行动、无依据的建议，以及匹配错的记录；仅仅生成得快，不代表整体工作更快。

如果同事能从建议直接找到原文，知道该确认什么，并且不需要重新读完整段聊天，才说明这套交接方式有用。若反复出现混淆客户、猜测日期或默默改原文件，先缩小输入、改提示词和权限，再重新验证，暂不接真实写入。

下一步可以把你们认可的字段、来源格式和审核习惯整理成团队 Skill。先保留这些练习中的歧义与缺失案例作为检查材料，避免把一次看起来不错的回答直接扩展成自动流程。