365 lines
29 KiB
Markdown
365 lines
29 KiB
Markdown
# “银城大喇叭 + 问模块纠偏”增量方案
|
||
|
||
> 版本：v1.2
|
||
> 日期：2026-07-24
|
||
> 状态：问模块纠偏、大喇叭发布/阅读/追问、定向/必读结构、单文件提炼，以及独立五通道直通车均已部署；当前完整包已通过线上静态资源、后端模块和 `64/64` schema 一致性核验，并完成全员文件消息与直通车的生产认证态回归。定向人群正反例、正式处理人绑定、消息修订/补推和强触达仍待补齐。
|
||
> 适用范围：银城帮道员工端、管理端与 `ruoyi-aihr` 业务模块
|
||
> 关联方案：[产品功能优先级与实施计划](银城帮道产品功能优先级与实施计划-20260721.md)、[员工端 APP 分阶段实施总纲](银城员工端APP分阶段实施总纲.md)、[问师傅多轮会话与原始资料交付设计](20260718/问师傅多轮会话与原始资料交付设计.md)
|
||
|
||
## 0. 决策摘要
|
||
|
||
本方案不是新增一个普通公告页，而是把“公司告诉员工什么”和“员工听完后还能问清楚什么”连成一个可信闭环。
|
||
|
||
1. **银城大喇叭**是员工端的公司信息频道，入口复用首页右上角的喇叭图标；不新增第五个底部 Tab。
|
||
2. 已发布的首版消息面向本租户全员可查；按项目、岗位、层级的匹配用于**置顶、提醒和排序**，不应导致员工完全看不到公司公开信息。
|
||
3. 员工可在消息详情中点击“就这条消息问数字师傅”，带着受服务端校验的消息上下文进入现有“问”模块。
|
||
4. “问”回答“我现在该做什么”时，必须先查该员工当前真实任务；没有任务就明确说明“当前没有查到待办”，只能给非强制建议，不能把通用培训内容伪装为已下发工作。
|
||
5. 员工直通车已作为独立领域实现，不复用大喇叭消息表；企业微信/短信强触达、考勤请假审批、工单派发或自动创建任务仍不纳入大喇叭。
|
||
|
||
这项增量同时服务两个目的：一是让制度、通知、文件不再散落在群聊中；二是让员工在接收信息后能基于原文继续追问，并获得有来源、不过度承诺的回答。
|
||
|
||
### 0.1 2026-07-24 实际交付边界
|
||
|
||
| 范围 | 当前状态 | 证据边界 |
|
||
|---|---|---|
|
||
| A：问模块纠偏 | 已实现、部署并回归 | 会话开始后收起占位辅助区；消息与知识回答不得伪造员工待办，强行动入口只接受服务端真实任务事实。 |
|
||
| B：大喇叭消息闭环 | 已实现、部署并回归 | 支持全员公开、项目/岗位/层级目标快照、必读、已读、撤回，以及单文件上传、异步提炼、摘要展示和受控下载。生产已验证全员文件消息，测试消息随后撤回。 |
|
||
| C：消息上下文追问 | 已实现、部署并回归 | 详情页只传 `broadcastMessageId`；服务端重验身份、租户、在职状态和消息状态，并从服务端加载附件内容。生产已验证基于文件内容回答；撤回后不可继续访问。 |
|
||
| D：员工直通车 | 已实现、部署并回归 | 员工选择高管、财务、人力、审计或运营后业务匿名提交；内部保留身份审计，五类角色分权处理，每条仅一次正式回复。生产已验证匿名提交、审计处理、员工查看回复。 |
|
||
| 发布基础验证 | 已完成 | 当前构建与线上 H5/管理端资源、后端模块一致，服务 `active`，schema 只读预检为 `64/64`。 |
|
||
| 后续范围 | 部分待补 | 定向人群正反例、正式处理人绑定、消息修订/补推、强触达和外部流程仍待完成。 |
|
||
|
||
本节是当前实现状态的唯一摘要；第 1—11 节保留目标设计和验收标准，不能因其中的完整设计而推断所有能力均已上线。
|
||
|
||
## 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 明确不纳入首版
|
||
|
||
- 直通反馈的附件、多轮聊天、工单转派和 SLA。
|
||
- 企业微信、短信、电话等强触达渠道；H5 的页面内提醒不能被表述为系统级推送。
|
||
- 正式请假、考勤、排班、工单、线索、客户画像和北森审批。
|
||
- 依据一条消息自动创建训练任务、工作任务、成果记录或 `COMPANY/PENDING` 外部流转。
|
||
- 将问师傅改造成长期个人记忆。现有会话仍保持 30 分钟不活跃过期、最近六轮上下文和显式“新对话”。
|
||
|
||
## 3. 目标体验与信息架构
|
||
|
||
### 3.1 一条消息的员工闭环
|
||
|
||
```mermaid
|
||
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：另案能力 | 独立五通道直通车；企业微信或短信、北森/审批/工单仍另案 | 直通车依赖五类处理角色；外部流程另需接口和回执契约 | 直通车已完成生产认证闭环；外部流程仍待独立验收 |
|
||
|
||
### 8.1 当前实施状态
|
||
|
||
1. A、B、C 已实现并完成生产回归；当前 B 不含发布后版本修订。
|
||
2. D 已实现单文件摘要与受控下载，人工补推、失败报表和强触达仍待后续。
|
||
3. E 中直通车已独立实现；企业微信/短信、北森、审批和工单仍保持另案。
|
||
|
||
### 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. 结论
|
||
|
||
“银城大喇叭”应成为银城帮道的**可信公司信息入口**，而不是一个带红点的公告壳；“问”应成为员工**理解消息、理解制度、核验自己真实待办**的助手，而不是把知识库推荐包装成指令。
|
||
|
||
因此，首版最关键的产品承诺是：**消息有原文、追问有上下文、行动有事实、无事实就明确说无事实。**
|