文章目录
- 前言
- 一、Loop Engineering 是怎么火起来的
- 二、四次范式跃迁：从语言学到管理学
- 三、一个完整 Loop 的五个组件
- 1. 定时器（Trigger）：循环的心跳
- 2. 工作空间（Workspace）：彼此隔离的执行环境
- 3. 知识体系（Knowledge System）：项目的长期记忆
- 4. 连接器（MCP / Tool Layer）：通向真实世界的端口
- 5. 子 Agent（Verifier）：做事的和检查的必须分开
- 四、/goal 命令：Loop 骨架的最小可用产品
- 五、定义目标的能力，比写脚本难十倍
- 六、古德哈特定律：Loop 工程师必须知道的隐形陷阱
- 七、Harness 与 Loop 的协同：约束先行 + 闭环驱动
- 八、从架构师视角看 Loop Engineering 的几个工程取舍
- 1. 「自驱动」不是「全自动」，关键节点必须留人在
- 2. 验证器的成本，往往比你想象的高
- 3. 成本和限速必须从 Day 1 开始想
- 4. 子 Agent 拆分要克制，不是越多越好
- 5. 知识体系是 Loop 的杠杆，但维护是长期工作
- 6. 范式跃迁不是替代关系，是叠加关系
- 九、给一线技术人的几条 Loop 落地建议
- 1. 这周可以做的：先选一个低风险任务，跑一次最小 `/goal`
- 2. 这个月可以做的：把团队最痛的重复活儿改造成 loop
- 3. 这个季度可以做的：建立团队级的 Loop 规范
- 4. 长期需要建立的：从「写代码」转向「定义目标」的能力
- 总结
前言
这两天圈子里被一个新词刷屏了——Loop Engineering。
第一次看到这个词的时候，我下意识又有点抵触。最近这两年，AI 圈造词的速度，明显比模型迭代还快。Prompt Engineering 没消化完，Context Engineering 又来了，紧跟着 Harness Engineering，现在又来个 Loop。每个新词背后都跟着一波课程、咨询、训练营，搞得不少做技术的同学一看到「XX Engineering」就先头疼三分。
但我把 Addy Osmani 的长文、The New Stack 的报道、卡兹克老师的中文解读都扒了一遍，又对照着 Claude Code、Codex 这些工具自己的/goal、/loop命令试了几轮，发现这次造的不是新词，是确实在描述一个「工程范式正在跃迁」的事实。
一句话核心观点：Loop Engineering 不是 Prompt 的升级版，而是 AI 编程从「人手动喂指令」走到「人设计自驱动循环」的范式分界线。
这篇文章不打算停在「Loop 是什么」这一层。我从一个研发管理者的视角，把它和前面三次跃迁串到一起，再讲讲为什么 Loop 的真正难点不在工程，而在管理学，以及一线团队落地它的时候，最容易踩进哪些坑。
读完这篇文章，你能搞明白这几件事：
- Loop Engineering 到底是什么
