人间万象:每天十几个小时的转录,我在看什么

陈婧霏发了一首新歌,叫《人间万象》。 世界是一张网,谁在编织方向。 有人跌落了黑夜,有人等待春风。 陈婧霏《人间万象》 我很喜欢她。听完觉得这个歌名刚好能当一个切口,聊一件想聊很久但一直没找到时机的事——我有一个持续观察世界的习惯。 好奇心和那扇窗 往大了说,叫见天地、见众生、见自己。往小了说,就是一种比较纯粹的好奇心。 我的关注列表里不单有我认同的东西,也会有我不太认可、但觉得是一个样本的东西。见过足够多的样本之后,你会真正理解为什么在网上争论大抵没什么意义——你不知道屏幕背后那个人的整个人生背景和思考方式到底是怎样的。 这个世界有一个有趣的分野:一批人在用 ASR 把各类内容变成文字、加速理解;另一批人在用 TTS 把文字变成声音、随时随地听。我属于前者——日常看视频基本都是三倍速,更多时候干脆把音视频转成文字来读。 但文字的表达门槛终归比音视频高太多了。 一个工作繁忙的人,可能只有时间录一段播客或拍个口白视频;一位一线从业者,日常就是拍个视频吐槽几句,写文对他来说显得太正式了。当你想以更广泛的视角去看不同人的真实体验时,音视频会比文字丰富得多。 还有一层:文字的审核门槛更高,这是一方面。另一方面,随着提速降费、上网人群的扩大,公共表达空间也在收窄——水至清则无鱼,你只能在最大公约数里面找话题、聊一些非常"正确"的内容。两相叠加,文字的世界越来越干净,也越来越安全。相比之下,音视频还是有机会传达一些更真实的、没那么"正确"的东西。 至少对我们这代人而言,这还不算太大的问题——毕竟经历过草莽的年代,水面上水面下的东西都有所涉及。但对于更年轻的一代,如果主要依赖的信息来源就是网络,那可能需要非常高的悟性,才能从各种自我阉割里面品读出一些水下的信息。不然的话,就只能靠家庭教育之类的方式来补了。 总之,为了获得对整个世界更广阔的感知,音视频是一个非常高价值的消费渠道。所以我给自己搭了一套音视频转录工具,自动处理各个平台的内容。每天系统处理的转录时长大概在十几个小时以上。 万种人生 那这十几个小时里,我在看什么? 常态化的订阅覆盖了法律、情感、餐饮创业几个方向,也有不少 AI 和 Agent 相关的经验分享、采访杂谈,偶尔还有些影视八卦。但比起品类标签,更有意思的是你从里面看到了世界的哪些剖面。举几个例子。 一个 07 年出生的女生,高考完当晚开了一场深夜直播。 她学纯文科,北京人,“普通家庭”——她反复强调这三个字。直播里的状态是典型的考后癫狂:语速极快、话题跳跃、自嘲里带着真实的焦虑。她向往 A-level 和柏林的教育,但家庭经济条件意味着她只能走体制内路径,“研究生再出去看看”。 一个 Z 世代,在直播间对几百个陌生人袒露自己的困惑、对教育制度的不满、对未来的迷茫。那种"心比天高"和现实约束之间的落差,在她身上非常直白地呈现。你很难在任何文字媒介上看到这种烈度的真实。 一位医生,用概率论算了一笔账。 韩医生因为漏诊被判刑,这件事在医疗圈炸了锅。而另一位已经转行的医生,用了一个数学概念——生日悖论——来解释自己为什么早早离开了临床:当样本量足够大的时候,任何小概率事件都会变成必然。一个临床医生一辈子接诊的患者数量,远远超过了这个阈值。漏诊、意外这类纠纷,过去尚有"赔钱了事"的出口,但入刑化的趋势把风险拉到了无法承受的级别。 他把这笔账算清楚之后,做了一个不可逆的职业选择。用他自己的话说:提前跑路,防止墙倒砸到我。这不是情绪化的抱怨,是概率论推导出来的理性决策。 一位在城投领域干了十余年的从业者,对着镜头聊了近三万字。 全国城投都是举债过日子,没有靠自己现金流的——这是他的原话。他描述了一种你在书本和新闻里看不到的运转方式:城投公司本质上是地方政府的融资平台——你所看到的城市基础设施,很多就是通过这类平台筹资建起来的,背后的资金链条远比外人想象的复杂和微妙。一个年轻同行写信给他,字里行间充满理想主义的质疑。他的回复浓缩成八个字:和光同尘,但保持清醒。 一个 B 站 做婚恋咨询的 UP 主拆解了"情绪价值"这个词。 她做了一个简单的性别互换实验,就揭开了这个流行概念是怎么从"美好的情感互动"一步步变成"单方面索取工具"的。你在婚恋市场的各种样本里反复看到类似的现象——一个好词被层层扭曲之后,变成人和人之间互相伤害的武器。 新加坡总理接受《金融时报》采访,谈"后美国"秩序。 一个小国的领导人,用极其冷静的语言描述了一个正在发生的变局:世界正从单极走向多极,过程漫长且混乱,小国不能坐等事态明朗。这种视角的高度和坦诚,你很难在中文互联网上找到对等的表达。 还有更多日常的碎片。 一线外卖骑手对配送系统的吐槽。网约车司机在车里录的独白。一位教师对自身处境变化的叹息。一位刚开始学数学的本科生,对 AI 时代数学何去何从的迷茫。 除了这些随手刷到的碎片,我也会主动去挖一些长内容——各行各业人物的访谈、采访、对谈式的纪录片,它们本身都是整个世界的剖面。很多小宇宙里的素人播客,订阅率可能很低,但有时候我也会主动丢进系统处理一遍,看看有什么有趣的信息。 这些内容没有一个能构成完整的"新闻"或"观点"——但法律纠纷里你看到生意、婚姻、友情之间的苟且,看到很多人性的幽微之处。情感咨询里你看到不同的人在婚恋市场上各自的诉求、碰撞和错位。勇哥说餐饮则是一部人间花式亏钱指南——你会真觉得,傻子太多了,骗子可能都不够用了。 观察人类物种的多样性和世界是怎样组成的——这是我长期的课题。人间万象,总是能多看一点的。 工具:我怎么看到这些 去年 4 月,为了更高效地消费音视频内容,我开始做 VideoTranscriptAPI。最开始非常粗糙——只能做 B 站等几个平台的下载转录,没有校对,没有区分说话人,没有推送,没有网页阅读。客观来讲,这个项目也算是完整见证了我整个 Agent 时代工程能力的提升。 除了观察世界,它也承载了不少内容学习的需求——很多 YouTube 上的经验分享、小宇宙的高质量对谈,我都是通过这个系统转成文字来读的。 一年多过去,缺位慢慢都补齐了。现在它支持 YouTube、B 站、小宇宙、抖音、小红书、视频号、Twitter 等主流平台;有 WebUI 可以操作,也有给 Agent 用的 Skill 接口。核心能力: ...

2026年9月14日 · 1 分钟 · 立行

老树开新花:中小团队的 Agent 落地框架

老树开新花 这篇文章的底稿是一段 45 分钟的语音思考。延续这个系列的传统——作为人类,你只需要读懂思路和框架;具体的执行细节,交给你的 Agent。 文末附录里有给 Agent 读的参考资料。 前置推荐阅读:Context is All You Need(上下文工程基础)、风控、设计哲学与模型选择(模型分层策略)、将军赶路不追小兔(多 Agent 调度体系)。本文聊的是一个不同的视角——不是"我个人怎么用 Agent",而是"一个传统团队怎么让 Agent 落地"。 开篇:为什么聊这个话题 过去半年我写了不少关于 Agent 的文章,但都是个人视角:我怎么搭环境、怎么调度、怎么在手机上遥控。这篇换一个角度——组织视角。 我目前在一个跨境电商的业务团队里,推进团队借助 AI 来提效、提规模。从流量端到供应链端,这是一个非常传统的行业,团队里什么角色都有——做投放的、做运营的、做供应链的、做设计的。这不是一个从零建起来的 AI 公司,而是一个已经跑了很多年的旧组织,想要在 Agent 时代找到新的增长空间。 以下基本上都是我的一手实践经验。 为什么要加上"中小团队"这个限定词?因为对大部分中小型团队而言,合规法务上的要求没那么重,公司内部一切以效率为主,很多东西实际上比较草莽。这样的话,你在推进过程中可以因为追求效率来接受一部分合规成本——等问题先出现再处理,是一个可接受的范围。这是大企业做不到的事。 在开始之前,先说一个我越来越确信的判断: 个体提效 10 倍是容易的,组织提效 20% 是困难的。 为什么?因为组织提效不只是上下文的问题——它涉及权限审批、基础设施建设、权力划分,这些组织层面的障碍才是真正难啃的骨头。上下文在技术上反而是最容易着手的部分,但这不代表它不重要——恰恰相反,上下文的质量对 Agent 的输出质量是决定性的(我在 Context is All You Need 里详细讲过)。而协作本身就是有损的:信息在人和人之间传递,一定会丢失、变形、延迟。 所以在 Agent 时代,协作其实是一个次优解。最高效的方式是:完整的业务上下文在一个人的脑子里,由这个人借助 Agent 去 handle。每多加一个人参与,你都应该多想一步——这个人是不是非加不可?还是 Agent 就能替代这个协作环节? 这不是说不要团队,而是说 Agent 时代的组织优化方向,不是"让更多人更好地协作",而是"让更少的人借助 Agent 覆盖更大的范围"。 带着这个前提,我们来聊怎么在一个传统团队里落地 Agent。 一、AI Native 是方向,不是目标 先说一个定义。我体感下来,一个 AI Native 的组织应该满足三个条件: ...

2026年9月8日 · 5 分钟 · 立行

Agent 不下班:手机遥控器的进化

本文是「Agent 不下班」系列的手机方案升级篇。基础架构怎么搭,见 Agent 不下班:随时随地随设备的开发体系;多 Agent 怎么调度,见 将军赶路不追小兔。这篇聊的是:整套体系切换到 Herdr 之后,手机端的开发体验怎么跟着升级。 还是那句话——作为人类,你只需要读懂架构思路和选型逻辑。具体的安装部署,丢给你的 Agent 去执行就行。 起因:断连之后的空虚 今天真是悲惨的一天。下午 Codex 用了四年的老账号突然被封了,莫名其妙,没有任何逆向也没有反代,正常使用。好不容易收拾好心情,晚上回到家发现远程开发机断连了。 平时回到家之后,都是打开手机继续和 Agent 协作——审一下主脑的方案、批几个任务卡、看看执行层的进度。和它们断连以后,一下子觉得特别空虚,健身完了也不知道该干嘛。 干脆就来写这篇文章吧。之前一直想写但没动笔——最近整个体系已经从 tmux 切换到了 Herdr,手机端的方案也跟着做了一次大升级。HerdWeb 其实已经开发完成并且用了一段时间了,正好趁这个空档把思路整理出来。 一、1.0 方案的两道裂缝 在 Agent 不下班 那篇文章里,我推荐的手机方案是 HAPI + tmux,网络走 Tailscale 或 Cloudflare Tunnel。用了一段时间之后,出现了两个越来越明显的问题。 裂缝一:tmux 的状态盲区 在 多 Agent 调度 那篇里我提过,我现在的调度思路是主脑派任务卡——主脑负责规划和拆任务,执行层在后台自主执行。 这个模式下,tmux 的标题(title)机制就不够用了。两种场景特别痛: 主脑已经干完了,但 tmux 标题没变。 你不知道它在等你,任务就一直卡着没往下推进。 tmux 标题变了,但后台执行层还在跑。 你点进去一看,其实什么都不需要做。白白浪费注意力。 同时开五六个主脑的时候,这两种情况反复出现。你的精力被大量消耗在"判断谁需要我关注"上——而不是关注本身。 裂缝二:HAPI 的两个硬伤 HAPI 本身做得不错,但有两个问题让我最终放弃了它: 第一,多了一层渲染。 HAPI 把 Agent 的终端界面重新渲染成网页。这个过程中,有些原生 Coding Agent 的命令和交互它没法完全支持。从电脑切到手机的时候,总能感觉到一个明显的"翻译层"在中间。 第二,跨会话消息接管。 HAPI 最近更新了一个功能——不同 Agent 会话之间可以互相沟通。这个功能可能有它的使用场景,但问题是没办法关闭。结果就是我在本地开发的时候,正和一个 Agent 聊着,对话突然被另一个 Agent 的消息"劫持"了。体验非常差。 ...

2026年8月26日 · 3 分钟 · 立行

将军赶路不追小兔:多 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 测试机的健康状况——最终它变成了调度系统的"仪表盘",辅助决策"这个任务该分给谁"。 ...

2026年8月9日 · 5 分钟 · 立行

人生的塞尔达时期:日均 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 亿往上(所有渠道合计)。 ...

2026年7月21日 · 4 分钟 · 立行

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 上如果没有类似的工具,我就很难切过来。 ...

2026年6月30日 · 4 分钟 · 立行

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 整套架构分四层:服务端 → 会话管理 → 网络 → 客户端,再加一组辅助工具。从里到外逐层展开。 ...

2026年6月28日 · 7 分钟 · 立行

在哈萨克斯坦:用 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,当地卡在乡下的网速都可以很顺畅地加载图片。 ...

2026年5月5日 · 3 分钟 · 立行

我的硬件我做主,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 的形式分享出来。 ...

2026年4月6日 · 2 分钟 · 立行

别关遥测: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 用,可以跑出远超订阅价的调用量。这中间的利润空间非常大,所以有很强的经济动机。 ...

2026年3月31日 · 6 分钟 · 立行