假设现在是半夜三点。

你正在睡觉，线上突然出现一个阻塞性 Bug。用户无法继续使用核心功能，客服开始反馈，监控报警也响了。过去这种情况很简单：工程师被叫醒，打开电脑，看日志，复现问题，定位代码，修改，测试，发版。

真正消耗人的，往往不是最后改的那几行代码，而是整个排查和验证过程。

最近做了一个 demo，就是模拟这个场景：线上出现阻塞性 Bug 后，不是立刻把工程师从床上叫起来，而是先让一个 AI 工程袋里进入工作流。

它会读取错误信息，查看日志，找到相关代码，提出修复方案，修改代码，运行测试。如果测试失败，它会继续看失败原因，再改，再跑。直到问题被修掉，或者它明确判断当前信息不足，需要人介入。

这个过程背后，其实就是一个很火的新概念：

Loop Engineer。

它不是单纯的 Prompt Engineer，也不是普通的 AI Coding Assistant。它更像是一种新的工程协作方式：把 AI 放进一个可执行、可验证、可持续迭代的工作循环里。

什么是 Loop Engineer

Loop Engineer 的核心，不是让 AI 一次性回答一个问题，而是让 AI 在一个循环里持续推进任务。

一个典型的 loop 大概长这样：

观察当前状态读取上下文提出下一步动作执行动作拿到反馈根据反馈继续调整产出可验证结果

以前我们用 AI 写代码，更多是「问一句，答一句」。

比如让 AI 帮你解释报错，帮你生成函数，帮你写一个组件。AI 给出答案以后，真正的验证和修正还是人来做。

Loop Engineer 的重点在后半段。

AI 不只是给建议，而是进入真实工程环境里。它可以读文件、改代码、跑命令、看日志、跑测试、提交结果。它不是一次性输出，而是在反馈里不断前进。

这也是「loop」这个词最关键的地方。

软件工程本来就不是一次写对。工程师平时做的事情，本质上就是循环：看现象，猜原因，改一点，跑一下，再看结果。AI 要真正参与工程，也必须进入这样的循环。

Loop Engineer 的核心结构

一个可用的 Loop Engineer，通常由几部分组成：

这张图里，最关键的是 Loop Contract 的位置。

它不是流程中的一个普通步骤，而是整个 loop 的约束层。它规定 AI 要做什么、能读什么、能改什么、怎么验证、什么时候停、最后交付什么。

下面拆开看每一部分。

Trigger：触发器

Loop 不能凭空开始，它需要一个启动信号。

这个启动信号可以是定时任务，也可以是 webhook，也可以是后台常驻进程。

比如：

每 30 分钟检查一次客服工单每天早上 9 点分析 SEO 数据监控系统发现线上异常后自动触发GitHub issue 被打上 bug 标签后启动修复流程用户反馈集中出现某个问题时生成任务

Trigger 决定了 loop 什么时候开始。

在我的 demo 里，触发器就是线上 Bug。系统收到错误日志和用户反馈后，自动启动一次修复 loop。

Context：上下文

AI 要做工程任务，必须能读取上下文。

上下文包括很多东西：

代码日志文档历史 issue用户反馈监控数据测试结果最近提交记录

没有上下文的 AI 只能猜。有上下文的 AI 才能定位问题。

比如线上 Bug 场景里，AI 至少需要看到：

错误日志用户反馈相关接口相关代码路径最近发布记录已有测试用例

这些信息决定了 AI 能不能从「看起来像错误」走到「找到真正原因」。

Tools：工具能力

Loop Engineer 必须能执行动作。

只会分析的 AI，更像顾问。能调用工具的 AI，才有机会变成工程袋里。

常见工具包括：

搜索代码读取文件修改文件运行测试启动服务查看 git diff创建分支生成 PR读取监控处理工单调用内部接口

工具不是越多越好，关键是和任务匹配，并且权限边界清楚。

比如修线上 Bug 的 loop，可以允许 AI 读取日志、修改相关模块、运行测试、生成 PR，但不一定允许它直接部署生产。

这样既能让 AI 自动推进，又不会让它越过关键边界。

Verify：验证机制

没有验证，就没有 loop。

验证决定 AI 的动作是不是有效。它可以是单元测试、集成测试、类型检查、lint，也可以是一个业务检查脚本。

比如：

修 Bug 后，对应测试必须通过改接口后，关键请求必须返回正确字段改页面后，截图不能出现空白和错位改数据处理逻辑后，样例输入输出必须一致生成 PR 后，必须包含原因、修改内容和风险说明

Verify 是 loop 的反馈来源。

AI 每次执行完动作，都要通过验证拿到结果。通过了，进入总结和交付；失败了，读取失败原因，继续下一轮分析和修正。

文件结构：AI 的工作台

Loop Engineer 要稳定运行，不能只靠一段 prompt。

Prompt 更像口头交代，适合一次性任务。Loop 要反复执行，就需要一个稳定的文件结构。

一个比较清晰的结构是这样：

loop-task/├── artifacts/│ ├── docs/│ ├── signals/│ ├── tasks/│ ├── contents/│ └── ...├── loop-contract.md└── LOGS.md

对应成结构图：

这套结构可以简单理解成三句话：

artifacts/ 是资料区loop-contract.md 是任务合同LOGS.md 是运行记录

artifacts：资料区

artifacts/ 放所有任务材料和中间产物。

它下面可以继续拆：

artifacts/├── docs/├── signals/├── tasks/├── contents/└── ...

docs/ 放背景资料，比如产品文档、接口说明、业务规则、历史决策。

signals/ 放外部信号，比如用户反馈、客服工单、监控报警、数据异常、增长机会。

tasks/ 放拆出来的任务，比如需要修复的 Bug、需要验证的假设、需要生成的实验。

contents/ 放产出内容，比如文章草稿、页面文案、PR 描述、分析报告。

如果是半夜修 Bug 的场景，signals/ 里面可以放线上报错和用户反馈，docs/ 里面放相关接口说明，tasks/ 里面放这次修复任务，contents/ 里面放最后的修复摘要和 PR 描述。

这相当于给 AI 一个文件化的上下文仓库。它每一轮都可以读取这些材料，而不是依赖聊天窗口里模糊的记忆。

loop-contract.md：任务合同

loop-contract.md 是整个 loop 的核心。

它不是资料，也不是日志，而是规则。

可以把它理解成一份任务合同。合同里写清楚：

Goal：这次 loop 要完成什么Inputs：AI 可以读取哪些信息Workflow：按什么流程推进Task：当前具体任务是什么Timeline：执行频率和时间节奏Permissions：允许做什么，不允许做什么Verification：怎样判断完成Stop Conditions：什么时候必须停下来Output：最终交付什么

对应成结构图：

Goal 定义方向。比如修复线上阻塞性 Bug，或者每天发现一个产品增长机会。

Workflow 定义流程。比如读取信号、分析原因、生成任务、执行修改、验证结果、记录日志。

Task 定义当前这一轮要做的具体事情。Goal 是大方向，Task 是当前动作。

Timeline 定义节奏。比如每 30 分钟检查一次工单，每天早上 9 点跑一次 SEO 分析，或者监控报警后立即启动。

Permissions 定义权限。比如只能改指定目录，不能直接部署生产，不能读取敏感密钥。

Verification 定义完成标准。比如测试通过、截图通过、指标达标。

Stop Conditions 定义停止条件。比如连续失败、权限不足、修改范围越界时停止。

Loop Contract 的价值，是让 AI 的自动化有边界。

它不是“你自己看着办”，而是“在这份合同内循环推进”。

LOGS.md：运行日志

LOGS.md 是整个 loop 的运行记录。

每一轮 AI 做了什么、看到了什么、判断了什么、失败在哪里、下一步准备做什么，都应该写进去。

一个简单的 LOGS.md 可以长这样：

# LOGS## 2026-07-10 03:12Trigger:- 线上支付接口出现大量 500 错误Observation:- 错误集中在 `/api/pay/confirm`- 日志显示 `user_coupon` 字段为空Action:- 搜索支付确认逻辑- 找到 `confirmPayment` 中对 `user_coupon.id` 的直接访问Result:- 本地复现成功Next:- 增加空值兼容- 补充回归测试

下一轮继续追加：

## 2026-07-10 03:25Action:- 修改空值处理逻辑- 新增 coupon 为空时的回归测试Result:- 单元测试通过- 类型检查失败Next:- 修复类型定义

这个文件很关键。

因为 loop 最怕黑箱运行。LOGS.md 让每一次执行都可追踪、可复盘、可接手。

工程师早上起来，不需要猜 AI 半夜到底干了什么，直接看 LOGS.md 就能知道整个过程。

一次 Loop 是怎么运行的

Loop Engineer 的运行过程，可以画成这样：

这里最重要的是中间这段：

分析执行验证反馈再分析

AI 不是一次性给出答案，而是在验证结果里继续调整。

这就是 Loop Engineer 和普通 AI 编程最大的区别。

普通 AI 编程重心在生成。

Loop Engineer 的重心在闭环。

半夜修 Bug 的完整例子

回到开头那个 demo。

这里有一个很重要的点：这个 demo 不是一个 loop 从头跑到尾，而是多个 loop 合作完成一件事。

一个真实的线上问题，通常不会直接变成“请 AI 修 Bug”。它会先以用户反馈、客服工单、后台异常、监控报警的形式出现。系统需要先把这些信息同步下来，再归类，再判断是否达到处理阈值，再生成任务。任务被人工批准以后，才进入 coding 阶段。

所以这套机制更像一条多 loop 协作流水线：

sync -> feedback -> task -> coding -> verify -> followup

每个 loop 只负责一段清晰的职责。

sync从 Admin API 同步 bug 反馈，写入 artifacts/feedbackfeedback使用 DeepSeek 对 pending 反馈做归类，提炼成 signalstask使用 DeepSeek 判断信号是否达阈值，生成 status=proposed 的 taskcoding使用 Cursor 执行修复，但必须等 task 被人工 approvedverify使用 DeepSeek 对照 Acceptance Criteria 写验证报告followup使用 DeepSeek 生成用户回访草稿，但永不自动发信serve提供 Control Plane API，只读展示状态，并支持手动 SYNC 和批准worker一 loop 一 worker，通过 --loop sync|feedback|task|coding|verify|followup 调度

对应成流程图，大概是这样：

这张图里有两个门禁非常关键。

第一个门禁在 coding 前面：

task.status === approved

只有任务被人工批准以后，Cursor 才能进入修复。也就是说，AI 可以帮你发现问题、整理信号、提出任务，但不能直接因为发现一个反馈就开始改代码。

第二个门禁在 followup 后面：

只生成草稿，永不自动发信

AI 可以根据修复结果生成用户回访文案，但发送动作仍然交给人。这个边界很重要，因为用户沟通不只是技术动作，也包含语气、责任和商业判断。

如果把它画成系统结构，会更清楚：

这也是为什么前面说，Loop Engineer 不只是“让 AI 自动修 Bug”。更准确的说法是：

把一个复杂工作拆成多个有边界的 loop，让它们通过文件、状态和人工门禁协作。

在这个 demo 里，sync 负责拿到事实，feedback 负责整理信号，task 负责提出任务，coding 负责修复，verify 负责验证，followup 负责生成沟通草稿，serve 负责给人一个控制面板，worker 负责让每个 loop 独立运行。

这样做的好处是边界非常清楚。

DeepSeek 更适合做归类、判断、总结和报告。Cursor 更适合进入代码仓库执行修复。人工负责批准任务和对外沟通。每个角色只做自己擅长、也被允许做的事情。

这时工程师早上醒来以后，看到的不是一个黑箱 AI 已经偷偷改完了线上系统，而是一条完整的处理链路：

哪些反馈被同步哪些反馈被归类成信号哪些信号达到了任务阈值哪个 task 被批准Cursor 改了哪些代码DeepSeek 如何对照 Acceptance 做验证最后生成了什么回访草稿

这个体验，才是 Loop Engineer 的价值。

它不是让一个 AI 袋里在生产环境里自由发挥，而是把复杂任务拆成多个可观察、可审计、可批准、可验证的小循环。

Loop 不只用于修 Bug

修线上 Bug 是一个很容易理解的场景，但 Loop Engineer 不只适合工程故障。

它还可以放在很多业务工作流里。

比如客服支持：

每 30 分钟读取新工单自动回复简单问题把高频摩擦点记录下来沉淀成产品信号如果某个问题重复出现，就生成改进建议

比如 SEO：

每天早上分析数据找出有机会的关键词生成页面草稿发布后持续监控表现把效果好的方向继续放大

比如产品增长：

每 2 小时读取产品分析数据从用户行为里提炼信号整理实验优先级生成一个小的产品改动 PR等待人审核和合并

这些场景看起来不一样，但结构是一样的：

Trigger 启动任务Artifacts 保存上下文Loop Contract 约束边界Tools 执行动作Verify 验证结果LOGS.md 记录过程Output 交付结果

只要一个工作可以被持续观察、执行、反馈和改进，它就有机会被设计成 loop。

Loop Engineer 改变的是工程组织方式

我更愿意把 Loop Engineer 看成一种新的工作组织方式。

过去我们把 AI 当成一个问答工具。人提出问题，AI 给出答案。

现在更有效的方式，是把 AI 放进一个有边界的系统里。它有输入，有工具，有任务合同，有验证标准，也有停止条件。

这个变化很重要。

因为真实工作里，最耗时间的部分往往不是想出一个答案，而是持续推进：

看数据查日志整理上下文尝试修复运行验证记录过程提交结果

这些动作一旦被 loop 化，AI 就不再只是帮你写一段代码，而是可以帮你推进一个完整任务。

工程师的角色也会跟着变化。

人不再需要盯着每一个细节操作，而是更多负责设计 loop：

定义目标设计合同准备上下文配置工具设置验证控制权限审核结果

这也是我觉得 Loop Engineer 值得关注的原因。

它不是一个花哨的新词，而是 AI 工程化之后很自然出现的一层能力。

结尾

Loop Engineer 的核心可以总结成一句话：

让 AI 在一个有目标、有上下文、有工具、有验证、有边界的循环里持续工作。

半夜三点的线上 Bug，只是一个最直观的例子。

真正有意思的地方在于，很多过去只能靠人反复盯、反复查、反复试的工作，都可以被重新设计成 loop。

AI 不是只负责回答问题，而是开始参与任务推进。

从 Prompt 到 Loop，这中间的变化，就是 AI 从“会说”走向“会做”的关键一步。