111 lines
3.3 KiB
Markdown
111 lines
3.3 KiB
Markdown
# H5 用户端开发计划与决策记录
|
||
|
||
更新时间：2026-07-05
|
||
|
||
## 当前目标
|
||
|
||
H5 用户端先作为“千问千答”用户入口，优先验证用户提问和系统回答这条主链路。第一期降低使用门槛，用户不登录也能进入页面并发起提问。
|
||
|
||
当前 H5 不是后台管理页，也不是知识库生产工具；它是未来小程序/用户端的交互雏形。
|
||
|
||
## 一期范围
|
||
|
||
一期只保留：
|
||
|
||
- 免登录进入 H5。
|
||
- 展示问答聊天界面。
|
||
- 用户输入问题。
|
||
- 前端调用后端已审核可调用库。
|
||
- 展示答案、来源和边界提示。
|
||
- 保留“新问答”按钮，方便用户重新开始。
|
||
- 保留复制和答案反馈的前端交互骨架。
|
||
|
||
一期明确不展示：
|
||
|
||
- 登录入口。
|
||
- 微信授权入口。
|
||
- 会话记录页。
|
||
- “我的”个人中心。
|
||
- 用户资料、手机号、微信昵称等身份信息。
|
||
|
||
## 当前隐藏决策
|
||
|
||
登录功能、微信授权、会话记录和个人中心此前已经做了部分前端预留，但一期先隐藏。
|
||
|
||
原因：
|
||
|
||
- 一期先验证问答能力，不让登录流程阻断用户体验。
|
||
- 后端还没有正式用户体系、会话历史接口和微信 code 换登录态接口。
|
||
- 如果展示半成品登录/记录/我的，会让测试用户误以为这些能力已经可用。
|
||
- 用户端要先把“能问、能答、答案可靠”打磨清楚。
|
||
|
||
恢复条件：
|
||
|
||
- 后端有正式用户登录接口。
|
||
- 后端支持微信授权登录或小程序登录。
|
||
- 后端支持用户会话保存和历史查询。
|
||
- 后端支持反馈入库。
|
||
|
||
## 当前接口绑定
|
||
|
||
H5 当前只适合直接绑定：
|
||
|
||
```http
|
||
GET /api/standard-qa/callable
|
||
```
|
||
|
||
这个接口只返回：
|
||
|
||
- 已审核标准问答。
|
||
- 已标记可调用。
|
||
- 低/中风险。
|
||
- 已脱敏或无需脱敏。
|
||
|
||
H5 不应该直接使用后台审核、编辑、任务、飞书、日志类接口。
|
||
|
||
## 后续后端方向
|
||
|
||
中长期不建议 H5 直接拉取全部可调用库并在前端匹配。更合理的结构是后端新增智能体接口：
|
||
|
||
```http
|
||
POST /api/h5/chat
|
||
```
|
||
|
||
后端智能体负责：
|
||
|
||
- 接收用户问题。
|
||
- 做风险初筛。
|
||
- 从标准问答可调用库中检索相关知识。
|
||
- 组装提示词。
|
||
- 调用大模型 API。
|
||
- 返回自然语言答案、来源、边界和命中状态。
|
||
- 保存会话和反馈。
|
||
|
||
H5 只负责：
|
||
|
||
- 输入问题。
|
||
- 展示答案。
|
||
- 展示来源和风险边界。
|
||
- 收集反馈。
|
||
- 管理用户交互状态。
|
||
|
||
## 后续建议开发顺序
|
||
|
||
1. 后端新增 `POST /api/h5/chat`。
|
||
2. 后端新增智能体 prompt 和知识库检索模块。
|
||
3. H5 从直接调用 `/standard-qa/callable` 改成调用 `/h5/chat`。
|
||
4. 后端新增用户会话和消息表。
|
||
5. H5 恢复会话历史页。
|
||
6. 后端新增反馈入库接口。
|
||
7. H5 恢复点赞、点踩、没解决等反馈入库。
|
||
8. 后端新增微信登录或小程序登录。
|
||
9. H5 恢复登录入口和“我的”页。
|
||
|
||
## 风险提醒
|
||
|
||
- 不要让 H5 使用未审核、不可调用、高风险或未脱敏内容。
|
||
- 不要让前端长期承担检索和风控职责。
|
||
- 大模型回答必须有明确边界，不能伪装成院长或老师原话。
|
||
- 医疗、法律、心理诊断、极端风险问题必须有兜底策略。
|
||
- 登录和历史记录上线前，要先确认隐私说明和数据保存规则。
|