prop-ai-hr/docs/银城大喇叭与问模块纠偏增量方案-20260722.md

“银城大喇叭 + 问模块纠偏”增量方案

版本：v1.0 日期：2026-07-22 状态：A（问模块事实纠偏）与 B（银城大喇叭核心）已本地实现并完成定向验证；尚未部署，C—E 仍待实施。 适用范围：银城帮道员工端、管理端与 ruoyi-aihr 业务模块 关联方案：产品功能优先级与实施计划、员工端 APP 分阶段实施总纲、问师傅多轮会话与原始资料交付设计

0. 决策摘要

本方案不是新增一个普通公告页，而是把“公司告诉员工什么”和“员工听完后还能问清楚什么”连成一个可信闭环。

1. 银城大喇叭是员工端的公司信息频道，入口复用首页右上角的喇叭图标；不新增第五个底部 Tab。
2. 已发布的首版消息面向本租户全员可查；按项目、岗位、层级的匹配用于置顶、提醒和排序，不应导致员工完全看不到公司公开信息。
3. 员工可在消息详情中点击“就这条消息问数字师傅”，带着受服务端校验的消息上下文进入现有“问”模块。
4. “问”回答“我现在该做什么”时，必须先查该员工当前真实任务；没有任务就明确说明“当前没有查到待办”，只能给非强制建议，不能把通用培训内容伪装为已下发工作。
5. 首版不包含高管直通、匿名建议、企业微信/短信强触达、考勤请假审批、工单派发或自动创建任务。这些能力另立流程和权限，不混入大喇叭 MVP。

这项增量同时服务两个目的：一是让制度、通知、文件不再散落在群聊中；二是让员工在接收信息后能基于原文继续追问，并获得有来源、不过度承诺的回答。

1. 背景、问题与目标

1.1 当前问题

问题	对员工的影响	根因	本方案处理方式
现有普通公告不能形成真正的公司消息闭环	不知道哪些信息与自己有关，也无法确认是否读过	sys_notice 只有常规公告基础，不具备定向提醒、阅读审计、附件摘要与补推能力	建立独立的“大喇叭”领域模型，不把普通公告包装成已完成的公司消息系统
消息阅读后仍需在群里或重新描述背景提问	员工得不到针对该通知、制度或文件的解释	消息内容与“问”的会话上下文没有受控连接	在消息详情提供“就这条消息问数字师傅”，由服务端传入并校验消息上下文
“问”会把岗位通用培训推荐说成员工当前必须完成的任务	员工被误导，主管也无法判断任务是否真实存在	回答只检索知识，未以当前员工的真实任务状态作为行动结论依据	将“真实待办”设为独立数据工具；无任务时禁止生成“去完成”动作卡
员工自称其他岗位后，回答可能被错误带向该岗位训练方案	角色、任务与权限边界混乱	角色描述被当作身份事实	服务端当前组织身份优先；其他岗位内容只能作为跨岗位参考明确标注
“问”页面支撑组件占用过多空间	对话上下文容易被打断，追问成本高	页面没有把连续会话作为核心内容	首轮保留引导；会话开始后收起快捷问题、项目和成果组件，突出消息来源与对话

1.2 增量目标

目标	可观察结果
统一公司信息入口	员工从首页喇叭进入“银城大喇叭”，可查看全员频道及与自己相关的提醒
消息可理解	每条可带原文、附件、AI 摘要和“与我有关”说明；摘要不能替代原件
消息可追问	员工无需复制粘贴消息，即可围绕该条消息连续追问
回答不越界	涉及真实任务、培训、审批、工单、外部处理结果时，只依据可验证数据回答
可运营、可追溯	发布、版本、命中、阅读、失败补推和问答来源均可审计

1.3 成功标准

首版上线后，不以“页面存在”或“日活”作为完成证明。以下闭环均有运行证据才可称为可用：

1. 管理人员发布一条面向全员的通知，并按目标人群设置提醒或置顶。
2. 目标员工在首页看到真实未读提示，从列表进入原文和附件。
3. 员工点击“就这条消息问数字师傅”，提问能引用当前消息，且不能越权读取其他消息或附件。
4. 员工追问“我现在要做什么”时，系统根据真实任务数据给出“有任务”“无任务”或“无权确认”的结果。
5. 管理端能查看发布版本、范围、阅读情况和提醒失败记录；不可用时不伪造“已送达”。

2. 产品定位与范围边界

2.1 模块职责

模块	要解决的问题	首版职责	不承担的职责
银城大喇叭	公司信息如何可靠触达、回看和理解	消息发布、频道浏览、定向提醒/置顶、阅读审计、附件与摘要	审批流、工单系统、即时聊天、匿名建议箱
问 · 数字师傅	员工如何理解制度、消息和工作知识	有来源的消息解读、SOP/知识问答、真实任务状态说明	擅自派工、自动创建任务、承诺外部部门已经处理
学 / 练	员工如何获得并完成训练	已有学习、陪练、训练任务承接	承担公司通知分发
后续员工直达	员工如何向管理层提出敏感意见或求助	后续单独设计匿名、实名、收件人、回复 SLA 与审计	复用大喇叭消息表“顺手实现”
北森/外部 HR	请假、考勤、正式人事流程如何办理	后续有正式接口合同后承接	用问答或大喇叭模拟审批成功

2.2 本次纳入范围

• 首页喇叭入口、真实未读红点和“大喇叭”消息列表。
• 全员公开频道、按组织身份匹配的提醒/置顶、已读未读和发布时间线。
• 消息详情：原文、附件、发布人、版本、适用提示、AI 摘要、“与我有关”、已读状态。
• 消息详情到“问”的受控上下文跳转，以及在会话中持续显示消息来源。
• “问”对消息类、知识类、真实待办类问题的意图分流与回答纠偏。
• 管理端的发布、撤回/修订、范围配置、阅读审计和失败记录。

2.3 明确不纳入首版

• 高管直通、财务/人力/审计直达、匿名建议、投诉受理及其工单分派。
• 企业微信、短信、电话等强触达渠道；H5 的页面内提醒不能被表述为系统级推送。
• 正式请假、考勤、排班、工单、线索、客户画像和北森审批。
• 依据一条消息自动创建训练任务、工作任务、成果记录或 COMPANY/PENDING 外部流转。
• 将问师傅改造成长期个人记忆。现有会话仍保持 30 分钟不活跃过期、最近六轮上下文和显式“新对话”。

3. 目标体验与信息架构

3.1 一条消息的员工闭环

flowchart LR
  A[管理端发布公司消息] --> B[服务端生成版本、范围与附件索引]
  B --> C[银城大喇叭：全员频道]
  B --> D[命中员工：置顶或提醒]
  D --> E[首页右上角喇叭红点]
  C --> F[消息详情：原文、附件、摘要]
  E --> F
  F --> G[就这条消息问数字师傅]
  G --> H[服务端校验消息、版本与当前身份]
  H --> I{问题类型}
  I -->|消息解释| J[仅依据消息及获授权附件回答]
  I -->|制度/SOP| K[企业知识检索并给出来源]
  I -->|我现在做什么| L[查询当前真实任务]
  L -->|有任务| M[展示真实任务和可执行入口]
  L -->|无任务| N[明确无待办，仅给可选建议]

3.2 首页与列表

首页入口

• 复用“今日”首页右上角现有喇叭图标，名称为“银城大喇叭”。
• 登录后根据服务端返回的未读数展示红点或数字；未登录时不展示假未读，点击后先进入登录。
• 红点只表示当前员工仍有未读的已发布消息；读取成功后应实时消退，不允许前端写死演示状态。

频道列表

建议提供三个筛选，不增加复杂频道树：

筛选	内容	排序规则
全部	租户内已发布、可公开给员工查看的全部消息	发布时间倒序；目标命中置顶优先
与我有关	当前身份被配置为提醒/置顶对象，或 AI 能明确说明相关点的消息	提醒优先，再按发布时间
必读/未读	标记为必读且当前员工尚未阅读的消息	必读优先，按发布时间

“与我有关”是帮助理解和排序的增强能力，不是对公司公开内容的访问过滤。首版发布人只能在大喇叭发布可向全租户员工公开的内容；涉及敏感人员、薪酬、纪律或审批材料，应走专门授权系统，不应通过本频道分发。

3.3 消息详情

消息详情是员工理解和追问的起点，固定包含：

• 标题、正文、发布时间、发布人、消息版本、适用提示。
• 附件清单与受保护下载；AI 摘要只用于快速理解，必须可回到原文/原件。
• “与我有关”：说明是因项目、岗位、层级或内容主题而被提醒；匹配不确定时显示“可能与你相关”，不能伪装成确定命中。
• 阅读状态：打开详情即请求记录阅读；阅读记录以服务端成功写入为准。
• 主行动按钮：“就这条消息问数字师傅”。

按钮点击后进入既有“问”模块，顶部出现可关闭的上下文条，例如“正在咨询：夏季服务标准通知（v2）”。员工可继续多轮追问；关闭上下文条或点击“新对话”即退出该消息语境。

4. 银城大喇叭功能设计

4.1 发布与版本

能力	首版规则	审计要求
草稿与发布	仅具备发布权限的管理人员可新建、保存草稿、发布	记录创建人、发布人、发布时间
内容	通知、制度、新闻、文件、图片等公开公司信息	保存正文、附件、来源和内容哈希
版本修订	已发布内容修订后产生新版本；重大变更可重新提醒	保留版本链，消息问答引用具体版本
撤回	撤回后频道不可再展示；已读审计保留	记录撤回人、时间、原因
必读	标记后进入员工“必读/未读”筛选，可配置提醒	不把“已发布”误写为“已送达”

首版建议控制在“可公开发布的信息”。制度、通知的审批责任仍由线下或既有管理制度承担；大喇叭保存的是发布证据，不取代企业正式发文流程。

4.2 目标匹配、提醒与可见性

分发策略采用“公开可查 + 定向优先”：

1. 公开可查：租户内员工可从“全部”频道查阅已发布内容，避免因为组织资料缺失而完全错过信息。
2. 定向优先：发布人可按项目、岗位、层级配置提醒/置顶对象；命中的员工在列表和未读提示中获得优先呈现。
3. 低置信提示：组织资料不完整或匹配存在歧义时，降级为“可能与你相关”，同时保留在全员频道，不做静默丢弃。
4. 失败可查：对需要提醒的对象，生成目标快照和处理状态；匹配失败、用户身份无效或提醒写入失败都应进入运营待处理，而不是显示“已覆盖”。

组织匹配以服务端的租户、当前有效组织身份、项目、岗位、层级为准。客户端不得传入或伪造项目编码、岗位编码来改变自己是否命中。

4.3 文件、摘要与“与我有关”

能力	规则
原件	附件沿用受保护资源交付，员工每次访问仍需重新授权；不能把真实下载地址直接写入消息正文
摘要	发布或解析时生成简短摘要；模型失败时显示“摘要暂不可用”，原件仍可阅读
与我有关	按员工已授权的项目、岗位、层级及消息内容生成简明说明，并标识依据；不能根据未授权个人数据推断
过期内容	若消息有有效期，到期后从默认列表降级或隐藏，但保留审计和管理端查询能力
版本一致性	摘要、相关性说明、附件解析结果都绑定消息版本；版本更新后不得把旧摘要当作新正文解释

4.4 阅读、补推与运营视图

首版需要的运营数据是“发布是否可追溯”，而非展示未经验证的覆盖率或日活：

• 发布数、已读人数、未读人数、必读未读人数、目标匹配失败数。
• 按消息查看目标快照、首读时间、最后读取版本和提醒状态。
• 对未读对象支持人工再提醒；每次操作记录操作者和时间。
• 员工已读某一版本后，若发布人更新为重大版本，可重新成为未读；是否重新提醒由发布人明确选择。

5. “问”模块纠偏设计

5.1 回答的三条受控路径

员工问题	可使用的数据	正确回答形态	禁止行为
“这条通知是什么意思？”“我需要注意什么？”	当前已授权消息、该消息版本及其获授权附件	围绕原文解释，注明“依据本条消息”或附件来源	把未出现在消息中的要求说成通知结论
“这个流程怎么做？”“请假制度是什么？”	企业知识库、SOP、制度文件	给步骤、适用条件和来源；正式审批入口不存在时明确说明	把制度咨询变成已经提交/已经批准的业务结果
“我现在该做什么？”“我有什么培训待完成？”	当前员工真实任务状态、当前组织身份、被授权的任务/训练数据	有任务：给出任务名称、状态、截止信息和真实入口；无任务：明确没有查到待办	用通用课程、岗位建议或别人的任务生成强制行动卡

优先级是：真实任务事实 > 当前消息原文 > 授权知识来源 > 非强制建议。模型只能组织语言，不得替代事实判断。

5.2 消息上下文追问

员工从详情页发起追问时，前端只传递 messageId（以及会话延续所需的既有上下文标识），不传递或信任消息正文、附件文本和目标范围。后端必须：

1. 根据当前登录身份重新校验该消息属于本租户、已发布、未撤回且当前员工可查看。
2. 读取消息的当前或指定版本、已授权附件解析内容和来源标识。
3. 将消息内容作为“可引用资料”而非系统指令，防止正文中的提示语改变模型权限或行为。
4. 在回答中标明来源：例如“根据《夏季服务标准通知》v2……”。消息未说明的内容，要直接说明“本条消息未明确”，再建议查对应制度或咨询负责人。
5. 维持既有短会话规则：30 分钟不活跃过期、最近六轮；不能因为带了消息来源而变成长时记忆。

消息被撤回、版本过期或员工权限变化后，后续提问应返回明确的不可用说明，不得继续以缓存内容作答。

5.3 “我现在做什么”的事实规则

为避免把“建议”说成“待办”，需新增一个面向回答引擎的当前任务状态汇总工具。它只聚合现有已授权任务来源，例如入职/学习任务、已下发训练、主管正式指派的待办；首版不另建平行任务表。

任务状态	回答与界面规则
查到一项或多项真实待办	说明任务名称、来源、状态、截止信息（如有）和真实跳转入口；行动卡必须指向真实功能
当前未查到待办	明确回复“当前没有查到分配给你的待办/训练任务”；可提供“查看学习中心”“咨询主管”等可选建议，不能称为必须完成
任务源暂不可用	明确说明当前无法确认，提示稍后再试或联系负责人；不回退成臆造任务
员工提到其他岗位	以服务端当前岗位为准；其他岗位资料只能标记为“跨岗位参考”，不生成该岗位的任务结论

示例：当前身份为保洁、没有入职待办的员工询问“生活顾问今天要做什么”。正确答法是说明“你的当前岗位为保洁，暂未查到待办；以下是生活顾问岗位的参考流程”，而不是直接要求其开始“生活顾问 5/30 天训练计划”。

5.4 页面交互纠偏

• 对话是“问”页面主体。首轮可展示快捷问题、项目/成果入口和能力说明；一旦开始对话，这些辅助区域收起为轻量入口。
• 消息追问时，顶部固定显示可关闭的来源条；回答卡的来源链接可回到消息详情或制度原文。
• 只有查到真实待办时才展示强行动按钮，如“去训练”“查看任务”。
• 无待办、无权限或数据暂不可用时，使用明确状态卡，不显示伪造的进度、截止日期或完成入口。
• 保留既有文字、语音、单次图片/视频分析能力，但不把附件当作长期记忆，也不把媒体分析结果自动写入大喇叭或任务系统。

6. 建议的领域模型与接口契约

以下为实施契约建议，具体字段以现有 TechSpec、数据库迁移评审和权限模型为准。新增业务放入 ruoyi-aihr，不改写上游框架的普通公告能力。

6.1 数据对象

建议对象	核心内容	说明
aihr_broadcast_message	租户、标题、正文、状态、必读、有效期、当前版本、发布/撤回信息	大喇叭的主消息，不复用 sys_notice 充当定向消息
aihr_broadcast_version	消息版本、内容快照、变更说明、发布版本标记	保证阅读、摘要和问答可追溯到具体版本
aihr_broadcast_attachment	消息版本、受保护资源引用、解析/摘要状态	不保存公开下载 URL；资源访问继续重新鉴权
aihr_broadcast_target	目标规则快照、命中员工、匹配依据、提醒状态	目标用于提醒/置顶与审计，不改变公开频道可见性
aihr_broadcast_read	员工、消息版本、首次/最后阅读时间	使用唯一约束保证重复打开幂等
aihr_broadcast_relevance	消息版本、员工、相关性文本、依据、置信标记	低置信只显示“可能与你相关”，不作为权限依据

禁止把大喇叭发布直接写成工作助手的 COMPANY/PENDING，也禁止把阅读事件自动写入“今日工作成果”。它们是不同业务事件。

6.2 API 轮廓

调用方	建议接口	关键约束
员工端	GET /api/aihr/broadcast/unread-count	仅返回当前登录员工真实未读数
员工端	GET /api/aihr/broadcast/messages	支持全部、与我有关、必读/未读；服务端按当前身份排序
员工端	GET /api/aihr/broadcast/messages/{id}	重新校验租户、发布状态、有效期和资源权限
员工端	POST /api/aihr/broadcast/messages/{id}/read	对消息版本幂等记录阅读
问模块	现有 POST /api/knowledge/query 增加可选 messageId	只能由后端加载消息上下文；不能接受客户端正文作为可信上下文
管理端	/api/aihr/broadcast/messages/**	草稿、发布、修订、撤回、目标规则、审计和人工再提醒；按发布权限控制

接口路径是本方案的建议命名，落地前需与既有 API_INTEGRATION.md、移动端鉴权和多租户拦截规则统一。所有写操作应包含幂等或版本校验，避免重复点击产生多次阅读、重复提醒或覆盖新版本。

6.3 问答所需的任务数据工具

现有知识检索接口继续处理 SOP、制度、文件和媒体问答；另增加服务端内部的“当前任务状态”查询能力，供问答编排调用。该能力的输出至少包含：

• 事实来源类型和记录 ID；例如学习任务、训练任务或主管指派。
• 任务名称、状态、截止时间（如真实存在）、所属项目和合法跳转入口。
• 数据新鲜度及不可用原因。
• 当前组织身份和岗位，以便处理跨岗位问题。

它不接受前端传入的岗位、项目编码或“请给我安排任务”等字段来生成事实。模型只有在该工具返回真实任务后，才可输出强制性待办和跳转动作。

7. 权限、安全与数据边界

风险点	控制要求
越权查看消息	每次列表、详情、问答上下文和附件访问都按当前租户与身份校验；消息 ID 不是授权凭证
旧版本误答	回答、摘要、阅读记录绑定消息版本；撤回/更新后不得继续用失效正文解释
客户端伪造上下文	前端只提交消息 ID；正文、附件文本、目标规则与岗位信息均由服务端加载
提示词注入	消息/附件只作为资料，不可修改系统权限、工具调用或角色判定
错把建议当任务	真实任务工具是唯一强行动事实源；缺失时给“无待办”或“暂无法确认”
外部流转被伪造	不因阅读或提问自动派工、发消息、创建工作成果；外部接口仍须显式确认和状态回执
过度收集	“与我有关”只使用该员工已授权组织属性，不使用敏感个人画像作为定向依据

8. 分批实施与依赖关系

大喇叭属于总体计划的 R2 高频协作能力；“问”的事实纠偏是现有能力质量修复，应先于或与 R2 同步完成，不能等到消息页面上线后再处理。

批次	交付内容	前置条件	完成证据
A：问模块事实纠偏	任务状态工具、意图分流、跨岗位标注、无待办状态卡、会话页面收纳	明确可聚合的现有任务来源和当前身份字段	真实账号下有任务/无任务/跨岗位三类 API 与页面验证
B：大喇叭核心	消息领域模型、发布/修订/撤回、首页入口、列表、详情、已读未读	发布角色、可公开内容范围、组织匹配字段确认	发布—阅读—版本—审计闭环；390×844 页面截图与交互记录
C：消息追问融合	messageId 受控上下文、来源条、消息引用、附件再鉴权	B 已有可审计的消息版本和资源引用	员工从详情追问、连续追问、撤回/换版本/越权三类回归
D：运营增强	AI 摘要、相关性说明、人工补推、失败队列与报表	核心阅读与组织匹配运行稳定	摘要可回原件、低置信提示、补推审计与失败可见
E：另案能力	员工直达/匿名建议、企业微信或短信、北森/审批/工单	业务负责人、权限、回执与 SLA 明确	独立 BRD、TechSpec、接口和正式环境验收

8.1 建议实施顺序

1. 先完成 A：解决“问”会误导员工的质量问题，并为消息追问准备可信任务结论。
2. 再完成 B：让消息具有稳定的发布、版本、阅读和权限事实。
3. 完成 C：将“就这条消息问”接入成熟的短会话机制。
4. 最后才做 D 的 AI 摘要和智能相关性。即使 AI 服务不可用，B/C 的原文阅读和人工提问仍应可用。

8.2 代码与页面影响面（实施前复核）

层级	预计责任区域	约束
员工端	mobile-uni/src/pages/user/today/、新增大喇叭页面、既有“问”页面	保持底栏“今日/练/问/我”；不回到旧 mobile/ 承载新功能
管理端	现有管理端业务路由及大喇叭发布/审计页面	不把页面能力误称为正式全员覆盖
后端	backend/ruoyi-modules/ruoyi-aihr 的消息、阅读、问答编排和任务状态聚合	不把业务代码塞进上游 ruoyi-demo；多租户和当前身份由服务端裁决
数据与迁移	新增 aihr_broadcast_* 表及必要索引	不自动把历史 sys_notice 当作已审计大喇叭消息；如需迁移，应经内容和权限人工确认
测试与证据	后端权限/幂等测试、移动端交互测试、真实账号回归	区分本地验证、视觉验证、部署和正式试点/生产验证

9. 验收清单

9.1 必须通过的功能与权限场景

场景	期望结果
发布全员消息	任一员工可从“全部”看到；发布记录、版本和附件可追溯
发布项目/岗位提醒	命中员工看到置顶/未读；未命中员工仍可从全员频道查阅公开消息
组织信息缺失	不丢消息；可见于全员频道，运营端出现匹配异常或低置信记录
读取消息	首次打开记录阅读；重复打开不产生重复记录；新版本按规则重新成为未读
受保护附件	当前有权员工可打开；换用户、换租户或失效后不能凭旧链接下载
从消息追问	回答引用当前消息或附件；消息没有写明的内容明确说明未知
越权消息 ID	不能通过构造 messageId 读取或提问其他租户/不可用消息
有真实任务	“我现在做什么”只展示当前员工确实存在的任务和真实入口
无真实任务	明确“未查到待办”，不生成伪任务、伪截止日或“去完成”按钮
跨岗位提问	服务端真实岗位优先；其他岗位只能作为参考说明
外部能力未接通	不显示“已请假”“已派单”“已送达”等成功结论

9.2 视觉与交互验收

• 在 390×844 员工端视口检查：首页喇叭、红点、列表筛选、详情、来源条、消息追问、无待办卡、错误态和返回路径。
• 验证会话开始后，快捷问题和支撑卡不会压缩主对话区或遮挡输入框。
• 验证消息摘要、相关性说明、附件、版本和“就这条消息问”层级清楚，原文入口始终可见。
• 实际点击验证，而非仅凭截图：未读变化、阅读写入、来源跳转、关闭上下文、新对话和登录拦截均须可操作。

9.3 发布与回滚

• 首次发布前以 feature flag 控制员工端入口与管理端发布权限；先用试点租户和真实组织数据验证。
• 数据库迁移应前向兼容；上线后如需回滚，优先关闭入口和发布能力，不删除已产生的发布、阅读与审计记录。
• 所有结论分别记录“已实现 / 本地验证 / 视觉验证 / 已部署 / 生产验证”，不得把其中任一层级外推为正式试点验收。

10. 需要确认的产品决策

以下事项会影响实现，但不影响本方案的核心方向，应在开发前由业务负责人确认：

1. 首版哪些管理角色可以发布、撤回和人工补推；是否需要发布前审核。
2. 哪些内容允许进入“面向全员可查”的大喇叭；涉及敏感信息时采用何种专门系统。
3. “必读”的业务定义：只做未读提醒，还是需要主管跟进；首版不自动产生考核或处罚。
4. AI 摘要与“与我有关”的人工校正机制、内容有效期和历史留存周期。
5. 后续是否接企业微信/短信等强触达渠道；如接入，接收对象、频率、失败回执和退订规则需另立接口与合规设计。

11. 结论

“银城大喇叭”应成为银城帮道的可信公司信息入口，而不是一个带红点的公告壳；“问”应成为员工理解消息、理解制度、核验自己真实待办的助手，而不是把知识库推荐包装成指令。

因此，首版最关键的产品承诺是：消息有原文、追问有上下文、行动有事实、无事实就明确说无事实。