prop-ai-hr/docs/工作助手与今日工作成果迭代计划-20260721.md

# 工作助手与今日工作成果迭代计划

> 版本：v1.6
> 日期：2026-07-22
> 状态：迭代 0-4 已于 2026-07-21 提交并部署；目标测试、真实 HTTP、390×844 视觉交互及生产真实员工账号主链路已验证。历史日期选择、未来日期拒绝和主管手机号授权兜底已于 2026-07-22 提交并发布；远端服务、schema 与 H5/后端产物匹配已复核。
> 适用范围：员工端工作助手、今日工作成果、主管项目视图、成果投稿及后续外部流转
> v1.5：在 v1.4 基础上补记生产发布、真实账号回归和生产截图；确认卡改为优先展示 AI 识别结论，再由用户向下查看并执行保存动作。
> v1.6：员工与主管成果页支持历史日期选择；前后端均拒绝未来日期；主管手机号登录时以手机号兼容组织身份授权。以上是本轮本地增量，不倒填为 2026-07-21 已发布能力。

## 0. 文档权威关系与冲突裁决

本文只回答“下一步按什么顺序建设”，不取代当前接口、生产状态或既有审核链的事实文档：

| 文档 | 职责 | 使用规则 |
|---|---|---|
| [业务需求 BRD](物业AI人力资源系统业务需求文档BRD.md) | 决定做什么及业务边界 | 业务需求事实源 |
| [开发规格 TechSpec](物业AI人力资源系统开发规格TechSpec.md) | 说明现有工程结构与已定技术契约 | 开发层当前事实源 |
| [个人助理专项 TechSpec](个人AI助理阶段二专项TechSpec.md) | 说明确认式采集、权限、记忆和个人知识空间边界 | 工作助手专项契约 |
| [API 对接指南](API_INTEGRATION.md) | 只列当前已经存在的接口 | 不把本文规划中的接口写成可调用接口 |
| [BRD 功能审查](BRD_IMPLEMENTATION_AUDIT.md) | 区分实现、部署、生产基础验证和正式验收 | 当前状态事实源 |
| 本文 | 项目选择、统一采集、今日成果、主管视图和外部流转的实施顺序与阶段证据 | 按状态列记录计划与证据摘要；部署和生产状态仍以审查文档及真实环境交叉复核为准 |
| [数字师傅整合方案](20260708/数字师傅学练问报整合方案.md) | 保留产品演进背景和“学练问报”决策 | 与当前事实冲突时以上述事实文档为准 |

已裁决的矛盾：

1. **项目是否必填**：当前已部署的确认式采集允许项目为空；后续迭代中，个人笔记仍可不选项目，但晨会、巡检、业主服务、画像、线索等项目工作记录必须先从项目名称下拉列表选择当前项目。用户不输入项目编码。
2. **“工作上报”是什么**：`/pages/user/report/index` 已在员工界面改名为“成果投稿”，底层 `/api/aihr/work-report/**` 继续兼容既有优秀案例、操作视频、完整 SOP 和有用知识审核链；日常事实不进入该表。
3. **日常记录放在哪里**：日常事实统一进入工作助手和 `aihr_assistant_capture`；不得为了日报把既有 `aihr_work_report` 改造成万能工作记录表。
4. **附件是否已经被 AI 看懂**：工作助手的现场图片/视频已有本次分析能力；确认式采集已能把受保护 OSS 来源绑定到记录并重新鉴权回看。成果投稿链仍不能仅凭附件名称声称已经理解图片或视频内容。
5. **“个人助理已实现”是什么意思**：确认式采集已经提交并部署，但个人文件、网页收藏、独立个人向量库、分享和 PPT 生成仍未实现；两者不能合并宣称完成。
6. **今日成果与外部流转**：员工今日成果和主管项目成果已于 2026-07-21 部署；真实线索/工单投递仍未接通，`COMPANY/PENDING` 只表示待流转。
7. **部署与验收**：2026-07-21 已完成本轮数据库幂等迁移、后端 JAR 与 H5 发布，并用正式员工账号验证项目读取、越权拒绝、确认卡、撤销和按项目/日期幂等生成成果；生产账号当前只有一个授权项目，因此多项目切换仍以本地双项目证据为准，真机媒体和正式业务窗口仍未验收。

## 1. 目标与边界

本轮不是新建另一套聊天、上传或工作上报系统，而是在现有「问 · 数字师傅」和确认式记忆链路上补齐项目上下文、日常工作采集、按日汇总与主管查看能力。

一线员工只需完成三个动作：

1. 按项目名称选择当前项目。
2. 通过语音、文字、照片或视频说明现场情况。
3. 检查 AI 整理结果并确认。

员工不需要记忆或输入项目编码，也不需要在表达前判断“线索、画像、案例、知识、工单”等专业分类。项目编码只作为前后端内部传输字段，服务端必须再次校验项目权限。

### 1.1 功能名称收敛

| 功能 | 用户理解 | 主要用途 |
|---|---|---|
| 工作助手 | 今天发生什么，直接告诉数字师傅 | 日常工作采集、记忆、待跟进 |
| 今日工作成果 | 今天做了什么，还有什么没完成 | 自动汇总、个人查看、主管查看 |
| 成果投稿 | 这条经验值得让公司复用 | 优秀案例、SOP、视频、知识投稿 |

当前员工端已经将原「工作上报」更名为「成果投稿」，四类审核内容和既有审核链继续保留；日常工作事实统一进入工作助手，不再让用户误以为必须先填传统上报表单。

### 1.2 业务链路

```mermaid
flowchart LR
    A[选择当前项目名称] --> B[语音、文字、照片或视频]
    B --> C[AI 理解并生成确认卡]
    C --> D[本人工作记录]
    C --> E[待跟进事项]
    C --> F[公司处理 PENDING]
    C --> G[成果投稿建议]
    D --> H[今日工作成果]
    E --> H
    F --> H
    G --> H
    H --> I[主管项目视图]
```

### 1.3 UI 变化与高保真基准

迭代 1-3 在现有「问 · 数字师傅」页面内渐进完成，不新建第二套工作助手界面：

![工作助手项目上下文与今日成果高保真基准](prototypes/work-assistant-project-context-v3.png)

权威资产路径：`docs/prototypes/work-assistant-project-context-v3.png`。本地生成源为 `output/imagegen/work-assistant-project-context-v3.png`，该目录被 Git 忽略，后续 Agent 必须引用前者。

### 1.4 UI 设计交付清单

| 设计交付物 | 覆盖页面与状态 | 对应迭代 | 开发引用路径 | 当前性质 |
|---|---|---|---|---|
| 工作助手项目上下文与今日成果 v3 | 工作助手主会话、当前项目、项目化确认卡、今日成果摘要、待公司处理 | 迭代 1-3，兼顾迭代 5 状态语义 | `docs/prototypes/work-assistant-project-context-v3.png` | 目标高保真图，尚非生产截图 |

仓库内绝对路径：`/Users/yuanjiantsui/dev/11-project/wygj/docs/prototypes/work-assistant-project-context-v3.png`。

UI 与代码页面的对应关系：

| UI 变化 | 员工/主管路由 | 主要实现文件 | 说明 |
|---|---|---|---|
| 当前项目名称选择器与大尺寸底部面板 | `/pages/user/sop/index` | `mobile-uni/src/pages/user/sop/index.vue` | 用户只选择项目名称，不输入或记忆项目编码；切换项目同时切换会话上下文 |
| 项目化确认卡、来源与业务状态 | `/pages/user/sop/index` | `mobile-uni/src/components/chat/MemoryCandidateCard.vue` | 确认卡展示项目、工作日期、来源和状态，并区分个人记录与待公司处理 |
| 今日工作成果摘要与员工详情 | `/pages/user/sop/index`、`/pages/user/work-results/index` | `mobile-uni/src/pages/user/sop/index.vue`、`mobile-uni/src/pages/user/work-results/index.vue` | 会话内给出当日摘要入口，详情按员工 + 项目 + 日期聚合 |
| 主管项目成果 | `/pages/supervisor/work-results/index` | `mobile-uni/src/pages/supervisor/work-results/index.vue` | 按项目查看记录人数、成果人数、待跟进和高优问题，不展示无权限项目 |
| 历史日期选择与中性标题 | `/pages/user/work-results/index`、`/pages/supervisor/work-results/index` | `mobile-uni/src/components/WorkDateSelector.vue`、两个成果页 | 默认当天；允许查看历史日期；前后端均拒绝未来日期；历史视图不再误称“今日” |
| 原“工作上报”分流为“成果投稿” | `/pages/user/report/index` | `mobile-uni/src/pages/user/report/index.vue` | 仅承载优秀案例、操作视频、完整 SOP 和知识投稿，不承载日常事实记录 |

### 1.5 本地运行视觉证据（390×844）

下列文件是 2026-07-21 本地开发环境的实际页面截图，用于证明实现状态和记录视觉修正；它们不是高保真设计源，也不是生产截图：

| 实际页面或状态 | 仓库内截图路径 | 验证结论 |
|---|---|---|
| 多项目名称选择面板 | `docs/visual-evidence/20260721/work-assistant-project-picker-fixed-390x844.png` | 两个项目完整可见；面板使用 `--window-bottom` 避开底栏 |
| 已选择当前项目的工作助手 | `docs/visual-evidence/20260721/work-assistant-selected-project-390x844.png` | 顶部显示项目名称，切换提示明确，不显示项目编码 |
| 巡检确认卡阶段性定位证据 | `docs/visual-evidence/20260721/work-assistant-inspection-card-autoscroll-390x844.png` | 当次本地验证证明四个动作可操作；生产回归发现卡片开头会被顶出屏幕，已由 §1.6 的“识别结论优先”实现取代 |
| 员工今日工作成果 | `docs/visual-evidence/20260721/employee-daily-work-result-fixed-390x844.png` | 按项目和日期聚合；已记录事项不再错误显示处理动作 |
| 主管项目成果 | `docs/visual-evidence/20260721/supervisor-project-work-results-fixed-390x844.png` | 显示记录人数、成果人数、待跟进、高优问题和员工来源类型；非文字记录可打开受保护原始来源 |
| 员工当天成果日期选择 | `docs/visual-evidence/20260721/employee-work-results-date-selector-today-390x844.png` | 默认当天，日期入口与统计清晰可见 |
| 员工历史日期空状态 | `docs/visual-evidence/20260721/employee-work-results-history-date-390x844.png` | 历史日期使用“这一天”等中性文案，可回到今天 |
| 主管当天成果日期选择 | `docs/visual-evidence/20260721/supervisor-work-results-date-selector-today-390x844.png` | 项目汇总与日期入口不互相遮挡 |
| 主管历史日期空状态 | `docs/visual-evidence/20260721/supervisor-work-results-history-date-390x844.png` | 历史视图人数标签采用中性“记录人数” |

绝对目录：`/Users/yuanjiantsui/dev/11-project/wygj/docs/visual-evidence/20260721/`。这些文件是已纳入仓库的本地验收证据；正式设计目标仍只以 `docs/prototypes/` 下的权威高保真图为准。

后续开发和验收使用规则：

1. 产品、前端、后端和测试 Agent 都以 `docs/prototypes/work-assistant-project-context-v3.png` 为共同设计输入。
2. 图中项目名称、日期、来源、业务状态和今日成果入口必须与本计划的数据与权限规则同时实现，不能只还原视觉外壳。
3. `output/imagegen/work-assistant-project-context-v3.png` 仅保留生成过程来源，不纳入 Git，也不能写入开发任务或验收报告作为权威资产。
4. 新增项目选择面板、今日成果详情页或主管项目视图高保真图时，继续放入 `docs/prototypes/`，并回填本表和对应迭代章节。

### 1.6 生产运行视觉证据（390×844）

下列截图来自 `https://peilian.njzhmj.top/h5/`，使用已授权的正式员工账号和脱敏测试表达完成；测试产生的候选记录在验证后选择“暂不保存”，没有写入长期工作记录：

| 生产页面或状态 | 仓库内截图路径 | 验证结论 |
|---|---|---|
| 单项目员工的工作助手 | `docs/visual-evidence/20260721/production-work-assistant-project-selector-390x844.png` | 顶部只显示项目名称“银河湾星苑”，不显示内部项目编码；单项目自动选择 |
| 巡检确认卡识别结论优先 | `docs/visual-evidence/20260721/production-work-assistant-confirmation-card-390x844.png` | 卡片首先展示建议类型、项目、对象、事项、摘要、日期和来源；用户再向下查看确认动作 |
| 员工今日工作成果空状态 | `docs/visual-evidence/20260721/production-employee-daily-work-result-empty-390x844.png` | 项目、日期、记录数、待跟进和成果版本清晰；没有已确认记录时不伪造内容 |

生产证据绝对目录：`/Users/yuanjiantsui/dev/11-project/wygj/docs/visual-evidence/20260721/`。生产账号只有一个项目，故项目下拉的多选形态仍以 §1.5 的本地双项目截图和权威高保真图为准。

相对当前页面的变化：

1. 页面标题继续使用「问 · 数字师傅」，顶部增加按项目名称操作的「当前项目」选择器，不展示项目编码。
2. 保留「工作助手 / 查全网」双入口，在会话顶部增加「今日工作成果」摘要入口。
3. 语音、照片和文字仍以微信式消息进入同一会话，不要求员工先选业务分类。
4. 确认卡增加项目、日期、地点、事项、原始语音/现场照片来源和本地业务状态；确认后才计入今日工作成果。
5. 「确认记录」与「提交公司处理」分开；后者只显示「进入待流转」，不得显示已派单或已送达。
6. 底部继续以「按住说话」为主入口，键盘、快捷指令和「今日 / 练 / 问 / 我」导航保持原有交互习惯。
7. 含确认卡的 AI 回复不再一律滚到消息底部，而是定位到该条回复开头，让用户先核对识别结论；普通短消息仍保持滚到底部。

| 图中元素 | 对应迭代 | 当前状态 |
|---|---|---|
| 当前项目名称选择器、切换提示 | 迭代 1 | 已实现并部署；生产单项目自动选择通过，本地双项目名称选择通过 |
| 项目化确认卡、来源入口、业务状态 | 迭代 2 | 已实现并部署；文字链路完成生产真实账号 HTTP 与 390×844 页面验证，媒体来源仍需真机回归 |
| 今日工作成果摘要入口 | 迭代 3 | 已实现并部署；员工生产空状态、员工本地有数据状态和主管本地项目视图均已视觉验证 |
| 提交公司处理、进入待流转 | 当前确认式采集 + 迭代 5 | `PENDING` 已有；真实外部投递和回执未实现 |

该图只定义信息层级、交互语义和视觉方向，不是生产截图。项目选择面板、员工今日成果详情页和主管项目视图已按 390×844 运行页面完成视觉验收，证据见 §1.5；生产发布后仍需重新完成真机验收。

## 2. 当前能力审计

### 2.1 已存在并可复用

- 「问」页面已经支持语音优先、文字次之，以及照片和视频辅助输入。
- 已有统一 `ChatComposer`，不得再建设第二套聊天或上传组件。
- “记一下/帮我记/保存一下”已经具备识别、补充、确认、幂等保存链路。
- 已有 `PRIVATE/COMPANY` 保存范围和 `NOT_REQUIRED/PENDING` 流转状态。
- 后端已经能够得到员工有权限的项目编码集合，并在确认时校验项目权限。
- `aihr_assistant_capture` 已包含项目、房号、分类、摘要、跟进时间、来源请求和流转状态等基础字段。

### 2.2 已有基础但需要补齐

- `/api/aihr/mobile/me` 已返回完整授权项目列表；生产组织同步仍需用真实多项目人员验证。
- 数据层和前端已支持按项目名称选择、切换与账号隔离缓存。
- 图片和视频可用于本次分析，确认记录已支持绑定受保护原始附件；生产真机媒体链路尚待回归。
- 已确认记录保存最小必要来源快照，非文字来源通过受保护接口重新鉴权回看；查询审计本身仍只保存问题哈希和来源类型，避免把审计日志误当业务记录。
- 短会话已绑定当前项目，项目不一致拒绝复用。
- 已能按“员工 + 项目 + 自然日”幂等生成工作成果。

### 2.3 尚未实现

- 真实外部线索、工单、考勤投递与回执。
- 生产真机语音、照片、视频来源回看验收。
- 未经确认的自动外发（本期明确不做）。
- 公司处理类事项的真实外部回执。

### 2.4 外部边界

以下能力在正式接口确定前只能保留 `PENDING`：

- 养老服务线索正式送达。
- 客户画像正式写入。
- 正式工单系统派单。
- 正式考勤系统同步。
- 线索奖励和结算。

没有真实接口回执前，界面只能显示“已记录”或“待公司处理”，不得显示“已派单”“已同步”或“已送达”。

## 3. 总体实施策略

1. 复用现有工作助手页面、`ChatComposer`、确认卡和 `aihr_assistant_capture`。
2. 先完成项目隔离和本地工作闭环，再建设外部接口。
3. 工作记录按自然日聚合；问师傅仍保持 30 分钟、最近六轮短会话，不全局改为 24 小时。
4. 分类由 AI 建议，用户只做确认或修改。
5. 业务处理状态与外部流转状态分开，避免把“已解决”误写成“已送达外部平台”。
6. 日报先用确定性规则聚合，LLM 只润色；模型失败时仍能生成结构化成果。

## 4. 迭代计划

## 4.1 迭代 0：统一产品与接口语义

**预计：0.5-1 人日**
**优先级：P0**

### 工作内容

- 文档和页面统一使用“工作助手、今日工作成果、成果投稿”。
- 明确“确认记录”和“提交公司处理”是两个动作。
- 明确 `COMPANY/PENDING` 为待流转，不是成功回执。
- 工作日按自然日处理，MVP 时区固定为 `Asia/Shanghai`，不采用滚动 24 小时。
- 更新专项 TechSpec、总 TechSpec、API 文档和后续 Agent 实施提示词。

### 验收标准

- 文档、页面名称、接口状态没有互相矛盾的表述。
- 原有工作上报审核链不被删除，也不被误改成日常记录表。

## 4.2 迭代 1：当前项目选择与严格隔离

**预计：1.5-2 人日**
**优先级：P0**

### 用户交互

本迭代 UI 设计输入：`docs/prototypes/work-assistant-project-context-v3.png`，详见 [§1.3](#13-ui-变化与高保真基准) 和 [§1.4](#14-ui-设计交付清单)。顶部项目选择器和大尺寸底部面板已实现；运行截图见 §1.5。

页面顶部展示：

> 当前项目：星河湾一期 ▼

点击后打开适合一线员工操作的大尺寸底部选择面板：

- 只展示项目名称，不展示项目编码。
- 项目较多时支持按名称搜索。
- 标记当前项目和最近使用项目。
- 切换项目前，如存在未发送内容或待确认卡，必须提示用户确认。

进入逻辑：

- 只有一个项目：自动选择并展示名称。
- 多个项目：首次进入或第一次工作记录前必须选择。
- 没有项目：禁用工作采集，并提示联系管理员。
- 组织权限变化导致原项目失效：清除旧选择并要求重新选择。

### 技术处理

- 扩展 `/api/aihr/mobile/me`，返回去重后的 `projects[]`。
- `aihr_org_snapshot` 同一员工的多项目成员关系使用 `UNIQUE(tenant_id, project_code, ext_party_id)`；组织同步把有效 `employee_project_assignment` 展开为多条项目成员行，不能再按员工 ID 折叠为单项目。
- `projectName` 仅用于展示；`projectCode` 仅作为内部传输字段。
- 当前项目缓存按租户和登录账号隔离，退出登录时清除。
- 查询、保存、汇总都携带内部项目值，服务端与授权项目集合再次求交集。
- 切换项目时创建新的 `conversationId`，清除当前草稿和待确认上下文。
- 短会话记录补充项目约束，项目不一致时拒绝复用。

### 验收场景

1. 单项目员工自动进入。
2. 多项目员工按项目名称选择。
3. 切换项目后旧对话不进入新项目。
4. 篡改内部项目值时服务端返回 403。
5. 更换登录账号后不沿用上一账号的项目。
6. 390×844 视口下选择面板没有截断、遮挡或误触问题。

## 4.3 迭代 2：统一日常工作采集与来源追溯

**预计：3-4 人日**
**优先级：P0**

### 分类体系

不让员工在表达前选择分类。系统内部沿用现有枚举并仅补充确有需要的类型，确认卡上使用通俗中文：

- 到岗/晨会记录。
- 巡检问题。
- 业主服务记录。
- 待跟进事项。
- 住户画像。
- 服务线索。
- 经验案例候选。
- 项目工作记录。
- 个人笔记。

兼容既有 `SERVICE_LEAD / RESIDENT_PROFILE / CASE / FOLLOW_UP / PROJECT_NOTE / PERSONAL_NOTE`，不重建平行分类系统。

### 确认卡

本迭代 UI 设计输入：`docs/prototypes/work-assistant-project-context-v3.png`，详见 [§1.3](#13-ui-变化与高保真基准) 和 [§1.4](#14-ui-设计交付清单)。确认卡的项目、日期、来源和业务状态已实现；文字巡检的最终生产截图见 §1.6，媒体来源仍需生产真机回归。

确认卡至少展示：

- 当前项目名称。
- 发生日期。
- AI 建议类型。
- 地点或对象。
- 事项摘要。
- 跟进时间。
- 原始文字、语音或媒体入口。

操作保持精简：

- 确认记录。
- 修改。
- 暂不保存。
- 提交公司处理。

“提交公司处理”不是默认动作，AI 不得自动替用户执行。

### 数据补充

在候选记录和确认记录中补充：

- `work_date`：自然工作日期。
- `business_status`：本地业务处理状态。
- `source_snapshot_json`：最小必要来源快照。

`source_snapshot_json` 记录：

- 来源类型：`TEXT/VOICE/IMAGE/VIDEO`。
- 原始文字或语音转写。
- 受保护的 OSS 引用。
- 文件类型、时长等必要元数据。
- 图片或视频识别出的现场摘要。

不建设第二套对象存储，继续复用 `sys_oss/MinIO`。

### 媒体保存策略

- 用户发送媒体时完成识别，并产生临时来源引用。
- 用户确认后将来源引用绑定到采集记录。
- 未确认的临时素材在候选过期后清理。
- 下载必须重新鉴权，不返回公开 OSS 地址。
- 正式素材保留时长遵循租户隐私策略。
- 测试和演示只使用脱敏或合成材料。

### 状态模型

业务状态：

- 已记录。
- 待跟进。
- 处理中。
- 已完成。
- 已作废。

外部流转状态：

- 无需流转。
- 待流转。
- 已送达。
- 失败。

两组状态不得互相替代。

### 验收场景

1. 晨会照片加人数说明，保存为“AI 整理的到岗记录”。
2. 巡检照片加问题说明，保存为巡检问题。
3. 住户养老需求生成画像或线索建议，但不自动提交。
4. 语音“帮我记一下”产生完整确认卡。
5. 确认后的记录可以回看原始文字、语音或媒体。
6. 重复确认不会产生重复记录。

## 4.4 迭代 3：今日工作成果

**预计：2-3 人日**
**优先级：P1**

### 聚合口径

第一层：员工 + 项目 + 自然日。
第二层：主管 + 项目 + 自然日，聚合有权限员工的记录。

禁止按对话轮数或最近 30 分钟聚合。短会话继续使用原有时间窗口。

### 报告内容

- 当前项目、日期和记录人。
- 今日已完成工作。
- 巡检问题及处理状态。
- 业主服务和待跟进事项。
- 新增住户画像和服务线索。
- 到岗/晨会记录摘要。
- 未闭环事项和下一步。
- 每项内容的原始记录入口。

### 生成原则

- 先按记录类型和状态进行确定性分组。
- LLM 只压缩和润色，不决定记录是否存在。
- 生成接口必须幂等。
- 使用一个最小日报快照表，保存租户、员工、项目、工作日期、报告 JSON、来源记录 ID、版本和生成时间。
- 同一员工、项目和日期重新生成时更新版本，不重复创建日报。
- 暂不实现未经确认的自动外发。

### 页面入口

本迭代 UI 设计输入：`docs/prototypes/work-assistant-project-context-v3.png`，详见 [§1.3](#13-ui-变化与高保真基准) 和 [§1.4](#14-ui-设计交付清单)。工作助手摘要入口、员工详情页和主管项目视图已于 2026-07-21 发布并完成 390×844 验证；本轮历史日期选择已于 2026-07-22 发布，本地运行截图见 §1.5。

员工端：

- 今日首页“今日工作成果”。
- 工作助手顶部入口。
- “我 → 我的工作记录”。

主管端：

- 记录人数。
- 已形成成果人数。
- 待跟进数量。
- 高优先级问题。
- 按员工查看来源记录。

### 验收标准

- 同一天多种记录正确归类。
- 不同项目严格隔离。
- 跨天记录不串入。
- 每一项可以回到原始来源。
- LLM 不可用时仍能生成结构化报告。

## 4.5 迭代 4：本地闭环与成果投稿分流

**预计：2-3 人日**
**优先级：P1**

### 巡检和待跟进闭环

支持记录状态更新，并保留：

- 操作人。
- 操作时间。
- 修改前后状态。
- 处理备注。

### 成果投稿

现有「工作上报」页面改名为「成果投稿」或「经验沉淀」，保留：

- 优秀案例。
- 操作视频。
- 完整 SOP。
- 有用知识。
- 人工审核。

工作助手识别到高价值内容时，只提供建议：

> 这段处置过程可能适合作为优秀案例，是否整理成成果投稿？

用户明确同意后，才进入既有 `aihr_work_report` 审核链。

### 主管能力

- 查看团队今日成果。
- 查看待跟进事项。
- 查看成果投稿审核状态。
- 不虚构养老线索接收平台或外部工单后台。

## 4.6 迭代 5：外部线索、画像与工单接口

**预计：正式接口确定后 3-5 人日**
**当前状态：阻塞，不纳入内部 MVP**

实施前必须取得：

- 正式接口路径。
- 请求字段和必填规则。
- 鉴权方式。
- 幂等字段。
- 成功回执。
- 人工复核状态。
- 失败重试规则。
- 奖励回调规则。
- 测试环境。

实现时复用 `aihr_assistant_capture.delivery_status` 作为 Outbox：

- `COMPANY/PENDING` 记录由 Worker 异步投递。
- 保留请求摘要、尝试次数、错误和外部记录 ID。
- “满 100 条”或“每小时推送”只适用于外部线索流转，不应用于全部工作记录。
- 没有真实成功回执时绝不更新为 `DELIVERED`。
- 外部现金奖励与当前非现金积分体系保持分离。

## 5. 汇报 PPT 计划与交付

正式汇报稿已按 16:9、白底、银城红和深灰视觉体系完成，共 5 页；员工和主管页面使用 2026-07-21 脱敏运行截图，高保真图仅作为设计基准，不冒充生产截图。第 5 页已按本次生产发布结果更新。

权威 PPTX 路径：`docs/presentations/数字师傅工作助手迭代汇报-20260721.pptx`。

仓库内绝对路径：`/Users/yuanjiantsui/dev/11-project/wygj/docs/presentations/数字师傅工作助手迭代汇报-20260721.pptx`。

### 第 1 页：从零散记录到可追溯成果

- 说明语音、照片和文字如何进入同一工作助手。
- 展示权威高保真图和本地实现/HTTP/390×844 验证状态。

### 第 2 页：一线员工体验

- 用户按项目名称选择，不输入项目编码。
- AI 自动建议类型，员工只需确认。
- “确认记录”与“提交公司处理”明确分开。

### 第 3 页：多项目与权限

- 展示项目选择、服务端授权求交集、项目化短会话和项目化日报。
- 明确越权返回 403，外部系统无真实回执时只显示 `PENDING`。

### 第 4 页：员工与主管今日工作成果

- 员工看个人闭环，主管看项目汇总。
- 事实由确定性规则聚合，LLM 不决定事实是否存在。
- 展示幂等版本和状态历史。

### 第 5 页：交付状态与下一步

- 严格区分已实现、已本地验证、已视觉验证、已部署、生产已验证和待外部接口。
- 记录备份、迁移、后端/H5 发布、真实账号回归和权限回归结果。

### 交付物

- PPTX：`docs/presentations/数字师傅工作助手迭代汇报-20260721.pptx`。
- PDF 与演讲备注：按正式会议版本另行导出，不把尚未生成的文件列为已交付。
- 脱敏截图素材：`docs/visual-evidence/20260721/`。
- 无网络环境可播放的录屏备份。

## 6. 排期与发布批次

按一名熟悉项目的全栈开发者估算：

| 阶段 | 人日 | 可独立上线 |
|---|---:|---|
| 迭代 0：文档与语义 | 0.5-1 | 是 |
| 迭代 1：项目选择与隔离 | 1.5-2 | 是 |
| 迭代 2：统一采集与来源追溯 | 3-4 | 是 |
| 迭代 3：今日工作成果 | 2-3 | 是 |
| 迭代 4：本地闭环与成果投稿分流 | 2-3 | 是 |
| PPT 与演示材料 | 1-1.5 | 是 |
| 迭代 5：外部接口 | 3-5 | 否，等待正式契约 |

内部 MVP（迭代 0-4 加 PPT）原估算约 10-15 人日；本轮依托既有确认式采集和问师傅链路完成最小闭环，并已作为同一兼容发布批次上线。后续外部流转继续独立发布。

推荐发布批次：

1. **R1：项目上下文** - 迭代 0、迭代 1。
2. **R2：一线采集闭环** - 迭代 2。
3. **R3：今日成果与主管查看** - 迭代 3、迭代 4。
4. **R4：外部流转** - 迭代 5，等待接口后单独发布。

## 7. 风险与控制

| 风险 | 等级 | 控制措施 |
|---|---|---|
| 多项目串数据 | 高 | 项目选择、服务端权限校验、项目化会话、日报组合唯一约束 |
| 用户被迫理解专业分类 | 高 | AI 自动建议，用户只确认或修改 |
| 把 PENDING 显示为已派单 | 高 | 业务状态和流转状态分离 |
| 原始媒体无法追溯 | 高 | OSS 受保护引用绑定确认记录 |
| 图片和住户信息泄露 | 高 | 临时素材清理、重新鉴权、脱敏测试 |
| 日期边界混乱 | 中 | 服务端按 `Asia/Shanghai` 计算 `work_date` |
| 重复保存和重复上报 | 中 | 确认、状态更新和日报均使用幂等键 |
| LLM 输出不稳定 | 中 | 分类规则和聚合确定性优先，LLM 只润色 |
| 外部接口尚未确定 | 高 | 保持 PENDING，不伪造成功 |

## 8. 验证与完成口径

每个发布批次必须分别报告：

- 已实现。
- 本地测试通过。
- 视觉与交互验证通过。
- 已部署。
- 生产验证通过。
- 仍受外部接口或业务规则阻塞的边界。

### 8.1 2026-07-21 生产发布记录

- 功能提交：`4536d607 feat: add project-scoped work assistant results`。
- 确认卡首屏修正：`11250811 fix: show work capture context before actions`。
- 生产备份：`/opt/wygj/backups/work-assistant-20260721-044923`，包含数据库、旧 JAR、完整 H5 与哈希清单。
- 生产数据库：组织多项目唯一约束与工作成果/状态表迁移执行成功；目标表及字段检查通过。
- 生产后端：`wygj-aihr.service` 为 `active`，线上 JAR SHA-256 与本地构建一致。
- 生产 H5：入口资源为 `assets/index-CXWK6x5P.js`，本地、服务器和公网 SHA-256 均为 `2bcd96dc97af6f0e7e6d69f022b6eeaad5a855d6246044ef9ec3c05a6657388d`。
- 生产 HTTP：根入口、H5、租户接口、移动首页、登录、`/api/aihr/mobile/me`、知识查询、候选撤销和今日成果生成均成功。
- 权限与幂等：伪造项目被业务层以 `403` 拒绝；同一员工、项目和日期重复生成成果得到相同版本哈希。
- 正式员工账号现状：返回一个授权项目“银河湾星苑”，因此单项目自动选择已验证；双项目下拉仍以本地授权数据验证，不宣称生产多项目验收完成。
- 未完成边界：生产真机语音、照片、视频采集与来源回看；主管正式账号生产回归；外部线索、画像、工单、考勤接口与真实回执。

最小验证链：

1. 后端目标单元测试和数据库迁移验证。
2. 移动端类型检查与 H5 构建。
3. 真实本地 HTTP 链路验证创建、确认、查询、汇总和状态变化。
4. 390×844 视口验证项目选择、文字/语音/媒体采集、确认卡、状态、今日成果。
5. 实际操作项目切换、重复确认、来源回看和跨项目隔离。
6. 代码审查并处理确认问题。
7. 发布前备份，发布后使用真实试点账号完成生产回归。

### 8.2 2026-07-21 本地验证快照

- 后端目标测试通过：确认式采集、项目化会话、移动身份、多项目组织同步、今日成果和主管项目权限。
- 移动端新增目标测试 7/7 通过，`vue-tsc --noEmit` 通过，H5 正式构建通过。
- 真实本地 HTTP 已验证：手机号登录、两项目列表、越权项目 403、巡检识别、PRIVATE/COMPANY 确认、状态幂等重试、冲突键 409、状态历史、两项目日报隔离、内容不变版本不增长、普通员工团队视图 403、主管跨项目 403。
- 390×844 实际交互已验证：项目面板、项目切换、文字采集、确认卡、确认保存、今日成果、状态推进、主管项目成果；截图路径见 §1.5。
- 旧移动端组合合同测试仍有 15 条失败：其中多数是旧首页/旧“工作上报”文案合同与本轮产品定案冲突，另有 uni-app 测试打包器与当前 Vue 版本的既有兼容错误；不得据此声称全量移动端测试通过，提交前需把过期合同迁移或明确列为基线债务。
- 本地仍未覆盖且已在生产记录中保留边界：生产真机媒体回看、真实组织多项目 dry-run、主管正式账号回归、外部线索/工单/考勤投递与回执。

### 8.3 v1.6 发布验证快照（2026-07-22）

- 本节与 §8.2 的历史 `7/7` 通过、全量组合合同 `15` 条既有失败并列记录，不修改或倒填历史快照。
- 员工与主管成果页已完成历史日期切换；默认当天，历史页使用中性标题和空状态，可回到今天。
- 前端日期选择与服务端 `workDate` 均拒绝未来日期；不能通过直接请求绕过页面限制。
- 主管使用手机号作为组织身份时，项目成果查询和受保护来源读取均兼容手机号授权匹配；未匹配仍保持拒绝访问。
- 本轮定向测试、类型检查、H5 构建和四张 390×844 截图见 [§1.5](#15-本地运行视觉证据390844)。
- 已发布 H5 与后端 JAR；发布后完整预检通过：根站、租户、移动首页均为 `200`，schema `43/43`，成果幂等 `3/3`，工作助手字段 `7/7`，H5 与后端嵌套模块内容均与本地构建匹配。
- 此证据只证明本轮静态与服务发布正确；主管正式账号、真实组织多项目与真机媒体仍按 §8.2 的边界单独验收。

## 9. 推荐施工顺序

内部 MVP 已按以下顺序在 R1-R3 范围内完成并于 2026-07-21 合并发布：

1. 项目名称下拉选择。
2. 项目切换后的会话隔离。
3. 确认卡展示项目、日期和 AI 建议分类。
4. 保存晨会、巡检、业主服务、画像和线索。
5. 原始来源追溯。
6. 今日工作成果。

以上六项已经形成可供客户真实体验的一线工作闭环；主管项目汇总和成果投稿分流已上线。后续只把正式外部接口、主管正式账号生产回归和真机媒体验收作为独立批次处理。