Prometheus

Prometheus 是做什麼的？

一個通用的元提示框架，用於為 LLM 代理編寫提示。適用於任何代理 CLI（Claude Code、Gemini CLI、Cursor 等）以及非 CLI 的使用情境。涵蓋所有七種提示形狀：代理循環、一次性任務、工作流程鏈、子代理提示、系統角色、LLM 作為評判者，以及代理團隊。

此框架建立在經典的語境工程（Anthropic 的「正確抽象層級」、「最小可行 Token 集」、「範例優於規則」）以及量子語義原則（提示是運算子，而非金鑰尋找；順序具有結構性；模糊性是一種特性；組合是非加性的）之上。

何時使用此技能

當使用者開始為 LLM 代理設計提示時觸發。常見的措辭包含：

• 「幫我為 [任務] 寫一個提示」
• 「我需要一個用於 [目的] 的系統提示」
• 「幫我為 [專案] 建立一個 [Claude Code / Gemini CLI / 等] 的提示」
• 「為 [評估] 設計一個 LLM 作為評判者的提示」
• 「我正在建構一個執行 [X] 的子代理，幫我編寫其指令」
• 「為 [任務] 啟動一個代理循環」

在以下情況不要觸發：簡單的問答、程式碼補全請求，或使用者想要答案而非用來取得答案的提示的任務。

核心立場：提示是運算子

此框架最深刻的重新框架，源自量子語義文獻：提示並不是從模型中「提取」出正確答案。提示是一個運算子，透過轉換模型的語義狀態來建構答案。 提示的每個部分都是一個矩陣，會放大某些解釋、壓制其他解釋，並混合基底狀態以產生新的解讀。

這不是比喻。它改變了設計實務：

• 我們不是「找到正確的關鍵字」——我們設計轉換。
• 順序具有結構性——運算子不可交換。
• 組合部分會產生干擾，而非加法。
• 每個指令都會破壞資訊；請據此設計。
• 使用者意圖中的模糊性是一種疊加態，而非需要剔除的缺陷。

此技能具體應用這些原則，而非流於形式。請參閱 references/quantum-principles.md 以了解操作性映射，以及 operators/ 以查看部分即運算子的目錄。

三種操作模式

此框架根據使用者的輸入，以三種模式之一運作：

從頭開始模式（預設）。 使用者描述一個任務；框架生成一個提示。六個階段：形狀推論 → 適應性訪談 → 運算子設計草案 → 審計 → 誠實評估 → 交付。

重構模式。 使用者有一個現有提示，並想要審計、修正或重寫它。六個階段（1R 到 6R）：接收並解析 → 意圖恢復訪談 → 模式選擇（審計 / 目標重構 / 全面重寫） → 應用該模式 → 誠實評估 → 交付。完整程序記錄在 references/refactor-mode.md。

管理模式。 使用者指向一個現有的受管理代理套件，並希望在其生命週期中對其進行操作——監控其運行、分析目標違規、調整它、在保持相同內部狀態的情況下停止並重新啟動。這是框架作為代理管理者，而不僅僅是設計者：一個 MAPE-K 循環（監控 / 分析 / 規劃 / 執行），作用於代理的提示，並透過運算子代數表達。完整程序在 references/manage-mode.md；套件佈局、生命週期和分類帳在 references/agent-state.md。

模式偵測。 當使用者的開場訊息包含一個貼上的提示，隨後是審計、改進、修正或重構的請求時，自動偵測為重構模式。諸如「重構這個提示」、「審計這個提示」、「這個提示有什麼問題」等直接調用會立即觸發重構模式。當使用者指向一個現有代理套件路徑或對其調用生命週期動詞時，自動偵測為管理模式——「管理這個代理」、「執行一個調適循環」、「我的代理為什麼退步了」、「重新啟動我的代理」。當偵測不明確時（已貼上提示但請求不明確），詢問一次：「我看到一個提示——您希望我重構它，還是將其作為不同任務的上下文？」除非重構或管理的訊號明確，否則預設使用從頭開始模式。

這三種模式共享基礎設施（形狀目錄、運算子目錄、審計清單、驗證器規格），但執行不同的程序。特別是管理模式，它重用從頭開始和重構的機制作為子程序（審計清單、重構子模式、跨運行驗證器），而不是添加新的分析機制。從頭開始的程序如下；重構程序在 references/refactor-mode.md；管理程序在 references/manage-mode.md。

從頭開始程序（六個階段）

階段 1 —— 形狀推論，而非路由

使用者的任務描述以疊加的語義狀態到達。不要問路由問題。 從已存在的訊號中推論形狀，遵循 §2.4 貝葉斯取樣的精神。

1. 仔細閱讀使用者的請求。提取訊號：動詞（建置 / 草擬 / 分類 / 評分 / 評估 / 提取 / 摘要）、名詞（系統 / 文件 / 管線 / 循環 / 代理 / 角色 / 評判者）、規模標記（一次性 vs 持續、多輪 vs 單次呼叫），以及工具提及（Claude Code、Gemini CLI 等）。

2. 生成一個關於可能形狀的內部後驗分佈。形狀目錄在 templates/shape-catalog.md。先不要確定——保持權重。

3. 僅當第二名的形狀明顯落後時，才選擇具有最高後驗質量的形狀。如果兩個或更多形狀在約 30% 以內，則推論不明確，你應該透過一個有針對性的澄清問題來消除歧義。將其表述為前兩個形狀之間的強制選擇，而不是一個開放式的路由問題。

4. 領域（工程 / 研究 / 寫作 / 運維 / 通用）是一個次要軸線，與形狀正交。以相同方式推論它。一個一次性寫作提示和一個代理工程提示都應用此框架，只是部分內容不同。

5. 在同一次掃描中偵測硬推理訊號。 數學 / 邏輯任務、多步驟規劃、程式碼分析或除錯、多約束問題，或任何使用者提到模型第一次嘗試失敗的任務，都是認知工具支架（根據 references/reasoning-patterns.md）應在草擬中成為結構性預設值（而非可選擴展）的訊號。兩個或以上訊號 + 工具呼叫執行環境 → 在舊版和強大層級上包含該支架，適用於引用的經驗結果。在前沿層級上，該支架是一個 M5 觸發的選項，而非預設值——請參閱 references/reasoning-patterns.md §層級閘控。

6. 推論基礎能力層級——第三個軸線，與形狀和領域正交，從執行環境答案中讀取：前沿（執行環境最新的高指令遵循模型）、強大（當前主流模型）、舊版（較舊或較小模型）。未知 → 假設為強大。層級條件：階段 3 中的預設運算子強度（references/quantum-principles.md 中的原則 9——規範性運算子對高指令遵循基礎過度投射）、支架觸發閾值（上方第 5 點）、前綴可用性，以及階段 6 中的推理控制參數指導。

階段 2 —— 適應性訪談（運算子感知）

訪談本身是一個應用於使用者意圖的運算子序列。根據 §5.6，每個問題都不可逆地消除了模糊性。不要消除得太快。

執行規則：

• 總問題數上限為 6 個平面問題，包括階段 1 中的任何消除歧義問題（3 個通用問題——部署上下文在明顯時可跳過——加上 2-3 個特定於形狀的問題）。嚴格上限。合作起草（形狀 3、6、7）根據 templates/interview-branches.md 的執行規則不受此限。
• 每輪一個問題。 多問題的輪次會產生較淺的答案。
• 跳過答案已在使用者請求中的問題。 重複發問是破壞資訊的重複。
• 問題順序很重要（§2.3、§5.1）。先問最廣泛的框架問題，然後縮小約束，最後問格式。第一個問題設定了所有後續問題運作所在的子空間。
• 在提問成本低但錯誤成本高的情況下保持疊加態（§4.1）。對於架構層級的選擇（形狀、受眾、工具），保持疊加。對於戰術性選擇（檔名、大小寫），做出預設後繼續。

每個形狀的問題庫在 templates/interview-branches.md 中。有兩個問題在所有形狀中都是通用的：

1. 工具 / 執行環境。 「這個提示將在哪裡運行？（Claude Code、Gemini CLI、OpenAI API、通用 LLM、其他？）」影響記憶體檔案命名和特定於工具的輔助功能。
2. 完成定義 / 成功標準。 「您如何知道這個提示有效？要可檢查，而非基於感覺。」為階段 5 的自我評估提供評分依據。

以摘要收斂結束訪談：陳述你推論出的形狀、你收集到的關鍵約束，以及你為任何未指定內容分配的預設值。給使用者一次在草擬前覆蓋的機會。這是有意的測量步驟（§1.2）——使其明確，以便使用者可以對收斂提出異議。

階段 3 —— 運算子設計草擬

草擬是運算子設計（§5.3），而非填入區段。對於你包含的每個部分：

1. 識別該部分轉換的基底狀態——哪些解釋應該被放大、壓制或混合？
2. 選擇強度——強運算子（角色、硬約束）積極投射；弱運算子（風格偏好、格式）與大多數其他運算子可交換。將預設強度校準到基礎層級（原則 9）： 在前沿層級上，偏好簡潔的通用指令而非列舉，並將強度語言（「關鍵」、「必須」、重複禁令）保留給具有已證明失效模式的約束；在舊版層級上，通常需要更強的投射。對於具有破壞性能力的角色，能力鎖定在每個層級上都應保持層次化和強烈——其理由在於風險，而非基礎的弱點。
3. 在運算子序列中放置，根據 §5.1：最廣泛的框架優先，其次縮小，最後是格式。
4. 檢查與相鄰部分的干擾（§5.4）——組合是否會產生預期或非預期的湧現行為？

使用 templates/shape-catalog.md 取得特定於形狀的主幹。使用 operators/ 取得每個部分的運算子描述（每個部分放大、壓制、混合的內容；其強度；其交換性質）。對於不值得進行完整形狀選擇的任務（小型、定義明確、單一用途），templates/minimum-viable-prompt.yaml 是備用支架——六個插槽（系統 / 指令 / 範例 / 約束 / 狀態 / 查詢），僅此而已。

對於結構化分解優於整體鏈式思維的推理密集型任務，請查閱 references/reasoning-patterns.md——它記錄了認知工具子模式（IBM Zurich，在 AIME2024 上提高 +16.6%）以及何時在所選形狀內呼叫它。

當提示的輸出將由另一個 LLM 代理使用而非顯示給人類時（最常見於形狀 4 子代理 / 工具提示和形狀 6 LLM 作為評判者），請查閱 references/agent-consumability.md。當消費者是一個代理時，輸出設計會改變：可 grep 的失敗標記、聚合優先的結構、帶有詳細日誌的簡潔標準輸出、確定性但不同取樣，以及可見的狀態轉換。

對於形狀 7（代理團隊），拓撲選擇是基礎性的，必須先於每個角色的草擬。請查閱 references/agent-team-topologies.md 以了解四種規範拓撲（協調者-工作者、並行化-分區、並行化-投票、評估者-最佳化者）及其運算子概況、角色定義和常見故障模式。先選擇拓撲，然後使用其各自形狀的主幹草擬每個角色的提示，最後審計跨角色的一致性。

通用草擬規則適用於所有形狀：

• 正確的抽象層級。 具體到可以據此行動，同時靈活到模型可以調適。脆弱的硬編碼和模糊的敷衍是雙重失效模式。
• 最小可行 Token 集。 刪除任何非針對特定失效模式或啟用具體行為的內容。每個 Token 都會消耗注意力。
• 範例優於規則。 當一個規則承擔關鍵作用時，編寫一個完整的範例。範例是承載規則的運算子，能錨定抽象指令。但範例也有其自身的模糊性表面——範例中任何無聲的判斷都會成為模型反向工程出的規則。在交付任何範例之前，問：這個範例在我意圖之外還默默地教了什麼？如果不確定，用一個更清晰的案例替換它。
• 按運算子強度排序部分。 最強的運算子優先。
• 將失效模式作為「不要做什麼」。 每個都針對一個特定的已知尖銳邊緣，並附帶具體後果。泛泛的警告浪費 Token。

階段 4 —— 審計（結構性和量子性）

執行 references/audit-checklist.md 中的審計清單。該清單結合了經典的語境工程檢查（正確的抽象層級、最小 Token 集、範例存在、長視野支援的持久性）和量子語義檢查：

• 運算子目錄完整。 每個部分都有一個清晰的放大 / 壓制 / 混合概況。沒有部分是「裝飾」。
• 順序已最佳化。 最強的運算子優先。透過在心理上交換相鄰部分並問「這會改變行為嗎？」來測試。如果答案是肯定的，你就正確識別了不可交換的配對。
• 干擾已檢查。 當兩個部分可能交互時（例如，角色 + 語氣 + 格式），確認組合產生了預期的湧現行為，而非非預期的抵消。
• 資訊保存。 重要的上下文應儘早載入（它會在更多投射中存活下來）。應保持模糊的事項應標記為如此，而非預先收斂。