prop-ai-hr/docs/AI陪练完整交付计划-20260724.md

# AI陪练完整交付计划（固定范围版）

> 版本：v1.0 ｜ 日期：2026-07-24 ｜ 状态：工程实施中；内容校审与真实试点未完成
>
> 本文是总纲“阶段一：陪练”的唯一后续施工范围。它不新开一个“第 N 期”，也不因每次发现差异而继续拆分产品期数；后续工作只是在本计划的固定范围内完成、验收或明确取消。

## 1. 结论先行

### 1.1 当前版本处在什么位置

当前已上线的“练”不是零散 Demo，而是**五岗位基础训练闭环**：场景、评分标准、每日/专项/再练任务、2-6 回合对练、训练总结、训练历史、主管复盘和任务运营均已有主链路。

它仍不是“练模块完整交付”，原因不是缺少更多页面，而是缺少一套被业务确认的成长语义：

- 场景有 `position`、`project_type` 和 `difficulty`，但没有正式的“住宅物业 + 岗位 + 初/中/高级 + 能力项”目录；
- 每日/专项题类型与 `daily/camp/retry/manual` 任务来源都已存在，不能被误当作能力等级；
- 员工尚不能清楚知道自己处于哪个成长层、下一步该练什么、为什么被解锁或暂未解锁；
- 现有场景需要完成业务校审和矩阵归类，不能以“库里有多少条”替代内容可用。

因此，本计划的完成目标是：

> **把“练”收口为住宅物业五岗位、三级成长、可运营、可复盘、可证明的训练体系；生活顾问是首个深度试点岗位，不是唯一岗位。**

### 1.2 阶段口径一次定清

| 名称 | 含义 | 是否再拆成产品期 |
|---|---|---|
| 系统阶段一“陪练” | 银城员工端三阶段总纲中的第一个业务阶段 | 否。本文就是其完整收口范围。 |
| 当前五岗位基础闭环 | 已实现的工程与运营底座 | 不是新一期，是本计划的起点。 |
| 三级成长 | 同一陪练阶段内的内容组织和员工进阶规则 | 不是三个发布期，三层共同构成一个目标。 |
| 执行序列 | 为降低风险而安排的开发、内容、试点顺序 | 只是施工顺序，不产生新的产品边界。 |

除非业务明确批准“新增行业”或“新增岗位”，否则后续不再另列“陪练三期、四期……”。未完成项只按本文的交付清单标记为“未开始 / 实施中 / 已验收 / 取消”。

## 2. 固定范围：一个三维矩阵

| 维度 | 本计划固定值 | 处理原则 |
|---|---|---|
| 行业/业态 | **住宅物业** | 先跑通住宅场景，不纳入写字楼、园区、医院、学校等新业态。 |
| 岗位 | **生活顾问、保安、保洁、保修（工程）、客服** | 沿用系统现有岗位值和别名归一，不迁移历史 `position`。 |
| 成长层级 | **初级、中级、高级** | 代表训练复杂度和可练内容，不等于自动职级晋升。 |
| 能力项 | 每个场景归属一个岗位能力项 | 能力项是任务分配、进度展示和复盘聚合的共同语言。 |

### 2.1 “生活顾问做深”的正确含义

生活顾问是第一条深度主线：优先完成内容校审、三级成长规则、种子用户试点和指标验证。其余四岗不是只练“与生活顾问配合”这一件事；各岗位都必须保留与自身安全、服务和专业职责相关的核心训练，再补跨岗位协同场景。

例如，保修（工程）不能只练“接到生活顾问派单后如何说话”，还必须有安全确认、报修诊断、上门沟通和完工交接等经业务批准的专业场景。这样既避免首期铺得过大，也不会把岗位训练做成表面覆盖。

### 2.2 固定能力目录

下表定义固定交付范围必须覆盖的能力域。它是内容校审清单，不要求为了凑数新造场景；先将现有场景归位，只补缺失单元。

| 岗位 | 初级：能上岗 | 中级：能独立处理 | 高级：能处理复杂协同 | 首批深度优先级 |
|---|---|---|---|---|
| 生活顾问 | 接待与记录、日常巡检、报事报修受理、基础服务规范 | 投诉/催费/停车费沟通、跨部门跟进、回访闭环 | 重大投诉服务恢复、复杂协同、群体沟通与风险预判 | 最高 |
| 保安 | 门岗礼仪、访客/车辆、巡查和异常上报 | 纠纷初处、夜间/高峰处置、与管家协同 | 突发事件协同、现场秩序组织、复盘交接 | 第二梯队 |
| 保洁 | 作业标准、工具安全、现场反馈 | 异常卫生/投诉处理、时间与区域协调 | 重大活动保障、跨工种协同、品质复盘 | 第二梯队 |
| 保修（工程） | 安全确认、报修受理、上门服务与完工说明 | 故障初判、延期沟通、跨部门转办 | 高风险故障协同、服务恢复、复杂工单闭环 | 第二梯队 |
| 客服 | 咨询受理、信息记录、基础话术 | 投诉分级、情绪安抚、跟进协调 | 复杂客诉、群体沟通、服务升级与复盘 | 第二梯队 |

每个能力域至少要有：一条经审批的对练场景、一套可追溯 SOP/制度依据、一份对应 Rubric，以及一个明确的“不应这样做”的红线。生活顾问优先完成所有三级能力域；其余四岗先完成初级全部能力域和高频跨岗位协同，再补中/高级内容。

## 3. 当前实现基线与明确缺口

以下结论来自当前代码、迁移脚本和已发布的五岗位内容运营闭环；它说明“从哪里继续”，不把源码存在等同于业务验收完成。

| 能力 | 当前基线 | 本计划的收口动作 |
|---|---|---|
| 场景库 | 已有岗位、场景类型、项目类型、难度、人设、SOP、回合内容、启停和内容版本。 | 用既有 `project_type` 固定住宅范围；补成长层、能力项、协同岗位、内容审核状态，并完成现有内容归类。 |
| 对练 | 已支持 2-6 回合、文字/语音、LLM 失败时 seed 回退、训练前预习和训练中求助。 | 在生成上下文中带入住宅项目类型/岗位/层级/能力项；保证 seed 回退拥有同一语义。 |
| 评分 | 已有 Rubric、五维评分和会话评分规则快照。 | Rubric 与能力项、成长层绑定；评分只决定训练建议/解锁资格，不自动决定职级。 |
| 任务 | 已有 `daily`、`camp`、`retry`、`manual` 来源和主管批量派发。 | 按当前成长层和短板选题；保留来源含义，绝不拿来源代替等级。 |
| 复盘 | 已有训练总结、逐句标注、主管查看与复盘后再派专项；本机增量已可把主管的可选“下一训练层级确认”附着在本次复盘会话上。 | 复盘页显示能力项、所属层级、下一步推荐；主管可人工确认“可进入下一层”。 |
| 员工视图 | 已有今日训练、训练历史、能力画像和训练反馈。 | 增加“当前层级、已完成能力项、下一解锁条件、推荐训练”四项，不新建第二个学习入口。 |
| 管理运营 | 已有训练内容、题库、Rubric、任务管理页和权限控制。 | 在现有页面加矩阵筛选、审核状态、覆盖缺口和内容版本追踪，不另建平行后台。 |
| 试点证明 | 已有按日期导出、唯一在职组织身份和每人至少 10 次完训的严格统计口径。 | 用同一口径完成真实住宅项目试点，不以 seed、测试账号或截图替代。 |

### 3.1 代码与数据复用边界

本计划不新建第二套培训引擎。继续复用：

- `aihr_practice_scenario`：唯一的场景内容载体；
- `aihr_practice_rubric` / `aihr_practice_rubric_dimension`：唯一的评分标准载体；
- `aihr_practice_assignment`：唯一的每日、专项、再练、人工任务载体；
- `aihr_practice_session`：唯一的训练与历史快照载体；
- 现有 `/api/train/practice/**`、管理端训练运营页面和员工/主管端页面。

首轮只在既有 `scenario` 与 `session` 上增加必要元数据和历史快照：`growth_level`、`competency_code`、`collaboration_positions`、`review_status`、`risk_level`、首/第二审核人的稳定用户 ID、显示名及时间、`curriculum_version`。主管确认只保存到支撑该判断的原训练会话：`growth_confirmation_level`、`growth_confirmed_by`、`growth_confirmed_time`，不新建第二套成长引擎，也不改写原训练层级。住宅物业是本计划固定范围，直接复用既有 `project_type`，不新加一个永远只有单值的 `industry` 字段。任务从场景继承这些信息，不复制出另一张课程或训练营表。

## 4. 目标功能安排

### 4.1 内容运营：先让内容能被管理和证明

1. 在现有“训练内容”页为场景增加以下字段和筛选：既有住宅 `project_type`、岗位、初/中/高级、能力项、协同岗位、审核状态、风险级别、版本。
2. 审核状态固定为 `草稿 → 待业务审核 → 已发布 → 已下线`。员工只可看到“已发布且启用”的场景，且不可读取审核人身份和审核时间；管理员停用不是删除历史。运营可标注“常规”或“高风险”，但收费、安全、投诉等受控词及所有训练回合会由服务端自动升级为高风险，待评估内容不可发布；高风险场景的第一位审核人只会留下带稳定用户 ID 的待复核记录，必须由第二位不同的已认证运营人员复核同一内容版本才会发布。
3. 每条场景保存：业务来源/SOP 引用、目标、成功条件、红线、业主人设、回合数、Rubric、风险级别、首/第二审核人及时间和版本。
4. 内容修改后只影响新会话；既有 `session` 保存当时的课程/评分快照，避免历史成绩被新规则改写。
5. 后台提供“矩阵缺口”视图：按住宅物业 × 岗位 × 层级 × 能力项列出已发布、待审核、缺失，成为内容补齐的唯一清单。

### 4.2 员工端：从“有训练”变成“知道为什么练”

员工仍从底栏“练”进入，不增加“成长学院”等第二入口。页面由上到下固定为：

1. **我的成长位置**：当前岗位、当前层级、已覆盖能力项和本层待完成项；
2. **今天该练什么**：优先显示已派发专项、到期再练、当前层级的每日训练；
3. **场景训练**：按当前可练内容展示；未解锁的中/高级场景显示原因和所需条件，不做假进度；
4. **训练后总结**：沿用五维评分、证据句、红线、可说话术和下一步建议；
5. **我的历史**：按能力项与层级看趋势，且可回看主管已给出的复盘建议。

员工能够跳过或重练已开放的内容；“锁定”只用于业务确认需要前置训练的复杂场景，绝不能拦住紧急 SOP 查询或实际工作求助。

### 4.3 任务分配：来源与成长层各司其职

| 任务来源 | 产生规则 | 与成长层的关系 |
|---|---|---|
| 每日训练 `daily` | 从当前层级尚未覆盖或需巩固的能力项中选取。 | 是日常练习，不等于“初级”。 |
| 专项训练 `camp` / 人工 `manual` | 主管根据真实问题、复盘或业务活动派发。 | 可跨层派发，但需说明原因并留痕。 |
| 定向再练 `retry` | 同一能力项持续低分、触发红线或主管要求后生成。 | 用于巩固，不把一次低分直接降级。 |
| 自主训练 | 员工从已开放场景选择。 | 计入能力覆盖和成长证据。 |

成长规则采用一套**固定、可审计的规则版本**，不建设复杂的可视化规则引擎：

- 初级：完成岗位基础能力项的训练与业务确认；
- 中级：满足规定的初级能力覆盖、最低有效评分和必要复盘；
- 高级：满足规定的中级能力覆盖、复杂协同场景和主管复盘证据；
- 阈值由业务负责人和 HR 在开发前一次确认，写入版本化规则；规则调整只影响之后的训练推荐，不反写已完成历史；
- 主管的人工确认仅可基于其有权限查看的已完成会话，且只能从会话快照的初级确认至中级、或从中级确认至高级；它是训练证据，不能绕过尚待业务确认的正式解锁阈值；
- 系统给出“达到训练层级条件”的提示，**绝不自动调整员工职级、薪酬、晋升或资格结论**。

### 4.4 主管与运营端：把带教做成闭环，而非定向师徒

1. 主管查看员工时，先看到岗位、当前层级、能力缺口、连续低分/逾期风险和待复盘会话；
2. 进入训练详情后，沿用音频、逐句标注、五维评分和复盘建议；
3. 主管可一次完成“写建议 → 选能力项/场景 → 派下一次专项 → 标记已复盘”，并可选确认“可进入下一训练层级”；服务端按已绑定的主管范围与本次会话原始层级校验，只记录会话证据，不生成职级、薪酬或资格结论；
4. 运营端可按岗位/层级/能力项查看覆盖率、完训率、低分聚集和内容未命中；
5. 不做员工与员工之间的强制“师带徒”关系。员工经验共创仍由“问题榜/案例”承接，主管带教由训练复盘和任务派发承接。

### 4.5 AI 与知识边界

- LLM 提示词必须携带经过服务端校验的住宅 `project_type`、岗位、层级、场景、SOP 和 Rubric，不相信客户端自报的岗位或等级；
- 输出继续保持结构化：角色回复、情绪/信任、红线/纠偏、证据、总结与下一步训练建议；
- 模型不可用时，seed 回退也必须按同一场景元数据运行，不能退回跨岗位通用话术；
- “问”模块可在训练中提供已授权的 SOP 提示，未命中问题进入知识缺口，但不将问答回答伪装成员工真实待办；
- 案例/问题榜被采纳后可作为成长证据输入，是否计入学分或晋升资格仍遵循既有人工审核与规则，不由模型直接判定。

## 5. 固定实施序列

以下是完成本计划的施工顺序，不是新的产品分期。每一项的退出条件满足后才进入下一项；任何未通过项仍留在同一计划内处理。

### A. 冻结目录和业务规则

**工作**

- 确认住宅物业、五岗位、三级成长和上表能力域为唯一范围；
- 为每一能力域指定业务内容负责人和审核人；
- 将存量场景逐条归入矩阵，标记“可发布 / 待补资料 / 不适用 / 下线”；
- 一次确认初/中/高级的解锁阈值、是否需要主管复盘、试点项目与种子人员。

**退出条件**：矩阵没有未归属的已发布场景；每个待补单元有明确内容责任人；不再讨论新增行业/岗位作为本轮插单。

### B. 补齐最小数据语义与兼容迁移

**工作**

- 扩展现有场景、会话 DTO/SQL/服务端校验和筛选；
- 写可重复执行的迁移：不重写历史 `project_type`；成长层和能力项只能由内容运营确认后发布；
- 启动新会话时复制课程语义与版本到会话快照；
- 保持现有 `daily/camp/retry/manual`、场景编码、Rubric、已完成会话和训练历史可用。

**退出条件**：旧接口兼容；新字段可查、可筛、可审计；历史训练不因内容更新改变所属版本。

### C. 在既有页面完成运营与员工体验

**工作**

- 管理端训练内容、Rubric、任务管理页增加矩阵筛选、审核状态和覆盖缺口；
- 员工“练”页增加当前层级、能力进度、下一步训练和可解释锁定；
- 主管复盘与派发页展示层级/能力项/推荐再练；
- 完成手机 H5 常用尺寸的布局、可访问名称、登录/空态/错误态与文字对齐检查。

**退出条件**：员工、主管、运营三种身份都能从同一条真实数据看到一致的岗位/层级/能力信息，并完成一轮“发布内容 → 派发 → 训练 → 复盘 → 再练”。

### D. 内容补齐与质量校审

**工作**

- 先完整发布生活顾问三级能力域；
- 再完成四岗位初级能力域与高频协同，再补中/高级；
- 每条内容按“来源资料 → 场景卡 → 业务审核 → 模型回归 → 发布”流转；
- 对红线、高风险话术、收费/安全/投诉内容执行双人审核；
- 用真实但脱敏的典型对话做回归集，验证不同模型与 seed 回退。

**退出条件**：矩阵中每个承诺的能力域均有已发布、可运行、可追溯的内容；不存在仅靠 LLM 临时生成且未审核的正式训练场景。

### E. 真实试点、复盘和结项

**工作**

- 在同一住宅项目/组织窗口内，用真实在职身份开展试点；
- 跟踪完训、评分校准、主管复盘、内容反馈、知识缺口与异常中断；
- 用现有显式起止日期导出统计，复核唯一组织身份和每人至少 10 次已完成训练；
- 召开一次内容与产品复盘，只允许作“规则/内容修订”，不把未证实需求扩进范围。

**退出条件**：达到下文“完成定义”的工程、内容、试点三类门槛，并形成结项报告与继续/暂停/扩行业的正式决策。

## 6. 完成定义与验收证据

“计划完成”必须同时满足以下三层；任一层未满足，都只能称已实现或已部署，不能称整个练模块已完成。

| 层级 | 必须通过的证据 |
|---|---|
| 工程完成 | 数据迁移可重复执行；后端单元/集成测试通过；管理员、员工、主管真实接口贯通；H5/admin 构建通过；受影响页面实际操作并截图检查。 |
| 发布完成 | 静态管理端、移动 H5、后端 AIHR 模块和远端 schema 同时通过完整 `release-preflight`；生产健康检查通过；不把单纯 H5 发布写成完整发布。 |
| 业务试点完成 | 在同一明确起止日内，使用真实在职组织身份；每人至少 10 次已完成训练；有业务内容审核、主管复盘样本、满意度/有效性结论和问题清单。测试账号、seed 会话、开发固定验证码流程都不能充当此证据。 |

试点结项还应回答四个业务问题：

1. 生活顾问是否能用训练解决真实高频服务场景，而非只完成题目？
2. 主管是否能根据复盘和任务进行下一次带教？
3. 五岗位内容是否各自符合岗位职责和安全边界？
4. 知识缺口、低分能力项和业务反馈是否能推动下一次内容修订？

## 7. 明确不在本计划内

- 新行业：写字楼/园区、医院、学校、城市服务等；
- 新岗位：项目经理及第六个以后的岗位；
- 自动晋升、自动绩效、薪酬/资格自动决策；
- 员工间强制定向师徒关系；
- 实时主管旁听、全量录像、完整离线对练；
- 视觉/视频情境作为正式训练主链路，或方言能力的正式验收；
- 学模块课程/考试、问题榜、案例运营、北森对接的独立建设。

这些内容并非否定，而是要在本计划完成并经真实试点证明后，由新的、显式批准的需求进入阶段二或阶段三。不得以“顺手补一下”为由混入当前陪练收口。

## 8. 变更控制

本计划冻结后，任何新增请求先按下列规则处理：

| 请求类型 | 处理方式 |
|---|---|
| 能使住宅五岗位三级矩阵某一单元可验收 | 允许进入对应工作项，并更新矩阵状态。 |
| 改善已存在链路的缺陷、性能、可访问性或安全 | 允许作为缺陷修复，不改变范围。 |
| 新岗位、新行业、新业务模块、自动人事决策 | 记录为后续候选项，不插入当前计划。 |
| 仅有演示需要、没有业务审核素材 | 只可做受控 Demo，不能标为正式已发布内容。 |

## 9. 相关事实源与实现入口

- 总阶段边界：[银城员工端APP分阶段实施总纲](银城员工端APP分阶段实施总纲.md)
- 历史实施记录（保留追溯，不再作为后续范围切分依据）：[AI陪练二期开发推进计划](AI陪练二期开发推进计划.md)
- 当前接口与训练闭环：[API_INTEGRATION](API_INTEGRATION.md)
- 当前生产/试点证据边界：[BRD_IMPLEMENTATION_AUDIT](BRD_IMPLEMENTATION_AUDIT.md)
- 场景、任务和评分的实际实现：[`AihrPracticeController`](../backend/ruoyi-modules/ruoyi-aihr/src/main/java/org/dromara/aihr/controller/AihrPracticeController.java)、[`AihrPracticeSeedService`](../backend/ruoyi-modules/ruoyi-aihr/src/main/java/org/dromara/aihr/service/AihrPracticeSeedService.java)、[`aihr_practice_mysql8.sql`](../backend/script/sql/aihr_practice_mysql8.sql)

> 执行原则：先完成矩阵内已承诺的能力，再以试点证据决定是否扩展；不再把“发现一个差异”误包装成“又要开一个新一期”。

## 10. 本次工程实施记录（2026-07-24）

本节只记录已落地的工程事实，不能替代业务内容审核或真实试点结项。

| 固定实施序列 | 当前工程状态 | 已落地内容 | 尚需业务动作 |
|---|---|---|---|
| A. 冻结目录和业务规则 | 待业务确认 | 五岗位、三级与能力目录已固化为服务端目录；矩阵会明确显示“待归类”。 | 指定内容负责人/审核人；逐条归类存量场景；确认真实解锁阈值与试点名单。 |
| B. 最小数据语义与兼容迁移 | 已实现、已本机回归 | `scenario` 增长层/能力项/协同岗位/审核/风险/版本；首/第二审核人同时保存稳定用户 ID、显示名和时间；`session` 保存岗位、项目类型与课程快照，以及可选的 `growth_confirmation_level/growth_confirmed_by/growth_confirmed_time`。确认只能写在被复盘会话上，不能覆盖原层级快照；迁移可重复执行，且不会清空高风险内容已完成首审、正在等待第二人复核的审核轨迹。旧 `enabled` 场景一律进入“待业务审核”，不从启停状态推断“已发布”；历史详情只读会话快照，缺失时明确标注“历史未记录/未归类”。已完成会话的重复 `/finish` 仅回读持久化评分与快照，绝不按当前场景重新归类或写回。运行环境的全部 `ensure*` 路径默认只校验 schema、绝不执行 DDL；派发请求的幂等唯一键与最近内容索引必须同时满足唯一性、完整列序和无前缀，偏离即失败关闭。远端完整预检会同时校验这两个索引定义及 `wygj-aihr.service` 的有效环境未开启 runtime bootstrap。 | 在目标环境按发布顺序执行正式迁移；内容运营逐条归类、审核后再发布。 |
| C. 既有页面体验 | 已实现、已本机真实页面验收（部分） | 管理端场景页新增目录字段、审核流、风险选择、审核轨迹与缺口矩阵；新增场景弹窗已在本机真实登录后的页面检查，风险下拉明确展示“待评估 / 常规 / 高风险（需两位不同审核人）”。员工“练”页显示成长位置、能力证据和已发布场景，无可用场景或目录加载失败时清空旧卡片并禁止开始；每日三题只会从已发布、已启用、风险审核完成的同岗位场景题库取题，并优先补当前最低未覆盖的成长层/能力项（仅作训练推荐，不自动改职级或形成硬性解锁）。主管复盘页对初级/中级会话提供可选的下一层确认，员工画像回显该会话证据；服务端只接受初级→中级或中级→高级，且复用既有主管范围校验。移动端仅按认证手机号精确解析 `person_phone`；后台不得向 `/api/aihr/mobile/**` 传入 `ext_party_id` 读取个人训练或主管数据，后台运营仅通过独立 `/api/train/practice/**` 契约以及不绑定员工身份的 `operator:{userId}`、`mode=preview` 预览完成；`/me` 与问师傅主体不再使用组织模糊查询。若手机号与其他人在职外部 ID 碰撞、同手机号关联多名在职员工，或同一外部 ID 映射多个在职手机号，则拒绝猜测、读取或写入任务；员工历史、画像、成长进度和晋升证据只从同一服务端核验的别名集合聚合。主管范围只保存外部 ID；旧手机号必须唯一映射到一个外部 ID，且该外部 ID 也唯一拥有该手机号，才可读出和统计；这一规范化结果复用于团队列表、详情、复盘、音频授权与后续任务，歧义记录一律排除。案例项目范围与岗位 SOP 同样复用已验证 APP 主体的精确项目范围，不再以手机号/外部 ID 混合查询或组织模糊快照兜底。员工端账号由服务端强制按 `mobile` 模式和组织岗位校验。管理端对练看板可走服务端绑定的 `preview` 运营预览，但不能传入或读取员工身份，预览记录不进入员工/主管/试点统计。主管复盘显示本次课程快照，只在有岗位快照时加载同岗再练场景。 | 用具备主管权限的真实身份，且至少有一条经业务审批的已发布场景，走完发布→训练→复盘（含可选下一层确认）→再练。 |
| D. 内容补齐与质量校审 | 工程门禁已实现，业务内容未开始 | 后台已提供内容归类、审核、下线、风险分类、版本和审核轨迹入口；发布前强制校验业务来源/SOP、红线、目标、成功标准、回合、能力项和五维 Rubric；待评估风险不能发布，高风险内容必须由两位不同审核人完成双审。 | 先完成生活顾问三级内容与四岗初级内容的来源、Rubric、红线和实际双人审核；不得将测试/seed 内容标为正式发布。 |
| E. 真实试点与结项 | 未开始 | 已保留既有导出和严格试点统计口径。 | 在同一项目、明确日期、真实在职身份下完成每人至少 10 次训练与结项复盘。 |

#### 10.1 管理端与移动端的权限收口（2026-07-24）

> 以下安全收口已随 2026-07-25 完整包部署；员工训练写入、主管复盘和真机媒体仍需专项生产验收。

- `/api/aihr/mobile/**` 的员工历史、画像、任务、主管复盘和团队难题仅由认证 APP 身份使用；员工端不采信客户端传入的 `extPartyId`，主管端从当前 APP 手机号解析项目范围。
- 对练录音下载同样只接受经 APP 身份和会话范围校验的请求；后台账号不能通过移动端 OSS 路径按对象编号读取员工录音。
- 管理端预览固定为 `operator:{userId}` 与 `mode=preview`，只能验证场景、模型和评分链路；不得读取员工身份、训练历史、主管复盘、成长证据或试点统计。
- 原后台“复盘校准 / 常见难题 / 成长激励”个人数据入口已撤出菜单并重定向到“任务运营”。后台继续保留已授权的内容审核、场景/Rubric 管理与批量任务运营；真实复盘、团队难题和定向再练由主管 APP 完成。

### 本次验证证据

- `mvn -pl ruoyi-modules/ruoyi-aihr -am -DskipTests=false -Dtest=AihrDashboardServiceTest,AihrPracticeSeedServiceTest,AihrPracticeLlmServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`：96 项通过；
- `mvn -pl ruoyi-modules/ruoyi-aihr -am -DskipTests=false -Dtest=AihrPracticeSeedServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`：本轮每日三题、题库审核失效与移动身份别名回归 89 项通过；
- `bash scripts/tests/aihr-schema-migrations.test.sh`：隔离 MySQL 数据库内重复执行迁移通过；成长目录迁移会补齐并修复派发幂等唯一键和最近内容索引。
- `pnpm --dir frontend build:dev`：管理端构建通过；
- `npm --prefix mobile-uni run typecheck && npm --prefix mobile-uni run build:h5`：员工/主管 H5 类型检查与构建通过。
- `node --test mobile-uni/tests/mobile-user-pages.test.mjs`：本轮新增的“当前已选场景启动”和“目录加载失败禁用开始”断言通过；全套仍有 3 条既有语音/方言断言与当前语音源码不一致，未在本计划中改写无关语音行为。
- 本机浏览器：管理端已认证打开“场景与评分”，验证矩阵刷新与场景元数据编辑对话框；员工端按“获取验证码 → 开发固定码 → 登录”完成认证，查看“我的成长位置 / 场景训练 / 错题练习 / 每日三题”。当前账号没有已发布场景时，页面明确提示需内容运营审核发布；员工身份直达“待复盘”返回“当前账号无主管权限”，未显示团队数据。登录手机号和验证码输入已改为 `tel`，保留数字键盘并避免浏览器将手机号当数值近似显示或丢失验证码前导零语义。
- `mvn -pl ruoyi-modules/ruoyi-aihr -am -Dtest=AihrPracticeSeedServiceTest,AihrKnowledgePrincipalResolverTest,AihrCaseServiceTest,AihrSopSeedServiceTest,AihrSchemaMigrationGuardTest,AihrRuntimeSchemaBootstrapContractTest -Dsurefire.failIfNoSpecifiedTests=false -DskipTests=false -Dmaven.test.skip=false test`：164 项通过，覆盖 APP/组织身份分流、历史手机号团队映射、案例范围、岗位 SOP 范围与 runtime schema 守卫。
- `mvn -q -pl ruoyi-modules/ruoyi-aihr -am -DskipTests=false test`：AIHR 模块全量 588 项通过。过程中修正了“问”模块训练数据工具的旧单测 mock：它必须先验证 APP 手机号，再读本人训练或经验证主管范围，不能继续按旧组织身份契约断言。
- `mvn -pl ruoyi-modules/ruoyi-aihr -am -Dtest=AihrSchemaMigrationGuardTest,AihrRuntimeSchemaBootstrapContractTest,AihrPracticeSeedServiceTest,AihrLearningContractTest,AihrExamIdempotencyTest -Dsurefire.failIfNoSpecifiedTests=false -DskipTests=false -Dmaven.test.skip=false test`：116 项通过；覆盖表/列/索引缺失时失败、派发幂等唯一键或最近内容索引存在但唯一性/列序/前缀错误时在任何 DDL 前失败、全部运行时 DDL 服务的静态门禁以及 Spring 实际属性缺省为关闭的行为。
- `mvn -pl ruoyi-modules/ruoyi-aihr -am -Dtest=AihrPracticeSeedServiceTest,AihrRuntimeSchemaBootstrapContractTest,AihrSchemaMigrationGuardTest -Dsurefire.failIfNoSpecifiedTests=false -DskipTests=false -Dmaven.test.skip=false test`：109 项通过；覆盖主管确认只能写入下一训练层级、确认写入原复盘会话、员工画像回显和新增字段的 schema 守卫。
- `bash scripts/tests/aihr-schema-migrations.test.sh`：在隔离 MySQL 内重跑通过，包含 `growth_confirmation_level/growth_confirmed_by/growth_confirmed_time` 三列的重复迁移。
- `FRONTEND_URL=http://127.0.0.1:4347 MOBILE_URL=http://127.0.0.1:4408 bash scripts/demo-check.sh`：通过；包含管理端、移动端 H5、租户/验证码接口、真实流程标记与严格试点门槛检查。门槛输出仍显示业务内容与真实试点未完成，不能把该通过当作试点结论。
- 本地开发库只读快照：五岗位各 20 条场景，全部为“初级 / 草稿 / 待评估”；正式训练会话 5 条、已复盘 3 条、达到每人 10 次完训的人数为 0。这些是开发 seed/本机验证数据，不可作为内容审核或试点证据。
- 2026-07-25 完整发布后，生产 H5 已包含手机号/验证码 `tel` 输入修复；使用从生产组织快照只读选择的在职员工手机号完成“请求验证码 → 登录 → 进入员工首页”认证回归。手机号未写入仓库、报告或截图；该回归不替代正式短信或真机验收。
- 生产服务保持 `AIHR_PRACTICE_RUNTIME_SCHEMA_BOOTSTRAP` 关闭，远端只读 schema 预检为 `64/64`，后端 JAR 与 AIHR 模块哈希和发布源一致；请求仍只能校验结构，不能执行 DDL。
- 2026-07-25 15:44:45，源码提交 `acd5fd3a` 增加常规陪练“建议回复”：服务端根据当前回合与教练提示生成可编辑但不自动发送的员工回复，失败时不复制提示。该提交已推送、尚未部署或生产验证。
- 2026-07-29，8 月 1 日 `0.1.13 (113)` 候选已在干净提交 `af8af2f6` 完成统一 RC，`releaseEligible=true`；199 项移动端测试、类型检查、H5/App、管理端构建、`ruoyi-aihr` 700 项测试、后端打包和 APK 深检通过，证据在 `output/aug1-rc/0.1.13-113-af8af2f6-frozen/`。生产固定码完成首次获取/登录、退出、旧令牌失效、等待防刷窗口后的再次获取和重新登录，两次均确认未真实发送短信；该项不再列为缺口。候选后端 JAR SHA-256 为 `93AD272118F6A28F88C2BFA305F5C450E163CBE22577FF5BE3E85B3BD3958DAD`，生产只读发布计划通过但未获部署授权、未发布。当前双提交交付包 `output/aug1-release/bangdao-aug1-0.1.13-113-af8af2f6-ops46f4616b.zip` 大小 `192,948,093` 字节，SHA-256 为 `F6DF4AB2660A4D3523C7E9785C1F8B572770F1F795A841E2D95C88936A8AE9C0`，20 个条目和内部哈希已复核；严格门禁覆盖正式场景、问题证据、五类负责人、五通道授权/越权/单次正式回复和受控分发/法务/签名决策，包内 Go/No-Go 已指向当前双提交包，旧 `ops9c53668c` ZIP 只作历史追溯。当前机器签认仍为正式场景 `0/5`、问题证据 `0/30`、通道验收 `0/5`、负责人签认 `0/5`、受控分发 `PENDING`。

当前只能确认 `0.1.13` 自动化候选已冻结、现网接口兼容且 schema 为 64/64；新后端尚未获授权部署，不能把历史完整包匹配外推为当前候选已上线。正式内容与五通道处理人签认、主管真实复盘、真机媒体和严格试点仍未完成，不能称“陪练模块完整交付完成”。