分类: BUG心得

把 AI 对话界面改成结构化录入界面，视觉上换掉聊天气泡只要改样式。但 HealthLoop 的实践证明：每次局部修复之后，下一种用户输入又会把聊天气泡带回来。这不是偶然，是重构姿势的必然结果。 现象 今日页视觉已经改成极简手帐：没有气泡、没有对话流，输入后应该出现的是字段补全弹层和候选确认。但实际

微信主包 2MB 硬限，是每个小程序开发者都绕不开的一道墙。这篇文章记录 HealthLoop（一个 AI 健康记录小程序）两次被这道墙打回来的完整过程，以及最后沉淀下来的治理方法。 第一次撞墙：2393KB 超限，元凶不是业务代码 上传体验版时，开发者工具报 source size 2393KB

1. 现象 在 pi-web 的界面里，给自定义模型（自建 vLLM 部署的 Qwen 系 27B 推理模型，OpenAI Responses 兼容协议）选择思考级别（reasoning level）时： 下拉框里最高只有 medium，看不到 xhigh； 在设置里把级别手动改成 xhigh 之后

小程序页面天然是"多异步请求并发 + 用户随时切走"的环境。数据回写旧值、错误提示被清掉、旧账号的响应盖住新账号的输入——这类 bug 有一个共同形态：代码没错，时序错了。本文从 HealthLoop 的四次真实故障里，把竞态守卫从第一代演进到第 N 代的过程整理出来。 第一代：布尔锁（防重复点击）

健康类应用里，数据错了比功能少了更致命。这篇文章收集 HealthLoop 四次真实故障，它们的共同点是：单看每一行代码都对，合起来会悄悄弄丢或弄脏用户数据。 一、软删除记录被误判为"不存在"，重复删除直接报错 实现健康记录删除时，自测里"重复删除应幂等返回计数 0"的用例炸了：第二次删除抛 REC

饮食页此前是个占位壳：一段说明文 + 当前日期 + 一句"页面状态会按账号保留"。需求要把它变成真页面：按日期回看、按餐次分组、能量区间与缺口一目了然。 本轮最值得记的不是页面本身，而是两个判断：这个需求其实不需要动云端，以及"能回看"不等于"能补录"。 判断一：先看云端能不能用 按惯例，"做新页面

这篇记的是「训练历史与记录修正」功能里最迷惑的一次排查：代码改对了，同步脚本一跑，改动没了，而报错信息完全不指向被覆盖的文件。 项目的双目录结构 这个项目里 shared/ 是领域逻辑的真源，miniprogram/shared/ 是微信运行时能加载的镜像副本，同步方向固定为 root → mini

社区是 HealthLoop 四个 Tab 之一，但它的需求里有一条不太起眼、却决定整轮工作量的规则： 在审核、平台类目和运营能力完成前，社区 Tab 仅展示明确的未开放状态，不提供伪造互动。 这条规则的存在意义，是防止一件很常见的事：为了"看起来在做"，先放一个假信息流——几张示例帖、几个点赞数、

「我的」页极简改造：主屏只留头像、昵称和六行设置。这篇记的是第一批——先做「隐私与数据」二级页和它背后的共享删除流程。 之所以从这个"最不显眼"的部分开始，是因为它有一条硬约束： 本需求仅改变信息架构与界面位置，不以隐藏入口替代功能交付。新增二级页必须与主屏改造同批交付；二级页尚未可用时，不得先移除

日期：2026-09-24 站点：https://high33light.cn（控制台 /console） 仓库：github.com/gaogaohang/halo-gao（fork 自 halo-dev/halo） 涉及版本：Halo 2.23.0 → 2.26.1；应用市场插件 1.12.0