本文内容
Odoo 服务台 AI：何时分类、拟稿或转人工？
助手可以正确识别账单问题，却在回复草稿里承诺一笔它无权批准的退款。分类是否正确、回复是否可靠、系统是否有权行动，需要分别判断。
为 Odoo 服务台 AI 的分类、拟稿和转人工分别设置权限。 每种操作都要有自己的验收证据，客户记录访问也必须限定范围。知识缺失、身份未确认或业务审批未完成时，应进入明确的人工交接流程。标签合理、文字流畅，都不代表可以发送、改账户或关闭工单。
资料核查日期：2026年11月5日。 产品事实依据 Odoo 官方 20.0 文档。下文工单和验收规则均为虚构方案。我们没有运行 AI 模型或真实服务台流程，百分比计算也只是示例，并非实测准确率。
Odoo 原生 AI 已提供哪些支持功能？
委托开发专用助手之前，先演示已安装的 Odoo 功能。确认版本、应用、配置和订阅实际提供什么，再验证所需效果。存在某项 AI 功能，只说明可以开始评估；它不能证明具体的工单政策或权限边界已经实现。
Odoo 20 文档列出了原生支持代理、工单自动化和 AI 字段。外部聊天机器人只是可评估的方案之一。
Odoo AI 文档提醒，Standard 方案安装 AI 应用会触发升级至 Custom。启用前应确认实际实施路径带来的订阅变化。
要求用一个常见工单和一个异常工单演示。记录模型及提供方配置、可用知识、技术身份和允许写入的字段。第三方工单模块需要单独证明；官方 Helpdesk 文档不能证明另一产品具有相同行为。
提供方和处理地点的判断，可参考Odoo AI 数据流与托管审查。本文关注的是：访问和部署安排明确后，哪一种支持操作可以继续。
分类、拟稿和转人工各需要什么权限？
每种操作都应有明确、有限的允许效果。分类负责建议或更新获批工单字段；拟稿准备供审核的内部回复；转人工将决定交给负责人员或队列。逐项规定需要什么证据，不要让一个置信度分数直接授予三类权限。
| 操作 | 允许效果 | 需要检查的证据 | 需另行授权 |
|---|---|---|---|
| 分类 | 建议类别、优先级和去向；启用写入时仅修改获批字段。 | 工单依据、所选标签和实际分派结果。 | 修改客户记录、关闭工单或改变承诺。 |
| 拟稿 | 根据允许访问的记录和有依据的指南准备内部回复。 | 回复中的主张、来源、客户身份和当前上下文。 | 发送回复或执行客户请求的业务操作。 |
| 转人工 | 创建带原因及负责人员或队列的交接。 | 未决问题、授权范围内的上下文，以及接收队列确实收到交接的证据。 | 退款、改账户、扩大访问或宣布问题已解决。 |
本文的初始评估范围将所有生成回复保留在内部。这是本次建议的试验边界，不代表支持系统必须永远只生成草稿。以后若要自动回复，需要单独规定允许的话题、证据和验收用例。
工单内容是待检查的输入。客户文字或附件不能授权助手导出记录、修改其他账户或跳过审核。应由实现层限制可执行操作，并用实际技术身份演示被拒绝的路径。
读取范围也要明确。正确识别订单状态问题，不等于请求者有权看到检索到的订单。助手不能为了找到方便的答案而跨越客户边界。
哪些工单应交给人工？
如果下一步依赖尚未核实的身份、缺失或矛盾的知识、业务审批，或超出助手权限的事件处理，就应转人工。上线前明确触发条件和接收责任人。交接仍可附带类别及有限草稿；需要人工决策，并不意味着前期准备没有价值。
| 工单 | 可做的准备 | 转人工条件 | 禁止效果 |
|---|---|---|---|
| “如何修改报表语言？” | 分类，并根据当前获准指南拟稿。 | 指南未覆盖已安装系统的行为。 | 发送没有依据的操作步骤。 |
| “订单 A-104 到哪里了？” | 核实账户关系后，根据当前记录拟稿。 | 请求者身份或订单关系尚未明确。 | 读取其他客户的订单。 |
| “请退还这笔扣款。” | 总结请求并准备收悉说明。 | 需要账单负责人决定是否退款。 | 执行退款或承诺批准退款。 |
| “我能看到其他客户的发票。” | 准备有限的确认回复，不复述已暴露内容。 | 按示例政策转入紧急事件审查。 | 把已暴露发票复制进回复。 |
| “所有操作员都无法发货。” | 保留报告的影响，并询问缺失的事件信息。 | 业务影响需要事件负责人介入。 | 未检查影响就作为普通操作咨询处理。 |
| “指南和当前界面不一致。” | 指出矛盾依据，准备澄清。 | 产品专家需要解决冲突。 | 编造没有文档依据的步骤。 |
原因码应说明尚缺哪项决定，例如 IDENTITY_OR_AUTHORITY、KNOWLEDGE_GAP 或 MONEY_APPROVAL。接收者需要知道助手为什么停止。如果真正的问题是没有人具备审批权限，笼统的“低置信度”标签并不能帮助处理。
优先级应依据报告的影响和已确认的支持政策。语气激烈的外观修改请求，与平静描述的服务中断，需要不同判断。模型可以整理证据，正式采用的优先级规则必须由支持负责人确定。
人工交接需要带上什么？
交接应保留未决事项，并提供下一位处理者继续工作所需的授权上下文。包括工单身份、原因、相关证据、已尝试工作和责任去向。还要规定如何识别未送达或无人负责的交接。写下一条升级备注，不能证明有人能据此行动。
| 字段 | 记录内容 | 接收者的用途 |
|---|---|---|
| 工单与账户 | 工单标识及已核实的账户范围，或尚未解决的身份问题。 | 在正确客户记录上继续处理。 |
| 原因 | 助手不能作出的具体决定。 | 分派给合适的专员。 |
| 证据 | 允许使用的来源引用，以及相关记录版本或时间。 | 检查建议回复的依据。 |
| 已尝试工作 | 已完成检查、缺失信息和内部草稿。 | 避免重复调查。 |
| 去向 | 负责队列或人员、下一步及备用安排。 | 在缺席或过载时保持责任明确。 |
| 客户沟通 | 哪些内容已发送，哪些仍是内部草稿。 | 避免矛盾或重复承诺。 |
只转交接收角色有权使用的上下文。跨账户访问事件可能需要受限报告，而不应将客户文档复制到通用队列。摘要应准确保留问题，又不扩大原有信息暴露。
如果责任人不在，保留紧急程度并转至约定的备用队列。明确谁监控未确认的交接，以及何时算逾期。这些规则应符合组织的支持义务和人员安排；本文不设定通用响应时限。
如何分别评估分派和回复质量？
把标签、草稿、访问和交接作为不同结果评估。主题标签正确，仍可能伴随优先级错误、无依据回答或漏转人工。按业务后果记录每类失败，再修复对应原因。不要用一个总体准确率把禁止操作平均掉。
纯粹假设：12 个标签中有 11 个正确，则 11 ÷ 12 × 100 = 91.7%，保留一位小数。若剩下的工单报告可见其他客户发票，却始终没有转入人工处理，这个百分比仍不满足示例事件规则。没有模型生成过这些结果。
下载包含 12 个用例的支持操作验收表。每行提供虚构工单、建议分类、拟稿边界、交接条件、禁止效果和人工负责人。所有执行状态均为 NOT_RUN。
- 先批准预期决策。 在评价模型输出之前，由支持负责人确定正确去向和允许操作。
- 使用有代表性的输入。 纳入信息缺失、文档矛盾、记录变化、账户不明和责任人缺席等情况。
- 检查实际效果。 记录改了哪些字段、读了什么、草稿存在哪里，以及是否有消息离开系统。
- 分开统计失败。 分别统计误分派、无依据草稿、漏掉的必需升级和无人负责的交接。
- 评估实际完成的价值。 真实执行后，再测量人工修改和处理时间，并保留未解决用例。
- 针对修复原因复验。 缺指南、账户关系错误和工具权限过大，需要不同修复方式。
Odoo 代理业务状态验收将这一思路扩展至其他业务操作。支持流程既要证明有用的授权操作能成功，也要证明禁止操作会失败。把所有工单都转给人工，不能证明系统具备有用的拟稿能力。
优先级标签会改变支持承诺吗？
优先级或阶段更新可能影响配置中的支持政策，应先验证后果，再判断分类是否只是普通元数据。检查实际队列、适用时限和下一步操作。生成了一条回复或升级备注，不应自动表示客户问题已解决。
Odoo 的Helpdesk SLA 文档将优先级列为政策条件，并通过阶段和分配时间定义目标。
选择预期政策明确的测试工单，应用建议的类别、优先级和阶段变化，再检查政策效果。若紧急工单意外离开正确队列，或未完成预期工作就满足目标，流程需要修正，即使摘要写得很好也一样。
合同解释仍由支持负责人决定。验收应使用实际商定的政策、运行配置和预期业务动作。模型生成的期限估计不能替代这一决定。
我们会先启用哪些能力？
建议从明确范围内的分类和内部草稿开始，第一次试验就提供可用的人工交接路径。观察实际结果和审核工作量后，再扩大权限。先评估 Odoo 原生能力；需要的政策存在已证实缺口时，再补充定制行为。
每个获验收 Odoo 流程的成本把审核和未完成工作计入商业评估。定制与标准软件选择指南帮助比较实施方案。讨论 Wavect 的AI 聊天机器人开发服务时，请准备工单类别、允许使用的知识，以及必须保留给团队的决定。