# 策展 · X (Twitter) 🔥🔥🔥🔥

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

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

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

## 中文摘要

# Loop Engineering 實戰

> 我不再 prompt Claude 了。我有一套 loops 在運行，它們會 prompt Claude，並決定接下來做什麼。我的工作是寫 loops。

在上一篇文章中，我們了解到什麼是 Loop Engineering，今天，我們來看下如何將 Loop Engineering 應用到實際工作中。

## 從 Harness 到 Loop：差在哪裡

我之前寫過 Harness Engineering（建構讓 AI 可靠工作的執行環境）。如果你沒看過，一句話補課：

> Harness 是為單個 Agent 搭舞台；Loop 是讓整齣戲自己演下去。

Harness 解決「一次做對」，Loop 解決「持續做對」。

Harness 是靜態的——規則、文件、檢查項目在那兒等 Agent 來用。

Loop 是動態的——它自己發現工作、分發工作、檢查工作、記錄進度，然後決定下一步做什麼。

![此圖展示了「Harness」與「Loop」兩種流程邏輯的視覺化示意圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0f94d1c1247c3724.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面分為左右兩個區塊，背景為深色格線風格。
左側標題為「Harness」，下方圖示為一個包含播放按鈕圖示的方形，向下延伸箭頭連接至一個圓形節點。
右側標題為「Loop」，下方圖示為一個圓形循環路徑，由四個圓形節點與連接它們的箭頭組成，呈現閉環結構。</div></details>

| | Harness | Loop |
|---|---|---|
| 觸發方式 | 你手動啟動 | 按時間 / 事件自動觸發 |
| 執行週期 | 單次對話 | 持續執行，跨對話 |
| 狀態管理 | 在 context 裡 | 在磁碟上（檔案/看板） |
| 你的角色 | 操作者 | 設計者 |

一個真正能跑起來的 Loop，需要五樣東西 + 一個記憶層：

| 建構塊 | 一句話 | 核心機制 |
|--------|--------|----------|
| **Automations** | 讓它自己動起來 | `/loop`、`cron`、`hooks`、GitHub Actions——給 Loop 一個節奏 |
| **Worktrees** | 讓並行 Agent 不打架 | 每個 Agent 獨立分支 + 目錄，共享 repo 歷史，互不干擾 |
| **Skills** | 讓 Agent 不靠猜 | 寫一次專案約定（`CLAUDE.md`、`me.md`），每次執行都複利 |
| **Connectors (MCP)** | 讓 Loop 連接真實世界 | 讀 issue、查 DB、呼叫 API、發 Slack——Agent 自己開 PR 而不是只給建議 |
| **Sub-agents** | 讓「寫的人」和「查的人」分開 | Maker ≠ Checker；獨立 verifier 是你能放心走開的唯一原因 |
| **Memory** | Loop 的脊椎 | markdown / Linear board / state file——跨對話記住「做了什麼、還剩什麼」 |

## 實戰案例：知識編譯 Loop

我有一個個人知識庫，它的核心就是一條 Loop：

![這是一張以霓虹藍色線條呈現的流程圖，描繪了從郵件接收到使用者互動的自動化處理程序。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/37f3ea58380bcead.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為深藍色背景，上方有一系列以霓虹藍色發光線條繪製的圖示，並由箭頭串聯成一個循環流程。圖示依序為：
1. 信封（代表郵件/訊息輸入）
2. 漏斗（代表過濾或篩選機制）
3. 文件堆疊（代表資料處理）
4. 齒輪（代表系統設定或自動化執行）
5. 開啟的書本（代表知識庫或參考資料）
6. 鈴鐺（代表通知或提醒）
7. 人物輪廓（代表最終使用者）

箭頭指示了從左至右的處理路徑，並有一條長箭頭從右側的人物輪廓回連至左側的信封，象徵流程的循環與持續性。畫面中無任何文字內容。</div></details>

![這是一張展示個人知識管理與資訊流處理流程的邏輯架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d91e0725fd0d3b8d.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表以文字流程圖形式呈現資訊處理的循環路徑，包含以下步驟：
1. 資訊來源：透過「RSS/Twitter 自動抓取」以及「我的行動產生新素材」匯入至「inbox/」。
2. 處理流程：
   - 「inbox/」經由「/triage 過濾」進入「raw/」。
   - 「raw/」經由「/compile 編譯」進入「wiki/」。
   - 「wiki/」經由「/briefing 推送洞見」最終傳遞給「我」。
3. 循環機制：流程末端設有反饋迴路，將產出的內容重新回饋至資訊抓取階段。</div></details>

拆開看五個建構塊怎麼落地的：

| 建構塊 | 我的實現 |
|--------|----------|
| Automation | 每天 6:03 自動觸發 briefing；RSS 和 Twitter 定時抓取進 inbox |
| Worktree | 編譯時用獨立 worktree，避免和我正在編輯的檔案衝突 |
| Skills | `/triage`、`/compile`、`/briefing` 各是一個 Skill，包含完整執行邏輯 |
| Connectors | Twitter fetch、RSS fetch 透過 MCP/腳本接入外部資料源 |
| Sub-agents | compile 時用獨立 agent 做「漣漪更新」檢查，避免主 agent 自己判斷是否需要更新 |
| Memory | `wiki/_changelog.md` + `raw/_registry.md` 作為跨對話狀態 |

兩個月跑下來的資料：

- 自動過濾了 200+ 篇 inbox 素材，真正進入 raw/ 的不到 30%

- wiki 從 0 編譯到 50+ 概念條目，全部由 AI 寫和維護

- 每天早上收到 briefing，平均喚醒 2-3 個我已經忘了的知識連結

關鍵體感：我沒有「管理」這個系統。我只是每天早上花 3 分鐘看 briefing，偶爾手動扔一篇文章進 inbox。Loop 自己在轉。

## 三個設計 Loop 的實操原則

先跑最小 Loop，再加層

不要一上來就搭五層全家桶。

我的第一版 Loop 只有：一個 cron + 一個 skill + 一個 markdown 檔案當 memory。

跑了一週確認基本邏輯對了，再加 sub-agent 做品質檢查，再加 connector 接資料源。

Loop 是迭代長出來的，不是一次設計出來的。

Maker 和 Checker 必須分開

這是最反直覺但最重要的一條。

我早期讓 /compile 自己判斷「這次編譯是否需要更新已有條目」——結果它總是說「不用」。

後來拆成兩步：一個 agent 編譯，另一個 agent 拿著新素材去對比所有已有條目。更新率從 5% 跳到 30%。

自檢是無效檢測。

Silent failure 是 Loop 最大的敵人

Loop 在你不看的時候執行。如果它悄悄失敗了，你可能一週後才發現。

我的做法：

- 每次執行寫 _changelog.md，格式可 grep

- briefing 裡有一個「例外」模組，專門報告 Loop 執行中的問題

- 關鍵步驟失敗時發通知，而不是靜默跳過

## 誰該用 Loop，誰不該

先潑盆冷水：Loop 不是所有人都需要的東西。

適合不適合有重複性工作需要持續執行偶爾用 AI 寫個程式你的判斷力已經足夠好，想放大它你還沒想清楚要 AI 做什麼願意投入時間設計系統只想快速拿到一個結果

還有一個更深層的警告：

> 兩個人可以建構完全一樣的 Loop，卻得到截然相反的結果。一個人用它在自己深刻理解的工作上跑得更快。另一個人用它來避免理解工作本身。

Loop 不知道這兩者的區別。但你知道。

如果你對自己領域的判斷力不夠，Loop 只會幫你更快地犯錯。

## 從今天開始的最小行動

如果你想試試 Loop Engineering，不需要搭一個完整系統。從這三步開始：

第一步：找一個你每天/每週重複做的 AI 任務。

比如：review PR、整理筆記、掃描新聞、檢查程式碼品質。

第二步：把它寫成一個 Skill 檔案。

不是 prompt，是 Skill——包含執行邏輯、輸入輸出規範、專案上下文。寫一次，永久複用。

第三步：給它加一個觸發器。

哪怕只是一個 cron job，讓它每天自己跑一次。

恭喜，你有了第一個 Loop。

剩下的——sub-agent 驗證、worktree 隔離、memory 持久化——等你覺得 Loop 不夠可靠的時候再加。

## 最後

從 Prompt Engineering 到 Context Engineering 到 Harness Engineering，再到 Loop Engineering——每一次演化，人的角色都在後退一步。

但「後退」不是「消失」。

你從「寫 prompt 的操作者」變成「設計系統的架構師」。

你的判斷力、品味、對品質的要求——這些東西不是被替代了，而是被放大了。

Loop 是放大器。放大好的判斷，也放大壞的判斷。

所以這件事比 prompt engineering 更難，而不是更簡單。

槓桿點移動了。建構你的 Loop——但要像一個仍然打算做 engineer 的人那樣去建構它。

## 標籤

Loop Engineering, Agent, 教學資源, 自動化, Claude, Anthropic