docs(work-report): define voice-first reporting flow

docs/20260708/数字师傅学练问报整合方案.md

@@ -1,12 +1,13 @@
 # 银城数字师傅产品方案(整合修订)
 
-> 版本:v1.4 ｜ 日期:2026-07-19
+> 版本:v1.5 ｜ 日期:2026-07-19
 > 输入源:①客户方《物业数字师傅系统三期建设方案》(2026-07-08 早,下称"第三版")②《企业内部AI培训学习APP产品需求与发布会内容讨论》会议纪要(2026-07-08)③客户方会后微信补充(学模块课程化+考试;巡检点位转入职学习任务)④2026-07-11 客户微信语音补充(员工个人 AI 助理/个人知识空间)。
 > v1.1 重构:按"产品是什么 → 发布会做什么 → 决策记录 → 执行"四部分分层,产品定义与发布会演示不再混写。
 > v1.2 更新(2026-07-08,客户回复三项待确认):①多端跳转议题**暂缓**,现阶段只保证能打开小程序页面;②工作积分排行榜**保留功能、可选择不用**(开关配置);③员工评价管理团队**按组织架构与权限控制**,需有权限才能评价。详见 §3.3。
 > v1.3 更新(2026-07-11):阶段二新增员工个人 AI 助理,首批做个人资料/链接收藏、时间检索、带引用问答和工作整理;PPT 生成后置为 P1;北森等外部个人数据归阶段三。
 > v1.4 更新(2026-07-19):个人助理增加确认式长期记忆,并把一级入口收敛为“工作助手 / 查全网”;内部个人资料、项目记录和企业知识默认自动路由,来源在答案中透明展示。
-> 与《银城员工端APP分阶段实施总纲》《AI陪练二期开发推进计划》的关系:本方案是增量修订,不推翻既有阶段划分;§4.2 回写清单已于 2026-07-08 执行——总纲升 v0.3、二期计划升 v0.8。BRD v1.2 已于 2026-07-11 增补个人 AI 助理,BRD 4.4 师徒演练等旧口径仍待后续版本继续修订。
+> v1.5 更新(2026-07-19):“工作上报”由传统表单主路径改为微信式语音/照片/视频会话,AI 整理并按需追问,用户确认后才提交既有审核链。
+> 与《银城员工端APP分阶段实施总纲》《AI陪练二期开发推进计划》的关系:本方案是增量修订,不推翻既有阶段划分;§4.2 回写清单已于 2026-07-08 执行——总纲升 v0.3、二期计划升 v0.8。BRD 已升至 v1.4,同步个人助理与工作上报交互定案;BRD 4.4 师徒演练等旧口径仍待后续版本继续修订。
 
 ---
 
@@ -42,7 +43,7 @@
 | 日常四模块 | **学** | 该会的知识按计划学、按要求考 | 岗位学习计划、入职任务包、文档/视频课件(防快进、最短阅读时长)、不定期考试(有截止时间) | 本期新建(最小集) |
 | | **练** | 每天 5 分钟,跟 AI 业主实战演练 | 场景对练(AI 控制生成)、语音对手戏、回复语气调节按钮、每日任务派发 | 已有主链,本期增强 |
 | | **问** | 现场遇事,一问就有能照做的答案 | 直给式问答(结论+一二三四五步骤)、语音提问、答案打勾/打叉、视频链接直出 | 已有,本期改格式 |
-| | **报** | 我的经验被看见、被沉淀 | 案例上报(文字+拍照+语音)、审核入库、署名计分 | 已有雏形,本期规范 |
+| | **报** | 我的经验被看见、被沉淀 | 微信式语音/照片/视频上报、AI 整理确认、审核入库、署名计分 | 已有表单链路，交互升级已定案 |
 | 共创层 | 问题榜 | 遇到难题有人帮,答题有奖 | "今天遇到什么难题"+"有奖征问题"双入口、全员可答、最佳答案置顶、沉淀入库 | 阶段二(本期埋 knowledge_gap 日志) |
 | 成长层 | 学分与晋升 | 努力可积累,晋升有通道 | 学分规则(可配置)、初/中/高级成长进度、E1-E8 远期框架、学分达标→统考资格 | 本期最小集 |
 | 地基 | 知识库 | 一切模块的内容来源 | 全业态资料入库、多格式解析、混合检索、纠错闭环、分级访问 | 已有,2026-07-08 当周补资料 |
@@ -79,9 +80,26 @@
 
 ### 1.3.4 报——案例上报与经验沉淀
 
-- 上报"今天处理了什么事、怎么处理的",支持文字+拍照+语音;目标**每个生活顾问每月至少 1 个有价值案例**;
+> 高保真实现基准：[工作上报微信式语音会话 v1](../prototypes/work-report-voice-conversation-v1.png)。该图是目标交互，不是当前生产截图。
-- 后台审核,采纳入库计学分并署名;与问题榜优质回答共同构成"行业经验知识库"原料;
+
-- "报"字面易与报事报修歧义,对外文案待定名,功能先行。
+![工作上报微信式语音会话高保真设计](../prototypes/work-report-voice-conversation-v1.png)
+
+- **2026-07-19 交互定案**：员工端不再以“先选类型 → 填标题 → 填说明 → 传附件”的传统表单作为主路径，而是复用「问」的微信式会话语言。首页“工作上报”仍作为清晰任务入口，进入后直接提示“今天处理了什么？按住说，也可以发照片或视频”。
+- 主流程固定为：`语音/文字/照片/视频 → ASR 与 AI 理解 → 必要时追问 1–2 个缺失信息 → 生成结构化确认卡 → 用户确认上报 → 主管/运营审核 → 会话内展示状态`。
+- 前端默认复用现有 `ChatComposer`：语音优先，键盘次之；图片、视频和音频继续走附件入口。不得为了“报”再建设第二套录音、附件或聊天组件。
+- “优秀案例 / 操作视频 / 完整 SOP / 有用知识”仍是后台结构化类型，但由 AI 优先判断并在确认卡中展示，员工可以修改，不要求普通员工在表达前理解分类。
+- 确认卡至少展示类型、标题、事情经过、处理方法、结果和附件；卡片动作收敛为“修改 / 确认上报”，继续补充直接使用底部语音/文字输入，避免重复入口。只有明确点击“确认上报”才能创建正式记录，AI 不得自动提交。
+- “我的上报”作为历史入口，审核中、已通过、已驳回及审核意见以会话消息或状态卡呈现。审核通过只代表上报通过；最终进入案例库或知识库仍由运营在对应模块人工完成，不自动入库。
+- 上报目标仍为**每个生活顾问每月至少 1 个有价值案例**；后台采纳后计学分并署名，与问题榜优质回答共同构成“行业经验知识库”原料。
+- “工作上报”与“记一件事”必须区分：前者会提交给企业审核并可能共享入库，后者只进入已授权的个人或项目记忆域；两者都必须在最终动作前向用户说明保存范围。
+- “报”字面易与报事报修歧义，对外入口统一使用“工作上报”，不使用单独的“报”字作为页面标题。
+
+高保真评审后的实施修订：
+
+1. **短追问直接可读**：师傅的一句式追问默认显示文字，并提供播放图标；只有长回答才使用“语音条 + 转文字/收起”。不得在文字已经可见时仍显示“转文字”。
+2. **脱敏能力不做虚假承诺**：后端未真正生成并提交脱敏内容前，只提示“检测到具体房号，请修改后再提交”，不得写“提交后将自动隐藏”。确认卡必须展示即将提交的真实内容。
+3. **分类是建议，不是审核结论**：标签统一显示“建议类型：优秀案例”等文案，并允许员工修改；主管审核前不得用“已认定优秀案例”的视觉语义。
+4. **补充入口唯一**：确认卡不再放“继续补充”按钮，底部“按住说话/键盘输入”就是唯一补充入口；可增加“还可以继续说话补充”的弱提示。
 
 ### 1.3.5 问题榜——师带徒的替代方案
 

docs/README.md

@@ -24,12 +24,13 @@
 | [个人AI助理阶段二专项TechSpec.md](个人AI助理阶段二专项TechSpec.md) | 员工个人知识空间的物理分域、数据模型、API、检索融合、权限、安全、删除和测试规格 |
 | [个人AI助理阶段二开发推进计划.md](个人AI助理阶段二开发推进计划.md) | 个人 AI 助理阶段二按 P0/P1 拆分的逐任务实施、测试、提交和试点闸门 |
 | [prototypes/personal-assistant-work-helper-voice-first-v2.png](prototypes/personal-assistant-work-helper-voice-first-v2.png) | 个人助理并入「问 · 数字师傅」后的语音优先会话、自动内部路由与确认记忆卡实现基准 |
+| [prototypes/work-report-voice-conversation-v1.png](prototypes/work-report-voice-conversation-v1.png) | 工作上报从传统表单升级为微信式语音/照片/视频采集、AI 整理追问和确认审核的高保真实现基准 |
 | [AI陪练二期开发推进计划.md](AI陪练二期开发推进计划.md) | 总纲阶段一执行文档:AI 陪练从 MVP 演示闭环推进到管家(生活顾问)岗位试点可用；区分工程就绪与正式业务试点证据 |
 | [员工端版本功能对比与功能对齐清单-20260717.md](员工端版本功能对比与功能对齐清单-20260717.md) | 旧版/历史需求/当前实现/生产验收的版本对比，以及 2026-07-17 客户反馈逐项处理结果 |
 | [BRD_IMPLEMENTATION_AUDIT.md](BRD_IMPLEMENTATION_AUDIT.md) | 当前生产基线、三端输入/BRD 匹配、客户反馈完成分层和正式试点剩余硬门槛；旧发布流水从当前真相源移除 |
 | [BRD_PRODUCTION_MIGRATION_RUNBOOK.md](BRD_PRODUCTION_MIGRATION_RUNBOOK.md) | AIHR BRD 生产 schema/内置内容迁移顺序、只读核验和发布后回归口径 |
 | [20260708/uni-app用户侧前端重建计划.md](20260708/uni-app用户侧前端重建计划.md) | `mobile-uni/` 重建阶段留档；当前完成状态以 BRD 审查和版本功能对比为准 |
-| [20260708/数字师傅学练问报整合方案.md](20260708/数字师傅学练问报整合方案.md) | 产品定义(学练问报+问题榜+学分晋升+个人 AI 助理)、半年会发布会方案分层及客户需求逐项处置对照 |
+| [20260708/数字师傅学练问报整合方案.md](20260708/数字师傅学练问报整合方案.md) | 产品定义(学练问报+问题榜+学分晋升+个人 AI 助理)、工作上报微信式语音交互定案、半年会发布会方案分层及客户需求逐项处置对照 |
 | [20260708/发布会演示候选题单.md](20260708/发布会演示候选题单.md) | 2026-07-08 发布会演示候选题单，作为产品讨论留档，不作为阶段一开发入口 |
 | [基于AI的银城员工端APP项目立项与开发规划会议-2026年07月07日-来自【Get 笔记】.md](基于AI的银城员工端APP项目立项与开发规划会议-2026年07月07日-来自【Get%20笔记】.md) | 2026-07-07 立项会纪要原文(总纲的输入源,只作留档) |
 | [20260708/企业内部AI培训学习APP产品需求与发布会内容讨论(纪要)](20260708/) | 2026-07-08 产品讨论纪要原文及客户"第三版"docx(整合方案的输入源,只作留档) |

docs/物业AI人力资源系统业务需求文档BRD.md

@@ -1,10 +1,11 @@
 # 物业行业 AI 人力资源系统 · 业务需求文档(BRD)
 
-> 版本:v1.3(统一版)｜ 日期:2026-07-19
+> 版本:v1.4(统一版)｜ 日期:2026-07-19
 > 定位:本文是本项目的**唯一事实源(Single Source of Truth)**,收敛此前所有讨论与文档,取代分散的局部材料作为业务需求基准。
 > v1.1 变更:第 5 章数据模型方向补充"HR 主干已对齐《手册》卷1 第9章"结论(见 5.2)。
 > v1.2 变更:新增阶段二“员工个人 AI 助理 / 个人知识空间”需求(见 4.8),明确个人资料、网页链接、时间检索、来源引用、PPT 增强项和阶段三外部 HR 数据边界。
 > v1.3 变更:个人助理新增确认式长期记忆;一级交互收敛为“工作助手 / 查全网”,内部个人资料、项目业务记录和企业知识默认自动路由并透明展示来源。
+> v1.4 变更:员工“工作上报”改为复用数字师傅的微信式语音会话,AI 只整理可编辑草稿,用户确认后进入原有审核链,审核通过仍不自动入知识库。
 >
 > **收敛来源**:
 > - 《物业管家与生活顾问 AI 陪练系统建设方案》(原始业务方案,陪练视角)
@@ -134,9 +135,17 @@
 
 ### 4.6 案例沉淀 pipeline(贯穿)
 
+员工端目标交互参考：[工作上报微信式语音会话高保真设计](prototypes/work-report-voice-conversation-v1.png)。该图用于说明采集与确认路径，不代表当前生产实现或正式审核完成状态。
+
 - 流程:项目负责人**语音上传**案例 → AI 转写 → 从大量案例(目标千级)**AI 筛选出有特色的少数** → 制作成 **AI 对话讲解视频** → 供全员学习(如早八点课堂)。
 - 节奏:每周每项目提交一个案例。
 - **一期**:流程跑通,视频用**预渲染样片**顶(数字人/视频生成慢且贵,不真跑)。
+- **员工端交互定案（2026-07-19）**：工作上报采用与「问 · 数字师傅」一致的微信式会话，默认语音输入并支持照片、视频和文字补充；系统从自然表达中整理类型、标题、经过、方法和结果，不要求员工先填写传统表单。
+- **确认边界**：AI 只能生成可编辑上报草稿和必要追问，必须由员工点击“确认上报”后才写入正式上报记录；不得把 ASR 转写、附件选择或模型推断直接视为提交。
+- **审核边界**：正式记录继续使用 `PENDING / APPROVED / REJECTED` 审核状态；通过后仍由运营在案例库或知识库执行最终人工入库，不因 AI 判断自动公开或自动计分。
+- **隐私边界**：确认卡应提示住户姓名、手机号、房号等敏感信息的脱敏风险；图片、视频和原始音频只能通过受保护附件接口访问，不在会话正文生成公开 URL。
+- **交互一致性**：短追问文字直接可见并提供播放能力，长回答才使用“转文字”展开；确认卡中的分类必须标识为 AI 建议且可修改，补充内容统一从底部语音/文字入口进入。
+- **脱敏真实性**：确认卡展示的内容必须与实际提交内容一致。未实现服务端脱敏时只能提示用户修改，不得承诺“提交后自动隐藏”；实现自动脱敏后也必须先展示脱敏后的提交预览再允许确认。
 
 ### 4.7 智慧知识中心
 

docs/物业AI人力资源系统开发规格TechSpec.md

@@ -1,11 +1,12 @@
 # 物业行业 AI 人力资源系统 · 开发规格(Tech Spec)
 
-> 版本:v1.4 ｜ 日期:2026-07-03
+> 版本:v1.5 ｜ 日期:2026-07-19
 > 定位:**开发层唯一依据**。回答"怎么建"——工程结构、数据表、API 契约、Prompt 规格、集成适配。
 > v1.1 变更:数据模型对齐《手册》卷1 第9章 HR 主干,补 3 张 backbone 表(职位职责/雇员绩效/雇用终止),新增附录 D 对照表。
 > v1.2 变更:第 6 章按 Codex 设计评审重写——状态机补异常/终止态、COACH_CHECK 工程化、评分引擎分层(P0 单 LLM / P1 融合)、澄清"单场对练评分 vs 跨期能力画像"两套评分、Prompt 加固 + RAG 硬约束、新增 6.5 P0/P1 切分。
 > v1.3 变更:Qdrant 作为一期向量索引层落地;SOP 知识库检索升级为 MySQL Fulltext + Qdrant RRF 融合,MySQL/MinIO 仍是事实源。
 > v1.4 变更:移动端拆为独立 `mobile/` Vue/Vite Web/H5 工程,承载员工端、候选人端、主管端;后台管理端继续在 `frontend/`。
+> v1.5 变更:当前用户侧以 `mobile-uni/` 为准;员工工作上报复用 `ChatComposer` 改为语音优先会话,增加无状态 AI 整理草稿契约,确认后继续提交既有 `aihr_work_report` 审核链。
 > 配套:需求见[《物业AI人力资源系统业务需求文档BRD》](物业AI人力资源系统业务需求文档BRD.md);2026-07 MVP 执行计划已归档到[《AI人力资源系统一期MVP版作战清单》](archive/2026-07-mvp-delivery/AI人力资源系统一期MVP版作战清单.md)。
 > **优先级图例**:`P0`=2026-07-05 MVP 演示必需 · `P1`=一期必需 · `P2`=二期/推迟。
 > 决策基线:若依基座 / 集中式前后端分离 / 本地登录 / 公有大模型API / 一期RAG / 组织人员外部同步(MVP 用快照) / 数据范围以项目为主体。
@@ -176,6 +177,7 @@ mobile/
 | `/h5/#/pages/user/today/index` | 员工端首页，手机号登录后可“开始训练”并同步主管待复盘计数；旧 `/h5/user` 兼容重定向 | P0跑通 |
 | `/h5/#/pages/candidate/index/index` | 候选人端首页，手机号登录后可面试练习、查岗位 SOP/案例、上传补充资料；旧 `/h5/candidate` 兼容重定向 | P0跑通 |
 | `/h5/#/pages/supervisor/index/index` | 主管端首页，查看团队、待复盘、案例/SOP 工具；旧 `/h5/supervisor` 兼容重定向 | P0跑通 |
+| `/h5/#/pages/user/report/index` | 员工工作上报；目标交互复用「问」的微信式语音会话，AI 整理确认后提交既有审核链 | 已有表单链路，待交互升级 |
 | `/train/daily` | 每日一练 | P1 |
 | `/train/camp` | 专项训练营 | P1 |
 | `/train/mistakes` | 错题本 | P1 |
@@ -254,6 +256,65 @@ POST /api/knowledge/case/organize    req: { caseId }                        resp
 POST /api/knowledge/case/curate      req: { criteria, limit }               resp: { selectedCaseIds[] }   // 从多案例筛选
 ```
 
+#### 5.3.1 员工工作上报会话化交互
+
+实现基准：[work-report-voice-conversation-v1.png](prototypes/work-report-voice-conversation-v1.png)。后续 Agent 应复用图中的语音主入口、必要追问、结构化确认卡和显式“确认上报”，但安全、权限、长度校验和审核状态以本 TechSpec 与后端契约为准。
+
+员工端 `mobile-uni/src/pages/user/report/index.vue` 的目标形态复用现有 `ChatComposer` 和「问」页消息语言，不再让四类选择、标题和说明字段占据首屏。后台仍使用 `aihr_work_report` 及现有审核链，避免为视觉改版复制数据模型。
+
+```text
+进入工作上报
+  → 默认语音模式，可切换键盘或添加图片/视频
+  → ASR 转写进入当前页面草稿
+  → AI 从自然表达推断 CASE / VIDEO / SOP / KNOWLEDGE
+  → 信息不足时只追问必要字段
+  → 返回可编辑确认卡
+  → 用户点击“确认上报”
+  → POST /api/aihr/work-report/reports
+  → 返回 PENDING，并在会话与“我的上报”中展示审核状态
+```
+
+最小接口策略：附件继续复用 `POST /api/aihr/work-report/attachment`，正式提交继续复用 `POST /api/aihr/work-report/reports`，历史继续复用 `GET /api/aihr/work-report/reports/mine`。只增加一个无状态整理接口，不新增草稿表或第二套会话表：
+
+```text
+POST /api/aihr/work-report/organize
+  req:  { transcript, currentDraft?, attachmentOssId?, attachmentName? }
+  resp: { suggestedType, title, content, missingQuestions[], privacyWarnings[], confidence }
+```
+
+- `organize` 只返回结构化草稿，不得写 `aihr_work_report`；页面刷新前草稿保存在前端当前会话状态，只有确认后的正式记录持久化。
+- 类型由 AI 建议但必须允许员工修改；`VIDEO` 仍由后端校验视频附件，标题和说明长度继续执行现有边界。
+- 语音、文字和附件输入复用 `mobile-uni/src/components/chat/ChatComposer.vue`、`services/speech.ts` 与现有上传接口，不新增录音框架。
+- 住户敏感信息应在确认卡中提示脱敏；提交、附件读取、我的上报与审核接口继续从登录态解析租户和用户，不接受客户端伪造提交人。
+- 审核通过不自动写案例库或企业知识库；运营最终入库沿用现有人工流程。
+
+#### 5.3.2 高保真评审实施细则
+
+设计图用于确定结构和视觉方向，代码实现必须吸收以下评审修订，不得逐像素复制图中的矛盾文案：
+
+1. **语音与文字状态唯一**
+   - 用户语音经 ASR 后始终显示带“语音转文字”标记的文字气泡。
+   - 师傅短追问直接显示文字，并在气泡内提供播放按钮；此时不显示“转文字”。
+   - 师傅长回答默认显示语音条，正文折叠；按钮状态只能在“转文字 / 收起文字”之间切换。
+2. **分类可确认**
+   - `organize` 返回 `suggestedType`，确认卡展示“建议类型：{typeLabel}”和修改入口。
+   - `POST /reports` 使用员工最后确认的 `type`，不得直接使用模型建议值提交。
+3. **脱敏提示必须真实**
+   - `privacyWarnings` 只描述检测结果，不代表系统已经完成脱敏。
+   - P0 若没有服务端脱敏能力，提示“检测到具体房号，请修改后再提交”，用户修改后确认卡重新展示最终提交文本。
+   - 只有服务端确实生成脱敏内容、且确认卡展示的就是该提交内容时，才允许出现“已隐藏”或自动脱敏开关。
+4. **补充入口唯一**
+   - 确认卡只保留“修改 / 确认上报”；底部 `ChatComposer` 继续承担语音、文字和附件补充。
+   - 不同时展示“继续补充”按钮和可用的底部输入栏；需要引导时只显示弱提示“还可以继续说话补充”。
+
+视觉与交互验收：
+
+- 在 390×844 视口下，确认卡可滚动且底部输入栏不遮挡“修改 / 确认上报”。
+- 页面不存在“文字追问已展开但按钮仍写转文字”的状态。
+- 类型标签包含“建议类型”语义并可修改，确认提交请求使用修改后的类型。
+- 未实现服务端脱敏时，页面不得出现“提交后将自动隐藏具体房号”等承诺性文案。
+- 页面只有一个继续补充入口；确认提交后返回 `PENDING` 状态卡并可从“我的上报”查到同一记录。
+
 ### 5.4 AI 适配层(P0)
 
 ```