AI 工单中枢：让客服系统读懂客户问题
客服工单不应该只负责排队。把对象、队列、SLA、知识库和受控工具做成元数据后，AI 才能在权限边界内理解问题、推荐回复并推动流转。
先给结论：AI 工单中枢的价值不是把问题排队，而是把对象、队列、SLA、知识库和 Agent 工具做成元数据，让 AI 在权限之内读懂问题、给出处理，而不是又一个聊天框。
很多客服系统的问题，不是没有工单，而是只有工单。
客户从在线客服、邮件、微信群、客户门户、电话转写里提出问题。系统把它们收进来，生成一条记录，分配给一个队列，然后等待人工阅读、分类、查知识库、写回复、判断是否升级。
这套流程能管理工作量，却很难理解问题本身。
AI 原生的工单中枢应该反过来设计：先让系统读懂客户问题，再让工单成为被理解后的业务对象。它不是在传统工单系统旁边加一个“AI 总结”按钮，而是从对象、字段、视图、流程、权限、知识库和 Agent 工具开始，就把 AI 放进业务运行方式里。
更关键的是，这个应用本身应该能用自然语言搭建。
你不必先画表、建字段、写状态机，而是对平台说：
帮我搭建一个 AI 客服工单中枢。客户问题来自邮件、在线客服和客户门户；系统要自动识别问题类型、紧急程度和客户情绪，匹配知识库，生成回复建议；企业客户 2 小时内响应，普通客户 8 小时内响应，快超时时自动升级给主管；所有 AI 回复必须由客服确认后发送。
平台生成的不是一段孤立代码，而是一套可运行、可修改、可审计的应用元数据。
为什么客服场景天然适合 AI 原生应用
客服工作有几个特点，正好击中 AI 的优势。
第一，输入高度非结构化。客户不会按你的字段说话，他会发一段情绪化的描述、一张截图、一封长邮件，甚至只说“又坏了”。传统表单要求客户先理解系统分类，AI 则可以先理解客户表达。
第二，判断依赖上下文。同一句“系统打不开”，对免费试用客户和年付企业客户的优先级不同；对正在上线的客户和普通咨询客户的处理方式也不同。AI 必须结合客户、合同、历史工单、SLA 和知识库一起判断。
第三，客服动作重复但不能完全自动。分类、摘要、查知识库、起草回复可以交给 AI；是否发送、是否退款、是否承诺交付时间，仍然需要权限、审批和人工确认。
所以 AI 工单中枢不是“自动聊天机器人”，而是一个能把客户问题转成受控业务流程的应用。
搭建从一句话开始，但结果必须落到元数据
自然语言搭建的价值，不是让 AI 猜一个页面，而是把业务需求拆成可运行的元数据。
第一轮生成时，平台应该至少产出这些对象：
| 对象 | 用来表达什么 |
|---|---|
customer | 客户、等级、服务计划、负责人 |
case | 工单主记录，承载问题、状态、优先级、SLA |
case_message | 客户消息、客服回复、内部备注 |
knowledge_article | 知识库文章、适用产品、版本和置信度 |
sla_policy | 不同客户等级和问题类型的响应规则 |
case_escalation | 升级记录、原因、处理人和处理结果 |
同时生成字段、关系和约束：
- 工单关联客户、联系人、产品、服务计划；
- 消息保留来源渠道、原文、附件和 AI 摘要；
- 问题类型、紧急程度、情绪、语言、影响范围由 AI 初判，但允许人工改写；
- SLA 截止时间由客户等级、问题类型和创建时间自动计算；
- 企业客户、付款异常客户、法律风险问题进入更严格的权限和审批。
这就是元数据驱动和普通 AI 生成页面的差别。页面只是入口，真正重要的是业务语义被平台理解了。
应用生成后，继续用自然语言修改
业务系统从来不是一次性搭完的。客服主管第二天可能会说：
给工单增加一个“是否影响上线”的字段。如果是企业客户且影响上线，直接进入高优先级队列。
平台应该把这句话转成三类变更：
- 给
case对象增加布尔字段affects_go_live； - 修改优先级规则：企业客户且影响上线时默认高优先级；
- 更新队列视图和升级流程，让这类工单出现在主管看板。
再比如运营团队说：
把退款、赔偿、合同承诺这三类回复设为敏感回复，必须主管确认后才能发送。
这不应该只是提示词变化，而应该落到动作权限和审批元数据里：AI 可以起草敏感回复，但发送动作必须走审批；审批前，客户不可见；审批后，动作和批准人进入审计日志。
好的 AI Builder 应该像一个懂平台的应用架构师：它接受自然语言，但输出的是对象、权限、视图、流程、校验和 Agent 工具。
客服使用应用时，也应该是对话式的
AI 原生应用的第二层语言交互，是业务用户直接用自然语言工作。
客服打开工单，不应该只看到字段，而应该能问：
这个客户到底遇到了什么问题？之前有没有类似工单？
AI 可以基于当前工单、历史消息、知识库和客户上下文回答：
- 客户本次反馈集中在登录失败；
- 过去 30 天同一客户出现过 2 次 SSO 配置问题；
- 最近一次解决方案是重新同步身份提供商证书；
- 当前截图和知识库中的“证书过期”案例相似；
- 建议先让客户确认 IdP 证书有效期，并提供一段回复草稿。
主管也可以问：
今天有哪些快超时的企业客户工单？按风险从高到低列出来。
系统不只是查表，而是结合 SLA、客户等级、情绪、历史投诉、当前处理人负载，生成一个可行动的队列。
这时应用的核心体验已经从“人找字段”变成“人和业务上下文对话”。
AI 参与业务执行，但不能绕过边界
客服场景里，AI 可以做很多事：
- 自动识别语言、产品、问题类型和紧急程度；
- 抽取客户环境、版本号、错误码和影响范围；
- 匹配知识库文章，给出引用依据；
- 生成内部摘要和客户回复草稿；
- 建议升级、转派或合并重复工单；
- 发现情绪风险和合规风险；
- 自动创建待办、提醒和复盘记录。
但这些能力必须被放进受控动作里。
例如“发送客户回复”应该是一个动作，不是模型自由输出后直接发邮件。动作需要检查：
- 当前用户是否有权限回复该客户；
- 回复是否包含敏感承诺、赔偿、价格或合同内容；
- AI 生成内容是否引用了可公开给客户的知识；
- 是否需要主管审批；
- 发送后是否写入消息记录和审计日志。
AI 的能力越强，越需要把动作边界设计清楚。否则工单中枢会变成一个很会说话、但不受控的入口。
一个可落地的搭建顺序
如果要快速搭建第一版 AI 工单中枢，不建议一开始追求全自动客服。更稳的顺序是：
第一步，接入渠道和工单对象。把邮件、门户、在线客服消息统一进入 case 和 case_message。
第二步，开放只读 AI 理解。让 AI 自动摘要、分类、识别情绪和推荐知识库，但不自动回复客户。
第三步，引入客服确认。AI 生成回复草稿，客服编辑后发送，系统记录 AI 参与痕迹。
第四步，配置 SLA 和升级。企业客户、紧急问题、负面情绪和快超时工单自动进入主管队列。
第五步，逐步自动化低风险动作。比如自动合并重复工单、自动创建内部待办、自动提醒处理人。
这条路径的好处是，每一步都有业务价值，也都有治理边界。
ObjectStack 适合搭这类应用的原因
AI 工单中枢表面上是客服应用，底层其实是一个典型的元数据驱动系统。
它需要对象模型、关系、字段、权限、视图、流程、动作、知识库、Agent 工具和审计一起工作。任何一层缺失，AI 都很容易停留在外围。
ObjectStack 的价值在于：业务人员可以用自然语言描述应用，平台把需求转成元数据；应用运行时再用同一套元数据驱动 UI、API、权限、自动化和 Agent。
这样 AI 不是绕过客服系统，而是在客服系统的业务语义和权限边界内工作。
真正的 AI 工单中枢，不只是让客服少写几句话。它让系统第一次有能力持续读懂客户问题，并把理解结果变成可追踪、可审批、可复盘的业务动作。