emoon-portal/docs/p0-mobile/01-product-definition.md

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 替换真实接口而不推翻前端入口？