# 06｜实施边界、开发顺序与验收

## 1. 现有工程与目标工程的差距

| 维度 | 当前工程 | P0 目标 |
|---|---|---|
| 终端 | 桌面自助终端，最小宽度 1280px | 360–430px 移动端优先 |
| 布局 | 左侧助手 + 中间对话 + 右侧任务卡 | 首页 + 独立任务页 + 底部导航 |
| 能力 | 单挂号流程 | 挂号、报告、舌诊 |
| 入口 | 输入一句话开始挂号 | 服务卡、统一助手、待办/记录 |
| 状态 | 单活动卡片 | 多任务记录、创建/恢复/完成 |
| 结果 | 对话内卡片 | 独立结果详情 + 健康记录 |
| 数据 | 挂号 Demo Fixtures | 三项服务 Fixtures + 现有舌诊 MCP |
| 品牌 | 医梦门诊助手 / 统一入口客户端 | 医梦患者智能服务门户 |

## 2. 可以复用的现有资产

- `src/api/sse.ts`：流式事件解析思路；
- `src/api/types.ts`：卡片与任务类型基础；
- `src/state/terminalStore.ts`：消息、任务、卡片和 Demo 状态处理经验；
- `src/cards/`：挂号业务卡片；
- `src/api/demoFixtures.ts`：挂号 Mock 数据；
- `src/theme/tokens.css`：品牌颜色、字体、间距、圆角；
- 挂号单元测试和 E2E 流程。

## 3. 不建议直接沿用的结构

- `AppShell.vue` 的三栏固定布局；
- `html/body/#app` 的 `min-width: 1280px`；
- 以 `activeCard` 为中心的单任务页面模型；
- 左侧静态助手身份区；
- 右侧上下文面板；
- 所有能力都从一个聊天框启动的假设；
- 卡片只服务挂号流程的命名和映射。

## 4. P0 建议路由

```text
/
/services
/records
/me
/assistant
/tasks/:taskId
/tasks/:taskId/result
```

任务页根据 `capabilityCode` 和标准 UI Schema 渲染，不建议为 FastGPT App ID 建路由。

## 5. 建议前端模块

```text
src/
├── app/
│   ├── router/
│   └── portalStore.ts
├── portal/
│   ├── HomePage.vue
│   ├── ServiceCenterPage.vue
│   ├── HealthRecordsPage.vue
│   └── MePage.vue
├── assistant/
│   ├── UnifiedAssistantPage.vue
│   └── intentRouter.ts
├── tasks/
│   ├── TaskPage.vue
│   ├── TaskResultPage.vue
│   ├── taskStore.ts
│   └── renderers/
├── components/
│   ├── entry/
│   ├── form/
│   ├── medical/
│   ├── task/
│   └── navigation/
├── api/
│   ├── portal.ts
│   ├── task.ts
│   └── mock/
└── theme/
    └── tokens.css
```

这只是职责建议，不要求本轮立即重构全部代码。

## 6. P0 能力配置

```json
{
  "hospital": {
    "hospitalId": "DEMO_HOSPITAL_001",
    "displayName": "空海医院",
    "portalName": "医梦患者智能服务门户"
  },
  "patient": {
    "operatorId": "DEMO_USER_001",
    "subjectPatientId": "DEMO_PATIENT_001",
    "relationType": "SELF",
    "displayName": "王*明",
    "mock": true
  },
  "capabilities": [
    {
      "capabilityCode": "SMART_REGISTRATION",
      "displayName": "智能分诊挂号",
      "placements": ["HOME", "SERVICES", "ASSISTANT", "RECORDS"],
      "enabled": true
    },
    {
      "capabilityCode": "REPORT_INTERPRETATION",
      "displayName": "报告智能解读",
      "placements": ["HOME", "SERVICES", "ASSISTANT", "RECORDS"],
      "enabled": true
    },
    {
      "capabilityCode": "TCM_TONGUE_ASSESSMENT",
      "displayName": "中医舌诊",
      "placements": ["HOME", "SERVICES", "ASSISTANT", "RECORDS"],
      "enabled": true
    }
  ]
}
```

## 7. 建议开发顺序

### 阶段 1：门户骨架与入口

- 移动端响应式基础；
- 首页、服务、健康记录、我的；
- 三项服务配置；
- 统一助手到具体任务的切换；
- 通用任务创建和恢复。

退出标准：三项服务都能从服务卡、统一助手和记录入口打开正确任务。

### 阶段 2：挂号任务迁移

- 复用现有挂号卡片和 Mock 数据；
- 增加两种开始方式；
- 增加急症风险筛查；
- 将桌面右侧卡片改为移动端任务块；
- 完成结果写入健康记录。

退出标准：正常挂号、急症打断、号源失败三条路径可演示。

### 阶段 3：报告解读

- 上传/示例报告；
- OCR 与类型识别 Mock；
- 血常规/血小板知识模块；
- 1～2 类检查报告；
- 风险卡与结构化结果；
- 写入健康记录。

退出标准：血常规正常解读、风险提示、图片识别失败可演示。

### 阶段 4：中医舌诊

- 服务说明；
- 分组问答；
- 问答保存与恢复；
- 拍摄指导；
- 接现有 MCP；
- 组合结果与记录。

退出标准：完整成功、图片不合格、MCP 失败重试可演示。

### 阶段 5：统一走查

- 390 × 844 主视口；
- 360 × 800 紧凑视口；
- 430 × 932 大屏移动端；
- 三项服务互不污染状态；
- 返回、退出、恢复、完成逻辑一致。

## 8. P0 必测剧本

### 正常场景

1. 首页点击智能分诊，输入“头疼三天伴恶心”，完成 Mock 挂号；
2. 首页上传血常规，得到血小板专题结构化解读；
3. 首页进入舌诊，完成问答、上传合格图片并获得综合结果；
4. 统一助手输入三种自然语言，分别进入正确任务；
5. 从健康记录回看三种完成结果。

### 异常场景

1. “胸痛、呼吸困难”中断普通挂号并进入急症提示；
2. 号源锁定失败后重新查询，不丢失前置信息；
3. 报告模糊，给出具体重传原因；
4. 报告触发 Mock 风险规则，风险卡置顶；
5. 舌象未完整入镜，要求重拍；
6. 舌诊 MCP 失败，保留问答并可重试；
7. 中途返回首页后，从待办继续任务。

## 9. 产品验收清单

- [ ] 对外名称全部统一为“医梦患者智能服务门户”；
- [ ] 内部文档可使用 `Adjutant`，患者界面不出现；
- [ ] 首页首屏能发现三项智能服务；
- [ ] 统一助手能路由三项服务；
- [ ] 服务确认后切换为独立任务；
- [ ] 三个任务都有步骤、保存、恢复、失败和完成；
- [ ] 任务结果进入健康记录；
- [ ] 急症和报告风险能够打断普通流程；
- [ ] 所有 Mock 事务和规则清楚标识；
- [ ] 无登录也能完成全部 P0 演示；
- [ ] 仍预留 `operatorId` 与 `subjectPatientId`；
- [ ] 移动端无横向滚动；
- [ ] 主按钮和关键控件触控区域不小于 44px；
- [ ] 不使用“确诊、自动诊断、保证准确”等越界文案。

## 10. 设计交付物

进入前端开发前，产品设计至少补齐以下高保真/可点击页面：

1. 首页；
2. 服务中心；
3. 统一助手；
4. 服务确认卡；
5. 挂号任务开始页；
6. 急症风险页；
7. 科室推荐页；
8. 医生号源页；
9. 挂号结果页；
10. 报告上传页；
11. 报告结果页；
12. 舌诊服务说明页；
13. 体质问答页；
14. 舌象拍摄页；
15. 舌诊结果页；
16. 健康记录页；
17. 通用失败/重试状态。

## 11. P0 到 P1 的演进边界

P1 再增加：

- 登录、实名认证；
- 家庭成员和代办；
- 真实 HIS/LIS/EMR 接入；
- 院内报告读取；
- 医院实际挂号/支付策略；
- 医院知识包和风险规则；
- 能力开通与灰度配置；
- 统一 Agent Gateway、审计和权限。

P0 结束后不是把 FastGPT 流程逐节点翻译成代码，而是做一次架构抽取：

```text
P0 业务原型
→ 提取可复用任务状态与 UI 组件
→ 区分 FastGPT 编排、Runtime、语义知识、MCP/Adapter
→ 决定 P1 的真实项目接入方式
```

## 12. 资料依据

- [当前工程 README](../../README.md)
- [当前视觉令牌](../../src/theme/tokens.css)
- 医梦内部知识库：统一入口客户端
- 医梦内部知识库：智能体平台
- 医梦内部知识库：报告解读智能体
- 医梦内部知识库：急症风险筛查
- 历史原始方案：统一入口客户端技术设计

> 知识库相关页面目前多为候选状态；医疗规则、医院接口和对外承诺在 P1 前仍需人工与医院确认。