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