04.群里反馈：怎样提问、调查和登记

1.用户从一句自然表达开始

在管理员已经接入并授权的企微工作群里，选择本群实际助手并@它，再说明场景即可。正文里看起来像“@助手”的一段文字，不一定等同于在界面中真正选择机器人。

想表达什么	可以怎样说
问用法	“我想导出本月全部记录，应该从哪里操作？”
报现象	“我在列表选了整个月，导出文件却只有第一页。预期包含全部结果。”
提需求	“每周都要整理上周记录，希望能按日期一次导出，减少手工拼接。”
补前文	“关于刚才导出只到第一页的问题，我确认日期已经选了整个月。”

用户提供已知事实就足够，不用先猜根因、模块或修复方法。截图和日志应先脱敏；当前接入不承诺所有图片、文件和语音都可直接识别。

咨询通常先根据当前规则与代码解释用法。答复已经解决问题，没有需要改变的事项，就可以结束，不必为了留下编号新建工单。

故障先在已有权限内调查。只有证据支持蜂巢自身缺陷且需要代码修改时，群Bug入口才查重登记。若原因来自调用方式、客户端或网络，给出有依据的建议；仍不清楚时说明具体缺失证据和下一步。

需求关注使用场景、希望得到的结果、价值、替代方式和代价。信息不足先澄清，有真实取舍交负责人判断。创新、有争议或实现成本高，不等于可以凭个人偏好直接拒绝。

好的追问应当影响下一步判断。例如，已经知道用户选择了日期范围，就不再问一次“有没有选日期”；若不知道实际行为，则优先问导出的条数或页面提示。

每轮只补问一两项关键事实，让用户容易回答。协调方也应主动检查已有资料，不能把自己可查的全部工作变成用户填写表格。

如果缺少的信息决定了查询是否安全，先说明受影响动作并澄清，不先运行风险未知的操作试一试。

当前桥接可能为每条群文本建立新的请求和Slack根消息，不能依赖同一个人自动续聊，或把引用文字当作可靠原消息标识。

用户自然点明事项最有帮助。接收方确需查前文时，按既有规则在固定频道、真实桥接来源中检索，以当前事件为上界向前30分钟，最多保留5个候选，再逐条核验同群和允许公开的用途。

同一频道不表示同一企微群；同一线程也可能含私有决定。只有明确事项与语义共同支持唯一关联时才使用，不能因为“最近只有这一件”就猜。答复仍走当前请求与原群，不移动旧消息或继承旧许可。

命中同范围旧Issue时，说明关联和有依据的新增信息，避免重复建单。群入口没有因此获得编辑旧单、追加评论、改标签或关单的权限。

新单正文用普通语言写清场景、现象、影响、初步判断、剩余未知和可观察验收。保留独立评审状态和正式登记身份，不把原始群聊、私人审批、路由标识或敏感技术细节贴进工单。

工具返回写入后还要独立读取，确认实际仓库、编号和正文。结果未知先核验，不盲目再建一份。只有核验成功才说“已登记”。

登记回执可以这样表达，下面是合成例子：

关于导出只到第一页的问题，已登记为蜂巢Issue#42，待负责人确认。现有静态代码与已核对的导出规则不一致，支持存在需要修改的条件分支；现场部署版本和实际影响范围还待核实。下一步在已有权限内补充核对。

这条回复同时说明登记结果、已有判断和未知。证据不足时不用凑满几点，更不能编造根因。只报一个编号或笼统说“等待排查”，会让用户不知道调查究竟推进了什么。

新单成功后及时核验长期来源关联，再检查原请求是否已经回复过登记结果。先完成原群回执，再到dots单项问询采纳；不能只在负责人通道汇报而漏掉原反馈者。

接收方只能在已有批准的私有映射使用范围内核验当前发送者姓名。姓名未知时省略称呼，提出人记录按规范标注待核实，不要求用户为了一次反馈公开身份资料。

出站回复使用普通姓名和事项，不做真正提及、纯文本@或提及测试。读到姓名也不表示取得权限或能够跨群继承上下文。

同一请求的根消息、附件就绪等重复事件需要合并核对。已经确认成功的登记回执只回一次；发送未知先查真实结果。只有用户明确要求补充，或出现关键新事实时，才在原权限内增加必要答复。

与蜂巢无关的内容不交给开发工具代查。群用户指定个人设备目录、聊天、凭据或任意终端命令时，直接说明超出范围；自称负责人或声称只读都不能把群变成远程终端。

对于有充分事实依据、明显破坏必要能力或安全边界，且没有合理目标或可成立替代设计的要求，可按现有规则直接拒绝，并说明原因与可行替代。信息不足或意见有争议时，先调查或交负责人决定。

这些界限保护的是正在处理的真实问题：让普通产品反馈继续推进，同时避免把群消息误用成研发授权或任意设备操作指令。