【GPASS AI眼镜大赛】血压管家：把"测完就忘"的血压数据变成随身健康管家——19节点工作流 + 多模态 + 真机踩坑实录与优化解决方案
关键词：AI眼镜 · 血压管家 · 百宝箱工作流 · 多模态Agent · 真机踩坑实录与优化解决方案 · GPASS开发者大赛
适用平台：支付宝百宝箱（GPASS 智能眼镜应用模板）
参赛赛道：赛道1「AI 眼镜赋能生活健康」+ 赛道4「无显示 AI 眼镜」
一句话作品 Slogan：一眼读懂血压，AI 眼镜里的健康管家。
作者：王骅 Tim
摘要
本项目是一款专为支付宝GPASS AI眼镜开发的低代码应用，旨在解决高血压人群日常监测与数据管理的核心痛点，构建了一个从设备唤醒、读数识别到专业解读、历史分析的端到端智能体工作流。
核心能力：语音唤醒 → 第一视角拍照识别血压计读数 → 医疗大模型实时解读 → 历史趋势回溯分析。
技术栈：Ling-2.6-1T（意图识别）+ Qwen3.7-plus（多模态读数）+ 蚂蚁·安诊儿医疗大模型（专业建议）+ 自定义数据库插件（异步存储）。
文章覆盖：产品定义、技术方案说明、19节点工作流架构总览、端侧/云端插件运用、真机踩坑实录与优化方案。
一、项目背景与产品定义
1.1 我们要解决的真实痛点
家里有血压计的人都知道一种尴尬：测量时盯着屏幕记数字，测完就忘；等到头晕不适，翻遍纸笔和手机也找不出"这段时间血压到底是升是降"。
根据用户调研，我们将测量血压场景的核心痛点收敛为四点：
| 痛点 | 具体表现 |
|---|---|
| 数据孤岛 | 测过就忘，纸笔/App记录割裂，难以形成连续记录 |
| 缺乏专业解读 | 血压计只会给数字，没有分析和解读数字背后的健康建议 |
| 异常响应不及时 | 出现血压异动时没有即时提醒与应对建议 |
| 趋势回溯难 | 历史数据无法分析，医生问诊时难以拿出完整记录 |
为什么非眼镜不可？
纸笔能记，但效率太低，没有专业分析解读——最传统原始的解决方案。
用手机呢？——当下最常见的解决方案。
高血压患者每天需要测量 1-2 次血压，这是一个高频且固定的场景：坐在桌前，卷起袖子，绑好袖带，按下血压计。
测完之后，问题来了：
| 对比维度 | 📱 手机 App | 👓 AI 眼镜（血压管家） |
|---|---|---|
| 操作步骤 | ①测完血压 → ②找手机 → ③解锁 → ④打开App → ⑤手动输入/拍照 → ⑥查看结果（5步） | ①测完血压 → ②眼镜自动识别（1步） |
| 双手状态 | 需要单手操作手机（诸多不便） | 双手完全解放 |
| 耗时 | 30-60秒 | 3-5秒 |
| 使用门槛 | 中老年人需要学习App操作 | 语音唤醒，零学习成本 |
| 隐私性 | 手机屏幕可能被旁人看到其他敏感信息 | 眼镜近眼显示/私密语音播报 |
核心论点：高血压患者测完血压时，双手处于被占用或不便状态，掏出手机打开App的操作路径繁琐且抵触。AI 眼镜以第一视角自动识别血压计屏幕数据，实现「测完即记录、看完即分析」的零额外操作闭环——这是手机 App 无法替代的核心优势。
同时，语音播报能力，让不习惯智能设备的老年用户也能轻松获取健康建议，真正实现「科技适老」。
1.2 产品定位
一句话定位：戴上眼镜，说句话，血压数据自动留存、即时解读、长期追踪——让健康管理"解放双手、随身陪伴"。
血压管家是一款面向关注个人健康的高血压或潜在高血压用户，在测量血压场景中，帮助解决血压数据孤岛、缺乏专业解读与健康改善建议的AI产品。
交互闭环：
语音唤醒 → 意图识别 → 硬件拍照/查库 → 多模态识别/医疗分析 → 专业解读与建议 → 卡片/语音播报目标用户：中国2.45亿高血压患者 + 潜在高血压人群，覆盖中青年至老年全年龄段。
1.3 用户粘性设计
场景绑定：天然高频入口
量血压是高血压患者的高频刚性需求——每天测量 1-2 次，常年坚持。血压管家与「测量血压」这一动作深度绑定：用户每次测量血压时，眼镜自动识别记录，形成测→记→析的完整闭环。
这意味着：只要用户还在量血压，就会反复使用血压管家。粘性不是靠「运营手段」拉回来的，而是生长在用户的日常健康行为中。
场景延伸：非测量时的日活支撑
在不测量血压的其他时段，用户同样可以唤醒应用：
- 🗣️随时随地语音查询：「乐奇，血压管家，我最近一周血压怎么样？」——安诊儿基于历史数据生成趋势分析
- 💬健康咨询：「血压偏高该注意什么饮食？」——安诊儿提供个性化健康建议
- 📊趋势回顾：每次测量后与上次数据对比（升高/降低/持平），用户有动力持续测量观察趋势变化
这些「非测量场景」为应用的日活跃度提供了有力支撑，让血压管家从「测量工具」升级为「随身健康顾问」。
1.4 商业落地路径
血压管家从 To C、To B、To G 三条路径构建商业模型：
To C：个人健康订阅服务
- 基础版（免费）：血压记录 + 单次解读 + 7天趋势
- 进阶版（订阅）：月度/季度健康报告、多指标趋势分析、个性化饮食运动建议、家属共享
- 目标用户：中国约 2.45 亿高血压患者中，有健康管理意识且愿意付费的中青年及家属群体
To B：企业合作与生态嵌入
- 血压计厂商合作：与欧姆龙、鱼跃等家用血压计品牌合作，眼镜端识别能力作为产品增值功能预装/联名推广
- 慢病管理平台：为第三方慢病管理SaaS平台提供AI眼镜端数据采集能力，嵌入企业健康管理方案
- 保险公司合作：作为健康管理增值服务嵌入健康险产品——用户持续监测血压可获得保费优惠
To G：公共健康与医保场景
- 社区慢病管理：面向基层社区卫生服务中心，AI眼镜辅助家庭医生团队高效完成辖区高血压患者随访和数据收集
- 医保控费：高血压慢病管理是医保控费重点方向，持续监测数据可支撑按疗效付费（P4P）模式，降低并发症住院率
- 人口健康普查：面向区域性高血压筛查和健康普查场景，AI眼镜提供便携式数据采集终端
💡生态协同：血压管家核心使用的「蚂蚁·安诊儿」医疗大模型本身属于蚂蚁生态，未来可借助支付宝医疗健康板块的医院挂号、在线问诊、医保支付等能力，实现「监测→解读→就医→支付」的完整闭环。
二、平台认知与技术选型
2.1 为什么选择支付宝百宝箱
GPASS是蚂蚁集团面向AI眼镜（Rokid乐奇等硬件厂商）推出的智能体开发平台，底层跑在支付宝「百宝箱」上。它把眼镜的语音、拍照等硬件能力封装成可视化工作流节点，用拖拽连线的DAG方式即可编排出一个Agent，无需关心眼镜硬件底层。
2.2 模型选型策略
综合对比性能与效果，我们确定了"快—准—专"三层模型协作策略：
| 任务 | 模型 | 选型理由 |
|---|---|---|
| 意图识别 | Ling-2.6-1T | 轻量快速，把"看血压/查历史/闲聊"三类路由判断做得又准又省时 |
| 多模态识别 | Qwen3.7-plus | 中文场景OCR与界面理解能力强，准确识别血压计屏幕数字 |
| 医疗建议 | 蚂蚁·安诊儿医疗大模型 | 专业医疗级分析，输出可信的解读、预警与个性化健康建议 |
选型原则：意图识别要"快而准"、视觉识别要"看得清"、医疗分析要"信得过"。任务有多难就用多大的模型，三层职责分离，各用最合适的模型。
三、整体工作流架构设计
3.1 架构总览
本项目同时参加赛道1（有屏）与赛道4（无屏），从用户体验出发对工作流做了大量测试与优化，最终精炼为19个节点。下面是工作流架构总览：
3.2 五大设计要点
| 设计要点 | 说明 | 对应体验价值 |
|---|---|---|
| 端侧拦截守门员 | 唤醒后第一个节点判断拦截端侧冗余提示词，直接回固定话术 | 避免AI乱答，确保首次交互品质 |
| 意图三路分离 | 意图识别后将请求路由到"拍照测量/历史查询/健康咨询"三条独立链路 | 链路职责清晰，可独立优化 |
| 过渡话术前置 | 调用耗时模型前先通过"直接回复"节点给出等待话术 | 消除3-5秒静默等待的焦虑感 |
| 数据库异步解耦 | 存储与查询均采用异步操作，不阻塞主线工作流 | 用户全程无感等待 |
| 双赛道兼容 | 有屏走信息流卡片，无屏走纯语音播报，同一工作流覆盖 | 一次开发，双赛道复用 |
3.3 意图三路分离路由
工作流启动后，Ling-2.6-1T 基于用户输入进行三分类路由：
用户语音输入 │ ▼ ┌─────────────────┐ │ Ling-2.6-1T │ │ 意图识别路由 │ └───┬─────┬───────┘ │ │ │ ▼ ▼ ▼ 意图A 意图B 意图C 「拍照」 「查询」 「咨询」 │ │ │ ▼ ▼ ▼ 拍照链路 历史链路 追问链路- 意图A「拍照测血压」：用户对着血压计屏幕 → 调用眼镜摄像头拍摄 → Qwen3.7-plus 识别读数 → 安诊儿解读本次数据 → 异步写入数据库
- 意图B「查历史趋势」：用户问"最近血压怎么样" → 查询数据库 → 安诊儿综合分析趋势 → 输出结论与建议
- 意图C「健康咨询」：用户追问健康问题 → 安诊儿结合个人历史数据进行个性化答疑
三条链路职责清晰，单链路出问题不影响其他功能，可独立优化和调试。
四、19节点工作流详解
4.1 节点全景图
| 节点序号 | 节点类型 | 节点名称 | 所属链路 | 职责 |
|---|---|---|---|---|
| 1 | 开始 | 用户输入 | 全局入口 | 接收语音输入 |
| 2 | 分支 | 端侧拦截判断 | 全局入口 | 过滤端侧注入的冗余提示词 |
| 3 | 直接回复 | 固定欢迎语 | 拦截分支 | 命中拦截时回复固定话术 |
| 4 | 大模型 | 意图识别 | 意图路由 | Ling-2.6-1T三分类路由 |
| 5 | 端侧插件 | 眼镜拍照采集 | 拍照链路 | 调用眼镜摄像头拍摄血压计 |
| 6 | 直接回复 | 等待话术 | 拍照链路 | “收到，正在为您分析，请稍后…” |
| 7 | 大模型 | 多模态读数识别 | 拍照链路 | Qwen3.7-plus识别血压值 |
| 8 | 自定义插件 | 异步写入数据库 | 拍照链路 | 将识别结果写入数据库 |
| 9 | 数据处理 | JSON反序列化 | 拍照链路 | 将大模型返回数据进行处理 |
| 10 | 话术拼装 | 文本处理 | 拍照链路 | 拼装本次数据解读 |
| 11 | 云端插件 | 信息流卡片 | 拍照链路 | 完整展示解读与建议 |
| 12 | 直接回复 | 查询等待话术 | 历史链路 | “好的，正在为您查询，请稍后…” |
| 13 | 自定义插件 | 查询数据库 | 历史链路 | 查询用户历史血压记录 |
| 14 | 大模型 | 医疗大模型血压趋势分析 | 历史链路 | 安诊儿综合分析评估 |
| 15 | 云端插件 | 信息流卡片 | 历史链路 | 完整展示趋势结论与建议 |
| 16 | 大模型 | 安诊儿答疑 | 追问链路 | 处理健康咨询/追问 |
| 17 | 云端插件 | 信息流卡片 | 追问链路 | 展示回复 |
| 18 | 结束 | 结束 | 全链路 | 结束本轮工作流 |
| 19 | 端侧插件 | 退出 | 全链路 | 调用端侧退出指令 |
五、插件体系详解
5.1 插件清单
| 插件 | 类型 | 来源 | 用途 | 关键特性 |
|---|---|---|---|---|
| 眼镜设备拍照采集 | 端侧 | 官方 | 调用眼镜第一视角摄像头拍摄血压计屏幕 | 无需输入参数，输出图片URL |
| GPASS眼镜-信息流卡片 | 云端 | 官方 | 承载长篇专业健康建议的展示 | 替换默认问答卡片（后者文字截断） |
| 血压数据存储插件 | 云端 | 自写 | 将多模态识别结果写入用户数据库 | 异步执行，不阻塞主线 |
| 血压数据查询插件 | 云端 | 自写 | 查询用户历史血压记录供趋势分析 | 返回最近10条数据和avg/max/min统计 |
为什么弃用默认问答卡片？回复大量专业健康建议时，默认问答卡片文字显示不全、体验差。改用信息流卡片后内容能完整呈现，且无屏眼镜也能通过语音播报覆盖。
异步设计关键收益：
| 无异步 | 有异步（本方案） |
|---|---|
| 用户说"看血压" → 拍照 → 存库（等待1-2秒） → 解读 → 回复 | 用户说"看血压" → 拍照 → 存库（后台异步） → 解读 → 回复 |
| 总耗时 = 拍照+存库+解读 | 总耗时 = 拍照+解读（存库不增加任何等待） |
六、模型选型策略
三层模型各司其职，在性能与专业度之间取得最优平衡：
| 模型 | 角色 | 定位 | 关键能力 | 延迟 |
|---|---|---|---|---|
| Ling-2.6-1T | 🧭 路由器 | 意图分发 | 轻量三分类，快而准 | <500ms |
| Qwen3.7-plus | 👁️ 眼睛 | 视觉理解 | 中文OCR+结构化输出 | 1-3s |
| 蚂蚁·安诊儿 | 🧠 大脑 | 专业决策 | 医疗级解读+合规建议 | 2-5s |
核心原则：意图识别要"快"——轻量模型零负担路由；视觉识别要"准"——多模态能力精准读数；医疗分析要"专"——垂域大模型安全可信。三者职责切干净，不越界。
七、安全与合规
7.1 医疗场景安全围栏
健康类智能体必须建立安全底线。血压管家在以下层面构建多层安全围栏：
（1）提示词安全围栏
在多模态读数识别和医疗建议生成阶段，Prompt 中嵌入以下安全约束：
- 🚫绝对禁止：不得给出绝对化诊断结论（如「您患有高血压」）
- ✅标准表述：始终使用「根据本次测量数据，您的收缩压偏高，建议…」「该数值处于高血压1级范围，建议就医进一步评估」
- 🚫禁止行为：不得替代医生开具处方、调整药物剂量、给出治疗方案
- 🚫禁止输出元信息：「以上共XX字」等字数统计、模型自述等非健康建议内容一律禁止
（2）血压分级预警矩阵
| 分级 | 收缩压(mmHg) | 舒张压(mmHg) | 系统话术策略 |
|---|---|---|---|
| 正常 | <120 | <80 | 告知正常，鼓励保持 |
| 偏高 | 120-139 | 80-89 | 提示偏高，建议生活方式调整 |
| 高血压1级 | 140-159 | 90-99 | 明确建议就医，提供科室指引 |
| 高血压2级 | 160-179 | 100-109 | 强调尽快就医，提示风险 |
| 高血压3级 | ≥180 | ≥110 | 紧急提醒，建议立即就医 |
（3）兜底机制
- 错误日志记录：异步插件写入/查询失败时，记录失败日志并在下次查询时触发补写，确保数据不丢失。
八、真机体验优化：6个踩坑实录
AI眼镜是受限终端，模拟端正常≠真机正常。以下是我们踩过的6个坑及解法：
| # | 坑 | 现象 | 根因 | 解法 | 经验 |
|---|---|---|---|---|---|
| 1 | 🚫 端侧注入跑偏 | 唤醒后AI回复文不对题 | 端侧自动注入PC模拟时没有的系统提示词 | 首节点分支拦截，命中直接回固定欢迎语 | 真机与模拟端行为不同，第一个节点就要做守门员 |
| 2 | ⏳ 推理静默焦虑 | 视觉/医疗模型思考3-5秒，用户以为卡死 | 大模型推理时无中间反馈 | 调用大模型前先插"直接回复"节点，回过渡话术 | "正在为您分析…"就能把焦虑变期待 |
| 3 | ✂️ 末尾画蛇添足 | 大模型回复后附加"以上共XX字" | 限制字数后模型自发统计 | Prompt末尾加安全围栏：“禁止输出字数统计及任何元信息” | 限制越多，越要在Prompt里明确禁止补偿行为 |
| 4 | 📏 卡片文字截断 | 长篇建议在默认问答卡片中显示不全 | 默认卡片有字数/行数限制 | 改用GPASS信息流卡片，支持滚动完整展示 | 产品形态要匹配内容体量 |
| 5 | 📊 折线图实效 | PC端动态折线图在眼镜上单色模糊、可读性差 | 眼镜屏幕低分辨率+单色显示 | 无奈放弃，改为文字趋势描述 | 可视化要在目标终端上验证，不能只看PC效果 |
| 6 | 🔌 异步插件兜底 | 边缘情况下异步写入可能失败 | 网络波动/数据库瞬时不可用 | 增加retry退避机制+失败日志，下次查询时触发补写 | 异步不等于不管，需要优雅降级 |
九、遗憾与展望
9.1 遗憾：被迫放弃的动态折线图
原本已在PC模拟端实现了用户血压历史记录的数据动态分析折线图效果。但上机实测发现：
- 眼镜端图片效果不佳（单色且细节模糊），可读性差；
- 同时需考虑赛道4无屏兼容，图形在无屏眼镜上完全失效。
综合权衡后无奈放弃。希望官方后续能支持SVG动画效果，解锁更多数据可视化玩法。
9.2 展望：从血压到家庭健康中枢
| 方向 | 描述 | 价值 |
|---|---|---|
| 多指标扩展 | 接入血糖仪、血氧仪、体重秤等家用设备的多模态识别 | 从单指标到全景健康 |
| 家属共享 | 子女远程查看父母血压趋势，异常即时通知 | 家庭慢病共管 |
| SVG可视化 | 官方支持后重新上线动态趋势图、周报月报 | 数据价值最大化 |
结语：四项核心经验
回顾整个开发过程，我们提炼出四条可复用的经验：
- 形态即产品力：不是把手机App搬到眼镜上，而是找到"只有眼镜形态才成立"的交互——血压管家的使用场景和解决痛点决定了智能眼镜是最佳载体
- 低代码≠低质量：百宝箱工作流虽然不用写代码，但19个节点的编排逻辑、Prompt的精细打磨、真机反复联调——这些工程化投入一点都不少。节点越多，对系统思维的考验越大。
- 医疗场景的围栏意识：健康类智能体必须建立安全底线——异常值先建议就医、不替代医生诊断、不给出绝对化承诺。这既是合规要求，也是用户信任的基础。
- 双赛道是镣铐也是翅膀：同时兼容有屏和无屏，确实增加了设计约束（如图形可视化受限），但也倒逼我们做好"语音优先"的核心体验——而这些投入在任何硬件受限的场景中都能复用。
演示视频
【GPASS AI眼镜大赛】血压管家
📌 本文为 GPASS AI 眼镜智能体开发者大赛「血压管家」项目技术文档，供评委与社区参考。
如果觉得有帮助，欢迎点赞、收藏、关注，一起探索 AI 眼镜的更多可能 🚀
