关于本刊

这是猫鱼周刊的第 86 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在

博客：阿猫的博客-猫鱼周刊

RSS：猫鱼周刊

邮件订阅：猫鱼周刊

微信公众号：猫兄的和谐号列车

私信：leslieleung@proton.me

INIT

迟来的新年快乐！这是猫鱼周刊 2026 年的第一期，先祝各位新的一年里万事如意。

如上期所说，元旦假期去了贵州玩，照片摄于荔波小七孔景区。虽然是枯水期，有些景点关闭了，但是主要的景点基本都可以游览，而且景色也不错。因为以前去过九寨沟了，这里的水倒没有特别惊艳，都是清得可以看见底下的水草，不过这边的水基本都是 Tiffany 蓝的颜色，大一点的湖面上还会飘荡着一层若有若无的雾气。

本来上周就应该发这期周刊，但是周末感觉实在太累了，还是决定歇一下。这段时间还是做了不少事，折腾了一下 Miloco（PVE 使用 LXC 部署 Miloco）、更换了新出的领谱人体存在传感器 ES5 以及给 Glean 做了 Electron 和 PWA 适配并且完成了官网的上线和备案等等。

STDIN

当我决定重构项目时

原文链接

关于重构这件事非常有文学色彩的描述，讲述了接手项目、简单维护、做新需求、决定重构、重构翻车、草草收场、铸造新的屎山这个过程。

分享几个我对于「重构」的经验，分别来自于我职业生涯的几个阶段。第一次接触「重构」，还是在大二大三的时候，当时我接手了当时学校里一个比较大的项目，全校几万师生在使用，某个活动签到时，最多会有几千人同时在使用。最初的版本是用 PHP 实现的，经常在大规模活动中崩溃，需要手动重启服务器才能解决。接手维护一段时间之后，我决定用 Java 重构整个项目，正好也带领社团从 PHP 的技术栈过渡到 Java。一点题外话，虽然我现在很讨厌 Java，但回头看这仍然是一个更好的选择，当时的就业环境还没有现在这样差，但是 PHP 的落后和颓势已经很明显；当然，如果现在再让我选，肯定是转 Go。这次重构确实达成了目标，通过把图片资源转移到 CDN 以及从 PHP 迁移到 Java 得到的性能提升，之后的大规模活动中再也没有出现卡死的情况，也不需要开发每次有活动都盯着服务器监控了。这次重构算是很「愣头青」，基本上就是拿 Java 把原来 PHP 的项目重新写了一遍，其实有很多历史遗留的设计问题都没有去改进，不过的确解决了并发的性能问题，所以这个项目在后面校招的时候是一个不错的谈资。

第二次接触「重构」是实习的时候，当时的团队也是在对原来的一个 PHP 项目重构到 Go。这个重构跟我之前做的差不多，也是用新的语言把旧的服务差不多重写一遍，唯一的区别是流程相对更加严谨一点，例如功能和 API 是逐步迁移的，也有做单元测试，同时也会有测试团队来对系统做相对全面的测试。这里的「逐步迁移」指的是新的系统在搭好基础设施之后，新功能会在新系统上实现，新旧系统同时运行，旧功能迁移之后测试通过再切换至新系统的接口。我没法评价这个重构做得好坏，只是老的系统实际上还有一些遗留至今没有迁移完，因为「业务价值」不足以支撑支出人力去做迁移。

再后面，又在工作中接手过不少项目，基本上每一个都会被我喷「写得太烂」，然后闲下来的时候 leader 就会问我有没有想法重构一下。但其实我很少再去做整个项目的重构，更多是在做某个需求的时候，根据我对业务的了解，对某个原来写的特别差的地方做小规模的重构。对于重构这件事，我的理解是：

• 前期的设计如果比较高明，一定程度上能避免后面需要比较大规模的重构
• 重构本质上是清理技术债，如果开发过程中，有恰当的流程保证不要持续引入技术债务，或者定期清理技术债务（例如上面说到的「小规模重构」），则很多时候不至于需要重构
• 大刀阔斧的重构收益很低，成本很高，尤其是用一种语言把原来用另一种语言实现的系统重写一遍这种事

AI 可能不会改变许多工作

原文链接

我一直反对 「AI 颠覆论」，之前也反复提过，营造焦虑只是一些培训班用来卖课的技巧。这篇文章提供了一个很新鲜的视角，从「劳动数字化程度」的角度来考虑 AI 对于就业岗位的冲击，例如：

在中国，每 10 个劳动者中，约有 4 个人（32.15% 至 39%）从事的工作，其核心流程完全不需要计算机、平板或智能手机的操作。

截至 2025 年，全球约有 58.6% 的劳动者，在工作中完全不需要计算机操作。

这些岗位并不会被 AI 取代，因为「他们仍以物理世界的“原子”为主要操作对象」，除非人形机器人迅速普及，否则难以影响他们的工作。当然，AI 更多影响的其实是例如软件工程师这种完全通过数字化方式完成工作的人。

最近 Claude 推出了 cowork 功能，可以视为是 Claude Code 功能应用到日常工作生活场景，从对代码文件的处理变成对常用办公格式的处理。另外你看大多数大模型厂商大头的业务除了面向 B 端卖 API，C 端的业务除了卖 coding plan 和做 chatbot，基本没有别的形式。所以其实真正大规模在日常使用 AI 的职业基本只有程序员，甚至只是一小部分程序员，因为还有一部分公司出于「数据安全」的考虑不允许使用，也有一部分程序员认为 AI 会影响他们的编程的技能而坚持「古法手工编程」。

当然，AI 的普及是必然的趋势，只是它并不是颠覆性的，会一点点去改善我们工作乃至日常生活，而且这个影响早就已经开始了。后面关于水银体温计的纪录片里就能看到，一个从上世纪八九十年代开始，厂房和设备非常破旧的厂家，都使用了 CV 的技术来做良品检测。

水银体温计为何要甩一甩？「寻找童年 14 水银温度计」

视频链接

一部关于水银体温计的纪录片。由于《关于汞的水俣公约》 ，我国自 2026 年 1 月 1 日起，禁止生产含汞体温计和含汞血压计，这部纪录片去洪江正兴医疗仪表厂进行了拍摄，对一些主要的工序都进行了介绍，有不少影像资料。

上面提到的，这家厂从上世纪八九十年代开始做，厂房和设备其实都很老旧，而且不少工序都是手工完成的。

但是在这样的条件下，居然有的工序是引进了 CV 的技术去做良品检测，跟后面泛黄的老报纸一对比，实在很大的反差。

我记得 10 年左右的时候，正是电子血压计逐渐成为主流的时候，那时候价格比较高，也有很多言论说手动的比较准，医生诊室里也会有一个手动的血压计。然而到现在几乎都见不到手动的血压计了，无论是专业还是市场，都很好地接受了电子血压计，想必除了汞公约的原因，准确性应该也是得到了验证。当然，好像目前医院做准确的测量还在使用水银体温计，不确定是什么原因。

翻了翻家里的药箱，已经没有最原始的三角棱型的水银体温计了，那种读数真的很难，要对着光在一定的角度才能读出来；倒是有一支后来型号的，在视频中也有提到，不用在玻璃上印字，只需要在玻璃管后面贴一张卡片，这种读数方便很多，但是在发烧头晕晕的时候还是比较麻烦。另外还有两支电子体温计，一支是国产品牌的，之前某次发烧的时候不知道怎么弄坏了，一直显示 Err；另外一支是欧姆龙的，这个是很多医院都在使用的品牌，印象中会比国产品牌稍贵一点。

外观上对比，欧姆龙的使用了一体式的外壳，不容易丢，取用也方便；国产的使用了一个分体的壳，做工稍差。机身来说，欧姆龙除了尖端是金属，整体是一体的，而国产品牌的机身上有很多接缝。

两个产品都做了可更换电池的设计，国产品牌采用的是在后面开盖的方式，这也是它坏掉的原因，整块电路板被我扯出来了，前面温度探头的线断了，电池也不好拿出来。而欧姆龙做了一个电池仓的设计，甚至有防水的胶圈，做工整体优质很多。我觉得体温计这种东西就很需要傻瓜式设计和防呆设计，不只是在功能上，在产品机身、甚至外壳的设计上也要做到傻瓜式和防呆，因为你的用户很可能是老人或者儿童，又或者是发高烧神智不清的人，多一个步骤，多一个可能出故障的点，都会是致命的。

STDOUT

Miloco 和领谱人体存在传感器 ES5 体验

其实 Miloco 完整的体验可以看文章里的使用体验部分，这里就简单总结一下。

之前使用的领谱人体存在传感器经常出现误判的功能，我原本期望 Miloco 能通过基于视觉的方案，实现更精准的判断。实际体验中，Miloco 的反应特别慢，不知道是推理的延迟，还是触发推理的逻辑就有问题，体验远不如人在传感器；在人在传感器无法实现的场景（例如「有人躺在床上」这种语义化的判断），除了上面提到的反应慢，规则之间还会相互打架，例如我在床上盖着被子，一时会被识别为「有人在床上」，一时又会被识别为「没有人在家」，似乎 AI 不太能处理好「人盖着被子」这个场景。

我觉得 Miloco 一个非常大的亮点就是把智能家居的门槛降低了，一句话就能创建对应的规则；另一点就是它是「纯视觉方案」，不再需要依赖传感器，也能更加动态处理事件，例如有人跌倒之类的检测。我觉得再打磨一下，可能会加入到米家，后续也可能推出类似智能网关中枢这样自带 AI 算力的 Miloco 中枢网关。

然后就是之前众筹购买的领谱人体存在传感器 ES5 ，众筹的价格是 ¥59，之前购买的初代人体存在传感器价格是 ¥79，新版增加了一个红外的传感器，用于辅助判断，排除干扰；另外也支持了太阳能板/电池供电，但我都是室内使用，就没有买这个版本。最大的体验是，传感器的灵敏度设置、排除干扰现在是傻瓜式、自动化的，只要直连传感器，人离开房间，然后校准就行了。实测校准之后效果非常好，NAS 硬盘的干扰、睡觉这些 case 都能很好处理。我主要的用途是绑定空调、空气净化器这些电器，回家和出门的时候再也不用手动去操作，也不用担心出门忘记关空调了，体验提升非常明显。

Glean 的 PWA 支持

Glean 在最近的更新中，着重优化了 PWA 的体验。PWA 能达到的效果，有点动摇了我「原生优先」的刻板印象。在一系列的交互、动画优化之后，其实 PWA 也能做到很流畅的动画，开发的成本也相对比较低（相对于完全重写一遍原生的逻辑，PWA 开发只用针对移动端页面做一下布局的优化）。

之前一直觉得原生相对流畅很多，很多时候其实是动画的调试问题，如果界面完全没有做动画，看起来就是卡卡的。有针对性地做了缓动动画之后，其实 web 也能做到很流畅的效果。原生只是如果你使用了对应的组件，会有默认的动画罢了。

另外，Glean 的官网 https://gleanapp.cn 最近也通过了备案等手续，成功上线，欢迎大家来看看。

MISC

麦当劳 MCP 平台

网站链接

是的，你没看错，麦当劳真的做了个 MCP 平台，目前有优惠活动和领券的功能，后面应该是要打通订餐的功能。

我觉得这算是麦当劳作为大公司一个很有前瞻性的决定。以后 AI 可能会成为更多人互联网的入口，比起之前豆包手机通过截图操作的方式，提供 MCP 是更加 AI 友好的方式。我在 vol. 72 提过：

我觉得它会是通用人工智能的「最后一公里」。又过去一段时间，国内支持了 MCP 的日常服务还是不是很多，至少还没有很现象级的 MCP 服务出现。这其实是很多服务的架构决定的，如果一个服务它本身就没有「开放平台」，那它出现 MCP 服务的可能性也很小了。

之前豆包手机受到国内很多大平台封禁、抵制，可以看出来很多国内大厂对于「开放」还是很保守，毕竟 App 作为他们的唯一入口，很容易打造信息差，而信息差就约等于赚钱。提供 MCP 之后，各种数据都可以被瞬时上下文比人类大得多的 AI 处理，信息差很难藏得住。

EOF

本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）

另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。