Loop engineering 把人挪到检查点

这和我最近用 Codex 的感受能接上。之前写那篇 goal 文章时，我更多关注的是“完成条件”这件事：目标是什么，边界在哪里，用什么验证，什么时候算完成。

大会以后再回头看，goal 只是 loop engineering 里很小但很关键的一块。它解决的是单次任务怎么不靠人反复提醒也能往前走。更大的问题是：哪些任务值得交给循环，哪些检查点必须留给人，哪些判断可以提前写进系统，哪些责任不能推给 AI。

我现在觉得最契合的场景有两个。

一个是性能优化。它天然有指标，最好还能自动复测。你告诉 agent：接口 P95 要降到多少，首屏要控制在多少毫秒，包体要降到多少 KB，回归测试不能挂。它每改一轮就跑一次 benchmark、profile 或压测，没达标就继续找瓶颈。这里人的价值不是每次看它改了哪一行，而是先给出可验收的指标，再在关键节点判断“这个优化有没有改变业务语义”。

另一个是 UI 重构。前提是要有明确设计稿，最好能做到 1:1 还原。没有设计稿时，人会不断被拉回“这个边距不对”“这个颜色不舒服”“这个交互不像”的琐碎判断里；有了设计稿，AI 的循环就可以围着截图、DOM、样式和视觉差异来收敛。人不必跟着每一次 CSS 调整跑，但要对最终界面负责。

这两个场景的共同点是，验收物不是一句“做得好一点”。性能优化有数字，UI 重构有设计稿。循环能跑起来，不是因为 AI 更听话，而是因为任务本身有可比较的目标。

Multica 像一块协作板

大会现场还碰到开源圈的人介绍项目，其中 Multica 挺有意思。我回来查了一下，它不是一个新的单体 coding agent，而是把 Claude Code、Codex、GitHub Copilot CLI、OpenCode、Gemini、Kimi、Cursor Agent 等工具接进同一个任务协作层。

它的 README 里把 agent 写成 teammate：可以被分配 issue，会汇报 blocker，会更新状态，也会出现在看板、评论和任务生命周期里。文档里更具体一点：agent 是 workspace 的一等成员，可以被 assign issue、在评论里发言、被 @ 提及；创建 agent 时可以选择背后的 AI coding tool，并配置 instructions、model、环境变量、CLI 参数、可见性和并发限制。

这就把“用哪个模型”从一次 prompt 里的临时选择，变成了团队协作里的角色配置。

它最有意思的地方，不是“多代理”这个词，而是可以给不同 agent 配不同身份。比如一个 agent 用便宜模型做重复修复，一个 agent 用更强模型做架构判断，一个 agent 只做 review，不改代码；再配合 Squad 这种机制，由 leader agent 根据 issue 内容把任务路由给合适成员。

我没有完整跑一遍 Multica，所以这里只能把它当作一个公开资料可核对的样本看。但这个设计方向和 loop engineering 是同一类问题：不是让一个 AI 把所有事干完，而是把任务、角色、模型、审核和状态流转放进同一个循环里。

如果公司真要落地 AI 写代码，这个差别很重要。

现在模型价格不一样，能力边界也不一样。所有任务都用最贵的闭源模型，成本不一定扛得住；所有任务都用便宜模型，返工和漏审又可能把成本搬到后面。更现实的做法是分层：低风险、重复、边界清楚的活交给便宜模型先跑；关键变更、架构取舍和最终审核，留给更强的模型或人。

闭源强模型用来做审核，我觉得是一个不错的位置。审核不只是“挑语法错误”，它要看需求有没有被改坏，边界有没有被越过，测试是不是只覆盖了表面，提交说明是不是掩盖了风险。这类任务对判断力要求更高，但调用频次未必像实现阶段那么大，成本账更容易接受。

人少参与，不等于人不负责

圆桌讨论里有个观点我很认同：代码是 AI 写的，但代码是人类提交的。

这句话听起来像责任提醒，其实也是流程设计原则。AI 可以写代码、改代码、跑测试、生成 PR 说明，甚至可以让另一个模型先审一轮。但最后把代码合进主干的人，不能说“这是 AI 写的，和我没关系”。

公司里要的不是谁在键盘上敲字符，而是谁对结果负责。你提交了，就表示你愿意为这次变更的业务语义、风险边界、测试证据和回滚预案负责。AI 参与得越深，这件事越不能含糊。

所以 loop engineering 不是把人彻底从流程里删掉。它更像是重新安排人的位置：

任务开始前，人写清目标、边界和验收条件。
循环运行时，系统和 agent 自己处理重复尝试、测试、修复和状态同步。
关键节点上，人看证据、看差异、看风险，而不是逐行追着 AI 的产出跑。
提交代码时，人承担结果责任，不能把 AI 当免责理由。

这也是我为什么会把 goal、性能指标、设计稿、Multica 这几个看似分散的东西连在一起。它们都在把人的判断提前、外显、结构化。人参与得少一点，但参与的位置更关键。

这件事如果做不好，就会变成另一种低效：AI 产出很多，人审不过来，最后团队靠“感觉上差不多”合代码；出了问题以后，又把锅甩给 AI。那不是工程化，只是把混乱换了个生产者。

真正值得追的循环，不是让 AI 一直写，而是让每一轮写作、修改、测试和审核都能回到同一张验收单上。人的工作从“盯着它写”变成“定义什么算好、检查证据够不够、为提交负责”。这可能才是 loop engineering 这个词让我一直想的地方。

参考资料

写作附记

原始提示词

$blog-writer 昨天参加 Minimax 线下开发者大会，有个东西一直没绕过去，loop engineering，近期在用 codex 代码开发，也喜欢用 goal，也写过关于 goal 的文章，发现两个场景，最契合，性能优化，直接给出我要求的性能指标、UI 重构，提供设计稿，要求 1:1 还原。回到开始说的 loop engineering，AI 时代的编程，由于 AI 的生产力远超人类，人类审核的速度，完全无法追平，AI 产出的速度，但是现在的 vibe coding，很多决策还是需要人类参与的，人的参与变多了以后，整个流程就不容易完全自动化。loop engineering 的理念，更多就是降低人类的参与程度。还碰到了开源圈的人来宣讲他们的项目，有一个项目比较有意思，Multica，你查下相关资料，简单的介绍下，除开他的设计理念，最有意思的地方在，不同给的模型，给不同的身份，能有效的利用各家的大模型，毕竟现在模型价格不一样，闭源模型来做审核是个不错的思路。关于 AI 代码在公司落地，圆桌讨论的时候，有个观点也是一致的，代码是 AI 写的，但是代码是人类提交的，你需要对你提交的代码负责，这表现的是你的责任心、你做事情的态度。你不能说这是AI写的，和你没关系。

写作思路摘要

保留 2026-06-13 参加 MiniMax 线下开发者大会这个现场触发点，没有把它扩写成大会报道。
把主线收束在“人的参与位置怎么变”，而不是逐条解释 loop engineering、goal、Multica 和公司责任。
Multica 部分只写公开资料能支撑的能力，并把“闭源模型做审核”明确放在作者判断里。
压掉了对具体模型价格、公司管理制度和代码审查流程的展开，避免文章从工作流观察跑成管理制度建议。