GeruzoniAnsasu

要知道这两代人大多数都是独生子，根本就不知道如何与兄弟姐妹家庭相处。包括我，也不懂。在我观念里这种大家族的资源模式就是老大哺育全家，等弟妹成长起来各自独立了，各自下一代再互相照顾。

我看了很多多子家庭的倾诉，感觉都过成了好几个独生子女在一个屋檐下居住互相争抢资源的模式，这跟我认知中的上一辈的家族完全不一样。

巧了

一周前我发现刷了 openwrt 的 ax3000t 内网 moonlight 表现极差，UDP 性能跑不到 10M ，遂重刷 MTK 私有固件的版本。
然后这一折腾就是一周过去了，抱着顺手修 bug 的想法一路查上去，发现上游实现各种 bug ，还发现光猫的硬件适配也有 bug………………😂

这是它现在的性能

对的对的，你的代码跑不了正是 bug 之神阻碍了你的认知

你都单干了，你自己为什么不在华强北？

> 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！


何意味，我写了你们会有推广费用？

我就说一个两个人协作都很痛苦的问题：

我们的 skill 里约束了 AI 写代码必须留下 execution plan 和需求变更记录文档。

这个文档的 文 件 名 有 版 本 号 。




想要让 AI 能顺利遵循 spec-driven 范式有一个对于软件工程来说不可能的前提 —— 你的项目必须高度解耦到每个维护者（每个 agent ）都只需要负责自己的一小部分 code space 。这样多个 agent 在品名滚版本号的时候才不会撞到一起，或者进入 理解对方修复-追加自己兼容层-理解对方的兼容层 的恶性循环。

@yuankui

第一命令行不利于 diff ，AI 动不动同时改 5 个 10 个文件，命令行的 review 效率太低了，除非你说 AI master 不需要人类 review.
第二 GUI 的交互方式天然并行，你可以在看到 AI 工作过程的同时看其它代码或者 preview staging 、编辑配置、写文档，命令行基本要切窗口，很不跟手
第三需要古法手工修复的时候，复制粘贴要方便得多……


而且我很喜欢 vscode+copilot 的交互，最重要的一点是它同时暂存了 1) git 工作区改动 2) agent 在本次 session 的改动 3) agent 在本轮 prompt 后做出的改动，回滚的层级很灵活而且很直观，可以单行、单文件、单会话控制保留部分

对于工作流已经很固定的稳定项目可能感知不到…… 我还见过有人直接丢给在线 codex 跑，自己直接摸鱼等回来黑盒测试的

首先排除所有命令行工具。因为你必然会（ almost always ）需要 IDE 内建的查错、LSP 、git 插件、mcp 管理、slash command 、attach 到上下文等等实用机制。所以本质上还是在比 IDE 。

而 IDE ，现在 vscode 集成了天下所有 agent ，应该没什么争议悬念。哪怕 IDE 自身功能不太够强 —— 反正 Visual Studio 有 MCP 插件，能把自己的能力暴露给 agent, jetbrains 则是已经好久都没打开过了。


然后，在 IDE 都一样的控制变量下，claude 的逻辑能力一骑绝尘，gpt/codex 的废话能力独步武林，但这是另外的事了。