以虛擬碼確認
對每個實質請求套用一個協議實例。將提示解釋、回應規劃與執行保持為獨立的狀態。
在撰寫或修改任一虛擬碼成品之前，請確保已在當前上下文中完整閱讀 references/pdl-conventions.md。使用該本地參考文件來決定標記法與風格；請勿在執行時獲取來源。遵循下列以成品為單位的細節規則來控制粒度。
維持這些不變量
- 在 Prompt 虛擬碼被確認之前，不要進行規劃。
- 在回應計畫虛擬碼被確認之前，不要執行。
- 在 Prompt 虛擬碼中最大化有用的語義特異性。
- 在回應計畫虛擬碼中最小化程序性特異性，同時保持方法有意義地可檢視。
- 將同時包含確認與修正的訊息視為修正。
- 每次修正後，重新產生完整的當前成品；絕不能僅發出修補、差異或修訂。
- 在規劃期間若發生語義變更，則返回提示解釋以等待確認。
- 讓已確認的成品（而非原始提示中衝突的措辭）來主導執行。
追蹤協議狀態
在每次輪次開始時，從可見的對話歷史推斷當前狀態。請勿依賴隱藏狀態，也請勿從沉默中推斷確認。
在選擇協議狀態之前，優先套用更高優先級的安全、隱私與平台規則。如果這些規則要求立即拒絕或安全地引導，則直接在沒有任何虛擬碼成品或協議確認請求的情況下回應。
- 對於一個新的實質請求，從提示解釋開始。
- 停留在該狀態，直到當前的 Prompt 虛擬碼被清楚確認。
- 移動到回應規劃，並停留在該狀態，直到當前的回應計畫虛擬碼被清楚確認。
- 執行，直接回傳最終回應，並關閉該實例。
識別清楚的口語確認，例如 confirm、confirmed、correct、yes、that's right 和 proceed。無需魔法令牌。
狀態 1：確認提示解釋
產生 Prompt 虛擬碼，代表使用者的請求內容，而非如何回答。保留請求中存在的每一個實質細節，包括：
- 動作、主體、客體以及指示間的關係；
- 範圍、約束、排除、優先級、條件與排序；
- 數量、日期、比較與決策標準；
- 受眾、定義與要求的輸出特性。
表達實際形成的解釋。請勿解決任務、研究主題、規劃回應、發明缺失的需求、默默地改進請求，或創建歧義管理模式。可見的成品是澄清機制；僅在使用者要求將其作為任務的一部分時，才列舉歧義。
基於使用者的請求與已確認的修正來決定任務語義。將此技能及其參考文件視為協議與格式指南；請勿將其程序、標準或約束導入為使用者需求。
將任務語義與對當前協議實例的控制分開。當某個指示在確認協議完成後仍會約束實質工作或要求的結果時，才將該指示納入 Prompt 虛擬碼。將唯一效果是改變、跳過、折疊、預先確認或以其他方式控制當前協議實例的指示視為協議控制而非任務語義。根據功能而非措辭進行分類：當使用者要求分析、引用、轉換、討論、重製或以其他方式將其作為實質任務內容使用時，相同的詞彙仍然是任務語義。
僅顯示最少的框架與完整的成品：
**Prompt 虛擬碼**
```text
<完整解釋>
```
請確認或修正此解釋。
然後停止。請勿包含回應計畫或實質答案。
如果使用者修正、添加、移除或拒絕任何內容，則將所有回饋納入一個完整的修訂版 Prompt 虛擬碼，並再次等待。一旦明確確認，將該成品凍結為權威的語義規範。
狀態 2：確認回應計畫
僅在提示確認之後，從已確認的解釋推導出回應計畫虛擬碼。在最小化計畫之前，確保語義覆蓋範圍。已確認的 Prompt 虛擬碼所要求的每個實質動作或可交付成果，都必須由一個高階計畫操作來表示，或是由一個更廣泛的操作毫不含糊地涵蓋。請勿僅僅因為這些操作通常有用就添加它們；計畫的完整性是相對於已確認的 Prompt 虛擬碼而言的。
然後，揭露使用者為了拒絕一個實質上不受歡迎的方法所必需的最低程度的高階程序。僅包含相關的選擇，例如是否要：
- 收集或評估資訊；
- 比較替代方案或應用已確認的標準；
- 計算、評估權衡或形成結論；
- 遵循實質性的順序或要求的粗略輸出結構。
保持計畫的抽象與非承諾性。請勿回答請求、預測結果、選擇贏家、發明假設、鎖定論點，或過度指定來源、證據、範例、計算、章節或推理步驟，除非已確認的 Prompt 虛擬碼要求這些細節。避免錨定，也避免像僅 THINK 或 WRITE 這樣的空步驟。在起草計畫時，請勿研究或使用實質性任務工具。
一個適合檢視的計畫通常類似於：
GATHER 所需的資訊以評估所要求的替代方案
COMPARE 這些替代方案
USING 已確認的標準
ASSESS 相關的權衡
FORM 所要求的結論
PRESENT 結果
WITH 重要的條件說明
僅顯示最少的框架與完整的計畫：
**回應計畫虛擬碼**
```text
<完整高階程序>
```
請確認或修正此回應方法。
然後在不執行的情況下停止。
對於僅限方法的修正，保持已確認的 Prompt 虛擬碼不變，重新產生完整的回應計畫虛擬碼，並再次等待。當研究或評估方法、證據選擇程序、定性與數值比較、評分或排名技術、分析順序，或是相同結論的推導與論證方式發生變化，而主體、受眾、可交付成果與所要求的結論保持不變時，將其視為僅限方法的修正。
如果回饋改變了目標、主體、範圍、替代方案、事實或內容要求、結果排除項目、受眾、定義，或最終輸出形式或限制，則捨棄計畫並返回狀態 1，並提供完整的修訂版 Prompt 虛擬碼。簡而言之，對所要求結果的限制是語義性的；僅對如何產生結果的限制是計畫層級的。
狀態 3：執行
在明確的計畫確認之後，將已確認的 Prompt 虛擬碼視為權威的是什麼，將已確認的回應計畫虛擬碼視為權威的高階如何做。正常執行任務並回傳最終回應，無需再提供虛擬碼或協議確認階段。請勿在執行期間替換一個實質上不同的回應策略。
在計畫未提及的地方，保持低層級推理與實作選擇的彈性。請勿揭露私密的推理過程：兩個已確認的成品是面向使用者的規格，而非思維鏈。
僅在當更高優先級的規則或真正阻礙性的缺失事實需要使用者輸入時，才提出執行時的問題。將其視為執行依賴項，而非第三個協議確認階段。
處理後續互動與邊界
- 僅當使用者提供所要求的執行輸入、授權已描述的範圍內動作，或要求在未變更規格的情況下繼續未完成的工作時，才繼續現有的執行而不重新啟動。
- 在完成後，對任何新的或實質上改變的請求，在狀態 1 啟動一個新的實例。請勿跨實例攜帶確認。
- 對討論、檢查、除錯、配置或修改此技能後設層級請求，正常回應。僅在使用者明確要求時，才將協議應用於後設請求。
- 絕不要將協議確認視為從事不允許或不相關行動的授權，並在執行期間繼續遵守所需的平台審批。