用AI编程工具为父亲开发慢病管理小程序
为什么做这个项目
2025年底，我决定转行做AI产品经理。
看课、读书、写文档，这些方式我都试过。但我始终觉得，真正的产品经理能力，是在约束条件下解决真实问题的能力。我需要一场实战。
真实问题来自我的父亲。他58岁，高血压多年，近期体检发现血糖也偏高。他的日常是：
- 每天早晚各测一次血压，记在本子上，本子经常找不到
- 吃降压药，但偶尔忘记有没有吃过
- 想告诉我他的血压控制情况，电话里说不清具体数字
- 我、弟弟、妹妹，三个人都想知道他的健康状况，但信息零散
我看过市面上的健康App。功能太复杂，父亲学不会；要么只做血糖，要么只做血压，没有联动分析；更没有"子女远程查看"的设计——它们都是给患者本人用的，不是给家庭用的。
我的目标很简单：开发一个以血压为主、血糖为辅的家庭慢病管理工具，让父亲3秒完成记录，让我们每周收到一份AI生成的健康周报。
第一阶段：产品定位——从"血糖助手"到"双亲健康"
我犯的第一个错误：从技术出发
一开始，我兴奋于AI视觉识别的能力。拍照识别食物GI值，计算血糖负荷，这很酷。我开始做"血糖分析助手"。
但当我把原型给父亲看时，他说：我主要是血压高，血糖是医生顺便让我关注的。我愣住了。我花了两周研究食物识别算法，却发现产品定位错了。关键洞察：技术酷不酷不重要，重要的是这是谁的产品。父亲的主要痛点是高血压，血糖只是辅助监测。如果定位错误，他会觉得"这不是为我做的"，然后放弃使用。
合并还是独立？一个关键决策
我画了两种架构：
| 方案 | 我的纠结 |
|---|---|
| 独立血压App | 功能专注，但父亲需要下载两个App，数据割裂 |
| 合并为慢病助手 | 血压血糖联动分析有价值，但功能复杂度增加 |
决策依据：我查到中国60%的糖尿病患者伴有高血压，医学上叫"三高共管"。父亲的情况不是特例，是普遍需求。
产品定位升级为双亲健康——血压血糖双管理，子女远程监护。这个名字有两层意思：一是父母双亲，二是血压血糖双重指标。
聚焦MVP：不做全量用户
我画了用户矩阵：确诊糖尿病患者、糖尿病前期、减脂人群、孕妇、术后康复……
最终聚焦三高共管——高血压+糖尿病前期共病患者，像父亲这样的人。他们的需求最明确：简单记录、趋势可见、子女知情。
第二阶段：技术选型——AI能力和工程约束的取舍
选型的弯路：我以为买了就能用
我买了字节方舟的Coding套餐，想着能直接调用AI能力。结果发现：Coding套餐只能用于AI编程工具（如Trae）写代码，不能用于我自己开发的应用调用API。
这是我第一次理解ToB产品（AI工具）和ToD（开发者服务）的权限边界。我重新开通了按量付费的视觉模型，多花了时间，但学到了重要一课：产品经理必须理解技术方案的成本结构和权限限制，不能只看Demo效果。
最终技术栈
| 功能 | 方案 | 理由 |
|---|---|---|
| 血压计屏幕识别 | 火山方舟Doubao-1.5-vision-pro-32k | 多模态理解，Base64图片传入 |
| 食物GI识别 | 百度菜品识别API | 免费500次/天，中餐优化好，MVP够用 |
| 数据存储 | 微信云开发数据库 | 按openid隔离，支持多设备同步，为家庭共享铺路 |
数据存储的转向
最初我用wx.getStorageSync本地存储，图快。但很快发现两个问题：父亲换手机数据会丢，更重要的是——我和弟弟妹妹看不到数据。
迁移到微信云开发数据库，意味着重新设计数据模型，但这一步必须做。产品价值不只是"父亲记录"，而是"家庭共享"。
第三阶段：UX设计——为父亲做减法
首页重构：血压优先的双核心布局
最初的设计里，血糖功能占据主导，血压入口隐藏在悬浮按钮的二级菜单。父亲测试时，找了半天才找到记血压的地方。
我重新设计了首页：
- 左右并列两个圆形进度卡片：左侧血压（放大突出），右侧血糖（缩小辅助）
- 快捷记录按钮：左侧"记血压"（医疗蓝色，大尺寸），右侧"记血糖"（绿色，小尺寸）
- 时间轴分区：上半部分血压（晨起/服药/睡前，默认展开），下半部分血糖（可收起）
验证标准：父亲打开小程序，3秒内知道该点哪里。他做到了。
阶段目标重构：从单一到联动
原有设计只有"控糖/减脂/增肌/妊娠期"，完全忽略高血压场景。我意识到这是"年轻用户偏见"——健康App的设计者往往是年轻健身人群，而中老年慢病用户被忽视了。
我重构为6个综合目标：
- 降压为主（单纯高血压）
- 控糖为主（单纯糖尿病）
- 三高共管⭐（父亲场景） 4.稳压控糖（波动大患者）
- 并发症预防（早期病变迹象）
- 术后/病后康复
智能推荐逻辑：基于7天数据自动推荐。如"血压超标3天+血糖正常"→推荐"降压为主"，并自动调整目标值和监测频率。
提醒功能：医学依据驱动
我查资料时发现：餐后30-120分钟是"餐后低血压"高发时段，且餐后血糖与血压存在关联。这是医学细节，但产品价值很大。
我设计了餐后综合提醒：
- 餐后2小时：血糖提醒（金标准）
- 餐后30-60分钟：血压提醒（预防餐后低血压）
父亲不需要懂医学术语，他只需要知道"饭后半小时再测一次血压"。
第四阶段：工程实现——在报错中理解系统构建
订阅消息：理想与现实的差距
我最初的设想是完美的：每周日20:00，AI生成周报，自动推送到家庭微信群。
现实是：微信公共模板库没有"长期订阅"模板，只有"一次性订阅"。这意味着用户每周都要手动点击授权，体验大打折扣。
我纠结了两天，最终决定：先用一次性订阅测试，接受体验折损，验证核心流程。如果验证成功，再考虑申请长期订阅模板或转向服务号方案。
这是产品经理的核心能力——在约束条件下做决策，而不是等待完美条件。
我的踩坑记录
| 报错 | 我的排查过程 | 解决 |
|---|---|---|
Cannot find module 'wx-server-sdk' | 云函数部署后报错，查文档发现依赖未安装 | npm install + 云端安装依赖 |
data.number1.value is empty | 日志显示调用成功，但微信没收到消息，仔细看日志发现返回errCode: 47003 | 核对模板详情页，确认number1是血压高压，代码里字段名写错 |
data.thing7.value is empty | 继续报错，发现代码写了thing7，但模板只有thing4 | 严格对照模板字段：number1/number2/number3/thing4/time5 |
| 消息发送成功但未收到 | 日志显示"调用成功"是假象，实际返回错误被忽略 | 添加详细日志打印，发现字段值为空字符串 |
关键学习：微信生态的产品经理，必须仔细阅读平台文档的字段说明和类型限制，不能凭假设开发。number类型最多32字符，thing最多20字符，time必须是YYYY-MM-DD HH:MM格式，这些细节决定成败。
当前进展
✅ 血压记录（手动输入+拍照识别血压计屏幕）
✅ 血糖记录（食物拍照识别+GI/GL计算）
✅ 云开发数据库存储，按openid隔离用户
✅ 一次性订阅消息推送（测试中，字段匹配已修复）
✅ AI周报生成（数据汇总→Prompt设计→定时触发器）
⏳ 家庭共享（多人订阅、权限管理、异常预警）
我学到了什么
翻译能力：三层语言的转换
做AI产品经理，我每天都在翻译：
| 层级 | 父亲的语言 | 我的翻译 |
|---|---|---|
| 用户语言 | "我想知道血压控制得怎么样" | 每周生成血压趋势图+达标率+异常提醒 |
| 产品语言 | 子女远程查看功能 | 云函数定时触发→聚合查询→AI Prompt→订阅消息推送 |
| 技术语言 | 拍照识别血压计 | Base64编码→火山方舟API→JSON解析→数据校验→本地存储 |
数据闭环：从记录到情感连接
父亲测量（拍照/手动）→ 云端存储 → AI分析生成周报 → 推送子女微信 → 查看后电话提醒父亲 → 父亲调整行为
从工具到情感
- 起点：学习AI编程工具Trae的使用
- 转折：发现父亲的真实需求，产品有了情感锚点
- 终点：产品名称"双亲健康"，Slogan"双亲健康，子女心安"
下一步计划
| 阶段 | 任务 | 我的目标 |
|---|---|---|
| 当前 | 修复订阅消息字段匹配，跑通推送链路 | 我和弟弟妹妹能收到第一条AI周报 |
| 短期 | 完善AI Prompt，生成结构化健康报告 | 报告包含：总体评估、关键亮点、风险提示、下周建议 |
| 中期 | 家庭共享功能：多人订阅、权限管理、异常预警 | 弟弟妹妹也能订阅，血压危象时立即通知 |
| 长期 | 数据导出PDF、就医支持、医生端对接 | 成为医患沟通的工具，父亲复诊时有数据可依 |
给转行AI产品经理的同学
三个我从实战中学到的建议： 1. 用真实需求驱动学习为自己或家人做产品，动力更强，理解更深。技术细节会忘，但"父亲每周收到周报时的反馈"会记住。当你知道谁在用你的产品，你会做出完全不同的决策。2. 接受不完美的MVP我理想中是长期订阅自动推送，现实是一次性订阅每周手动授权。但MVP阶段，能跑通的方案就是好方案。不要等待完美条件，在约束中做决策才是产品经理的核心能力。3. 技术理解要到底层不只是"调API"，要理解Base64编码、openid隔离、云函数冷启动、模板字段类型限制。这些细节决定产品能否落地。AI产品经理不需要写所有代码，但必须知道边界在哪里。
--- 项目信息
- 产品名称：双亲健康
- 技术栈：微信小程序 + 微信云开发 + 百度AI + 火山方舟
- 开发工具：Trae+Claude code（AI编程）
- 当前状态：MVP测试中，欢迎交流