@freeman1266：Loop Engineering 實戰 我不再 prompt Claude 了。我有一套 loops 在運行，它們會 prompt Claude，並決定接…

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」，下方圖示為一個圓形循環路徑，由四個圓形節點與連接它們的箭頭組成，呈現閉環結構。 | | 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： 展開畫面重點畫面為深藍色背景，上方有一系列以霓虹藍色發光線條繪製的圖示，並由箭頭串聯成一個循環流程。圖示依序為： 信封（代表郵件/訊息輸入） 漏斗（代表過濾或篩選機制） 文件堆疊（代表資料處理） 齒輪（代表系統設定或自動化執行） 開啟的書本（代表知識庫或參考資料） 鈴鐺（代表通知或提醒） 人物輪廓（代表最終使用者） 箭頭指示了從左至右的處理路徑，並有一條長箭頭從右側的人物輪廓回連至左側的信封，象徵流程的循環與持續性。畫面中無任何文字內容。 展開畫面重點該圖表以文字流程圖形式呈現資訊處理的循環路徑，包含以下步驟： 資訊來源：透過「RSS/Twitter 自動抓取」以及「我的行動產生新素材」匯入至「inbox/」。 處理流程： - 「inbox/」經由「/triage 過濾」進入「raw/」。 - 「raw/」經由「/compile 編譯」進入「wiki/」。 - 「wiki/」經由「/briefing 推送洞見」最終傳遞給「我」。 循環機制：流程末端設有反饋迴路，將產出的內容重新回饋至資訊抓取階段。 拆開看五個建構塊怎麼落地的： | 建構塊 | 我的實現 | |--------|----------| | 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 是放大器。放大好的判斷，也放大壞的判斷。…