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

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

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

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

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

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

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

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

为了让这套系统真正“像个团队”，我给每个 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 也会越来越多地替人类把软件写出来。想到这里，我反而有点兴奋：这条路才刚刚开始。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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