给 qodercli 加了「跨会话消息功能」 1\ 这是我来 qodercli 以来加的最重的功能，总耗时一天左右。 2\ 我有个 loop 会在 claude code 发新版时自动拉 changelog 和代码，分析每一项新功能的实现。8.7 深夜，针对 claude code 2.1.224，生成了十三份分析文档。其中一份有一千零一十一行，讲一个新功能，同一台机器上的两个会话可以互相发现、互相发消息。一个会话干完活，可以直接叫另一个会话接着干，不用人在两个终端之间复制粘贴。 3\ 8.8 早上闲着没事刷推，发现 claude code 在宣传这个功能，就留意了下，然后拿着分析文档让 agent 照着给 qodercli 也加一份。指令是「i want to impl to qodercli, full feature」，用我的 one-shot skill 实施。2 个小时后 mvp 完成了，47 个文件，5513 行，152 个新测试。发群里大家觉得还不错。 4\ 8.9 歇了一天，8.10 PD 催了，于是下午开始补细节。细节太多，补了 20 来个 commit 到晚上才补完。然后开始用 claude code 和 codex 等，用不同的模型做交叉 review。合计 40 多条 review 建议，然后慢慢 fix，直到 8.11 上午才最终完成。 5\ 8.11 上午推分支找同事 review，基本上没啥新增问题了，只处理了一个。同时让 agent 写了份 1722 行的测试手册给测试同学，46 个用例，功能细节还是很多的。 6\ 8.11 晚，随 v1.1.19 版上线。

AI Coding 时代，好的编程习惯仍然重要 最近做一个 Agent benchmark，发现不能简单地用开发者视角来评估一个编程任务对 AI 的复杂度。 比如一个重构任务：把一个几千行的大文件，按功能拆成十多个小模块。 这个任务对开发者来说其实不算难，主要工作就是移动代码、整理 imports、编译验证，新手也能搞定。 所以想着用一个简单的任务来做一下 benchmark，结果却出乎意料。 Claude Code 判断这个任务比较大，尝试拆了一部分，提了个 PR 写了 Future work 打算分步来。 我自己的 Agent 是“硬上”，往完整拆分的方向推进了更多，但代价也很明显：Token 消耗是 Claude 的几十倍，后面大量时间都花在反复读文件、修编译错误、再读文件、再修错误上。 这让我意识到，人觉得简单的任务，对 Agent 不一定简单。 对人来说，这类重构很多时候就是“把这一段挪过去”。但对 Agent 来说，它要先分批读大文件，记住哪些函数和哪些测试有关，再生成一堆跨文件修改，最后通过编译错误一点点补洞。看起来像机械活，实际变成了一个高 Token、高状态管理成本的任务。 前一段时间看到有人说，AI Coding 时代，拆分模块这些编程原则没那么重要了，反正人也不看代码。现在看，我不太同意。模块边界清楚、文件粒度合适、依赖关系简单，不只是方便人读，也是在帮 Agent 降低任务复杂度。 从另一个角度看，现在 Agent 的读文件和改文件工具，对这种重构也不太顺手。 Coding Agent 改文件，主要还是文本替换。比如 Claude Code 常见的是 old_string / new_string 模式：先给出一段旧文本，再替换成新文本。Codex 常用的是 apply_patch：生成一个类似 git diff 的 patch，表达把旧的内容替换成新的。它们都适合小范围修改，但如果要删除一大段旧代码，或者把一批函数挪到别的文件，模型往往还是要先把原始内容读进上下文，再生成一大段替换或 diff。 所以我后来给 Agent 一个提示，让它先用脚本、sed、perl 这类工具把大文件粗拆开，直接把旧内容删掉，写到新文件中，然后再逐个慢慢修，它的完成度确实高了许多。Agent 默认不会这样做，主要是因为系统提示词里会强烈要求 Agent 用内置工具修改文件，而不是命令行工具。 再往前想一步，Coding Agent 可能还需要更高级的编辑工具。不是只给它一个“替换文本”的接口，而是先通过 parser、LSP 或 compiler 建立代码结构，让 Agent 可以像 IDE 一样做重构：移动函数，删除 impl block，整理 imports。不知道是否有朋友做这方面的尝试。 总的来说，即便是 AI Coding 时代，好的编程习惯还是有价值的。尽量在早期通过 harness engineering，把好的编程习惯变成 Agent 的默认工作方式，比后来再重构的成本要小很多。