康比特 AI 运动养生：从系统数据到真实吃动结果

2026-09-22 · V0.1 概念架构与试点设计 · 面向 Jack、产品、研发、营养与运动专业团队

核心判断：把已有食堂、体测和运动服务连接成一个能执行、能反馈、能验证的个人吃动服务。竞争力来自真实场景的执行能力与结果证据。

本轮已完成资料核验、3 个 Sub Agent 的独立研究与方案整合。没有提取生产数据库、没有得到全部用户数据、没有完成统计效果分析、没有开发或部署业务系统。下文系统、算法、接口、指标目标均为设计提案；已知事实见来源索引。首轮人群暂按同一企业/园区食堂内的健康成年人，等待业务负责人确定，不覆盖所有年龄及健康状态。

1. 把你的想法归纳成一个产品命题

为了让用户在工作与生活中更容易做到适合自己的饮食和运动，我们提供一个理解个人状态、能调用真实服务、能根据执行反馈调整的 AI 运动营养师。

产品每天回答五个问题：我现在有哪些可信信息？今天值得做哪件事？在哪里、何时、用什么资源做？实际完成了多少？下一次为什么调整？

“AI 运动养生”可以作为面向用户的暂定名称；专业能力沿用 AI 运动营养师。养生的首版范围限定为饮食、活动、恢复与习惯支持，不承诺诊断、治疗、延寿或确定健康效果。

三项差异化假设需要验证：①推荐匹配当天真实供应，用户做得到；②运动与饮食在同一计划中协调，减少相互冲突；③长期记忆减少重复提问、纠错和专业服务工时。数据量和 Agent 数量本身不构成已证实的竞争壁垒。

2. 现有基础与不能跳过的事实

同在阿里云，只代表可能共享基础设施环境。接入还要分别满足资产覆盖、网络可达、技术权限、客户与个人用途授权、身份关联、数据质量。系统运维权限不自动等于健康分析或模型训练权限。

3. 一天的体验：让用户愿意回来

示例仅说明产品行为：用户下午临时加班，可以把原计划替换为规则允许的短活动；晚餐按整日计划重新匹配。不能因为午餐吃多就要求惩罚性运动，也不能因为设备报告消耗较高就机械增加进食。

持续使用依靠少做决定、真实完成、可解释反馈和可自主调整。通知按本人选择设置时间与频次；允许休息、暂停、关闭提醒和退出。进度以本人目标比较，避免体重排行榜、羞辱提醒、强制连续打卡和无限刷屏。北极星指标采用“每周完成建议→行动→反馈的用户比例”，不采用停留时长。

4. 整体架构：六层分工

数据流为“来源事件→质量检查→个人状态快照→并行候选→联合计划→校验→确认→执行反馈→新快照”。食堂订单服务继续管理交易；Agent 通过受控接口发起用户确认后的业务动作，不直接写订单表。

建议部署形态：沿用现有入口与业务库，在内网增加连接器、独立分析存储、决策服务和队列 Worker；外部模型只经模型网关接收最小必要上下文。原始健康数据、身份映射和日志各设权限边界。客户本地部署采用本地适配器按授权汇总或同步，不要求客户把全库上传公有云。

阿里云组件是候选映射：RDS 或兼容数据库承接事务；OSS 私有存储承接受控原始批次；队列承接异步事件；DTS 可作为受支持库之间的同步选项。官方 DTS 文档确认其可用于把数据同步到分析侧，具体支持矩阵、源库影响与费用仍须按现网核验。DTS 官方说明

首版采用“模块化服务＋一个队列＋少量 Worker”，按吞吐与隔离需要再拆分；不预设必须上 Kubernetes、全量湖仓或自训大模型。

5. 拿到数据之后，究竟分析什么

先接入有明确用途的最小数据集。每个数据源登记：系统/环境、客户与租户、责任人、数据对象、字段字典、时间范围、用途授权、接入方式、更新频次、删除机制、覆盖率及质量负责人。全量的分母来自经负责人核准的数据源目录，不来自“已发现服务器数量”。

最低事件合同：event_id, tenant_id, subject_ref, source_system, source_record_id, event_type, event_time, ingested_at, schema_version, consent_scope, quality_flags, evidence_ref。具体测量值另带单位、设备/配方版本、测量方法与修订链。身份映射保存在隔离服务，分析侧使用去标识化标识；去标识化仍按个人数据保护。

实现应继承既有 health-data-integration.md 的 memberId/sourcePlatform/externalId/revision/value/unit/permissionScope 等字段，本文事件合同是架构级补充，不是另建一套不兼容接口；字段命名与迁移映射须在开发UC中冻结。同一手表经两个App镜像的数据不能相加，全天总消耗不能再次叠加训练消耗。小程序不能默认直接读取手机原生健康仓库；首条路径须核对厂商服务端接口，或受支持的原生伴随端，完成一次授权后自然到数、补传与撤权验证。

接入顺序：只读元数据盘点→获准脱敏小样→数据字典与质量剖析→授权范围内初始快照→增量同步→逐批对账。大规模扫描和回补在复制库/分析侧限速运行，安排源库负载监控；不能让 LLM 临时生成任意生产 SQL。

实际分析分六个工作包：

1. 可用性分析：各来源的身份匹配率、字段缺失率、重复/迟到比例、单位异常、有效期、餐次覆盖，交付质量报告和可用字段表。
2. 行为基线：按时间、地点与目标分析就餐规律、活动规律、记录负担和计划困难。仅描述关联，不能从偏好/消费推断疾病。
3. 供需可执行性：适用推荐是否在售，受预算/过敏/份量限制的无解比例，替代后可履约比例。
4. 个体趋势：可比测量条件下的运动、饮食和本人反馈变化，同时报告观察窗口、缺失和不确定性。
5. 策略效果：先回放和影子运行，再比较真实执行与留存增量；避免用后发生数据预测过去、按用户与时间隔离训练/验证集。
6. 服务经济性：机构服务、个人订阅、商品交易分别核算；统计模型、设备接口、人工、供应维护、获客、退款成本。

本轮没有上述业务原始数据，因而不能给出真实用户画像占比、推荐提升率或营收预测。下一阶段的真实分析交付必须包含查询/计算口径、数据时间窗、有效样本分母、授权凭据索引、质量报告和可复算结果。

6. 算法设计：让每一步有依据

6.1 状态估计

个人状态 S(t) 由目标/偏好、限制、可用时间、历史执行、近期体测/活动、本人反馈和餐食供应组成。每个字段保留来源、发生时间、可信度、有效期与缺失标记。事实、推断和计划分字段，不让推断回写成观测。

规则先判断数据是否足以做决定：缺少关键限制则补问；运动数据断连时提供允许的保守模板；菜品配方不明时不输出精确营养数值。可信度应来自数据校准或明确质量分级，不能用 LLM 自报“95%置信度”。

6.2 可复算计算与知识依据

营养目标和运动范围采用由营养/运动专业负责人审核的适用人群、公式、参数和版本。配方计算示意：某营养素量＝各食材可食重量×对应营养密度×适用加工修正的和；共享菜、油盐和剩餐误差须独立记录。重量、千焦/千卡等单位转换由确定性程序负责。

知识检索只从经审核资料中取适用条目，记录来源、版本、有效人群和证据等级。RAG 负责提供依据，不替代数值计算和规则校验。WHO 的活动资料按不同人群区分建议，本方案据此要求人群适用性审核，不把公共指南直接复制为个人处方。WHO 身体活动资料

6.3 饮食与运动联合规划

饮食候选变量包含菜品、份量、餐次、价格与供应；运动候选包含项目、时段、场地、时间和经审核的强度范围。二者必须读取同一 snapshot_version。

形式化目标：在硬约束满足的前提下，最小化 w1×目标偏差＋w2×执行负担＋w3×偏好偏差＋w4×计划变化＋w5×数据不确定性惩罚。各项先归一化，权重先由专业与产品团队设定，再通过试点校准；不得宣称已经学到最优权重。

硬约束包括过敏/禁忌、已审核安全边界、可用场地与时间、供应有效性、本人授权和不可突破的用户预算。软约束包括口味、多样性和便利程度。无解时说明冲突，提供允许的替代或转人工；禁止偷偷放松安全约束。

初期采用审核模板＋候选过滤＋可解释排序。有大量组合与份量决策后，再评估线性/整数约束求解器。执行概率模型只有在事件质量和样本量足够、校准与偏差验证通过后才引入。个性化排序实验限制在安全候选集合内，不通过在线强化学习探索更危险的运动/饮食边界。

6.4 验证、解释与有界调整

规则服务先验算数值、单位、约束和证据，再让沟通 Agent 生成解释。解释必须与结构化计划一致，不能新增未审核的动作或数值。

按事件更新，而非每次聊天都重做全天计划。用户取消训练、菜品售罄或新增有效限制时重算受影响部分，再合并完整计划，结合已完成行为重验整日/周期硬约束；日内调整幅度、频率和有效期由专业规则配置。不能把一两次体重波动当成策略有效，也不能把缺数补为零。

6.5 安全承接

首版仅在确认适用人群内运行。专业规则定义何时暂停相关建议、何时转营养师/运动专业人员、何时提示寻求医疗帮助。出现身体不适不靠多 Agent 投票决定继续；未成年人、孕产、慢病用药、伤病康复和专业竞技等各有独立流程与责任人，未建流程则不开放自动个性化方案。

人工接单要有负责人、服务时间、回执和无人承接提示，不能把“转人工”按钮当成服务已完成。此为设计门槛，具体筛查问题与数值待专业审核。

7. Agent、子线程、多线程与多进程各做什么

Sub Agent 是职责/上下文隔离；一次调用不必对应一个操作系统进程。逻辑子线程用于同一请求的独立候选任务；异步 I/O 或受限线程池用于等待 API/模型；进程池或容器 Worker 用于计算密集的批量清洗、优化求解和模型评估。跨机器任务交给队列与持久状态，不能仅靠内存线程。

线上固定流程：鉴权和授权检查→冻结快照→并行请求饮食/运动候选→等待必要结果→联合规划→完整计划规则校验→保存待确认候选→用户确认→原子条件校验并切换有效版本→执行回执。风险暂停可立即生效，替代方案仍需确认。在线缺数不等耗时的全库分析，先说明缺口并提供允许的降级结果。

请求合同包含 tenant_id, subject_id, snapshot_version, rule_version, plan_version, trace_id, evidence_ids, deadline, idempotency_key, consent_epoch, safety_epoch。子任务回包另含状态、候选、依据、缺失项、耗时和成本；返回结构化错误，不能用一句“成功”代替结果。

并发规则：

• 每个租户设置查询、任务和模型并发配额；固定最大派生深度、调用次数与 Token 预算，不无限互相派发。
• 正式计划用乐观锁比较版本。同一用户两次重算只能在仍有效的快照上提交，旧结果丢弃或重新计算。
• 队列按可能重复投递设计，消费者幂等；数据库提交与发事件使用事务 outbox 等可验证机制。超时查状态后再重试业务写入。
• 网络暂时错误有限重试；权限失败、无可行解、规则拒绝进入相应分支，不反复换模型绕过。
• 菜单售罄、授权撤回、风险升级可以使旧计划失效。任务执行前和结果提交前都重新核验授权；此外必须将单调递增的consent_epoch/safety_epoch与快照、规则和计划版本纳入原子生效条件，防止检查后撤权/风险变化。跨服务统一生效门禁或可靠序列化，旧epoch结果不得生效或发送通知。
• 模型超时只能回退仍适用的审核模板；模板同样需检查当下限制。周报失败不阻断就餐交易。

容量先用公式预算：峰值请求率×平均处理时长≈在线并发；每日任务量×单任务时长÷处理窗口≈Worker 基础需求，再留故障余量。记录每次 Token、工具成本和人工分钟。容量、成本、p95 时延均待实测，不能先编实例数量。

本轮实际协作是 3 个 Sub Agent 并行研究资料事实、算法架构、产品验证，主线程统一写方案；没有在生产启动多进程 Agent 服务。

8. 权限、记忆与可观测性

健康信息属于敏感个人信息；接入、跨系统关联、对外提供和训练用途要分别核准处理依据、告知与适用同意要求。实施前由负责人员审核具体流程。本设计默认不将服务数据转作模型训练，机构只能在批准范围查看汇总，不能默认查看员工个人健康明细。个人信息保护法原文

记忆分四类：本人可修改的偏好与限制、带来源的事实时间线、每次任务的临时工作记忆、独立版本化的专业知识。健康事实不能简单作为聊天全文永久向量化；检索必须先按身份、租户、用途和有效期过滤，再查相似度。

撤权要停止新采集和新推断、取消排队任务、失效依赖计划、处理分析派生物与缓存；保留或删除哪些审计记录及备份按核准保留政策执行。撤权不能只删除前台授权标识。

追踪保存决策输入摘要/版本、工具与计算输出、规则命中、计划版本和用户确认；不记录模型隐含推理或明文凭据。用户输入、设备文本和知识文档都视为不可信内容，不得改变工具权限。生产日志脱敏，外部模型网关限制数据范围和留存策略。

WHO 对健康场景大模型的指导强调其用途与能力仍需验证；本设计据此将 LLM 解释与确定性计算、专业责任分开。WHO 大模型健康应用指导

9. 如何验证“能用、愿用、有效、值得付费”

建议八周探索试点，周期从接入与人员条件就绪后开始，不是排定上线承诺。

可讨论30–60人探索规模，具体依招募、服务能力与风险决定；不是证明疗效的样本量。统计负责人根据主终点、基线变异、最小值得做的差异和流失率决定正式样本量。联合服务包的效果不能单独归功于某个 Agent。

安全测试中已知越权、过敏/规则硬约束绕过、重复写入和错误身份关联应为零；这是测试门槛，不能保证现实零风险。试点出现严重问题即暂停相关路径，由专业负责人决定恢复。

业务数值门槛在基线后、比较试验前冻结，标明继续/延长/停止条件和负责人。执行率与留存可以先验证，健康效果需适当随访与独立评估。只做八周不能声称90天净贡献已经验证。

商业单独建账：机构服务费、个人订阅、营养品交易。贡献计算扣除推理/API、人工、渠道、设备分摊、供应维护、退款与履约成本。营养品销售不能改变健康推荐排序；不购买营养品也应获得完整基础建议。

10. 最小产品、扩展路径与责任

V0：一站点、本人授权、可供应饮食组合、审核运动模板、实吃/实动反馈、人工例外、每周复盘。先完成吃动执行链，聊天作为入口之一。

V1：在V0门槛通过后增加一个体健之星或科训数据接口；用影子模式比较是否提供增量。V2：跨场景标准化与个性化模型，必须分别验证不同人群和客户的适用性。

建议分工（岗位，不是已指派人员）：产品负责人锁人群与主终点；数据负责人核资产和数据合同；营养/运动负责人审规则与承接例外；研发负责接口与一致性；测试负责失败路径；试点运营负责参与和退出；财务/业务负责单位经济性。

进入开发前需关闭五项P0：首个人群/站点与业务Owner；获准数据源和字段；跨系统身份方案；专业责任人与规则范围；试点终点/预算/服务容量。当前 DoR: BLOCKED 表示开发条件待确认，不影响本轮概念方案交付。

11. 后续设计与工程输入

详见 Use Case 执行合同。系统地图：UC-AIW-001 授权与关联→UC-AIW-002 今日计划→UC-AIW-003 执行反馈→UC-AIW-004 动态调整/专业承接→UC-AIW-005 周复盘/退出；UC-AIW-006 数据接入与效果分析横向支撑。

UML后续任务：①系统上下文图标出客户/平台/个人/专业服务边界；②时序图覆盖并行候选、版本冲突、撤权与超时；③状态图分开计划/订单/取餐/实吃；④部署图只在真实环境和数据流核验后标具体组件。当前六层表是逻辑设计，不是已部署拓扑。

原型后续任务：优先小程序“今日、就餐确认、运动反馈、周复盘、授权中心”五页，再做专业工作台和食堂供应维护；每页必须覆盖空数据、拒绝授权、待人工、供应不足、超时与完成状态。先连通一个当天闭环，再美化完整产品。当前没有生成可运行小程序或高保真原型。

最终应形成的能力：知道什么、建议什么、是否可执行、实际做了什么、结果如何、下一次怎样调整，全部有版本和证据。