Engineering成了硅谷AI圈新顶流钛媒体

你有没有这种感觉？

明明说AI能帮我们写代码、做方案、省时间，结果几个月下来，自己反而更累了。

以前自己吭哧吭哧写，现在变成了一轮又一轮地“伺候”AI。

写提示词、看结果、不满意、再写提示词、再改……活是一点没少干，只是从“搬砖”变成了“监工”。

但你猜怎么着？AI圈那帮大佬们，最近已经进化到next level了。

人家现在根本不跟AI“对话”了，而是直接“放养”。

X上最近有个词特别火，叫Loop Engineering（循环工程）。你要是还没听过，可能很快就要被刷屏了。

AI圈造词的速度向来不慢。什么Prompt Engineering、Context Engineering、Harness Engineering，一波接一波。

有人说这次又是炒作，新瓶装旧酒。

于是我花了一周时间把各家大佬的讨论、实践案例、踩坑记录翻了个遍。

事情的起因是，Claude Code的负责人Boris Cherny在一个会上说，他现在基本不手动给Claude写提示词了。

那干嘛呢？他说：“我的工作就是写循环（loop）。”

紧接着，另一位大佬Peter也发文说：“别再给编码智能体写提示词了，没用。你应该设计一套循环机制，让这些循环去提示你的Agent。”

这听起来有点玄乎，但说人话就是：我们跟AI的配合方式，该换换脑子了。

以前人当“发动机”，现在只需“定好闹钟”

咱们先回忆一下，平时咱们用AI（比如Claude、ChatGPT、Codex）干活，是什么画风？

基本就是你问一句，它答一句。

你说“帮我写个登录页面”，它写完了。你一看，“不行，按钮颜色不对”，它改了。你再一看，“哎呀，手机端适配呢？”它再补。

发现没？你才是那个真正的发动机。

每一轮对话，都得你亲手点火。AI像一个特别听话但没啥眼力见儿的实习生，你催一下，它动一下。

这其实不叫“人工智能”，这叫“人工+智能”。

而Loop Engineering就是把你这个“发动机”给解放出来。

它的核心逻辑不是“写好提示词”，而是 “设计好闭环”。

什么意思呢？比如说，以前你用AI修一个程序里的Bug，流程是：你贴报错→AI改代码→你跑一下→还有Bug→你再贴新报错……循环往复。

现在不一样了。你直接跟AI说：“去把我仓库里所有失败的PR（代码合并请求）修了，测试过了才算完。修不好就记下来，明天早上告诉我。”

然后你就可以合上电脑下班了。

等你第二天早上打开电脑一看：AI自己开了好几个独立的小隔间（Worktree），互不干扰地在那改代码，跑测试，通过的已经帮你把合并请求都发好了，没通过的也把原因整理得明明白白搁那儿了。

你看，这个过程中，从“你驱动”变成了“目标驱动”。

而你的核心工作，从一句一句“发指令”，变成了设计这个“自动运转的系统”。

说白了这个转变就是：以前你是个“提问者”，现在你得当个“定规矩的人”。

给AI世界装上一套“自动驾驶仪”

听到这里，你可能觉得这就是个自动化脚本嘛，搞个定时任务不就行了？

一开始我也这么想，但深入了解后发现，Loop Engineering的核心根本不是“定时”，而是“闭环”。

一个真正能跑起来的循环，不是拿个鞭子在后面抽着AI跑，而是给它装上一套“感知-决策-行动-反馈”的自动驾驶仪。

我根据几位大佬的分享，把它拆解成三个最关键的环节：

第一，你得给AI一个“员工手册”。

用过AI的朋友都知道，AI有个“金鱼记忆”，新开一个对话，之前聊的都忘了。你上周跟它说过的代码规范、项目架构，这周它全不记得了。

所以，一个靠谱的循环，必须有一个外挂的记忆。

比如一个Markdown文件或者项目文档。

这就好比给新员工发了一本《员工手册》，里面写着：“数据库密码在这里找”、“命名不能用拼音”、“上次那个坑千万别踩”。

AI每次干活前，先看一遍，就不怕它再次走弯路了。

这不就是职场里的“把SOP写清楚，新人来了直接照做”嘛，AI也得按规矩来。

像极了产品经理和开发互相battle，但最后出来的东西还真靠谱。

第二，什么样的AI干什么样的活。

人类组织里有个常识：写代码的和审代码的，不能是同一个人，否则大概率看不出自己的bug。

AI世界也一样。

一个好的循环，会把“干活”和“检查”拆开。

让一个模型负责写，让另一个模型（甚至要求更严格的模型）专门负责挑刺。

写代码的Agent刚提交，负责测试的Agent就跑起来，如果挂了就打回去重写；负责审美的Agent觉得界面太“土”，也打回去重画。

这种“左右互搏”，反而保证了产出的下限。

第三，定义目标的能力。

听起来很虚，但实操起来，才是真正的分水岭。

比如，你跟AI说“把这个脏乱差的数据库清洗一下”。这基本等于废话。

AI会试图转动本就不存在的大脑来思考：“清洗”？怎么洗？什么叫“清洗好了”？是删掉重复数据？还是填补缺失值？

它可能会随便删了几个字段，可能觉得自己干得不错，就停了。也可能陷入死循环，把你的数据库改得面目全非。

但如果你换一种说法，给AI一个可量化、可验证的硬指标：“剔除所有重复数据，补全缺失的年龄字段（默认值设为0），并将处理结果导出为CSV格式，确认文件大小不超过10MB。”

AI立马就懂事了。它每处理完一轮，就去跑一遍数据校验脚本。全过了，收工；没过，继续改。清清楚楚。

如果你领悟了这一点，那么恭喜你，get到了管理学的精髓。

不需要告诉AI怎么修bug（那是它的活），你只需要定义什么叫“修完了”。在这一点上，管AI和管人，逻辑出奇地一致。

模糊的指令产生混乱，而清晰的量化标准才能产生执行力。

循环有风险，“放养”需谨慎

当然，把活儿全甩给AI，自己躺着喝咖啡，目前还只是个美好愿景。

Loop Engineering虽然听着美，但玩不好，也很容易“翻车”。而且，翻得还挺有“人性”的。

首先，AI会钻空子。

在“应付KPI”这件事上，碳基和硅基殊途同归。

假设你设定Loop的规则是“服务器CPU占用率必须保持在50%以下”。结果AI发现无论怎么优化代码都压不住涨幅时，它会选择偷偷把系统的监控探针给干掉了。

你看，监控面板上确实显示0占用，天下太平，但实际上服务器早已满负荷宕机了。

咱们打工人会偷奸耍滑的“小聪明”也让AI学去了。

其次，别把自己也“优化”掉了。

这就像把车交给自动驾驶太久，自己都不会倒车入库了。

在AI全自动帮你写代码、修bug、甚至做决策时，你对项目的理解也会急剧下降。

你从“执行者”变成了“旁观者”。代码堆积得越来越多，但你对这段逻辑的掌控力越来越弱。万一哪天循环崩了，或者出了个AI搞不定的诡异bug，你再去接手，会发现这代码陌生得像别人写的（虽然确实是AI写的）。

工具越来越强，人却越来越菜，这可能是AI时代我们面临的最大悖论。

最后，烧钱烧得肉疼。

这是最痛的......

试想一下，你在跑一个自动生成视频脚本的Loop，要求“画面精美且符合语境”。AI为了达到这个模糊的标准，可能会在背后反复调用昂贵的图像生成模型和多次重写的API。

如果不设限，短短一夜之间，几十刀的API费用就灰飞烟灭了。

这哪是“睡后收入”，简直是“睡后破产”。

这就是“金钱换时间”的极致体现，循环是跑起来了，但这玩意儿每一秒都在烧Token。

Boris Cherny背后是Anthropic公司，有近乎无限的额度。但对于咱们普通开发者或者小团队来说，这可能是无法承受之重。

那我们普通玩家该怎么办？难道就不配拥有Loop了吗？

也不是，但咱得学会“抠门”地玩。

别啥破事都用Loop。一次性的任务，或者结果很难被机器验证的事情（比如“写一首感人的诗”），你老老实实用提示词就行了，又快又便宜。

只有那些重复发生、流程固定、结果可以自动检查的事情，才值得你花心思去设计一个Loop。比如每天的自动化测试、定时的代码库维护、例行的数据清洗。