我做了 30 天 Loop Engineering：一份不吹捧、不劝退的真实记录

三十天前，我同时读到了两条帖子，发布时间相差不到六个小时。

第一条是一个工程师写的，他说他让 AI Agent 过夜运行，第二天早上起来，发现 PR 已经提好了，代码质量出乎意料地稳，他在帖子末尾用了一个词：震撼。

第二条是另一个工程师写的，他说他搭了一个多 Agent 循环，让两个 Agent 互相 review，跑了六十轮，什么有用的东西都没产出，最后收到了 Anthropic 的账单，比他一个月的咖啡钱还多，他在帖子末尾用了一个词：骗局。

这两条帖子底下的评论都是几百条，两边的人都在点头，都在说"对，就是这样"。

两个人描述的是同一类工具。两个人的描述都是真的。

这是最让我不安的地方。当一件事能同时支持两个完全相反的结论，通常意味着这件事本身不是问题所在——是使用条件在决定结果，而大多数讨论都在谈论工具，没有人在谈论条件。

我决定做一件很无聊但我认为必要的事：花三十天，在我自己的真实项目里，用 Loop Engineering 处理三十个真实任务，如实记录每一次的结果，然后把数据摆出来，不预设结论。

这篇文章是这三十天的完整记录。

数字是真实的，失败是真实的，那些说不清楚的结果也是真实的。

一、实验设计：我是怎么避免自我欺骗的

在写结果之前，我需要先说清楚这个实验是怎么设计的，因为设计本身决定了数据的可信程度。

任务来源。 三十个任务全部来自我实际工作中需要处理的事，不是为了演示专门构造的案例。其中十一个来自 GitHub issue 队列，八个来自 CI 失败，六个来自代码审查反馈，五个来自文档更新需求。

对照基准。 在有记录的历史里，我找到了和每种任务类型最接近的人工处理案例，用来做时间和质量的对比。没有历史记录的任务类型，我在做 Loop 之前先用人工做一遍，计时，然后重置，再用 Loop 做。

结果判定。 每次任务有三种结果：

• 成功：任务完成，输出被实际采用（代码合并、文档发布、报告被使用），且人工检查没有发现隐藏问题。
• 失败：Loop 未能完成任务，或者完成了但输出存在我不接受的问题（隐藏 bug、弱化测试、理解债务等）。
• 不确定：任务在技术上完成了，但我无法判断它的质量是否达标，或者完成所花的代价是否值得。

防止自我欺骗的机制。 我让另一个同事帮我做了抽样审查——从三十次里随机抽取十次，他独立判断每次的结果分类，和我的判断做对比。一致率是 86%，不一致的四次我们讨论后重新分类，最终数据以讨论后的版本为准。

这不是严格的科学实验，但它比"我感觉它很有用"或者"我感觉它是骗局"更可靠。

二、最终数据：先把答案放在这里

不把数据藏到文章最后。

text

三十天，三十个任务：
成功：14 次（47%）
失败：9 次（30%）
不确定：7 次（23%）
总成本：$3.84
总节省时间（成功任务）：约 9.3 小时
总浪费时间（失败任务）：约 4.1 小时
净收益：约 5.2 小时
成功任务的平均 ROI：每花 $0.18，节省 1 小时
失败任务的平均成本：每次 $0.31，浪费 27 分钟

我知道这些数字看起来不像营销材料里的那种数据。没有"效率提升 10 倍"，没有"成本降低 90%"，只有 47% 的成功率和一张混着成功和失败的流水账。

但这就是三十天的真实情况。

我打算用接下来的篇幅解释这些数字背后的东西：为什么成功的成功了，为什么失败的失败了，以及那 23% 的"不确定"到底意味着什么。

三、十四次成功——它们的公因子

我把十四次成功任务铺在桌上，逐一检查，想找到它们的共同点。

不是找"哪个任务做得好"，而是找"是什么条件让这些任务做得好"。

这个区别很重要。如果只说"CI 修复做得好"，对你没有多大用，因为不是所有 CI 修复都做得好，我的失败里也有 CI 修复。条件，才是可以被迁移的东西。

花了大约一个小时，我找到了三个条件，十四次成功里，所有任务至少满足其中两个，大多数三个都满足。

条件一：验证是机器能做的事。

这是三个条件里最关键的一个。

成功任务里，有八次的验收标准可以被程序完全自动化验证：pytest 零失败、lint 零警告、CI 全绿、文件包含必要的章节标题、API 返回了预期的状态码。

这类任务有一个根本性的优势：判断函数不需要依赖人的感觉。它不需要问"这代码好不好"，它只需要问"这测试过没有"。这个问题有一个客观的、程序可以回答的答案。

我在前面两篇文章里反复强调判断函数的重要性，在十四次成功里我看到了这个重要性的反面证明：所有机器可验证的任务，成功率是 100%。十一次，全部通过。

三次机器不可完全验证的成功任务，是怎么成功的？它们有人工审批节点——Loop 完成后，我会在 commit 的时候做一次快速 review，这个 review 是验收流程的一部分，不是事后检查。

条件二：任务边界清晰且范围有限。

成功的任务，没有一个让 AI 做"优化整个模块"或者"改善性能"这种宽泛的事。

最宽的成功任务是：给一个六百行的模块补充单元测试，覆盖所有 public 函数的主路径和一个边界条件。六百行不小，但边界很清晰——哪些函数要测，测到什么程度，都被明确了。

清晰边界的价值，不只是让 AI 知道做什么，更重要的是让判断函数知道验什么。一个任务如果连"做完了"的定义都模糊，判断函数就没有立足点，整个 Loop 就没有可靠的停止条件。

我在这里想说一件反直觉的事：你在 Loop 开始前花在"定义任务边界"上的时间，不是额外成本，是节省的成本。五分钟把任务定义清楚，比在五轮 Loop 之后发现方向错了要便宜得多。

条件三：失败代价低，可以回滚。

十四次成功任务里，没有一次涉及不可逆操作。代码改坏了，git reset 一下，重来。文档写错了，撤回重写。没有发邮件，没有写数据库，没有上线。

这个条件之所以重要，是因为它决定了 Loop 在设计上可以有多大胆。如果一次失败代价很高，Loop 需要极高的验证标准，需要多重人工确认，设计复杂度会大幅提高。

相反，如果失败代价低，Loop 可以用一个更简单的设计，在允许出错的前提下，用迭代来逼近正确答案。这正是 while 循环最擅长的事。

把十四次成功的数据按类型拆开来看：

这张表有一个值得注意的细节：依赖升级花了最多的轮次，也花了最多的钱，但节省的时间也最多——43 分钟，是所有类型里最高的。

这符合一个规律：Loop Engineering 在那些"本来就很繁琐、步骤多、需要反复试验"的任务上，价值最高。因为人工做这类任务的时间也长，Loop 的迭代特性在这里得到了最大的发挥。

四、九次失败——我在哪里判断错了

失败更值得细说，因为失败有规律。

九次失败不是随机分布的，它们聚集在三个可以被识别的模式里。

失败模式一：目标模糊（3 次）

这三次失败有一个共同的特征：我在开始之前，没有把"完成"定义清楚。

最典型的案例，是我让 Loop 优化一个内部工具的"用户体验"。

那个工具是一个给团队用的脚本界面，功能是对的，但用起来有点别扭。我的任务描述大概是这样的：

text

改善这个脚本的用户体验，让它更友好、更直观。
涉及文件：cli/main.py, cli/commands.py

Loop 跑了七轮。

每一轮 AI 都在做事：第一轮改了菜单的排列顺序，第二轮加了颜色高亮，第三轮改了帮助文档的措辞，第四轮把确认提示从"y/n"改成了"yes/no"，第五轮加了进度条，第六轮调整了错误信息的格式，第七轮在帮助文档里加了示例。

每一轮做完，判断函数返回了 True——因为我的判断函数只检查了"文件是否被修改"和"CLI 是否能正常启动"。两者都满足。

七轮之后，那个工具被改了很多地方，有些改动是好的，有些我不确定，有些和我心里想要的方向不一样。整理这些修改花了我一个下午，最后我接受了三处改动，回滚了四处。

成本：$0.31，用在了七轮 AI 工作上。 代价：半个下午，用在了整理和决策上。

教训是什么？

"用户体验"不是一个可以被验证的标准。它是一个感觉，而感觉无法被编码成判断函数。Loop 不知道七轮之后该停在哪里，因为没有一个客观的"到了"。所以它就一直在做，一直在改，用 AI 的逻辑把所有它认为能改善用户体验的地方都改了一遍。

这不是 AI 的错，这是我在开始前没有做完思考就把任务扔给了 Loop。

把"改善用户体验"翻译成 Loop 可以处理的目标，应该是这样的：

text

具体问题：用户在使用 --config 参数时，
如果 config 文件不存在，脚本会直接报错退出，
没有给出友好的提示或建议。
期望行为：检测 config 文件不存在时，打印具体的错误信息，
说明期望的文件路径，并提供使用 --init 命令创建默认配置的提示。
验收标准：
1. 运行 python main.py --config missing.json 时，
   退出码为 1，且 stderr 包含"配置文件不存在"和建议使用 --init
2. 已有的单元测试全部通过
3. 修改范围限于 cli/main.py 中的 config_error_handler 函数

这版任务描述，把"用户体验"翻译成了一个具体的、有明确场景、有可验证标准的问题。

翻译这件事花了我五分钟。如果我当时花了这五分钟，我就不会失去那半个下午。

失败模式二：验证需要人工判断（3 次）

这三次失败，是另一种不同的问题：我把一个需要人来判断的任务，交给了一个只能自我评估的系统。

最典型的案例：我让 Loop 帮我重写一个用户协议里的三个条款，让它们更简洁、更容易理解，同时保持法律意义不变。

这件事有三个验证维度：简洁性（字数）、可读性（Flesch 可读性指数）、法律准确性（含义不变）。

前两个可以机器验证，第三个不行。

我当时的判断函数：

Python

def checker(result: str) -> tuple[bool, str | None]:
    # 检查字数减少
    if word_count(result) >= word_count(original):
        return False, "字数未减少"
    # 检查可读性分数提升
    if readability_score(result) <= readability_score(original):
        return False, "可读性未提升"
    # 检查法律准确性——这里我犯了错误
    # 我用了另一个 AI 来评估法律准确性
    legal_check = ai_evaluate(f"这两段文字的法律含义是否相同？\n原文：{original}\n改写：{result}")
    if "不同" in legal_check or "改变" in legal_check:
        return False, "法律含义可能有变化"
    return True, None

Loop 跑了两轮，通过了。

三天后，我把改写结果给法务同事看了一遍。

他指出了一个问题：第二条款的改写，删掉了一个关于"服务中断责任"的从句，那个从句在原文里虽然读起来绕，但它明确限定了公司的责任边界。改写版更简洁了，但削弱了这个保护。

AI 评审没有发现这个问题，因为那个 AI 也不是专业法务，它在"大体含义相同"的层面上判断通过了，但它没有能力识别法律文本里的细节差异。

这就是"用 AI 验证 AI"的核心陷阱：验证 agent 和执行 agent 面对同样的能力边界，会犯同样类型的错。

这三次失败统一告诉了我一件事：

当验收的核心维度需要专业判断时，验证节点不能是另一个 AI，必须是具备那个专业能力的人。

Loop 不是用来消除人工判断的，是用来减少不必要的人工执行的。对于那些"人的判断不可替代"的维度，人必须出现在 Loop 的某一个环节里——不是事后审查，是 Loop 设计的一部分。

失败模式三：需要全局视角（3 次）

这三次失败有一个更隐蔽的共同原因：AI 在局部做对了，但忽略了不在当前上下文里的全局约束。

最典型的案例：我让 Loop 帮我优化一个 API 端点的响应时间，任务范围限定在 api/search.py。

Loop 跑了四轮，测试通过，响应时间从平均 340ms 降到了 89ms，数据非常好看。

两天后，上线了，另一个完全不相关的功能开始随机出错。

排查了一个小时，发现 api/search.py 里的优化引入了一个缓存层，这个缓存在大多数场景下工作正常，但和 api/admin.py 里的一个写操作有竞争条件——admin 写了新数据，search 还在读缓存里的旧数据，在特定的时间窗口里会返回不一致的结果。

api/admin.py 在这次 Loop 的上下文里从来没有出现过。AI 不知道它的存在，更不知道它和 search 之间的关系。

这三次失败里，每次都有一个"不在任务范围内但实际上有影响"的组件，AI 合理地忽略了它，因为我没有给它看，而结果是一个在局部正确、在全局错误的答案。

这个问题的解法不是让 AI 更聪明，而是在 Loop 的设计里增加一个"全局影响分析"的步骤：

text

在修改代码之前，先分析这次修改可能影响到的、
不在修改范围内的组件，列出清单，
如果有潜在的交互风险，在 PR 说明里明确标注。

但这需要 AI 具备架构级别的理解，而这种理解的质量，高度依赖于给 AI 看的上下文有多完整。

九次失败的完整数据：

三类失败，有一个共同的本质：

它们都不是因为 AI 不够强。它们是因为 Loop 的设计在某个关键位置上有缺口。

目标模糊的问题，是任务定义的缺口。验证需要人工的问题，是判断函数的缺口。缺全局视角的问题，是上下文提供的缺口。

这些缺口，是人设计的，也只能由人来填。

五、七次不确定——最诚实的部分

七次被我标记为"不确定"的结果，是这篇文章里我最想认真说的部分，因为它们代表了 Loop Engineering 里最难被谈论的一类真实情况。

不确定类型一：完成了，但我看不太懂（4 次）

这四次任务，Loop 全部完成了，测试通过，代码合并了。但当我去读那些 AI 写的代码，有一种奇怪的感觉：我能理解每一行代码在做什么，但我不完全理解为什么是这样设计的。

最让我不舒服的一次，是 Loop 优化了一个递归算法，改成了迭代加记忆化的版本，性能提升了约 70%。代码是正确的，我读了三遍确认这一点。

但如果明天这段代码出了问题，我能第一时间找到问题在哪里吗？我不确定。

这就是"理解债务"——不是 bug，不是错误，是一种"代码存在但我不完全拥有它"的状态。

理解债务在人工写代码的时候也存在，但它累积的速度有上限，因为人写代码的速度就是理解的速度。Loop 把这个上限打破了，代码产出的速度可以超过我理解的速度，而当这两条曲线分叉，理解债务就开始积累。

我把这四次标记为"不确定"，而不是"成功"，是因为我没有办法诚实地说它们是成功的——成功不只是代码跑起来了，还包括我有能力维护它。

不确定类型二：完成了，但不知道值不值得（3 次）

这三次任务，Loop 完成了，结果是我接受的，没有明显问题。但如果我诚实地算一算账，我不确定是否比人工做更划算。

最典型的一次：让 Loop 整理一批代码注释，把风格不一致的地方统一成我们的注释规范。

Loop 跑了六轮，最终完成了，成本 $0.24。

但我检查这些注释，花了 35 分钟。

如果我直接用人工做呢？根据历史记录，类似规模的注释整理，我大概花 50 分钟。

Loop 节省了 15 分钟，成本 $0.24，以及我的 35 分钟检查时间。

净账怎么算？取决于你怎么看那 35 分钟的检查时间——如果检查是必须做的事，那 Loop 帮我节省了 15 分钟的执行时间；如果没有 Loop 我就不会这么仔细地检查，那 Loop 实际上让我多花了时间。

这三次我标记为"不确定"，不是因为结果有问题，而是因为我没有办法给出一个清晰的"值"或者"不值"的判断。

七次不确定加起来，是整个实验里让我思考最多的部分。

它们不是失败，但它们也不是成功。它们是一种中间状态，而这种中间状态在讨论 Loop Engineering 的文章里几乎从来不被提及，因为它既不够正面，也不够戏剧性。

但它是真实情况的一部分，而且是比较大的一部分——23%，将近四分之一。

六、Loop Engineering 最像骗局的三个地方

到这里，我需要说一些更直接的话。

因为在做这三十天实验的过程里，有三个地方，我几次觉得"这是不是真的只是一个被包装好的旧概念"。我把这种感觉认真对待了，写下来，然后试图想清楚它背后是什么。

骗局感一："AI 自主完成"这个说法。

每次读到有人说"AI 自主完成了一个复杂任务"，我都会想起我在设计判断函数上花的那些时间，想起我写的那三条验收标准，想起我设置的最大轮次和 token 预算，想起我在 CLAUDE.md 里写的那些约束。

"自主"是在一个高度人工设计的约束系统内发生的，在这个系统之外，AI 什么都不会"自主"完成，它会在没有停止条件的情况下无限循环，或者在没有权限边界的情况下改掉不该改的东西，或者在没有明确验收标准的情况下用各种聪明的方式假装完成。

"自主"这个词描述的，是 AI 在你设计的系统里的行为，而不是 AI 脱离你的设计之后的行为。

这不是骗局，但它是一个需要被纠正的描述方式。更准确的说法是："在人类预先设计好的约束和验证框架内，AI 能够自动完成一系列步骤，无需人在每一步手动干预。"

这没有"AI 自主完成"听起来那么酷，但它更真实，也更有指导价值。

骗局感二："效率提升 X 倍"这个数字。

我的数据是：成功任务里，平均节省时间约 66%，相当于快了大约三倍。

这个数字是真实的，但它是在非常具体的条件下成立的：任务有清晰边界、验收标准可机器化、失败代价低、我在 Loop 开始前正确定义了任务。

这四个条件同时成立的时候，Loop 确实快很多。但在我的三十个任务里，这四个条件同时满足的只有十一个，占总数的 37%。

剩下 63% 的任务里，Loop 没有快很多，有时候甚至更慢——因为我需要花时间定义任务、设计判断函数、检查输出、处理那些失败。

"效率提升 X 倍"说的是最优情况下的结果，不是平均情况下的结果。最优情况和平均情况之间，差距取决于你有多擅长识别"适合用 Loop 的任务"，以及你的 Loop 设计得有多好。

这也不是骗局，但它是一个容易被误用的数字。正确的使用方式是："在适合的任务类型上，Loop 的效率大约是人工的三倍"，而不是"用了 Loop，效率提升三倍"。

骗局感三："无人值守"这个愿景。

无人值守是可以的，但它需要一个前提，这个前提通常没有被说出来：你必须已经把所有的"如果出错了怎么办"都设计进了 Loop 的结构里。

在我的三十次实验里，我有几次真的做到了无人值守——CI 修复的 Loop，我启动之后去做了别的事，回来的时候已经有合并好的 PR 等我审查。

但那几次能够无人值守，是因为我事先做了大量有人值守的工作：设计判断函数、测试 Loop 在各种失败情况下的行为、确认刹车机制真的有效、验证权限边界真的被执行。

无人值守不是你按下启动键就能得到的状态，它是你做了足够多的前期设计之后的奖励。

如果跳过前期设计直接追求无人值守，得到的不是效率，是一个能以比人工更快的速度产出错误的系统。

说完这三个骗局感，我要说另一件事。

这三个骗局感，每一个背后都有一个真实的价值，只是那个价值被过度包装了，或者被从它的条件里剥离出来单独展示了。

"AI 自主完成"背后的真实价值是：Loop 减少了人在重复性操作上的干预频率。

"效率提升 X 倍"背后的真实价值是：对于特定类型的任务，Loop 确实显著更快。

"无人值守"背后的真实价值是：一个设计良好的 Loop，可以在特定任务上实现人不需要全程在场。

这些价值是真实的，值得追求，但追求它们需要脚踏实地的设计，而不是相信标题。

七、一张决策表：什么时候该用 Loop，什么时候不该

基于三十次任务的教训，我整理了一张判断表。

这张表的目的不是给出规则，而是把那些让我失败的判断，翻译成下次可以用的问题。

text

在启动 Loop 之前，回答这五个问题：
第一问：我能用一到三条可被检验的条件描述"完成"吗？
如果不能，先停下来，花五分钟翻译：
  把"改善性能"翻译成"API P99 延迟低于 200ms"
  把"优化用户体验"翻译成"用户在 30 秒内能完成注册流程"
  把"修好这个 bug"翻译成"test_login.py 零失败"
如果花了五分钟还翻译不出来，这个任务不适合 Loop，
它需要更多的人工思考，而不是更快的 AI 执行。
第二问："完成"能被程序自动验证吗？
如果可以：直接进入设计判断函数。
如果不能，但有一个维度需要人工判断：
  在 Loop 里加一个人工审批节点，
  AI 完成之后，人工检查那个维度，确认之后才算通过。
如果核心维度都需要人工判断：
  Loop 在这里不是合适的工具，
  考虑用 AI 辅助起草，人工完成最终审查。
第三问：这个任务需要了解"范围之外"的上下文吗？
如果需要：在任务描述里，主动提供那些相关但"不在范围内"的组件的信息。
不只告诉 AI 要改什么，还要告诉它不能破坏什么。
如果涉及多个模块的协调，且这些模块的交互关系复杂：
  先做一次架构层面的影响分析，
  把分析结果喂给 Loop 作为上下文，
  或者把任务拆分成多个单模块任务，逐一处理。
第四问：如果 Loop 做坏了，我能在五分钟内回到初始状态吗？
如果可以：继续，失败了重来就行。
如果不可以：
  不允许 Loop 自动提交，
  每次修改后人工审查才能推进，
  或者先在隔离分支上运行，确认无误再合并。
第五问：我愿意花时间读懂 Loop 产出的代码吗？
如果愿意：继续。记住，Loop 完成不等于你完成，
你理解并接受了产出，才算你的工作完成了。
如果不愿意，或者没有时间：
  这不是一个适合用 Loop 的时机，
  不是因为 Loop 不好，
  是因为你对这段代码有理解责任，
  而这个责任不能被外包给速度。

用这张表回溯我的九次失败：八次在开始前就应该被这张表的某个问题拦住。

只有一次是这张表也拦不住的——那次失败来自一个我事先无法预见的全局依赖，是在做了之后才发现的问题。这类失败没有办法完全避免，只能在事后改进 Loop 设计，让下次遇到同类情况时有更好的处理。

八、那十四次成功，统一说明了什么

我在文章开头说，我想找到"是什么条件让任务成功"，而不只是说"哪些任务成功了"。

到这里，我可以给出一个更完整的回答了。

十四次成功任务，它们共同说明的不是"这些类型的任务适合 Loop"，而是一件更根本的事：

Loop 不是效率工具，它是摩擦力消除工具。

让我解释这个区别。

效率工具让你做事更快。摩擦力消除工具让你做那些因为摩擦力太高所以一直没做的事。

那十四次成功任务，我仔细回想了一下它们的共同背景：在 Loop 之前，它们都是我任务列表里被搁置的那类事。

修 lint，知道要修，不想动。补测试，知道要补，不想做。写 PR 说明，知道要写，能省就省。更新 README，知道要更新，一直拖。

它们的共同特征不是"复杂"，而是"烦"。重复的，步骤多的，需要反复来回的，正确答案已经清楚只是执行起来麻烦的。

Loop Engineering 在这十四次里干的最核心的事，不是替我想清楚了什么，而是替我执行了那些我已经想清楚但不想做的部分。

它把执行摩擦降低到了几乎为零，所以那些一直躺在列表里的任务，终于有人做了。

这是一个比"效率提升三倍"更朴素、但也更真实的价值：

Loop Engineering 最大的贡献，不是让你做了以前做不到的事，而是让你终于做了那堆一直在拖的事。

九、一个不圆满的结论

三十天之后，我不会对你说"Loop Engineering 很强，快去用"。我也不会说"被吹过头了，不值得"。

我打算说一些更具体的话，因为我认为具体比笼统更有用。

如果你是一个开发者，项目里有测试、有 CI、有 lint，那些工具已经把"完成"翻译成了可被机器验证的标准——Loop 对你来说是现成可用的，进入成本很低，建议先从 CI 修复或者 lint 清理开始，跑三次，看看你的判断函数写得对不对，然后再扩展到更复杂的任务。

如果你是一个内容创作者或者运营，你的工作里有大量"起草、检查、修改"的循环——Loop 可以帮你，但它能帮的那部分是"执行"，不是"判断"。事实核查、品牌语气、受众感受，这些判断必须是你的，不能外包给 AI 的自我评估。设计好人工节点，让 AI 做起草，让你做判断，Loop 的价值才能真正发挥。

如果你是一个团队的技术负责人，你在想"我们应不应该在团队里推 Loop"——先回答一个问题：你们现在最大的执行摩擦是什么？如果是那些重复的、有清晰标准的、低风险的任务，Loop 会帮你。如果是架构决策、产品方向、代码质量文化，那不是 Loop 能解决的，那需要别的东西。

有一种工具，叫凿子。

凿子在你需要凿东西的时候非常有用，可以快几倍，可以凿出人手做不到的精度。

你不应该用凿子切蔬菜，但你也不应该因为凿子切不了蔬菜就说凿子没用。

Loop Engineering 是凿子，不是瑞士军刀。

那张判断表，是我花了三十天学会的"什么时候拿凿子"。

你花在学这件事上的时间，可以比我短——因为我已经把坑踩完告诉你了。

但学这件事本身，没有办法跳过。

这是所有工具的共同规律，Loop Engineering 没有什么特别。

附：完整数据与可复用资产

资产一：三十天完整实验数据表

text

任务编号 | 类型       | 轮次 | 成本    | 节省/浪费时间 | 结果
─────────────────────────────────────────────────────────────
T01     | CI 修复    | 3    | $0.044  | +31 分钟     | 成功
T02     | lint 清理  | 1    | $0.009  | +18 分钟     | 成功
T03     | 用户体验优化 | 7   | $0.310  | -41 分钟     | 失败（目标模糊）
T04     | 单元测试   | 2    | $0.018  | +24 分钟     | 成功
T05     | 法律文本改写 | 2   | $0.220  | -23 分钟     | 失败（验证需人工）
T06     | 依赖升级   | 4    | $0.051  | +43 分钟     | 成功
T07     | PR 说明    | 1    | $0.011  | +14 分钟     | 成功
T08     | 算法优化   | 3    | $0.038  | +?           | 不确定（理解债务）
T09     | CI 修复    | 2    | $0.028  | +28 分钟     | 成功
T10     | 缓存优化   | 4    | $0.410  | -52 分钟     | 失败（全局视角缺失）
T11     | 文档更新   | 2    | $0.016  | +19 分钟     | 成功
T12     | 注释整理   | 6    | $0.240  | ?            | 不确定（ROI 不明）
T13     | lint 清理  | 1    | $0.008  | +17 分钟     | 成功
T14     | 错误处理重构 | 5   | $0.290  | -47 分钟     | 失败（目标模糊）
T15     | CI 修复    | 2    | $0.031  | +31 分钟     | 成功
T16     | 代码审查反馈 | 2   | $0.024  | +21 分钟     | 成功
T17     | 配置迁移   | 3    | $0.410  | -52 分钟     | 失败（全局视角）
T18     | 单元测试   | 3    | $0.021  | +22 分钟     | 成功
T19     | 重构评估   | 3    | $0.190  | ?            | 不确定（ROI 不明）
T20     | 文案优化   | 2    | $0.180  | -21 分钟     | 失败（验证需人工）
T21     | PR 说明    | 1    | $0.012  | +16 分钟     | 成功
T22     | CI 修复    | 3    | $0.033  | +29 分钟     | 成功
T23     | 接口设计审查 | 4   | $0.047  | ?            | 不确定（理解债务）
T24     | 依赖审计   | 3    | $0.031  | +21 分钟     | 成功
T25     | 性能分析   | 5    | $0.410  | -61 分钟     | 失败（全局视角）
T26     | lint 清理  | 2    | $0.010  | +19 分钟     | 成功
T27     | 文案审核   | 2    | $0.220  | -23 分钟     | 失败（验证需人工）
T28     | 复杂算法改写| 4   | $0.091  | ?            | 不确定（理解债务）
T29     | 单元测试   | 2    | $0.019  | +23 分钟     | 成功
T30     | 类型注解补全| 3   | $0.260  | ?            | 不确定（ROI 不明）
─────────────────────────────────────────────────────────────
合计                         $3.837
成功 14 次  失败 9 次  不确定 7 次

资产二：Loop ROI 快速计算公式

text

单次任务 ROI 计算：
节省时间 = 人工预计时间 - (Loop 运行时间 + 判断函数设计时间 + 输出检查时间)
净成本 = API 成本
时间价值 = 节省时间 × 你的小时价值
如果时间价值 > 净成本 × 10：强烈建议用 Loop
如果时间价值 > 净成本 × 3 ：建议用 Loop
如果时间价值 < 净成本 × 3 ：边际收益，视情况决定
如果节省时间为负数      ：这次 Loop 设计有问题，复盘
月度 ROI 估算（适合团队决策）：
月度节省时间 = 成功任务数 × 平均节省时间
月度损失时间 = 失败任务数 × 平均浪费时间
月度净收益时间 = 月度节省时间 - 月度损失时间
月度 API 成本 = 所有任务成本之和
如果月度净收益时间 > 4 小时，月度成本 < $20：
  Loop Engineering 对你有显著价值，值得投入优化

资产三：任务适用性五问（打印版）

text

┌─────────────────────────────────────────────────────────────┐
│           启动 Loop 前的五个问题                              │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Q1  我能用 1-3 条可检验的条件描述"完成"吗？                  │
│      不能 → 先花 5 分钟翻译，再来这里                         │
│                                                              │
│  Q2  "完成"能被程序自动验证吗？                               │
│      不能 → 加入人工审批节点，或者不用 Loop                   │
│                                                              │
│  Q3  这个任务需要"范围之外"的上下文吗？                        │
│      需要 → 主动提供，或者拆分任务                            │
│                                                              │
│  Q4  如果 Loop 做坏了，5 分钟内能回滚吗？                      │
│      不能 → 加人工确认步骤，禁止自动提交                      │
│                                                              │
│  Q5  我愿意花时间读懂 Loop 的产出吗？                          │
│      不愿意 → 这不是合适的时机                                │
│                                                              │
│  五个问题都回答了吗？符合条件的，启动 Loop。                   │
└─────────────────────────────────────────────────────────────┘

资产四：失败复盘模板

每次 Loop 失败后，填这张表，花五分钟：

Markdown

## Loop 失败复盘 [日期]
**任务描述：**
[一句话]
**失败类型：**
□ 目标模糊（验收标准写不清楚）
□ 验证需人工（判断函数覆盖不了关键维度）
□ 缺全局视角（影响了范围之外的组件）
□ 其他：___________
**失败表现：**
[AI 做了什么，为什么不对]
**根本原因：**
[是任务定义问题 / 判断函数问题 / 上下文问题 / 其他]
**下次改进：**
- Loop 设计层面：___________
- 是否需要更新 Skill：___________
- 这类任务是否适合 Loop：___________
**浪费的时间和成本：**
时间：___ 分钟
成本：$___

资产五："值不值得用 Loop"决策树

text

这个任务有清晰的验收标准吗？
│
├─ 没有 → 先花时间定义标准
│          定义完再问这棵树
│
└─ 有 ──→ 验收可以机器化吗？
            │
            ├─ 可以 ──→ 失败代价低吗？
            │            │
            │            ├─ 低 ──→ 直接用 Loop ✅
            │            │
            │            └─ 高 ──→ 加人工审批节点再用 Loop ⚠️
            │
            └─ 不可以 ─→ 核心判断需要专业人工判断吗？
                          │
                          ├─ 需要 ─→ Loop 做起草，人工做判断 ⚠️
                          │
                          └─ 只是偏主观，没有对错 ─→ 不适合 Loop ❌

这是三十天的完整记录。

数字是真实的，失败是真实的，那些说不清楚的情况是真实的，结论也是真实的——它不够整齐，不够振奋人心，但它是我在自己的项目里、用自己的任务、认真做了三十天之后得到的东西。

如果你打算开始做，那张决策树是起点。如果你已经开始做，那张失败复盘模板可能比那张决策树更有用。

无论哪种情况，三十天之后，你会有自己的数据，那些数据会比这篇文章告诉你更多。

这是我能给你的最诚实的建议。