Chiho AI
Telegram 批量消息是指为多个选定对话准备同一条消息。对于专业团队，重要的是检查谁应该收到消息，并在之后核对每位收件人的实际结果。批量请求成功并不能证明每条消息都已发送、被阅读或受到欢迎。
本指南介绍 Chiho 中的受控批量流程：选择预期收件人，审核解析后的名单和消息，使用所需的授权途径，然后区分成功、失败、跳过、待处理和不确定的结果，再考虑重试。
先说明每位收件人的入选理由
有用的批量消息可以通知那些已请求同一维护窗口更新的现有客户。联系人文件夹只是组织工具，并不能证明其中每个人都期待同一条消息。
Telegram 官方垃圾消息常见问题要求用户联系期待收到其消息的人，并说明不受欢迎的消息可能导致账号受限。缩小批量规模或降低发送速度，并不会让不受欢迎的主动联系变得合理。
选择聊天之前，写下共同目的、相关客户请求或关系，以及任何排除条件。移除已拒绝后续更新、已经收到信息或需要不同答复的人。如果无法解释某位收件人为何应当入选，就不要包含该对话。
对于持续的销售工作，在准备批量消息之前，使用按优先级跟进指南决定谁需要关注。Telegram CRM 指南解释了对话背景如何融入更广泛的工作流程。
在审核消息前确定受众
姓名可能重复，文件夹可能变化，所选对话也可能无法通过已连接账号访问。应审核具体收件人，而不只是批准“发送给五位客户”这样的数量。
在 Chiho 的代理发件箱流程中，outbox_preview 会解析所请求的收件人，并保存拟议操作，但不会发送消息。其结果包含收件人名单和数量、跳过的收件人、消息预览、有效期，以及是否需要批准。创建这种已保存的预览会改变 Chiho 状态，即使它并未发送 Telegram 消息。
一起检查以下细节：
- 已连接账号以及个人或团队上下文符合预期。
- 每个解析出的聊天都对应你选中的客户对话。
- 跳过条目的原因已被理解；它们不计为成功发送。
- 显示的文本适用于每位解析出的收件人。
- 任何排期都符合预期时间和时区。
- 预览仍然有效，最新对话也未改变原来的决定。
当前代理预览最多接受 20 位请求的收件人。这是 Chiho 针对此途径的防护限制，并非 Telegram 的通用许可，也不保证批量操作能够完成。团队执行还要求每个已批准批次只有一位 Telegram 会话所有者；应明确账号归属，而不是混合无关的发送账号。
将通用措辞与个人事实分开
只有消息事实一致时，才使用共同消息。服务通知可以共享已确认的维护窗口，但客户的退款、续费价格、交付日期或合同承诺需要各自经过核实的背景。
例如，下面是虚构的文案示例，并非客户结果：
“根据您接收维护更新的请求，已确认的维护窗口为周二，新加坡时间 14:00–15:00。如果该窗口有变化，我们将另行发送更新。”
只有收件人已请求更新、时间窗口已确认，而且发送者已接受后续通知承诺时，这段措辞才算准备就绪。不要仅因为这句话听起来合理就重复使用它。在真实消息中，将相对日期替换为准确的日历日期，并检查所有链接是否适合每位收件人。
使用消息模板指南准备可重复使用的措辞，然后根据选定对话审核最终文本。不要在消息中包含内部笔记或其他客户的细节。
检查实际的批准要求
对于代理发件箱途径，解析出多位收件人时需要批准。如果连接使用始终询问模式，或者预览属于高风险，即使只有一位收件人的预览也需要批准；跳过收件人可能使预览变成高风险。应读取返回的批准要求，而不是根据最初选择的人数推断。
这并不意味着 Chiho 代理的每次写入都要等待新的批准界面。不同操作和连接的权限及防护措施有所不同，客户端的工具控制也很重要。“仅起草”的请求是一项指示，并不是发送能力的技术限制。在启用写入工具之前，阅读 AI 代理连接指南。
团队消息队列和代理发件箱是独立的工作流程。遵循相应的消息批准清单，核对已批准的内容，并重新审核重大变更。不要将先前的批准视为对不同受众或修改后承诺的许可。
核对每位收件人的结果
记录现有预览或运行标识，以及返回的批次 ID（如有）。然后查看每位收件人的报告。completed_with_errors 这样的汇总表示工作需要核对；它本身并不指出应重试哪些对话。accepted 结果不能证明发送已经完成。
在你自己的受控记录中使用这份工作表。这些类别是审核决定，并不承诺每个产品界面都使用相同标签：
- **已报告成功发送：**记录支持该结论的结果。将该收件人排除在新一轮重发之外。发送结果不能证明对方已阅读消息。
- **明确失败：**记录错误以及是否发生过任何发送。解决原因后，检查重试是否合适。
- **解析时跳过：**查看收件人被排除的原因。只有获得授权时才修正范围或身份，然后审核修正后的选择。
- **待处理或已排期：**查看现有操作及其排期。不要因为消息尚未出现就立即启动重复操作。
- **结果不确定：**在决定之前，查看现有运行和相关对话。仅凭超时不能证明消息未发送。
工作表应将每位预期收件人与已知结果及下一步操作对应起来。限制对操作记录的访问；不要将客户身份或消息内容复制到公开报告中。
部分完成的批次并不是全部重发的理由
考虑一个模拟的五位收件人练习。其中两位有成功发送结果，一位明确失败，一位在发送前被跳过，还有一位在超时后结果不确定。这些是示例类别，并非观察到的 Chiho 表现。
将两位已成功的收件人排除在新发送之外。分别调查明确失败和跳过的条目。在任何重试之前，检查结果不确定的收件人的现有操作。如果客户已经回复、撤回请求，或者通过另一条授权途径收到更新，下一步可能完全无需发送。
如果适合重试，仅审核那些结果尚未解决、现在又符合条件的收件人。保留足够的原始运行记录，以说明两次操作的关系。创建新预览会产生新的拟议操作，不能替代对第一次操作的核对。
以运行时限制为准
Chiho 的限制参考说明了代理写入的保守节奏，但静态限制并不承诺送达。Telegram 可能在运行时返回 flood-wait 等待响应和其他限制。遵守报告的等待时间，并在采取进一步行动前检查现有操作。
不要反复提交同一批次、切换账号来绕过限制，或将请求成功理解为每位收件人都已收到消息。如果工具无法提供足够证据来区分待处理工作与失败，暂停受影响收件人的操作，先解决这种不确定性。
扩大范围前先审核一个受控批次
从已授权的测试对话和事实可核实的消息开始。验收检查很实际：你能否解释每位选定收件人、每项排除、所用授权，以及每次发送尝试的结果？
要探索 Chiho 的工作流程，请创建账号，查看 Telegram 模板消息工作流程，并准备受控预览。发送是独立的决定。让首次练习的规模足够小，以便手动核对；只有收件人身份、权限和结果证据都明确时才继续。