这是 FitTracker 开发日志的简洁版，面向博客读者。 只记录最近做了什么、解决了什么问题、项目推进到哪里，不展开内部调试细节。
当前进度
FitTracker 是一个 HarmonyOS 健身训练记录应用，目标不是只做动作清单，而是把“设定目标 -> 生成计划 -> 执行训练 -> 复盘记录 -> 调整目标”串成一个完整闭环。
截至 2026-09-11，功能主线已经收口，重心转到了“界面重建”这条新主线上：先把设计导出的 HTML 冻结成唯一视觉规格，再逐屏还原成 ArkUI 页面。
Phase 1 基础训练闭环 100%
Phase 2 内容与工具化 100%
Phase 3 回顾与体验修整 100%
Phase 3.5 收口与恢复能力 100%
Phase 4 系统化与扩展能力 100%（内部验收包已收口）
视觉主线 · 15 屏 1:1 重建 代码层完成，设备像素验收收敛中
现在最值得关注的是三件事：
- 15 屏是不是都按同一份 HTML 规格还原，而不是每页各写一套
- 小屏 / 大屏 / 安全区下会不会顶不住
- 设备像素验收还剩哪些屏没跑完
可以看到的功能
下面几张图来自此前的模拟器回归截图（新一轮 1:1 还原的设备截图还没整理进文章）。为了避免手机长截图在文章里占太大空间，这里继续使用小尺寸展示。
目标设置页负责收集训练时长、可用器械和限制肌群，这些信息会直接影响后面的训练计划生成。
动作详情页除了展示步骤和提示，也在为后续更完整的内容库和会员能力做准备。
训练执行页已经可以把输入压缩到最关键的重量与次数，并自动给出 1RM 参考值。
最近做了什么
2026-09-11：把 HarmonyOS 官方工具链接进项目
这一轮做的是“让后面少猜”的准备：把 DevEco 官方的 deveco-cli 能力装进项目，并把本地代理产生的临时目录排除在版本控制之外。
换成普通话讲，就是以后无论人来改还是让 AI 参与改，HarmonyOS 的构建、跑真机、查官方文档都走官方工具链，而不是靠印象里的 API 硬凑。这类改动本身不产生任何新界面，但它决定了后面还原 15 屏时会不会反复踩同一批坑。
2026-09-07：15 屏设计稿冻结成唯一规格，然后并行还原
这是这一轮最大的一次推进，可以拆成三件事看。
第一件是规格冻结。把设计侧导出的 17 个 HTML 快照整体复制进仓库作为只读基线（覆盖 15 条路由），并自动抽出三份清单：路由到页面的落点表、逐屏的动效声明、逐屏的色值与设计令牌对照。从那之后，“这个按钮该多大、这个色值该是多少”不再靠感觉，而是有唯一出处可以查。
第二件是并行还原。这次没有一屏一屏顺着做，而是把每屏拆成互不重叠的单元并行推进，先做公共组件（底部导航、按钮、页面头部、卡片），再分三批铺开：登录 / 注册 / 计划 / 我的，首页 / 回顾 / 训练预览 / 训练执行 / 训练完成 / 动作库，身体数据 / 设置 / 计划组列表 / 计划组详细。
顺带补上了 4 个原来“只有设计、没有实现”的二级页：计划组列表、计划组详细、身体数据、设置。这 4 个页面不是画出来就算，而是同时注册进页面清单和路由常量，真机上从入口点得进去。
第三件是验收口径的修正，也是我觉得最值得记的一条。上一轮定的标准是“内容区像素差不超过 2%”，实际跑下来发现这个门槛根本不可达：浏览器和系统渲染的字体栅格化、边缘抗锯齿天然就有差异，再怎么调也压不到 2%。于是把口径改成更诚实的版本——裁掉状态栏和底部系统带、把文字区域单独掩掉，只看非文字内容的几何、配色和间距是否一致，最终判定以热力图的人工复核为主。
同一天还做了自适应硬化：登录页、注册页、首页、我的页的内容区包了一层滚动容器，小屏上顶不住时可以滚；底部导航的阴影、按压反馈按 HTML 的数值补齐成设计令牌，进度条的填充动画时长也统一收进动效令牌，不再各页自己写一个数字。
2026-08-30：回顾页的肌肉分布图可以点了
回顾页新增了可点击的肌肉分布图：点某一块肌肉，会展开对应的训练明细行。
看起来只是加了一层交互，实际是把“看图”变成“顺着图查数据”。之前回顾页只能告诉用户“这周练得怎么样”，现在可以回答“具体是哪个部位练了、练了多少”。
2026-08-26：回顾页补齐指标卡，顺手做了视觉对比工具
回顾页按原型补上了三张指标卡：体重目标、努力度、估算 1RM，统计区的排布也重新和原型对齐。
同一天还加了一个挺关键的工具：把设计稿截图和设备截图并排比对，输出并排图和差异热力图。后面所有界面还原都靠它给出量化依据，而不是“看着差不多”。首页也顺手修了两处问题：误挂在周节奏卡上的进度条被移除，切回首页时会主动刷新进度数据。
2026-08-25：页面接上真实数据，动效有了统一令牌
之前不少页面还在用占位内容，这一轮把静态页面接到了真实数据流上，并补了一套动效令牌——动画时长、缓动曲线集中定义，组件按令牌取值。另外加了动作收藏服务和动作演示动图，动作库的三列网格改成更稳定的写法（单行筛选标签 + 固定三列），并补了一档完整的演示数据种子，方便回归时一键造出有内容的完整状态。
2026-08-19 ~ 08-21：清掉旧页面，给主线定一个基线
之前项目里同时存在旧版页面、旧路由和归档设计稿，改动时很容易改到已经废弃的地方。这一轮做了三件事：归档旧设计产物、删除旧页面和零引用的功能代码、给当前主线打一个可用基线。
旧文件不是直接删掉，而是整体移动到归档目录并逐条写清处置原因，事后审计还能追溯。
2026-07-20 ~ 07-21：先把仓库理干净，再谈继续开发
这一轮基本是工程卫生：做了一次全仓库文件审计，给顶层产物分类，明确服务层的归属规则（哪些属于通用能力、哪些属于跨功能共享、哪些只属于训练功能），补上启动状态和演示种子工具，刷新了页面与服务层，并把规划类文档整理成能直接执行的形式。
这类工作不会带来新功能，但它决定了后面能不能安全地并行改——也是 9 月那波并行还原能跑起来的前提。
2026-06-12：收口验收，把“做完了”变成可复查的证据
功能主线的收口没有停在口头完成：这一轮补了一份严格的 closeout audit（逐条对照目标，只认能复查的证据）、一份 MVP 内部验收包说明（明确交付边界是未签名安装包 + 验收记录 + 重跑说明），以及备份恢复能力的收口文档——备份范围固定为目标、计划、当前计划指针、训练记录和内容版本，冲突规则写死。
同一天，工程门禁检查和完整测试都跑通了。
2026-06-11：把收口验收和证据链补完整
这轮没有继续加功能，而是把 FitTracker 交付前最缺的“验收材料”补齐了。
新增的 UI acceptance checklist 把页面验收拆成了逐项检查表，closeout audit 则把当前工程状态、验证规则和可复查证据整理得更清楚，方便后续按同一标准收尾。
同时，项目把外部模型服务依赖和本地验证路径分开了：一条是可重复的 closeout evidence check，另一条是不用依赖外部 Midscene 的 live-device probe。这样即使外部服务暂时受限，项目也还能继续推进页面级复查，不会因为单一验证方式卡住。
对普通读者来说，这表示 FitTracker 现在已经从“继续加功能”进入“把页面、流程和发布前验收做实”的阶段。
2026-06-10：会员中心第一次真正落到页面里
这一轮最重要的新进展，是 FitTracker 不再只在文档和底层 service 里谈商业化，而是第一次把“会员中心”做成了一个真实可进入的页面。
现在项目里已经有了独立的 MonetizationHubPage 和 MonetizationHubService。这个页面暂时不接真实支付，但它已经能把三层能力边界讲清楚：
- 免费版保留哪些基础训练能力
- Pro 更适合哪些本地高级能力
- Plus 预留给哪些持续服务能力
更关键的是，它没有为了展示商业化，把主训练链路改成付费墙。当前做法更像是先把“未来会怎么卖、为什么这样分层”讲清楚，再逐步决定以后要不要接真实购买流程。
2026-06-10：回顾页开始区分“最近可看”与“全部历史”
同一天，回顾页也往前推进了一步：现在“全部历史训练记录”已经开始和会员能力挂钩。
这不代表免费用户不能用回顾页，而是项目开始更明确地区分：
- 免费版可以继续看最近一段时间的训练记录
- 更完整的长期历史记录，预留给 Pro 能力
这一步的重要性不在“多了一条限制”，而在“产品边界终于从底层规则长到了真实页面”。项目开始把“哪些能力属于基础体验，哪些属于升级价值”讲得更具体了。
2026-06-09：本地内容同步已经从设计走到了可运行流程
上一轮最关键的进展，是本地内容同步终于从“先写设计文档”走到了“应用里有一条真实可运行的更新路径”。
现在 FitTracker 已经具备了内容包、版本信息、导入逻辑和失败回退路径。应用启动时会优先尝试加载本地数据库内容；如果导入失败，仍然能自动退回到原来的 JSONL 种子库。
这意味着项目已经先把“内容以后怎么升级”这条路铺好了。后面无论是继续扩动作库、补媒体素材，还是考虑更远一点的内容分发，都不用从零搭底座。
2026-06-09：设备受阻时，验证脚本先补稳
最近设备侧还有一个现实问题：当前机器没有稳定可用的 HDC target，所以部分真机或模拟器验证没法完整重跑。
这轮没有硬顶着设备问题空转，而是先把验证脚本补稳：当 HDC target 为空、离线或状态异常时，脚本会更早停下来，明确告诉你问题出在环境，而不是把错误拖到流程后半段才暴露。
这类工作不显眼，但很重要。项目已经进入交付前阶段，很多问题不再只是“功能有没有”，还包括“出了问题后能不能很快判断是代码、设备还是环境”。
一点代码
简洁版只保留几段短代码，用来说明这次设计取向。
底部导航中心胶囊的阴影直接照 HTML 的数值落成令牌，激活态换更重的一档：
static readonly TAB_PILL: ShadowConfig = {
radius: 14,
color: 'rgba(0,0,0,0.30)',
offsetX: 0,
offsetY: 6
}
进度条的填充动画也收进统一令牌，不再各页自己写时长：
static readonly DURATION_PROGRESS: number = 350
项目现在到了哪里
如果把前几轮进展连起来看，FitTracker 现在已经过了“补功能”的阶段，在做的是“把设计稿变成真机上的页面”：
- 视觉有了唯一事实源：设计导出的 HTML 被冻结进仓库，页面变成“对着规格抄”，而不是凭手感调
- 改动可以并行：一屏一个归属，互不重叠，最后统一编译验收
- 验收不再靠“看起来差不多”：有并排图、热力图和写明的达标口径，也承认了哪些指标做不到
还没做完的是设备侧的逐屏验收：15 屏的代码层已经按规格还原，但只有欢迎页和首页跑过完整对比，其余屏还在收敛。
下一步
- 逐屏跑设备截图对比，把 15 屏的像素验收补完
- 补 320 / 360 / 430vp 的小屏大屏冒烟（目前只能做静态审计 + 真机抽测）
- 设计侧 HTML 更新时，走“比对 -> 回写规格 -> 只回归受影响屏”的流程
- 把这一轮还原的设备截图整理进这篇文章