Chiho AI
批准 Telegram 消息前，请检查发送账户、准确收件人、完整消息、发送时间，以及任何承诺的证据。审批应涵盖一个具体操作。对早期草稿笼统地说“看起来不错”，会留下太多未解决的问题。
Chiho 有团队消息队列，也有代理发件箱预览流程。两者的权限检查不同。本指南详细介绍代理预览，并提供团队可用于两种流程的检查清单。
**验证说明 — 2026 年 9 月 14 日：**下方产品描述已根据 Chiho 当前源码和文档核对。本文没有读取客户消息，也没有进行预览、审批或发送。现有顶部图片展示操作历史视图，并非今天评审练习的截图。示例均为虚构。
评审前确定发送路径
在团队消息流程中，需要审核的消息可以进入管理员队列。这并不意味着通过 AI 连接执行的每个操作都会进入同一队列。
在代理发件箱中，outbox_preview 解析收件人并保存拟议操作，但不发送消息。返回结果包括预览 ID、收件人数和列表、跳过的收件人、消息预览、到期时间，以及是否需要批准。解析出多个收件人时需要批准；连接使用 ask_always 时，单个收件人也需要批准。
其他获准写入可在适用的客户端控制和 Chiho 检查后直接执行。尤其不要假定 message_send_draft 只是保存文本：它会发送。成员邀请和退出群组有各自的预览与审批流程。启用工具前请阅读 AI 代理连接指南。
审批记录也不能证明另一位经理审核了操作。代理预览与其用户、令牌、个人或团队上下文和访问范围绑定。经过身份验证的网页审批端点检查预览所有者和团队成员资格；它不是让任意团队管理员批准另一位用户代理预览的通用机制。如果流程要求第二个人审核，请明确安排该审核，并确认所选产品流程支持它。
准备包含六项检查的审核材料
1. 发送身份和上下文
记录由哪个已连接的 Telegram 账户发送、操作属于个人还是团队范围，以及对应哪个客户对话。如果账户或聊天名称相似，仅凭熟悉的显示名称并不足够。准备操作前先消除歧义。
团队可见性是访问边界，不是联系每个可见人的许可。团队交接指南介绍如何将客户上下文带入下一步行动。
2. 已解析收件人和排除项
检查实际解析后的列表，不要只看请求的文件夹、标签或数量。核对每个收件人是否属于预期受众。检查跳过的收件人及每项排除原因：请求两个聊天而只解析出一个，并不构成完整的双聊天计划。
批准文案时不要扩大受众。列表错误或不完整时，应修改请求并生成新预览。Telegram 的垃圾消息常见问题建议联系期待收到您消息的人。内部批准不会使不受欢迎的联系变得可接受，也不能保证 Telegram 允许发送。
3. 完整消息和事实依据
阅读完整的拟议消息，而非仅阅读缩短的预览。检查问候语、链接、姓名、适用于所选流程的附件，以及剩余模板占位符。根据获准使用的来源核实价格、交付日期、退款和其他承诺。
在草稿旁保留简短证据备注：“客户在所选对话中要求修订提案；交付日期已由负责队友确认。”如果缺少证据，请明确说明，并删除或限定承诺。消息模板指南提供起点；模板不能证明其说法适用于当前客户。
4. 发送时间和到期时间
注明“立即发送”或准确的计划日期、时间和时区。新加坡的审核者与其他地区的发送者不应猜测“明天早上”是什么意思。检查实际传给工具的计划，而非仅看消息措辞。
预览有到期时间。过期预览需要重新准备和审核；批准不会让它永久有效。计划发送仍受账户能力和 Telegram 当前响应约束。不要仅因为创建了预览，就承诺在特定时间送达。
5. 预览身份和修订
将预览 ID 与审核决定一起保留。Chiho 还返回载荷哈希，作为已准备输入的标识符。执行路径使用与预览关联的已保存操作，而不在发送时接受替换的消息文本。
如果消息、收件人选择、账户或计划发生变化，请准备新预览并审核该版本。不要将哈希当作人可读的内容检查，也不要将审批备注当作修改已保存消息的指令。阅读真正将要执行的内容。
6. 决定和允许的下一步
记录以下三种决定之一：批准此确切操作、修订指定字段，或拒绝拟议发送。注明决策者以及下一步可以发生什么。这是建议的审核记录，并不声称 Chiho 强制执行组织职位或第二审核者政策。
批准和执行是代理流程中的独立步骤。已保存的批准不等于已发送消息。反过来，无需批准的预览可能无需额外服务器审批步骤即可执行。客户端权限和明确任务边界仍然重要。
三个审核决定示例
这些虚构示例仅演示决定，不是已执行操作或客户结果。
批准：两个预期的提案更新
请求指定两个客户聊天，双方都要求修订提案。预览准确解析出这些聊天，没有跳过收件人。完整文本包含正确提案链接，没有未经核实的交付承诺。审核者确认发送账户和明确的立即发送指令。
决定可以写为：“批准预览 P-101，由所选账户立即向列出的两个聊天发送已审核的提案文本。”P-101 是示例标识符。操作人员必须使用真实预览 ID，并在之后检查执行结果。
修订：预览后截止时间改变
预览写着“我们会在周五交付”，但负责队友仅确认周五能提供预计交付时间。审核者将措辞改为“我们会在周五分享预计交付时间”。
该修正需要新预览。写着“使用新措辞”的审批备注不会替换已保存文本。请一起审核修订消息和收件人列表；等待修正时不要执行旧预览。
拒绝：受众缺乏依据
拟议批量操作面向通过用户名搜索找到的人，没有证据表明他们期待这次联系。即便文案礼貌且预览解析出每个收件人，审核者仍拒绝拟议发送。
记录原因，不要为该预览调用执行。单独文档中的拒绝是流程决定，不是底层预览已在产品中取消的证明。适当时使用可用的取消控制，并验证结果状态。
执行后核对结果
检查返回的运行或批次标识符，以及每位收件人的结果。操作报告相应状态时，应区分排队、计划、已发送、跳过和失败。运行层面的“完成”不能证明每位客户都收到或读过消息。
结果不确定或仅部分成功时，重试前先检查已有运行。发件箱实现支持幂等获取已有运行的结果，但新建预览或改变重试身份，不能替代检查哪些收件人已成功。避免因为一位收件人失败就向所有人重复发送。
如果操作仍在运行，记录该状态。如果失败，保留报告原因，并在准备另一操作前判断原消息和受众是否仍然合适。运行时限制和限流等待响应优先于静态发送计划。
在不发送的情况下试用清单
先在文档里写虚构草稿，填写六项检查。将未知账户身份、缺少证据、时间不明确或收件人未解析列为修订原因。这项仅在文档中进行的练习不需要写入工具。
准备检查真实预览时，请明确授权为选定对话创建预览：它虽然不发送，但会保存状态。请代理展示返回的预览身份、已解析和跳过的收件人、完整拟议文本、时间及到期时间，然后在批准或执行前停止。确认客户端工具控制支持这一边界。
将兼容的 AI 客户端连接到 Chiho，评估预览流程。如果仍在选择如何组织更广泛的客户流程，请从 Telegram CRM 指南开始。