principle-encode-lessons-in-structure | 把教訓編入結構
本頁以 pstack-claude 0.9.126 為基準。原文標示 user-invocable: false，通常由 poteto-mode 按需讀取。以下用自然語言要求代理套用，不把原則當成獨立命令。
定位與適用情境
當你第二次寫出相同指示，或反覆糾正同一種錯誤，應檢查能否把它變成結構性防線，而不是再加一條容易被忽略的文字規則。可採用程式碼檢查（Lint）、中繼資料（Metadata）旗標、執行期檢查或腳本。
例如教材多次忘記填寫分類。團隊每次都在審查留言提醒，但新文章仍會漏填。如果「分類必須存在且屬於允許值」可以機械判定，就讓內容驗證直接拒絕不合規資料。
上游正文很短，重點也包含反方向的限制。若教訓需要判斷、無法編碼，就讓說明更醒目並附上失敗案例。以下流程是依此原則設計的練習，不是上游內建檢查器。
準備
- 找出同一錯誤的實際紀錄，確認不是兩種不同問題恰好用了相同說法。
- 準備合法教材、缺少分類的教材，以及填入不支援分類的教材。
- 確認現有內容驗證與本機檢查入口，避免另建一條沒有人執行的流程。
- 分開列出可機械判定的條件與需要編輯判斷的品質要求。
操作步驟
- 把重複提醒改寫成可判定條件。 「不要忘記分類」改成「分類欄位存在且值在專案允許集合內」。不要把「文章要有深度」硬轉成字數門檻。
- 選一個能實際擋住錯誤的位置。 本例優先使用已有的內容結構驗證，讓錯誤在加入教材時出現。若現有入口無法表達規則，再考慮最小腳本或其他檢查。
- 用正反例確認防線。 合法資料應通過，缺少或錯誤分類應得到可定位到檔案與欄位的失敗訊息。保留反例，方便日後調整規則時重驗。
- 整理提醒的去留。 對已由結構完整保障的操作提醒，不再額外堆疊同義指示。保留有效背景文件。對仍需判斷的要求，留下醒目指示及具體失敗案例，不假裝已自動化。
可直接使用的提示詞
套用 principle-encode-lessons-in-structure。
教材審查已多次提醒補填分類，輸入是相關紀錄、現有內容 schema 與三份正反例。
先區分能機械判定的規則，以及仍需要人工判斷的品質要求。
在核准範圍內提出最小結構性防線，優先沿用既有驗證入口。
驗收須看見合法資料通過，缺欄位與錯誤分類被拒絕，錯誤能定位到檔案。
不要用字數門檻取代內容深度，也不要把同一規則複製到更多指示檔。
尚無法編碼的要求，保留醒目說明並補一個具體失敗案例。
先列出預計變更，不修改全域設定或刪除既有有效文件。預期結果與驗收
預期結果不是「規則文件變長」，而是同一個已知錯誤再次出現時，現有工作流程會直接回報失敗。維護者應能指出規則由哪個結構承擔，以及哪些條件仍需要人工審查。
驗收時，把漏填分類的範例重新送入檢查。若仍可無聲通過，或工具未接到實際流程，就還沒有把教訓編入結構。也要確認合法例子不會被錯擋。
常見誤用是同時增加多份規則文字與重複檢查，卻沒有清楚責任位置。另一種是把無法精確表達的審美或內容判斷硬編成簡單門檻，讓代理只會迎合指標。
限制與權限
不是每個教訓都能自動化。對無法判定的部分，明示限制比宣稱「已杜絕」更可靠。本頁沒有宣稱 pstack 已附帶教材分類檢查工具。
修改內容結構、持續整合（Continuous Integration，CI）或執行期檢查，可能影響既有資料與開發流程，須先列出受影響檔案。整理重複提醒不構成刪除文件、修改代理設定或調整權限的授權。