工作區工程 是做什麼的？
將工作區視為使用者手中的產品。工程化的重點在於讓有用的工作變得可重複，而不僅僅是設計能產生一次好結果的提示。
核心問題：這個人還需要記住、修復或解釋哪些本來應由工作區處理的事？
主要使用場景是使用代理編寫程式碼。主動提出開發流程，包括當前工作區缺少的部分；不要止步於描述現有指示。對於非技術性角色，將相同的反饋和驗收原則應用於他們的交付物。
1. 確定任務
從使用者的話語推斷請求的模式：
- 審查： 檢查當前流程，解釋落差，並推薦改善方案。不做實作變更。
- 建構或改善： 實作要求的範圍，包括驗證和可用的交接。建構請求已授權一般可逆的實作；不要再增加計畫批准環節。
從現有的證據開始：儲存庫、流程文件或使用者的說明。流程發現不需要儲存庫。在檢查實作或執行指令前，先閱讀適用的儲存庫指示。在執行設定腳本前先檢查其內容。保留現有工作，並遵循目標的規範技能/指示佈局。
識別主要角色、重複任務、可接受的結果、當前的痛點以及人工決策。使用 discovery 進行訪談、流程文件或所有權不明的情況。先閱讀可用資料，然後只問那些答案會改變設計的問題。等待期間繼續獨立工作；不要憑空捏造缺失的答案。
2. 追蹤一個完整任務
選擇一個代表性的請求，從受理到執行、驗證、交接和復原，完整追蹤。如果存在失敗或修正的證據，也應包含在內。對於廣泛的審查，取樣每個實質上不同的工作流程，而不是聲稱一個樣本涵蓋所有情況。
記錄使用者做什麼、代理做什麼、哪些工具起作用、保存了什麼狀態、以及什麼證明了完成。比較預期做法與實作和觀察到的行為。保持這些證據標籤的區分：
- 已記錄： 某規則或流程指出應該發生這件事。
- 已實作： 存在具體機制並已整合到路徑中。
- 已觀察： 一次執行針對某個命名版本或工件展示了該行為。
- 未知： 缺少證據或存取權限。這不代表不存在。
使用 review 檢查路徑並對發現事項進行優先排序。一個通過的測試只證明它所斷言的內容，而不證明與其相關的所有主張。
3. 設計改善方案
閱讀 基準流程 的審查和建構模式。除非任務是非技術性的，否則使用其軟體開發預設值；若為非技術性任務，則使用其改編指南。對於混合型工作區，即使最終使用者是非技術人員，也對程式碼和輔助工具應用編碼基準。
使提議的流程具體化：觸發條件、步驟、指令或工具、通過/失敗標準、失敗回應、負責人以及完成證據。將每個適用的基準項目對應到現有機制、建議的變更、明確的例外或未知。說明重大偏離的原因；不要因為儲存庫從未有過某個做法就默默省略它。保留更嚴格的現有要求。
將其根本原因相同的症狀分組。比起為代理增加另一條需要記住的警告，更傾向於使用共享的公用程式、更好的輸入、更清晰的工具合約或更短的流程。僅當冗餘指令和檢查的目的在其他地方已保留時，才移除它們。
對於每個提議的變更，指定：
| 欄位 | 答案 |
|---|---|
| 使用者問題 | 什麼變慢、失敗或需要重複解釋？ |
| 證據 | 哪個檔案、流程步驟、事件或執行支援該發現？ |
| 變更 | 工作區將有何不同作為？ |
| 放置位置 | 知識、技能、規則、工具、本地檢查、遠端閘門或人工決策？ |
| 證明 | 我們如何知道變更有效，包括相關的失敗案例？ |
| 權衡與負責人 | 執行或維護的成本是什麼，誰可以更改政策？ |
按使用者影響、重複次數、信心程度、努力程度和反饋延遲進行優先排序。以少數值得先做的變更為先，而不是一個分數或一堆樣板內容。當具體範例或工作區佈局有幫助時，使用 patterns。
4. 審查或實作
對於 審查，簡要提供當前流程、提議的工作流程、帶有證據的優先排序發現事項，以及下一個有用的步驟。保留強大的現有機制，並說明哪些內容無法檢查。僅限於流程文件的審查應區分提議的控制措施與已知存在的控制措施。
對於 建構或改善，使用 build。端到端實作授權的範圍。如果使用者想要一個新工作區但角色或交付物仍未知，請先解決此問題再選擇技術棧。不要將每個流程問題都變成一個軟體專案。
5. 關閉迴圈
報告什麼更改了或建議了什麼、它如何幫助該角色、實際驗證了什麼、以及仍依賴於存取權限或人工判斷的內容。對於實作，留下一種清晰的方式來啟動工作流程和一種方式來執行其檢查。
保持運作限制明確：
- 絕不透過弱化標準、繞過掛鉤或接受缺失的證據來使失敗的檢查通過。合法的政策變更必須單獨識別並由其負責人授權。
- 保留已給出的授權；區分本地建構與花費額度、發布或變更生產系統。僅在實際需要權限的動作上解決權限問題。
- 不要將自動合併、無程式碼審查、固定覆蓋率、測試驅動開發或特定 CI 系統規定為工作區的定義。
- 將機密和私有原始碼細節排除在可重複使用的指示之外。當原始材料是私有時，用中性的範例提取模式。