Chiho AI
使用 AI 摘要帮助了解情况，来源消息验证实际说过什么，CRM 备注记录已核查上下文和团队决定。摘要可帮助找到话题，但不应成为客户承诺、截止日期或审批的唯一证据。
实际问题是某条陈述应放在哪里，以及新信息与它矛盾时该如何处理。本指南提供用于该决定的记录质量工作表，以及可改用于获授权测试对话的虚构示例。
发布方与证据说明： Chiho 发布本指南。这里描述的 Chiho 行为于 2026 年九月 28 日依据源代码和文档核查，未在真实客户账号中测试。请检查已部署工作区中的可用控制。示例是虚构的，并非客户成果或实测准确性主张。页首图片是已有的 Chiho 界面示例，并非本练习截图。
给来源消息、摘要和备注分配不同用途
来源消息确立参与者实际说过什么。 保留足够上下文，区分请求与约定、提议日期与已确认截止日期、问题与承诺。消息是某项陈述的证据，不一定证明该陈述真实或仍然有效。行动前检查后续更正。
AI 摘要是生成的解读。 将其用于了解大致情况：对话似乎涉及什么、什么可能需要关注，以及哪个细节值得细查。语气肯定的句子不会显示包含了哪些消息，或某个条件是否被遗漏。摘要缺少信息，不能证明对话中没有该信息。
CRM 备注是持续维护的工作记录。 在这里放入已验证事实、待解问题和明确团队决定，并清晰标记各项。手动输入的备注也可能出错。其价值来自来源引用、负责的审核者，以及客户证据与内部判断之间清晰的边界。
例如，如果来源只说“如果安全部门批准，周五可能可以”，那么“客户已批准周五”就是糟糕的备注。更好的备注保留条件：“已提议周五；安全审批仍未确认。在将日期视为承诺前请求确认。”
如果眼前问题是定位原始讨论，先从在 Telegram 历史中查找客户承诺开始。本指南从找到材料之后、需要决定记录什么时开始。
Chiho 保存什么，刷新改变什么
在已审核的 Chiho CRM 源代码中，备注与 AI 摘要是独立字段。备注控件在字段失去焦点或按 Enter 时保存编辑文本。AI 摘要控件生成文本后，将其保存到摘要字段。个人和团队上下文贯穿这些操作；编辑前确认所选账号与工作区。
成功刷新摘要会写入新的摘要值、更新时间，以及最后一条被总结消息的引用。已审核的持久化路径在替换摘要值时，保留同范围内其他 CRM 字段，包括独立备注。它不会将备注合并到生成摘要，也不会确定备注仍然正确。
已审核的生成路径请求一段有边界的近期消息历史。不要假定刷新会重新阅读整个关系历史。 即使摘要刚刷新，较早的约定仍可能需要单独核查来源。同样，“新消息”指示是覆盖提示，不是事实准确性证书。
已审核界面在备注中提供手动编辑，在 AI 摘要中提供生成。不要依赖文档未说明的手动摘要覆盖或可恢复版本历史。将已验证修正放入维护中的备注，保留来源引用，并在刷新后再次检查。重新打开记录验证持久化，不要将编辑器中可见文本视为已完成保存的证明。
使用智能体时，摘要刷新和 CRM 变更可在授权与客户端控制约束下直接执行；并非每次写入都需要独立审批提示。明确请求范围和预期修改。智能体连接指南解释了连接与权限审核。读取摘要、刷新摘要、更改备注和发送消息是不同操作。
同事能够使用的五部分备注
保持记录简洁便于浏览，但重要决定应包含以下五部分：
- 已核查事实： 来源支持什么，包括条件和不确定性。
- 来源定位： 对话和消息日期，或获授权同事可访问的适当消息引用。避免复制不必要的个人信息。
- 解读： 你的评估，明确标为评估，而非客户原话。
- 决定与责任： 团队决定了什么、谁行动，以及还需要什么确认。
- 复查触发条件： 应让人重新查看备注的事件或日期。
这些是建议的撰写约定，并非五个专门的 Chiho 字段或自动强制规则。如果流程提供独立任务或负责人控件，应使用它们明确行动责任。备注中只有某人的名字，不能确立任务指派或通知。
有用的交接备注应让同事回答：什么已知？什么仍不确定？我应该做什么？更广泛的协调见以团队方式管理 Telegram 客户对话。
完整示例：有条件日期变成错误承诺
以下消息、摘要、姓名和决定均为虚构。它们说明一种审核方法；未测试模型或客户流程。
来源，周一： “如果我们的安全审核完成，可以在周五开始试点。”
来源，周二： “安全部门仍有问题。请先不要安排日程。”
假设的生成摘要： “客户将在周五开始试点。”
首先识别差异。摘要将有条件提议转化为承诺，并遗漏了后续指令。刷新可能生成不同措辞，但刷新本身不是验收测试。验收测试是维护中的记录和下一步是否反映来源。
建议备注如下：
周二已核查：周五取决于安全审批。客户随后要求暂停安排日程。来源：本对话中周一的提议和周二的暂停消息。评估：开始日期仍未确认。决定：Maya 将在提出新日期前询问未解决问题是否已解决。客户回复时复查；不要将周五视为已约定。
再考虑一条后续消息：“安全部门已批准。周五已确认。”重新检查来源，再修订备注以反映新约定及其日期。不要将旧的“暂停”指令保留为当前操作。如果先前上下文仍重要，保留简短且有标签的更正，而非两句相互矛盾、无标签的陈述。
该程序不能证明预约已安排或消息已发送。应在相关流程中单独验证这些结果。
处理分歧，不要悄悄把猜测升级为事实
摘要与来源不一致： 返回来源及周边消息。记录有依据的事实，标记摘要差异。不要选择听起来更肯定的文本来解决冲突。
备注与来源不一致： 检查备注记录的是内部决定还是客户主张。内部决定可以合理地不同于客户请求，但必须注明。修正无依据的事实主张，并指出改变了什么。
两条来源消息不一致： 检查顺序、条件和参与者。后续消息可能取代早期提议，也可能指不同范围。如果上下文无法确定，就标为未解决。
所需历史不可用： 记录无法验证的内容。避免将“未获取”变成“从未发生”。在作出依赖缺失证据的承诺前，请获授权负责人澄清。
保存或刷新失败： 保留预期修正，查看错误，重新打开记录以确定已保存状态。验证前不要告诉同事记录已修正。检查时使用同一账号及个人或团队上下文。
工作区的小规模验收练习
使用获准的非生产对话或样例，包含有条件提议、后续更正和无关细节。示例不包含实际客户数据。这是建议的评估协议，没有报告结果。
- 记录所选账号、工作区和对话。生成任何内容前，写下来源支持的当前状态。
- 只有获授权更新记录时才生成摘要。将每条可行动主张与可用来源上下文比较。
- 撰写区分事实、解读、决定、责任和复查触发条件的备注。保存后重新打开记录。
- 如获授权，刷新摘要。再次打开记录，检查备注仍在，且摘要得到独立审核。
- 通过获准测试流程添加样例更正。修订备注，移除过时指令，并在同一上下文验证保存结果。
- 将每个结果标为已观察、失败或未测试。不要仅因生成返回了文本，就报告持久化、共享可见性或摘要准确性通过。
当审核者能够将当前决定追溯到来源，并确定下一项有人负责的操作时，练习完成。它不衡量节省时间或模型总体准确性。
从一个已核查事实开始
在 Chiho CRM中打开一段获授权对话。选择可能改变跟进决定的陈述，验证来源，并在备注中记录当前事实和不确定性。然后检查已保存记录是否符合预期。
如果你在评估产品，请从小型 CRM 试点开始或创建 Chiho 账号。Telegram CRM 指南解释更广泛流程。在使用记录准备对外回复之前，请遵循独立的 AI 草稿审核清单。