Files
prop-ai-hr/docs/BACKLOG.md
T

12 KiB

Backlog

需求池:2026-07-03 甲方反馈四项

来源:甲方微信反馈(2026-07-03)。均不进 2026-07-05 一期 Demo(守 MVP 切割线),按下方优先级顺序排入 Demo 后迭代。 依据:物业AI人力资源系统业务需求文档BRD.md(D1 数据权限、4.3.4 案例视频、G6 成本闸门)、物业AI人力资源系统开发规格TechSpec.md(5 数据表、6.2 persona_json、/api/ai/tts 契约)。

B1. 层级数据权限 + 人资运营者角色(优先级 1,成本最低)

需求:按所管人层级看到不同项目人数;人资部门作为"运营者"负责整理资料、出题、每日收集训练结果、考评。

  • 组织快照映射进 sys_dept(本地只存 ext_party_id,BRD 4.6),数据权限以「项目」为范围主体(D1),用若依 @DataPermission 过滤,"不同项目人数"即权限过滤后的聚合报表。
  • 新建 hr_operator 角色,菜单挂既有/规划中后台能力:
    • 资料整理:SOP/案例管理(AihrSopController / AihrCaseController,已有)
    • 出题:practice_scenario 场景/人设/rubric 管理(TechSpec 第 5 章)
    • 考评:评分复核,基于评分缓存 practice_score
  • 净新增工作量:「每日训练结果」按日聚合报表一张页面(practice_session 聚合,TechSpec M10 驾驶舱子集);其余为角色/菜单/数据权限配置。

B2. AI 面试官/客户人设:分岗位形象 + 多语气声(优先级 2,对练体验提升最大)

需求:AI 员工分岗位等级面试官形象;模拟多种语气声——老太说话慢、带方言、吵架、求救听不清。

  • 复用三角色对练人设机制,不新建架构:面试官 = 另一组 practice_scenario.persona_json(TechSpec 6.2),按岗位等级(管家/主管/项目经理)建多条,新增字段:
    • avatar_url:岗位形象头像,由 B3 文生图生成
    • voice_profile:{ voice_id, speed, emotion, pitch, dialect }
  • TTS 契约扩展:POST /api/ai/tts 的 voice 参数扩成 voice_profile。以 MiniMax speech-2.8-hd 为参照:
    • 老太慢速 → 老年音色(如 Chinese (Mandarin)_Gentle_Senior)+ speed: 0.7
    • 方言 → 粤语/川话预置音色,或语音克隆接口用 ~15s 真实录音复刻(方言 TTS 本来就在一期集成清单第 4 项)
    • 吵架 → emotion: angry + speed: 1.2
    • 求救听不清 → TTS 出 emotion: sad/fearful 底音 + ffmpeg 后期加噪/压音量/断续("信道劣化"无现成 API,后期处理最可控)
  • 2026-07-04 反馈增补(截图见 feedback/2026070423/,解读见其 ANALYSIS.md):
    • 连贯语音对手戏:对练从"回合制答题"升级为实时情景对话——ASR→LLM(情绪人设+对话记忆)→TTS 低延迟循环,"很凶的老太太吵架"是验收场景;
    • 场景库分岗位:生活顾问为英雄岗位优先做深(日常小区服务/物业费停车费催缴/投诉处理全面覆盖,"老带新"式陪练;现有投诉/催费 seed 场景即属该岗位),四保一服(保安/保洁/保绿/保修/客服)其次做广;启用 practice_scenario.position/project_type 字段,内容不混岗。

B3. AI 一键生成场景培训图片(优先级 3)

需求:培训场景配图一键生成。

  • 供应商:SiliconFlow 已接入(embedding 同 key 可用 Kolors/FLUX 文生图),或 MiniMax POST /v1/image_generation。
  • 落地:ruoyi-aihr 新增 AihrMediaService + 异步生成任务表(生成慢,禁止同步等待);生成结果必须下载转存自有 OSS(MiniMax 返回 URL 仅 24h 有效)。
  • 前端:场景/SOP 编辑页加"一键生成配图"按钮,SOP 要点自动拼 prompt。
  • 受 G6 约束:图片调用计入月度成本上限。

B4. AI 一键生成培训视频(优先级 4,二期)

需求:一键生成培训视频;选定视频接口供应商。

  • 维持 BRD 既定决策:一期视频用预渲染样片(4.3.4),真接口二期;调用量受 G6 成本闸门约束。
  • 形态分层,先便宜后昂贵:
    1. 图文转视频(首选落地):B3 图片 + TTS 配音 + 字幕,ffmpeg 合成,成本近零
    2. 数字人口播(案例讲解视频主力):腾讯智影 / 百度曦灵 / 硅基智能,按分钟计费,比文生视频便宜一个量级
    3. 文生视频(片头/场景氛围镜头):可灵 Kling / 火山即梦 Seedance / MiniMax 海螺 / 通义万相
  • 选型倾向:二期先只接 MiniMax 一家打通(LLM + TTS + 文生图 + 视频一个 key 一套鉴权,对 2 人团队集成量最小,且同时覆盖 B2 语气声);视频质量不满意再单换可灵/即梦——全部封装在自有 provider 抽象后(参照 siliconflow embedding provider 先例)。
  • 2026-07-04 反馈:优先级上调(解读见 feedback/2026070423/ANALYSIS.md)——视频不是"锦上添花的生成玩具",而是表演型/动作类隐性知识的主传递媒介(巡逻、查卫生、礼仪、上门催费:"几个人去、带什么、开口怎么说,经验上的东西没办法说,好的领导现场表演一遍,现在都可以用 AI 做出来")。切入点:催费上门等 1-2 条示范视频先行,验证价值再铺量。

B5. 员工四维画像:训练时长 / 贡献度 / 测评分 / AI 等级

需求(甲方 2026-07-03 补充):每个员工要有训练时长、贡献度、测评分、AI 等级。贡献度 = 为平台提供的有效案例/资源等;AI 等级 = 系统对其的等级评定。

约九成落在 TechSpec M6 能力/认证/激励(P1) 既有排期内,不新建平行体系:

指标 承载 缺口
训练时长 practice_session.started_at、course_enrollment(P1) session 补 duration_seconds 字段 + 按人/按期聚合
贡献度 incentive_point(P1,自带 source)+ BRD 4.7 审核链 贡献计分规则(见下)
测评分 两层已设计:单场 practice_session.total_score(4维)+ 跨期 competency_assessment(BRD 4.5 五维加权 40/25/20/10/5) 无;两层勿混成一个数
AI 等级 certification / cert_rule(初/中/高,condition_json 规则引擎,P1) 只需写等级条件规则

设计要点:

  • 贡献度 = 积分体系的一个来源:员工提交案例 → review_task 专家终审通过 → incentive_point 记 source='case_contribution' 积分并署名入库(BRD 4.7 已定);贡献度即该来源积分累计,可按案例被引用/选入训练营加权。审核、署名、积分共用一条流水,不加表。
  • AI 等级 = cert_rule 组合另外三个指标:condition_json 示例 {训练时长≥20h, 画像总分≥75, 贡献积分≥100} → 中级。遵守 BRD"一期建规则,挂钩推迟"——等级可上线,挂钩晋升/绩效须过生产前闸门(AI 分挂钩绩效公平性/申诉、员工接受度 G4)。
  • 展示面已有落点:移动端 GET /api/aihr/mobile/profile(能力画像)聚合四指标(雷达图+时长+贡献积分+等级);管理端对应规划中的 /competency/radar、/competency/cert。

净新增工作量:① session 时长字段+聚合;② 审核通过→积分的贡献计分服务逻辑;③ profile 接口拼装四指标。其余为 M6 既有 P1 表和页面。

B7. 视觉向量检索(Doubao-embedding-vision,二期)

需求(2026-07-04 技术评审结论):纯视觉语义检索——"找演示保安站姿的视频"、图片素材以图搜图等"没说出口、也没写在画面上"的内容,当前文本向量链路(转写/OCR/caption → bge-m3)覆盖不到。

  • 选型已定:火山引擎 Doubao-embedding-vision(Seed1.6-Embedding,文本/图片/视频 → 统一向量空间,中文原生,0.7 元/百万 token)。优于 CLIP 类双塔方案:免融合排序调参、托管 API 免运维。
  • 工程量(不只是换模型名):入库管线支持"视觉片段"(帧/图直接向量化)、Qdrant 图文混合存储、检索结果展示帧图/跳转视频时间点、引用约束适配(视觉命中服务"找资料"场景,不进 RAG 生成)。
  • 前置:火山引擎开户 + G3/G6 供应商合规评估;图片/视频资料成规模、以图搜图成为真实高频需求。
  • 已做的替代缓解(2026-07-04):视频关键帧 caption(vision prompt 带画面描述)+ rerank(bge-reranker-v2-m3)已上线,覆盖大部分检索需求;B7 只补最后一段纯视觉语义。

B8. 数字师傅:学习旅程模块化 + 个性化分发引擎(2026-07-04 反馈,方向级)

来源:2026-07-04 用户反馈(截图与完整解读见 feedback/2026070423/ANALYSIS.md)。核心洞察:系统的对标物是"会带人的老师傅"——把言传(话术语音)、身教(动作视频)、判断(该学什么)用 AI 规模化;用户原话背书:"感觉像老带新的感觉"(截图 10)。

三个子块,可独立排期:

  1. 员工端五段学习旅程模块化:入职前面试考核 → 岗前培训 → 每日小训(5-10 分钟,独立模块) → 棘手问题即时求助("发一个语音,给我两三个 SOP 或话术"——检索输出加话术层)→ 场景模拟。角色主页做成"职责地图"(板块化菜单,不是卡片流)。
  2. 主管端学习监控面板:员工×活动(看了哪些视频/做了哪些互动)×时长×效果,衔接 B5 四维画像与视频观看时长统计(心跳+区间合并方案,见 2026-07-04 会话讨论)。
  3. 个性化分发引擎(系统的大脑):岗位(生活顾问为先,四保一服其后)× 阶段(入职前/岗前/在岗)× 画像短板 → 决定"今天该看什么/练什么";内容多了以后分发比生产更难("用 AI 分析该让他们看到哪些东西")。闭环:AI 生产内容 → AI 匹配媒介 → AI 决定给谁看 → 数据回流画像。

配套知识模型扩容:知识类型维度(SOP=标准 / 案例=参照 / 话术=直接能说 / 经验策略=火候),检索按类型分层供给;案例沉淀链路是隐性知识的采集入口,战略地位上调。

B9. 员工个人 AI 助理 + 个人知识空间(阶段二,2026-07-11)

来源:客户微信语音转写。员工希望把个人认为有用的表格、PPT、文章、网页链接、工作灵感和日常问题发给个人助理保存,之后按日期/主题追问、汇总分析并整理成文字或 PPT。

推荐拆分:

  1. P0 个人收藏:文字、多格式文件、图片、网页链接;保存来源、收藏时间、主题、解析状态和原附件。
  2. P0 个人检索:按时间范围/主题/来源查询,支持个人资料与有权限企业知识的混合检索,答案引用可追溯。
  3. P0 工作整理:把冲突、灵感、零散材料整理为结论、行动项和待确认项;不自动对外发送。
  4. P1 内容再加工:多资料对比、周报/月报、汇报提纲、PPT 生成;PPT 先确认大纲与模板。
  5. 阶段三扩展:北森、考勤、请假、组织任职等外部个人数据授权接入后,再提供跨系统分析。

前置闸门:个人空间与企业知识分域;默认仅本人可见;分享/企业入库需审核与脱敏;网页抓取需防 SSRF、尊重版权与访问权限;需提供删除、导出和数据保留策略。阶段二开工前另出专项 TechSpec,不直接复用公共知识库表造成权限串域。

零散待办

  • 总结卡「保存图片」按钮(设计基准 summary-modal 图内有):需 html2canvas 类依赖做 DOM 转图,2026-07-05 P0-2 实现时按"不加依赖"红线砍掉;引依赖或后端出图方案定型后补。
  • 员工端「学」板块(我的地图橙色块):已在 mobile-uni/src/pages/user/learning/index.vue 落成第一版,从今日任务、岗位 SOP 检索和训练前预习卡读取现有真实接口;后续再接课程/考试/视频学习数据。

Future Enhancements

Model Classification Version Governance

Current behavior:

  • Same document fingerprint reuses existing category, summary, and tags.
  • Model classification uses temperature=0 to reduce drift.

Add later when model upgrades need governance:

  • Record provider, model name, prompt version, and analysis time.
  • Preview batch reclassification after model changes.
  • Show before/after category and tag diffs.
  • Require admin confirmation before overwriting historical metadata.
  • Keep an audit trail of prior classification versions.