个人健康助手看起来很适合成为 AI 应用的高频入口用户每天都有睡眠、运动、饮食、体重、情绪、复查提醒等需求。但从工程落地看入口频次并不由“回答一次问题是否聪明”决定而由系统能否持续提供可验证、可执行、可信任的闭环决定。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议文中规则均为示例真实项目需要由医疗专业人员和机构规范确认。入口频次来自连续场景而不是聊天窗口个人健康助手如果只是一个问答框用户打开几次后很容易流失。健康管理更接近“长期状态跟踪系统”它需要理解用户最近一周是否完成了计划、提醒是否有效、哪些建议被忽略、哪些内容需要升级给专业人员确认。一个更合理的产品假设是个人健康助手不是替代医生也不是万能百科而是围绕日常健康目标做任务编排。典型高频节点包括每日记录睡眠、步数、饮水、体重、主观感受周期提醒复查、体检、运动计划、健康档案更新数据解释把设备数据和用户输入转成可读摘要行动建议给出可执行但低风险的生活方式任务异常处理基于示例规则触发“请咨询专业人员”的提示这里的难点是持续性。用户不会因为一次回答漂亮而每天回来但会因为系统记得上下文、能减少记录成本、能提醒下一步而形成习惯。技术目标把健康助手做成状态机而不是单轮 Agent从架构角度看个人健康助手至少需要四层能力数据接入、用户状态建模、任务决策、触达执行。LLM 可以参与理解和生成但不应该独自承担全部决策。可以把系统拆成如下流程[Consumer App] | v [Event Collector] --- [Analytics Store] | v [User Health Profile] --- [Vector Store] | | v v [Rule Engine] ---------- [Context Retriever] | v [LLM Response Composer] | v [Notification / Task / Human Review]其中几个关键点Event Collector 负责收集用户授权后的行为和记录事件User Health Profile 存储结构化状态例如目标、偏好、提醒配置Vector Store 存放长文本记录和历史对话摘要便于上下文检索Rule Engine 处理确定性逻辑避免把风险判断完全交给模型Notification System 负责执行闭环包括提醒、延迟、取消和反馈这类系统的核心不是“模型会不会说”而是“状态是否准确、规则是否可审计、任务是否真的被执行”。一个最小可运行的任务决策示例下面用 Python 写一个简化版本输入用户事件生成下一步任务。注意风险判断只是示例规则不代表医学标准也不能用于真实诊断或分诊。fromdataclassesimportdataclassfromdatetimeimportdatetime,timedeltafromtypingimportList,DictdataclassclassUserEvent:user_id:strevent_type:strvalue:strcreated_at:datetimedataclassclassTask:user_id:strtask_type:strmessage:strpriority:intdue_at:datetimeclassHealthAssistantPlanner:def__init__(self,institution_rules:Dict):self.rulesinstitution_rulesdefplan(self,events:List[UserEvent])-List[Task]:tasks[]latest_by_type{}foreventinsorted(events,keylambdax:x.created_at):latest_by_type[event.event_type]event nowdatetime.now()ifdaily_checkinnotinlatest_by_type:tasks.append(Task(user_idevents[0].user_id,task_typedaily_checkin_reminder,message今天还没有完成健康记录可补充睡眠、运动和主观感受。,priority1,due_atnowtimedelta(hours1)))symptom_eventlatest_by_type.get(user_note)ifsymptom_event:keywordsself.rules.get(escalation_keywords,[])ifany(wordinsymptom_event.valueforwordinkeywords):tasks.append(Task(user_idsymptom_event.user_id,task_typeprofessional_consult_notice,message你的记录包含需关注内容。此为示例提示请按机构规则咨询专业人员。,priority5,due_atnow))returntasksif__name____main__:demo_rules{escalation_keywords:[持续不适,明显加重]}events[UserEvent(user_idu001,event_typeuser_note,value最近运动后感觉持续不适,created_atdatetime.now())]plannerHealthAssistantPlanner(demo_rules)fortaskinplanner.plan(events):print(task)这个例子刻意没有让 LLM 直接决定风险等级而是把可审计规则放在 Rule Engine 中。LLM 更适合做自然语言解释、摘要生成、意图识别和低风险交互涉及升级规则时应由机构配置和专业人员确认。信任门槛可解释、可追溯、可撤回个人健康助手要进入高频使用信任比“拟人化”更重要。用户会关心三个问题你为什么提醒我、你记住了什么、我能不能删除或关闭。工程上建议把每次建议拆成可追踪结构{suggestion_id:sg_20260520_001,user_id:u001,source_events:[event_101,event_108],rule_id:daily_checkin_v1,model_version:composer_2026_05,message:今天还没有完成健康记录可在晚间补充。,user_action:pending}有了这个结构后续才能做调试和治理用户质疑提醒时可以解释触发来源规则更新后可以回放历史事件评估影响模型版本变化时可以比较生成文本差异用户关闭某类提醒后可以避免重复打扰对于消费级 App透明度本身就是体验的一部分。一个无法解释来源的建议即使文本流畅也很难获得长期信任。执行闭环通知系统不是简单 push高频入口通常不是用户主动打开而是系统在合适时间触达。但健康类触达很容易过度打扰因此通知系统需要做节流、优先级和反馈学习。建议至少设计以下字段channelApp push、短信、邮件、站内信priority提醒优先级quiet_hours免打扰时间cooldown同类提醒冷却时间action_state已读、完成、忽略、延后feedback用户是否认为有用简单实现可以从任务队列开始后续再接入更复杂的调度服务。关键是不要把所有提醒都当成一次性消息而要当成可观测任务。例如连续三次被忽略的提醒下一次应降低频率或询问用户是否调整目标连续完成的任务可以转成周报总结而不是每天重复推送。Vector Store 应该存什么不应该存什么个人健康助手容易把所有内容都塞进向量库但这会带来隐私、成本和召回噪声问题。更推荐区分结构化数据和语义数据。适合放入结构化存储的内容用户目标提醒配置设备指标摘要任务完成状态授权与隐私设置适合放入向量库的内容用户长期偏好描述历史对话摘要健康记录中的非结构化文本常见问题解释材料不建议直接无差别入库的内容未脱敏的敏感原文已过期且无业务价值的临时记录无来源标记的模型生成内容用户明确撤回授权的数据向量检索的目标不是“记住一切”而是在生成回复时找回少量高相关上下文。实际项目中还需要加入权限过滤、数据保留周期和删除机制。分析指标不要只看 DAU如果把个人健康助手当成入口产品DAU 当然重要但仅看打开次数会误导团队。更有价值的是闭环指标。可参考的工程指标包括checkin_completion_rate记录任务完成率reminder_accept_rate提醒被接受比例suggestion_follow_rate建议后续执行比例notification_ignore_streak连续忽略次数context_hit_rate生成回复时上下文命中率escalation_audit_pass_rate升级提示审核通过率这些指标可以帮助判断系统是否在产生连续价值。例如DAU 上升但提醒忽略率也上升说明触达策略可能过载上下文命中率低则说明数据建模或检索策略存在问题。个人健康助手的真实门槛个人健康助手有机会成为高频入口但门槛不在单点模型能力而在产品和工程系统的组合能力。第一要有低摩擦的数据入口。用户不可能每天填写复杂表单系统需要支持自动采集、快捷记录和渐进式补充。第二要有长期状态管理。没有状态助手就只能重复回答常识问题有状态才能生成连续任务和个性化提醒。第三要有可信边界。健康场景不能把模型输出包装成确定性结论示例规则、升级流程、人工确认和审计日志都要纳入系统设计。第四要有执行闭环。提醒、任务、反馈、复盘缺一不可否则助手只是内容生成器不是日常入口。结论与下一步个人健康助手能否成为高频入口取决于它能否稳定解决“我今天该做什么、为什么做、做完后系统如何继续跟进”这三个问题。工程实现上应优先建设事件流、用户状态、规则引擎、通知系统、向量检索和分析看板而不是把全部预算压在单轮对话质量上。如果要做原型建议先从一个窄场景开始每日记录加提醒闭环。先验证任务完成率、提醒接受率和用户反馈再逐步引入更复杂的上下文检索和 Agent 编排。医疗健康相关功能务必保持技术边界所有阈值、风险分层和升级规则都应由专业人员与机构规范确认。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。