上了AI的贼船

我最近把主力 harness 换成了 Oh My Pi。它不把模型绑死：同一套工作流里，我可以自己选模型，不必跟着“Codex 就等于 GPT、Claude Code 就等于 Opus”这类默认搭配走。模型和调用环境各自更新，分开选更自在。

顺带，我也在收拾自己的习惯。只在某个 harness 里能跑的 hook 和 skill，当时很省事，换环境时就成了包袱。以后我会优先写通用的命令和脚本，不再塞进特定 harness。下次换工具，也不用背着一串迁移债。

裸 pi 很素，OMP 正好加上一层：开箱就好使，也方便二次开发。和当初搞 Prowl 一样，我喜欢这种可以慢慢按自己习惯改的东西。

五月的时候，我的 fork Prowl 上线了统管全部 agent 会话的视图，结果一两天后 Claude Code 就发布了自己的 agent view。撞车归撞车，倒是印证了一个判断：并行跑多个 agent 已经是日常，而"怎么管住它们"正在变成一个独立赛道。

同一个问题，现在至少有三种解法。Claude Code 的 agent view 走内置路线，按个左箭头就能在会话间切换，但只管自家；herdr 走 tmux 路线，一个 Rust 单二进制在终端里开工作区、标签页、窗格，agent 在后台继续跑，你随时 attach 回去；Prowl 则是 GUI，把 Claude Code、Codex 这些不同的 agent 放进同一个窗口，配上脚本按钮和 diff view。

用下来我的体感是：单个 agent 之间的能力差距在缩小，真正的瓶颈挪到了人这一侧——谁在等我输入、谁跑完了、谁卡死了，这些状态一多，靠终端标签页和脑内记忆就管不过来了。驾驶舱解决的不是 agent 的问题，是我自己注意力调度的问题。至于选 TUI 还是 GUI，倒不用站队，跟选编辑器一样，顺手就是正义。

今天想让 agent 抓一下我自己的 X 时间线，顺手把手边的轻量方案挨个试了一遍。fxtwitter 的 API 只给 profile 元数据，拿不到推文；Jina Reader 对 x.com 整个域名处于封禁状态，因为之前有人拿它对着某个大 V 的主页薅到触发了风控。最后还是 agent-browser 加一个完整的 Chromium 一次通过，代价是先下载一百多 MB 的浏览器内核。

这件事有意思的地方在于，专为 agent 造的轻量无头浏览器最近确实越来越多。收藏夹里躺着的 Obscura 用 Rust 重写，内存 30 MB，号称比 Chrome 轻十倍还内置反检测；用 Zig 从零写起的 Lightpanda 主打毫秒级启动。方向我完全认同，agent 上网是高频动作，为一个几秒钟的任务背一整个 Chrome 确实奢侈。

但今天的实践给了我一个更冷静的判断：对 x.com 这类硬目标，"像一个真的浏览器"本身就是核心能力，而反爬系统检测的恰恰是那些被"轻"掉的部分。轻量浏览器的上限取决于 Web API 的覆盖度，把这些补齐的工程量和重新做一个浏览器没有本质区别。所以我目前的用法是分层：静态页面用 curl 或 reader 类服务，一般的动态页面可以给轻量方案一个机会，遇到登录墙和反爬就老老实实上完整内核。减肥是理想，兜底靠体重。

“兼听则明，偏信则暗。” 最近做了一个叫 argue 的小工具，让多个 AI agent 围绕同一个问题进行一场结构化的辩论。起因是注意到，同一份技术方案或同一个 PR 丢给不同的模型时，它们关心的点和切入的角度常常完全不同 —— Claude 偏向看出设计层面的潜在风险，Codex 盯实现细节，Gemini 又常常从另一个维度发现盲点。只问一个模型，往往需要更精细的提示词调试，不仅产生额外的心智负担，剩下的那些角度也容易被忽略。

argue 做的事情，就是把这种"角度的差异"显式地放上桌：让你配置的 agent（Claude / Codex / Gemini / OpenCode 等任意组合）先独立发表意见，再互相挑刺、合并立场、投票表决，最后输出一份带证据、带分歧、带信心分数的结论。我最近基本都用它做关键的技术方案评审、代码审查和重要决策。决策还是自己做，argue 只是把不同模型各自的视角和分歧一次摆全。

这并不是要追求"AI 民主投票后取平均"，相反，最有价值的部分往往是那些没能被合并的分歧 —— 它们是某个模型独自看到、其他模型也无法反驳的角度。MIT licensed，欢迎来玩、欢迎 Star。

我在本地工作流里基本已经从 Git 切到 jj，连续用了几个月，体验一直很稳。最明显的变化，是它那套版本管理心智更贴近我现在的开发节奏。

Git 依然是非常成熟的协作系统，过去二十年已经证明了它的价值。只是今天的开发现场变了：回看、重排、整理历史这些动作更频繁，jj 在这部分更顺手，思路也更连贯。

我把这段时间的实践和判断写成了完整文章：jj for Agent Era。如果你也在重新评估版本管理，也许会有参考价值。

AI 让软件开发的稀缺点变了：通用功能越来越容易获得，真正稀缺的是“贴合自己工作流的版本”。

过去二次开发难，不是因为不会写代码，而是读懂旧代码、判断改动边界、控制风险太贵。很多“我其实想改”的需求，最后都被成本劝退。现在不同了：Fork 一个成熟开源项目，再用 AI 辅助理解和改造，门槛明显下降，效率却明显上升。

这也解释了为什么“贡献上游”不再是唯一答案。很多需求本来就偏私有：个人习惯、团队流程、交互偏好，甚至和原作者理念冲突。它们不适合做公共默认值，但非常适合留在自己的分支里持续迭代。

我的 fork Prowl 就是这样：底子沿用原项目，只做高频体验改造，比如脚本按钮、快捷键、diff view。单点改动不大，但组合起来，工具会从“能用”变成“顺手”。

我越来越相信，开源底座 + AI 定制会成为下一阶段非常主流的开发方式。软件的核心问题，正在从“做不做得出来”，转向“是否足够像你自己”。

我最近渐渐不再把 OpenClaw 当成「一个助手」来用了——它更像是一套可以养成的“团队系统”。在同一台机器上放了好几只猫娘，分工明确，然后让她们彼此协作。

为了让这套系统真正“像个团队”，我给每个 agent 配了独立的 GitHub 身份（比如 onevclaw），让她以自己的名义写代码、提交、评审，甚至写日记（claw.onev.cat）。大部分协作性质的提交则通过 Co-authored-by: 留在历史里进行追溯，也算向她们的贡献致敬。

通信也进行了一些研究：agent 之间配置了会话通道，参考 Claude 的 Agent Team，使用文件系统和轮询来确保猫娘团队的交互模型简单有效。最有意思的环节可能是互评和“吐槽大会”：一只猫娘负责实现，另外的猫娘们进行审查和挑刺；不同模型、不同性格往往会带来不同的盲区和偏好，但只要把她们放进同一个流程里，就更容易得出更稳定和全面的结论。

这更像一个长期的实验：多 agent 协作可能会是下一个阶段的主要形态，而指挥多个 agent 协作的能力自然也会越发重要。这套机制最后会演化成什么样子，我也说不准，但整个过程确实挺有意思。

在此之前，我写项目时脑子里总有一个明确的受众：用户是人、读者是人、开发者也是人。功能怎么设计、文档怎么写、发布怎么做，默认都是围绕“人如何使用”来组织的。

最近我做了一个小项目：TransCrab。它是我第一次认真地把“第一用户”从人切换成 agent——准确说，是 OpenClaw。

人要做的事情被压缩到极少：告诉 OpenClaw 这里有个项目、我想要怎样的效果、我同意你把它装起来并跑起来。剩下从安装、配置、到把工作流真正跑通的那些繁琐步骤，基本都可以交给它完成。更离谱（也更好玩）的是：TransCrab 这个项目本身，从头到尾都是我在聊天 app 里让 OpenClaw “写”的。

这种体验对我来说非常新奇：我第一次清晰地感觉到，我不是在做一个“给人用的工具”，而是在做一个“给 agent 用的能力”。它读文档、跑脚本、做判断、自己维护，甚至还能在冷启动的情况下把整个部署流程推到上线——而我更多是在旁边看着、确认、修正方向。

顺着这个体验往前想一步，就会发现一件更有意思的事：也许不久以后，“写项目”这件事本身会越来越像一种协作——人类把意图与边界讲清楚，agent 把执行与维护扛起来；甚至 agent 还能为别的 agent 准备能力包，让它们自己协商、自己对接，最后共同把一个系统搭出来并长期运行。人类更像是提出愿望的人，而不是亲手拧每一颗螺丝的人。

TransCrab 只是一次小小的探索，但它让我第一次真正看见一个未来：软件会越来越多地写给 agent，而 agent 也会越来越多地替人类把软件写出来。想到这里，我反而有点兴奋：这条路才刚刚开始。

在写 Chroma（一个 Swift 终端语法高亮库）和 ca（cat 的高亮替代品）时，最值得记录的并不是功能本身，而是性能优化被 AI 放大后的价值：在持续 benchmark 驱动的迭代下，tokenizer 与 renderer 的性能被推到原来的十倍左右。

这次实践的核心方式很朴素：把 benchmark 当作一等公民，让 AI 读代码、找热点、给方案；每次只做小改动并跑基准，用结果反馈下一轮。优化不再是几次试错后就疲惫的体力活，而是“提出假设—验证—修正”的科学实验。AI 的价值不是某个天才微优化，而是把试错成本压到足够低，让我们愿意把优化做完。

两个典型优化也说明了这一点：把 tokenizer/renderer 从 batch 流水线改成 streaming，系统性降低内存和拷贝成本；为 ASCII 主导的输入分布加 fast-path，非 ASCII 时回退到安全路径。它们都不算“灵感一击”，却需要大量细致改动与验证，而这恰恰是 AI 擅长扛住的部分。

因此，“过早优化是万恶之源”的经验在 AI 时代需要重新理解。过去我们避免过早优化，是因为试错昂贵、脑力与时间难以投入；但在 AI 开发中，这些成本被显著降低，许多优化可以提前布局、尽早验证。我也越来越相信：提早优化并不违背工程理性，反而更高效。

最近在反思 MCP (Model Context Protocol) 的使用方式。虽然协议本身很强大，但在本地跑一堆 server 感觉还是太重了，另外对 agent 的 context window 来说也是一个负担。我开始尝试回归本源，尽量直接使用 CLI 工具来让 AI 调用。

比如用 Jira CLI 来处理 JIRA 上的任务，或者用 AXe 来操作模拟器。背后的理由其实很简单：不需要跑 server，干净的 binary，管理方便语义清晰。将 CLI 直接放在 skill 中，只要 CLI 自身的帮助编写得足够优秀，你甚至不需要额外说明就能让 agent 成为超级高手。

现在有了 Vibe Coding 的加持，如果缺什么工具，自己手搓一个 CLI 也是分分钟的事情。而对于那些暂时还没有办法替代而且你懒得去转 CLI 的 MCP，可以使用 MCPLI 作为一个中间层，把 MCP 转成命令行来用，体验也相当不错。

我有一个很奇怪的需求，需要把 Claude Code 的订阅想办法转成一个可以通用的 OpenAI API 端点，提供给本地的一些其他服务和 app 使用。请别问为什么会有这种需求，或者为什么不直接用现成的 API 和其他模型…合规啊限制啊这些事儿，说起来那都是泪。

总之，原本应该是从从容容游刃有余的事儿，现在只好匆匆忙忙连滚带爬地给 Claude 的 Agent SDK 套一层 Hono，做一些简单的转换，让 claude CLI 变身成了一个 Open AI 兼容的 API，提供给本机使用。看了一圈社区里好像也没有什么好用的类似方案，顺手开源出来方便大家有需要的使用，请注意风险提示不要违规。不过我估计应该没什么需求，毕竟并不是谁都能遇到这种奇葩局面的…

在又一次经历充给 Anthropic 的钱因为没用完到期被坑以后，我决定将所有的 API 使用方式从「向模型厂商充值」转向到「通过模型聚合平台」使用。之前我已在 OpenRouter 持有帐号并很轻量地用过，但是 OR 的模型太多太乱，供应商设置也较为复杂，稍不注意就可能流向非主流服务商，引发意料之外的问题。相比之下，ZenMux 的界面更简洁清晰，模型也经过明显筛选，供应商看起来只有官方。今后我应该会重点使用一段时间。

访问按钮指向我的推荐链接，新用户首充可额外获得 25% 余额，性价比不错，推荐给大家尝试。

Nix 是一个建立在“纯函数式”理念之上的包管理器，它会把依赖写得清清楚楚，让所有软件构建都可复现，也不会互相污染环境。更妙的是，用声明式配置就能把多台机器上的系统环境、开发工具、用户级软件全部同步，真正做到“写一次，到处一致”。

之前我一直用 Mackup 来同步配置，但在新系统里它被限制了不少，甚至出现了直接丢配置的情况。于是我开始重新评估使用 Nix 的优先级。只不过，Nix 的语法和上手成本确实不算友好，这也是我过去迟迟没完全迁移的主要原因。但现在情况变了：我可以直接用自然语言描述需求，让 AI 代写 nix 配置甚至整个 flake，学习成本几乎被清空。

结合 Nix 的确定性特性，未来要换设备、重装系统或者搬家环境，基本只剩下一个词：拷贝即完成。

我辗转用过不少笔记 app，但是想要找到一款本地优先，视觉效果优秀，而且深度集成 AI 的笔记应用实属不易。在又一次回到 Obsidian 之前，我用了大概两年的 Craft.do。虽然它们真的把 Mac Catalyst 做到了出神入化，但是在 AI 上的对应缓慢还是让我直接忍痛离开。AI 时代最好的笔记组织方式回到了 markdown 文件，直接操作文件让 Agent 能发挥最大的潜力。我在 Obsidian 上使用 Infio，这让我的笔记们有机联合起来，真正成为一个知识库。

其实直接使用 VS Code + 任意 Agent 也能达到类似效果，不过 Obsidian 具有更加完善的生态：包含笔记所需要的视觉样式和反向链接等。手机上的 Obsidian 要弱很多，因此在外的话，我转而使用 Termius 直接连回家里的 server，用命令行的 agent 操作笔记：这样也算省去了操心同步的烦恼。

对于以前那类重复枯燥，但是又需要一定人为参与的任务，使用AI来进行替代简直是最理想的使用案例。

Kingfisher 的版本发布往往牵涉到多个 PR 和 Issue，人工整理会漏掉细节；手动核对并将改动归功到相应贡献者也很繁琐；最后，要给每个版本取名有时候也够我苦恼一整天。有了这套流程，AI 会先帮我罗列 master 相对上一个 tag 的所有变动，然后自动解析 PR 描述，汇总出功能、修复与贡献者。这样我就可以把注意力放在校对和补充洞察上，而不必重新搜集信息。

为了提升准确率，我还会在对话里附上一两个示例输出，让 AI 仿照示例把新的条目填入 change_log。只要提示词里明确「不要改动 YAML 的键名」以及「每条目必须附带链接和贡献者」，AI 就能稳定产出符合 release 脚本要求的版本说明。另外，我也会让它给出版本号推导过程（比如为什么是次要版本还是补丁版本），这样在审查时可以快速验证语义化版本的判定依据。把这些策略组合在一起，原本繁琐的 release 准备变成了一次轻松的审阅流程。

作为一个每天埋头搬砖的技术从业者，我在经济和投资上缺乏系统学习，相关嗅觉也较迟钝。阅读经济类读物（博客、长文、评论等）时，常常难以抓住重点，也不易理解现象背后的本质。AI 的出现恰好弥补了我作为小白“无人可问”的尴尬。我最近订阅了 Stratechery 的文章，粗读后交给 LLM，然后进行十来分钟的讨论对话，深入研究文章及其背后的逻辑，受益良多。

多数 LLM 在文章总结和投资建议上表现不错，但在讨论环节，模型之间存在一些细微差异。Sonnet 容易被带偏，进入附和模式；ChatGPT 较为发散，常用反问把话题引向不太相关的方向；Gemini 专业性似乎强一些，但有时感觉却又带点情绪。综合来看，ChatGPT 在这类任务上更全面。用得越多越杂，就越能感到模型和人很相似：它们各有性格与特点，擅长的任务也不尽相同，挺有意思。

开发者的极限其实是输入速度！在 AI 时代，我终于可以真正随心所欲地使用语音输入来完成所有的任务了：通过 VoiceInk 或者其他类似工具，进行本地听写转译，然后按照所在的 app，把听写结果交给 AI，在不同场景下配合提示词进行二次处理（比如在 Codex 或 Claude Code 中使用「开发者语音指令处理」，在 Slack 中使用自动翻译把我的中文输入翻译成对方能够理解的文字等）。这些工作流非常简单，但极大提升了输入效率，让我真正跨过了多线程工作的最后一道阻碍。

二次处理的速度至关重要，当下以速度擅长的 Groq 似乎是不二选择。在模型方面，我偏好 Kimi-2。虽然 GPT OSS 的两个模型在生成 token 时的绝对速度更快，但很不幸由于它们是推理模型，在处理这种实时任务时反而效果不如 Kimi 这种非推理模型来得直接迅速。平常用量的话，Groq 的个人方案甚至可以完全白嫖，十分舒适。

自建的 n8n 实例真的能提升幸福感。我在家用服务器上部署了 n8n，每天早晨定时任务会自动获取当天和明天的天气，以及全家人的日程安排。接着，结合 AI 能力，自动生成穿衣建议和每日计划，并附上一句温馨的问候和简短的激励语，最后通过 Bark 发送给家人们 —— 让一天有个美好的开始。

没错，您看到的这个网站就是一个纯 vibe coding 的产物，我没有写任何一行代码。当前编程 agent 类工具在处理前端问题时确实是如臂使指了，Codex 的性价比在当今可以说是顶级，它从计划到实施几乎包揽了全部工作。

要说经验的话，经过几次“从零开始”的 vibe coding，我发现在实际开始着手前，就把需求聊清楚可能是成功的关键。就像这个项目的第一次提交那样，「基于计划文档」的新开发范式，或许是 AI 时代开启新项目时不二的选择（当然，这个计划文档本身也是 LLM 的产物）。