admin/prop-ai-hr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
15282db6219ca80d49c258e8da017d550ba40ba2
prop-ai-hr/docs/工作助手与今日工作成果迭代计划-20260721.md
T

32 KiB
Raw Blame History

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

版本：v1.5 日期：2026-07-21 状态：迭代 0-4 已实现、提交并部署；目标测试、真实 HTTP、390×844 视觉交互及生产真实员工账号主链路已验证，真机媒体和外部正式接口仍待验收 适用范围：员工端工作助手、今日工作成果、主管项目视图、成果投稿及后续外部流转 v1.5：在 v1.4 基础上补记生产发布、真实账号回归和生产截图；确认卡改为优先展示 AI 识别结论，再由用户向下查看并执行保存动作。

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

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

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

已裁决的矛盾：

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

1. 目标与边界

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

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

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

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

1.1 功能名称收敛

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

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

1.2 业务链路

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 在现有「问 · 数字师傅」页面内渐进完成，不新建第二套工作助手界面：

工作助手项目上下文与今日成果高保真基准

权威资产路径：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/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 显示记录人数、成果人数、待跟进、高优问题和员工来源类型；非文字记录可打开受保护原始来源

绝对目录：/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 和 §1.4。顶部项目选择器和大尺寸底部面板已实现；运行截图见 §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 和 §1.4。确认卡的项目、日期、来源和业务状态已实现；文字巡检的最终生产截图见 §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 和 §1.4。工作助手摘要入口、员工详情页和主管项目视图均已本地实现并完成 390×844 验证，运行截图见 §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、主管正式账号回归、外部线索/工单/考勤投递与回执。

9. 推荐施工顺序

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

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

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

Reference in New Issue View Git Blame Copy Permalink