客户项目档案的价值，不是把所有录音、PPT 和聊天记录堆在一个文件夹，而是让后来接手的人快速回答：客户是谁、谁在决策、已经确认什么、我们做过什么、当前卡在哪里、下一步由谁负责。
一份可用档案至少有八块
- 客户基本信息：主体、行业、组织规模与当前负责人。
- 联系人和决策链：角色、关系、参与记录与待补信息。
- 系统与业务现状：只记录有来源的客户自述或系统事实。
- 接触时间线：会议、拜访、材料发送和明确承诺。
- 需求与约束：客户点名需求、已确认边界、仍未知变量。
- 方案与资产：版本、用途、是否已发送、客户反馈。
- CRM 对象：客户、联系人、商机、订单、项目的稳定 ID。
- 待确认清单：谁来问、何时问、得到答案后写到哪里。
档案应指向原始证据，不复制出多份互相漂移的“最新版”。
四种表达必须分开
| 表达类型 | 例子 | 是否可直接当客户事实 |
|---|---|---|
| 客户原话 | 会议中明确说出 | 可保留原意与来源 |
| 近似复述 | 对多段表达的忠实压缩 | 标明为整理 |
| 内部判断 | 对机会、风险和打法的分析 | 不可升格 |
| 待确认项 | 转写矛盾、人员全名、系统边界 | 保持未知 |
Agent 最容易犯的错误，是把一段合理推断写成“客户确认”。档案必须保留归因层级。
CRM 是当前状态，档案是上下文证据
客户负责人、商机阶段和下一跟进应在 CRM 中维护；会议原文、方案演变和决策背景适合进入档案。Agent 可以从档案生成 CRM 更新建议，但写入前要展示字段差异，由负责人确认，写后再回读。
拜访内容写回方法见销售拜访录音怎么进 CRM；企业记忆与知识库的区别见企业记忆和知识库有什么区别。
每次事件增量更新，不做全篇重写
新会议发生后，应追加时间线、更新已确认事实、关闭已回答问题、生成新的待办。旧判断被推翻时保留变化原因，不静默覆盖历史。这样档案才能支持交接和复盘。
验收时随机选择一个客户，让未参与过项目的人在有限时间内找出决策链、当前阶段、已发材料、三个关键约束和下一动作。如果仍要翻群聊问人，档案就没有完成。需要把客户上下文、CRM 和项目行动连接起来，可继续了解企业知识中枢与定制开发。
媒体与原始文件要有索引
录音、视频、截图、PPT、合同和压缩包不适合全部复制进主档案，但要记录文件名、日期、用途、权限和存储位置。转写或 OCR 结果只能作为检索入口，关键事实仍应能回到原始片段。无法可靠识别的文件标记待核，不把机器转写错误写进客户事实。
对外发送的材料还要记录具体版本和发送对象。同名文件被多次修改时，只写“已发方案”无法判断客户看到的究竟是哪一版。
档案摘要按角色生成
老板关心机会价值、决策链和下一承诺；销售关心关系、需求和跟进；项目经理关心范围、依赖与交付；技术人员关心系统边界和待确认接口。底层事实只有一份，摘要可以按角色投影，避免维护四份互相漂移的客户介绍。
摘要里的每个重要结论应能点回证据。不能点回的内容标明判断或待确认，不用肯定语气包装。
结案不是停止维护
项目结束时，补齐实际交付、验收、未完成项、后续责任和可公开案例边界。进入续约或二期后建立新阶段，沿用客户和关系事实，但不重写一期历史。客户要求删除或限制使用的资料，按约定同步处理索引、摘要与派生内容。
从真实工作自动触发增量
会议结束、材料发送、商机变化、订单创建和项目里程碑，都可以触发档案更新候选。Agent 整理差异，人确认关键事实，再写回权威位置。这样档案来自日常工作，而不是临到汇报前花半天补一份“完整情况”。
