管理者需要工作对话，不是员工的整部手机

“我想看团队的聊天记录”听起来只是一个功能。追问几个问题后，它就变成了访问架构：哪些对话？哪些号码属于公司？个人联系人怎么处理？谁能打开附件？修改数据后留下什么？

在独立的 WhatsApp CRM 项目中，我研究的是一个面向单一管理者和多个工作电话账户的系统。它是已准备好的试点，不是经过证实的大规模使用案例。接入真实渠道和验证送达，都是独立阶段。

下面是使用虚构消息的团队通信界面。无需接入真实电话账户，也能查看对话与工作联系人的关联。

工作对话

归档界面 · 演示数据

先决定到底允许存储什么

基础是一组范围有限的工作联系人。在保存消息、上传媒体之前，系统先检查联系人是否属于其中。等个人内容进入存储后再过滤，是完全不同程度的保护。

对话旁边是虚构客户的资料。可用修改都留在演示内部；通过外部服务商发送消息的功能已关闭。

客户资料

归档界面 · 演示数据

原始消息与之后对它们所做的工作分开保存。PostgreSQL 中设有限制，约束原始记录的修改。管理者的备注、分类或未来的 AI 摘要，不应改写对方实际发送的内容。

媒体保存在私有对象存储中，通过访问权限检查后才提供。知道文件地址并不足够。界面出现方便的预览时尤其要注意：便利不能意外变成指向工作文件的公开链接。

这里需要另一套技术栈

界面使用 React，服务端使用 Fastify，数据在 PostgreSQL 中，附件使用兼容 S3 的存储。项目包含 WhatsApp 接入适配器，包括 Baileys 和 360dialog。代码中存在适配器，不代表真实账户已经接入，也不代表所有事件情况都经过了检查。

默认情况下，渠道不会自行启用。这样的系统需要有意识地接入、检查数据边界，并在获准的工作场景中验收。我不承诺绝不会封号、保有全部历史记录，或完美送达。

AI 在哪里发挥作用

首先是在开发过程中。未来有用的功能可以包括摘要和查找工作约定，但先要有可靠的基础。如果消息混乱、丢失，或被不该看到的人访问，聪明的摘要只会让错误更有说服力。

案例目前展示的是准备好的试点：团队通信和客户资料。真实渠道接入与送达检查仍是独立工作。AI 协助了开发；对话摘要只是可能的后续方向，不是已启用的功能。

相关故事：经纪人 CRM · 早期 WhatsApp 工具。