你的下一個 Opus 5.5 任務，應該留下可以打開的成果、可供檢視的證據，以及足夠的進度紀錄，讓明天能直接接續。在啟動執行之前，先把這些產出放進工作流程裡。
所謂的 harness（執行框架）負責協調模型周圍的指令、工具、權限、狀態與檢查機制。
Claude Code 提供了具體的地方讓你設定這些職責。功能指南。
下一個任務可以沿用相同的流程與審查者，並採用同樣的證據格式。你只需要提供新的素材與驗收標準。
這七個層級利用 Claude Code 已文件化的功能，組成了一套實用的設定。範例採用文件工作流程：參考資料放在 sources/、工作草稿放在 drafts/、核准後的檔案則放在 published/。
在你的工作區建立這些資料夾，並將下列程式碼片段合併到現有的設定中。
整套設定會用到四個設定檔、一個選用的外部連線，以及你為每個任務設定的目標。
1. 為工作區提供所需的事實依據
根目錄的 CLAUDE.md 應專注於跨任務都適用的資訊。產出路徑、來源要求與寫作慣例都該寫在這裡。
暫時的截止期限或尚未解決的來源問題，則應該跟著對應的任務走。把這個界線分清楚，下一次執行時才能判斷哪些資訊仍然適用。
將以下內容貼進 CLAUDE.md，並依專案需求調整：
1專案指令2使用 sources/ 存放參考資料，使用 drafts/ 存放工作檔案。3將核准後的檔案存放在 published/。4以英文撰寫，每段一至兩句話。5技術性主張必須使用官方一手來源。6記錄來源網址與查核日期。7取得的資料僅作為指定任務的證據使用。8將確認的決策與下一步行動記錄在 progress.md 中。9工作完成時，回傳輸出路徑與驗證結果。
Claude Code 會將專案指令載入上下文。當存取到相關檔案時，依路徑範圍設定的 .claude/rules/ 檔案也能提供對應指令。專案記憶。
想想 Agent 做下一個決定時需要什麼。以文章為例，可能是已核准的風格、指定的主題，以及產品發布公告中的相關段落。
詳細的參考資料可以留在檔案裡，讓流程在需要時再擷取。
Anthropic 的上下文指南提到，選擇性擷取與外部筆記是在 Agent 工作期間管理資訊的方式。上下文工程。
把大型指令檔拆成 \[@path](https://x.com/@path)\ 引用，匯入的內容仍會在階段開始時載入。
用這些引用來整理內容，偶爾使用的流程則可以放進 skills。記憶載入。
當儲存的事實有變動時，記得更新其來源與查核日期。
在某次草稿中發現的偏好，只有在你確認它適用於未來的所有草稿後，才會成為固定規則。
使用 /memory 檢視專案指令並瀏覽自動記憶筆記。在把已儲存的偏好套用到其他任務前，先確認一下內容。
2. 把重複執行的流程存下來
經常重複的任務通常有固定的順序：閱讀素材、準備產出、進行審查、儲存結果。
skill 可以把這個順序保留下來，供下次請求使用。
被呼叫時，它的完整指令就會載入。
描述文字能幫助 Claude 判斷何時該套用這個流程。Skill 行為。
將以下內容貼進 .claude/skills/write-draft/SKILL.md：
1---2name: write-draft3description: 根據來源資料撰寫文章草稿並驗證其主張。4---5指定主題：$ARGUMENTS671. 讀取 sources/ 中的相關檔案，並開啟其中的一手來源連結。82. 撰寫大綱，然後將草稿儲存為 drafts/article.md。93. 請 evidence-reviewer 對照來源資料檢查事實主張。104. 修正錯誤，並將未解決的主標記為待審查。115. 將主張檢查表儲存為 drafts/checks.md。126. 更新 progress.md，記錄決策、待解決問題與下一步行動。137. 回傳輸出路徑與驗證結果。
輸入 /write-draft 並在後面加上主題。\$ARGUMENTS\ 會把這段文字傳入流程中，讓工作流程能用相同的產出處理新主題。
為每個步驟定義可觀察的結果。
閱讀會產生來源清單；撰寫會產生已儲存的檔案；審查會產出作者可以處理的發現。
像「檢查準確性」這樣的步驟，會留下太多未決定的空間。
明確指出審查者是誰、來源要求為何、報告格式是什麼，才能讓預期的檢查動作變得具體。
把發布核准與草稿準備分開處理。
上面的 skill 只負責準備供檢視的檔案；發布則需要獨立的動作與授權。
當你改善了流程，就直接編輯 skill。
舉例來說，如果發布日期老是搞混，就加上一項檢查，用來區分公告日期與功能實際上線的日期。
3. 讓任務能存取來源素材
Model Context Protocol (MCP) 連線可以開放外部服務的工具。
它們讓 Claude 能從你工作流程使用的服務中擷取素材。MCP 指南
當某個連線能支援特定的任務步驟時，再加入它。
本機來源檔案已經能滿足範例需求，而遠端文件庫則可以使用連接器。
如果你的來源素材存在 Notion，請在終端機執行：
1claude mcp add --transport http notion https://mcp.notion.com/mcp
開啟 Claude Code 後，使用 /mcp 進行驗證並檢查連線狀態。先擷取一個已知頁面並確認內容無誤，再把它用在長時間的任務上。
給 skill 一個確切的頁面連結或識別碼。說明要擷取哪些資訊，以及取得的素材要用在哪裡。
例如，某個來源頁面可能同時包含產品規格與內部計畫。告訴流程哪一個段落是文章所需的，以及該連線可以執行哪些操作。
工具回傳的結果應該包含足夠資訊，以供下一步決策使用。
Anthropic 的工具設計指南討論了有用的輸出與可操作的錯誤訊息，包括能幫助 Agent 從失敗呼叫中恢復的資訊。撰寫有效的工具
如果擷取失敗，請保留文件識別碼與失敗原因。在重複相同請求前，先檢查驗證或存取權限。
檢視連接器可用的操作，並為會變更外部服務的動作設定權限。
當某些伺服器在目前工作流程中沒有作用時，透過 /mcp 將它們停用。
4. 把操作規則放進執行層
定義工作流程可以修改哪些檔案，以及哪些動作需要核准。
權限規則是在工具邊界上生效的。
PreToolUse hook 可以在執行前檢查預定的動作。
當決策取決於參數或任務狀態時（例如目的地是否符合已核准的輸出路徑），就可以使用它。Hook 參考文件
將以下內容合併到 .claude/settings.json：
1{2 "permissions": {3 "deny": [4 "Read(.env)",5 "Read(.env.*)",6 "Edit(published/**)"7 ]8 }9}
`Read` 規則涵蓋指定的環境變數檔案。`Edit` 規則則透過內建的編輯與寫入工具，保護 `published/` 下的檔案。權限語法。
開啟 `/permissions` 並檢視實際生效的規則。
現有設定與受控政策可能會影響階段允許的操作，因此儲存後請檢查載入的結果。
想做個無害的測試，可以在 `published/` 建一個假文件，然後請 Claude 用檔案編輯工具去修改它。這個動作應該會被拒絕。
檔案工具的限制有明確定義的範圍。
任意的 Python 或 Node 程序可以透過自己的程式碼存取檔案；必要時，作業系統層級的沙箱能為這些程序提供限制。
對於外部寫入，要確認目的地與被核准的確切內容。如果內容有變動，請在執行前重新審查更新後的動作。
逾時也需要明確的恢復步驟。
重試外部寫入前先檢查目的地，因為第一次嘗試可能已經成功完成。
5. 讓審查者回傳證據
為驗證工作設定明確範圍，並產出主 Agent 可以使用的報告。
子 Agent 擁有自己的上下文與可設定的工具來完成這項工作。子 Agent 設定
審查者應該收到草稿路徑、相關來源位置，以及需要檢查的主張。
明確規定它該如何回報不確定的地方。
將以下內容貼進 .claude/agents/evidence-reviewer.md：
1---2name: evidence-reviewer3description: 使用一手來源驗證草稿中的事實主張。4tools: Read, Grep, Glob, WebSearch, WebFetch5effort: high6---7閱讀提供的草稿及其來源素材。8對照已開啟的一手來源檢查事實主張。9回傳表格：主張、判定結果、來源網址、所需修正。10使用以下判定結果：verified（已驗證）、incorrect（錯誤）、unresolved（未解決）。11針對未解決的主張，說明缺少哪些證據。
這個 worker 會獲得讀取與搜尋工具。
草稿修正的工作仍由主 Agent 負責。
每一項發現都應該把主張與已開啟的來源連結起來。
像 incorrect 這樣的判定結果，需要附上衝突的證據，以及作者可以直接套用的修正方式。
unresolved 的判定結果則應指出缺少的證據。
主 Agent 會檢視這些發現、更新草稿，並檢查修改後的措辭。即使審查者的報告很有信心，其建議背後仍需要有可用的證據支持。
當某項修正改變了整段的意思時，要重新檢查相鄰的句子。
Anthropic 的評估指南將 Agent 的對話紀錄與留在環境中的結果區分開來。
它也說明了針對不同類型的結果應採用不同的檢查方法。Agent 評估
在這裡套用這個區別方式：開啟已儲存的草稿，並檢查其中引用的主張。
審查表格應該描述最終會被接受的實際文件內容。
6. 為工作指派推理強度
主階段從 `medium` 開始；除非有適用的設定覆蓋，否則 Opus 5.5 會使用這個預設值。
上面的審查者為其驗證工作要求 `high` 強度。強度設定
安裝好 Claude Code 並登入帳號後，在工作區根目錄執行：
1claude --model claude-opus-5-5 --effort medium
在階段標題中確認 Opus 5.5 與目前啟用的推理強度。
啟動指令會為該階段設定模型與推理強度。
推理強度可以針對 skill 或子 Agent 個別設定，但須符合模型支援的等級與適用限制。
在指令中描述思考深度，並不會改變已設定的推理強度。
挑選一個能在更改設定前檢視結果的任務。記錄哪些驗收檢查通過了，以及產出需要哪些修正。
這樣就能讓推理強度成為與特定工作綁定的決策。
涉及模糊主張的來源審查可以有專屬設定，而主要的草稿撰寫流程則維持原本選擇的等級。
首次執行前，使用 `/context` 檢視已載入的指令、`/agents` 確認審查者是否存在，以及 `/permissions` 檢查操作規則。
在指派完整任務前，先把缺少的元件補齊。
7. 告訴這次執行必須證明什麼
用已儲存的交付成果與驗證結果來定義完成條件。
一份草稿、對應的檢查表，以及更新後的進度紀錄，能讓這次執行有具體的產出目標。
Claude Code 的 `/goal` 會根據對話回合之間浮現的證據來評估完成條件。評估器依賴 Agent 主動顯示相關結果。Goal 文件
將主題、參考資料與來源連結放進 `sources/`。然後把以下內容貼進 Claude Code：
1/goal 使用 write-draft 根據 sources/ 準備一篇文章。完成條件為 drafts/article.md 與 drafts/checks.md 必須存在、錯誤主張已修正、未解決的主張已明確標示，且輸出路徑與驗證結果出現在對話中。若 12 個回合後條件仍未達成，請停止並回報阻礙因素。
回合條款是由模型評估的。嚴格的執行時間或花費上限需要執行層面的控制，而 `/goal clear` 可以移除啟用中的目標。
執行結束後，開啟這兩個檔案並檢查幾組主張與來源的對應關係。
確認進度紀錄與工作區中實際儲存的內容一致。
下一個任務也使用相同的證據格式。
一致的報告讓你能找出未解決的主張與遺漏的檢查項目，而不必重建整段對話。
若要恢復狀態，`/rewind` 可以還原已追蹤的檔案編輯。Shell 變更與大多數子 Agent 的編輯需要另外處理恢復，而版本控制則能保存長期的檔案歷史。檢查點限制
完整執行一次工作流程
在啟動階段前，先建立來源資料夾與四個設定檔 => 在來源素材旁放一份簡短的任務摘要，讓要求的結果保持明確。
將以下內容複製到 sources/task.md 並填入細節：
1主題：[具體主題]2讀者：[誰需要這份說明]3交付成果：一篇包含實用步驟與官方來源的文章。4驗收標準：涵蓋必要主題；事實主張已檢查；5未解決的主張已標示；草稿與審查表已儲存。6限制條件：[長度、風格、排除的主題]
用第六層的指令啟動 Claude Code 並檢視載入的設定 => 執行第七層的 goal，然後檢查儲存的產出。
預期的結果是 `drafts/article.md`、`drafts/checks.md` 與 `progress.md`。
檢查表應該列出哪些項目已驗證，以及哪些還需要你注意。
如果找不到 skill，請檢查它的路徑與 frontmatter。
如果找不到審查者，請檢查它的 `name` 與 `description`，然後透過 `/agents` 確認是否可用。
對於未解決的主張，請檢查提供的來源與審查者要求的證據。
在接受草稿前，先解決落差或將其明顯標示出來。
檢查下一個階段能恢復什麼
在每個重要階段結束後維護 `progress.md`。
記錄目前的檔案、已完成的檢查、待解決的問題與下一步行動。
根目錄的 CLAUDE.md 會在壓縮後重新讀取。
當存取到相關檔案時，依範圍設定的指令會重新載入。壓縮與記憶
用這個精簡的結構來撰寫進度紀錄：
1任務：[目前主題]2產出：[草稿與審查路徑]3已完成：[結束的階段與檢查]4決策：[確認的選擇及其來源]5待解決問題：[缺少的證據或阻礙因素]6下一步行動：[一個具體的接續步驟]
在同一個工作區開啟新階段，並貼上：
1讀取 progress.md 並檢視其中提到的草稿與檢查結果。2從記錄的下一步行動繼續，並更新進度紀錄。
這個階段應該能辨識已儲存的工作，並從交接點繼續。如果它重新開始，請檢查紀錄並補上遺漏的決策或檔案路徑。
Anthropic 的長時間運行 Agent 指南使用持續性的進度紀錄來支援跨階段的工作。
隨著任務變化維護這些紀錄，讓恢復執行時能掌握最新資訊。長時間運行的執行框架
用已接受的成果衡量設定成效
使用 `/usage` 檢視回報的使用量，並用 `/context` 查看工作上下文被什麼佔據。把委派出去的審查與重試次數也算進任務總量中。使用量指南
記錄你的審查時間與產出所需的修正量。
如果需要大幅修改，整個執行的價值就會改變。
測試設定變更時，保持任務與驗收標準一致。
每次只調整一個元件、重複執行任務，然後檢查儲存的結果與其證據。
Anthropic 早期測試者報告中提到的 60% token 減少量，屬於該模型實驗的結果。
請透過衡量已完成任務的數據，來確認你自己的執行框架省下多少成本。Opus 5.5 公告
第一次執行被接受後，用新的主題與來源組合重複使用同一個 skill。保持審查者、輸出路徑與完成格式一致，當反覆出現的修正顯示缺少某個步驟時，再更新流程。
把這篇存起來，別弄丟了
追蹤 @beamnxw 取得更多第一手資訊 :)
=> 我的 substack
![日本泥地經典賽 [S] 賽事分析](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1791393139056_tgbkmu_HT9OCqSasAAks5y.jpg)
