从手搓 prompt 到无人值守：Loop 工程方法论拆解
公众号名称：极客BIM设计工坊
作者名称：朗朗晴空
发布时间：2026-06-29 17:04
📹 此处为视频内容（vid: wxv_4582386822759940101）（上图为封面），未能直接提取，请前往原文查看：在公众号原文中观看
2026 年 6 月，AI 编程的主流工作方式从「手搓 prompt」转向「设计 loop 系统」。
你不再逐轮指挥 agent，而是写一个小程序，定时给它下指令、读结果、判断是否完成。Claude Code 作者 Boris Cherny 已经把这种方式用到 production：30 天内 100% 的贡献由 agent 落地，259 个 PR 无人值守合并。
5 块
自运行 loop 必备组件
259 PRs
Boris Cherny 单人 30 天产出
95%
可被 loop 自动化的重复工作
大模型开发者社区里，最近两个月最热的词不是「推理」也不是「上下文工程」，而是 loop engineering。这个词来自 Google 工程师 Addy Osmani 和 OpenAI 工程师 Peter Steinberger 的讨论。核心论点很简单：当你能让 AI 定时自己跑任务，人类的角色就从「逐轮 prompt 操作员」变成「设计自运行系统的工程师」。Anthropic 官方文档也同步了这个方向：Claude Code 文档里 agent loop 的定义是「Claude 评估 prompt -> 调用工具 -> 收到结果 -> 重复直到完成」。你不需要再写每一轮 prompt，你只需要设计 loop 的规则。
从 Prompt 工程到 Loop 工程
过去两年，你拿到一个 coding agent 的标准姿势是：写一个 prompt，丢足够的上下文进去，等它返回，再写下一个 prompt。你要待在聊天窗口里，每一轮都亲手触发。
Loop 工程把这件事翻过来了。你不再做 prompt 操作员，你做的是设计一个系统，让这个系统替你给 agent 发 prompt。agent 的那套「感知、推理、行动、观察」的内循环还在，但你安排了一个外循环来调度它。
▸ 三层抽象
Prompt 工程：优化单条 prompt 的措辞，单位是「你手搓的一轮对话」
上下文工程：决定每轮喂给模型什么文件、历史、工具，单位是「单个回答的条件」
Loop 工程：设计「什么时候 prompt、prompt 什么、结果不合格怎么办」，单位是「多轮自运行周期」
三层抽象不是线性替代，而是逐步把人力从「手动触发」里解放出来。很多人把 loop 误以为是「自动化跑 prompt」，但真正的区别在于：loop 会读执行结果、判断是否达标、决定是再跑一轮还是升级给人工。
Loop 的五块积木
一个能稳定运行的自循环，需要五样东西，再加一个记忆槽。名字在 Claude Code 和 OpenAI Codex 里略有不同，但能力完全对等。
▸ 5 building blocks + memory
1. Automations — 定时触发，自己发现任务并做初筛
2. Worktrees — 多 agent 并行时不撞文件
3. Skills — 把项目知识写成 SKILL.md，不用每次重教
4. Connectors / MCP — 接线 issue tracker、Slack、CI
5. Sub-agents — 一个做执行，一个做验证
Memory — 写在磁盘上的状态文件，跨 run 存活
这里面最关键的是 memory。模型每轮之间会忘光所有上下文，所以「做到哪了、下一步是什么」必须存在磁盘上，不能存在 context window 里。一个 markdown 文件或 GitHub issue board 都能胜任，核心要求是：活在一个 single conversation 外面。
Claude Code 的现成命令是 /loop 和 /goal。/loop 把自然语言指令转成 cron job，定时执行；/goal 则让 loop 在某个可验证条件成立前一直跑。Anthropic 官方文档定义了内循环：Claude 评估 -> 调用工具 -> 收到结果 -> 重复直到完成。
FIX起始 loop 实例
Claude Code：/loop “先读昨天 CI 失败记录，写到 TODO.md” —schedule “0 9 * * 1-5”
Claude Code：/goal “test/auth 下所有测试通过，且 lint 清零”
OpenAI Codex：codex /goal “billing 模块迁移到新 pricing API，现有测试保持绿色”
一个真实 case：AI 公众号写稿 loop
小白开发者最容易上手的 loop 不是修代码，而是管理每天重复出现的「固定噪音任务」。以公众号写稿为例，一个 loop 可以这样跑：
▸ 公众号自动写稿-loop 链路
触发：每天 08:30 通过 cron 启动一次 Claude Code session
读取：从固定目录读当天选题.md 和昨日读者反馈
执行：调用 SKILL.md 里的 mp 技能，生成一篇公众号草稿 JSON
验证：跑 lint_draft.py 检查格式、去 AI 腔、过质量门
升级：lint 通过后发消息通知人工；lint 不过把稿子移入 error/ 并重试一次
留痕：把已发稿和草稿状态写入 memory/2026-06-30.md
真正执行时，你作为 loop 工程师要做的事只有一件：把「重复 3 次以上的固定流程」写成一段可验证的指令。剩下让 loop 跑。几天后你会发现，大多数 mornings 打开电脑时，公众号草稿已经躺在 error/ 或 ready/ 目录里。
关键在于 边界写清楚：哪些步骤自动完成，哪些步骤人工拍板，以及 loop 失败时怎么记录错误、怎么通知你。不是 prompt 写得有多花哨，而是自动化范围定义得多清楚。
Loop 的成熟度阶梯
从业者的共识是：不要第一天就搭全自动多 loop 系统。按这五级往上爬：
FIX五级成熟度
L0 手搓：每轮对话手动 prompt agent，适合一次性复杂问题
L1 分诊：定时跑一次，把发现写入 markdown，不改代码，人读后再行动
L2 起草：Loop 在隔离 worktree 里起草修复，人工 review 后合并
L3 验证：加入 verifier sub-agent 做 gate，人只批一次
L4 自合并：低风险变更（依赖升级、lint 修复）自动合并，人只查日志
每一级只多一个能力，且每一步都留着人工审批。loop 只有在你能信任它产出、且能快速 review 它产出时，才值得往上一级跳。
失败边界与风险
Loop 把「人酿的错」变成了「无人值守酿的错」。几个真实风险要先看清。
FIX验证断点
问题 — “done” 只是 agent 的一面之词，不是可复现的证明。
对策 — 让 stop condition 变成可测试的 contract：「test/auth 全部通过 + lint 清零 + 不修改 public API」。
FIXtoken 账单失控
问题 — 调度越频繁、sub-agent 越多，token 消耗呈指数级上升。
对策 — 先设慢节奏和预算上限，跑一周看实际消耗，再上调频率。
FIX认知投降
问题 — loop 跑顺了以后容易放弃判断，全盘接受它产出的结果。
对策 — 你是 loop 的设计者，不是 loop 的签收员。持续 review 关键变更，保持对代码库的理解深度。
SOURCES
Addy Osmani, Loop Engineering — Lushbinary, June 2026
Boris Cherny interview, WorkOS Acquired Unplugged, June 2026
Anthropic, How the Agent Loop Works — Claude Agent SDK Docs
Peter Steinberger, Agent Scripts — github.com/steipete/agent-scripts
内容效果不满意？点此反馈