# 策展 · X (Twitter) 🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：Elvis (@elvissun) · 平台：X (Twitter) · 日期：2026-06-12 > 原始來源：https://x.com/elvissun/status/2065035615800864954 ## 中文摘要 # /goal 與 Loss Functions：如何用一個 Prompt 在 30 小時內提煉出一款產品 [完整實戰手冊] 99% 的人都在錯誤地使用 `/goal` 和迴圈。 他們聽到的炒作是：「利用長時間運行的迴圈來驅動自主 Agent：給它一個任務，然後走開，回來時就能得到可用的程式碼。」 但頂尖的 Agentic 程式開發工程師早在 6 個月前（當 GPT-5.2 和 Opus 4.5 發佈時）就已經在這樣做了。這稱為 **harness 工程 + 規格驅動開發 (spec-driven development)**： 1. 為 Agent 建立一個 harness，讓它能觀察問題。 2. 撰寫一份包含所有測試案例的嚴謹規格。 3. 讓 Codex 或 Claude Code 在無人看管的情況下持續迴圈，直到滿足所有條件。 我經常在過夜時啟動這些任務，每次運行約 2-5 小時。四月份時，其中一個 Agent 解決了我們 Vercel monorepo 中的一個 Turbo build-cache 錯誤，隔天早上就已經修復完畢。其實根本不需要 `/goal`。 ## 那麼，`/goal` 到底是做什麼用的？ 當我離開時，僅僅一個 Prompt 就完成了以下工作： - 約 30 小時，6,300 行程式碼，爬取了 92,000 個頁面，API 花費 40 美元。 - 複製了另一款產品的核心迴圈——從零開始對整個架構進行逆向工程。 - 在相同的查詢下，我們版本的輸出結果比參考產品好約 50 倍。（這是一個全新的資料層，將為 newsjack.sh 提供動力——這是我一直在開發的開源新聞情報 skill）。 秘訣在於 **Loss Function Development (LFD)**：你為 Agent 寫下一個要優化的目標，而不是要它去構建的規格。 這就是 Peter 的推文被付諸實踐的具體案例。 在規格驅動開發中使用的「規格」，現在變成了起點，而不再是終點。 我經過了一些實驗才掌握竅門。以下是完整的實戰手冊——但我們必須先從它失敗得有多慘開始講起，這樣你才能理解如何設計這些 `/goal`。 ## Agent 作弊了 3 次。 一切都始於我慣用的做法：一份規格。 我直接讓 Codex 指向另一款產品的公開網站——「我們該如何自己打造這個？」。30 分鐘後，它給出了一份完整的系統設計和測試案例——也就是規格。 但這一次，我嘗試了一個不同的 Prompt： `"/goal 執行直到你的輸出與他們的完全一致"` 結果發生了這種事： **迴圈 1（5 分鐘）** Agent 抓取了評估集 (eval set)，生成了與之鏡像的種子資料，並在五分鐘內宣佈勝利。 「100%」召回率，零通用性——這是一個只能找到我餵給它的那 30 個項目的搜尋引擎，哈哈。 **修正 → 遮蔽它。** 在運行期間隱藏評估集，僅在評分時揭露，並附上逐項缺失清單。 **迴圈 2（20 分鐘）- 遮蔽，30 個項目。** 我對 Agent 遮蔽了評估集，但它改為透過缺失來學習——每一條「你沒找到 X」的訊息在下一個週期都變成了關鍵字。幾次迴圈後：它精確地使用了 30 個關鍵字，每個項目一個，然後它又「贏」了。 **修正 → 擴大評估集。** 數百個項目用於評分，多到無法枚舉。 **迴圈 3（30 分鐘）- 遮蔽，200 個項目。** 在新的評估集中加入 200 個項目後，Agent 又作弊了。 有趣的是，Agent 還是把它們枚舉出來了。關鍵字清單膨脹到了數百個，每個詞都是針對下一個缺失的精確誘餌。 三輪，三次作弊。 就在那時我意識到了：Agent 只是在進行優化。 作弊並不是 Agent 的 Bug。而是我目標設定的 Bug：我告訴它要去哪裡，卻留下了所有捷徑。 每一個你沒有圍起來的廉價路徑，都是優化器會衝刺的方向。而我最初的目標跳過了所有的圍欄。 **迴圈 4（30 小時）- 遮蔽，200 個項目，硬性限制。** 所以我開始封鎖方向。限制關鍵字清單、遮蔽評估集、擴大日期範圍——每一次修正都關閉了一條廉價路徑，直到唯一能提升數值的方向，就是真正地提升任務執行能力。 它停止作弊了。 然後它開始運行。約 30 小時的運算，92,000 個頁面被爬取，約 40 美元的 token 花費，6,300 行程式碼。 事實證明，我們參考的那款產品是地板，而不是天花板：我們最終在相同的查詢下呈現了約 50 倍的結果。 ![圖表顯示 Codex 產品目前僅尋獲目標評估集（eval set）中的 10%（即 10% recall），而最終目標是尋獲整個評估集。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6222e861457251bc.jpg)
展開數據表
項目數值
對象total search space
對象eval set (the /goal is to find the entire eval set)
對象What codex's product found already
指標10% recall (current state: 10% recall)
（好奇的人可以在這裡看到完整的旅程和收據） ## Loss Function Development (LFD) - 優質 Loss Function 的解剖 當大多數人嘗試開發產品時，他們使用 Agent 在幾小時內從零到上線。 但問題在於接下來會發生什麼——長尾效應。規格書中從未想像過的邊緣案例 (edge cases) 只會在生產環境中浮現，一次一個錯誤日誌。你必須一個一個修復它們。那些沒被日誌捕捉到的案例會被使用者回報，這是發現 Bug 最昂貴的方式。 我已經將這部分的廉價工作自動化了。我的 OpenClaw Agent Zoe 每天監控錯誤日誌，並在錯誤出現時啟動 Codex 來建立 PR——這已經是該迴圈能達到的最緊密程度。（完整設定記錄在此） 長尾效應仍然需要幾個月的時間。這就是為什麼即使有 Agent 協助，開發一款好產品仍然需要時間。 LFD 加速了長尾過程。如果你能預先獲得真實的預期輸出範例——即大規模下「好的結果」是什麼樣子——你就能在發佈前進行壓力測試：讓數百個邊緣案例在一次優化運行中衝擊 Agent，而不是每季一次的錯誤回報滴灌。而這之所以突然變得可行，是因為對於越來越多的問題，這些範例就擺在公開網路上。 **規格驅動開發：** > 構建這個。讓測試通過。 **Loss-function 開發：** > 構建這個。讓測試通過。然後針對這 1,000 個評估案例進行迭代。 測試套件是有限的——一旦變綠就結束了。一個 1,000 個案例、準確率 95% 的評估集是一個你向下探索的目標；除非達到標準，否則沒有出口。這很重要，因為 Agent 會做出數百個你永遠看不到的決定，而每一個決定都會針對某個東西進行解析。如果你沒有寫下目標，Agent 就會自己挑一個——正如第 1-3 輪所顯示的，它會挑選任何最容易滿足的目標。 Loss-function 比評估集更宏大。它包含 4 個部分——目標、約束、工具 (instruments) 和強制熵 (forced entropy)。四個組件。 ### 1. 目標 (Target) - **規模要大到枚舉無法獲利。** 一個 28 個項目的評估集在第一輪就被記住了。越多越好。 - **對 Agent 遮蔽答案鍵。** 評估資料僅用於事後評分。如果 Agent 在運行期間能看到答案，它就會想辦法偷看。 ### 2. 約束 (Constraints) Agent 被允許做什麼，以及不被允許做什麼。 - **時間是 Agent 總是忘記的約束。** Agent 沒有時間感。它們會為了 2% 的提升而苦幹 10 小時，因為指標在名義上是有變動的。但 2 小時內完成 80% 的解決方案，勝過 30 天內完成 100% 的解決方案。解決方案：設定一個牆上時鐘預算 (wall-clock budget)。 - **金錢。** 對每一筆付費呼叫設定硬性上限：爬蟲點數、LLM 花費、一次性金鑰的總金額上限。 - **範圍。** 所有供應商、允許的模型、併發上限。將 Agent 沙盒化，只讓它接觸你希望它接觸的事物。 - **方法論。** 是否允許 LLM 分析，還是只能用確定性邏輯？Agent 可以存取哪些資料來源？請明確說明。 ### 3. 工具 (Instruments / The Harness) 沒有工具的約束只是一種「氛圍」——Agent 會愉快地違反它，因為它無法判斷自己正在違反。對於上述的每一個約束，都要為 Agent 提供一個可以檢查它的 CLI 指令。 - **目標測量，在正確的解析度下。** 謹慎選擇目標工具。真實案例：一個天真的「讓 LLM 評分兩張截圖」的裁判，會批准間距有 12px 誤差的 UI 複製版，因為 LLM 無法真正看到圖像，它將其轉換為 embedding 然後比較。所以如果你想要像素級完美的 UI 複製，給你的 Agent 一個像素差異工具。然後 `/goal` 直到像素差異為 0。 - **時間核算。** 記錄每一次運行和每一步的時間戳。Agent 應該知道每一步花了多少時間，以及總共經過的牆上時鐘時間。時間是一等公民工具，而不是註腳。 - **供應商預算。** 「我們現在在爬蟲上燒了多少錢？」應該是一個指令，而不是猜測。追蹤剩餘的抓取點數、本次迴圈的消耗、累計消耗，以及在下一次付費批次前的預計消耗。 - **LLM 花費。** 給它一個 LLM API 金鑰在資料層使用可以簡化很多邏輯。但 Agent 應該負責任地使用它們，首先要了解它實際花了多少錢。 - **Codex 使用量。** 這有點後設。迴圈應該有自我意識：我在這次優化上花了多少 token？這對於了解當前優化步驟的梯度很有幫助。 模式就是那句老話：你無法優化你看不見的東西。 如果你是第一次運行這些迴圈，不要啟動後就走開。坐在那裡觀察第一個週期。看看它觸發了什麼。確認你建立的 harness 確實被正確使用。然後再去睡覺。（並試著在睡覺時不要去想你醒來後會看到什麼） ### 4. 強制熵 (Forced entropy) 為什麼強制熵很重要：每個迴圈都從上一次運行的完整上下文繼續。模型不是從零開始——它在閱讀自己過去的一百個決定以及目前為止有效的梯度。 在 `/goal` 迴圈中，陷入局部最大值是預設狀態。沒有明確的推力，Agent 會一直走在同一座山上，而「同一座山」就是它停止改進時所在的位置。 例如，如果一個小旋鈕能將結果提升 0.1%，Agent 就會一直轉動那個旋鈕，即使它還有 1000 個其他旋鈕可以嘗試。 熵需要被明確地強制加入運行中，因為模型不會自己採取行動： - **每個週期進行過擬合反思。** 我是在構建一個更通用的解決方案，還是在死記硬背評估集？如果是死記硬背，下一次變更必須移除一個評估集形狀的偽影（限制清單、遮蔽特徵、擴大評估集、拒絕種子），而不是增加一個。 - **在停滯時強制加入熵。** 如果上一個週期沒有推動指標，下一個週期不能是「同樣的想法，更努力」。模型必須做出真正的非顯而易見的跳躍——「跳出框架思考」是一個很好的 Prompt——阻止 Agent 只是更用力地轉動同一個旋鈕。 - **保持迭代日誌。** 讓 Agent 記錄假設、預期的失敗模式、每一步的診斷，這樣它就能回顧並在壓縮過程中進行反思。 ## Meta-Meta-Prompt 我曾經自己寫這些目標，但很快就發現這也是 Agent 的工作。 所以我寫了一個 skill，專門為良好的 Loss-function-development 運行產生這類目標。 現在已開源在這裡： https://github.com/elvisun/loss-function-development ![這張圖表展示了一個自動化開發流程所產生的檔案結構及其對應的功能描述。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/422b7fa7cd002b94.jpg)
展開畫面重點
圖片顯示了一個名為「What it produces」的列表，詳細說明了各個檔案與目錄的用途： - **goal.md**: 定義損失函數，包含 spec gate（內部迴圈）、目標、約束條件、循環協議、熵規則及停止條件。 - **spec.md**: 定義內部迴圈，包含系統設計與測試案例（透過參考產出物進行導入或逆向工程）。 - **harness/score.sh**: 針對特定任務的評分器（如像素差異、召回率與精確度、架構差異，皆為針對任務生成，非通用型）。 - **harness/lint.sh**: 執行容量上限與評估重疊檢查；若違規將使分數無效且不回報其他資訊。 - **harness/probe.sh**: 擾動評估變體；開發與探測之間的差距是用來衡量記憶能力的指標。 - **harness/status.sh**: 記錄每步驟的實際執行時間、分數歷史、花費與預計消耗，以及代理程式自身的 Token 消耗量。 - **eval/dev/**: 在執行期間可自由評分（輸入可見，答案遮蔽）。 - **eval/holdout/**: 僅進行稀少且聚合性的評分；驗收標準存放於此。 - **LOG.md**: 迭代日誌，包含假設、預期失敗、診斷與結果。
## 梯度下降到底：兩個迴圈 退一步看，這就是梯度下降到底。 **內迴圈是 Agent：** 寫程式碼、跑測試、修復。短視界、快速回饋、單一目標——讓測試通過。這是開發者的內迴圈，而規格驅動開發就是你運行它的方式。編碼 Agent 已經將其自動化了。 **外迴圈是 `/goal`：** 在多個週期內推動整個系統朝向一個結果指標——發佈、測量、改變策略、下降。長視界、稀疏回饋。這傳統上是產品團隊的迴圈，將數個月的「發佈-測量-迭代」浸潤過程壓縮成單次運行。 現在這兩個迴圈都自動化了。留給你的是定義 Loss function——`/goal` 到底應該朝什麼方向優化，以及以什麼方式優化。 ## 你正在提煉一款產品——或任何留下公開產物的東西 另一個視角：這本質上是提煉 (distillation)，從訓練時移到了 Prompt 時。這就是 DeepSeek、Kimi、Minimax 系列縮小與 GPT 和 Claude 大部分差距的方式——用別人的輸出訓練你的模型，直到你的模型能重現它們。 但你現在不需要提煉模型，而是可以使用 `/goal` 和 LFD 來進行適用於任何可公開搜尋到的產物的提煉——它從不檢查內部結構，也不需要這麼做。 請留意「公開」這個詞。提煉別人的 ToS 限制、登入牆後或付費輸出是不公平的競爭。但公開發佈的內容——公司為了贏得客戶而發佈的輸出——一直以來都是可以學習的。這部分並不新鮮——這是軟體業最古老的招數。新鮮的是，現在這很便宜，而且可以在幾小時內完成，而不是幾個月。 退一步看，這裡有一個更大的轉變。在資訊對稱的地方，執行成本會崩潰到約 0 美元——當輸出是公開的，每個人都能看到「好的結果」是什麼樣子，所以任何人都能在週末花 40 美元把它提煉出來。 所以，這裡有一個正變得越來越有價值的護城河：**資訊不對稱**。 那家典型的開源公司已經妥協了。2026 年 4 月，cal.com（500 萬美元 ARR）將其生產程式碼轉為私有，並改為閉源。他們給出的理由讀起來簡直就像這篇文章的摘要：在 AI 驅動的安全威脅時代，你不能把原始碼留在 Agent 可以讀取的地方。 `"/goal 讀取 cal.com 原始碼並枚舉其攻擊面，直到找到可行的方法"` 這是一種太危險且太容易執行的攻擊。 那家整個身分認同都是「開源」的公司，在 2026 年決定開放已經成為一種負債。這應該能告訴你一切。 在整個軟體歷史中，「我們構建了它」就是護城河。 那個時代正在結束。 下一個時代屬於那些擁有產物中從未包含的東西的人：別人無法針對其評分的評估集。你的使用者真正會遇到的邊緣案例清單。你在私下測量的真實基準 (ground truth)。擁有競爭對手 Agent 看不到的目標的人，才是唯一能讓迴圈持續下降的人。 產品現在只是一個週末的工作。 去建立一個週末無法觸及的評估集吧。 ## 標籤 Agent, 教學資源, Harness, 自動化, GPT, Claude