上了AI的贼船

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

最近我做了一个小项目：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 的产物）。