# 01｜产品定义与 P0 范围

## 1. 产品命名

| 使用场景 | 名称 |
|---|---|
| 患者可见正式名称 | 医梦患者智能服务门户 |
| 公司内部项目代号 | Adjutant |
| 历史名称 | 统一入口客户端、医梦门诊助手 |

患者界面不出现 `Adjutant`、Agent、Workflow、FastGPT、MCP 等内部术语。

## 2. 产品定位

医梦患者智能服务门户不是智能体启动器，也不是全屏聊天机器人。

它是：

> 一家医院面向患者提供的移动端智能就医服务门户。它以医院上下文和患者当前任务为中心，用固定产品骨架承载传统服务与智能服务，并通过统一助手、服务入口和业务记录调用后端智能体能力。

### 产品前台关注

- 患者现在需要完成什么；
- 医院现在能为患者提供什么；
- 患者如何开始、继续或回看一项服务；
- 医疗风险出现时，患者下一步应该怎么做。

### 产品后台关注

- 当前医院开通了哪些能力；
- 每个入口对应哪个 `capabilityCode`；
- 背后由 FastGPT、自研 Agent、Mock MCP 还是医院真实接口执行；
- 任务如何记录、恢复、失败和降级。

## 3. P0 目标用户和环境

### 目标用户

- 使用指定医院移动端 H5、小程序或 App Demo 的患者；
- 演示时默认使用固定 Mock 患者本人；
- 不要求患者理解医疗智能体或技术平台。

### 使用环境

- 单家指定医院；
- 单医院品牌和服务配置；
- 无需登录即可演示；
- 固定 Mock 患者；
- 挂号和报告能力使用 Mock MCP；
- 舌诊使用现有成熟 MCP；
- 数据只用于演示，不代表真实院内数据。

## 4. P0 必须完成的三项智能服务

| 能力编码 | 患者可见默认名称 | 核心价值 | P0 执行方式 |
|---|---|---|---|
| `SMART_REGISTRATION` | 智能分诊挂号 | 描述症状、识别急症风险、推荐科室并完成模拟挂号 | FastGPT + Mock HIS/MCP |
| `TCM_TONGUE_ASSESSMENT` | 中医舌诊 | 完成体质/症候问答、上传舌象并获得综合评估 | FastGPT + 现有舌诊 MCP |
| `REPORT_INTERPRETATION` | 报告智能解读 | 上传检验或检查报告，获得结构化解释与行动建议 | FastGPT + Mock Report MCP + 知识库 |

## 5. P0 功能范围

### 必须包含

- 单医院品牌头部；
- 固定 Mock 患者提示；
- 首页三项智能服务入口；
- 统一助手文字输入；
- 语音入口的可发现状态（可使用预设文本模拟语音结果）；
- 报告/舌象图片上传入口；
- 服务中心；
- 三个独立任务流程；
- 任务进行中、等待用户、处理中、完成、失败状态；
- 最近任务和结果回看；
- 急症风险、报告风险等安全提示；
- Mock/演示环境标识；
- 工具失败后的重试、返回和人工建议。

### 可以简化

- “我的”页面只展示固定 Mock 患者、医院信息、隐私与演示说明；
- 首页待办由 Demo Fixtures 生成；
- 报告历史只展示预置报告和本次上传记录；
- 语音识别可以只模拟转写结果；
- 支付只做 Mock 成功/失败；
- 院区、科室、医生和号源使用预置数据。

## 6. P0 明确不做

- 用户注册、登录、实名认证；
- 家庭成员和代办；
- 多医院切换；
- 跨医院健康档案；
- 真实 HIS、LIS、EMR 或支付接入；
- 医生端、护士端和运营后台；
- 自动诊断、自动开方或治疗决策；
- 正式急诊分级；
- 完整语音对话；
- 医院自由设计任意页面；
- 让大模型动态生成任意 HTML/UI；
- 所有未来智能体的通用市场或应用商店。

## 7. P0 产品原则

### 7.1 患者看到“服务”，不是“智能体”

使用：

- 不知道挂什么科？描述症状并预约；
- 看不懂报告？上传后获得结构化解读；
- 想了解中医体质？完成问答并拍摄舌象。

不使用：

- 调用挂号 Agent；
- 进入报告 Workflow；
- 连接舌诊 MCP。

### 7.2 可发现入口与自然语言入口并存

仅靠对话会让患者不知道系统能做什么；仅靠功能卡又无法处理模糊需求。

P0 首页必须同时提供：

- 三项清晰的服务入口；
- 一个“描述症状或告诉我想办理什么”的统一助手入口。

### 7.3 统一助手只负责路由，不承载无限混合会话

统一助手识别意图、执行安全前置判断并确认服务后，切换到具体任务页面。三个任务拥有独立状态和结果。

### 7.4 智能体负责理解，标准组件负责确认

- 对话：表达症状、补充信息、解释结果；
- 表单：体质问答、病史、时间偏好；
- 卡片：科室、医生、号源、异常指标、舌诊结果；
- 确认页：患者归属、挂号、上传、支付；
- 结果页：可回看、可继续、可追踪。

### 7.5 医疗安全优先于原意图

如果患者说“胸痛、呼吸困难，想挂明天心内科”，系统必须先进入急症风险筛查，而不是直接开始挂号。

### 7.6 P0 是可执行的业务原型

P0 用于：

- 熟悉和确认业务流程；
- 对外演示；
- 明确后续需要的医院接口；
- 为 P1 架构抽取提供输入。

P0 不等于生产系统，也不应把事务一致性、医院差异适配、语义标准化等全部堆进 FastGPT。

## 8. 成功标准

P0 验收通过时，必须能回答“是”：

1. 首次进入的患者能在 10 秒内找到三项服务吗？
2. 患者用自然语言表达需求时，能正确进入对应任务吗？
3. 三个入口是否调用同一套能力，而不是维护多份流程？
4. 三个任务是否都能跑通正常和至少一个异常场景？
5. 患者是否始终知道当前任务、当前步骤和下一步？
6. 风险提示是否能打断普通业务流程？
7. 任务中断后是否能从首页或健康记录继续？
8. 结果是否能独立回看，而不是只存在聊天历史？
9. Mock 数据和正式医疗结论的边界是否清晰？
10. 当前设计是否能在 P1 替换真实接口而不推翻前端入口？