14 KiB
下一步计划（「帮道-跟进的意见」对齐版）
版本：v1.0 日期：2026-07-27 需求输入：《帮道- 跟进的意见.txt》（会议纪要，微信文件） 现状基准：生产只读实测（2026-07-27）+ BRD 功能审查 + Changelog 死线：2026-08-01 测试版上线（会议明确「倒排」「边跑边调」） 上位文档：分阶段实施总纲 > BRD > TechSpec
0. 结论先说
会议提的九项要求里，七项功能代码已经存在，真实缺口不在开发，而在三处：
- 未发布：main 领先生产发布基线
230dfb4d25 个提交，其中「Agent 追问不再误答成澄清」（7b014765）必须发 JAR 才在生产生效。这是 8/1 死线的头号风险，也是最便宜的一次性收益。 - 内容与运营空转：
aihr_knowledge_category生产 0 行，分类分级打标签能力表建好了但完全没用；向量覆盖率只有 44%，制度库更低到 23%。会议抱怨的「回答冗长、矛盾、来源不清」根因在这里，不在检索算法。 - 两项真净新增：AI 每日问题简报、AI 短视频。其余都是补齐或运营。
必须先纠正会议里的三个技术前提，否则会按错误方向投入：
| 会议表述 | 生产实际 | 影响 |
|---|---|---|
| 「通过向量数据库（RAG）技术提升检索精准度」 | 向量检索已在线：Qdrant 3638 点、BAAI/bge-m3 1024 维已启用，与 SQL LIKE、MySQL 全文检索三路 RRF 融合后再 rerank |
不是新建设，是补覆盖率。按「上 RAG」立项会重复建设 |
| 「探索向量数据库 RAG 的 17 种搭建方式」 | 当前架构已定且在跑；换方案的收益远低于把 4714 个未向量化片段补齐 | 建议改为「补覆盖 + 调参（分块/阈值/rerank）」，不做架构选型 |
| 「AI 机器人即时响应『我已收到，将跟进处理』」 | 直通车无任何自动回复；status 建为 SUBMITTED，reply_content 至人工回复前为 NULL |
是真缺口，但要先定边界：自动回复不得让员工误认为已处理 |
另有一处产品定位冲突需要拍板，见 §4。
1. 会议九项要求 × 当前事实
| # | 会议要求 | 当前事实（含证据位置） | 缺口性质 |
|---|---|---|---|
| 1 | 聚焦「学」「问」，删除冗余功能、隐藏入口 | 员工端 45 页、tabBar 四项 = 今日/练/问/我。「学」不是 tab，在 pages/user/learning/index.vue（1545 行）二级页 |
信息架构调整 |
| 2 | 优先落地虚拟练习 + 政策制度问答 | 虚拟练习已上线（100 场景/86 启用/44 会话）；政策问答无独立入口，与 SOP 混在同一「问师傅」Agent | 补入口 + 内容 |
| 3 | 暂不做拍照生成工单，只给「如何写工单」指引 | 已符合。全仓 工单 仅 services/auth.ts 一处，外部投递未接，写 COMPANY/PENDING |
已达成，勿动 |
| 4 | 空间划分（全员/业务/人资），上传可多选可见空间 | 多选可见空间已实现（uploadDoc(file, List<String> spaceCodes)，每个目标空间校验 MANAGE）；但生产授权只有 ROLE 四值（employee/supervisor/hr_operator/superadmin），无全员/业务/人资划分 |
配置 + 少量后台 |
| 5 | 课程资料归集、分类分级打标签 | 13 个空间 / 8352 片段已入库，但 aihr_knowledge_category = 0 行；最大空间名为「其他（行政管理制度）」648 文档 4260 片段，完全未分类 |
纯运营，最大阻塞 |
| 6 | 高价值内容转 AI 短视频 | 全仓无短视频内容类型。视频仅两种形态：附件扩展名启发式判定的 VIDEO 检索意图、员工上传的现场视频证据 |
真净新增 |
| 7 | 政策制度独立封装、独立查询入口 | 无独立端点/空间/表。制度 只是 Agent 路由关键词（与 sop/流程/规定 并列） |
补入口 |
| 8 | 员工直通 CEO/财务/运营/人力 | 已上线并生产验证：五通道（总裁/财务/人力/审计/运营）、业务匿名、一次正式回复、管理端 /content/direct 页 |
已达成 |
| 9 | AI 即时响应 + AI 每日问题简报匿名汇总管理层 | 自动回复无；每日简报无（后端 9 个 @Scheduled 均与直通车无关）。生产直通车仅 2 条数据 |
真净新增 |
会议要求的「访谈 24 位优秀生活顾问」属业务侧动作，不占开发资源，但产出物（标准动作指南、标准应答话术）是 §2 内容工作的输入，故列入 §5 外部输入催办。
2. 真实阻塞：内容与覆盖率
这是全部计划里唯一会决定 8/1 测试版口碑的部分。开发量小，运营量大。
2.1 向量覆盖率缺口（生产实测 2026-07-27）
| 空间 | 名称 | 片段 | 已向量化 | 覆盖率 |
|---|---|---|---|---|
| 1008 | 其他（行政管理制度） | 4260 | 990 | 23% |
| 1009 | 培训视频 | 2571 | 1286 | 50% |
| 1010 | 图片素材 | 153 | 0 | 0% |
| 1201 | 增值服务需求识别 SOP | 3 | 0 | 0% |
| 1202 | 日常服务回访 SOP | 3 | 0 | 0% |
| 1001–1007、1203 | 其余 | — | 全覆盖 | 100% |
| 合计 | 8352 | 3638 | 44% |
未向量化的 4714 个片段只能靠 SQL LIKE 和 MySQL 全文检索命中。中文全文检索对制度类长文本的召回质量明显弱于向量，这直接解释会议反馈的「来源不清、答非所问」。
另需注意：vectorHits 是 catch-all 静默降级（AihrSopSeedService.java:2874-2877，注释 "vector recall is additive"），embedding 端点或 Qdrant 配错只会退化成关键词检索，不报错。回答质量下降先查这里，不要先怀疑 Prompt。
2.2 分类分级为零
aihr_knowledge_category 表结构就绪（tenant_id, knowledge_id, code 唯一约束）但生产 0 行。会议要求的「课程分类分级、打标签、识别高价值内容」目前完全没有落点。
同时 searchAuthorized 把 category 硬编码为 ""（AihrSopSeedService.java:210），所以即使填了分类，授权检索路径也用不到——要让分类真正影响检索，需要一处后端改动。
3. 分批计划
R1：原子发布（8/1 死线前必须完成，最高优先级）
不含任何新功能，纯粹把已完成的 25 个提交送上生产。
| # | 任务 | 完成定义 |
|---|---|---|
| R1-1 | 隔离 worktree 收拢 main 至 release commit，跑 release-preflight.sh（拒脏工作区） |
release commit 落字；当前 3 个脏文件（mobile-uni/package.json/package-lock.json/manifest.json）先提交或收拢 |
| R1-2 | 备份后端 JAR + H5 + DB，原子切换，重启 wygj-aihr.service |
备份目录落字；服务 active；错误级日志为 0 |
| R1-3 | 生产复核 schema、静态资源哈希、AIHR 模块与本地构建一致 | 远端预检通过；7b014765 追问修复以认证态验证生效 |
风险：这 25 个提交含 App-Plus 实时对练、编译链升级、ASR 切换等较大改动，且部分「已本地验证、未真机验收」。建议 R1 只发后端 JAR + H5，App 云打包另走一批，避免把未验收的原生包混入死线发布。
R2：内容与检索质量（8/1 测试版的实际口碑来源）
| # | 任务 | 归属 | 完成定义 |
|---|---|---|---|
| R2-1 | 补齐向量覆盖：对 1008/1009/1010/1201/1202 重跑 embedding 入库 | 技术 | Qdrant 点数与 aihr_knowledge_fragment 一致（8352）；抽样 20 条制度类问题命中率留证 |
| R2-2 | 制度库分类分级：把 1008 的 648 个文档按业务口径归类，写入 aihr_knowledge_category，空间改名（去掉「其他」） |
人力牵头 + 业务 | aihr_knowledge_category 非空；每个分类有负责人 |
| R2-3 | 让分类进入检索：解开 searchAuthorized 的 category="" 硬编码，支持按分类收窄 |
技术 | 定向测试；不改变既有无分类调用的行为 |
| R2-4 | 检索调参：分块大小、similarity_threshold、rerank 生效性验证；固定 ≥20 条真实问题回归集 |
技术 | 调参前后同一回归集对比留证，不靠主观感受判定 |
| R2-5 | 政策制度独立入口：新建政策空间 code + 授权 + 「问」页独立入口，答案强制带来源 | 技术 | 未命中不编造（复用既有 unsupported_claims 硬约束）；答案必显来源文档名 |
R2-1 是纯技术动作，当天可完成；R2-2 是整个计划的关键路径，无业务侧归类就无法验收「回答精准」。
R3：信息架构收敛（会议第 1 项）
| # | 任务 | 完成定义 |
|---|---|---|
| R3-1 | 确认「学」「问」为主场景后的 tabBar 方案（见 §4 待拍板） | 方案定稿 |
| R3-2 | 按决议隐藏非核心入口（只隐藏入口，不删代码、不删表） | 隐藏项可一键恢复；无死链；已发布能力不回退 |
| R3-3 | 「如何写工单」指引内容进知识库（会议第 3 项） | 员工问「工单怎么写」能得到带来源的答案 |
边界：会议说「删除冗余功能」，工程上执行为隐藏入口。已生产验证的能力（大喇叭、直通车、问题榜、工作成果）删代码等于毁掉已验收资产，且与总纲阶段二冲突。
R4：直通车闭环补齐（会议第 9 项）
| # | 任务 | 完成定义 |
|---|---|---|
| R4-1 | 提交后自动回执 | 文案不得暗示已处理；员工端状态仍显「待处理」，与人工「正式回复」视觉可区分 |
| R4-2 | 简报聚合查询接口（当前 adminFeedback 只返回分页列表 + total，无未回复时长/分通道计数） |
新增聚合端点 + 定向测试 |
| R4-3 | AI 每日问题简报，匿名汇总 | 匿名口径复用既有实现（处理端只见「匿名员工」，内部保留审计）；简报不得泄漏 sender_name |
| R4-4 | 简报投递到管理层群组 | 依赖外部输入：群组、时间、渠道、重试规则未确认前不实施（同智能日报既有口径） |
R4-3 需注意：现有产品边界是「一条反馈仅一次正式回复，不做多轮/工单/SLA」（AGENTS.md:56）。简报是聚合视图，不要顺势做成工单系统。
R5：AI 短视频（会议第 6 项，建议不进 8/1）
会议要求「学习 AI 视频制作技术，小丽牵头与张立团队协作，不依赖外部供应商」。这是从零起步的能力建设，与 8/1 死线不兼容。
建议：8/1 前只交付 1 条示范视频（人工+AI 辅助均可），作为方向验证；系统化的视频内容类型、播放进度、转码等留待方向确认后立项。这与既有半年会「1 条示范视频」止损口径一致。
4. 需要拍板的三个决策
D-A：「学」是否升为 tabBar 一级入口
会议说聚焦「学」「问」两大主场景，但当前「学」是二级页，tabBar 是今日/练/问/我。两者矛盾。
- 选项 1：「学」替换「练」进 tab —— 与「优先落地虚拟练习」冲突
- 选项 2：tab 扩到五项 —— 违背「简化」
- 选项 3：「今日」页承载学习入口，「学」仍为二级 —— 改动最小，但没体现「聚焦」
倾向选项 3 + 把「今日」的学习入口做显著提升，理由是虚拟练习是会议明确的 P0，不应让位。需产品拍板。
D-B：空间划分口径
会议要「全员/业务/人资」，当前是 employee/supervisor/hr_operator/superadmin 四个 ROLE。这两套是不同维度（内容归属 vs 人员角色），不能直接映射。需业务确认：
- 「业务空间」指哪些部门可见？与现有
supervisor是什么关系？ - 大库 1006（验收测试）、1203（sop）当前仅管理端可见，1004–1010 已对 employee 放开——这与既有「大库待业务签字再放开」的记录不一致，实际已放开，需业务补签认或收回。
D-C：自动回执文案
「我已收到，将跟进处理」由 AI 发出，但系统内该反馈仍是 SUBMITTED。若文案让员工以为已在处理，实际无人跟进，会比不回复更伤信任。建议文案明确区分「已收到」与「已处理」，并保留人工正式回复为唯一结论。需产品拍板文案。
5. 外部输入催办（沿用既有 B 系列编号）
| # | 需要的输入 | 提供方 | 阻塞 |
|---|---|---|---|
| B12 | 制度库分类分级口径：1008 的 648 个文档按什么维度分类分级、谁是各类负责人 | 人力 + 业务 | R2-2，进而阻塞「回答精准」验收 |
| B13 | 空间划分口径（D-B） | 业务 + 人力 | R2-5、R3 |
| B14 | 24 位优秀生活顾问访谈产出：标准动作指南 + 标准应答话术（含「业主拒说楼栋号」类情绪化回应模板） | HRBP | 内容质量，非阻塞发布 |
| B15 | 每日简报投递对象、时间、渠道、重试规则 | 管理层 + 人力 | R4-4 |
| B3 | 仍未闭合：正式试点范围圈定（1–2 个住宅项目、≥20 名员工、≥1 名主管、窗口起止） | HR | 一切正式验收指标的分母 |
B3 自 2026-07-16 挂起至今未闭合，是既有计划里的最大阻塞，8/1 测试版若仍无试点范围，「快速验证效果」就没有度量对象。
6. 明确不做
- 不换 RAG 架构、不做「17 种搭建方式」选型对比。
- 不删已生产验证功能的代码或表，只隐藏入口。
- 不做自动化工单投递（会议明确暂缓，当前实现已符合）。
- 不把直通车简报扩成工单/多轮/SLA 系统。
- 不因短视频方向引入新的转码、播放进度或媒体数据模型，直到方向确认。
- 不把「已部署」写成「正式试点通过」——沿用既有四级口径（已实现／已部署／生产验证／规划中）。
7. 建议执行顺序
今天 → R1 原子发布（含 7b014765 追问修复）
∥ R2-1 补向量覆盖（纯技术，当天可完）
∥ 发出 B12/B13 催办（B12 是关键路径，越早越好）
↓
7/28-29 → R2-3 分类进检索 + R2-4 调参回归集
∥ R2-2 业务归类进行中（依赖 B12）
↓
7/30-31 → R2-5 政策独立入口 + R3 信息架构收敛
∥ R4-1 自动回执（依赖 D-C）
↓
8/1 → 测试版上线；R4-2/R4-3 简报按 B15 回复情况顺延
R5 短视频只交 1 条示范
R1 与 R2-1 无相互依赖，可并行。整个计划的关键路径是 B12 → R2-2 → 回答质量验收，不是任何一项开发任务。