企业官网建设流程全解析

这次我们来拆一个很少见的标的：写进财报里的AI医疗产品——京东健康的AI医生“大为”。

医疗AI产品不少，但多数停留在发布会PPT和演示Demo阶段。真正进入上市公司财报、被写进业务叙事里的，确实不多。“大为”的价值不在于多了一个会聊天的医疗大模型，而在于它直接嵌入京东健康的在线问诊、健康管理、用药服务链条，成为一项能影响成本和收入结构的基础设施。

这篇文章不聊股价建议，只从技术落地和企业级AI产品角度拆三件事：

1. “大为”到底是什么，长在什么业务场景里；
2. 支撑它的技术底座有哪些关键模块；
3. 为什么市场认为它有“价值重估”的潜力，以及普通人如何跟踪验证。

如果你在做AI Agent、医疗大模型、RAG落地，或者关注大模型如何从技术Demo变成真实业务系统，这篇文章可以收藏。

1. 核心能力速览

先把“大为”的关键信息列出来，后续再展开。

需要说明的是，大部分技术参数、模型规模和内部实现，京东健康不会完全公开。所以下面凡是涉及细节的推测，我会明确标注“从业务形态推断”或“更稳妥的判断是”，不会用猜测冒充事实。

2. AI医生“大为”是什么：产品定位不是聊天机器人

2.1 从财报看到的信息

从财报的业务表述看，京东健康对“大为”的定位不是“智能问答机器人”，而是“医疗服务能力的AI化”。

在线问诊行业的核心成本是医生人力。一个医生同时只能接待一个用户，问诊时长受限于打字速度和医生经验判断。平台做大之后，问诊量增长会带来医生成本的线性增长。AI医生要解决的，正是这个问题：

• 在用户进入人工问诊前，由AI完成预问诊，收集症状、病史、用药情况；
• 在问诊过程中，AI提供辅助决策建议，帮助医生快速完成判断；
• 在问诊结束后，AI承担随访、用药提醒、报告解读等低频但耗时的工作。

这其实是一个典型的“AI Agent + 人工兜底”模式：AI负责标准化、重复性、低风险的环节，医生负责诊断、处方和复杂沟通。

2.2 产品闭环拆解

“大为”不是孤立功能。从互联网医疗的业务流程看，它至少嵌在四个环节里：

1. 问诊前：用户描述症状，AI分诊到对应科室，推荐匹配医生；
2. 问诊中：AI整理用户主诉和关键信息，辅助医生快速决策；
3. 问诊后：AI解读报告、生成用药提醒、安排复诊计划；
4. 健康管理：面向慢病用户提供长期随访和健康建议。

这样拆下来就清楚了：AI医生不是替代医生，而是重新设计“问诊服务”的生产流程。它把医生从“重复问问题”里解放出来，把更多精力放在“判断”和“决策”上。

这也是AI医疗产品和通用ChatGPT类产品最本质的区别：医疗AI的价值不在“生成文字”，而在“完成一个医疗服务流程”。

3. 技术底座拆解：医疗Agent不是通用大模型加壳

通用大模型经过Prompt工程可以回答“感冒了吃什么药”，但距离可商用的AI医生还差很远。一个能在真实业务里运行的医疗Agent，至少需要下面这些模块协同。

3.1 医疗大模型与领域微调

通用大模型的知识覆盖广，但医学知识更新慢，且容易产生“自信的幻觉”。医疗场景要求模型在“不知道”的时候承认不知道，而不是编造一个治疗方案。

所以“大为”这类产品的基础模型，需要经过一系列医疗领域改造：

• 医学语料继续预训练；
• 问诊、诊断、用药等场景的指令微调；
• 基于医生反馈的偏好对齐；
• 高频错误样本的定向修复。

这套流程和通用大模型微调一致，但难点在数据质量。医疗对话数据涉及隐私，清洗和标注成本远高于通用数据。

3.2 RAG与知识库

医疗知识是强时效性的。药品说明书会更新，指南会修订，新药会上市。如果只靠模型参数里的记忆，必然出现版本滞后。

更稳妥的方案是RAG：把药品库、疾病指南、说明书、医学文献切成向量块，用户提问时先检索再用原文兜底。这样做有两个好处：

• 回答可以附带来源，用户和医生可以追溯到具体依据；
• 知识更新只需替换文档，不需要频繁重训模型。

RAG的工程难点不在“能检索到”，而在“检索到的内容是否匹配当前问诊上下文”。同样是“发烧”一词，儿童和老人、有基础病和无基础病，对应的检索策略完全不同。

3.3 知识图谱与推理

大模型擅长自然语言理解，但不擅长“多跳推理”和“严格逻辑约束”。医疗场景里，疾病、症状、药品、科室之间存在大量结构化关系，这正是知识图谱的强项。

一个完整的医疗图谱至少包含四类节点：

操作路径是：大模型先从用户对话中抽取实体，再交给图谱做规则校验。比如用户说“阿莫西林过敏”，图谱会关联出禁用药物类别，在后续推荐中自动拦截。

这里有一个工程判断：纯靠大模型做“药物相互作用判断”风险很高，用“图谱规则优先，大模型生成兜底”的混合架构更稳。

3.4 工具调用与多模态识别

医疗Agent还需要调用大量外部工具，比如：

• 用药提醒调度；
• 科室医生排班查询；
• 处方药订单合规校验；
• 化验单OCR识别。

以化验单识别为例：用户拍一张血常规报告，AI需要先识别表格文字，再判断哪些指标异常，最后结合用户主诉生成解读。这个链路不能靠单一模型完成，必须用多模态模型 + 结构化解析 + 规则引擎串联。

3.5 语音交互与安全护栏

手机上的AI医生，语音是重要入口。中老年用户打字慢，语音问诊能显著降低使用门槛。这里需要ASR准确率、方言兼容、语音中医学实体抽取等能力。

更要紧的是安全护栏。医疗场景不允许“自由发挥”，系统必须包含：

• 风险问题拒答；
• 敏感词拦截；
• 处方药合规校验；
• 极端情绪识别；
• 转人工兜底触发条件。

如果AI识别到“胸痛持续半小时”“呼吸困难”等高风险信号，必须立即引导用户急救，而不是继续问诊。

4. 医疗AI Agent的工程实践参考

虽然京东健康没有公开“大为”的完整技术架构，但一个可商用的医疗AI Agent，通常可以按下面这套流程设计和验证。以下代码和配置仅用于说明工程思路，不是京东健康实际接口。

4.1 系统架构

按模块拆分，医疗AI Agent可以分成六层：

用户入口层：App / 小程序 / 语音助手 交互层：多轮对话管理、语音识别、情绪识别 理解层：意图识别、医学实体抽取、分诊决策 知识层：RAG检索、知识图谱查询、医学规则引擎 行动层：报告解析、药品校验、用药提醒、转人工调度 审计层：日志留痕、质量抽评、合规审查

这层结构的好处是，每一层都可以独立评测和替换。知识库里换文档，不需要动交互层；语音识别换成新供应商，也不会影响实体抽取。

4.2 意图路由示例

AI医生面对的第一件事，是判断用户想干什么。

# 示例代码：医疗Agent意图路由（非京东健康实际实现） def route_intent(user_query: str) -> str: query = user_query.lower() if "报告" in query or "化验" in query or "结果" in query: return "report_interpretation" if "药" in query and ("怎么吃" in query or "几次" in query): return "medication_guidance" if "痛" in query or "烧" in query or "不舒服" in query: return "symptom_triage" if "预约" in query or "挂号" in query: return "appointment_booking" if "过敏" in query: return "allergy_screening" return "fallback_to_human" # 无法判断时转人工

这段代码的关键点是最后一行：当意图不明确时，优先转人工，而不是继续生成。这是医疗Agent和普通客服机器人最大的差异。

4.3 问诊请求与响应结构

一个标准化问诊请求，建议包含用户身份、症状时间线、历史病史和当前用药情况。响应结构则需要带有“依据来源”和“风险等级”。

下面是一个通用的JSON结构示例：

{ "request_id": "20250601001", "patient": { "age": 45, "gender": "male", "allergy_history": ["penicillin"] }, "session": { "chief_complaint": "咳嗽持续三天，夜间加重", "ongoing_medication": [ {"name": "头孢克肟", "dosage": "100mg"} ] }, "response": { "likely_category": "急性上呼吸道感染待排", "risk_level": "moderate", "suggestion": [ "建议线下就诊呼吸内科", "暂停使用当前抗生素，需医生评估后再决定" ], "evidence_source": [ "国家呼吸系统疾病诊疗指南_v2025", "头孢克肟说明书_不良反应部分" ], "action": "refer_to_human_doctor" } }

这个结构体现了一个核心原则：AI给出的是“建议”而不是“诊断”，且必须携带证据，必须给出下一步行动方案。

4.4 RAG配置模板

RAG的召回质量直接决定医疗回答质量。下面是一个通用配置模板，用于限定知识库类型、切片方式和召回参数：

retrieval: top_k: 5 score_threshold: 0.72 chunk_size: 512 chunk_overlap: 64 embedding_model: "medical-embedding-v2" knowledge_base: - name: "drug_instructions" version: "2025.06" priority: high - name: "clinical_guidelines" version: "2025.03" priority: high - name: "medical_qa_cases" version: "2025.01" priority: medium rerank: enabled: true model: "medical-cross-encoder" filter_conditions: - "drug_conflict_check: must_pass" - "age_group_match: required"

score_threshold建议设高一点。医疗场景宁可“没找到答案”也要避免“拿错答案硬答”。召回质量不达标时，应该触发回落机制，而不是强行生成。

4.5 评测与灰度验证

医疗AI Agent的评测不建议只跑通用Benchmark。更有效的做法是分模块评测：

灰度策略建议按“风险等级”分阶段放量：先放开健康咨询类问题，再放开常见病预问诊，最后才考虑辅助诊断类能力。每一步都要有人工抽检和召回机制。

5. 财报里的价值重估逻辑

企业级AI产品的价值，最终要体现在财务指标上。“大为”被写进财报叙事，背后是四条可以量化的逻辑线。

5.1 成本端：问诊边际成本下降

在线问诊平台最大的成本是医生人力成本。AI预问诊能把用户从“主诉表达”到“医生看到信息”的时间压缩到极致。医生不需要再花时间问“什么时候开始的”“有没有发热”“对什么药过敏”，AI已经把这些信息结构化整理好了。

这个改变带来两个结果：

• 同样数量的医生，单位时间能服务更多用户；
• 平台增加问诊量的边际成本降低。

当问诊量的增长不再需要等比例的医生数量增长，平台的毛利率和运营效率就会发生变化。这是最直接的价值重估依据。

5.2 收入端：服务链条延长

传统的“问诊-开药”模式，用户在医生回复后大概率离开。AI医生可以把服务链条拉长：

• 问诊结束，AI自动推送用药提醒；
• 药品快吃完时，提示复诊开方；
• 慢病患者按周期收到随访问卷；
• 化验单异常时，建议进一步检查。

每多一次触达，就可能多一次复购和续费。AI医生在这里的角色，是“低成本运营用户关系”的工具。

5.3 数据飞轮

AI医生每服务一个用户，都会产生结构化的健康数据。数据经过脱敏和标注后，可以反过来优化模型，提升后续问诊的准确率和体验。这形成一个闭环：

用户使用AI问诊 → 产生结构化数据 → 优化模型 → 体验提升 → 更多用户使用

这个飞轮一旦转起来，就是竞对很难复制的能力。数据积累和模型优化之间存在时间窗口优势。

5.4 估值逻辑：从卖药到“医疗服务平台”

京东健康原本在资本市场的核心标签是“医药电商”。这个标签有明确的天花板，毛利率受制于药品品类的价格竞争。

AI医生“大为”的存在，让京东健康可以讲一个更强的故事：从“卖药的地方”变成“提供健康服务的入口”。用户先找AI问诊，再按需求买药、买器械、买保险，服务链路的入口从商品搜索变成了医疗咨询。

这个迁移一旦成立，估值体系就会从“零售公司”转向“科技医疗平台”。

当然，叙事需要数据支撑。市场真正会跟踪的，还是AI渗透率、问诊量增速、复购率这些可以验证的指标。

6. 合规与安全使用边界

医疗AI是强监管领域。无论产品体验多好，合规边界控制不好就会出大问题。这里重点说四个边界。

责任边界：AI不能独立承担诊断责任。产品的界面、话术、服务协议都必须明确“AI建议仅供参考，最终以医生诊断为准”。系统如果无法判断，必须引导用户转人工。

隐私边界：问诊数据属于医疗健康数据，受个人信息保护相关法律严格约束。数据采集、存储、传输、流转都必须做脱敏、加密、权限控制。AI对话记录不能随意用于模型训练。

内容边界：涉及处方药推荐时，必须遵循处方药管理要求。AI不能直接向用户销售处方药，必须经过有资质的医师审方。

授权边界：如果AI需要采集用户的音频、人脸图像、体检报告，必须取得用户明确同意，并在显著位置说明用途。涉及第三方数据合作时，必须确认数据来源的合法授权。

任何做医疗AI的团队，都应该把合规能力当成产品的一部分，而不是上线之后补的“补丁”。

7. 常见问题与排查方法

医疗AI Agent在落地过程中，最容易遇到下面这些问题。

以上问题不是某一家公司的特有情况，而是医疗AI Agent从Demo到生产环境都会遇到的通用坑。排查的关键，是把每个模块的日志留好、指标拆细。

8. 跟踪AI医生落地效果的方法

判断“大为”到底是真价值还是PPT概念，不需要去猜财报措辞，跟踪下面几件事就够了。

从前面的技术拆解可以看出，AI医疗产品最重要的指标不是“对话流畅度”，而是“流程渗透率”：用户从进入AI问诊，到最后完成服务闭环，AI参与了多少步。这一步渗透得越深，公司的服务成本越低，估值逻辑越扎实。

9. 总结与下一步

AI医生“大为”值得关注的原因，不是它聊得多好，而是它把AI医疗从一个“演示能力”变成一个“生产工具”。

它最值得验证的三个点是：

1. 问诊成本是否真的下降；
2. 用户复诊和购药转化是否提升；
3. 数据飞轮是否形成稳定的迭代节奏。

最容易踩的坑，则是“过分相信模型生成能力”和“忽略医疗责任边界”。任何一个医疗AI产品，都要先把合规、安全、转人工兜底做好，再谈效率提升。

如果要做同类的医疗AI Agent，建议从最小闭环开始：选一个垂直场景，比如“用药咨询”或“化验单解读”，把RAG和规则引擎跑通，先证明它能稳定完成一类任务，再扩展到更多场景。

方法上，可以先用开源医疗大模型搭一个可运行的原型，验证意图识别、RAG召回和知识图谱这三块核心能力能不能对齐业务需求。判断标准很简单：AI给出的建议有没有依据，用户看不懂时能不能转给真人，错误有没有被记录下来并持续修正。

“大为”后续的表现，重点看它在京东健康财报里被提到的频率和具体业务数据，不用听发布会怎么说，看季度问诊量和AI渗透率的变化趋势就够。