为什么 Telegram 聊天数量不同：联系人、对话和 CRM 行

Telegram 聊天数量不同，是因为联系人列表、实时对话列表、已保存的 CRM 清单，以及当前屏幕可见行衡量的是不同事物。在认定聊天缺失前，先比较相同 Telegram 账号、访问范围、文件夹覆盖和观察时间，然后检查分页与同步是否已完成。

上方现有 Chiho 产品图片展示 CRM 行和字段，并非下方数量核对的截图。

**于 2026年九月15日检查：**此处 Chiho 行为依据当前源代码和文档，并非实时账号审计。示例数字是虚构的。Chiho 发布本指南，不报告客户成果，也不声称总数一致就证明迁移完整。

比较数字前先明确清单类型

联系人是 Telegram 账号通讯录中的条目。Telegram 提供独立的联系人 API。某人出现在对话中，并不会让对话列表变成通讯录计数。

对话是账号 Telegram 对话清单中的会话。Telegram 的对话列表 API接受文件夹和分页参数。返回页面的条目可能少于清单总数。群组和频道也使对话清单不同于个人客户列表。

已保存 CRM 对话是 Chiho 在选定范围中为 CRM 使用持久保存的对话记录。它们有同步历史。已保存总数与新获取的 Telegram 总数未必描述同一个时刻。

可见行是屏幕当前显示的条目。选定筛选器或未完成的页面可能解释显示较少，却不能证明底层记录缺失。

如果你在决定对话之外哪些信息应放进 CRM，请从 Telegram CRM 能做什么开始。这里当前的问题更窄：每个数字描述的是哪种清单？

从一个账号和一个访问范围开始

写下选定的 Telegram 账号，以及视图属于个人还是团队范围。不要把一个账号的 Telegram 总数，与访问边界不同的团队视图比较。记录正在调查的屏幕上的任何搜索、状态或文件夹筛选。

对连接 Chiho 的 AI 客户端，account_whoami识别可访问账号。解读缺失结果前，检查连接及重新授权状态。权限或连接错误表示测量不可用，不代表数量为零。

Chiho 的实时 dialogs_list 不适用于团队范围令牌；支持的替代工具是 crm_dialogs_list，读取已持久保存的 CRM 清单。这个替代不会把保存结果变成实时 Telegram 测量。如果所需范围不可用，请记录限制，并请获授权的账号所有者执行比较。设置和访问边界见 AI 智能体连接指南。

分别比较活跃与归档对话

Chiho 的 inventory_summary 返回实时 Telegram activeTotal、archivedTotal 和 allTotal，并同时提供独立的 CRM syncedTotal 和 lastSyncedAt。Telegram 部分还记录 measuredAt。

查询当前可用的 Telegram 对话总数时，使用 telegramDialogs.allTotal。不要用 dialogs_list 响应中的条目数量替代。在工作表中保留活跃与归档数量，让归档覆盖差异可见。

实时总数仍是一次观察，不是冻结的导出。在你逐页查看时，对话可能发生变化。比较时间接近的观察，并保留时间戳。之后的差异可能需要再次进行限定读取，而不是宣称记录丢失。

完成分页后再称列表完整

第一页回答的是“这一页有什么？”要检查每个返回的对话，保持账号和查询范围不变，沿 nextCursor 继续，直到它不再出现。记录是否实际到达该点。

对于已保存 CRM 对话，crm_dialogs_list.syncedTotal 独立于当前页面长度。如果 CRM 分页期间清单改变，Chiho 可以拒绝游标并要求重新分页。将这个响应视为中断的观察；不要把重新开始的第一页追加到旧列表中，将重复项算作新对话。

比较单条记录时，使用工具返回的账号和稳定对端身份，包括可用时的类型。仅用显示名称并不适合作为匹配键：两段对话可能有相同标题，标题也会改变。在获授权诊断记录中，只保留必要的最少标识。

尝试修复前先读取同步状态

sync_status 读取最新或指定运行，不会启动 Telegram 工作。将其模式、归档覆盖、阶段、进度、失败和重试信息，与清单总数一起检查。

• queued 或 **running：**运行尚未达到终态。部分已保存清单不是最终核对结果。
• **waiting_for_telegram：**检查 resumeAt。Chiho 持久保存等待和已提交进度；计划工作在该时间前不得调用 Telegram。反复请求同步不能绕过等待。
• **enriching：**仍在进一步处理。不要推断每个 CRM 字段或相关细节都已填充。
• **complete：**运行已到终态，但要检查报告中的跳过和信息补充失败数量。完成不证明每项补充任务成功，也不证明历史中的每条消息已导入。
• **failed：**保留运行 ID、阶段和错误代码。决定如何恢复前，先报告失败。

启动 sync_once 是另一个操作，会启动或恢复持久保存的同步工作，不属于本只读检查。如果获授权操作人员之后选择完整核对，文档所述配置是完整模式，并包含归档对话。完整模式还刷新联系人快照，需要单独授予 telegram.contacts.read 权限。近期模式运行不应作为完整清单覆盖的证据。

示例：50 行不意味着 50 个聊天

以下是合成工作表，不是观察到的 Chiho 账号或性能测试。假设每次观察都针对同一个个人账号，且检查期间实时总数稳定。

• Telegram 活跃对话：120。
• Telegram 归档对话：30。
• Telegram 全部对话：150。
• Chiho 已保存 CRM 对话：142，有其自己的同步时间戳。
• CRM 第一页行数：50，有后续游标。
• Telegram 通讯录联系人：80，通过联系人访问单独测量。
• 同步状态：waiting_for_telegram，恢复时间在未来。

这份工作表能支持以下结论：

1. 实时对话总数为 120 + 30 = 150。
2. 50 行只是一个页面，不能证明丢失了 100 个聊天。
3. 已保存总数比实时总数少 8。这是未解决的数量差异，不是八个特定聊天缺失的证据。
4. 80 个联系人属于不同清单。不要从 150 中减去它们来计算缺失客户。
5. 等待中的运行尚未完成。记录重试时间，在允许恢复的时间点之后再次检查状态。

即使之后的运行完成，总数相等也不能证明两个集合包含相同对话。一个缺失对端与一个过时多余对端，可能在数字上抵消。如果完整性重要，请在完成分页后比较实际对端集合，再在授权范围内检查差异。

复制这份核对工作表

每个账号和范围使用一条记录。未知字段保持未知，不要猜测。

• **问题：**哪个具体对话或数量看起来有问题？
• **账号与访问：**选定账号；个人或团队范围；连接状态。
• **屏幕：**当前搜索和筛选；可见行数；是否还有页面。
• **实时对话：**活跃；归档；全部；观察时间；任何读取错误。
• **已保存对话：**已同步总数；最后同步时间；分页完成或中断。
• **联系人（如相关）：**单独联系人测量；权限可用或不可用。
• **同步：**运行 ID；模式；归档覆盖；状态；阶段；进度；跳过或失败工作；恢复时间。
• **记录比较：**仅出现在一侧的最少稳定对端身份；观察时间。
• **决定：**由范围、页面或筛选解释；等待完成；或需调查的未解决差异。

例如，“客户聊天不在第一页”需要分页或限定范围查找。“同一个对端在实时清单中存在，却不在已完成的保存清单中”是更强的调查依据。聊天存在但缺少备注，是字段或上下文问题，应归入团队交接流程，而非对话总数计算。

给 AI 智能体限定的只读任务

将 Chiho 连接到客户端后，使用类似请求：

对选定账号，检查账号身份、清单摘要和同步状态。分别报告实时活跃与归档总数，以及已保存 CRM 总数，附时间戳和任何访问错误。不要启动同步或发送消息。如果需要列出记录，请说明分页是否完成。不要从对话推断联系人数量。

联系人问题只有在相应权限可用时，才明确请求单独读取联系人。对于团队范围连接，接受实时对话列表工具不可用，并明确将保存清单报告为已保存的数据。

下一步：打开 Chiho，选择正在调查的账号，针对一个具体差异完成工作表。有效结果是解释清楚的差异，或可复现的诊断记录，而不只是恰好相等的两个数字。