AI 编程正在换底层逻辑:从写 Prompt 到写 Loop过去一年，很多人学习 AI 编程，第一反应是：怎么把提示词写得更好？怎么让 Agent 一次性理解我的需求？怎么让它少犯错、多输出？但真正提醒我们的，是另一件更底层的事：AI 编程的核心抽象正在变化。过去我们是在“提示 Agent”，未来我们是在“设计循环”。也就是说，AI 不再只是一个等待指令的助手，而会逐渐进入一个持续工作的系统：它可以读代码、改文件、运行命令、调用工具、看日志、修错误、再测试、再提交，直到满足某个条件，或者被停止。part 01不是 Prompt 不重要，而是 Prompt 的位置变了很多人会误解：既然进入循环工程时代，是不是提示词不重要了？恰恰相反，提示词仍然重要，只是它不再只停留在聊天框里。报告里有一个很关键的判断：Prompt 从主界面变成 Loop 内部配置。这句话翻译成普通人的话，就是：过去你把要求一次性写给 AI；未来，你要把要求拆进系统的不同位置。哪些任务能做，哪些不能做；什么结果算完成，什么结果必须返工；什么时候继续，什么时候停止；哪些工具能调用，哪些权限不能碰；这些都会变成循环系统的一部分。所以，未来真正会用 AI 的人，不只是会写一句漂亮的提示词，而是会把提示词沉淀成技能、规范、评估标准和停止条件。part 02AI 可以执行，但工程判断不能外包报告里最适合做公众号标题的一句话是：“循环可以提示 Agent，但工程判断不能外包。”Agent 可以越来越能干，可以替你执行越来越多动作，但它不应该替你决定目标、边界和验收。一个工程任务到底要解决什么问题，什么风险不能接受，什么证据才算完成，这些判断仍然必须由人负责。这也是 AI 编程从“玩具感”走向“工程化”的分水岭。玩具式使用，是让 Agent 生成一段代码、写一份文案、改一个页面；工程化使用，则是让 Agent 在明确边界中反复执行，同时每一步都有可检查的证据。换句话说，人的角色不是消失，而是从“每一步都亲自操作”转向“设计目标、边界、验收与复盘”。part 03真正的效率来自“更少轮次得到可证明结果”很多人评价 AI 效率，喜欢看它跑得快不快、输出多不多。但在循环工程里，效率的定义要变。真正的效率，不是让 Agent 不停循环，也不是让它产出一堆看起来很努力的过程，而是用更少轮次得到可证明的结果。比如一个代码修复任务，不是“AI 说它改好了”就结束，而是要看测试是否通过、日志是否正常、依赖是否一致、上线后是否有异常。再比如一个运营任务，不是“AI 写了方案”就结束，而是要看客户是否回复、数据是否改善、复购是否发生。循环工程强调的不是自动化表演，而是证据链。没有证据链的自动化，只会把错误包装得更快、更大。part 04从一次性对话，到可持续工作流过去我们和 AI 的关系，更像一次次对话。你问一句，它答一句；你补一句，它改一句。而循环工程的出现，意味着 AI 进入了更接近真实组织工作的状态：任务会被拆分，过程会有反馈，结果会被评估，异常会进入分流，完成后会被归档。这也是为什么报告会把 Claude Code 的 /loop、/goal、Routines、Skills、Worktrees、MCP，以及 Codex 的 Agent Loop、Automations、Worktrees 和 Skills 放在一起分析。它们看似是不同产品能力，背后其实都在补齐同一套东西：让 Agent 能够长期、稳定、可控地工作。AI 编程的下一阶段，不是“谁更会写 Prompt”，而是“谁更会设计 Loop”。当每个团队都能让 Agent 跑起来时，差距就不在于是否用了 AI，而在于你有没有一套可验证、可停止、可复盘的循环系统。未来最重要的工程师，可能不只是写代码的人，而是能把目标、工具、反馈、评估和治理连接起来的人。一句话总结：Build the loop, stay the engineer。把循环建起来，但工程判断不要交出去。
夜雨聆风
