秋田散人(@akitabtc):补充一点前置条件，对于庞大且高频迭代、高度机器托管的项目，单元测试是不能少的，我的仓库已经三万多例测试。提交 PR 之前，pre-commit 脚本至少要 hook git push 行为（如果是小项目就 hook git commit 行为）。测试这一轮都没通过是不可能进入 Review agent 的，浪费 token。另外有几点小经验就是： 1. 远端 CI 要尽量采纳本地测试的回执，非 git baseline 变了不允许重跑，测试是很烧 CPU 也很耗时的，Github actions 的云端计费是很贵的，无非也就是看计算量和时间占用率。除非完全托管在云端的项目，大部分 CI 资源消耗还是应该放在本地。 2. 一定要想方设法在本地测试过程中用 CPU 置换时间，能并发执行、并发布署到本地 CI server 就最好。因为 coding agent 的等待耗时本来就是有成本的，容易让你吃更多上下文中断成本。更重要的是影响 coding agent 并行开发的效率。 3. 对于 Docker 镜像的构建加速其实也有很多盲区或者窍门，比如 pip/npm/cargo 版本没缓存到 docker layer 之类的重复构建，偶尔漏掉一层其实对于 CI 的耗时也是有影响的，最好让 agent 自检一遍，让 CI 的成本优化到极致，对于一个每天发几百个 PR 的项目来说完全是有必要的。

2026.09.01 10:40

补充一点前置条件，对于庞大且高频迭代、高度机器托管的项目，单元测试是不能少的，我的仓库已经三万多例测试。提交 PR 之前，pre-commit 脚本至少要 hook git push 行为（如果是小项目就 hook git commit 行为）。测试这一轮都没通过是不可能进入 Review agent 的，浪费 token。另外有几点小经验就是： 1. 远端 CI 要尽量采纳本地测试的回执，非 git baseline 变了不允许重跑，测试是很烧 CPU 也很耗时的，Github actions 的云端计费是很贵的，无非也就是看计算量和时间占用率。除非完全托管在云端的项目，大部分 CI 资源消耗还是应该放在本地。 2. 一定要想方设法在本地测试过程中用 CPU 置换时间，能并发执行、并发布署到本地 CI server 就最好。因为 coding agent 的等待耗时本来就是有成本的，容易让你吃更多上下文中断成本。更重要的是影响 coding agent 并行开发的效率。 3. 对于 Docker 镜像的构建加速其实也有很多盲区或者窍门，比如 pip/npm/cargo 版本没缓存到 docker layer 之类的重复构建，偶尔漏掉一层其实对于 CI 的耗时也是有影响的，最好让 agent 自检一遍，让 CI 的成本优化到极致，对于一个每天发几百个 PR 的项目来说完全是有必要的。

秋田散人@akitabtc

2026.08.31 04:35

btw，我现在每月可能几千个 PR 合并，软件 CI workflow 是高度自动化和高度依赖 github 框架的，特别是 actions 以及 PR 的评论区。整体分三阶段，由三个 agent 来跨期分段处理： 1. Review agent（PR 合并前）：在合并前，3 个不互相蒸馏的模型厂家一一审计，一一留档，没有达成共识的 PR 不允许合并。 2. Release agent（PR 刚合并）: 灰度测试，小额接生产流量，留下验收目标和验收方式（固定字段） 3. Verify agent（生产流量验证期）: 看到验收目标和字段出现在日志中 marker 以后，确认并且操作 gray 翻全量；有明确 error 和适配问题同样要留档 PR 评论区，可以驱动下一个关联 PR 项。 4. Graduate agent（全量翻完在生产跑 15-30 天以后）：每一个灰度 feature tag 都是 candidate，看哪些 feature 已经验收无误，后完整毕业，翻 default value。 ——以确保一个 feature PR 能在软件生命周期早期被准确监督复核，哪怕他是 agent 的一个随机并且未充分验证的 idea，在这套体系下也几乎不可能犯大错误。而这几阶段中间可能隔了几个小时甚至几天几周，完全不是 continuous 的，也完全不可能被同一个短寿的 agent 接管，那么一定需要有一个 “论坛式的记忆”——PR 评论区就是最好的跨期开发对话记忆载体。

커뮤니티로 전달