钉钉群里IT、人事、报销类问题反复出现，建议采用"先答后转"：Agent只在有现行依据、且当前群受众有权查看的范围内先答，答案附可见的出处和更新时间；缺证、冲突或未解决时转人工。同一对象、问题和可见范围都一致的提问才考虑关联，个人账号或报销等事项不因措辞相似就合并。群消息保留原话，工单承载对象、负责人和结果，两者的边界参见群聊需求转业务工单的确认与状态同步规则；本文讨论的是先答、拒答与转单的判定，而不是把群消息直接变工单。
五种情形的判定
| 群内提问情形 | AI 在群里的动作 | 后续处理 |
|---|---|---|
| 有现行依据且适合向当前群公开 | 回答并附可见的出处与更新时间 | 记录已答，不默认用户已解决 |
| 找不到依据 | 明确说明未检索到，不编造 | 记入知识缺口，补资料后用原问题回归验证 |
| 依据冲突或过期 | 只列当前受众有权看到的来源与待确认项 | 交资料负责人核对口径 |
| 超出知识范围或权限 | 拒答并说明原因 | 给出正确的咨询渠道或工单入口 |
| 用户回复未解决 | 追问确认具体未解决的点 | 确认后转工单，关联原消息与问答记录 |
判定表的下半段比"能答多少"更重要。答不上来的问题进入知识缺口队列，由对应Owner补证据、审批发布后，用原问题及其变体重测，再观察重复提问是否减少；只统计已答数量而不处理缺口，机器人永远在答同一批旧问题。
钉钉侧的接入验证
不要把Slack机制原样搬到钉钉。Zapier 的 ZapIT 是Slack原生帮助台，能在工单产生的Slack线程里直接作答，背后是Slack的线程与历史读取能力；LegalZoom 的 Ask People Team Agent 也是在Slack频道里回答日常问题、真正需要人工时才转工单。这两套是"先答后转"的判定机制参考，不代表钉钉默认具备同样的消息能力。钉钉侧至少要在方案设计阶段核实四件事：应用以什么方式接收群消息、收到后能否定位到具体话题或楼层再作答、能否按授权读取既有群记录作为上下文、提醒提问人时的推送方式与频控。机器人类型与权限差异可先看钉钉群机器人能干哪些活，以开放平台当期文档为准。
落地与验收
- 划范围：选一两个提问最频繁的群和一类知识（如IT常见操作），明确哪些情形必须人工。
- 接入验证：收消息、检索作答、附来源、转单留痕四条链路逐项打通，授权不足的能力明说，不硬做。
- 试点：高频问题先上线，统计已答、拒答、转单和缺口四类数量。
- 验收：抽样核对每条答案的来源能否定位到原文并支持结论，方法见企业 AI 答案来源定位与逐项引用验收清单；再核对重复提问是否合并到同一记录、转单是否关联原消息。
以下为场景示例。某两百人软件公司在IT支持群试点：高频问题集中在VPN、打印、账号权限三类，前两类多数能在群里直接答出并附内部文档链接，账号权限类按规则一律建议转单并关联原消息。两种例外要单独设：涉及个人信息的问题不在群里公开答复，改为单独提醒提问人走工单；提问人有权查看某资料，不代表全群成员都有权。群内只答适合该受众公开的内容；敏感事项改走获授权的私密渠道，也不能跨群复制出处或处理进度。试点期每周复盘一次转单记录，核对有没有本可以先答却直接转人工、以及该转没转的情形，规则据此微调。
更多落地方法可顺着AI Agent 落地专题阅读；要把群内问答接进现有工单系统与钉钉组织架构，可了解开沿 Agent。
来源说明：本文机制参考 Glean 客户故事中 Zapier 的 ZapIT（Slack原生帮助台，线程内作答，原文：https://www.glean.com/resources/customer-stories/zapier ）与 LegalZoom 的 Ask People Team Agent（真正需要人工才转工单，原文：https://www.glean.com/resources/customer-stories/legalzoom ）。两者均为厂商发布、未独立验证，本文不引用其效果数字，钉钉侧场景为本土方案示例。
