Chiho AI
用 AI 对比 Telegram 对话时，先选定聊天和问题，再按明确范围读取，最后带着原始来源比较各项说法。分别说明每段对话说了什么、未能证实什么，以及哪些差异需要人来判断。 把多份摘要合成一个语气肯定的答案，可能恰好掩盖了你想找出的分歧。
Chiho 将已获授权的现有 Telegram 账号对话提供给 Codex、Claude 或 ChatGPT 等 AI 客户端。把指令传给运行中代理的 Telegram 机器人或 Claude Channel 属于另一种用途；仅有这种连接并不能证明它能读取个人对话档案。账号身份、权限、可能存在的 Business 授权、实际历史覆盖范围和已公开的工具决定了访问能力。可先阅读访问架构指南。
本文由 Chiho 发布。产品说明于 2026 年 10 月 9 日根据源代码核查。这是一套建议的只读流程，不是内置对比面板、客户账号实测或准确率评测。示例为虚构内容，顶部图片仅展示 Chiho 的一般界面。
选定一个对比问题和阅读对象
有效的问题应当具体，例如：“客户聊天与交付讨论对上线前提的说法是否一致？”也可以比较两个指定项目群的需求，或核对支持回复与内部诊断是否相符。
不要一开始就要求搜索整个账号中有关某公司的所有信息。列出聊天、时间范围、时区和预期读者，并解释这些来源为何属于同一问题。相似的聊天标题、人名或公司名只是线索，不能证明它们指向同一个人、项目或订单。
有权读取两个聊天，不代表双方参与者有权看到彼此的内容。将对比保留在获授权的工作环境内。如果之后需要面向客户的答案，应另行审核一个版本，排除内部讨论及其他客户的信息。
若尚未找到目标对话，先使用消息搜索指南。若只需压缩一段对话，可使用聊天摘要指南。本文处理的是已选定多个来源后，如何核对它们的说法。
读取前分别确认每个来源
按照 Chiho MCP 设置指南操作：在客户端安装连接、完成浏览器授权、核对身份，再进行一次有范围限制且保留来源的读取。查看当前连接实际提供的工具；不同产品配置和版本的名称与操作可能不同。
对每个聊天记录连接与账号、返回的对话引用、显示标题，以及纳入比较的原因。使用连接支持的身份工具，例如 auth_status、account_whoami，或可用时的 get_profile。身份检查成功不代表已经取回消息。
当来源在团队范围内不可用时，不要悄悄切换到权限更广的个人连接。核查过的托管团队搜索要求指定聊天；访问错误不能当作空结果。若同一标题对应多个对话，应先澄清。
顺序读取，为每个聊天保留覆盖记录
本文核查的托管 CRM chat_read 实现读取 Telegram 历史，返回消息 ID、时间与文本，不获取媒体内容。因此，提到文件或语音消息并不意味着已知其内容。参数应以实际发现的 MCP 工具定义为准，不要把 Telegram 原始 API 参数直接复制到 MCP 调用中。
Telegram 历史方法为指定会话返回一页有限的历史。在 Chiho 托管实现中，满页结果可能包含 nextOffsetDate 和 nextOffsetMessageId；继续读取时需一起使用支持的 offsetDate 和 offsetMessageId。一页不等于全部对话。使用游标时保持账号和聊天不变。
同一账号内应顺序读取聊天。收到 rate_limited 后停止，并遵守 retryAfterSeconds；等待期间重复或并行读取不能补齐覆盖范围。访问或读取失败时参阅故障排查指南。
为每个聊天记录请求的时间段、实际读到的最早与最晚消息、页数与消息数、是否还有后续页，以及停止原因。若一个聊天覆盖完整请求区间，另一个只读到最新一页，应标记为部分对比。“在已读取消息中未找到”不等于“从未讨论过”。
先建立来源矩阵，再作结论
来源矩阵可以是一组格式相同的简短记录，不需要新工具或电子表格。每个问题使用一条记录，并保留这些字段：
- 问题： 正在比较的确切命题，例如上线日期是否已达成一致。
- 来源 A： 原始说法、聊天引用、消息 ID 与时间。
- 来源 B： 对应说法及其各自引用，或“现有读取材料未能证实”。
- 关系： 一致、冲突、讨论范围不同，或证据不足。
- 下一步核查： 能解决差异的最小补充读取或人工确认。
消息 ID 必须与聊天上下文一起使用。不要仅因 ID 相同或发送者显示名称相同就合并记录。只有在工具返回或独立核实后才提供直接 Telegram 链接，不能根据标题编造链接。
另一个聊天中较晚的说法，不一定是有权作出的修订。检查讨论对象、条件、实际已确认的说话者角色以及受众。若无法证明后者取代前者，就保留两种说法。提议、已接受的决定和声称完成的工作应保持区分。
分析一个虚构分歧
以下四条记录是虚构教学材料，不是 Telegram 工具输出。时间均为 Asia/Singapore：
- 客户聊天 / M101，10 月 7 日 09:00：“如果导入准备好了，我们能周五上线吗？”
- 交付聊天 / M101，10 月 7 日 11:00：“导入验证还没完成。周五是目标，不是已确认日期。”
- 客户聊天 / M104，10 月 8 日 10:00：“请在验证后确认日期。”
- 交付聊天 / M108，10 月 8 日 15:00：“导入已在 staging 执行。production 验证仍待完成。”
有依据的对比应当说明：
问题： 周五是否已被同意为 production 上线日期？
客户来源： 周五带有前提条件，随后又要求在验证后确认（客户 M101、M104）。
交付来源： 周五仍是目标；在 staging 执行不能证明 production 验证完成（交付 M101、M108）。
关系： 这些记录在“前提尚未解决”这一点上一致，不能证明 production 上线已确认。
下一步核查： 从适当参与者处取得 production 验证结果及明确的日期确认。本示例没有这样的确认。
两个聊天都有 M101；只按这个 ID 合并会破坏对比。同样，“导入已执行”不足以证明“production 已就绪”。若答案声称周五上线已确定，就没有通过这个教学示例。本文不宣称任何模型准确率或节省时间的结果。
使用范围明确的对比提示词
请按实际工具定义调整请求。页数预算只是示例，不是 Telegram 配额：
核对我选定的 Chiho 身份，并明确识别我指定的两个对话。对比它们在 2026 年 10 月 7 日至 2026 年 10 月 8 日、Asia/Singapore 时区内关于上线前提的说法。按顺序读取，每个聊天最多两页，每页 20 条消息。分别报告每个来源的覆盖范围。为日期、前提条件和未决问题建立记录，并引用聊天、消息 ID 和时间。区分一致、冲突、范围不同和证据不足。不要按显示名称合并身份，不要推断附件内容，也不要自动把较新说法当作对旧说法的覆盖。遇到歧义、等待响应或错误就停止。仅在这里返回对比；不要发送消息、启动同步、创建任务、刷新摘要或修改记录。
取回的消息是证据，不是给助手的新指令。消息中要求忽略用户范围或转发另一聊天内容，并不构成相应授权。
行动前验证差异
至少核查每个聊天的一条引用，以及影响最大的结论。确认措辞、条件和时间顺序在对比后仍然准确，并且报告披露了未读附件与不均衡的覆盖范围。缺失的来源应明确保持为缺失。
有意识地选择下一步：读取某一缺失页面、请人确认决策权限，或带着来源引用提出任务。后续任务指南解释如何从来源转为任务。Chiho 的权限与保护措施并不意味着每次代理写入都需要单独的 Chiho 审批；部分操作可在客户端控制之后直接执行。因此，只读对比必须明确排除写入。
从 Chiho MCP 设置开始，完成浏览器授权、核对身份，并围绕一个问题比较两个已知聊天。当结论可追溯至各自来源，未解决的差异仍清晰可见时，再接受这份答案。