Bestony | 白宦成的 RSS 预览

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

2026-10-09 10:32:06

我把 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 参与管理自己的身体，又受够了每天充电，它值得一试。

以棋娱乐

2026-10-05 22:50:30

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

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

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

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

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

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

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

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

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

2026-10-04 20:55:21

在上一篇《开源，可能是新手软件工程师的唯一的路了，所以我做了 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

2026-10-04 17:48:38

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版）

2026-09-17 23:14:22

写 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

Claude Tag 产品分析

2026-09-10 22:04:08

Claude Tag 这个产品市面上的仿品很多，但我看到的绝大多数的产品仿品仿其型而未有仿其神。这背后是本身绝大多数仿品的团队都是 TO C 创业者出身，导致对于他们来说，并未看出背后的很多设计的原因。而作为一个真的干过 TO B 的产品经理，我觉得大家其实做的都还是 TO C 的产品，由于实在看不过眼（~~觉得在座的都是垃圾~~），我决定自己写一篇对于 Claude Tag 的拆解，方便大家参考和使用。

对于 Claude Tag 来说，其神在于：

访问按地方配，不按人配。 配置的单位是 scope——整个组织（Default Slack access）、一个 Workspace、一个 Channel——Access Bundle 挂在 scope 上，往下继承；一个 Channel 拿到的是它自己、它的 Workspace、组织三层 Bundle 的并集
记忆跟地方走，不跟人走。 Memory 只有两层：Public Channel 里产生的记忆在整个 Workspace 内共享，Private Channel 只读共享层、写自己那一份；
用组合来在不同地方配置 Agent。你可以通过组合 Access Bundle，在不同的位置，给 Agent 组合出各种用法的能力，从而让 Agent 真正解决问题。

如何开通 Claude Tag

花钱就行，50 刀起步；我花了 70 刀；50 刀是用来开 Claude Teams 权限；剩下 20 刀是 Claude Tag 日常消耗的（我觉得对于很多小公司来说，Claude Tag 的一大痛点可能在于成本太高，因为不是按照订阅算的 Token，而是按照真实的消耗算的 Token，那你可能真的得思考，我真的有必要上 Claude Tag 么？以及会考虑选择使用更便宜的 Sonnet 模型作为 Claude Tag 的主模型）。

Claude Tag 怎么使用

比较简单粗暴，当你完成 Claude Tag 连接之后，接下来直接 at Claude 做事就行；过程中可能会涉及到你要去做一些前置授权等。

但需要注意的是，目前 Claude Tag 的所有使用必须放在 Channel 中进行；私聊是无法使用 Claude Tag 的，它只能在 Channel 中使用，你需要把它放在任何一个 Channel 中使用；不过好在是，我测试了，其实你可以在 Private Channel 中使用 Claude Tag。所以你依然可以和他一起工作。只是 Private Channel 会在管理后台看不到 Channel Name

Claude Tag 产品原语

在看 Claude Tag 的细节功能上，我们需要先理解 Claude Tag 的产品原语，以便于我们对齐对于 Claude Tag 的理解，并且让你对于 Claude Tag 的产品理解有一个更加形象的认知，避免快速沉浸到产品的具体功能细节里。同时也更好的帮助理解不同功能的服务层级。

整个 Claude Tag 从产品原语上，你可以定义包括三个大类：Space（任务和行为发生在哪）、Capability（能执行和发生什么样的任务）、Control（如何控制这些任务的发生）。

Space 又可以进一步细分为 Organization、Workspace 和 Channel，后两者可以直接对应到 Slack 的相同概念（Claude Tag 如今还是和 Slack 有较深的绑定），且 Channel 是会话中的最小单元。和 Slack 一一对应可能是源自 Claude 团队自己在用，所以也就没做更多其他品类的兼容。Session 和 Routines 则是会发生在这些 Space 中的具体的会话；Session 是由人类触发的行为，而 Routines 则是由时间触发的行为。底部的 Environment 则是两个 Session 的运行环境；

Capability 则可以细分为四个子类：Repositories、Domains、Plugin、Credentials ； Repositories 可以提供让 Claude Tag 访问的权限，你可以同时链接多个不同 Github Org 的多个 Repo，从而让 Agent 可以在多个 Repo 中协作。Domains 则给 Claude Tag 了网络访问权限，通过 Domains 的配置，让 Claude 可以访问到目标的网站，从而获取到必要的信息，从而确保 Agent 的网络行为是可管控的，避免出现信息异常出网的情况。credentials 则提供了不同 SaaS 服务的链接能力，在完成授权后，Agent 会获取到对应的授权，以及一些预制好的 API 请求方式，从而你可以让 Claude Tag 在整个过程中，可以访问到一些外部的 SaaS，从而搞定所有的工作。Plugin 则是一个我们大家相对熟悉的概念，之前在 Claude Code 当中就有，Claude Tag 使用的 Plugin 基本上是一致的；不同的是 Claude Tag 不会执行其中的 Hook，但对于 Skill 和 MCP 都是完全支持的。

在 Capabilities 最下方，还有一个虚线的 Access Bundle；Access Bundle 是一个 Capabilities 的打包合集，其中包含了Repositories、Domains、Plugin、Credentials、Instructions。你可以在某个 Channel 中找到专属的配置，也可以直接添加一个 Access Bundle，来批量管理这些内容；从而，你可以非常快速的将一组预设好的 Access Bundle 给应用到某个特定的 Channel 上。从而快速完成不同 Channel 的配置。这里有一个特殊的是，Instruction 也是可以放在 Access Bundle 当中一起传递的；不过在产品的原语中，我将他放在了 Control 中。所以这里 Access Bundle 横跨了 Capabilities 和 Control。

在 Control 中，则汇聚了各种对于 Agent 的控制能力（aka：让 Agent 更好的做事），这里包括了我们刚刚提到的 Custom Instruction、Memory、Auto mode allow rules、Channel name rules、Channel name rulesd等一系列细节产品功能，这里比较重要的是 Custom Instruction 和 Memory。Custome Instrucion 会出现在 Org、Channel 级别的配置当中，对应的描述会出现在 Agent 的 System Prompt当中，引导 Agent 行为。Memory 则记录了你在和 Agent 之间的交互中产生的信息，支持频道级别的 Memory 和全局的 Memory ，从而可以实现一些很有意思的用法（比如 Claude Tag 宣发中的一个 Case: 不同用户在不同 Channel 中和 Claude 聊同一件事，Claude Tag 会主动告知另外一个用户所做的决策）。其他我们就不再专门讲述，稍后会按照具体的功能细节时再说。

当你了解了 Claude Tag 的产品原语、定位和他们之间的关系之后，我们就可以来看看他的一些底层设计机制和数据状态了，能帮你更好的理解后续的一些功能设计。

Claude Tag 的一些数据设计

对于整个 Claude Tag 来说，你可以认为数据大概是这个样子的。

所有的数据都归属于某个特定的组织；组织下可以拆分多个不同的 Workspace（就像你可以是 Openai + 对应的 FDE 组织）。图的上部
每个 Workspace 里可以有一整套独立的 Channel、Memory 等机制；图的中左部。
当你进入到每个 Workspace 之后，你会看到 Workspace 内部的 Memory（工作区级别的），然后里面可以有不同的 Channel 来进行日常的沟通和不同工作的分配。比如有的做 A，有的做 B；有的做 C；大家分布在不同的 Channel 里；图的中下部
每个 Channel 中有自己的 Channel Memory 、Custom Instruction、Access Bundle、Plugin、Credentials、Repository 等一系列 Agent 运行所需要的信息。用户可以根据自己的需要选择合适的内容。图的中右部。
Channel 内部，会同时出现多个 Session 或 Routine。且由于存在自定义 Environment 的能力，可能会出现部分运行在 Anthorpic 的 Runtime 里，部分运行在用户自建的 Runtime 里。

上面的这种数据组织方式，很好的满足企业对于数据的管理诉求：

Claude Tag 的一些产品设计细节

围绕这上述的产品原语、产品数据设计；和面向 To B 的产品设计，里面出现了大量很符合 To B 产品直觉的产品设计。

Claude Tag 是组织买给你的，所以组织、Workspace、Channel 当中，都要能够给你的 Channel 设定不同的 Custom Instruction，从而确保你在使用 Claude Tag 做应该做的事情。正常情况下时按照顺序一层层拼接。

一个公司可能会存在不同的部门和分公司；不同的产品团队也可能会使用不同的 Slack Workspace ，从而更好的做好权限管控。因此，要支持一个 Claude Tag 能连接多个 Slack workspace。

一个 Agent 想要完整的完成一系列工作，不是简单的 Prompt 、Skill 就能解决，依赖MCP、鉴权、Skill和一定的指引。如果一个 Agent 要被持续复用（比如做客服 Channel 用），那么提供一个打包的 Access Bundle 就是必要的。

由于每个 Channel 都不是从 Day 1 就开始思考 Access Bundle，和目前这种 Channel 中除了 Access Bundle 还能单独配置 Credentials（在单独Channels 里叫 Connector ）、Plugin 的能力，我猜测大概率他们是先有 Channel 级别的单独配置，后面共享多了，干脆提供了单独的 Acess Bundle。目前已经出现每个 Channel，很快可能就会去掉 Channel 级别的配置，直接改 Channel 上的默认的 Acess Bundle 就行。

在让 Agent 工作时，会涉及到一个 Agent 可能有多种职能，因此允许 Access Bundle 的叠加

由于在 Slack 的对话式交互中，进行权限审批是一个复杂和不好判断的事情，因此，设计了 Auto mode allow rules，允许用户根据需要，写一些简单的规则，来让 Agent 自己进行 Auto mode 下的判断。一方面相信 Agent 的能力；另一方面，也给了企业足够的控制权。对于 Claude 还不擅长的业务领域，提供了足够的逃生空间。

因为要把 Claude Tag 用在对外客服，因此支持 Claude Tag 被 Guest 访问；但对于不把 Claude Tag 用作客服场景的企业来说，可以直接关掉这个 Feature。

Claude Tag 似乎改了一次计费逻辑；在上个月我刚开通的时候，是你充值多少用多少；上个月两个任务花了我 $10 ；我赶紧把默认模型改成了 Sonnet 5 ；但今天写这个 Blog 的时候发现，似乎也变成了 Credit 的机制。如果是这样的话， Claude Tag 还蛮香的。

如果是将 Claude Tag 用在客服支持等场景，可能会出现某些特定规则的群名，这些群名可能是希望 Claude Tag 加入或者不加入的，所以这里还会有专门的 Channel Name Rule；有白名单有黑名单；白名单会自动加入；黑名单则是绝不加入。对于一些做客服的场景，完全可以把 Channel 名写成 [Channel Support]，然后等 Claude Tag 自己进去做支持。

Claude Tag 的 Memory

Memory 是如此的重要，以至于我认为我一定要专门开一章来写它。如果你要做仿品，只做一件事，那我认为就是做这个 Memory 体系。

Claude Tag 也为其产品设计了 Memory 的机制，

你可以看到，Claude Tag 的 Memory 是以树的形式来组织的：

你会先在 workspace 级别的 Memory 中，看到每个 Channel 中的 Memory ，但这里其实是各 Memory 的 Channel 的总结，更多是一个 Summary；而不是完整的 Memory；

而 Channel 级别的 Memory，你需要切换到 Channel 的选项中，查看详情。

在实际的使用时，memory.md 会作为索引，加载到 System prompt 中，Agent 根据需要，自己加载别的文件

且系统会根据相关性，通过对 Description 的二次判断，正式判断是否需要加载 Memory 当中的细节，并取前4K 放在 context 中，方便 Agent 进一步自己去读。

Claude 一个 Channel 中可以有多个 Session （每个 Threads 都是一个新的 Session），Claude Tag会在开始处理任务的时候加载 Memory，因此，如果某个 Threads 写入了 Memory，另外一个 Threads 大概率需要到下一次调用时才能加载到。

在写入 Memory 的时候，Claude Tag 是在本地以文件夹和文件的方式组织 Memory， Agent 在必要的时候，写入相关的 Memory，当然，你也可以自己主动和他说。

Claude 会把 Memory 写入到 Channel 和 Silo 文件夹；这两个文件夹的区别主要在于silo存储的是 workspace 级别的 Memory；而 Channel 存储的是本 Channel 自身的 Memory，这样就可以同时兼顾本 Channel 和全局的 Memory，从而确保 Agent 能及时获得必要的 Memory；同时，因为 Agent 可以同时看到两组 Memory，就可以有所取舍，将 memory 放在合适的位置。

===== 我在沙箱里看到的目录（文档未描述） =====
/tmp/claude/memory
`-- team
    |-- channel
    |   |-- .memory-sync
    |   |-- .memory-sync-basis
    |   |-- MEMORY.md
    |   |-- bestony-language-and-timezone.md
    |   |-- claude-tag-custom-instructions-layering.md
    |   |-- claude-tag-primitives-review.md
    |   `-- report-delivery-format.md
    `-- silo
        |-- .memory-sync
        |-- .memory-sync-basis
        `-- channel
            |-- C0BQB2J46D6
            |   |-- MEMORY.md
            |   `-- report-delivery-format.md
            `-- C0BQB5WPQD6
                |-- MEMORY.md
                `-- bestony-timezone.md
7 directories, 13 files