我怎么用 AI 编程 2026.08

陈成·约 4 分钟阅读

2026年8月26日8月26日

文章目录

每隔一段时间写一篇这个主题，这次隔了两个月。这两个月的变化可以归成一个词：并发。打磨 design 从串行问 5 遍变成并发问 n 个 agent，review 从跑一轮变成并行跑 n 个模型，项目从盯一个变成 Herdr 里管一排。

工具

我的主工具是 Qoder CLI 和 Claude Code。这两个 Agent 大部分能力都是对齐的，所以切换起来毫不费力，用不同的模型时切不同的工具即可。

与之前不同的一点是，最近会用主 Agent 来指挥其他 Agent 一起干活，比如用 Codex、Agy、Grok Build 做对抗性 Review。不同模型和 Agent 各有人设，Grok 限制少道德感低可以拿来逆向和翻译书，Codex + sol 5.6 fast 最稳，Agy + Flash 拿来兜底。

研发流程

我会在不同场景用不同的研发方式。

我的研发全流程由这些节点组成，Brainstorm > Save Design > Improve Design > Impl > Review。然后每个节点原子化，来适应不同的研发场景。

感觉正式点的 workflow 有两种，侧重于 design 和侧重于 review。这两种都能写出比较高质量的代码。我个人是倾向于前者，花 90% 的时间把 design 打磨好，然后花 10% 的时间 Impl，能减少不必要的返工。同时我的 commit 会附上 design，存于仓库或以 link 的方式附在 PR 里，方便 reviewer 了解细节和每个决策点。

一种是前面 design 好后面省力，一种是前面简单然后加 review 。

和很多人的 workflow 有个不同的点在于我有个「Improve Design」的节点。之前是通过问 n（up to 5）遍「any suggestion to improve this design」来实现，用了半年多。最近感觉实在太慢，改进了下，通过一次并发问 n 个 agent 这个问题的方式来实现，整体效率高了不少。

至于具体用什么样的 workflow？会比较灵活，感觉判断的维度比较多，比如我会分场景、功能大小、功能的重要程度、以及自己对其的熟悉程度等。

比如对于 vibe 的项目或者很小的功能，我会简单分析后，直接要求 impl。

比如在 Qoder CLI 研发里，我对于大部分需求都是这样，先讨论清楚需求，确保大的方向和思路没问题，然后要求 save design & improve & impl。因为流程里本身就有机器人 review 和人为 review 的环节了，所以一般不自己跑 review。

然后其中涉及核心改动或自己拿不准的改动，会跑 1-n 轮的 review，每轮 review 都会并行跑 n 个不同的 agent 和模型。

编排

前面在讲怎么研发好一个需求，编排讲的是怎么研发好一批需求或者整个项目。

上半年我自研了一个方案叫 Helm。其中一个功能是基于 issue 管理去做研发，用着很舒服，一天能干 70 - 100 个 PR。然后后面工作重心调整，研发工作不重，每天需要并行做研发的事偏少，反而需要关注不少研发外的工作。Helm 也就荒废了。

最近开始用 Herdr，用他的 workspace 管理不同的项目。越用越觉得这类基于 hook 实现的 agent 管理工具好用，内置 Terminal 保留了原工具 100% 的功能（想起上半年做 Helm 和 Neovate Desktop，为了对齐 Claude Code 的能力，在 UI 层费了老大劲了）。

同时我本地和远程机器上有 n 个 loop。他们基于 skill 做定时任务，跑在 QoderWake 上。我倾向「重 Skill」，所以本地建了 n 个 skill，感觉每天都在建新的和完善老的。其中 Qoder CLI 相关的有 17 个，涉及竞品、反馈、数据、回顾、写作等。他们能给我源源不断的需求来源，所以每天都感觉很忙。。Agent 干的活越来越多，我反而越来越忙。现在我一天的开始不是打开编辑器，而是看机器人昨晚干了什么。9 点竞品日报先到，9 点半用户反馈分类完毕，其中 3 条已经变成 issue 排进队列…

昨晚开始陆续在研究 Robobun，bun 仓库的机器人。基于 github 的 workflow，昨天提了个 issue 感觉他们处理地很顺畅，虽然很多团队都有做类似的，但他们的 pr merge 率还是很高的。下午开始尝试做个复刻，基于 Github/Gitlab 做 issue 处理、自动 pr/mr、自动响应 review、自动处理 mention、自发任务流做治理等。