生活的策略

发表评论

很多时候，大家对于我的很多生活的决策是不太理解的，觉得 —— Hey，Bro，你是不是对自己太狠了。关于对自己为什么这么狠，可以看看用力，且认真的生活，而你了解了我的基本逻辑之后，你就会发现，由于我认为生活本身是有无限可能的，我就会希望尽可能做对的决策。

而做决策的时候，我就会思考，这个决策是否重要，是否是长期的，如果是长期的，我就会开始去运用极限的思考方式，将整个方案中的某些元素逼近极限，以思考正确的选项来完成。

说实话，我的高数真的很烂，但，极限的概念又是如此深刻的影响了我的思考方式。

举个例子：当我在字节工作时，我又确认了我长期会回天津生活，会在天津买房，我就会开始思考我的时间和金钱的安排方案，而如果你用理性和逻辑推演，你很容易得到一个结论：最优解是北京赚钱天津花，在北京应该尽可能少的花钱，而在天津多花钱。因为相同的钱，在天津和北京所产生的效益是完全不同的。天津的花钱的效益远高于北京。

而基于这样的决策，很容易就推演出下一步的结论：我在北京应该尽可能少花钱，不要花无谓的钱。然后，得出进一步结论：我在北京的最优解是用好公司提供的各项资源，同时在所有需要花钱的项目上，尽量控制开支。然后你就会很容易推演出 吃饭应该吃公司食堂；住宿的话，就住宿最便宜的就行（这就是为什么我甚至可以接受住在宿舍里），时间可以花在公司里，卷出最大化效益。而这种生活，就是我在字节时的日常。

我写这篇文章更多不是想说「我的生活方式值得你们学习」，因为每个人的生活目标是不同的，因此不能简单的照搬我的策略，但是，我确实觉得，你需要思考你的生活目标和结果，再基于你的目标和结果，设计你的路线和最优策略，然后提醒自己以终为始。最终，抵达目的地。

用力，且认真的生活

1 条回复

用力的认真生活是我很长时间的态度。

之前在 X 上发过我自己的一些健康的指标和健康跟踪的策略，有位网友评论：“这睡眠时间，这HRV，这久坐时间，感觉超级不健康。可穿戴设备如果不能改变行为，仅仅是监控有什么意义呢？”

我对于生活的观点是：我们的生命是有限的，拉长我们生命长度的方法，无疑是体验各种不同的人生和生活，而如果想要在相同的时间过更精彩的人生，就需要合理的利用时间和生活。

但我的兴趣和爱好太多了，以至于我一直觉得自己的生命不够用，感叹时间飞逝。所以，就开始追求，让自己的时间利用率更高、让自己的清醒时长更长，以便于去获得更加丰富的体验。

但是，折腾自己是有风险的，一旦玩脱了，就会把自己推向深渊，无法自救，所以知道边界很重要。当你知道边界在哪里之后，你就可以选择将自己趋向边界，但不越过边界。

不仅如此，人对于很多事情的阈值，都如同力量训练的肌肉一样，需要通过不断超越自己的极限，让肌肉断裂再重新生长，才能达到提升的效果。

而我对于我的人生和健康也如是，我知道什么是完全无风险的，但不是我想要的，而我想要的部分，我要控制风险，不能把自己给玩没了。但在可控的范围内，我要无限逼近极限，以获得极致的体验。

我的超强精力、我的能力，皆源自于此。把自己当成一个试验品，也很好玩啊!

2026 年9/10 月观影总结

发表评论

9/10 月份还是看了不少的电影的，不过一直没顾上写总结；于是乎，继续写一下总结；

整个9/10月份一共看了 5 部电影，其中按顺序来分别是：

《奥德赛》

奥德赛真的很长，看的我中间还是出去上了趟厕所。不过，我觉得这部剧拍的还不错，特别是马特达蒙的部分，他经历过的事情，真的很考验人性。

看完这部电影的时候，我突然在想：今天 AI 生图、生视频如此盛行，我们为什么不做我们自己的史诗？这部剧是荷马史诗，我们为什么不能拥有中国的史诗？这部电影看得我心生澎湃，我希望同样的状态，可以让海外的人也可以心生澎湃。

《生化危机：爆发夜》

这部电影我去看的时候，没预期到会被这么吓到|ﾟДﾟ)))，整体还是把握吓得一愣一愣的。看这部电影一大感受是 —— 顶楼的实验人员本身不够尊重人和尊重世界，才最终造成了这样的事故，不然或许有改观。

如果你不怕吓，我觉得还行，可以看看。全场最佳的外卖小哥，还挺好玩的。

《欢迎来龙餐馆》

龙餐馆听说是反战的，所以来看的时候心里有数，倒也没那么害怕。但我对于人性的残忍还是没有预计到位。。。看到里面的校长做的事情，真的心底对于战争的厌恶又多一分。相比之下，老扎好了很多。

后面在抖音上看到有一些老扎后面的片段，我感觉是二创，但也算是大家对于老扎的认可。

《杀死比尔：血色全传》

我是奔着昆汀来的，杀死比尔 1 看着确实很有昆汀暴力美学的意思 —— 满屋子必须都是血。很刺激；

但是。。。第二部就非常的拉跨了。。。突然峰回路转，感觉昆汀的暴力美学没了，给我一种第二部分是另外一个人拍的。

以及，我最终还是看到的里面的彩蛋《失落的篇章：由纪的复仇》

《肖申克的救赎》

肖申克的救赎之前我在电脑上看过，这次重映，我决定到影院去交一张电影票钱，重新回顾一下。好电影不愧是好电影，去电影院看依旧很爽。

而且，真的在看这部电影之后，对于自由和希望的理解，真的是又进一步。

《工资外收入：不要再单次、廉价地出卖你的时间》书摘

1 条回复

这本书似乎是微信读书单独出版的，很简短，内容相对浅薄，适合职场新人读。

2 时间的瓶颈

问题也正出在这里。对于很多基础岗位来说，工资这东西，通常体现的是岗位的预算，而不是你实时创造的价值分成。

作为资源的提供者，必须面对一个现实：市场只为当下的稀缺性买单，绝不会为你过去的辛苦自动加价。

作为资源提供者，想要改善当下的处境，有三条路比较现实。第一，设法提高单位时间的“身价”，去竞争那些需求更旺、议价权更高且不容易被替代的岗位。第二，别让自己太依赖单一的雇主，要通过积累作品、案例、证书，或者经营行业口碑和客户关系，来提升自己的可迁移能力。第三，试着把经验转化成能反复使用的成果，比如做成课程、工具、模板、书稿，或者咨询流程、软件插件、数据服务，甚至是能独立售卖的作品。这三条路走起来都不容易，既需要持续学习，也得有勇气面对市场的反馈。

3 名气

名气的商业价值，本质上是降低了别人认识你、信任你并最终选择你的成本。

对大多数普通人而言，一份沉甸甸的可信度，远比一时的热闹更值钱。

4 学会看需求

这就是消费者视角和经营者视角的本质区别。消费者关心的是“值不值得买”，而经营者关心的则是“为什么有人会一直愿意付钱”。

一个成立的需求，起码得满足四个条件：有人确实遇到了问题，这个问题足够具体，对方愿意为了解决它而掏钱，而且你能以自己承受得起的成本把方案交付到人家手里。

生意的起点永远在外部，而不是你的内心。它源于别人的麻烦、恐惧，源于人们想要节省时间、提高效率、获得身份认同，或者是想降低生活中的不确定性。

5 规模化系统

扩大规模通常有这么几种路径。第一，产品标准化。把原本依赖个人经验的服务拆解成清晰的步骤，降低培训门槛。第二，流程复制。让不同的员工都能按照同一套标准完成接待、报价、交付和售后。第三，自动化交付。利用系统来搞定下单、付款、发货、提醒、记录和客户管理。第四，渠道稳定。降低每一单都要重新找客户的获客成本。第五，团队分工。把财务、法务、供应链、运营和客服这些专业的事，交给专业的人去处理。

很多人起初以为创业就是做自己喜欢的事，可真正入场后才发现，大把的时间其实都耗在了合同、发票、退款、招聘、培训、投诉、库存、税务以及研究平台规则上。经营者赚的那份钱，本质上是你在处理完这些琐碎麻烦之后，还能剩下来的利润。

6 学习的真相

想懂财务，就读会计和商业基础；想懂消费，就读行为经济学和社会观察；想懂投资，就读资产定价、企业分析和金融史；想提升表达，就读优秀的非虚构作品和写作手册。带着问题去读，知识才能转化为你的判断力。先行动后补课，并不代表莽撞行事。它的核心逻辑是：用极小的成本通过行动暴露问题，再针对这些问题去针对性学习。

7 债务

支出越高，所需的资产规模就越大；如果欲望没有边界，自由就永远不会到来。债务最昂贵的代价，往往不在利息，而在你失去的选择权。

8 资本的耐心

耐心，绝不意味着两手一摊、无所作为。相反，它要求你保持持续的储蓄习惯，不断学习新知，敏锐地观察市场，并反复审视自己的判断是否依然站得住脚。

9 自由的能力

真正危险的处境，往往不是上班本身，而是你除了工资一无所有：没有储蓄，没有可迁移的能力，没有可复用的成果，却背负着越来越高的固定支出。所谓的自由能力，首先体现在识别合同上。你要看清自己正在向谁提供什么，对方凭什么付钱，你的身价由谁说了算，增长的收益归谁，风险什么时候会转移到你头上，以及退出的成本有多高。

Everything is Harness：从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering

1 条回复

在 Harness Engineering 这个概念逐渐流行甚至要过气之后，我终于理解了这个词背后的含义。作为一个笨人，决定用费曼学习法，把 Harness Engineering 这个词讲明白，也算是对自己的一个交代。

从 Prompt Engineering 说起

在 ChatGPT 刚出来的时候，大家面对一个空白的输入框，不知道说什么好，于是我们看到大量的教程、指南和分享中，大家开始提prompt这个词。而随之而来的，便是 Prompt Engineering。

大家希望通过修改自己的 Prompt，来让模型返回不同的内容，从而达成让模型完成不同的工作任务。在 2023 年的时候，Prompt Engineering 作为一个指引，帮助我们把 Prompt 写的更加结构化、更加明确化，向模型描述我们到底希望看到和使用的内容的框架，指引和帮助很多人走上了 AI 之旅。

其中的技巧即使在今天，也并非完全失效，在这个阶段，由于应用的形态以 ChatBot 为主，同时 API 主要也是在使用 Chat Completions API 为主，在这个阶段，我们的主要对于上下文的操作就是不断 Append，把用户的输入和模型的输入一起写入到整个会话的 Message。

但只有 Chatbot 是无法满足业务的需求的；我们开始研究使用 LLM 来完成更多的工作，并随着 GPT 3.5 Turbo /GPT4 支持 ToolCall ，LLM 开始可以稳定的输出更多的信息，从而延伸出了更多的功能和能力；我们开始在整个会话轮次中塞入更多的东西。Chat Completions API 在返回 Tool 的 Params 的时候，也需要我们将对应的 Tool 的 Response 一并回传给模型，整个会话的轮次也开始越变越长。

而模型的上下文和注意力机制决定了，模型的注意力预算有限；在这种持续的、长轮次的沟通方式累计下，整个上下文会快速累积（tool 的调用结果、system prompt、历史存储的状态、检索的内容都会进入到整个 Messages 序列里）。我们需要做出一些方式的优化，来确保在每次推理时，从不断增长的信息里，挑出最小但信号最强的那一组 token。

而随着 Agent 的概念开始出现，我们开始对 Agent 本身的能力开始做不同的上下文裁剪的方案，来确保 LLM 能够拿到最重要的信息。直到 2025 年中，Context Engineering 的概念被Karpathy、Tobi Lütke 等人提出，随后 Anthropic 发布《Effective context engineering for AI agents》，我们开始正式用 Context Engineering 的理念来管理我们的 Agent 行为。

从 Context Engineering 到 Harness Engineering

随着 Context Engineering 的实践逐渐成熟，我们开始能够更有效地管理有限的上下文预算，使 Agent 在复杂任务中保持更好的信息相关性和行为一致性（但这并没有彻底解决长程任务中的可靠性问题）。随之而来的是，我们迎来了 Agent 的时代；Claude Code 的横空出世，Claude 3.5 Sonnet 、Claude 4.0 Sonnet、Claude 4.0 Opus 等模型的推出，我们开始发现 Agent 可以很好的完成工作；

我们开始大量的使用这些 Coding Agent 来完成工作；但我们也不只满足于让 Agent 能完成工作，我们开始思考让 Agent 尝试更加长久的工作，完成长程任务。ReAct 等框架帮助我们初步探索了 Agent 长程任务的可能，但整体来说执行还是非常的不稳定的，依然需要人类介入其中，承担一些中间的粘合、持续推进的动力。

但很显然，我们不希望人类担任这个无价值的 Connector，与此同时，Anthropic 在长程 Agent 实践中展示了一种 Harness 设计方案《Effective harnesses for long-running agents》。不过这一版的 Harness 的定义和我们如今看到的 Harness 定义还是有很多变化的，它还定义了特定的 Feature List。如今我们用的 Claude Code 则是用了 Dynamic workflows 来完成了相同但更强的功能。

2026 年 2 月 5 日，HashiCorp 的 Co-Founder Mitchell Hashimoto 写下了《My AI Adoption Journey》,在个人实践中明确使用并阐述这一概念，并定义了两种可能的形式：改进 AGENTS.md 和改进编程工具。

I’m making an earnest effort whenever I see an agent do a Bad Thing to prevent it from ever doing that bad thing again. Or, conversely, I’m making an earnest effort for agents to be able to verify they’re doing a Good Thing.
Mitchell Hashimoto

紧随其后，OpenAI 在 2 月 11 日发布了他们自己的《Harness engineering: leveraging Codex in an agent-first world》的文章，在这篇文章里， OpenAI 没有定义 Harness Engineering 是什么，但给出了不少他们做的修改的范式，并给出了他们认为重要的部分: 识别缺失的部分，并让 Agent 编写相关的部分。

Humans always remain in the loop, but work at a different layer of abstraction than we used to. We prioritize work, translate user feedback into acceptance criteria, and validate outcomes. When the agent struggles, we treat it as a signal: identify what is missing—tools, guardrails, documentation—and feed it back into the repository, always by having Codex itself write the fix.
Ryan Lopopolo, Member of the Technical Staff of OpenAI

至此，Harness Engineering 的画像变得清晰：不是改进模型本身，而是改进围绕模型的一切环境、产物和工具，通过这些环境和产物以及工具，来让模型正确的工作。

所以，到底什么是 Harness？

我们可以简单的将 Agent 的拆解为 Model + Harness，所有不在 Model 的部分，都在 Harness。当然，这不是严格的系统架构定义，而是一种工程视角上的简化：在模型权重不变的前提下，我们能够主动设计和优化的执行机制、上下文管理、工具调用、状态管理与验证反馈，可以统称为 Harness 的一部分。但这句话的关键不在于拆解方式，而在于解决问题的思路 —— 将目光从改进模型切换为改进 Harness。

这就好像我们试图让一个人去计算一个很难的题目，由于替换人的难度很大，成本很高，所以我们选择将目光转移到人可以用的工具上。我们可以用算盘去计算一个复杂的题目，但如果我同样还可以使用一个强大的计算器，那自然使用计算器可以更快的到达目的地。而好的工具（Harness），也给了我们让一个更差的模型获得更好的质量的可能。好的模型可以向下兼容算盘，但给它计算器，它才能把精力省下来做更难的部分。

当然，更强的模型往往能够驾驭更复杂的工具，完成更加困难的任务。但 Harness Engineering 的意义，不只是进一步提高模型的能力表现，而是降低任务成功对模型单次推理和执行正确性的依赖。

通过外部工具、状态管理、验证反馈与错误恢复，我们可以把原本需要模型独立完成的部分工作交给工程系统，让同一个模型更加稳定地完成任务。

Harness Engineering 的目标，是将模型具有不确定性的推理与执行能力，转化为可验证、可恢复、可持续的任务交付能力，提高任务的端到端成功率。

举个例子，假设我们希望一个 Coding Agent 完成一次代码重构。它不仅需要修改代码，还需要确保修改没有破坏现有功能。

如果没有 Harness，我们只能期待模型记得运行测试、正确理解测试结果，并在失败时尝试修复。
但如果我们将编译检查、单元测试、端到端测试和任务状态管理接入 Harness，那么即使模型某次修改出错，系统仍然能够发现问题、提供反馈，并引导 Agent 继续修复。

这并没有改变模型本身的能力，却改变了整个系统完成任务的可靠性，帮助整个系统更加准确的交付结果。

所以，为什么模型公司要搞自己的 Harness？

很显然，Harness 存在的目标是帮助模型获得更好的结果。各个模型公司在训练环境的差异，会使得模型公司倾向于通过优化 Harness 来帮助自己获得更好的结果和智能。这也是为什么你会关注到，很多模型的 Benchmark 必须说清楚用的是什么 Harness 得到了这个分数，因为 Harness 就是会影响最终模型的结果。

而不同的模型公司在设计哲学上的变化最终演变出来了不同的 Harness，也让我们看到了不同的分类 —— Claude Code、Codex 、Pi、Deepseek Harness 。每个 Harness 背后都是对应模型公司或应用公司对于 Agent 的重新理解和定义。而对于这件事的理解，让我对于 Harness 的生态位既感到乐观，也感到悲观。

我们如何选择自己的身位？

毫无疑问，我们可以将 Harness 区分为 Base Harness 和 Domain Harness / Business Harness：Base Harness 代表模型公司基于 Agent 能力抽象出来的最小集合；而 Domain Harness 是将特定领域的知识、工具、业务流程和验收标准封装成 Agent 可执行、可验证的工程系统。

我对 Base Harness 的生态位悲观，因为对于模型公司来说，他们会优先适配自己的 Base Harness，来帮助自己以最低成本获得最好的效果，同时，也会分配一部分精力去适配社区使用比较多的 Harness。但另一方面，这种和模型的深度绑定，让开源的 Base Harness 会在持续发展的阶段中，逐步被抛下（除非你能成为 The One）。这让我们在选择 Base Harness 时要谨慎。

目前来看， Pi 可能会好一点，因为足够简单，和本身设计理念的简单，会让他大概率就算靠模型泛化，不做特定的优化，也能获得不错的结果。其他缺少独特系统能力、只追求复制官方 Agent 产品体验的通用 Harness，长期竞争空间可能被压缩；而和模型厂商绑定的 Harness，则会逐步在自己的 Harness 上拥有最佳表现，顶多再适配一下 Codex / Claude Code。如果一个第三方的 Harness 不够薄、不够可替换，就容易被模型厂商的官方 harness 挤压，最终失去自己的价值（回想我们之前看到的复杂的 Garry Tan 的 Gstack，你还用么？）

同时，我也对 Domain Harness 更加乐观，因为领域知识实在是太深太杂，以至于对于模型公司来说，这些东西可能也会吃下巨大的人力成本。与其花时间去做 Domain Harness，倒不如直接提供更好的开放度（比如 Pi / Deepseek Harness），来帮助领域专家构建 Domain Harness（从这个视角来看，我能理解 Deepseek Harness 的设计理念为何如此激进）。不过这些机会可能并不属于我（虽然我是 EE 背景的人，但我的领域 Know How 约等于没有，自己的技能都点在互联网 & CS 相关了）。

在这样的生态格局下，我们如何做好 Domain Harness？

当你理解 Harness 的存在价值和设计理念后，接下来就可以动手设计你的 Domain Harness 了，

定义你要解决的问题，设计任务集和验收条件：定义领域的真问题和对应的成功标准、验收条件，用于判断 Agent 的行为。
选择一个你喜欢 / 熟悉 / 定制方便的 Base Harness，这方面我推荐你看看 Pi 或者 Deepseek Harness， Codex 虽然本身和 GPT 强绑定，但因为 Open Core，你也可以快速找到他的 Base Harness 实现，然后基于此做自己的实现和改造，只是从开放度来讲，前两者还是更好。
让 Agent 去尝试完成任务，并在失败的时候停下来分析 Trajectory，在这一步，你要先分析 Agent 的失败原因，到底是缺乏验证机制，导致无法判断对错最终做错了？还是缺乏外部状态，导致模型在长程任务中迷失了自我。
1. 如果是缺乏验证机制，那么你需要给到 Agent 一个能够验证对错的方案（可能是一个验证脚本，也可能是一个 Linter），并要求 Agent 看验证的结果再继续推进；并查看 Agent 的行为是否符合预期。
2. 如果是缺乏外部状态，那么你需要定义在长程任务中必须要完成的工作，让 Agent 可以自己去跟进状态，并在持续进行长程任务过程中，不会丢失自己的位置（我们看到的 Claude Code 第一版的 Todolist 和后续的 Dynamic workflows都是类似的作用）。
3. 如果这两个都不是关键问题，纯粹是 Agent缺乏信息或者外部信息的输入，那么你才需要设计新的工具和引入更多的内容作为 Prompt 来帮助 Agent 获得足够的上下文。
至于修改 Prompt 文件，虽是成本最低，最直接的优化手段，但却不应该成为我们的默认选项。
当你完成所有的修改后，重新跑一次回归测评，对比成功率、成本、耗时与副作用，来促进下一次优化。

总结

过去，我们花费大量的精力研究如何写出更好的 Prompt，让模型尽可能一次性给出正确的答案。

后来，我们开始研究 Context Engineering，让模型在合适的时间看到合适的信息。

而今天，我们开始研究 Harness Engineering，不再只关注模型在某一次推理中是否正确，而是关注整个系统能否持续、稳定、可验证地完成任务。

从这个角度来看，Harness Engineering 的价值，不是让模型永远不犯错，而是让系统有能力发现错误、修复错误，并从错误中持续改进。

Prompt Engineering 优化的是表达，Context Engineering 优化的是信息，而 Harness Engineering 优化的是完成任务的整个过程。

当模型能力不断提高，我们真正需要积累的，可能不再是某个版本的 Prompt，也不是某个 Agent Framework 的使用技巧，而是那些能够被验证、执行和持续改进的工程经验与业务判断。

模型会不断迭代，Harness 也会不断演进。但如何定义正确、如何验证结果、如何把经验沉淀为可以复用的系统，依然是值得长期投入的事情。

我们正在从教模型如何做事，转向设计一个让模型能够把事情做对的系统。

我把 Apple Watch 半退役了：Google Fitbit Air 可能是最适合 AI 用户的可穿戴设备

8条回复

我把 Apple Watch 半退役了，身体记录的主力换成了 Fitbit Air。

什么是 Google Fitbit Air

Google Fitbit Air 是 Google 在收购了 Fitbit 之后，推出的一款无屏手环设备（对标 Whoop），其核心设计理念是在设备上彻底移除数据查看的能力，专注在数据追踪和全天候检测上。

得益于这样的设计思路，Fitbit Air 可以减少手环的最大热源和耗电源 ——屏幕；同时，还可以把整个设备做得更加轻薄，省电，官方标称最长 7 天，我实际大概 8 天。如果你对于 Apple Watch 的每日一充实在顶不住了，那么 Fitbit Air 就是你的最优选。

既然目标是用来做全天候健康检测，Fitbit Air 也集成了不少的传感器，可以满足你的日常需求，具体包含：

光学心率监测器（Optical heart rate monitor）
三轴加速度计 + 陀螺仪（3-axis accelerometer + gyroscope）
用于血氧饱和度 (SpO2) 监测的红光及红外线传感器（Red and infrared sensors for oxygen saturation (SpO2) monitoring）
设备温度传感器（皮肤温度变化可在 Google Health 应用中查看）（Device temperature sensor (skin temperature variation available in the Google Health app)）
振动马达（Vibration motor）

对于日常基础监控已足够，大部分时候我们使用 Apple Watch 所监控的基础健康指标也大概是这些了。

详细的技术 Spec 可以查看 https://store.google.com/product/google_fitbit_air_specs?hl=en-US

而且其售价也不算特别贵，相比于小米手环要贵一些（原价 99 美元；亚马逊买大概是 700 元人民币不到），但作为一个含智能属性的装饰品而言，我觉得还是可以接受的。

将 Google Fitbit Air 与 AI Agents 整合起来使用

促使我购入 Google Fitbit Air 的核心原因，是我对于让 AI Agent 参与到我的个人健康数据分析，指引我进一步优化自己的身体健康状态有很强的诉求。

但目前我在用的产品不管是 Apple Watch 还是 Garmin，这方面做的都不够好，我没办法比较随意的将它们接入到 Claude / Grok 等不同的应用，这使得我非常不爽；我已经买了更好的模型，但受限于开放度，没办法把这些数据提供给 AI Agent 帮助我自己提升表现。而 Google Fitbit Air 在买之前，我就了解到它是基于 Google Health 的。而 Google Health 是给用户提供了开放的 Google Health API 的。

这就给了我更进一步分析自己的各种数据的可能性，不管是将其封装成 MCP 给到 AI Agent 使用，还是我把数据拉下来做其他分析，都有了机会。从这个视角来看，我还有个暴论： Google Fitbit Air 可能是迄今为止，最适合 AI User 的可穿戴智能设备。

如果你要购买，且有兴趣把 Fitbit Air 和你的 AI Agent 整合起来，我写了一个开源的程序，可以帮助你把 Google Health API 封装成 MCP 来使用：https://github.com/bestony/google-health-connector 。如果你对这些数据有隐私顾虑，可以直接自己部署一个；如果你懒得自己部署，也可以选择使用我部署好的线上服务：https://www.stillwarm.app/

为什么说 Google Fitbit Air 是一个伪装成装饰品的健康追踪设备

得益于无屏幕的设计，使得 Fitbit Air 更加接近于一个装饰品，你几乎可以把它当成下面这样的硅胶手环来戴（当然，你戴的表带不同决定了实际的体感），如果你能够接受这样的硅胶手环，那么你大概率能接受 Google Fitbit Air。毕竟，Fitbit Air 主机 5.2 克，连上表带也只有 12 克，真的没什么感觉。

为什么这个无屏幕如此重要？因为无屏幕为用户提供了一种可能性：用极低的侵入感，提供装饰作用，从而让你可以一直戴着它。不管是我们更熟悉的小米手环，还是各种智能手表，你不可避免会遇到的问题是 —— 你的手腕上总是有一截「黑色」，即使是小米手环这样很细的，依然是有一截黑色。如果你还没感觉的话，下面这张图，可能会让你更有对比感；它们从左到右分别是 Fitbit Air、小米手环 7 、Apple Watch S12；

而也因为这种装饰品的属性，让我开始尝试一些更大胆的风格 ——我买了非常多不同的表带，可以根据场景、喜好、穿搭替换不同颜色的表带，来搭配自己的穿衣风格；

你可以在淘宝上找到各式各样、不同风格和颜色的表带，根据自己的喜好，把它搭配成你自己的风格。而得益于 Google Fitbit Air 以饰品的形态完成了身体指标的追踪，我开始买一些其他的腕表来配合着戴。

Google Fitbit Air 的数字体验 —— Google Health App

Google Fitbit Air 使用的是 Google Health App，需要单独下载，整个 App 设计的很简约，功能不多，从打开体验上来看，可能比 Apple Health 还好一点点。

在打开的那一刻，你可以快速看到一些你的基础信息，并可以根据这些基础信息来微调自己的规划。在这个界面中，最核心的是左上角的心肺负荷；Google Health 的基础假设是预期你能不断提升自己的心肺负荷，提升心肺能力；所以随着你使用的越久，它就会给你更加完整的心肺负荷的数据，同时帮你动态调整每周的目标。跟着这个目标，你会慢慢提升自己的心肺能力。

你如果是新买的 Fitbit Air，Google 官方还会给你送免费 3 个月的 Google Health Premium 会员（新用户和回归用户都算，活动截止到 2027-05-26。试用结束后自动按 $9.99/月续费），从而可以在 Google Health 中直接使用 AI 助手。而如果你已经购买了 Google 的 AI Pro 以上的会员，那你的 AI Pro 就包含了 Google Health 的 Premium 会员，可以畅快用 AI Agent 了；

除了基础的数据指标和 AI 助手，Google Health App 里还有类似 Keep 的运动库，你可以直接跟着练习；不过我有自己的训练计划，这部分用的很少；

在整个健康检测过程中，睡眠是一个很重要的指标，因此，Google Health 也给睡眠提供了一个单独的 Tab 方便你查看睡眠情况的分析。

以及独立的健康状态页面，记录你的身体的各项指标；你可以在这里去查看你的各项指标的趋势；

一些很有用的 Google Fitbit Air 的小功能

Google Fitbit Air 支持配置闹钟和智能唤醒，依靠腕间震动，来把用户给震醒。很适合有同床人，但只希望叫醒自己的人。
高度可定制化的首页：虽然官方推荐你把心肺负荷放在首页，但你可以根据需要，把自己关注的生命体征调整到前面。这比 Apple Health / Garmin Connect 好太多了。

Google Fitbit Air 不适合什么场景？

上面说了很多适合的，接下来还要说一些不适合的人群

你有记录运动的习惯，但没有另外一个设备：Google Fitbit Air 不是不能记录运动，但它的记录功能和实时提醒的功能相对较弱，毕竟没有屏幕，所以各项指标你都只能在手机上查看；
你需要一个手表来看时间并完成记录：这种场景下，Apple Watch、小米手环之类的带屏设备还是更适合你。
你并不信任Google：毕竟 Google 的主要盈利模式是广告，那么你的数据从某种意义上，也可能会参与到针对你的广告推广当中去。

Google Fitbit Air 用下来让我不爽的点

Google Fitbit Air 的数据同步不太及时。数据不会丢，设备本身能存 7 天的分钟级运动数据，只是会晚一点才到 Google Health。
如果你用 AI Agent 的定时任务分析身体指标，就要留意时间：定时任务排得早，起床后最好先打开一下 App，让手环把数据同步上去，不然 Agent 分析的时候可能拿不到昨晚的数据；定时任务排得晚，基本不用管。

总结

我觉得今天的 Google Fitbit Air，是以一个饰品的姿态，做了一台合格的健康追踪器。它轻、续航长、戴着没负担，最关键的是数据开放，可以直接交给 AI Agent 去分析。

如果你和我一样，想让 AI 参与管理自己的身体，又受够了每天充电，它值得一试。

以棋娱乐

发表评论

作为一个工作狂，我的时间大部分被计算机所占据，但难免有休息的时候。近来，我和太太选择了以棋娱乐，消磨时间。

而当我们开始下棋后，我突然意识到并理解为什么过去老人们总是喜欢下棋了。

第一便是下棋对于人数的要求很低，只需要两个人就可以开始，非常符合如今的家庭结构，大多数只有两个人；

第二便是下棋本身也是一种动脑筋的游戏和活动，相比于刷抖音视频，显然下棋是一个更好的选择，能够动动脑筋，思考一下如何破局；同时，也不至于像编程一般烧脑。

第三便是和玩游戏相比，下棋是与人的博弈，人带来的变化让游戏本身乐趣无穷；同时，还可以在游戏的过程中，增进感情。

我们从一开始下五子棋、跳棋，慢慢拓展到了直接把常见的棋种都买了一份：五子棋、围棋、象棋、国际象棋、跳棋、军棋。不过，象棋还在学习过程中（我虽然看过很多老人下，但并不会下，还是需要开始学习。）

如果你和你的家人在家里无聊，那么不妨也买副棋回来，玩一玩。

（我也是认真开始玩才发现，五子棋竟然还有禁手一说。。。）

Near By Guru: 找到你身边的开源上师

发表评论

在上一篇《开源，可能是新手软件工程师的唯一的路了，所以我做了 GoodFirstIssue.org》中，我介绍了 GoodFirstIssue.org ，今天我希望重点介绍一下其中的一个我个人很喜欢的项目 —— Near By Guru。 Near By Guru 可以帮助你找到你所在城市的开源开发者，你可以借此功能找到他们，并与他们取得联系，请他们帮助你，加入到开源社区当中。

有了合适的 Issue ，但贡献依然很难

对于新手来说，做贡献很难。开源和企业内部一个很不一样的点是，开源社区当中，没有人有义务为你提供帮助。大家会秉承着最大善意去帮你参与到社区的贡献当中；但并不意味着大家能像企业同事那样，做到当天甚至即时给你反馈；对于新手来说，这种等待反馈和确认无疑是煎熬的；而对于开源老炮们来说，这不过是他们参与到开源社区的一个又一个日常。

开源社区很好玩，但这些隐形规则的和企业内的不一样，容易让新手一开始就失去信心，使一个人放弃参与开源社区。这个时候，如果身边能够有一个已经在开源社区中浸润已久的人参与其中，给予心理支持，对于新手来说，可能就足以继续坚持下去。

当然，还不止于此，你身边的这些优秀的开源开发者们，他们可能已经成为很多企业的中流砥柱，你可以和他们取得联系，了解业界的最新进展，避免闭门造车，同时也可以对于业界有更多的了解。

Near By Guru 的功能到底是什么？

在设计 Near By Guru 的时候，我核心设计了三个功能：

读取大家写在 Github 上的 Location，并进行标准化处理；
以城市级的精度，进行地区排布，从而形成地区级别的开发者地图；
当用户登录后，获取用户的 Location，并基于 Location 来获取到自己所在地区的开源开发者的地图。

通过这样的方式，方便大家可以快速的找到自己城市的开源开发者们。同时，考虑到像湾区这种跨了好几个城市的地方或者是国内的京津冀、长三角、珠三角地区的情况，我还加了一个 60KM 的约束，一个城市地图上，除了加载本城市的开发者，还可以加载到自己所在城市周边 60KM 内的开发者，方便大家使用。

寻找 Guru 的正确姿势

作为新手，你不能预期每一位 Guru 都能回应你的联系请求，他们可能很忙，所以你要控制好自己的预期；
尊重 Guru 的时间：绝大多数时候，如果一个问题，你简单地通过 AI 就能获得答案，就不要拿来问你的 Guru。如果你问了 AI 依然不懂，也不要把问题直接抛给你的 Guru，而是要告诉他，你自己做了哪些研究，有哪些结果，你还有哪里不懂。这样才不至于浪费他的时间，在他心中给你留下不好的印象。
你们是在尝试建立朋友关系，不是招聘关系，不是师徒管理， Guru 没有义务回答你的任何问题；他的回答是出于善意和热心，而非义务，帮你那是情分，不帮是本分。

怎么使用 Near By Guru？

你可以直接打开 Near By Guru 的功能页面，浏览器会自动向你索要授权，并加载你的所在地，然后你就可以在地图上看到你所在地的开源开发者们。

需要注意的是，因为我们的精度是城市级别，所以固定大家是围绕着城市中心呈圆环状排列的。并不代表每一位开发者的真实位置。

你可以点击他的头像，或在地图或下方列表中查看他的详细信息（比如他的简介、Star 最多的项目）。我们在网站上并不直接提供联系方式，如果你需要和他取得联系，可以点击「前往 Github 联系 Ta」，通过他公开的联系方式，来和他取得联系。

此外，如果你所在城市没有人，但是你所在的省会有，你也可以向下滑动，找到你所在的国家和地区，按照城市级别去查找对应的人。

Near By Guru 的一些已知问题

由于使用的是 Github 的 Location 字段，所以存在多种问题：

这里的位置不一定是准的，因为大家不一定想起来要去更新，有可能你建立联系后，发现其实他已经离开了你的城市；
这个信息读取的是 Github 上的 Location ，如果你和你的 Guru 取得联系后，他不希望自己再被打扰，你可以告诉他：可以选择直接更新 Github Location 信息，一周后会自动更新；或者直接通过 GitHub 登录网站，把自己设置为 unlist即可。

以及，如果你受益于这个功能，通过这个功能找到了志同道合的朋友，并加入到开源社区里，希望你也能以对应的善意，在 Github 上写清楚你的 Location，方便帮助更多的新人加入开源社区。

总结

如果可以，我希望看到这篇文章的你，不管是开源新手，还是开源老炮，我们都能抱着善意，帮助我们身边的开发者。

开源，可能是新手软件工程师的唯一的路了，所以我做了 GoodFirstIssue.org

1 条回复

TL;DR
AI 能写代码之后，企业更想招一个熟手配上 AI，而不是一个新手。新手要被看见，开源是唯一的一条不用先被录取的路。我做了 GoodFirstIssue.org，按难度、语言和领域把 issue 筛出，让他们少翻、多改，用更多的时间，去构建自己在开源社区的信誉。

AI 时代的到来，对于我来说，无疑是欣喜的：我早已进入这个行业，虽算不上什么知名人士，但至少在圈子里也有不少好友知道我的能力，因而会给我机会；但对于我刚毕业的堂弟堂妹，甚至今年刚进入大学软件工程相关专业的年轻人来说，这个世界又无比的残酷。因为他们能做的事情， AI 也能做，甚至还能做得更好。相比于招募一个新手配上一个 AI，企业老板更希望招募一个老人，再辅以 AI。

更残酷的是，我自己作为小微企业的老板，我也会选择找一个老人，来辅以 AI。

所以，路在何方？

作为一个从开源社区成长起来的人，我自然是相信开源的，而且我也确实觉得 —— 在今天，开源已经成为这些新手们唯一的路：他们需要一个场合，能够让他们锻炼自己的各项软件工程技能，他们需要犯错，改正，记住教训；他们需要让自己走上舞台的机会。对于他们来说，开源是唯一的机会

你想要在企业中走上舞台，你需要先有机会进去，才能走上舞台；而开源不需要，它的代码是开源的，它的场景是开放的，它的用户反馈可能也是公开的。对于你来说，只要你有一个热忱的心，你就可以加入到这个社区当中，参与社区贡献。在开源社区，走上舞台不需要你先成为，只需要你真的有心。

开源贡献，也没那么容易

当你有了一个热忱的心，你就可以开始走上开源的贡献之路了。开源的贡献可大可小，如果你无所求（像我一样），那对于你来说，开源贡献很多时候就是 —— I Can Fix It。在 Github 上激情 Coding，也完全 OK，你依然在为开源社区做贡献，很好。

但对于这些新人们来说，他们显然是有所求的，那么如何以最低的 effort 获得自己想要的，就成为问题。

什么样的项目会是好的？适合新人的项目：

项目本身具有一定的关注度和领域价值：大多数时候表现为 Star 多 / Fork 多 / Download 多
项目本身拥有完善的项目贡献机制和 Mentor 体系：大多表现为有标准的 Contributing 路径且有人在对项目的 issue 、问题进行归档、分类、安排。
要解决的问题本身复杂度可控：对于新手来说，改一个几千行的 Kernel 的 Bug 不是一个特别可控的方案，但如果只是调试某一个函数，倒也未尝不可；

Github 上有那么多开源项目，又有多少项目能满足我们的需求呢？新手们如何找到这些 issue 呢？理想情况是本身这些新手们已经在用一些开源项目了，那么直接为自己在用的开源项目做贡献，显然是更好的。但，更多的人需要一个工具，帮助他们找到值得他们花时间精力去参与的项目，同时，在「找 issue 」这件事上，让新手在找 issue 上少花时间，把更多时间花在提交代码和参与社区贡献上。

所以，你应该如何使用 GoodFirstIssue.org？

简单来说，如果你没有目标，那么直接用筛选，按照可量化的指标来筛选即可；如果有目标领域，不如直接进提前筛选好的领域分类里快速看要贡献的 Issue 。

如果你不知道自己要做什么，但有一些模糊的目标，那么最简单的方法是，打开高级筛选，根据你的喜好，选择适合你的 Issue；比如筛选已标记 Good First Issue 的 Issue，难度为 2/5 或者 3/5 （越高越难），然后选择你想要的 Star 的范围（虽然越高影响力越大，但意味着竞争越强）。然后点击应用筛选，就可以选择出你喜欢的想要的 issue 。

如果你已经有明确的发展的领域，那么提前分好的类别，可能更适合你。你可以选择语言、框架、领域，点击进去后，你可以找到这个领域内的各种问题，然后，参与到其中，让别人看见你在这个领域交过的 PR。

甚至是，如果你已经在参加一些社区活动，那么基于活动的分类，也可以帮助你快速找到属于 Hacktoberfest 或者是 Google Summer Of Code 的 Issue；对了，现在刚好就在 Hacktoberfest 的时间范围内，为什么不参与一下呢？（快速查看符合预期的 issue）

总结

开源不是唯一能写代码的地方。但它是少数不需要先被录取、就能把代码、场景和反馈都摊开的地方。我做 GoodFirstIssue.org，不是为了让新手少焦虑，是为了让他们把时间从翻 issue 挪到改代码上，从而更好的在开源社区中，去构建自己的信誉。

So，要不要来试试看 https://www.goodfirstissue.org/zh ?

四年前梦想的生活与现实的生活之书房篇（2026版）

4条回复

写 Blog 的好处就是，你总是会有一些历史的内容，时不时的浮上来，让你回想起自己曾经的想象。

而对于房子来说，我历史上也写了不少的内容《梦想的房子（1）：书房篇》就是一篇,而今天，我已经拥有了自己的房子，刚好可以回来 Callback 一下曾经的文章；

如今的书房

梦想的生活

我曾经在《梦想的房子（1）：书房篇》中写到，我对书房的尺寸有要求；比如要有足够的纵深、要有咖啡机、饮水机、制冰机；要有书架、办公桌、储物柜、单人床；

我在《我想要什么样的房子？》中写到，我希望书房有个单人床，且一定要有书房；

而到了去年年初，真的要买房之前，我又写了《关于买房的思考》，思考书房其实是可以外移的；

如今的生活

和上面的梦想的生活对比来看，差距不是特别大；虽然局部有些差异，但整体也有了一些新的解法；

我需要咖啡机？：现在的解法是我直接买了山姆、麦德龙的大瓶装冻干咖啡，因为我意识到，我自己真实需要的其实是咖啡因；咖啡机反而在这个选项里其实不算是最优解；便宜大碗的冻干咖啡显然是个不错的选择。
我需要饮水机？：现在我的解法是，还是买了饮水机，不过饮水机放在客厅，因为客厅里用水的场景会更多；而书房我也没有完全放弃对于水的需求，我引入了苏打水，在房间里放了好几箱苏打水，需要的时候直接开一罐苏打水就行。推荐一下小象和七鲜的气泡水，非常不错。
我需要制冰机？：现在我的解法是：直接上小象买成袋装的冰块就好；之前需要制冰机，是因为当时这些平台并不卖冰块，导致我必须要买制冰机才能有冰块；但今天这些平台买冰块已经非常方便了，而且比自己冻冰块还更加安全放心。所以，just buy it。这也是为什么你看我的书房里竟然还有个冰箱。这里一部分是因为这个冰箱其实是之前买的，也没扔，另一方面是这个冰箱可以用来存放冰块和一些家里的冻货。挺好。
我需要书架？：是的，我需要的，而且是大书架，你可以看到照片里，我选择的是宜家的毕利书架，并加高了一层，加高到了 2.3米；根据阅读的频率，把不同的书放在不同的高度；同时，你可能注意到了，我故意选择带柜门的版本，这是因为我把下半截作为储物柜，通过带门的毕利，将一些杂物隐藏在柜子里，从外面看就会比较舒服。
我需要储物柜？：是的，我需要，只不过是通过毕利的下半截带门柜子来实现的。此外，因为大部分常用的已经放在毕利下方，其实剩下的往往是一些不太常用的，比如电钻啥的，我就把它直接放在储物箱子里，然后放在了 2.3 的柜子顶上，需要的时候直接拿梯子取下来就好。反正不常用。除此之外，一些杂物，我在书桌旁放了一个宜家的卡莱克储物柜，刚好储物柜上可以放置打印机，和书桌相同高度，使他很自然成为了书桌的延展空间。
我需要单人床？：是的，不过最后是买成了宜家的沙发床，不过因为绝大多数时候都是沙发状态，所以其实不怎么用，偶尔有亲戚留宿时，会展开成床。这个沙发作为沙发还是非常不错的（除了扶手有点硬）。现在来说，午休直接回卧室就行，倒也没必要用专门的单人床（但确实舒服的房子会让我睡得更久一点）。

而书桌的部分，我选择了宜家的胡福斯佩，140*80的桌子；纵深足够深，所以可以方便地把显示器电脑放在上面；不过，后续我反而没有再买双屏，Mac 本身的屏幕配合一个足够大的 4K 显示器，就足够了。

成本

这个房子最后算下来的成本挺低，各种家具加起来差不多在 6000 块钱；冰箱和储物架因为是之前买的，所以没算，不过这两个加起来的总成本也在 1000 块以内，整个书房的家具成本差不多可以定在 7000 块钱，很舒服，家电方面，这个房间主要是一些小的米家智能控制，加起来不到 500 ，然后就是空调。得益于去年的国补，空调也没花多少钱。

如果真说成本最贵的话，应该是我的显示器，我的显示器是明基 BenQ MA320U，一个 5000+的显示器。。。基本上赶上屋子里的其他一大堆东西了。。。不过一个每天都使用的重要设备，买个好的，不亏！

如果你想看细节，可以看附录中的总表，有核心的大项的汇总，小项我就没有计算。

五年后重装怎么搞？

对照四年前的文章，四年前记录大多是解法，而非需求本身；到了四年后的今天，我开始思考到底我需要的是什么，并选择一个合适的解法，这何尝不是一种进步？完全没必要刻舟求剑，Just Follow What You Need!

目前的书房使用的是我们的主卧的空间，但随着备孕计划的推进；后续我们肯定会要重装整个家庭（要从目前的卧室搬到主卧，把现在的卧室留给孩子）；

不过，想了想，可能 5 年后重装的时候，我会按照《关于买房的思考》的策略，将书房进行外迁，我可能需要在附近找个合适的房子，来作为书房 & 会客室、储物间等等。到那个时候，可能最大的变化是，真的要把单人床备上了 hhh.

哦对了，我可能还要再加两组书架；目前的书架又快满了；有些书不得不收纳到卡莱克里。现在就已经不够用了，5 年后重装正好一并解决。

附录：总表

项目	数量	单价	总价
显示器	1	5171	5171
空调	1	2222	2222
书桌	1	599	599
卡莱克收纳	1	299	299
德罗纳收纳盒	4	29.9	119.6
毕利书架	5	709	3545
人体工学椅	1	399	399

合计			12254.6