Posts

前两天在南京，刚好把《肥话连篇》历史上的 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 规划，被风吹走无人机，与黄金时代的余晖 一、缘起 一对情侣朋友要去哈萨克斯坦，问我五一的安排。刚好我没有安排，遂欣然同意，还拉上了大学舍友。整个行程 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 时代按需定制手机功能 上一篇《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 的当前版本源码（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 用，可以跑出远超订阅价的调用量。这中间的利润空间非常大，所以有很强的经济动机。 ...

本文是「LLM 吞噬一切」系列的硬件篇。上一篇 我用 AI 长出来的那些工具 聊的是软件层我怎么搭的，这一篇聊底下的硬件基座——怎么搭、为什么这样搭，以及硬件市场的趋势判断。 这篇文章会有点极客。其实我早就想写了，拖了快一个月，结果这一个月硬件的价格又涨了不少。 硬件全景 一、我的硬件全景 先上一张全局架构图，看看各设备之间的协作关系： graph TB subgraph 网络层 R2S["R2S 软路由全局网络管理 & 分流"] end subgraph 主机与服务器 NAS["NAS 32GUnraid | 数据存储"] N305["N305 小主机PVE + Debian | 自部署服务"] MAC["Mac Studio 64GM1 Max | ASR/OCR 计算中心"] X86["X86 高性能主机 64GPVE + Ubuntu | 本地模型 & 开发机"] end subgraph 云端存储 GH["GitHub代码仓库"] JG["坚果云 / OneDrive文件同步"] W115["115 网盘 40TB大容量云备份"] end subgraph 冷备 COLD["独立断网硬盘冷备 ~40TB"] end subgraph 手机 MI14["小米 14Root | Agent 工具机"] K90["红米 K90 Pro MaxRoot | 主力机 & 日常自动化"] DB["豆包手机豆包原生 Agent"] end subgraph 随身硬件 LYD["飞书录音豆语音采集 → 飞书妙记"] GLASSES["小米智能眼镜拍照 & 录音兜底"] end subgraph 日常硬件 GUITAR["Libre Live 无线吉他情绪舒缓 🎸"] ACTION["Action 5 Pro生活记录 🎬"] end R2S -->|网关| NAS R2S -->|网关| N305 R2S -->|网关| MAC R2S -->|网关| X86 R2S -->|网关| K90 R2S -->|网关| MI14 R2S -->|网关| DB NAS <-->|镜像互通| N305 X86 <-->|镜像互通| N305 MAC -->|API 调用| X86 K90 -->|HAPI 远程| X86 MI14 -->|HAPI 远程| X86 LYD -->|自动同步| K90 X86 -->|镜像/数据| NAS N305 -->|镜像/数据| NAS MAC -->|数据| NAS NAS -->|云端同步| W115 NAS -->|文件同步| JG X86 -->|代码推送| GH NAS -->|重要数据| COLD style R2S fill:#e74c3c,color:#fff style NAS fill:#3498db,color:#fff style N305 fill:#2ecc71,color:#fff style MAC fill:#9b59b6,color:#fff style X86 fill:#f39c12,color:#fff style K90 fill:#1abc9c,color:#fff style MI14 fill:#1abc9c,color:#fff style GH fill:#24292e,color:#fff style JG fill:#2980b9,color:#fff style W115 fill:#2980b9,color:#fff style COLD fill:#7f8c8d,color:#fff 下面逐一展开。 ...

Claude Code：防封号、模型选择与设计哲学 Claude Code 配合 Opus 4.6，Codex 配合 GPT 5.4——这是目前 coding agent 领域断档领先的两款产品。我自己的配置是 Claude Code Max 套餐加 Codex 20 刀的基础套餐，大部分时候用 Claude Code 写项目，Codex 用来做一些艰难的 debug。 随着越来越多人开始接触 AI 编程，不可避免会被引导到这两款原生 coding agent 上来。而 Claude Code 作为生态更成熟的一方，使用门槛却也更高——不只是技术门槛，还有准入门槛。 本文是我在使用过程中的一些零散思考，涵盖风控生存、模型选择和设计哲学三个话题。不是标准答案，仅供参考。 如果你只记住一件事：不要在手机上安装 Claude 客户端。 这可能是目前中文互联网上从未有人提到过的风控盲区，后文会详细展开。 一、风控与生存 1.1 IP、手机号与支付 这三项是网上讨论最多的基础门槛，这里只做简要罗列。 检测维度 要点 风险 IP 类型（ASN） 区分家庭宽带与数据中心 IP，后者极高危 🔴 DNS 一致性 DNS 泄漏会暴露真实网络拓扑 🔴 WebRTC 穿透 未阻断则直接暴露真实 IP 🔴 Impossible Travel 短时间内跨国 IP 跳跃触发警报 🟡 时区 / Locale 比对 IP 显示美国但系统时区 UTC+8 = 特征悖论 🟡 手机号 虚拟接码号段被大量拉黑，初始信任分极低 🔴 支付 发卡行 BIN + 账单地址 + IP 地理位置需一致 🔴 一句话总结：仅靠改 IP 远远不够，你的整个网络环境需要自洽。 ...

Description： AI 聊着聊着就犯傻、Skill 成功率忽高忽低、复制别人的配置却跑不出同样的效果——这些问题的根源往往是同一个。理解上下文窗口，是用好所有 AI 工具的第一课。 像对待你最宝贵的注意力一样，对待 AI 的上下文。 前言：这些问题，你可能都遇到过 和 AI 聊了二十几轮，它开始前后矛盾，甚至忘了你五分钟前说的话 让 Agent 跑同一个流程，有时候一次过，有时候莫名其妙失败 把一大段数据扔给 AI 做分析，结果答非所问，或者分析得驴唇不对马嘴 同一个 Skill，换个模型结果完全不同；同一个模型，这次成功下次又失败 原来运行正常的 Skill，安装了更多 Skill 之后反而开始出错 完整复制了别人的 Agent 配置和工程设定，实际效果却和演示差了十万八千里 Meta 安全总监的 AI 助手帮他删光了所有邮件——因为对话太长，上下文压缩时丢失了安全限制 如果你有过类似的经历（或者担心类似的事发生在自己身上），这篇文章可能会帮你找到根源。 这些问题看起来五花八门，但往往指向同一个原因——上下文窗口（Context Window）。简单说，它就是 AI 的"工作记忆"，是它在回答你时能同时"看到"的所有信息的总量。这个空间是有限的，而且远比你想象的脆弱。 理解上下文窗口，是理解当下所有 AI 工具的钥匙。不论你是在用 ChatGPT、Claude，还是在搭建自己的 Agent 自动化流程，这个概念都是绕不过去的第一课。 Harness Engineering：为什么我没有追最新的潮流 业界当前最热门的方向叫 Harness Engineering——它的目标是让 AI 系统能自动纠偏、自动迭代，全程最小化人类干预。它包含上下文工程、架构约束、自动化反熵等多个支柱，确实是一个很有前景的方向。 但坦白说，目前即便是最顶尖的团队，也还处在探索阶段。OpenAI 声称部分内部系统中 90% 的代码由 Agent 编写无人类参与，但这离普通人在日常工作中可以直接复用，还有相当的距离。 而如果你去拆解 Harness Engineering 的底层，会发现它的第一根支柱就是上下文工程——把正确的信息以正确的方式喂给 AI。所以与其追一个还在演进中的顶层框架，不如先把最底层的东西理解透。地基打好了，将来理解上层建筑也更容易。 本文聚焦的，就是这个地基。 一个贯穿全文的比喻：你的工作台 为了让后面的内容更好理解，我们先建立一个比喻——把 AI 的上下文窗口想象成一张工作台。 工作台的面积是有限的（上下文窗口有上限） 桌上堆的东西越多，你越难找到关键资料（噪声导致输出质量下降） 桌子越大，租金越贵——而且不是线性增长（成本问题） 聪明的做法是把资料分类归档到抽屉里，需要时再拿出来（渐进式披露） 脏活累活可以让助手在另一张桌子上干，只把结果递过来（Sub-agent 隔离） 每天重复的手工活，应该想办法变成一台机器自动跑（流程工具化） 后面的每一个方法论，都可以回到这张工作台上来理解。 ...

上个月写了一篇《LLM 吞噬一切，我用 AI 长出来的那些工具》，聊了聊过去一年多我用 AI 给自己造的那套信息处理体系。反响还不错，收到了不少反馈。 但写完之后总觉得意犹未尽。那篇更多是在讲"我做了什么"，而这段时间脑子里一直转的，其实是一些更虚的东西——关于 AI 怎样影响我们的生活、社会关系、乃至人的价值定义。这些想法比较零碎，层峦叠嶂的，跟朋友聊过一些，姑且一并写下来，算是闲言几则。 先交代一下背景。尽管我分享了不少技术相关的东西，但本质上我对编程这件事没有狂热的热爱，始终只是拿它当实现目标的工具。我的代码水平长期停留在"脚本小子"的层级——大学学过一点 C++，对底层数据结构有基础了解，平时用 Python 写写脚本，但也仅此而已。语言底层那些语法、规范实在太烦人，我没那个耐心去深入学。我只想问一句：能不能直接帮我把功能实现了？ 所以在很长一段时间里，我都是用各种自动化工具组合来解决问题。Windows 上的 Quicker（也是我没用 Mac 的唯一原因）、Android 上的 Tasker、iOS 上的捷径——这些自动化软件就是我之前的主要手段。写代码？更多只是拼接一些现成的代码片段，来回调试。 一、我和 AI 协作的这一路 ChatGPT 出来之后，写脚本确实方便了很多。脚本这种东西目的明确、体量小，基本上在对话框里就能搞定。但那时候想写一个完整的工程项目还是很困难——单纯的 Chatbot 缺乏对项目全局的了解，运行日志要手动粘贴给它，如果你自己都不了解项目底层，想把一个项目 run 起来都费劲。困难更多是耐心层面的，夹杂着知识框架上的缺失。 不过那个阶段已经可以写一些稍微复杂的脚本、Chrome 插件之类的了。 后来 GitHub 出了 Copilot。很多情况下它的 Tab 补全准确率非常高，函数级别的功能基本上定义好输入输出，一路 Tab 就行。但此时还是需要你对相关框架和语法有基本的了解。 再后来 Cursor 出来了，体验有一个跃升。在 IDE 里面它能调用更多工具，拥有更多项目上下文和日志信息。此时完成一个中小型项目已经有非常大的效率提升了。 然后就是去年大概三四月份，Claude Code 的口碑慢慢起来了。最开始我对这种 CLI 工具（命令行工具，没有图形界面，纯文字交互）还是有些心理门槛的，觉得不如 IDE 直观。但用了以后就真的回不去了。慢慢地 IDE 就只剩一个功能——查看项目结构，选择重要文件，复制相对路径提供给 Claude Code 来构建它的上下文。其他功能都没太多意义了。因为 Claude Code 自己能做的越来越多，每当它需要人类介入的时候，你总会去想：凭什么这个事情要让人类来做？ 严格意义上讲，过去一年我应该没有写过一行代码，但 GitHub 的提交次数却越来越密。基本流程就是：有想法 → 跟 Gemini 做 Deep Research 调研可行性 → 找参考项目和文档 → 精选上下文 → 跟 Claude Code 开聊 → 不断描述需求和问题 → 迭代。 ...

过去一年多，我用 AI 给自己写了不少工具。从一开始只是想解决某个具体的小问题，到后来不知不觉搭出了一套还算完整的信息处理体系。 今天分享的内容在当下会有一些价值。不过这个价值更多是在于思路上，具体的代码其实没有那么重要。按当前 Coding Agent 的发展速度，恐怕过几个月，当前的这些代码就一文不值了。 下面我按层次来介绍。先讲我造的那些工具，再讲支撑它们运行的基础设施，最后聊几点这一年折腾下来的想法。 全景概览 图 1：信息流主线（采集 → 处理 → 存储 → 回顾） 图 2：基础组件与硬件（谁跑在哪，谁调用谁） 这套体系不是一次性设计出来的，是过去一年多时间里根据实际需求一点点迭代出来的。简单来说，信息的流向大概是这样的： 采集 → 过滤筛选 → 转录/理解 → 存储管理 → 回顾分析 每一层都有对应的工具在支撑。下面逐个介绍。 处理系统 AI Information Processor —— 统一的信息处理中枢 每天要面对大量的文章、图片、音频、视频，信息过载严重，人工筛选完全不现实。最初是从范冰老师那里学到的思路——把所有文本内容走一条统一的 Pipeline，用 AI 打分过滤。 我在这个基础上做了两点迭代：一是把处理范围从纯文本扩展到所有内容形式——图片、音频、视频都先转换成文字（虽然现在很多模型都有多模态的能力，但不论从成本还是效果上看，文字都是最优选择），然后走同一条管线；二是增加了事件聚类去重。具体来说，管线做两件事： 第一是打分过滤。按一定的规则给内容打分，分数不够的直接剔除。系统会用 AI 对内容做结构化分析——分类、评分、简单摘要、提取水下信息——然后根据评分阈值过滤。此部分 AI 工作流会以 API 的形式暴露给其他工具使用（比如长文本的主动剪藏）。 第二是事件聚类去重。对所有内容做 Embedding 向量嵌入（用的 text-embedding-3-small，非常便宜），计算相关性，剔除针对同一个主题、不同信息源的重复内容。这里有一套三级通知降噪机制：相似度低于 0.85 的视为全新事件，完整推送；0.85 到 0.97 之间的视为增量更新，只推送新增信息；超过 0.97 且实体高度重合的，直接静默。一个事件簇如果连续 7 天没有更新，会自动归档。 热点的信息，多个信息源会同时报道，所以此时会做一个去重来提取增量信息。 信息采集方面，系统对接了多种 RSS 源： ...