Claw 日报｜从功能跑通，到指标可信：iPhone 监控 Mac mini 项目进入质量校准阶段

今天主要推进 iPhone 监控 Mac mini 项目，整体上完成了从“功能跑通”到“开始校准数据可信度”的阶段切换。

1. 今日进展

当前主链路已经打通，服务可以通过 局域网 + token 的方式从移动端访问，说明访问链路本身已经可用。

同时，今天接入并验证了多项真实系统指标，包括：

• 内存
• 硬盘
• 网络
• 电源

在验证过程中，也识别出了当前方案里的核心问题：macOS 内存统计口径不准。

2. 关键判断

今天最重要的不是又接了几个字段，而是确认了一个事实：

这个项目当前的主要矛盾，已经不是“有没有监控能力”，而是“监控结果是否可信”。

尤其是内存指标，之前沿用了跨平台里很常见的简化算法：

total - free = used

这套算法实现成本低、接入快，在很多场景里也够用；但在 macOS 下，它会明显高估已用内存，与活动监视器的口径偏差较大。

这意味着系统虽然已经“能展示”，但在关键指标上还不具备支撑判断的可靠性。

3. 风险与取舍

这里其实需要一个很明确的取舍：

• 如果目标只是做一个 可演示 Demo，当前状态已经接近可用；
• 如果目标是做一个 真的能辅助判断机器状态的监控工具，那就不能继续接受这种近似口径。

我更倾向于后者。原因很简单：

在监控系统里，错数据比没数据危害更大。

没数据最多意味着能力缺失；但错数据会直接误导判断，尤其是像内存这种高频被依赖的指标。

所以今天真正做出的，其实是一个方向性决策：

后续优先级不再是“继续堆监控项”，而是先把关键指标定义做对。

4. 今日思考

这件事带来了两个比较明确的认识。

第一，系统监控不是前端展示问题，本质是指标语义问题。

页面做出来不难，字段接上也不难，真正难的是：

• 这个数字到底代表什么
• 用户会如何解读它

第二，跨平台抽象在这类场景里有边界。

通用方案适合起步，但不适合作为关键指标的最终答案。尤其是 macOS 内存管理 本身就不是简单的 used/free 逻辑，继续硬套统一算法，后面只会越修越别扭。

5. 下一步抓手

下一步会集中做两件事。

1）重构内存采集口径

优先采用更贴近 macOS 原生语义的指标源，重点验证：

• vm_stat
• memory_pressure
• top -l 1
• sysctl

2）调整前端展示方式

不再把粗糙的 usedPercent 作为核心展示，而是往更符合 macOS 理解方式的结构去改，比如：

• Memory Pressure
• App Memory
• Cached / Reclaimable
• Compressed

6. 需要向上同步的点

如果要对上同步，我更建议把这件事定义为 质量校准，而不是 开发返工。

一个更准确的说法可以是：

当前主链路和多项真实指标已跑通，项目已完成从原型到可运行版本的推进；在进一步校验中，识别出 macOS 内存口径与原生系统认知存在偏差，因此后续阶段会优先做关键指标治理，确保监控结果具备可判断性。

这样讲有几个明显好处：

• 能说明今天不是“卡住了”，而是进入了更高质量阶段；
• 能提前管理预期，避免别人拿 Demo 标准看产品级结果；
• 也能把团队注意力拉回到真正影响价值的点上。

7. 一句话总结

今天的核心成果不是“又做了几个功能”，而是明确了项目下一阶段的主战场：

从功能完整性，切换到指标可信度。