从Prompt Engineering到Loop Engineering，AI编程协作正在进入工程化闭环时代！

过去两年 AI 编程讨论的焦点是 Prompt Engineering——如何写好单次提示词获得更好的回答。但随着编程智能体能力不断提升，这种模式正在触及天花板。真实的软件开发并非一次性交互，而是需求澄清、方案设计、代码修改、测试验证、错误修复、文档更新等多环节的连贯流程。在这个流程中，每一步都可能失败，每一步都需要反馈和修正。如果人仍然守在每轮交互的入口，不断复制上下文、重复解释规则、追问下一步，那么 AI 越强反而越容易把人拉进新形式的微操陷阱——不是直接写代码，而是不断调度智能体。

这就是为什么真正的控制点正在从"这一轮怎么问得更好"转向"整个流程怎么持续变好"。这种理念的实践就是 Loop Engineering（循环工程）。

Loop Engineering 的核心是为编程智能体设计一个可重复、可观察、可验证、可修正的工作循环。不同于单次提示工程关注的是一次提示的质量，循环工程关注的是一段流程的可靠性。人类工程师给出目标、上下文、工具权限和停止条件，智能体在这个边界内持续迭代，直到完成任务或遇到需要人类判断的节点。它需要回答的问题是：什么时候启动、读取哪些上下文、能调用哪些工具、怎样判断做对了、失败后怎么修正、哪些动作必须人工确认。

一个可运行的 Loop 需要六类构建协同工作。首先是 Automations，提供循环的心跳——让任务按时间、事件或条件自动启动。其次是 WorkTrees，提供隔离层，使得多个智能体可以并行修改而不互相覆盖。第三是 Skills，用来沉淀项目知识和规则，避免每轮都从零开始解释。第四是 Plugins 和 Connectors，接入 Issue 系统、CI/CD、PR、监控和内部工具，让智能体进入真实的工具链。第五是 Subagents，通过分离实现者和检查者的角色，形成内部制衡。第六是 Memory，把尝试记录、测试状态和下一步计划保存到对话之外，使循环可以恢复和继续。

一个真实的循环可以从每天早上的自动巡检开始。系统读取昨天的 CI 失败、开放的 Issue、近期提交和团队反馈，然后用某个 Skill 把问题、来源、影响范围和优先级建议整理出来。值得处理的问题会进入一个独立的 WorkTree，由实现智能体阅读项目规则、起草方案并完成代码修改，然后交给审查智能体检查边界、测试以及回归风险。如果测试失败，失败的输出会回到实现环节继续修正；如果测试通过，连接器可以打开 PR、关联 Ticket、把摘要发给团队。最后，状态文件记录这一轮发生了什么，让下一轮从已知状态继续，而不是重新施议。

但 Loop Engineering 虽然吸引力很大，却对系统设计的要求也很高。首先是 Token 成本。自动化运行、长上下文、反复验证都会放大消耗，必须有清晰的触发条件和停止条件。其次是无人指手的错误。系统说 Done 不代表代码真的可靠，权限越深，验证和人工门禁就越重要。第三是理解债和认知投降。AI 写得越快，工程师越要同步理解改动而不是只相信摘要，因为最终的交付责任仍在工程师手里。

从 Prompt Engineering 到 Loop Engineering，变化的不是提示词消失了，而是提示词被放进了更大的系统工程。工程师的工作位置前移，不再是每轮都给指令，而是在循环设计、全线边界、上下文沉淀、验证信号和最终审查上下功夫。未来的 AI 编程会越来越像设计一套智能体持续推进工作的系统，但可靠交付的责任仍然在工程师手里。