131 lines
6.7 KiB
Markdown
131 lines
6.7 KiB
Markdown
# 工作上报语音会话化开发 Agent Prompt
|
||
|
||
将下面整段 Prompt 交给负责“工作上报”的开发 Agent。该任务与个人助理开发并行时，工作上报 Agent 只负责本文列出的文件，不修改 `mobile-uni/src/pages/user/sop/index.vue` 或个人助理后端包。
|
||
|
||
---
|
||
|
||
你正在 `/Users/yuanjiantsui/dev/11-project/wygj` 开发银城员工端 APP 的“工作上报”。请直接完成实现、测试和视觉验证，不要只输出方案。
|
||
|
||
## 必读事实源
|
||
|
||
1. `AGENTS.md`
|
||
2. `docs/20260708/数字师傅学练问报整合方案.md` §1.3.4
|
||
3. `docs/物业AI人力资源系统业务需求文档BRD.md` §4.6
|
||
4. `docs/物业AI人力资源系统开发规格TechSpec.md` §5.3.1–5.3.2
|
||
5. 高保真基准：`docs/prototypes/work-report-voice-conversation-v1.png`
|
||
|
||
设计图只约束结构和视觉方向。若图中存在“文字已经显示但仍写转文字”“承诺自动隐藏房号”“类型看似已审核”“继续补充入口重复”等问题，以 TechSpec §5.3.2 为准。
|
||
|
||
## 目标
|
||
|
||
把当前 `mobile-uni/src/pages/user/report/index.vue` 的传统表单主路径改成适合物业一线员工的微信式会话：
|
||
|
||
`语音/文字/照片/视频 → AI 整理 → 必要时追问 → 可编辑确认卡 → 用户确认上报 → 原审核链 → 会话内状态`
|
||
|
||
保留现有 `aihr_work_report`、附件上传、我的上报和主管审核，不创建第二套正式记录或草稿表。
|
||
|
||
## 文件所有权
|
||
|
||
主要允许修改：
|
||
|
||
- `mobile-uni/src/pages/user/report/index.vue`
|
||
- `mobile-uni/src/services/work-report.ts`
|
||
- `mobile-uni/tests/work-report.test.mjs`（新建或扩展现有契约测试）
|
||
- `backend/ruoyi-modules/ruoyi-aihr/src/main/java/org/dromara/aihr/report/*`
|
||
- 对应的 `backend/ruoyi-modules/ruoyi-aihr/src/test/**/report/*`
|
||
|
||
优先直接复用，不要复制或重写：
|
||
|
||
- `mobile-uni/src/components/chat/ChatComposer.vue`
|
||
- `mobile-uni/src/services/speech.ts`
|
||
- 现有 OSS、登录态、模型配置和 JSON 结构化输出能力
|
||
|
||
不要修改：
|
||
|
||
- `mobile-uni/src/pages/user/sop/index.vue`
|
||
- `org.dromara.aihr.personal` 或个人助理相关 SQL/文档
|
||
- 企业知识检索与短会话实现
|
||
|
||
多人共享工作区，不要回滚或覆盖其他 Agent 的改动。
|
||
|
||
## 后端要求
|
||
|
||
1. 保留现有接口：
|
||
- `POST /api/aihr/work-report/attachment`
|
||
- `POST /api/aihr/work-report/reports`
|
||
- `GET /api/aihr/work-report/reports/mine`
|
||
- `GET /api/aihr/work-report/reports`
|
||
- `POST /api/aihr/work-report/reports/{id}/review`
|
||
2. 新增登录态无状态整理接口：
|
||
|
||
```text
|
||
POST /api/aihr/work-report/organize
|
||
req: { transcript, currentDraft?, attachmentOssId?, attachmentName? }
|
||
resp: { suggestedType, title, content, missingQuestions[], privacyWarnings[], confidence }
|
||
```
|
||
|
||
3. `organize` 只返回草稿，绝不能写 `aihr_work_report`、创建审核记录或自动入知识库。
|
||
4. 复用现有 chat 模型运行时，要求结构化 JSON；模型未配置、超时或 JSON 解析失败时，不编造事实，返回基于原始转写的可编辑草稿和明确降级提示。
|
||
5. `suggestedType` 只能是 `CASE / VIDEO / SOP / KNOWLEDGE`。正式提交继续由现有 `create` 做白名单、标题/正文长度和 `VIDEO` 附件校验。
|
||
6. `privacyWarnings` 只提示检测到的姓名、手机号、房号等风险，不得宣称已经脱敏。没有真实服务端脱敏就不要返回“提交后会自动隐藏”。
|
||
7. 所有接口继续从登录态解析租户、用户和权限，不接受客户端提交人身份；附件不返回公开 OSS URL。
|
||
8. 审核通过仍只更新 `APPROVED`，不自动写案例库/知识库、不自动计分。
|
||
|
||
## 移动端要求
|
||
|
||
1. 页面标题“工作上报”，右上角“我的上报”。首屏不出现四类选择网格、标题输入框或大段说明表单。
|
||
2. 复用 `ChatComposer`，默认“按住说话”，键盘为次级切换，支持图片/视频/音频附件。
|
||
3. 用户语音经 ASR 后显示“语音转文字”气泡；整理接口根据当前草稿和补充内容生成下一版草稿。
|
||
4. `missingQuestions` 非空时只展示最必要的 1–2 个追问，不生成可提交状态。
|
||
5. 短追问直接显示文字并提供播放按钮；长回答才使用“语音条 + 转文字/收起文字”。文字已经可见时不得继续显示“转文字”。
|
||
6. 确认卡展示：建议类型、标题、场景/经过、处理、结果、附件、隐私提示。建议类型必须可修改，正式提交使用员工最后确认值。
|
||
7. 卡片只保留“修改 / 确认上报”。继续补充统一使用底部语音/文字输入，可显示弱提示“还可以继续说话补充”。
|
||
8. 隐私提示必须真实：未实现服务端脱敏时写“检测到具体房号，请修改后再提交”，确认卡展示的就是即将提交的最终文本。
|
||
9. 点击“确认上报”后才调用 `POST /reports`；成功在会话中显示 `PENDING / 待审核` 状态卡，并能从“我的上报”读取同一记录。
|
||
10. 模型失败、ASR 失败、上传失败、重复点击和未登录都要有明确可恢复状态，不使用假数据。
|
||
|
||
## 最小测试
|
||
|
||
后端至少覆盖：
|
||
|
||
- 整理接口不写数据库。
|
||
- 非法类型被拒绝或归一化为允许值。
|
||
- 模型失败不编造内容。
|
||
- 未登录 401、跨租户不可见、普通员工不能审核。
|
||
- 正式提交幂等防重复点击（若现有接口尚无幂等，增加最小请求幂等键并测试）。
|
||
|
||
移动端至少覆盖：
|
||
|
||
- 页面默认语音模式且不再呈现传统表单主路径。
|
||
- 文字追问可见时不存在“转文字”按钮。
|
||
- “建议类型”可修改，提交使用修改后的类型。
|
||
- 未实现脱敏时不存在“提交后自动隐藏”承诺。
|
||
- 只有一个继续补充入口，确认前不调用正式提交接口。
|
||
|
||
运行：
|
||
|
||
```bash
|
||
npm --prefix mobile-uni run test:unit
|
||
npm --prefix mobile-uni run typecheck
|
||
npm --prefix mobile-uni run build:h5
|
||
mvn -f backend/pom.xml -pl ruoyi-modules/ruoyi-aihr -am test
|
||
```
|
||
|
||
## 视觉与交互验证
|
||
|
||
启动真实 H5，在 390×844 视口完成并截图：
|
||
|
||
1. 初始语音输入。
|
||
2. 带照片/视频的用户消息。
|
||
3. AI 追问。
|
||
4. 完整确认卡。
|
||
5. 修改建议类型。
|
||
6. 确认后待审核状态。
|
||
7. “我的上报”可见同一记录。
|
||
|
||
检查固定输入栏不遮挡确认按钮，无横向滚动、文字截断、重复入口和虚假脱敏文案。截图不是功能验证的替代，必须实际点击受影响交互。
|
||
|
||
## 完成口径
|
||
|
||
分别报告：implemented、locally verified、visually verified、deployed、production-verified。没有真实生产账号、真实附件和线上审核链验证时，不得写 production-verified。提交时只暂存你负责的文件，使用 Conventional Commit，并给出提交哈希、测试结果、截图路径和未完成项。
|