杂谈by立行

记录一个数字生活流民的所见，所思。

将军赶路不追小兔：多 Agent 调度体系的架构与实践

将军赶路不追小兔这篇的底稿是一段 80 分钟的语音分享。依然延续这个系列的传统——作为人类，你只需要读懂思路和架构逻辑；所有具体的执行细节，把文章丢给你的 Claude Code 或 Codex，让它去做就行。开头：为什么要聊调度体系在人生的塞尔达时期那篇文章里，我用了一张架构图和一段概述提过"多 Agent 调度"这个话题——主脑负责规划、执行层负责干活、门禁负责把关。但那篇的重心在 Token 经济学和模型军火库，调度体系本身只是一笔带过。这篇就是展开讲。先回到一句话原则：Agent 的注意力是非常宝贵的东西，你应该把它用在解决高质量的不确定性上面，而不是琐碎的事情。怎么理解这句话？你可以把 Agent 的注意力想象成一个人的工作精力。如果它花一个小时去处理登录验证码，就少一个小时去干正事。我在 Context is All You Need 里用过一个比喻：注意力就像你的工作台面——台面就那么大，放了杂物就没地方干正事。在那篇文章里聊的是管好一个 Agent 的"工作台"；这篇是——当你同时有 Claude Code、Codex、Kimi、Grok 这一堆 Agent 的时候，怎么把每个 Agent 的工作台面都利用好。这完全可以类比 CEO 的精力分配。CEO 的精力是有限的，应该只用来决策、高价值的方向判断、找资源——而不应该浪费在一线执行层的细节上。将军赶路，不追小兔。一、这套体系是怎么长出来的很多人看到"多 Agent 调度"可能觉得这是个很重的架构设计，但它最开始其实是一个非常朴素的想法。那时候 Fable 5（Claude 家目前最顶级的模型）还是限量内测，不知道以后还有没有机会再用。所以我用得抠抠搜搜：Fable 5 只负责规划设计，所有具体的执行任务全外包给 Sonnet 5（一个便宜且能力均衡的模型）。成本倒逼出了最初的分工逻辑。后来的演化路径是这样的：起点：多个 Coding Agent 各有各的配置文件，维护起来很麻烦，单独建了个代码仓库（可以理解为一个项目所有文件集中存放的地方）来统一管理。第一步：既然配置文件都集中了，能不能试着把其他 Coding Agent 变成执行层？第二步：执行层能自动跑了，需要知道各家套餐还剩多少额度——于是写了个监控面板。第三步：监控面板有数据了，能不能根据剩余额度自动选执行器？于是有了配额感知调度。每一步都不是预先设计的，而是在使用过程中"长出来的"。你会发现建好一个组件之后，它会产生意想不到的新用途：监控面板一开始只是统计各套餐的用量，后来加了 Token 消耗统计（分模型、分项目、分设备），又加了开发机的内存和工作区清洁度监测，再加了 CI 测试机的健康状况——最终它变成了调度系统的"仪表盘"，辅助决策"这个任务该分给谁"。 ...

人生的塞尔达时期：日均 40 亿 Token 的那一周

这篇的底稿是一段 80 分钟的语音分享，聊的东西比较杂：我最近的沉迷状态、Token 的使用逻辑、Skill 和软件的边界、人机协作方式的进阶，以及我在用的所有模型。依然延续这个系列的传统——作为人类，你只需要读懂思路和架构逻辑；所有具体的执行细节，把文章丢给你的 Claude Code 或 Codex，让它去做就行。人生的塞尔达时期开头：Token 用光了这个晚上好久没有更新了。原因很简单：沉迷于薅 Token 羊毛中。多个 Token 套餐已撞线 Claude Code 7 天撞线、Fable 5（Claude 当前最顶级的模型）撞线、Codex 7 天撞线，Kimi Code 也到了 94%。备用渠道里 GLM 还剩 63%，Grok 剩 32%，DeepSeek 和百炼倒是余量充足——但主力全歇了。所以干脆趁着等额度恢复的间隙，写写文章吧。这个话题其实之前就想写，定的主题叫——人生的塞尔达时期。聊的东西可能会比较杂，很多都是关于 AI 的，各位读者朋友，且看吧。一、人生的塞尔达时期塞尔达是 Switch 上的一个游戏。我本身其实不怎么玩游戏，之前玩过的也都是派对游戏或者双人游戏，和朋友一起打发时光用的。一个人玩的游戏，大概只能追溯到小学时候的跑跑卡丁车。但当我接触《塞尔达传说：旷野之息》的时候，一下子就沉迷住了。那段时间，每天脑子里只有塞尔达里没有探索到的地方。晚上经常玩到两三点，周末基本上一整天都泡在里面。你不知道疲惫，吃饭、出行之类的事情都可以往后排——你的脑中只有海拉鲁大陆。塞尔达玩家最常说的一句话是：很想要一个没有玩过塞尔达的脑子。因为整个游戏毕竟是有限的，当你把很多地方都探索过、支线任务也打完了，再玩的时候就很难找回首次接触时那种惊喜和沉迷感。后来《王国之泪》出来，我也玩了一下，但明显没有一代上头——客观讲，很多地方都是已经探索过的了。但是最近，我觉得我又找回了这种感觉。或者说，我可能进入了一段人生的塞尔达时期。每天实际上是被好奇心塞满的，去探索很多不同的方向，解决很多切实的问题。经常一干起来，就跟 Agent 聊到一两点。我有一个朴素的信念：一个东西只要它的数据在线上，大语言模型之前有过相关的训练数据，那原则上都可以拿 Agent 去尝试——之前的软件篇、硬件篇，都是这么试出来的。客观地说，我整个 7 月份的作息，都是围绕着 Claude Code 里 Fable 5 的额度有效期、还有 Codex 的额度重置时间来安排的。7 月 10 号之前，我的日均 Token 消耗大概只有七八亿；7 月 10 号新一轮额度周期开始，怕重置浪费，要集中消耗 Fable 5 和 Codex 的额度，消耗量迅速拉升——连续几天日均都是 40 亿往上（所有渠道合计）。 ...

Agent 的遥控器：一台 MBA 的软件清单

本文是「LLM 吞噬一切」系列的客户端篇。远端 24h 大本营怎么搭，见上一篇 Agent 不下班：随时随地随设备的开发体系；硬件基座怎么选，见 Agent 的家。这篇聊的是：当你的开发主力都在远端服务器上跑着，手里这台笔记本到底该装什么。先说背景。我最近刚从 Windows 笔记本切到了 MacBook Air M5 32G。在上一篇文章里我就提过，这个时代笔记本只是一块屏幕加一个键盘，所以买 Air 不买 Pro。这台 MBA 不承担长期开发任务，它只干两件事：临时性的本机小活：给本机软件提个 bug、改个小工具、管理一下云端服务当云端所有机器的遥控台：远程桌面连 Windows 主机、SSH 进 Linux 虚拟机、管理文件所以这份软件清单，本质上是在回答：一台"遥控器"级别的笔记本，怎么配才顺手。 MBA 作为遥控台连接云端所有设备还是那个原则：作为人类，你只需要知道自己有没有类似的痛点。如果有，把这篇文章丢给 Claude Code 或 Codex，让它帮你找方案、装软件。我的选择只是参考，不是标准答案。一、从 Windows 切到 Mac：两个曾经的顾虑在决定换 Mac 之前，有两件事让我犹豫了很久。外接屏幕：三块变两块在 Windows 上我外接了三块屏幕，工作区非常宽裕。MacBook Air M5 芯片在开盖状态下最多原生支持两块外接屏幕。超出这个数量需要借助 DisplayLink 方案（通过 USB 传输视频信号），但它的显示效果和稳定性都不如原生支持到位。最终还是接受了这个限制。我现在外接两块屏：一块小米 34 寸 2K 带鱼屏，一块普通 27 寸 2K 屏。加上 MBA 自带的屏幕，三块也够用了。 Quicker：曾经离不开的 Windows 自动化工具在 Windows 上我一直重度使用 Quicker。它可以很方便地做各种自动化操作和快速启动，设计得非常直观。我一度觉得，Mac 上如果没有类似的工具，我就很难切过来。 ...

Agent 不下班：随时随地随设备的开发体系

本文是「LLM 吞噬一切」系列的开发环境篇。硬件基座怎么搭，见上一篇 Agent 的家，AI 时代个体的硬件基座；软件层怎么搭，见我用 AI 长出来的那些工具。这篇聊的是：硬件和软件都就位以后，怎么让你的 Agent 24 小时在线，而你可以随时随地、用任何设备接入。还是那句话——作为人类，你只需要读懂这篇文章的架构逻辑。所有具体的软件安装、环境配置，把这篇文章丢给 Claude Code 或 Codex，让它去执行就行。一、一个认知转变在硬件篇里我就提过：按 Coding Agent 当前的发展速度，我大概率不会再买高性能笔记本了。所有预算会迁移到高性能主机上。笔记本出门唯一的需求就是更大的屏幕看得更舒服——MacBook Air 这种便携续航型产品，才更符合 AI 时代编程的需求。前阵子听说苹果供应链成本要上涨，连夜就订了一台 MacBook Air M5 32G + 1T，准新在保二手 10,300 块，同款原价 15,000。收到手没几天，苹果果然全线涨价。也算享受了一下认知变现的红利。为什么买 Air 不买 Pro？因为在这个时代，笔记本只是一块屏幕加一个键盘。所有的算力、所有的代码仓库、所有正在跑的 Coding Agent 进程，全都在远程的服务器上。你手里的设备只需要做一件事——连上去。核心思路就一句话： 24 小时在线的服务器跑 Coding Agent，所有其他设备都是远程接入的瘦客户端。这是整篇文章的底层逻辑。下面的所有内容，都是围绕这个思路展开的。二、架构总览先上一张全局拓扑图，让你有个整体概念。后面每一层会逐个展开。 graph TB subgraph 服务端["🖥️ 服务端（24 小时在线）"] MAC["Mac StudioM1 Max 64G"] LINUX["X86 主机PVE + Ubuntu 24.04"] end subgraph 会话层["⚙️ 会话管理层"] TMUX["tmux会话保持 & 后台运行"] AGENT["Coding AgentClaude Code / Codex"] HAPI_S["HAPI RunnerWeb 化会话管理"] end subgraph 网络层["🌐 网络层"] TS["Tailscale异地组网（设备互联）"] CF["Cloudflare Tunnel+ Access 鉴权"] end subgraph 客户端["📱 客户端（随设备接入）"] LAPTOP["笔记本Terminal / CMUX / VS Code"] PHONE["手机HAPI Web / Telegram"] TABLET["平板浏览器"] end subgraph 辅助["🔧 辅助工具"] CCCLIP["cc-clip远程图片粘贴"] SYNC["Syncthing文件双向同步"] BESZEL["Beszel多设备监控告警"] UPS_D["UPS断电保护"] end MAC --> TMUX LINUX --> TMUX TMUX --> AGENT TMUX --> HAPI_S LAPTOP -->|SSH| TS PHONE -->|HTTPS| CF TABLET -->|HTTPS| CF TS --> MAC TS --> LINUX CF --> HAPI_S CCCLIP -.->|图片桥接| AGENT SYNC -.->|文件同步| LINUX BESZEL -.->|监控| MAC BESZEL -.->|监控| LINUX UPS_D -.->|供电保护| MAC UPS_D -.->|供电保护| LINUX style MAC fill:#9b59b6,color:#fff style LINUX fill:#f39c12,color:#fff style TMUX fill:#2ecc71,color:#fff style AGENT fill:#e74c3c,color:#fff style HAPI_S fill:#e74c3c,color:#fff style TS fill:#3498db,color:#fff style CF fill:#3498db,color:#fff style LAPTOP fill:#1abc9c,color:#fff style PHONE fill:#1abc9c,color:#fff style TABLET fill:#1abc9c,color:#fff 整套架构分四层：服务端 → 会话管理 → 网络 → 客户端，再加一组辅助工具。从里到外逐层展开。 ...

我把听过的 234 期播客，做成了一张推荐地图

前两天在南京，刚好把《肥话连篇》历史上的 234 期播客全听完了。这档节目里时不时会推荐点东西——某个城市的馆子、最近在追的剧、用着顺手的小物件。听的时候觉得不错，心里记一句"回头试试"，然后……就没有然后了。等过阵子真想找回来某家店叫什么，只能凭着模糊的印象在脑子里翻，基本翻不到。小宇宙的这个对音频里的文本的搜索能力目前是缺位的。听播客这件事的尴尬就在这儿：信息是流过去的，你很难在当下停下来做整理，事后又无从检索。但这次我手里正好有半套现成的工具，于是干脆让它自己长出了个解法。最后的成品是一张地图： 👉 《肥话连篇》推荐地图 234 期播客里的 935 条推荐，按城市聚到了一张地图上下面说说怎么做出来的。起点：我本来就有半套工具我之前做过一个 VideoTranscriptAPI——一个音视频转录服务，能把小宇宙、YouTube、B 站的音频转成区分说话人、并且经过 LLM 校对的文字稿。这东西本来是给我那套信息处理体系用的，这次要处理播客，自然第一个就想到它。所以这件事的起点不是从零开始，而是"我手上正好有半套积木"。剩下的，就是让 Claude Code 在后台帮我把缺的那半套补齐。做了什么：转录 → 提取 → 地图整件事大致分三步，断断续续后台跑了两天。第一步，把声音变成字。先得抓下《肥话连篇》全部单集的链接——这一步本身就有个坎：小宇宙网页端默认只展示最近 10 集，想拿到全部 234 集的历史内容并不现实。好在这块我之前也探过，做在线音视频消费记录的时候就研究过怎么抓小宇宙的历史列表，这次直接复用。拿到全部链接，写脚本一股脑提交到我那台 VideoTranscriptAPI 的服务器。234 期音频排着队跑了大概一天，DeepSeek 的校对成本花了快 20 块。跑完，我就有了 234 篇区分说话人、校对过的文字稿。（这中间还有个小插曲：ASR 总把主播的名字写错，得专门做一步人名归一，不然后面全乱。这种活儿正好适合丢给 AI 顺手解决。）第二步，把字变成结构化数据。光有文字稿没用，得把里面"推荐了什么"抠出来——是美食、影视剧还是产品，各自该有哪些字段，都要规整成统一的结构。这一步我没写传统脚本，而是用了 Claude Code 最新的 Workflow 功能：对 234 篇稿子跑同一套提取逻辑。模型用的是成本更低的 Sonnet，并发大概 8，三四十分钟就全跑完了。比起自己写脚本，它更灵活——过程里冒出来的各种小毛病，它能边跑边处理掉。这里我额外较了个真：每条推荐都要能反查回原文出处。这样既能确认不是模型自己编的，回头也能跳回播客原话去听上下文。处理这么多内容，“可信"比"好看"重要。第三步，把数据变成地图。这里没做到精确每家店的经纬度，只停留在城市层级——把推荐按城市聚到地图上。那具体某家店怎么找？取了个巧：高德地图网页版支持把搜索词直接嵌进 URL（类似 Google 那种 URL 搜索），所以点一下店名就能跳到高德里搜，精确定位的活儿就甩给高德了。整个可视化另起一个项目，部署到 Cloudflare 上。（顺带一提，地图底图特意用了带审图号的合规版本——这种细节不较真，哪天就出问题。） ...

南京小记：栖霞山音乐节、玄武湖夜城墙，胡思乱想

空荡的南京城墙，幽邃到远方想写篇游记，又懒得正经写，于是先对着录音豆把想说的絮叨了一遍，再慢慢理出来。一、缘起缘起很简单：朋友说南京有音乐节，里面刚好有陈婧霏，喊我去。我秒 call。本来以为是头一回来南京，后来才惊觉——其实是第二次了。朋友这次临时出了点意外没能成行，于是整趟就成了我一个人的 solo trip。二、出发：新 T3，好看但不太中用九点多的飞机，五点半就爬起来，坐城际赶去广州新 T3 机场。设施是真不错，可惜美得不太实用——拖着箱子走那段地毯，费劲得想骂人。倒是充电那些细节，比老航站楼好了不少。三、落地：皮肚面，和太乡下的场地到南京先去新街口，吃了碗皮肚面——朋友照着豆包的攻略找的当地馆子，味道还行。智能眼镜的模糊抓拍，配一碗皮肚面吃完往郊区赶，奔栖霞山音乐节的场地。好家伙，这地方是真乡下。机场到市区 20 公里，市区到场地又是 20 公里，这单程光路上就 40 公里。办完入住，人已经累瘫，倒头睡到下午六点。醒来寻思：第二次来南京，总得多逛逛。不如去市区吃点东西，再找个景点散散食、自言自语嘚啵一段时间。四、玄武湖夜游：蟹黄面、骑行，和湖边的情侣搜了一圈，决定先去玄武湖附近吃饭。本想吃小笼包配鸭血粉丝，结果那家店晚上不开，只好在地铁站附近的点评上另找了一家，蟹黄面加小笼包。一碗蟹黄面配蟹黄，88 块。说实话我对这风味没什么感觉——也可能是工艺的问题——吃得意兴阑珊，还得靠一堆配菜来解腻。吃完去玄武湖。打车不好打，一看也就 4.7 公里，干脆骑了辆共享单车过去，八点多。南京的路修得挺适合骑车。半道上看见个小女孩跨坐在电动车后座，背靠着大概是她爸的人，挺有意思，可惜想抓拍时已经骑远了。本以为夜里的玄武湖没什么人、适合一个人溜达，到门口才发现完全想错了——人巨多，里头各种表演，商业化拉满。刚进玄武门那会儿，旁边一对游客在问——这玄武门，跟唐朝的玄武门之变有啥关系？听得我一愣，又觉得好笑。两座城门同名，本质是中国古代 “方位命名传统” 的体现：玄武作为北方之神的文化符号贯穿了中国古代都城建设，宫城、都城的北门常以 “玄武” 命名。唐朝玄武门直接因 “宫城北正门” 的方位得名；南京玄武门则间接得名于玄武湖（湖泊因位于六朝都城以北、契合北玄武的风水格局而得名），二者最终都溯源到同一套传统文化逻辑。玄武门，旁边就是玄武区婚姻登记绕着湖走了三四公里，倒也没走全。平时都是听播客，但想着第二天要看演出，也就循环起了陈婧霏的歌单，跟着哼唱了起来。湖边没围栏，能看见三三两两的情侣，在树下抑或岸边结对坐着。也不刷手机，就那么你来我往闲言碎语几句。晚风拂面，挺美好的。少年的心事，最是可爱。走着走着，瞥见湖边一家茶颜悦色。上上周才在长沙见过，转头南京又撞上了。脑子里突然冒出个念头：茶颜悦色不是从某个成语改的吗？可这词听太多，原成语死活想不起来。问小爱同学，大概没收清音，没给答案。最后还是豆包告诉我——哦，和颜悦色。这词如今看着都陌生，太久没说过了，满脑子只剩茶颜悦色、茶颜悦色。五、城墙夜行：闹中取静，和一个人才会想的事走着走着到了出口，忽然瞅见旁边有城墙的检票口。寻思城墙应该能上吧？问工作人员，说十点关，现在九点。门票 30 块，我犹豫了一下——来都来了，上去看看。事后证明这票买得值。上面人很少，可能快关了，颇有种闹中取静的意思。顺着台阶往上走，身后那些喧闹的声响一点点退远，慢慢静下来；往前看，整条路上可能就你一个人。很适合自我嘚啵嘚。于是我在城墙上打开录音，对着夜色，慢慢聊起了一些想法。空荡的城墙，往前看只有自己雕栏玉砌应犹在，只是朱颜改。我一直以为自己没来过南京，直到某天才猛地想起：大二大概率是来过的。只是那段记忆太浅，具体的东西全然记不清了，只剩些模糊的碎片——好像有个斜下坡的书店，买过一个小熊挂件挂在单肩包上，后来包不背了，挂件也断了。很多东西就这么不声不响地散掉。或许是这个原因，我对南京的印象，一直很淡。现在再来，整个人从容多了。经历这么些事，会更清楚自己是怎样的人、想要怎样的关系、到底在追什么。去哪儿也完全没有必然打卡、必然出片的执念，更多是想多体验、多记录。 ...

在哈萨克斯坦：用 AI 规划，被风吹走无人机，与黄金时代的余晖

在哈萨克斯坦：用 AI 规划，被风吹走无人机，与黄金时代的余晖一、缘起一对情侣朋友要去哈萨克斯坦，问我五一的安排。刚好我没有安排，遂欣然同意，还拉上了大学舍友。整个行程 4 月 25 号到 5 月 4 号，请了 4 天年假，大概八九天。说实话现在出行更多还是在乎自然风光——人文方面的东西确实没那么感兴趣，也看不懂。另外就是尽量错峰。哈萨克斯坦的地形地貌和新疆差不太多，但至少人少一些，从成本上讲也不贵。反正有人订机票酒店做行程计划，我只需要付款跟着走就行。开团秒跟。但还有很多日常的东西要谋划——交通、汇率、钱币，这些就交给了我。二、用 AI 规划一次冷门自由行整个前期规划很大程度上是借助 AI 来完成的。具体来讲比较简单：汇总多个不同平台的 Deep Research 报告，让 Claude Code 跟我聊里面哪些是共性的、哪些是冲突的，最后通过飞书 CLI 写入飞书文档，然后分享给同行的人。 Deep Research 用了四个渠道：豆包、点点、千问、Gemini。从最终结果看，我理解两块信源其实就足够了：点点（背靠小红书）：时效性强，很中国化。有些踩坑的点它提前踩过了——比如机场汇率差、建议去银行换汇，比如 Google Map 在当地不如 2GIS 好用。这是它独一无二的优势。 Gemini（背靠 Google）：信源更国际化、更规范。比如药品携带规定这种东西，在其他渠道完全看不到。全球视野对准备东西还是有帮助的。当然，里面提到的很多注意点未必会在实际过程中遭遇到，更多的是有备无患、心里有个数。反正既然已经生成了，我干脆就直接分享出来给有需要的朋友。 📎 完整出发前准备文档：飞书 Wiki 链接（含 Checklist、通信方案、换汇攻略、支付方式、交通、阿克套专题等）三、踩坑清单我们去的是阿拉木图和阿克套。这两个地方不能代表完全的哈萨克斯坦，只能谈自己的感触：很有那种上个世纪停留在苏联时期的感觉。自然风光比较原始，商业化没有那么完善——你可以看到更原始的东西，但配套体验也就没有那么方便。厕所是一个永恒的话题，后面会反复提到。以下是实际执行中踩过的坑。 3.1 SIM 卡：IMEI 绑定的坑尽管前期调研了比较多，实际执行中还是遇到了问题。我们定的方案是国内买两张漫游卡 + 当地买两张本地卡，互有备份——还真得是靠这个互补。实地体验下来：漫游卡（淘宝）当地本地卡价格 80 元 20G / 10 天 80 元 / 不限流量，超出降速市区信号尚可好郊区/乡下经常没信号，有信号也只能发文字，图片加载费劲明显更强，图片加载流畅荒野（阿克套）信号稍强一点大差不差整体更建议买当地卡。不论安卓还是 iOS，当地卡在乡下的网速都可以很顺畅地加载图片。 ...

我的硬件我做主，AI 时代按需定制手机功能

我的硬件我做主，AI 时代按需定制手机功能上一篇《Agent 的家，AI 时代个体的硬件基座》里，我提到过一个观点：AI 时代，值得拥有一台 Root 过的手机。当时给了四个理由，但没有展开讲。这篇文章就是那个展开。我会用 5 个最近实际在用的 Root 模块来演示：当你拥有硬件最底层的权限，配合 Claude Code 这样的 AI 编程工具，一个普通人能做到什么。重点不在这些具体的插件——它们只是载体。我想展示的是一种可能性：只要你能把问题定义清楚，把测试说明白，人人都可以是开发者。这篇文章会有点极客。如果你对 Root、Xposed 这些概念完全陌生，建议只看每个模块「它解决什么问题」的部分，感受一下思路就好，不必实际折腾。给不了解的同学： Root 是什么？简单来说，你买了一台手机，但厂商只给了你「住户」权限——能用，但不能改。Root 就是拿到「房东」权限，可以修改系统的任何行为。而 LSPosed 是 Root 之后最常用的工具框架，它可以在不修改 APP 本身的情况下，改变 APP 的行为——比如让微信的链接跳转到外部浏览器，或者让视频 APP 默认 3 倍速播放。下面提到的「插件」「模块」，都是基于这个框架开发的小工具。一、从零造一个插件：锁屏直达飞书机器人问题在之前《我用 AI 长出来的那些工具》里，我分享过自己的 Memo 笔记体系——通过飞书/企微/Telegram 机器人，随时随地把想法发给机器人，自动存入 Memo 并触发 AI 后处理。这套体系运转得很好，但有一个环节一直不够顺畅：记录闪念的速度。当一个想法冒出来的时候，我需要：解锁手机 → 打开飞书 → 找到机器人 → 开始输入。三步，每一步都有摩擦。我一直在找一个更快的方式，也考察过各种随身硬件，但始终没找到合适的。思路既然硬件路线走不通，那就从手机本身想办法。我知道很多 APP 支持 URL Scheme 协议——比如你点一个特定的链接，可以直接跳转到小红书的搜索页、微信的扫码页。飞书也支持类似的能力：可以把机器人的聊天窗口以 URL 的形式分享出来。 ...

别关遥测：Claude Code 源码泄露后，你可能正在做最危险的操作

昨天 Claude Code 源码泄露，中文社区最热门的操作就是照着教程关闭遥测。请不要这样做。这篇文章解释为什么。主图昨天发生了什么 Claude Code 的当前版本源码（cli.js.map）被逆向泄露了。泄露内容里包括遥测上报的全部逻辑——上报了哪些字段、走了几条链路、以及怎样通过环境变量把遥测关掉。很快，中文社区开始疯传一份"遥测拆解文档"，有一个建议是：设置几个环境变量，把遥测关掉，这样 Anthropic 就看不到你的信息了，账号就安全了。恐怕有非常多人照做了。我写这篇文章，是因为我认为这个建议不仅没用，而且有害。它会让你的账号更危险，而不是更安全。在开始之前：两个共识第一，所有风控策略都是黑盒。除了 Anthropic 内部的风控团队，没有人知道确切的规则和权重。我们能做的，只是根据现象反推逻辑，结合经验做出判断。包括这篇文章本身，也是我的推测和分析，不是内部信息。第二，风控是概率题，不是是非题。风控系统做的事情，是给每个用户打一个"风险分"，综合多个信号交叉判断。这就导致了一个现象：同样的操作，A 做了没事，B 做了被封。不是因为规则不一致，而是两个人的其他信号组合不同，最终得分不同。记住这两点，后面的分析会更好理解。一个重要背景：Claude Code 深度参与 Anthropic 的运作在聊风控之前，有一个背景值得单独拿出来说。 Anthropic 已经多次公开表示，他们公司内部大量的工作——包括代码开发、内部工具搭建——都是由 Claude Code 自己来完成的。换句话说，Claude Code 不只是他们卖给用户的产品，也是他们自己每天在用的生产工具。那么我们就有理由做一个合理推测：Claude Code 的风控策略设计、信号分析、甚至判定逻辑，很可能也有 Claude 自身的深度参与。这意味着什么？意味着你面对的风控系统，不太可能是一堆写死的 if-else 规则。它更可能具备大模型的分析能力——能理解上下文、能做多信号交叉推理、能识别行为模式。用人话说：你面对的"审查官"，可能就是 Claude 本人。而你觉得自己很聪明地关掉了遥测，在它看来，可能只是一个非常显眼的异常信号。 Claude Code 风控的两个目的在分析具体行为之前，先理解风控在防什么。Claude Code 的风控主要针对两类人： 1. 反逆向 / 反自动化有人通过逆向 Claude Code 的客户端，对外暴露 API 接口来倒卖。Claude Code 是按月订阅的（Max 套餐 $200/月），但如果逆向后当 API 用，可以跑出远超订阅价的调用量。这中间的利润空间非常大，所以有很强的经济动机。 ...

Agent 的家，AI 时代个体的硬件基座