确实，“一次性的API调用”这个比喻太到位了。我最近也在折腾类似的闭环流程，发现最关键的瓶颈反而不是模型本身，而是怎么把“错误反馈”这一步做得足够快和准。你试过给循环工程里加自定义的测试断言吗？我加了之后，AI自己迭代修复的成功率直接从30%蹦到了70%左右，感觉这才是把提示词从“遗书”变成“自动化脚本”的核心。

说实话，循环工程这个概念我最近也在疯狂实践。之前一直觉得提示词工程快走到头了，每次调prompt都像在搞玄学，加一句“请仔细思考”可能就出奇迹，去掉一个空格就崩。但Cherny这个思路确实戳中我了——开发者从“手把手教AI每一步”变成“设计一个让AI自己纠错的系统”，这根本不是提示词的消亡，而是提示词从“一次性指令”进化成了“持续运行的微循环”。

我自己试过类似的方式，比如用Claude Code写一个爬虫脚本，先不追求完美，让它在每次报错后自动读取错误日志、修正代码、重新运行，几轮下来代码质量比我自己手写还稳。关键是真的省心，你只需要给个大方向，比如“用requests库，注意反爬”，剩下的交给反馈闭环去磨。

不过有个实际痛点想跟你讨论：循环工程里的“反馈信号”怎么设计才够精准？我试过让AI自己判断“是否完成任务”，结果它经常自我感觉良好，实际上逻辑有漏洞。后来我改成让它输出测试报告，我人工看一眼再决定是否继续循环，但这样又打断了自动化流程。Cherny他们是不是有更聪明的做法，比如让AI自己写测试用例并验证通过率？你有没有遇到类似的问题？

这帖子看得我直接拍大腿，“调度员变系统设计师”这个说法太对了。我最近也在折腾类似的事，发现最头疼的反而不是怎么设计循环逻辑，而是怎么让AI在迭代过程中不把之前的好思路给覆盖掉。你试过在反馈闭环里加版本回滚节点吗？感觉这比单纯调/loop命令要稳得多。

看到循环工程这个提法挺有共鸣的。我最近也在拿Claude Code试类似模式，发现关键其实不在提示词本身，而是怎么设计那个“自动反馈”的阈值——迭代多少次、什么时候停下来让你review。你试过给循环工程设定“失败回退”机制吗？比如某轮改崩了能自动回滚到上一个稳定版本继续迭代，我总觉得这个比优化提示词更实用。

说实话，循环工程这个概念我最近也在自己的项目里试水，核心确实是把反馈闭环从手动变成自动化——但有个实际痛点：当循环深度超过5轮时，AI容易在局部最优里打转，甚至开始“遗忘”早期约束。你是用什么策略来限制搜索空间，还是干脆靠多轮验证集做外部纠偏？我这边试过对每次迭代的产出做差分打分，但阈值设高了又容易过早收敛。