AI 做完了，不等于真的完成了

我最近用 Codex 做项目，有一个感受越来越明显：

AI 很多时候不是没做，而是做了，但没做到位。

如果它完全没干活，你很好判断。

真正麻烦的是，它确实动手了，改了一部分，然后很自信地告诉你：

“已经完成。”

但你打开结果一看，发现还得重新检查、重新指出问题、重新让它返工。

几轮下来你会发现，真正消耗时间的，不是让 AI 执行，而是反复确认：

它到底有没有达到我要的标准。

这其实就是最近很多人在讲的 Loop Engineering 要解决的问题。

我更愿意把它翻译成中文：循环工程。

说白了，它不是让 AI 回答一次就结束，而是让 AI 在一套规则里自己循环：

执行、检查、返工，再检查，直到达标，或者触发停止条件。

为什么现在会出现循环工程？

因为 AI 的用法变了。

以前我们更多是让 AI 回答问题。

比如解释一个概念、写一段文案、起几个标题。

这种任务，一次回答可能就够了。

但现在不一样了。

我们开始让 AI 改代码、改项目、处理字幕、生成动画、跑自动化流程。

这些都不是简单回答。

这些是交付任务。

只要是交付任务，就会出现一个核心问题：

它做完了，到底算不算完成？

如果这个问题没有定义清楚，AI 就很容易自己定义完成。

而一旦 AI 自己定义完成，它大概率会用一句“已经优化完成”来结束任务。

但你真正想要的，可能根本不是它做出来的那个结果。

这个判断不是我一个人的感受

这个方向并不是我自己拍脑袋想出来的。

最近开发者圈有两个例子，刚好都指向同一件事。

第一个是 Peter Steinberger。

他是 OpenAI 的工程师，也是 OpenClaw 项目的创建者。前段时间他发过一句很直接的话，大意是：

你不应该再只是给 coding agent 写提示词，而是应该设计那些能提示 agent 的循环。

这句话听起来有点绕。

翻译成人话就是：

以前是你一句一句推着 AI 干活。

现在是你先设计一个循环，让 AI 根据目标、反馈和检查结果，自己往前推进。

第二个是 Boris Cherny。

他是 Claude Code 的创建者，也是 Anthropic 里负责 Claude Code 的核心人物。Boris 在公开分享里也提到过类似的工作方式：

他不再手动一条条给 Claude 写提示词，而是运行一些能让 Claude 自动安排任务的循环。

他的工作，变成了编写这些循环机制。

这两个人说的其实是同一件事：

未来真正重要的，不只是怎么写提示词，而是怎么设计让 AI 自己推进任务的工作循环。

这也是为什么我觉得 Loop Engineering，翻译成中文叫”循环工程”，这个词值得普通人理解。

它不是为了造一个新概念。

它是在提醒我们：

AI Agent 的使用方式，正在从”我一句一句告诉它做什么”，变成”我先定义目标、验收和返工规则，然后让系统自己跑起来”。

当然，普通用户不需要一上来就理解什么 Subagent、Worktree、MCP。

那些都是更偏工程化的东西。

我们先理解最核心的一点就够了：

AI 时代，技术的尽头很可能是管理。

你不只是负责下命令。

你还要负责定义目标、制定验收标准、设置返工规则。

这就是循环工程真正有价值的地方。

循环工程的核心，不是“循环”

很多人听到 Loop，很容易理解成：

让 AI 一直跑。

但这其实不准确。

一个好的 Loop，不是无限循环。

它必须有边界，有检查，有收口。

我理解循环工程的核心能力，主要有两个。

第一，目标定义和管理。

你不能只说：

“帮我优化一下。”

这句话太模糊了。

AI 不知道什么叫优化，也不知道优化到什么程度，更不知道哪些地方不能动。

你要告诉它：

这次到底要完成什么。

优先级是什么。

哪些东西不能改。

什么结果不能接受。

第二，结果检查和收口规则。

也就是 AI 做完以后，怎么判断它有没有达标。

如果没达标，根据什么继续修？

如果达标，什么时候停止？

如果连续几轮都没修好，什么时候必须停下来，让人来判断？

所以循环工程不是让 AI 一直跑。

而是：

定义目标，设定验收规范；不通过就继续返工，通过就收口，超出能力范围就停下来汇报。

一个很简单的对比

你给 AI 一个目标：

帮我把这个项目优化一下。

这句话看起来很正常。

但对 AI 来说，它太自由了。

它可能改一点代码，觉得差不多了，就停了。

也可能一直改来改去，把项目改得面目全非。

因为它不知道到底什么时候算完成。

如果换成循环工程的说法，目标应该变成：

只修改和当前问题相关的文件。

修改后项目必须能正常运行。

检查命令不能报错。

原有功能不能被破坏。

如果检查失败，说明失败原因，并继续定向修复。

最多循环 4 轮。

如果仍然失败，停止并汇报阻塞点。

你看，区别就在这里。

前者是一个愿望。

后者是一个可以执行、可以检查、可以收口的任务。

这才是 AI 真正能稳定交付的前提。

我自己的例子：用 Codex 做 Remotion 动效

我最近感受最明显的，是用 Codex 做 Remotion 动效。

我现在做 C哥OPC 这个账号，会在视频里加一些 VFX、动效卡片和全屏讲解动画。

一开始我给 Codex 的需求也很自然：

帮我做得更有科技感一点，偏黑客帝国风。

这句话听起来没问题。

但真正做出来，经常会很离谱。

它可能会做出一张很廉价的发光卡片。

信息堆得很满，像 PPT。

线条、框、文字挤在一起。

有时候还会挡住人物，或者压到字幕。

明明我想要的是克制、高级、系统感，它却理解成了：

多加点光效。

多画几个框。

多放几条线。

更麻烦的是，它还会很自信地告诉我：

“整体已经更符合科技风。”

这时候问题就很清楚了。

不是 Codex 没执行。

它确实执行了。

但它没有理解：

在我的项目里，什么叫合格的 Remotion 动效。

比如我的项目里，动效不是随便加几个发光边框就行。

它至少要满足这些要求：

不能遮挡人物；
不能遮挡主字幕；
不能单字换行；
不能把信息挤成一团；
不能做成廉价 PPT 卡片；
不能为了科技感乱堆光效；
必须符合黑客矩阵风，但要克制；
画面要有安全区；
进入、停留、退出节奏要清楚；
稳定画面必须能一眼看懂。

这些标准如果不提前写清楚，AI 就只能按自己的感觉发挥。

而 AI 对“高级感”“科技感”“黑客帝国风”的理解，很多时候并不稳定。

它会把审美问题，当成装饰问题。

它会把系统感，做成数据大屏。

它会把强调信息，做成一堆卡片。

所以后来我不再直接让 Codex “优化动效”。

我会先让它把我的需求，翻译成一份可以执行、可以检查、可以返工的任务单。

所以我做了一个 /loop skill

我最近做的 /loop skill，就是循环工程的一个小版本。

它不是直接帮我做任务。

它先做一件事：

把我随口说的一句话，翻译成 Codex 能执行、能检查、能返工的任务单。

比如我输入：

/loop 帮我重做这组 Remotion 动效卡片，整体要有黑客帝国风，但不要廉价，不要挡人物，不要像 PPT。

它不会马上乱改。

它会先生成一份类似这样的清单：

目标：
重做当前 Remotion 动效卡片，让它符合黑客矩阵风，服务口播表达，而不是单纯堆装饰。

任务类型：
Remotion / VFX 视觉任务。

硬约束：
- 不遮挡人物
- 不遮挡主字幕
- 不做廉价发光卡片
- 不做 PPT 风排版
- 禁止单字换行
- 信息不能挤成一团
- 光效必须克制
- 不大范围重构无关组件

验收标准：
P0：项目能正常运行，检查和渲染不报错。
P1：动效主体清晰，人物和字幕安全，稳定画面可读。
P2：风格符合黑客矩阵风，有系统感，但不过度装饰。

执行 Loop：
实现 → 抽帧检查 → 失败归因 → 定向修复 → 再检查。

停止条件：
P0 / P1 通过才算完成；最多循环 4 轮。
如果仍然无法判断视觉是否达标，标记 NEEDS_HUMAN_REVIEW。

这张清单看起来不复杂。

但它解决了一个关键问题：

不再让 AI 自己定义完成。

以前我说“做得更科技一点”，Codex 会按自己的理解去发挥。

现在它必须先回答：

什么叫科技感？

哪些效果不能出现？

怎么判断画面是否合格？

如果不合格，下一轮修哪里？

这就是循环工程真正有价值的地方。

它不是让提示词变得更长。

而是把“目标、标准、检查、返工”变成一套可重复使用的工作机制。

以后我不需要每次都重新说：

不要遮挡人物。

不要单字换行。

不要做成 PPT。

检查不通过就继续修。

最多循环几轮。

这些都可以放进 Skill 里。

我只需要说我的目标。

Skill 负责把目标翻译成 Codex 能执行的闭环任务。

普通人怎么开始用循环工程？

你不一定一上来就做 Codex Skill。

可以先用一个更简单的方法：

以后给 AI 一个中长任务之前，先让它把任务整理成 Loop。

你可以直接用这个提示词：

你是我的 AI 任务 Loop 设计器。

我会给你一个自然语言目标，请你不要直接执行，而是先把它整理成一份可执行的闭环任务单。

请按下面结构输出：

1. 目标：我要完成什么
2. 上下文：这个任务发生在什么项目或场景里
3. 硬约束：哪些东西不能改，哪些错误不能出现
4. 验收标准：什么情况才算完成
5. 检查方式：完成后应该怎么检查
6. 失败处理：如果没达到标准，应该怎么返工
7. 停止条件：什么时候可以结束，什么时候必须停下来汇报

我的目标是：

【把你的需求写在这里】

这个提示词不复杂。

但它能让你从“让 AI 回答”，往“让 AI 交付”迈一步。

以前你给 AI 一个模糊目标。

现在你先让 AI 把目标整理成任务单。

以前你只看结果顺不顺眼。

现在你让 AI 先按标准自查。

以前你每次都重新说一堆要求。

以后高频要求可以慢慢沉淀成模板、Skill 或项目规范。

这就是普通人也能用的循环工程。

真正重要的不是提示词，而是目标和验收

我现在越来越觉得，AI 时代很多人的误区是：

以为高手和普通人的差距，是谁的提示词更高级。

但真正做项目之后你会发现，不完全是。

提示词只是入口。

标准才是控制权。

你没有标准，AI 就会给你一个看起来很努力的结果。

你有标准，AI 才会进入执行、检查、返工、再检查的状态。

这也是我现在做 C哥OPC 这个账号时，一直在验证的东西。

我不是在收集零散 AI 技巧。

我更关心的是：

一个普通人，能不能把 AI 变成自己的长期工作系统。

今天这个 /loop skill，只是其中一个小模块。

它解决的不是“怎么让 AI 回答得更好”。

它解决的是：

怎么让 AI 做事更可控。

以前我们用 AI，更多是在问问题。

以后真正重要的，是让 AI 交付结果。

只要是交付，就必须有目标、验收、返工和停止条件。