# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：老金 (@freeman1266) · 平台：X (Twitter) · 日期：2026-06-11

> 原始來源：https://x.com/freeman1266/status/2064702757773496552

## 中文摘要

# 什麼是 Loop Engineering

Claude Code 的 Boris Cherny 最近在紅杉資本 AI Ascent 2026 大會上說了一句話：「我不再提示 Claude 了。我有執行中的循環在提示 Claude，並決定接下來做什麼。我的工作是寫循環。」

他一天提交 150 個 PR，全程用手機完成，沒有親手寫過一行程式碼。

這不是在炫耀產量，他想說的是，寫程式這件事的入口，已經不在 Prompt 上了。

## Loop Engineering 亮相

過去一年，從 AI 程式開發工具那裡拿結果的方式都一樣：你寫一個提示詞，餵夠上下文，等它輸出，讀返回的內容，再寫下一條。Agent 是個工具，你始終握在手裡，一輪接一輪。

如果你還採用這種方式，就已經落後了。

現在的做法是：你搭一個小系統，讓它去發現工作、分發工作、檢驗結果、記錄進度、決定下一步。由小系統去呼叫 Agent，你不再親自上手。

這就是 Loop Engineering（循環工程）。

Google Chrome 工程總監 Addy Osmani 的說法更直白：Loop Engineering 就是把你從「提示 Agent 的那個人」的位置上挪開，改成設計一個系統替你幹這件事。

說到底，循環就是一個遞迴目標——你定義要什麼，AI 自己迭代到完成為止。

## 一個循環需要什麼

循環大致由五塊東西拼起來，Claude Code 和 Codex 現在都湊齊了。

![這是一張以霓虹藍色調呈現的科技概念圖，展示了一個循環流程與周邊數據處理節點的系統架構。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1c990a5e0251d747.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面中央是一個由箭頭組成的循環圓環，圓環上有六個連接點，分別向外連接到不同的圖示，象徵著數據處理、系統監控或軟體開發生命週期（如 DevOps 或 CI/CD）的各個階段。圖示內容包括：
1. 頂部：心電圖/脈衝波形圖（代表監控或即時狀態）。
2. 右上方：資料夾圖示（代表檔案管理或儲存）。
3. 右下方：資料庫圖示（代表數據儲存）。
4. 右下方（較靠近底部）：文件圖示（代表文件或紀錄）。
5. 左下方：插頭圖示（代表連接、API 或整合）。
6. 左側：節點連接圖示（代表網路、關聯或分佈式系統）。
整體畫面採用深藍色網格背景，呈現出數位化、高科技的視覺風格。此圖為演示用的概念圖，無具體文字內容或統計數據。</div></details>

1. 自動化任務——這是心跳

有了它，循環才會自己轉起來，而不是你手動跑過一次就停了。

Claude Code 給了兩個核心原語：

- /loop：按節奏重複跑，用來做週期性檢查

- /goal：一直跑，直到你寫的條件真的成立——每輪跑完，一個獨立的小模型來判斷算不算完成，所以給程式碼打分的不是寫程式碼那個 Agent

/loop 30m /goal All tests in test/auth pass and lint is clean.
Scan src/auth for new failures, propose fixes in claude/auth-fixes,
open draft PR when goal condition holds.

這其實就是循環工程最核心的一招——創作者和檢驗者分開——只不過這回用在了「什麼時候算完成」上。

2. Worktrees——讓並行不變成混亂

只要你同時跑多個 Agent，檔案就開始打架。兩個 Agent 寫同一個檔案，跟兩個工程師不打招呼往同一行程式碼上提交，是一模一樣的麻煩。

git worktree 治的就是這個：各自一個獨立工作目錄，各在自己的分支上，共享同一份倉庫歷史，一個 Agent 的改動碰不到另一個的檢出。

Claude Code 用 --worktree 標誌、子 Agent 上的 isolation: worktree 提供同樣的隔離，每個輔助 Agent 拿一份乾淨的檢出，幹完自動清理。

3. Skills——讓你不必每次重新解釋你的專案

Skills 解決的是這個尷尬：你不用每開一個新會話，就把專案背景從頭講一遍，像得了健忘症。

它就是一個帶 SKILL.md 的資料夾，裡面放指令和元資料，外加可選的腳本、參考資料、asset。

沒有 Skills，循環每一輪都得重新摸清你的專案；寫下來之後，這些認知就攢住了。約定、建構步驟、「這事我們不這麼幹，因為上次出過事故」——寫一次，Agent 每次跑都讀得到。

name: ci-triage
description: 分類 CI 失敗原因（環境/偶發/真實 bug/依賴/基礎設施），
 為簡單問題起草修復方案，其餘升級處理。
 當工作流執行失敗或在晨間分診循環中觸發。

分類規則：

- env：缺金鑰、環境變數錯了 → 人工處理

- flake：重試就過、程式碼沒動 → 重試一次後歸檔

- bug：跟最近提交相關的確定性失敗 → 起草修復

- dependency：跟版本升級相關的失敗 → 起草回滾

4. plugin 與連接器——循環觸及你的真實工具

只能看到檔案系統的循環，是個微型循環。

基於 MCP 的連接器讓 Agent 能讀你的問題追蹤器、查資料庫、呼叫測試 API、往 Slack 發訊息。

「一個能告訴你『這是修復方案』的 Agent」，和「一個能自己開 PR、關聯 Linear 工單、CI 一變綠就在頻道裡吱一聲的循環」，差的就是這一層。

接哪個回報最快，大致是：GitHub → Linear/Jira → Slack → Sentry。

5. 子 Agent——讓創作者遠離檢驗者

循環裡最有用的一個結構性設計，沒有之一：把寫程式碼的和驗程式碼的分開。

![此圖示展示了一個從設計創作到安全驗證的流程概念圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a2a7f8ae35fc1deb.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為一個深藍色背景的流程示意圖，由左至右包含三個主要元素：
1. 左側為一個發光的青色「鋼筆工具」圖示，代表設計或創作過程。
2. 中間為一個虛線框構成的方形，代表處理、轉換或中間步驟。
3. 右側為一個發光的橘黃色「盾牌內含勾選符號」圖示，代表安全、驗證或合規結果。
整體設計採用霓虹發光風格，並以細線框出流程路徑，屬於概念性的演示圖示。</div></details>

寫程式碼的模型給自己的作業打分，手太鬆。換一個指令不同、有時候連模型都不同的第二個 Agent，能逮到第一個 Agent 說服自己忽略掉的問題。

Claude Code 靠 .claude/agents/ 裡的子 Agent、以及在它們之間傳遞工作的 Agent 團隊來做這件事。常見的分工是：

> 探索 Agent → 實現 Agent → 驗證 Agent（對照規格檢驗）

子 Agent 是更燒 token 的，所以把它們用在真正值得第二意見的地方。

## 還有第六樣東西：記憶

一個 Markdown 檔案，或者一塊 Linear 看板，反正是任何活在單次對話之外、記著「幹完了什麼、還剩什麼」的東西。

聽著簡單到不值一提，可每個長時間跑的 Agent 都靠這一招。模型每次重啟都忘光，所以記憶必須落在磁碟上，不能留在上下文裡。Agent 會忘，倉庫不會。

Loop state · ci-triage

上次執行
2026-06-09 03:30 UTC · 7 個失敗已分類，3 個修復已起草，4 個已升級

進行中
· claude/fix-auth-token-refresh — 本地測試通過，等待 CI
· claude/fix-flaky-payment-webhook — 已應用重試模式，監控中

今日完成
· claude/bump-axios-1.7.4 → 已合併（CI 通過）

升級給人工處理
· src/billing/refund.ts — 測試以三種方式失敗，根因不明

經驗教訓（寫在這裡，不寫在聊天裡）
· 2026-06-08: PowerShell 在此 Windows runner 上遇到 TLS 1.2 問題，改用 bash

## 一個循環實際長什麼樣

把這五塊拼到一起，一條對話線就變成了一個小控制台：

每天早上，一個自動化任務在倉庫上跑起來。它的提示詞呼叫分診 Skill，讀昨天的 CI 失敗、開著的 Issue、最近的提交，把發現寫進狀態檔案。

每一條值得處理的發現，循環就開一個隔離的 Worktree，派一個子 Agent 起草修復，再派第二個子 Agent 對照專案 Skills 和現有測試審一遍那份草稿。

連接器讓它能開 PR、能更新工單。循環搞不定的，統統落進分診收件箱，等你。

你做了什麼？你把它設計出來，就一次。中間每一步，你都沒去提示。

## 在你建循環之前，先過這道檢查

不是所有任務都適合做成循環。下面四條都滿足，才值得：

| 條件 | 說明 |
|------|------|
| 任務重複 | 至少每週一次，否則設定成本永遠攤不平 |
| 驗證能自動化 | 有測試、型別檢查、建構或 Linter 能自動判斷對錯 |
| token 預算夠 | 循環要重讀上下文、重試、探索，比單次對話燒得多 |
| Agent 工具齊 | 看得到日誌、跑得了程式碼、看得見執行結果 |

適合做循環：CI 失敗分診、依賴升級 PR、Lint 修復、Issue 轉 PR 草稿。

不適合：架構重寫、鑑權支付這種核心程式碼、生產部署、「做好看點就行」這類要拍腦袋的活。

## 循環幫不了你的三件事

驗證還是你的活。 沒人盯著跑的循環，也是沒人盯著犯錯的循環。它報「完成了」，那是它的說法，不是事實。

理解債會越欠越快。 循環發程式碼越快，你沒親手寫的程式碼就越多，「程式庫裡有什麼」和「你真懂什麼」之間的口子就越大。你要是不讀它產出的東西，這就是在用複利借理解債。

最隱蔽的是認知上的偷懶。 循環自己轉起來之後，人很容易跟著放下判斷，它返回什麼就收什麼。同樣是設計循環，你帶著判斷力去做，它是幫手；你拿它來躲開思考，它就成了幫兇。

## 槓桿點移動了

Boris 想說的不是活變輕鬆了。活沒變輕鬆，只是吃勁的地方挪了位置——從怎麼寫提示詞，挪到了怎麼設計循環。

兩個人搭出一模一樣的循環，結果可能完全相反。一個拿它在自己吃透的活上跑得更快，一個拿它來繞開「吃透」這件事本身。循環分不出這兩者，你分得出。

所以循環設計其實比提示詞工程更難。

## 幾句不太一樣的話

這套敘事很順，順到值得停下來戳幾個洞。

先說那個「一天 150 個 PR、全程用手機」。那是工具作者幹出來的——他腦子裡裝著 Claude Code 的完整心智模型，他跑循環那個倉庫八成也被收拾得乾乾淨淨、專門為循環調過。拿創造者在理想環境裡的吞吐量，去對標你在一個十年祖傳程式碼裡的預期，沒什麼參考價值。真正卡住大多數人的，不是「會不會寫循環」，是「你那個倉庫配不配得上一個循環」。多數企業程式庫的答案，是還不配。

再說工作量。文章一直暗示循環幫你省了事，其實它只是把事挪了個地方。你不寫提示詞了，換成維護 Skills、調連接器、搭驗證腳手架、盯狀態檔案。「你只設計了一次」這話在現實裡從來不成立——Skill 會過期，連接器會斷，驗證條件會被下一個需求繞過去，狀態檔案會跟程式碼慢慢對不上。任務不夠重複、又難自動驗證的團隊，也就是大多數團隊，這套設定成本根本攤不平。你只是把調 prompt 的工時，換成了調 loop 的工時。

「創作者和檢驗者分離」這個設計，我也沒那麼信。問題出在兩邊都是 LLM。第二個 Agent 不是獨立審計員，是個跟第一個高度相關的審計員——同一批訓練資料、同一批盲區、同樣的過度自信。它能挑出低級筆誤，可碰上「整個方向就錯了」這種系統性問題，兩個模型很可能一起點頭放行。讓一個會犯同樣錯的人去 review 另一個會犯同樣錯的人，這不叫品質保證。

驗證這件事本身也得多想一層。能自動跑通，不等於對。一旦停止條件寫成「測試通過、lint 乾淨」，Goodhart 那一套就來了：循環會去找一切讓測試變綠的捷徑——把斷言改鬆、給 mock 注水、拿 try/catch 把例外吞掉。你以為自己在量「程式碼對沒對」，其實量的是「檢查器閉沒閉嘴」。條件越機械，循環越擅長在不解決問題的前提下把它滿足掉。

最彆扭的一點：真正值錢的工程，恰好是循環幹不了的那部分。判斷、架構、在一堆爛選項裡做權衡——這些循環自己都明說排除掉了。於是它替你把那點雜活工業化了，副產品是一堆等著人來 review 的低價值 PR。寫程式碼的速度一旦超過讀程式碼的速度，瓶頸就從「寫」挪到了「讀」，而 review 的人手不會因為你建了個循環就自動多出來。最後你多半不是更快了，是被自己循環吐出來的合併佇列淹了。

循環是好東西，但它只獎勵已經想明白的人。指望它替你想，它會很樂意帶著你一起想錯。

## 標籤

Loop Engineering, Agent, Claude Code, 產業趨勢, Anthropic, Claude, Loop Engineering