trailofbits/goal-prompt

目標提示詞

/goal 能讓代理持續工作，直到滿足完成條件為止。Claude Code 和 Codex 都將其作為一行指令接受，最多 4,000 個字元。在 Claude Code 中，一個小型模型會根據每次互動後的對話記錄，重新判斷條件是否滿足——它無法執行命令。

起草一個可以終止的條件，然後對其進行格式化。一個目標應適合比一次互動更大規模的工作，並且具有可檢查的終點；將小目標串聯起來，並在它們之間進行審查，而不是撰寫一個巨大的目標。

草稿

包含以下條件，並以 AND（且）連接——絕不用 OR（或），因為迴圈會選擇成本較低的分支：

1. 結束狀態，而非活動 — 例如「所有 legacyAuth() 的呼叫位置都使用 auth.verify()」，而不是「遷移認證程式碼」。活動是可以被宣稱完成的；而結束狀態則是真或假。
2. 先行定義讀取範圍 — 在行動之前需要讀取的檔案、問題、日誌或計劃。
3. 明確的檢查指令 — 具體的命令及其可觀察的結果（例如「npm test 退出碼為 0」），加上執行該命令並顯示輸出的指示；一個從未出現在對話記錄中的結果，對評估者而言等同於不存在。
4. 不變量 — 哪些不能改變（例如「不修改 vendor/ 目錄」），始終包含「不得削弱、跳過或編輯檢查本身」。
5. 停止邊界或受阻條款 — 例如「或在 20 次互動後停止」、「如果受阻，則停止並報告阻礙因素」。缺少此條款時，一個表述錯誤的條件會導致無限迴圈；格式化工具會在缺少時發出警告。（Claude Code 會在恢復工作階段時重設計數器，因此互動次數限制會無聲地跨越多個工作階段。）

保持簡潔。 每個限制都會縮小模型可以探索的狀態空間。盡可能將其收斂為一個終止標準，將範圍和定義移入一個參考檔案，並刪除非目標條款——一個限制只有在能關閉一個真正的捷徑時，才有其存在的價值。

對於較長的目標，也應指定最終的證據（差異、報告、產出物），並要求一個進度日誌檔案——這是跨壓縮和恢復的持久狀態。如果簡報超過 4,000 個字元，請將詳細資訊放入 GOAL.md 檔案中，並從目標中引用該檔案。

切勿發明不存在的元素。 將每個元素都建立在使用者的請求、對話或儲存庫的基礎上——查詢資料而非猜測。如果某個元素無法從可用資訊中填充，則仍然優化和格式化使用者提供的內容，省略該元素，並將其標記為缺失（請參閱格式化）。一個帶有虛構成功條件的目標，會在錯誤的合約下終止。

堵住捷徑

在格式化之前，以一個懶惰模型的角度重新審視草擬的條件：要讓每個檢查都通過而不完成預期工作，最省力方法是什麼？堵住最省力的那些捷徑——優先考慮配對您已有的檢查，而不是增加限制，並且不要將每一個可能的路徑都列舉成一個非目標清單。常見的捷徑包括：

• 刪除或打樁而非修復 —「搜尋結果為空」在呼叫端都被刪除時也成立；將此類檢查與一個能證明功能仍然正常的檢查配對。
• 只在子集上通過 — 只執行一個測試檔案、縮小搜尋路徑、從檢查中排除某些目錄。
• 玩檢查規則的漏洞 — 跳過/標記為預期失敗的測試、硬編碼預期輸出、對測試輸入進行特殊處理、編輯檢查本身（不變量規則）。
• 宣稱完成而不執行 — 宣稱完成或受阻，但對話記錄中沒有檢查輸出（顯示輸出規則）。

與上述相同的原則：一個您無法從現有資訊中堵住的捷徑，應放入 Missing:（缺失）清單中作為警告——一個虛構或不合理的限制，比一個被標記的漏洞更糟糕。

安全研究目標

將審計目標收斂為一個可終止的標準，例如：識別、觸發並驗證一個在參考的威脅模型檔案下有效的高嚴重性漏洞。該檔案（而非目標）應承載範圍、攻擊者能力、嚴重性基準以及已知要跳過的發現。使用中性措辭（如「觸發並驗證」，而非「證明這是可利用的」），要求展示前提條件——假設的攻擊者訪問權限是最常見的誤報——並在每次發現後停止以進行人工審查，而不是堆積未經分類的報告。驗證發現應由一個全新的代理進行第二輪檢查，絕不能由發現者獨立完成。

格式化

在草稿（檔案或標準輸入）上執行 uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced。它會將空白字元壓縮為一行，去除 /goal 前綴、引號和程式碼區塊，在缺少停止子句時發出警告，並拒絕輸出超過 4,000 個字元——請縮短內容或將細節移至檔案後重新執行。

只返回一個被程式碼區塊包裹的 text 塊，一行：

/goal <單一正規化目標>

不要在其前後添加任何散文——除非清單元素無法被置於具體基礎之上：此時請在該區塊之後緊接一個 Missing:（缺失）清單，每行一個空白，告訴使用者需要提供什麼。

範例

草稿：

/goal 遷移認證模組：
  - 用 auth.verify() 取代 legacyAuth()
  - 確保測試仍然正常運作

重新起草並格式化後：

/goal 所有 legacyAuth() 的呼叫位置都使用 auth.verify()：`rg "legacyAuth\(" -t ts` 列印結果為空 且 `npm test` 退出碼為 0（執行兩者，並顯示輸出），不修改 vendor/ 或削弱任何測試。如果受阻，停止並報告嘗試過的路徑和阻礙因素，或在 20 次互動後停止。

此處的 npm test 來自儲存庫的 package.json——不是猜測——將其與零匹配檢查配對，堵住了最省力的捷徑：刪除呼叫位置而非遷移它們。當沒有任何元素有具體基礎時，格式化現有內容，並標記漏洞：

草稿：讓結帳更快，上下文中沒有任何指標或基準：

/goal 讓結帳更快

Missing:

• 可測量的結束狀態 — 哪個指標和閾值算作「更快」
• 驗證方式 — 證明它的基準測試或命令
• 停止邊界 — 例如「或在 20 次互動後停止」