“别再写Prompt了，设计loop吧！”这个开源项目，强烈推荐你安装一个

“别再写Prompt了，设计loop吧！”这个开源项目，强烈推荐你安装一个 “别再写Prompt了，设计loop吧！”这个开源项目，强烈推荐你安装一个 Modified June 25 对我这样的穷鬼来说，是非常友好了！所以我在知道有这么个东西的第一时间，立马给我codex配置上了。 三、L1 到 L3，慢慢放手 这个仓库还有一个我非常喜欢的设计：分阶段信任。 它并非一上来就让循环全自动接管一切，而是设计了三个等级： • L1，纯报告。循环跑完了什么都不改，只生成一份观察报告发给你。你看了之后自己决定要不要动手。第一周，你在这个等级待着。 • L2，辅助修复。循环在发现问题之后可以尝试自动修，但只修那些低风险的、你明确允许的事情，比如格式化代码、更新依赖版本号。不能自己合并。 • L3，全自动。你已经完全信任这个循环了，它自己发现问题、自己修复、自己合并。当然前提是子 Agent 审查那关过了。 这个坡度设计得很合理...你不信任循环，就让它先报告，跑了一周没问题，再慢慢放开权限。 但凡出过一次事，立刻降回 L1。 合理，而且很安全， 就像我之前设计的obsidian的loop engineering一样（ 四、从“操作员”到“设计师” 写到这里，我回头看了看自己那八个定时任务。 说实话，它们已经是 loop 的雏形了，差距在于，一个真正的 loop 不是"到点就跑"，而是"到点了先判断一下值不值得跑"。 值就跑，不值就跳过，跑出问题了自己修。 如果修不了了咋办？把问题整理好，连上下文一起交到我手上。 这才是"设计师"和"操作员"的区别。 Addy Osmani 在 Loop Engineering 的原作里说了这么一句话： "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go." 翻译一下就是：造循环。但造的态度应该是——你依然是那个工程师，而不只是一个按启动按钮的人。 他说这句话是有原因的。 Loop Engineering 的 GitHub 仓库里专门有一个板块叫"失败模式"，里面记录了所有翻车案例。 • 有人在 CI 自动修复模式下让循环自动修 bug，结果循环把一个关键参数改错了，线上炸了六个小时。 • 有人在依赖更新模式里没设版本白名单，循环把 Spring Boot 从 3.0 升到了 5.0，整个项目直接编译不过。 • 还有更隐蔽的问题。文章里给了一个概念叫"理解负债"，意思是你越让循环替你干活，你对代码的直觉就越退化。 • 比如说：循环帮你改了三个月 bug，有一天循环挂了，你打开代码一看，这谁写的，我怎么不认识了。 哦，原来是自己项目的代码。 所以这个概念从头到尾都在强调一件事：循环不是让你偷懒的借口。 它是把你从"操作 AI"这件事里解放出来，让你回到更重要的位置上去，设计系统、做判断、把关质量。 结语 prompt 会过时，模型会更新，工具会换。 那些你和 AI 之间的话术、你精心打磨的提示词模板、你已经习惯的一套工作流，迟早都会被版本迭代洗掉。 但一条你亲手设计的循环，一条你知道它什么时候该跑、什么时候该停、什么地方不能碰、什么地方需要你来拍板的循环。 这，才是你留在项目里的工程直觉。 感谢你看到这里。 如果觉得这篇文章还不错，欢迎： 点赞，推荐，转发 给你的朋友，让他试试看用Loop Engineering代替那些永远跑不通的定时任务。 我建了一个 AI 交流群，群的信息密度很高，也有很多AI行业的从业者。 如果你是以下选手： • 一线 AI 从业者——工程师、产品经理、创业者、投资人 • 正在把 AI 融入自己的业务或工作流 • 对 AI 工具、Agent、大模型落地有真实的经验和困惑 • 不只是想"学 AI"，而是想和同行交流、找资源、找合作 感兴趣的话，移步到公众号后台，回复：" 进群 "，和朋友们一起聊关于 AI 的那些事儿。 我是 Simonlin，下次见。 对我这样的穷鬼来说，是非常友好了！所以我在知道有这么个东西的第一时间，立马给我codex配置上了。 三、L1 到 L3，慢慢放手 这个仓库还有一个我非常喜欢的设计：分阶段信任。 它并非一上来就让循环全自动接管一切，而是设计了三个等级： • L1，纯报告。循环跑完了什么都不改，只生成一份观察报告发给你。你看了之后自己决定要不要动手。第一周，你在这个等级待着。 • L2，辅助修复。循环在发现问题之后可以尝试自动修，但只修那些低风险的、你明确允许的事情，比如格式化代码、更新依赖版本号。不能自己合并。 • L3，全自动。你已经完全信任这个循环了，它自己发现问题、自己修复、自己合并。当然前提是子 Agent 审查那关过了。 这个坡度设计得很合理...你不信任循环，就让它先报告，跑了一周没问题，再慢慢放开权限。 但凡出过一次事，立刻降回 L1。 合理，而且很安全， 就像我之前设计的obsidian的loop engineering一样（ 四、从“操作员”到“设计师” 写到这里，我回头看了看自己那八个定时任务。 说实话，它们已经是 loop 的雏形了，差距在于，一个真正的 loop 不是"到点就跑"，而是"到点了先判断一下值不值得跑"。 值就跑，不值就跳过，跑出问题了自己修。 如果修不了了咋办？把问题整理好，连上下文一起交到我手上。 这才是"设计师"和"操作员"的区别。 Addy Osmani 在 Loop Engineering 的原作里说了这么一句话： "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go." 翻译一下就是：造循环。但造的态度应该是——你依然是那个工程师，而不只是一个按启动按钮的人。 他说这句话是有原因的。 Loop Engineering 的 GitHub 仓库里专门有一个板块叫"失败模式"，里面记录了所有翻车案例。 • 有人在 CI 自动修复模式下让循环自动修 bug，结果循环把一个关键参数改错了，线上炸了六个小时。 • 有人在依赖更新模式里没设版本白名单，循环把 Spring Boot 从 3.0 升到了 5.0，整个项目直接编译不过。 • 还有更隐蔽的问题。文章里给了一个概念叫"理解负债"，意思是你越让循环替你干活，你对代码的直觉就越退化。 • 比如说：循环帮你改了三个月 bug，有一天循环挂了，你打开代码一看，这谁写的，我怎么不认识了。 哦，原来是自己项目的代码。 所以这个概念从头到尾都在强调一件事：循环不是让你偷懒的借口。 它是把你从"操作 AI"这件事里解放出来，让你回到更重要的位置上去，设计系统、做判断、把关质量。 结语 prompt 会过时，模型会更新，工具会换。 那些你和 AI 之间的话术、你精心打磨的提示词模板、你已经习惯的一套工作流，迟早都会被版本迭代洗掉。 但一条你亲手设计的循环，一条你知道它什么时候该跑、什么时候该停、什么地方不能碰、什么地方需要你来拍板的循环。 这，才是你留在项目里的工程直觉。 感谢你看到这里。 如果觉得这篇文章还不错，欢迎： 点赞，推荐，转发 给你的朋友，让他试试看用Loop Engineering代替那些永远跑不通的定时任务。 我建了一个 AI 交流群，群的信息密度很高，也有很多AI行业的从业者。 如果你是以下选手： • 一线 AI 从业者——工程师、产品经理、创业者、投资人 • 正在把 AI 融入自己的业务或工作流 • 对 AI 工具、Agent、大模型落地有真实的经验和困惑 • 不只是想"学 AI"，而是想和同行交流、找资源、找合作 感兴趣的话，移步到公众号后台，回复：" 进群 "，和朋友们一起聊关于 AI 的那些事儿。 我是 Simonlin，下次见。 🔗 原文链接： https://mp.weixin.qq.com/s? biz=Mz... https://mp.weixin.qq.com/s? biz=Mz... 原创 Simonlin Simonlin Simonlin的精神世界2026年6月24日 08:30 Hello啊朋友们，我是Simonlin，用通俗易懂的语言手把手带你玩转AI，提升10倍效率 ！ 每天早上九点，我的Cola会准时给我发一条消息。 有时候是群日报，有时候是AI资讯简报，有时候是知识库整理报告.... 八个定时任务轮着跑 所以，我自己已经很久没有主动跟Cola说"帮我生成个日报"了。 听起来很爽对吧？完全解放双手！但你仔细想想，这个流程有个bug。 Cola（又或者是你自己的本地Agent助理）只是在 按时间触发， 到点了就跑那条固定的prompt。 在“总结群聊日报”这件事情上，它实际上是这样的： 今天群里消息多，它跑一次，今天群里静悄悄，它也跑一次，跑完了发给我，不管有没有价值。 比这更糟糕的是另一种情况... 举个真实的栗子： 就今天早上，我心血来潮查了一下后台，发现八个定时任务里有两个已经静悄悄挂了好几周。 有一个任务，最后一次成功跑是两周前，而另一个任务，6 月 22 号的直接给我跳过了。 没有任何报错和提醒...它们只是到点触发、发现跑不通、然后安安静静地挂掉。 而我每天傻傻还在等它们发消息，什么都不知道。 这个问题的根源很简单： 我设计了一套 定时器 ，但我没有设计一套 判断系统 。 最近爆火的Loop Engineering，要解决的问题就是这个。 它的思路非常简洁：把一次性的手动prompt，升级成一个会自己判断、自己找活干、自己验收、自己决定要不要继续的 循环 。 Addy Osmani 把这套思路写成了长篇论述，而有一位开发者做了一件更狠的事： 他把这个概念变成了一个可以直接跑的 GitHub 仓库。 项目地址： https://github.com/cobusgreyling/loop engineering 一、五个模块，拼成一条自动化神经 这个循环看着好像没什么特殊的，因为它只有五个模块。 • 第一，自动化调度。循环不是等你召唤，是按频率自己启动。可以设成每小时跑一次，也可以设成每天早上九点。甚至可以在检测到某个事件，比如 GitHub 上有新的 Issue，的时候自动触发。 • 第二，工作树隔离。多个任务同时跑的时候互相不干扰，就像每个人在独立的房间里干活。你在改前端代码的时候，循环不会在同一份文件上踩到你的脚。 • 第三，技能文档。把项目知识写成文档固化下来，循环里的 agent 每次读一下就知道这个项目是干嘛的、架构是什么、有什么坑不要踩。不用你每次都解释一遍。这才是真正的"一次配置，长期复用"。 • 第四，插件和连接器。通过 MCP 协议接入真实工具，Git、飞书、数据库...这个循环不是活在沙箱里的，它能真正碰到你的项目。 • 第五，子 Agent 分工。一个 agent 干活，另一个 agent 审查。制造者和检查者分开，代码没经过审查不会自己合进去。你只做最后一道把关。 还有一个记忆层。循环跑了多少次、上次做到哪了、有没有遗留问题、哪些 PR 已经被它动过了，都记在对话之外的 STATE.md 文件里。 你把这些拼在一起看，它就是你项目的自动化神经系统。 而且有意思的是，这些模块不是什么需要自己从零开始搭建的东西，Claude Code 和 Codex 都已经内置了全部五个模块，设计的循环可以跨工具跑。 所以你不需要写脚本去管理文件锁，不需要自己写调度逻辑，你只需要设计逻辑，完全适配你的工作流。 二、七个模式，有人帮你做了 在这个项目里，一行命令就能让你整个循环跑起来。 里面有七个已经设计好的生产级循环模式，每个都配了完整的配置文件和启动命令，我们一个个看。 • 第一个，"每日筛选"。每天早上自动扫一遍你的项目，把昨天新开的 Issue、没回复的 PR、CI 失败记录全部挖出来，写成一份报告发你。比我自己每天点开 GitHub 翻半天高效得多。这是入门款，token 成本最低，建议所有人从它开始。 • 第二个，"PR 自动看护"。一旦有 PR 的 CI 挂了，循环自动分析失败日志，判断是谁的改动导致的、具体炸在哪一行，然后把诊断结果贴在 PR 下面。你不用再盯着 CI 转圈了。 • 第三个，"CI 自动修复"。比 PR 自动看护更进一步，CI 炸了不仅诊断，还尝试自动修复。当然这是高风险操作，作者明确标注了 L2 谨慎级别，让它先修，修完了你审查。 • 第四个，"依赖自动更新"。每六个小时扫一次项目的依赖文件，发现新版本自动 bump，跑一轮测试，通过了就帮你开一个依赖更新的 PR。 • 第五个，"变更日志起草"。每次发版本，自动扫描从上一个版本到现在的所有合并 PR，按类型分类整理，起草一份完整的 changelog。这个功能我从第一天就盯上了，以后再也不用在发版前对着几十个合并记录挠头。 • 第六个，"合并后清理"。PR 合进主分支之后，自动清理对应的开发分支、更新关联的 Issue 状态、把相关文档标注为已处理。这些都是你每次合完代码之后手动做的碎活，循环帮你做了。 • 第七个，"Issue 分流"。自动给新开的 Issue 打标签、分优先级、判断类型。它不是简单的关键词匹配，而是读一遍 Issue 内容再决定该归到哪个类别。 而且这七个模式，每一个都配了脚手架命令，你只需要跑一条 npx loop init，它就帮你在项目里生成好骨架文件和完整配置。 搞完之后再跑一下 loop audit，它自动扫描你的项目环境，有没有未关闭的 PR、CI 是否稳定、工作空间是否干净，然后给你一个准备度评分。 评分不够的项目强行跑循环是危险的，它会提醒你先处理前置问题。 还有一个工具叫 loop cost，你在部署之前先跑一下，它会根据你选的模式和频率估算 token 消耗，这样，起码你心里会有个数。