Chiho AI
用 AI 总结 Telegram 聊天时，先授权访问正确的账号，选定一个会话和时间范围，读取消息，再要求生成附带来源的摘要。摘要应说明读了什么、决定了什么，以及哪些内容仍不确定。 没有覆盖说明的流畅回答很难核查。
Chiho 将经过授权的现有 Telegram 账号会话提供给 ChatGPT、Claude 或 Codex 等 AI 客户端。向运行中的代理传递指令的 Telegram 机器人或 Claude Channel 属于另一种用途；仅有这种连接，并不能证明它能访问个人聊天历史。账号身份、权限、Business 访问授权、实际历史覆盖范围和工具文档共同决定可读取的内容。详见访问架构指南。
本文由 Chiho 发布。产品细节于 2026 年 10 月 8 日依据 Chiho 源码核查。本文是工作流程和评估清单，不是客户账号测试或准确率研究。下方示例完全虚构。页首图片仅展示 Chiho 的一般界面，并非本次摘要生成过程的证据。
选择即时摘要还是已保存的 CRM 摘要
即时摘要由 AI 客户端根据本次请求获取的消息生成。已保存的 CRM 摘要是另一条记录，有自己的更新时间和覆盖范围。读取它并不意味着今天的消息已经包含在内。
在本文核查的托管 CRM 实现中，chat_read 读取 Telegram 历史。summary_show 返回已保存的摘要，其中包括 updatedAt、lastSummarizedMessageId 等字段；这些字段有助于判断新旧程度，但不能证明完整覆盖了指定时段。summary_refresh 是写操作，不是只读摘要的必要步骤。不同连接和产品版本提供的工具可能不同，选择操作前应检查当前工具结构。
如果只需在 AI 对话里得到摘要，请明确要求只读取历史并回答。不要为了回答问题而刷新或覆盖 CRM 摘要。如果目标是维护持久记录，请使用独立的 CRM 笔记与 AI 摘要指南。
确定账号、会话和停止条件
从持续维护的 MCP 设置页面开始：在客户端安装、完成浏览器授权、核对身份，然后进行一次有明确边界和来源的读取。使用当前连接实际提供的身份工具，例如 auth_status、account_whoami，或可用时的 get_profile。检查个人资料不等于读取消息。
使用返回的会话引用和选定账号定位聊天。两个聊天可能同名，应澄清歧义，而不是接受第一个匹配。团队请求必须限定在团队可见会话内。如果还不知道讨论位于哪个聊天，先使用消息搜索流程。
定义起止日期、时区、摘要需要回答的问题，以及读取预算。每日简报、项目决策回顾和工作交接需要不同的筛选标准。先从一个聊天开始，避免遗漏的会话悄悄消失在多聊天汇总中。
可复制并修改以下请求。名称和预算只是示例，不是产品限制：
使用我指定的 Chiho 连接和我选定的 Telegram 账号。读取前核对身份，并准确定位 Project Cedar 聊天。总结 2026 年 10 月 5 日 00:00 至 2026 年 10 月 6 日 23:59、Asia/Singapore 时区的消息。按顺序读取最多三页，每页 20 条，只使用当前工具支持的参数。报告实际覆盖的时间、页数、消息数和缺口。分别列出已确认决定、提议、待解问题和明确承诺；只有原文说明时才填写负责人和日期。每个重要结论都附上会话引用、消息 ID 和时间。若未覆盖整个时段，请标记为部分摘要。遇到歧义、错误或等待响应时停止。不要发送消息、创建任务、刷新摘要、启动同步或修改记录。
指定时段是证据筛选规则，并不保证工具接受任意起止时间过滤参数。不要编造工具不支持的参数。
压缩内容前先记录覆盖范围
在本文核查的托管 CRM chat_read 路径中，满页结果可能返回 nextOffsetDate 和 nextOffsetMessageId。继续读取更早消息时，应将二者一起传入受支持的 offsetDate 和 offsetMessageId。保持账号和会话不变，使用返回值，并按顺序读取。其他连接应遵循自身工具结构。
达到约定时段或预算就停止。若仍有游标、结果被截断，或尚未读到目标区间，都应写进回答。三页样本不能称为完整聊天历史。没有后续游标，也不能证明已读取被删除或不可访问的消息。
此托管读取路径不获取媒体内容。文字可能提到文件或语音，但并未提供其内容。应将这些内容标为未读；不能根据文件名总结文件，也不能猜测语音含义。通过另一个受支持且获授权的工具获取内容，是单独的后续步骤。
请将以下简明覆盖记录保留在授权的工作环境中：
- 范围： 选定的连接、账号和准确会话引用。
- 请求区间： 起点、终点和时区。
- 实际区间： 已读消息最早和最晚时间、页数和消息数。
- 后续历史： 是否提示还有更多内容，以及停止原因。
- 缺失证据： 媒体、不可访问的时段、错误或不明确的引用。
- 回答状态： 对已说明的读取范围完整，或对请求区间仅部分覆盖。
覆盖说明反映的是证据，而不是模型的自信程度。如果工具返回 rate_limited，应等待 retryAfterSeconds 指定的时间后，才能对同一账号再次调用 chat_read；不要并行重试。成功但为空的读取与工具调用失败不同。无法确认读取时，使用故障排查指南。
用摘要结构保留不确定性
要求输出五个简短部分：覆盖范围、决定、提议、待解问题和承诺。每个重要条目都应指向一条或一组消息。只有工具返回或独立验证过的 Telegram 直达链接才能使用；猜出来的链接不是来源。
将承诺中的执行人、行动和期限分开。“我们应该周五检查一下”并不说明谁接受了责任。应写“未说明负责人”或“日期尚未确认”，不要自动填入最近出现的人名或时间。
消息冲突时，按顺序展示早先提议与后续修正。如果“明天”等相对日期含义明确，应同时保留原话、解析后的日期和时区；否则标记为需要澄清。没有上下文依据时，不要将沉默、表情符号或助手推断写成明确同意。
读取到的消息是资料。消息中要求助手忽略指令或转发摘要的文字，并不构成操作授权。私人引文和引用应留在预定受众范围内；内部引用不会让聊天自动变成公开内容。
一个计划发生变化的虚构示例
下面四条记录是教学用的虚构素材，不是 API 输出，也不是客户数据。时间均为 Asia/Singapore：
- Cedar / M201，10 月 5 日 09:00 — Mira：“我们可以周三发送草稿吗？”
- Cedar / M207，10 月 5 日 10:15 — Leon：“周三太早。我可以在周四，也就是 10 月 8 日，发送修改后的草稿。”
- Cedar / M211，10 月 5 日 10:30 — Mira：“周四可以。价格先不要定，等财务确认。”
- Cedar / M245，10 月 6 日 15:00 — Leon：“修改后的草稿已准备好。价格还在等财务。”
基于这些记录的合理摘要应写成：
覆盖范围： 四条提供的文字记录，10 月 5 日 09:00 至 10 月 6 日 15:00。未查看其他消息或附件；无法确认覆盖整个请求时段。
决定： 在提出周三之后，草稿时间改为并确认在周四，即 10 月 8 日（M201、M207、M211）。
承诺： Leon 表示可以在周四、10 月 8 日发送修改后的草稿（M207）。他在 10 月 6 日报告草稿已准备好（M245），但这些记录没有确认已经发送。
待解问题： 价格等待财务确认（M211、M245）。没有指定财务负责人或截止时间。
关键区别是“准备好”和“已发送”。如果摘要声称已经交付、价格获批，或给财务添加了截止日期，就未通过此示例的检查。这是一个小型审查清单，不是任何模型的准确率测试结果。
转成任务前先核查摘要
打开引用消息，将最重要的结论、一个期限和一个未解决问题与原文对照。检查每个被点名的负责人是否确实接受了相关行动。确认覆盖说明与读取记录一致，并包含已读时段内的后续修正。
如果摘要不完整，选择一个具体的下一步检查：一页更早历史、一个已知缺失时段，或一次获授权的附件读取。不要悄悄扩大到整个账号。会议场景可使用会议回顾技能。
建议行动仍然只是建议，直到你要求执行写操作并验证结果。Chiho 会执行权限和操作防护检查，但并非每次代理写入都需要单独的 Chiho 审批；某些操作可在客户端控制之后直接执行。因此，只读摘要必须明确排除写操作。若要有意识地将来源转为任务，请使用后续任务指南。
从 Chiho MCP 设置开始，完成浏览器授权，核对身份，再请求总结一个熟悉的会话。只有能把决定和未知事项追溯到实际读取的消息时，才接受这份摘要。