Chiho AI
用 AI 制作 Telegram 收件箱简报时，先选定会话和时间范围，读取相关消息，再按明确规则排列建议行动。每项建议都应有来源，整份简报都应有覆盖记录。 一个安静却仍有待核实承诺的客户会话，可能比没有向你提出请求的活跃群更需要关注。
Chiho 将已获授权的现有 Telegram 账号会话提供给 Codex、Claude、ChatGPT 等 AI 客户端。向运行中的代理传递指令的 Telegram 机器人或 Claude Channel 属于另一种用途；这种连接本身不能证明它能访问个人聊天档案。应核对账号身份、授权、可用工具和实际历史覆盖。参见 MCP 架构指南。
本文由 Chiho 发布。2026年10月13日更新依据当前产品源码和文档，并非真实客户账号实验。上方现有产品图仅提供界面背景，不展示下方虚构简报，也不证明测试结果。
区分未读状态与尚未处理的工作
未读标记反映阅读状态，不能证明团队欠对方一个答复。Telegram 对话结构分别定义 unread_count、unread_mark 和阅读位置，也支持手动标记未读。已读聊天可能仍有未兑现的承诺，未读聊天也可能只是最后一句感谢。
Chiho 当前的实时对话列表返回 unreadCount，以及可选的末条消息 ID、日期和预览。该列表没有暴露 Telegram 的全部阅读状态字段，预览也不标明发言者。不要虚构手动未读字段，也不要根据预览猜作者。先检查可用工具结构，再进行有界历史读取；无法确认作者或消息方向时，应明确记为未知。
每项候选工作分别记录：
- 账号、聊天、检查时间、读取范围和缺失页面。
- 观察到的未读数或不可用状态；手动标记只有独立核实后才能记录。
- 请求或承诺的来源消息、作者证据及目标接收者。
- 已检查范围内的后续答复、取消、期限变更或依赖。
- 建议负责人及截止时间，各自注明有证据或尚未确认。
将结论分为有依据的行动、检查范围内未发现行动或未知。未读数为零不能自动结清承诺。账号发出的最后一句“明天确认”仍然产生工作，并不证明问题解决。群聊中最后发言的人也未必是负责人。
用练习检验简报队列
这是虚构且尚未执行的验收协议，不是客户成果。练习聊天 U 的 U41 请求新版报价，U42 回复“收到，谢谢”，未读数为三。判断报价是否已交付前，必须检查上下文。聊天 V 未读数为零，但 V51 写着“周五发送报价”，已查范围内没有完成证据。保留承诺，将完成状态记为未知。未确认周五日期和时区前，不得判定逾期。
移除包含 V51 的页面：应报告覆盖未知，而不是没有待办。加入仅含附件的答复：没有附件就无法核实答案。换成显示名相同的另一个账号：暂停并确认身份。引用 U41、V51 时保留聊天归属，避免证据错配。
排序前要求展示证据和不确定性。账号、作者、早期上下文或后续更正无法核实时停止。本次只读检查不得顺带标记已读、同步记录、创建任务或发送答复。这些动作需要单独请求及适用的工具控制；Chiho 并非对每次写入都要求额外确认弹窗。
先明确决策并核对账号
从可执行的问题开始：“这五个客户会话中，哪些今天需要我处理？”指定审阅时间、时区、账号和会话清单。“检查所有重要事情”没有定义覆盖范围或重要程度。
按 Chiho MCP 设置指南 安装连接器，在浏览器中完成授权，再用 auth_status 和 account_whoami 核对上下文。先确认个人或团队范围及目标 Telegram 账号。有多个可用账号时，应明确指定，而不是依赖默认选择。
个人范围可通过 dialogs_list 从 Telegram 活跃与归档会话中定位目标。团队授权不提供这一账号级个人工具；应使用可用的限定 CRM 清单，例如 crm_dialogs_list，并核对共享会话。不需要最后一条消息预览时，只请求元数据。团队访问不等于能读取同事全部私人会话。
会话标题只是标签，不足以确认身份。为每个来源保存返回的账号和 peer 信息。标题歧义或无法定位的会话应记为覆盖缺口。账号覆盖检查表 负责更广泛的清单审计；简报应注明自身边界，不承诺完成全账号检查。
为行动队列保留覆盖记录
每个选定会话应记录：
- 账号、peer、个人或团队范围，以及要求的时间窗口。
- 实际审阅的最早与最新消息，包括时区。
- 是否仍有下一页历史，以及停止读取的原因。
- 未解决的访问错误、未查看的附件和未经核对的旧上下文。
chat_read 返回有限的历史，包含消息 ID、日期、发送者和文本。返回继续读取字段时，下一页应同时使用 nextOffsetDate 和 nextOffsetMessageId。Telegram 历史 API 按页返回结果；一次成功响应不代表已读完目标时期。达到读取预算时，说明哪些部分尚未读取。
同一 Telegram 账号的历史读取应串行进行。遇到 rate_limited 时，等待返回的 retryAfterSeconds，不要在等待期间反复重试。RPC 错误文档 说明运行时等待。读取暂停表示覆盖不完整，不表示没有待办。
用 search_messages 定位相关措辞后，再查看附近历史。团队范围搜索必须指定会话。托管搜索不支持本地 CRM 标签或公司筛选；关键词命中不能描述为“所有优先客户”。查询设计参见 消息搜索指南。
读到文本不代表查看了附件或语音。未审阅媒体中的信息应标记为未知。“在已读消息中未发现行动”与“整个收件箱无需处理”不是同一结论。
按后果与责任排列行动
可以先约定以下顺序：
- 对方没有你的回答就无法继续。
- 你明确承担的承诺已到期或逾期。
- 某项决策需要在指定检查点前澄清。
- 值得联系维护关系，但没有当前期限。
- 最近很活跃，却没有识别出需要你做的事。
这些是建议的审阅类别，不是 Chiho 评分公式。让助手解释例外。未读不一定紧急，已读会话仍可能有未完成的事。
每项行动使用简洁卡片：账号/会话；来源消息 ID 与时间；已确认请求或承诺；建议负责人；原文期限；当前状态；优先理由；下一项核查。 推测的负责人和期限必须保持为推测。提出的日期不等于接受的承诺，沉默不等于拒绝。
账号、会话与消息身份应一起保存；不同会话可能出现相同消息编号。只有返回或核验过的 Telegram 链接才能作为来源；否则保留来源三元组，不编造永久链接。承诺有争议时，使用 承诺修订指南。
用三个虚构会话检查简报
以下是合成验收练习，不是测量结果。审阅时间为 2026年10月13日09:00，Asia/Singapore。使用获授权的非生产测试数据，或手动审阅书面案例。
- **会话 A，客户配置：**10月12日16:00的 901 表示“没有配置答复就无法完成设置”；17:00的 902 表示“我明早检查”。案例没有完成的答复。建议检查配置问题；“明早”是检查点，不是确切小时或修复证明。
- **会话 B，活动群：**10月13日08:30的 901 讨论场地，周围消息没有向审阅者提出请求。不要把这个901引用给会话 A。活跃本身不应成为首要理由。
- **会话 C，合作伙伴介绍：**10月10日11:00的 903 承诺在10月12日介绍。没有提供后续结果。应核查介绍是否发生，而不是断言承诺失败。
按上述规则，可将 A 与 C 放在 B 前面，并解释理由，保留具体配置检查时间和介绍结果的不确定性。这不证明服务改善。删除 C 的承诺所在页后，简报应报告旧历史缺失，而不是确信该会话无事可做。给 A 加上“答案见附件”但不提供附件，修复仍未经核实。交换两个901的来源，审阅者应在接受队列前发现错引会话。
请求一份只读、可检查的简报
只审阅选定账号、会话和时间窗口。先确认身份与范围，串行读取有限历史，并遵守 Telegram 返回的等待。输出覆盖记录和行动卡片，包含账号、会话、消息 ID、时间、证据、负责人及期限的不确定性、优先理由。区分明确请求、推测及未知媒体。覆盖不完整时指出缺口。不要发送消息、刷新已存摘要、启动同步、创建任务、修改标签或优先级。最后给出一项我应审阅的下一步核查。
提示词是指令，不是技术权限边界。还要检查客户端工具控制。Chiho 强制执行账号/团队范围与能力检查，但单条发送、CRM/任务修改和摘要刷新，在客户端控制后可以直接执行。批量发送可能按连接模式要求审批；邀请和退群要求保存预览并审批。不要以为所有写操作都会再次询问。
自行检查影响最大的来源消息。单会话深入回顾可使用 带来源的摘要指南。定期简报须在 AI 客户端另行配置；这个请求不会创建后台计划。
单独选择并验证下一项行动
建议任务不是已存任务，已存任务也不是已发送回复。跟进流程 说明另行请求的记录修改：先检查现有任务，再读回保存结果，之后才考虑重试不确定的保存。
重要回复或决策前，重新读取相关最新上下文。简报记录的是审阅时观察到的状态，后续更正可能改变队列。保留原始覆盖记录，注明变化。
从 Chiho MCP 开始：安装、浏览器授权、身份核对，再完成一次有限且有来源的读取。然后为少量选定会话请求简报，核验记录后再扩大范围。