用 AI 根据 Telegram 历史准备会议

要根据 Telegram 历史准备会议，先告诉 AI 客户端需要作出的具体决策，选定相关对话，再让它根据检索到的证据拟定议程。把已经回答的问题与仍需参会者决定的事项分开。 每个议程项都应说明已知内容、尚不明确的内容，以及支持这一区分的消息。

Chiho 向 Codex、Claude、ChatGPT 等 AI 客户端提供经授权访问的现有 Telegram 账号对话。通过 Telegram 机器人或 Claude Channel 向运行中的代理发送指令属于另一种用途；仅有这种连接，并不能证明能够访问个人对话档案。账号身份、权限、Business 访问范围、已记录的工具及实际历史覆盖决定了能读取什么。选择连接前，可先了解 Telegram MCP 架构。

本文由 Chiho 发布。产品描述于 2026 年 10 月 12 日根据源码核查。这是一套建议的准备流程，包含虚构示例，并非内置会议规划器、客户账号演示或经测量的生产力成果。页首图片仅展示 Chiho 通用界面。

收集背景前，先明确决策

从“我们需要决定什么？”开始，而不是“总结这个客户的一切”。例如：“准备一次内部会议，决定试点能否在周五启动，以及谁需要确认剩余前提条件。”这与为重新商议范围而召开的客户会议，需要不同的议程。

明确受众、获授权账号、选定聊天、请求的时间范围、时区和停止边界。确定输出是私人准备笔记，还是将提供给参会者的文件。有权读取内部聊天，不等于其内容适合客户议程。

如果还不知道讨论在哪个聊天里，可通过消息搜索流程查找。收集资料前先消除名称歧义；相似标题不能证明两个聊天讨论同一个项目。

限定读取范围，并记录局限

按照 Chiho MCP 设置指南操作：在客户端安装连接，通过浏览器授权，核实身份，然后进行一次带来源的有限读取。使用 account_whoami 和可用账号工具，先确认目标账号以及个人或团队访问范围，再确定对话。

用 search_messages 查找相关词语，再用 chat_read 检查上下文和后续更正。关键词命中只是线索，并非完整决策记录。团队范围的搜索必须指定聊天，不能变成越过团队边界的全账号搜索。

分别记录请求的时间区间与实际返回的最早、最新消息。Telegram 历史采用分页。当 Chiho 返回 nextOffsetDate 和 nextOffsetMessageId 时，继续读取应将两者分别作为 offsetDate 和 offsetMessageId 传回。在约定边界停止，说明缺口，而不是悄悄扩大搜索。同一账号应顺序读取；若返回 rate_limited，须等待指定的 retryAfterSeconds 后再重试。

当前历史读取返回消息文字、标识符和日期，本身不检查附件内容。“批准在文档里”这条消息只能证明有人这样说，不能证明已获批准。把不可用文件、语音内容、缺失聊天及未检查时段标为未知。涉及多个来源时，将跨聊天来源矩阵与最终议程分开保留。

区分已回答、待决和缺失信息

如果已读取讨论支持某个答案，且已检查的后续更正没有推翻它，就可写入会前材料。当来源显示存在选择、条件、冲突或待确认事项时，应列入议程。缺失证据应放在覆盖说明中，不能写成“无人回答”的确定结论。

为每个建议议程项填写一张简短证据卡：

决策： 参会者需要作出的选择。
已知背景： 简短转述，并保留账号、聊天、消息 ID 和时间；仅在有可用链接时附上。
开放问题： 仍需解决的条件、冲突说法或确认事项。
问题和决策角色： 要问什么、哪个角色可能回答；未确认的负责人必须标为建议。
覆盖和下一步核查： 实际读了什么，哪些信息可能改变结论。

消息 ID 必须与来源聊天一起保留。不要编造 Telegram 链接，也不要假设每位参会者都能打开。基础摘要格式可参考用 AI 总结 Telegram 聊天。

演练一次虚构的试点会议

以下消息是合成阅读练习，并非客户记录，也不是在测试账号中运行得到的结果。假设获授权的内部读者为同一个试点选择了客户聊天和交付聊天；示例时间均为 Asia/Singapore。

S1 — 客户聊天，消息 801，2026 年 10 月 10 日 09:00： “试点覆盖两个地点，不是整个地区。”
S2 — 客户聊天，消息 802，2026 年 10 月 10 日 09:10： “如果安全审查先获批准，周五可以。”
S3 — 交付聊天，消息 801，2026 年 10 月 11 日 14:00： “检查清单已准备好。我们还没收到安全决定。”
S4 — 客户聊天，消息 803，2026 年 10 月 11 日 16:00： “请保持试点范围不变。”

有用的会前材料应根据 S1 和 S4 说明讨论范围是两个地点，无须在会上再问是否包括整个地区。根据 S2，周五仍有前提条件；S3 仅说明交付方当时尚未收到决定，不代表审查人已拒绝。注意消息 801 在两个聊天里都出现了，因此必须保留聊天引用。

建议的内部议程可以是：

确认前提条件： 以 S2 和 S3 为背景，询问安全决策角色是否已经批准。这只是建议角色；这些消息中没有具体负责人接受责任。
选择启动方案： 在确认后决定周五是否仍可行，或是否需要提出新日期。不要将任一结果表述为已经达成一致。
确定对外措辞： 准备保留前提条件、排除无关内部资料的客户更新。准备文字不等于发送。

现在从可用材料中移除 S3。正确输出应变为“从检索到的客户消息中无法确定安全审查结果”，而不是“交付团队正在等待”。如果加入 S2 提到但未读取的附件，其内容仍是待查项。这些变化用于评估议程，并非实验结果。

给客户端一个只读准备提示词

将占位内容替换为已明确识别的对话和具体时间范围。此提示词只要求在当前 AI 会话中给出议程，不授权持久化修改。

请只使用[获授权账号和选定聊天]在[时间范围和时区]内的内容，为我准备关于[决策]的内部会议。先核实身份和访问范围。读取限定讨论，并报告实际覆盖。区分已回答问题、待定决策和缺失证据。每个议程项保留来源聊天、消息 ID、日期和简短转述。检查范围内的后续更正。将建议负责人和解释标为提议。在这里返回私人会前材料与决策议程。不要刷新已存摘要、创建任务、修改 CRM 字段、安排任何事项或发送消息。若访问或覆盖不完整，请指出下一次有限核查。

会议回顾技能可将讨论整理为回顾，也可能包含摘要刷新或按请求创建任务。它不会自动成为只读的会前准备流程。请明确边界，不要假设要求摘要就排除了写入。

分享或行动前审阅议程

检查每个问题在已读材料中确实未解决，转述保留了全部条件，建议负责人也没有变成已接受的指派。尽可能亲自打开引用来源。会前重新检查相关新消息，并注明最后一次检索时间。

当受众不同时，应另做参会者版本。删除不必要的个人信息和内部讨论；引用来源不代表有权再分发内容。日历预订、任务保存、摘要刷新及发送都应有各自明确的行动意图。Chiho 执行范围限制和保护措施，但某些获准写入在客户端控制之后可直接执行，并非所有写入都需要第二个批准页面。

先从一个会议决策和一段获授权对话开始。连接 Chiho MCP，完成浏览器授权，确认身份，再请求一次带来源的有限读取。只有具体未答问题需要其他来源时，才扩大范围。

用 AI 从现有 Telegram 对话准备会议