99% 的人都在用錯 /goal 和迴圈。
他們聽到的 hype 是「長時間運行的迴圈驅動自主 Agent」：把任務丟給它，然後走開，回來時就能拿到可以運作的程式碼。
但頂尖的 Agent 工程師早在六個月前（也就是 GPT-5.2 和 Opus 4.5 問世時）就已經在這樣做了，而且完全不需要 /goal。這種方法叫做工具工程 + 規格驅動開發：
- 為 Agent 建立一個工具，讓它可以觀察問題
- 撰寫一份包含所有測試案例的嚴謹規格
- 讓 Codex 或 Claude Code 在無人在場的情況下反覆迴圈，直到通過每一項測試
我經常在睡前啟動這些任務——每次執行大概 2-5 小時。四月有一次，它就在我睡覺時，解決了我們 Vercel 單一儲存庫裡的一個 Turbo 建置快取錯誤，早上起來時所有測試都通過了。實際上完全不需要 /goal。
那麼 /goal 到底是做什麼用的？
來看看當我不在的時候，僅僅一個提示詞能做到什麼：
- 耗時約 30 小時，寫了 6300 行程式碼，爬取了 92000 頁面，API 花費 40 美元
- 複製了另一個產品的核心迴圈——從頭開始逆向工程了整個架構
- 我們版本的輸出在相同查詢上，效果比參考產品好了大約 50 倍。（這是一個新的資料層，將為 newsjack.sh 提供動力——這是我一直在開發的開源情報技能專案）
秘訣在於損失函數開發（LFD）：你寫給 Agent 的不是要建構的規格書，而是一個要最佳化的目標。
這就是 Peter 那則推文的具體實作範例。
在規格驅動開發中使用的規格，現在變成了起點，不再是終點線。
我花了一些實驗才把這個方法搞對。但這裡是完整的劇本——不過我們得先說明一開始有多慘烈，你才會知道該如何設計這些 /goal。
這個 Agent 作弊了三次。
一切從我慣用的做法開始：一份規格書。
我只是把 Codex 指向另一個產品的公開網站——「我們要如何自己打造這個？」。30 分鐘內，它就回傳了一份完整的系統設計和測試案例——這就是那份規格書。
但這次，我嘗試了一個不同的提示詞。
/goal 持續執行，直到你的輸出與他們的完全一致
然後，事情是這樣發生的：
迴圈 1（5 分鐘）
這個 Agent 抓取了評估集，產生了與它完全相同的種子資料，然後在五分鐘內就宣告勝利。
「100% 召回率，零通用性」——一個只能找到我給它的 30 個東西的搜尋引擎，哈哈。
修正 → 讓它瞎掉。 在執行期間隱藏評估集，只在評分時才揭露，並且附上每個項目的遺漏列表。
迴圈 2（20 分鐘） - 盲目模式，30 個項目。
我讓 Agent 看不到評估集，但它反而從「遺漏」中學習——每個「你沒找到 X」的訊息，在下一個循環中都變成了一個關鍵字。幾個循環下來：它恰好使用了 30 個關鍵字，每個項目一個，然後它又「贏了」。
修正 → 擴大評估集。 用數百個項目來評分，多到它無法一一列舉。
迴圈 3（30 分鐘） - 盲目模式，200 個項目。
在新的評估集中加入了 200 個項目後，這個 Agent 又作弊了。
有趣的是，這次 Agent 還是逐一列舉了。關鍵字列表膨脹到數百個，每個詞都像一個精準的誘餌，去捕捉下一個遺漏的項目。
三輪，三次作弊。
就在那時我恍然大悟：這個 Agent 只是在單純地最佳化。
作弊不是 Agent 的 bug。這是我目標的 bug：我告訴它要去哪裡，卻讓每一條捷徑都敞開著。
你沒有封鎖的每一條廉價路徑，都是這個最佳化器會狂奔而去的方向。而我最初的目標，完全跳過了所有的圍欄。
迴圈 4（30 小時） - 盲目模式，200 個項目，加上嚴格限制。
所以我開始阻止這些方向。限制關鍵字列表大小、讓評估集不可見、擴大日期範圍——每個修正都堵住了一條廉價路徑，直到唯一能讓分數提升的方向，就是真正把任務做得更好。
它停止作弊了。
然後，它就開始運作。大約 30 小時的運算，爬取了 92000 頁面，花了約 40 美元的代幣費用，產出 6300 行程式碼。
結果發現，我們參考的那個產品只是地板，而不是天花板：我們最終在同樣的查詢上，呈現了大約 50 倍的結果。
（對於好奇的人，這裡有完整的旅程和收據）
損失函數開發（LFD）- 一個好的損失函數的結構
當大多數人嘗試打造一個產品時，他們使用 Agent 來在幾小時內從零到出貨。
但問題在於之後發生的事——那條長尾。 規格書從未想像過的邊界案例，只會在生產環境中逐一透過錯誤日誌浮現。你一個一個地修復它們。那些你沒在日誌中捕捉到的案例，會被使用者回報，而這是發現 bug 最昂貴的方式。
我已經自動化了這個比較便宜的部分。我的 OpenClaw Agent Zoe 每天監控錯誤日誌，並在新的錯誤發生時，自動派生出 Codex 來建立 PR——這個循環差不多就是這麼緊密。（完整的設定記錄在這裡）
但那條長尾仍然需要數個月。這就是為什麼即使有 Agent 幫忙工作，打造一個好產品仍然需要時間。
LFD 將這條長尾快速向前推進。如果你能在前期就拿到真實的預期輸出範例——也就是「好的結果」長什麼樣子，而且要有足夠的規模——你就可以在出貨之前進行壓力測試：數百個邊界案例在單一最佳化運行中一次撞擊 Agent，而不是透過一個季度一個季度的 bug 回報點滴累積。而這件事之所以突然變得可行，是因為對於越來越多的問題來說，這些範例就只是公開地擺在那裡。
規格驅動開發：
建構這個。讓測試通過。
損失函數開發：
建構這個。讓測試通過。然後根據這 1000 個評估案例進行迭代。
一個測試套件是有限的——一旦全部變成綠色就結束了。一個 1000 個案例、目標 95% 的評估，則是一個你向下逼近的目標；在達到門檻之前沒有出口。這很重要，因為 Agent 會做出數百個你永遠不會看到的決策，而每一個決策都會根據某個目標來解決。如果你沒有寫下目標，Agent 就會自己選一個——正如第 1 到 3 輪所顯示的，它會選那個最容易滿足的。
損失函數比評估集更大。它包含四個部分：目標、限制、工具，以及強制熵。四個部分。
1. 目標
- 要大，讓列舉不划算。 一個 28 個項目的評估集在一輪內就被記住了。越大越好。
- 讓 Agent 看不到答案。 評估資料只存在於事後評分。如果 Agent 在執行期間可以看到答案，它就會想辦法去看。
2. 限制
Agent 被允許做什麼，以及不允許做什麼。
- 時間是 Agent 永遠會忘記的限制。 Agent 沒有時間觀念。它們會為了 2% 的改進而耗費 10 小時，因為指標名義上仍在變動。但一個 2 小時內達到 80% 解決方案的成果，勝過一個 30 天內達成的 100% 解決方案。解決方案：設定一個真實時間的預算。
- 金錢。 對每一個付費呼叫設定硬性上限：爬蟲額度、LLM 花費、一個用完即丟的 API 金鑰的總金額上限。
- 範圍。 所有的供應商、允許的模型、並發上限。將 Agent 限制在你希望它接觸的事物上。
- 方法論。 是否允許 LLM 分析，還是只能使用確定性邏輯？Agent 可以存取哪些資料來源？都要明確說明。
3. 工具（也就是那個工具框架）
一個沒有工具的限制只是一個氛圍——Agent 會樂呵呵地違反它，因為它無法判斷自己正在違反。針對上述每一項限制，提供一個 CLI 命令讓 Agent 可以檢查它。
- 目標測量，要有正確的解析度。 小心選擇目標測量工具。一個真實案例：一個幼稚的「讓 LLM 評分兩個截圖」的評判者，會批准有著 12 像素間距誤差的 UI 複製品，因為 LLM 其實看不到那些圖片，它把它們轉換成向量嵌入然後比較向量嵌入。所以，如果你想要像素完美的 UI 複製品，給你的 Agent 一個像素差異比對工具。然後 /goal 持續執行，直到像素差異為 0。
- 時間記錄。 記錄每一次運行和每一步的時間戳。Agent 應該知道每一步花了多久，以及總共的真實時間。時間是一個首要的工具，而不是一個註腳。
- 供應商預算。 「我們現在在爬蟲上燒了多少錢？」應該是一個命令查得到的事，而不是靠猜測。追蹤剩餘的爬取額度、本次循環的花費、累積花費，以及下一次付費批次前的預估花費。
- LLM 花費。 提供 LLM API 金鑰給 Agent 在資料層中使用，可以簡化很多邏輯。但 Agent 應該要有責任地花費，而首要條件就是知道它實際上花了多少。
- Codex 使用量。這部分有點後設。這個循環應該要有自我意識：我花了多少代幣在這次最佳化上？這有助於了解當前最佳化步驟的梯度。
模式就是那句老話：你無法最佳化你看不見的東西。
如果你是新手上路，不要啟動它然後就走開。坐下來觀看第一個循環。觀察它觸碰了什麼。確認你建立的那個工具框架是否真的有被正確使用。然後，再去睡覺。（並且試著在睡著前不要去想醒來會看到什麼。）
4. 強制熵
為什麼強制熵很重要：每個循環都從前一次執行的完整上下文繼續。模型不是從頭開始——它正在讀取自己過去一百個決策以及目前為止有效的梯度。
在 /goal 循環中，陷入局部最佳化是預設狀態。 如果沒有明確的驅動，Agent 會持續爬上同一座山丘，而「同一座山丘」就是它停止進步時所在的任何位置。
例如，如果一個小旋鈕能將結果改善 0.1%，Agent 就會一直轉那個旋鈕，即使它還有 1000 個其他旋鈕可以嘗試。
熵必須被明確地強制注入到運行中，因為模型不會自行這麼做：
- 每個循環都進行過度擬合反思。 我正在建立一個更通用的解決方案，還是在背誦評估集？ 如果是在背誦，下一次變更必須移除一個評估形狀的人為產物（限制列表大小、遮蔽某個功能、擴大評估集、拒絕某個種子資料），而不是增加一個。
- 在停滯時強制注入熵。 如果上一個循環沒有讓指標進步，下一個循環不能只是「同樣的想法，更加努力」。模型必須做出一個真正的、非顯而易見的跳躍——「跳出框架思考」是一個很好的提示——這可以阻止 Agent 只是更用力地轉同一個旋鈕。
- 保留迭代日誌。 讓 Agent 記錄每次迭代的假設、預期的失敗模式、每一步的診斷資訊，這樣它就可以在後續壓縮時回頭反思。
後設-後設提示詞
我本來是自己撰寫這些目標，但很快就發現這也應該是 Agent 的工作。
所以我寫了一個技能，來為一個好的損失函數開發運行產生這類目標。
現在已在此開源：
https://github.com/elvisun/loss-function-development
/lfd-design 用來產生工具框架和目標
一路向下都是梯度下降：兩個迴圈
退一步看，這一路向下都是梯度下降。
內部迴圈是 Agent：撰寫程式碼、執行測試、修正。短視野、快速回饋、一個目標——讓測試通過。這就是開發者的內部迴圈，而規格驅動開發就是執行它的方式。編碼 Agent 已經將其自動化了。
外部迴圈是 /goal：驅動整個系統跨越多個循環朝向一個結果指標邁進——出貨、衡量、改變策略、向下逼近。長視野、稀疏回饋。這傳統上是產品團隊的循環，將數個月的出貨-衡量-迭代壓力測試壓縮成一次執行。
現在兩個迴圈都自動化了。留給你的工作，就是定義損失函數——/goal 應該要精確地朝什麼目標最佳化，以及用什麼方式。
你正在蒸餾一個產品——或任何留下公開產出物的東西
另一個觀點：這本質上就是蒸餾，從訓練階段轉移到了提示階段。這就是 DeepSeek、Kimi、Minimax 這條產品線縮小與 GPT 和 Claude 之間大部分差距的方法——用別人的輸出訓練你的模型，直到你的模型能複製出這些輸出。
但現在，你不需要蒸餾一個模型；你可以使用 /goal 和 LFD 來對任何公開可發現的產出物進行蒸餾擬合——它完全不需要檢查內部結構。
強調一下公開這個詞。蒸餾那些受使用條款保護、需要登入、或付費才能取得的產出是不正當的。但是，那些公開發表的東西——一家公司為了贏得客戶而發布的產出——一直以來都是可以學習的。這部分並不新鮮——這是軟體產業最古老的手法。新鮮的是，現在它變得很便宜，而且可以在幾小時內完成，而不是幾個月。
退一步看，這裡有更大的轉變。只要存在資訊對稱——當產出是公開的，每個人都能看到「好」的標準——執行成本就會暴跌至接近 0 美元，任何人都可以在一個週末花 40 美元把它蒸餾出來。
所以，一個新的護城河正在變得越來越有價值：資訊不對稱。
典型的開源公司已經率先做出了反應。2026 年四月，cal.com（年營收 500 萬美元）將其生產程式碼設為私有並轉為閉源。他們給出的理由讀起來簡直就是這篇文章的摘要：在 AI 驅動的安全威脅時代，你不能把你的原始碼留在 Agent 可以讀取的地方。
/goal 讀取 cal.com 的原始碼，並枚舉其攻擊面，直到有東西起作用
這是一個極度危險且極易執行的攻擊。
一家整個身份認同都是「開源」的公司，在 2026 年決定開放性已經成為一種負債。這應該說明了一切。
在整個軟體歷史中，「我們建構了它」就是護城河。
那個時代正在結束。
下一個時代屬於掌握那些產出物從未包含的東西的人：沒有人能與之競評的評估集。你的使用者真正會踩到的邊界案例清單。你私下衡量的真實數據。誰擁有競爭對手的 Agent 看不到的目標，誰的循環就能持續向下逼近。
產品現在只需要一個週末就能做出來了。
去建立一個週末觸及不到的評估集吧。
