AI 时代医疗产品演进方向与研发建议
研发视角讨论稿｜2026 年 10 月 15 日更新
面向产品、研发与架构团队，围绕传统医疗应用、专病科研与辅诊、自有 C 端和具身智能体，提供未来产品演进与能力建设参考。
一 现状背景与产品演进目标
目前面临的背景是：新增交付项目减少，存量项目维护成本不断增加，部分项目收益逐步转负。 从研发视角，需要关注产品为什么越来越难维护、哪些能力值得复用，以及如何通过效率与质量的提升，为持续服务和增值创造条件。
传统应用承担稳定的业务记录、规则执行、权限控制和系统集成；AI 处理非结构化信息、辅助判断；Agent（智能体）在授权范围内调用工具，协助完成多步骤任务。这些能力可以在现有产品中逐步融合，让系统更易使用、更可靠，也更容易维护和扩展。
未来可探索相互支撑的产品方向：面向机构的专病科研和临床辅助，面向个人与家庭的连续健康服务，以及面向居家与养老的具身智能体。通用技术和经审核的知识可以复用，各场景保留独立的数据权限、质量要求和服务边界。
以下建议用于产品与技术方向讨论。研发可通过场景原型、架构设计、质量评价和成本数据，为产品价值及商业可行性判断提供依据；具体选择结合现有产品基础、专业合作条件和验证结果逐步形成。
图 1：传统应用提供业务基础，AI 与 Agent 在此基础上扩展能力。
二 现状分析与研发问题
持续维护压力来自哪些产品问题
一次性建设完成后，接口变更、政策适配、数据修复和流程调整仍会持续发生。逐院定制和人工支持较多时，新增客户往往伴随更多版本差异与维护工作。需要结合实际工单、代码分支、接口和升级记录，识别研发侧能够改善的原因。
| 可能问题 | 研发侧可观察的现象 | 对应优化方向 |
|---|---|---|
| 共性能力重复建设 | 相似需求在多个项目分别开发和修复 | 提炼标准模块，复用实现与测试 |
| 定制版本和接口过多 | 独立分支多，升级和适配工作重复 | 配置化、扩展机制与标准接口 |
| 产品质量或可维护性不足 | 重复故障、人工修数、排障困难 | 根因修复、可观测性与质量改进 |
| 需求边界和影响不清楚 | 小变更牵动大量模块，维护与新增需求混杂 | 明确能力边界，提供影响与工作量分析 |
| 交付运维依赖个人经验 | 同类问题解决时长差异大，交接困难 | 知识沉淀、标准作业与工具辅助 |
上述问题与合同、服务范围及收入结构也有关。研发可提供工作量、复杂度和持续维护成本等事实，帮助相关团队判断问题来源；产品优化则重点解决重复建设、版本分化和质量负担。
从交付完成转向持续可维护
新院建设、系统替换和专项建设仍可能产生一次性交付需求。产品研发需要同时考虑上线后的升级、适配、故障处理和能力扩展，让每次交付尽量复用已有产品，而不是形成新的独立维护体系。
评价改造价值时，应同时看一次性迁移投入与后续维护负担。技术改造能否改善项目收益，还取决于实际服务范围和业务条件；研发可以先验证共性问题是否减少、升级是否更稳定、交付与排障是否更高效。
三 存量产品的可维护性与标准化
按产品差异识别改造机会
| 产品现状 | 研发关注点 | 可形成的能力 |
|---|---|---|
| 多个客户使用相似功能 | 共性实现与差异配置是否清楚 | 标准模块、配置模板和共享测试 |
| 项目依赖独立分支 | 差异能否通过扩展机制承载 | 版本收敛、兼容策略与迁移工具 |
| 接口与升级工作重复 | 数据规范、适配逻辑和错误处理是否一致 | 统一适配、接口校验与升级诊断 |
| 故障与人工修数频繁 | 是否存在跨客户重复根因 | 共性修复、数据校验和可追溯处理 |
| 旧产品迁移困难 | 业务连续性、数据兼容与回退条件 | 渐进迁移、验证工具和回退机制 |
这些信息可用于讨论产品改造优先级。涉及临床业务的迁移，需要在设计中考虑数据一致性、业务连续性和可回退能力，并结合实际使用方验证。
将一次改进复用到多个项目
可优先从高频、跨客户重复发生的问题入手，完善日志、告警、诊断信息和异常处理，将共性修复同步到适用版本。版本差异通过配置或可控扩展承载，接口适配尽量复用，减少为每个项目单独解决同类问题。
AI 可辅助工单归类、历史案例检索、日志摘要和升级影响分析。评价时要计入人工复核与返工时间，并持续解决根因，才能把回复效率的提升转化为维护工作量的下降。
新增功能的设计应说明适用场景、依赖条件、数据需求和维护影响。已有缺陷修复与新增能力分别描述，让产品团队能够清楚表达升级价值和服务范围。
图 2：标准化、根因修复与智能辅助共同改善产品可维护性。
四 传统产品的优化思路
传统应用的价值可以持续提升。优化的重点应落在稳定性、可维护性、操作效率、数据质量和跨流程协同上，AI 是其中可选的实现方式。
| 现有产品 | 常见改善机会 | 优先优化内容 | 可验证的客户价值 |
|---|---|---|---|
| HIS、EMR 等核心系统 | 重复录入、操作繁琐、数据缺项 | 简化流程、统一字段、规则校验；在适合处增加摘要或草稿辅助 | 录入时间、返工率、完整性与稳定性 |
| LIS、PACS 及接口服务 | 适配分散、数据传输故障、排障困难 | 标准接口、异常监控、统一诊断和升级方式 | 传输成功率、故障恢复时间、升级成本 |
| 随访与患者服务 | 名单整理、人工触达、异常追踪耗时 | 任务编排、渠道接入、结构化记录；增加文本理解与整理能力 | 有效触达率、漏访率、异常处理时间 |
| 运营与质量管理 | 报表分散、指标口径不一致、问题处理脱节 | 统一指标，连接分析、待办、处理与复核 | 分析耗时、问题处理完成率、质量缺陷变化 |
| 专病数据库与科研平台 | 文献分散、病例筛选费时、研究变量口径不一 | 建立专病知识库，辅助数据提取、队列筛选和研究过程管理 | 证据检索与核验时间、变量准确率、队列构建耗时 |
| 自有 C 端产品 | 服务零散、推荐相关性不足、问题难以持续处理 | 统一个人任务与服务进度，增加个性化管理、专业服务转接和家庭协同 | 问题解决、服务质量、周期留存、增值服务续费 |
产品优化可结合使用价值、复用程度和维护复杂度作取舍：优先完善核心能力，评估重复模块的合并方式，对使用少且维护重的功能分析调整影响。每项建议说明改善的用户指标、研发依赖和持续维护成本，为产品方向讨论提供依据。
五 AI 与 Agent 的场景选择
根据任务复杂度选择实现方式
明确、稳定的校验、计算和固定流程适合规则或传统程序；文档检索、摘要和草稿适合 AI 助手；需要根据上下文选择工具、调整执行步骤并推动后续任务的场景，可采用 Agent。模型处理文本与语义，规则和工作流约束其行动，业务系统保留正式记录。
Agent 的产品边界应具体到任务：可以读取哪些数据、调用哪些工具、写入哪些内容，哪些操作必须人工确认，以及失败后如何转回原有流程。对涉及诊疗的内容，人工复核、医学评价和相应准入评估属于产品成本与上线条件。
结合现有产品基础选择研发场景
| 场景 | 使用者与接入基础 | 产品能力 | 价值与成本验证 | 演进建议 |
|---|---|---|---|---|
| 内部交付运维助手 | 交付、运维与研发团队；工单、文档和诊断信息 | 工单归类、案例检索、日志摘要、排障建议 | 问题处理总工时、重复发生率、复核成本 | 可作为内部效率验证场景 |
| 病历完整性与质控助手 | 医生、病案和医务人员；病历与质控流程 | 规则检查、文本一致性提示、可追溯的修改建议 | 漏检与误报、审核总耗时、医生返工 | 有现有工作站入口时优先验证 |
| 出院随访 Agent | 科室、护理或患者服务人员；既有随访规则和渠道 | 随访任务、经批准的触达、回复整理、异常待办 | 有效随访、异常处置、人工总耗时、渠道成本 | 从一个已确认的管理流程切入 |
| 就医服务 Agent | 患者及客服；预约、导诊等业务接口 | 预约导诊、就医准备、流程提醒 | 任务完成率、人工转接、接口与服务成本 | 先验证工具调用与任务完成 |
| 专病科研知识库与科研助手 | 专科研究者；授权资料、专科专家与数据条件 | 文献证据检索、变量提取、队列筛选、研究材料整理 | 引用准确性、筛选漏检、数据质量、研究准备总耗时 | 以明确研究任务验证知识与数据能力 |
| 专病 AI 辅诊 | 专科医生；临床流程、专业知识与评价条件 | 病情汇总、证据检索、缺失信息提示及经验证的决策支持 | 临床评价、错误风险、审核负担及准入成本 | 先验证信息与证据辅助，再按用途验证临床功能 |
场景选择可关注已有数据和接口、用户任务频率、专业审核条件及技术复用价值。业务价值与付费意愿由产品及业务团队结合验证结果讨论，研发侧提供可行性、质量表现和持续成本依据。
出院随访 Agent 的产品边界
如果公司已有随访产品，可先从一个科室、一个已批准的随访方案切入。系统读取授权患者名单和既定随访任务，生成待确认的触达安排，通过医院批准的渠道执行，将患者回复整理成结构化草稿，并创建未回复或异常信息的待办。
医护人员审核医学内容和正式记录，按院内规则处理异常。首个版本只执行已批准的随访方案；超出方案的问题进入人工工作队列。产品必须指定异常接收人和响应机制，否则"发现异常"无法转化为实际服务质量。
医院评估有效随访和异常处置是否改善，人工准备、阅读与记录的总时间是否下降。公司评估接口配置、渠道、模型、培训和支持成本。两侧指标同时改善后，再扩展科室和病种。
政策方向与实际需求
2026 年的《国民健康"十五五"规划》强调服务质量效益和数智化转型，提出数据共享、县域医共体智能应用及辅助诊疗、健康管理等方向。该规划落款为 2026 年 7 月 7 日，国家发展改革委网页于 9 月 28 日发布。
2026 年 5 月发布的《智能体规范应用与创新发展实施意见》列出病历管理、预问诊、报告解析等医疗场景，并强调决策权限、行为管控和评测。2025 年 11 月发布的《关于促进和规范"人工智能+医疗卫生"应用发展的实施意见》提供了医疗行业的应用方向与治理要求。
这些政策支持产品探索。研发方向仍需落到真实任务、可获得的数据和可验证的效率与质量改善；政策支持可作为场景参考，具体产品价值需要结合实际使用验证。
六 专病科研知识库与 AI 辅诊产品方向
围绕专病建设可持续更新的产品
专病方向可以作为中长期产品增长线。以现有专病数据库、电子病历和科研平台为基础，把授权文献、临床数据和专家审定的知识组织起来，逐步形成知识检索、科研辅助、临床辅助和随访管理等可独立购买的能力。
建议从已有客户和合作专家所在的一个专科、一个病种切入，选择数据可获得、业务需求明确且具备专业合作条件的场景。先验证知识检索或科研准备的效率与质量，再扩展临床应用。知识库内容、数据接口和业务工具可以复用；科研与临床功能分别管理权限、评价标准和发布版本。
图 3：科研与辅诊复用知识基础，临床功能按用途独立验证。
专病知识库需要管理三类不同资产
| 资产 | 主要内容 | 建设与使用要求 |
|---|---|---|
| 医学证据知识库 | 诊疗指南、专家共识、药品说明书、公开或获授权文献 | 标注来源、发布日期、适用人群和证据性质；保留原文定位与更新记录，落实内容使用许可 |
| 专病科研数据库 | 经授权的病例、病理和影像报告、检查指标、治疗过程及随访结局 | 统一变量定义、单位、时间范围和缺失值处理；保留原始记录来源，按项目授权访问 |
| 科室经验与业务规则库 | 经审核的病例讨论、院内路径、研究变量字典和操作规范 | 专家审核、版本管理；明确本地经验与指南证据的区别，并标记适用范围 |
AI 可以辅助文献归类、信息提取、同义词整理和跨资料检索，输出仍需支持来源核验。模型引用了文献，也可能误解其结论；产品应展示支持该结论的具体段落，并提示证据冲突、内容过期和适用条件。知识库的验收要看答案与证据是否一致、内容是否持续更新，以及医生完成任务的总时间是否下降。
科研助手连接研究准备与数据工作
科研助手可以嵌入现有科研平台，围绕研究者实际任务提供以下能力：
- 文献与证据整理。 根据研究问题辅助检索和筛选文献，提取研究设计、人群、结局及局限，形成可逐条回查的证据表。需要系统综述时，由研究者确认检索策略与纳排过程，不能把通用问答结果视为完整检索。
- 研究方案准备。 协助整理研究背景、纳排条件、变量清单和数据采集表草稿，由研究者及方法学人员确认设计与分析方案。
- 变量提取与队列筛选。 从授权病历中提取候选变量、构建病程时间线，按研究条件筛选候选病例；展示筛选理由和原始记录，复核遗漏及误纳情况。
- 分析准备与项目跟踪。 检查单位、缺失值和数据一致性，生成待确认的分析计划，提醒随访和资料补充。统计结果由可复现的计算流程产生，保留数据版本、代码和人工确认记录。
客户购买的是研究准备、数据治理和项目执行能力。验收指标应采用证据核验准确性、变量提取质量、队列筛选表现和人工总耗时，论文数量、课题获批或研究阳性结果不宜作为产品承诺。
在这些工具成熟后，科研 Agent 可按研究者确认的任务计划，串联文献检索、变量提取、候选队列复核和分析工具调用，并记录每一步输入与结果；研究设计、入组确认和结论解释保留研究者确认节点。
AI 辅诊嵌入医生工作流程
AI 辅诊可沿着三个层次逐步推进：先提供病情摘要和病程时间线，再提供患者相关的指南证据与缺失信息提示，最后对特定临床用途开展验证，形成相应的决策支持能力。各层次都应嵌入医生工作站或专病管理界面，减少切换和重复录入。
在完成相应用途验证与准入评估后，可进一步提供辅助鉴别诊断、必要检查提示、诊疗路径比对和用药风险提示等功能。每项提示展示患者依据和医学证据，并由医生结合实际情况确认；评价时既看遗漏是否减少，也看误报和审核负担是否可接受。
例如，在一个肿瘤专科场景中，科研助手可整理授权病例的病理、影像报告、治疗过程和随访结局，辅助构建候选队列；医生端可在多学科讨论前生成待审核的病情摘要，并定位相关指南条目。文献结论、患者事实和模型推测需要明确区分，资料不足时提示缺项，由医生确认临床判断与正式记录。
相似病例检索可用于学习和研究线索，不能单凭相似性认定治疗有效。研究发现进入临床知识库前，应经过证据评价、专家审核及相应验证；不能让模型自动把院内探索性结果转为诊疗规则。
模块化能力与持续服务价值
| 产品模块 | 潜在采购与使用方 | 首次交付 | 可持续购买的内容 |
|---|---|---|---|
| 专病知识库 | 专科、科研部门、图书或信息部门，按院内职责确认 | 内容接入、知识整理、权限和检索配置 | 合同约定的内容更新、授权、检索服务和质量评估 |
| 科研助手与队列工具 | 科研团队、科研管理部门 | 数据字典、接口、提取与筛选流程 | 软件服务、适用用量、数据质量及项目管理支持 |
| 专病 AI 辅诊 | 专科、医务及信息部门 | 工作站接入、临床工作流配置及相应用途验证 | 经验证版本的服务、知识更新、运行监测与评估 |
研发可将文献许可、医学专家审核、数据治理、模型、验证和支持工作纳入能力与成本评估。共性知识处理与软件能力尽量复用，客户特有的接口、流程和研究配置明确边界。数据访问、处理与输出按授权设计，为后续产品与服务方案提供清晰的能力范围。
专病产品的持续价值来自知识更新、数据质量、模型评测和业务适配。研发设计应体现这些持续工作，形成可复用、可维护的更新机制，帮助产品团队讨论长期服务价值；科研项目结束后的使用与服务条件需要业务侧进一步确认。
设置科研与临床各自的验证门槛
涉及人的研究数据使用，应由机构按适用要求完成伦理审查、知情同意或相应豁免程序判断；数据脱敏与研究伦理要求需分别评估。科研空间与临床空间应控制数据访问和内容发布范围。《涉及人的生命科学和医学研究伦理审查办法》
科研工具通过验收，不代表临床辅诊已经具备上线条件。影响诊疗判断的功能，应按实际预期用途评估相应准入、临床验证和持续监测要求。研发时可以复用基础能力，上线时分别验收。国家卫健委的《关于促进和规范"人工智能+医疗卫生"应用发展的实施意见》同时提出专病辅助诊疗和文献综述、研究方案、数据收集分析等科研智能应用，可据此组织产品方向，采购与收益仍需逐项验证。
七 自有 C 端产品的服务升级与用户价值
以服务质量和精准匹配提升用户粘性
自有 C 端产品可以成为用户持续获得健康服务的入口。用户粘性来自档案持续积累、建议符合自身情况、服务及时可靠，以及遇到问题时能够找到合适的人。产品应围绕用户的健康任务组织服务，让每次使用都能完成具体事情。
"精准"首先体现在服务匹配：根据用户明确授权的信息、健康目标、既有管理计划和使用反馈，提供适合的内容、提醒和服务。对诊断、风险预测及治疗相关的精准能力，需要相应医学证据和验证，不能仅凭用户画像或模型表达能力作出承诺。
图 4：围绕健康任务持续提供相关、可靠的服务。
| 优化方向 | 可建设的产品能力 | 用户价值与评价指标 |
|---|---|---|
| 服务质量 | 答案依据与适用条件、专业内容审核、问题转人工、服务进度查询 | 回答质量、问题解决率、人工接入及时性、投诉与返工 |
| 个性化与精准匹配 | 个人健康档案、目标管理、按既有方案提醒、可调整的服务偏好 | 推荐相关性、任务采纳、无关提醒及错误匹配比例 |
| 连续服务 | 检查资料整理、复诊准备、随访安排、阶段报告与计划复盘 | 资料准备效率、计划完成率、阶段服务留存 |
| 体验与信任 | 适老交互、可管理的记忆、授权撤回、清晰的费用与服务说明 | 首次任务完成率、满意度、退款与续费情况 |
专业端与个人端可以复用经过审核、适合公众理解的知识内容。个人端应使用用户能够理解的语言，解释资料不足和建议适用条件；院内病例、科研数据和用户健康档案按各自授权管理。
从一次咨询延伸到长期健康任务
建议优先服务已有用户中需求明确的人群，例如已有慢病管理计划的用户、出院后需要随访的人群，以及需要照护老人的家庭。先围绕一个场景，衔接"资料整理、任务计划、提醒执行、反馈记录、人工服务、阶段复盘"，再扩展人群。
例如，用户可在自有应用中整理本人检查报告，生成待核验的趋势记录和复诊问题清单，按已确认的计划记录指标、接收提醒；出现超出服务范围的问题时，转接具备相应资质的医疗服务。家属端在本人授权范围内查看共享信息和协助任务，付费购买服务不自动取得他人的全部健康信息权限。
医院、社区和养老机构可以成为合作渠道，但患者进入自有产品需要明确的服务安排和本人授权，不能将机构系统中的患者数据默认转作公司个人用户运营。
用明确权益设计增值服务
| 服务层 | 可提供的内容 | 收入方式与成立条件 |
|---|---|---|
| 基础服务 | 基础档案、健康知识、约定范围的资料整理与提醒 | 按产品定位提供基础权益，控制模型和支持成本 |
| 个人健康会员 | 更连续的记录整理、阶段报告、个性化任务管理与人工支持权益 | 月度或年度订阅；写清次数、服务时间、用量和续费规则 |
| 专病管理服务包 | 与合规服务方合作提供约定周期的随访、咨询和管理 | 按服务周期或明确项目收费，核算医护与运营投入 |
| 家庭照护服务包 | 经授权的家庭协同、老人服务报告、人工关怀与照护协调 | 家庭订阅或组合服务；适配实际联系人和照护关系 |
| 机构合作服务 | 医院、养老机构等为符合条件的用户购买服务 | 由机构采购或双方约定分担，分别核算渠道与履约成本 |
增值权益要对应持续、可验收的服务。若包含问诊等医疗服务，应由具备相应资质的机构和人员提供，并明确用户购买的是哪项服务、由谁负责交付。
评价用户价值与持续服务成本
按同一批用户跟踪首次任务完成、适当周期的复用、付费转化、续费与退款；慢病和照护产品尤其要看管理计划完成情况与服务质量。健康服务的合理使用频次因人而异，不能只用每日打开次数或聊天时长判断价值。
研发侧可关注模型用量、响应质量、人工转接和异常处理成本，结合产品团队反馈的留存与服务完成情况评估方案。用户信任、相关性和可兑现的服务共同支撑长期粘性；增值方案需要同时考虑技术能力与实际服务承载条件。
八 医疗具身智能体的探索方向
将居家感知与实际服务连接起来
医疗具身智能体可以作为中长期探索：通过终端感知用户状态和环境，在授权范围内执行提醒、交互、设备控制或经过验证的物理动作，并连接人工服务。C 端应用承担档案、账户、授权和服务管理，具身终端成为生活场景中的服务入口。
设备形态应随任务选择。早期可与现有智能终端、监测设备和机器人厂商合作，验证感知、交互和服务连接；有明确需求且完成相应验证后，再扩展移动操作等能力。软件公司的投入重点可放在医疗知识、任务组织、设备接入和运营服务。
图 5：具身健康服务概念示意；实际能力按设备和用途验证。
从健健的设定提炼产品能力
以《灵笼》中健健的设定作为产品构思参考，可以借鉴其一体化医疗服务入口：用户表达需求后，终端组织信息、连接检测与专业服务，并协助完成后续任务。以下为基于用户提供设定的产品映射，动漫情节不作为现实技术能力的依据。
| 设定中的能力 | 可借鉴的产品设计 | 现实落地条件 |
|---|---|---|
| 面向普通人的医疗向导 | 用自然交互承接需求，连续办理咨询、导诊、预约和后续服务 | 接入真实业务系统，核验任务是否完成，失败时交接人工 |
| 人体与伤情扫描 | 将问询、适用设备的测量结果、历史资料组织为待核验的信息，按经验证的用途提示风险 | 每种检测依托对应设备和验证；影像、感染或义肢状态等判断需专门能力，不能承诺通用扫描即可完成 |
| 药品仓库导航 | 连接院内导航、药房位置、服务时间和库存信息，帮助用户找到正确服务点 | 地图与库存持续更新；涉及处方及调配的环节由相应系统和人员审核 |
| 挂号缴费等自助办理 | Agent 在授权范围内调用预约、身份和支付工具，展示结果并保存凭证 | 敏感信息按任务需要采集，关键交易确认，处理失败与重复提交 |
| 仿生义肢咨询 | 延伸为康复与辅具知识、适配服务预约、维护提醒和售后指引 | 与专业机构或设备厂商合作，区分一般咨询与专业评估 |
| 接入全域 AI 的独立终端 | 多个终端共享经审核的知识、服务目录和工具能力，按机构与用户分别授权 | 数据隔离、终端身份、操作审计；网络或云端故障时保留本地安全控制与人工求助方式 |
| 有个性的交流和服务推荐 | 提供亲切、稳定、适老的交互风格，解释服务选择并收集体验反馈 | 语气适配场景，医学判断与商业推荐分别审核，评价不能替代质量验证 |
对医疗公司的启发是把已有能力连接起来：传统系统提供预约、档案、收费和库存等可靠服务；专病知识库与 AI 提供信息整理、解释和任务辅助；终端负责现场交互及经过验证的感知与执行；自有 C 端在用户授权后承接离场后的计划和服务。用户通过一个入口获得连续服务，各系统仍按职责和权限运行。
这种协同可以先复用现有系统和终端，随着部署增加，再统一知识版本、工具接口和终端管理。评估投入时，把共性软件与设备适配分别核算，观察新增一个点位是否还需要大量定制，避免形成新的长期维护负担。
首个样板可以是社区健康服务向导
可选择已有合作的社区健康服务点或养老机构，使用成熟终端，在工作人员支持下验证一条任务链：接待并确认需求，说明授权范围，协助使用适用设备测量，整理可核验的结果，引导至工作人员或专业服务，按用户确认的安排在自有应用中继续提醒和随访。移动带路、递送等物理能力按环境与设备条件逐项增加。
样板验收看完整任务成功率、用户及工作人员总耗时、结果整理准确性、人工接手及时性和单点运营成本。机构侧验证部署、软件与持续服务费用，个人侧验证后续服务包的实际使用和付费意愿。检测与导诊保持其业务依据，服务推荐说明内容、价格和可选择性。
聚焦生活助手 疾病监测预防与老人陪伴
| 场景 | 可探索的能力 | 实际服务连接 | 验证重点 |
|---|---|---|---|
| 生活助手 | 日程与复诊提醒、已确认用药计划提醒、语音求助、经授权的家居控制；条件成熟后扩展递送等物理协助 | 用户确认、服务预约、家属或照护人员协助 | 任务成功率、语音可理解性、误执行、使用负担 |
| 疾病监测与风险预防 | 接入适用的监测设备，整理指标趋势，按经确认的规则提示异常，支持饮食活动等健康计划 | 提醒复测、联系约定人员、转交专业评估、记录处理结果 | 数据有效性、误报漏报、异常响应、健康计划完成情况 |
| 老人陪伴与情感支持 | 日常交流、兴趣活动、回忆记录、联系亲友或社区人员、协助参与现实活动 | 约定的关怀服务、社区活动、人工咨询与求助 | 易用性、满意度、现实联系、人工响应与持续使用收益 |
疾病监测与预防能力应按具体设备、目标人群和用途验证。消费级传感数据、趋势提示和正式诊断的适用范围需明确；产品通过医学验证后，才能对相应健康结局作出具体承诺。
老人陪伴需要覆盖失去亲属支持，以及独居、失独等不同情况，按实际家庭和社区关系设计服务。本人同意后，可指定可信联系人或签约照护机构；没有家属可依托的老人，需要社区或专业服务组织承担约定的人工响应。产品应明确 AI 身份，尊重记忆和隐私偏好，帮助用户保持现实联系。
异常发现后必须有人接续处理
监测产品应把"发现异常、提醒核实、通知约定对象、人工接手、结果记录"设计成可执行流程。服务设计应明确响应范围、设备故障及失联时的处理方式，并验证通知能否送达、是否有人确认，以及何时升级处理。
例如，用户授权监测设备向应用发送指标，系统发现符合已确认规则的异常后提示核实，向约定服务队列或联系人发出通知，再记录人工处理结果。研发验证需要覆盖通知、确认与接续处理，并将人工响应列为服务依赖和持续成本。
涉及移动、递送、身体接触等物理动作时，应单独验证环境适应性、动作安全、停止机制和运维能力。可先在有人协助的养老机构或社区服务场所测试，再按实际能力拓展到居家环境。
终端与服务的产品化条件
可探索"设备销售或租赁 + 软件与服务订阅"，也可由养老机构、社区服务运营方或家庭购买组合服务。对缺少家庭支付与照护支持的老人，可与机构协商购买服务，公共采购或资助收入以实际合同为准。
技术与产品评估可分别说明终端的安装、维护、升级和故障处理，以及服务侧的模型、连接、人工关怀与异常响应需求。这些持续工作决定方案能否长期提供价值，也可作为相关团队估算成本与讨论服务模式的依据。
以场景原型验证技术与服务条件
可用一个目标人群、一类终端和一个高频任务构建原型，例如"社区老人的日常提醒与人工关怀连接"，验证后再讨论健康监测和更多服务。研发评价重点是设备稳定性、交互可用性、任务完成与异常接续能力，同时为产品团队提供服务依赖和成本依据。
工信部、民政部的智能养老服务机器人试点通知覆盖 2025---2027 年，涉及居家、社区和机构场景，强调情感陪护、健康促进、生活辅助及安全性、适老化和经济性验证。该方向可作为合作与验证参考，具体项目资格和采购需另行落实。
2026 年的人形机器人与具身智能实景实训专项行动通知将医疗康养列入重点场景，强调在真实环境中评估作业成功率、效率、安全可靠性和经济可行性。产品借鉴应据此落到可测试的服务任务与经营指标上。
持续情感互动类服务还应按适用范围落实《人工智能拟人化互动服务管理暂行办法》。该办法已于 2026 年 7 月 15 日施行，要求明确 AI 身份、保护老年人权益，并防范情感依赖。陪伴产品的长期价值应体现在生活支持和服务质量上。
九 产品增值与持续服务价值参考
建设收入与持续服务收入并行
从研发角度，模块化能力、清晰的服务边界、持续更新机制和可观察的使用效果，可以为产品增值提供基础。以下模式供产品与业务讨论，研发重点是说明各模式需要什么能力、持续投入和部署条件。年度服务也可以采用院内部署，技术设计应适配实际数据与系统环境。
个人与家庭产品可支持明确的服务权益、用量与进度查询；设备产品需要同时具备终端管理和持续服务能力。不同产品形态的成本特征有差异，研发估算宜分别说明首次接入、持续运行、更新与支持工作。
| 价值方向 | 可提供的内容 | 可供业务讨论的方式 | 产品与技术条件 |
|---|---|---|---|
| 建设与实施 | 标准产品、首次集成、数据整理和流程配置 | 按范围讨论建设与实施服务 | 交付边界明确，后续支持可维护 |
| 基础维护 | 约定版本支持、故障处理和服务级别 | 年度维护或服务合同 | 服务范围与持续成本匹配 |
| 智能功能增购 | 质控、随访等独立增量能力 | 可按模块、科室或机构报价；设用量区间 | 明确预算与验收指标，避免与既有权益重复收费 |
| 专病科研与辅诊产品 | 专病知识库、科研助手、经验证的临床辅助模块 | 首期建设加约定的年度软件、知识与服务费用 | 科研和临床分别验收，确认项目结束后的持续预算 |
| 自有 C 端增值服务 | 个人会员、专病服务包、家庭照护与机构合作服务 | 明确权益的订阅、周期服务或机构购买 | 用户授权、服务资质、留存与单用户贡献成立 |
| 具身终端与照护服务 | 适用终端、软件、人工关怀及约定的响应服务 | 销售或租赁加服务订阅，也可由机构采购 | 设备与服务分别核算，具备实际响应和售后能力 |
| 持续运营 | 约定的知识更新、模型评测、流程复盘和优化 | 按周期签订服务合同 | 有持续交付物，责任与人工投入清楚 |
| 结果相关服务 | 双方可核验的非临床运营改善 | 条件成熟时探索固定费用加浮动费用 | 能归因、可验收，符合客户采购和结算要求 |
研发设计可明确基础维护、新增模块和持续更新的能力边界，并提供相应的配置、使用计量和服务记录。产品增值需要可验证的新价值支撑，已有使用权益和具体服务约定由相关团队结合实际情况确认。
区分软件采购与患者医疗收费
公司向医院销售软件和服务，与医院向患者收取医疗服务费，是不同的收费链条。不能把医院采购 AI 的成本直接假设为可向患者新增收取的费用。
国家医保局 2026 年 2 月的《医疗服务价格项目立项指南解读辅导》第 5 期明确：放射检查类指南已将相关 AI 辅助诊断技术纳入扩展项，不与主项目同时收费；医疗机构具体收费以当地医保部门出台的价格政策为准。该规定针对相应放射检查场景，不能外推为所有 AI 服务的统一收费规则。
研发讨论产品价值时，应区分软件能力、机构购买服务和患者医疗服务等不同场景。涉及付费方式的设想，需要产品与业务结合服务内容和适用政策进一步确认。
用研发证据支撑价值判断
产品价值可通过任务总耗时、返工、缺陷、及时性和使用体验等指标呈现。节省工时与实际现金节约之间存在业务条件，研发宜提供真实测量结果，帮助相关团队判断价值如何实现。
成本评估可分别说明首次集成与迁移工作、持续模型与基础设施用量、知识更新与评测，以及必要的人工复核和异常处理。比较方案时，既看生成速度，也看完成任务所需的总投入。
可复用模块、稳定接口和自动化工具首先有机会降低交付与维护工作量；专病知识、科研助手和个人健康服务则有机会形成新增能力。研发建议应清楚表达两类价值，并给出可验证的条件。
十 研发验证与技术取舍
场景探索可从现有流程和可测量任务开始，记录原有处理方式，再用相近任务比较新方案。研发讨论可围绕四类问题展开：
- 任务价值。 是否解决真实问题，是否减少总耗时、重复操作或质量缺陷，人工复核与异常处理后仍有改善。
- 质量与安全。 误报、漏检、错误建议和工具误执行能否达到场景要求；低频高风险问题需要专门评价。
- 可复用与可维护。 关键差异能否通过配置或标准适配承载，版本、知识和模型更新是否可管理，故障能否定位与回退。
- 持续成本与外部依赖。 模型、设备、接口和人工服务是否可持续支撑，相关数据、专业审核及应用条件是否具备。
数据不足、依赖长期不可用，或复核与维护负担抵消收益时，可先缩小任务范围、调整实现方式，再验证效果。技术验证结果为产品价值和商业可行性讨论提供依据。
十一 研发评价指标与价值验证
以下指标可按产品类型选择，用于比较方案和评价原型，具体门槛由实际场景确定。
| 评价维度 | 可观察指标 | 对应研发问题 |
|---|---|---|
| 可维护性 | 重复故障、人工修数、排障耗时、升级与回退成功情况 | 共性问题是否减少 |
| 任务效率 | 准备、执行、复核、返工和异常处理的总耗时 | AI 或流程改造是否有效 |
| 输出与执行质量 | 场景相关的误报、漏检、事实错误与工具误执行 | 能否进入相应使用范围 |
| 知识与数据质量 | 引用一致性、来源可追溯、变量提取准确性、更新时效 | 科研与辅诊能力是否可靠 |
| 复用程度 | 新场景的配置量、适配量、独立分支与重复开发 | 能否降低后续交付成本 |
| C 端服务体验 | 首次任务完成、服务相关性、转人工质量、周期复用 | 是否支持持续健康服务 |
| 具身任务能力 | 感知有效性、动作与任务成功、设备故障、异常接续 | 是否适应真实使用环境 |
| 运行与支持成本 | 单任务模型和资源用量、人工审核与支持工作量 | 能否支撑持续提供能力 |
用户留存、续费和付费意愿可作为产品团队反馈的价值信号，与研发测量结果结合讨论。指标可按实际场景持续复核，为后续方向取舍提供参考。
十二 医疗场景质量与数据要求
数据与安全要求应纳入场景设计、架构和研发验证。医疗健康信息属于敏感个人信息；处理需具备合法依据、特定目的和充分必要性，并采取严格保护措施。公司应明确与医疗机构的委托处理范围、权限、保存期限及第三方模型的数据处理方式，不能将客户数据的接入权限等同于跨客户使用或训练授权。《个人信息保护法》
Agent 按用户授权调用工具，关键操作保留人工确认和记录；故障时能够回到原有业务流程。对临床相关功能，按实际用途评估准入及临床验证要求；对模型、知识库和流程的更新，保留版本与评测记录。质量评价应同时覆盖生成内容与工具执行结果，持续监测实际应用中的问题。《智能体规范应用与创新发展实施意见》、《关于促进和规范"人工智能+医疗卫生"应用发展的实施意见》
十三 未来研发方向与演进原则
未来产品演进可以围绕以下方向展开，结合现有产品基础选择切入点，并随验证结果调整：
- 传统应用的效率与质量。 完善稳定性、流程、数据质量、接口与可维护性，在合适的工作界面增加 AI 辅助。共性能力与配置化设计有助于减少逐项目重复投入。
- 专病科研与 AI 辅诊。 建设可追溯、可更新的专病知识与数据能力，支持文献分析、队列构建和病例整理，再按实际用途的验证条件延伸临床辅助。
- 自有 C 端的连续服务。 围绕个人与家庭的健康任务，提升精准匹配、服务相关性、进度反馈与专业服务转接，探索能够长期提供价值的增值能力。
- 医疗具身智能体。 结合合作设备与实际场景，探索生活助手、疾病监测预防和老人陪伴。通过现场感知、任务执行与人工接续，将既有软件服务延伸到居家、社区和养老环境。
这些方向可复用数据接入、知识管理、模型调用、受控工具、权限审计和质量评价等基础能力。共性能力根据已经出现的真实需求提炼，成熟模块逐步复用，保留各场景的专业边界。
演进顺序可以依据依赖关系形成：已有业务与数据能够支撑的助手先验证；需要跨步骤协作的任务再引入 Agent；科研结论进入临床功能时单独审核与验证；具身能力随设备和环境条件逐项增加。每一项探索都应说明用户任务、预期改善、技术依赖和验证方式。
研发视角的持续价值，体现在产品更可靠、任务完成更高效、能力更易复用、持续维护更可控。这些成果为产品增值、服务质量、用户粘性和未来收入机会提供基础。