沒有編譯器時如何驗證：Cowork 與 Claude Code 的 harness，以及為何切片驗證器仍要保留

問題#

兩個 #oq/now 項目指向同一個問題——沒有機械驗證器的代理程式輸出：

1. Cowork —— Cowork 的 harness 和 Claude Code 相比如何？兩者都提供 skills、MCP、sub-agents，但非程式碼輸出的失敗模式不同（沒有測試套件、沒有編譯器，也沒有差異可供檢視）。
2. Vertical Slice Tracer Bullets —— 規劃器代理程式被告知要垂直切片後，是否就能信任它做到，還是需要一個會標示水平切片的驗證器？

答案一：基本元素相同，驗證器階梯卻相反，因此 harness 的配置重新分配#

這兩項產品確實共用一些基本元素——skills、MCP 連接器、sub-agents、computer use，以及相同的模型（Cowork，mcp-and-computer-use 上的跨介面比較表）。差異在於它們的輸出落在驗證器品質階梯的哪個位置（何時驗證品質會決定 AI 自動化是否奏效？）：程式碼位於 CI 階梯（確定性的通過／失敗），而簡報、資料卷宗和收件匣分類則落在嘈雜的判斷階梯——單單這項差異就重新分配了整個 harness：

• Claude Code 的 harness 仰賴事後確定性驗證器堆疊。 測試、編譯器、linter、差異檢視、規格偏移檢查——這是當能力腳手架縮減時仍然承重的邊界執行層（驗證成為新的瓶頸、模型進步時的 Harness 縮減）。關鍵是，這個堆疊一舉兩得：它既能捕捉錯誤，也能限制損害——合併前就會以紅燈測試呈現失敗，而且依其設計可復原（git、worktrees、sandboxes）。
• Cowork 的 harness 以判斷編碼取代機械檢查。 語料中點名的替代做法包括：載入的設計系統——Cat Wu 的簡報之所以「看起來像設計師做的」，是因為 harness 中包含 design_system.html 類型的上下文，這是最接近非程式碼樣式檢查器的做法（Cowork、Living Design System）；用來評估輸出品質的evals 和 LLM-judges，但必須坦承，評審驗證本身仍不夠嚴謹（LLM-as-a-Judge），而 Cowork 頁面也明確把簡報品質的 eval 規範列為未解問題；以及把人工審查集中在決策檢查點，而非分散在各項輸出中（人機責任歸屬重新設計）。
• 事前閘門成為承重環節。 因為從生成到產生效果之間沒有紅燈測試——Cowork 的錯誤可能就是寄出一封電子郵件，或在使用者已驗證的 SaaS 工作階段中修改紀錄——驗證不能等到事後。這是 分類器閘門與 OS 沙箱：Auto Mode 和 Cowork 的深度防禦故事以 harness 設計角度重述的發現：Claude Code 可以承受閘門漏接（後方還有 containment），Cowork 則不行，因此分類器／探測層與人工核准檢查點，必須承擔程式碼端由測試承擔的份量。
• 失敗模式分成明顯與隱而不顯兩種。 程式碼會明顯失敗（建置中斷、測試亮紅燈）；非程式碼輸出則可能成為一場看似成功的失敗——一份精美、看似合理卻有錯誤數字的簡報，其表面上的可信度反而會讓審查者卸下戒心。這就是為何語料認為責任歸屬重新設計對 Cowork「更重要，而非較不重要」（人機責任歸屬重新設計）——少了編譯器，消失的不只是檢查器，還有警報。

精簡比較：

答案二：切片驗證器應保留——這是設計如此，不只是因為 4.7 的經驗#

Pocock 根據經驗提出的報告是，規劃器「至少到 4.7 都需要驗證器」：他的 prd-to-issues skill 會在提議的切片屬於水平切片時觸發規則（例如只建立 gamification service），並要求第一個切片涵蓋 schema + service + UI（Vertical Slice Tracer Bullets）。綜合後的答案是，這不是等待模型變得更可信的臨時補丁——驗證器在結構上就是安放這項規範的正確位置，理由有三：

1. 切片形狀是可檢查的不變條件，而可檢查的不變條件應由確定性空間負責。「每個切片都能產生可見的端到端回饋」可化約為近乎機械化的檢查——這張票單是否涵蓋每個層級？這正是潛在空間與確定性空間指出不該交由模型處理的運算，也正是 Agent Harness Engineering 的規則：強制執行不變條件，而非實作。提示詞說明垂直切片的原因；檢查器則強制確認它確實垂直。
2. 約束形式才可靠。 在提示詞中說「垂直切片」是一項行為要求——這類指令在能力提升過程中並不可靠（代理程式預設採用水平切片，可能是訓練資料先驗所致——Vertical Slice Tracer Bullets），而當該行為成為原生能力後，它也容易逐步累積（Instruction Compounding）。確定性驗證器是一項約束：不會逐步累積，每次執行的成本幾乎為零，無論模型的預設傾向朝哪個方向偏移，都能悄悄抓出回歸。
3. 存留者分類法早已將它歸類。 切片形狀檢查器屬於邊界執行——這是耐久的 harness 類型，不會向內遷移；提示詞層級的勸告則屬於會遷移的要求類型（哪些腳手架能在模型改進後存留——以及如何判斷某一行指令何時有害？）。因此，模型進步時的正確發展方向並不對稱：當消融實驗顯示模型已能原生做到時，就刪除提示詞行（「記得垂直切片」）；驗證器則保留，就像模型學會寫出正確程式碼後，測試仍然存在（模型進步時的 Harness 縮減的綜合結論：提示詞腳手架會縮減，機械驗證不會）。

所以答案是：沒錯，它需要驗證器——而問題的問法（「被告知後能否信任它」）已經包含答案的輪廓：被告知是提出要求，而語料明確指出，不能以要求來建立可靠性。信任模型適用於刪除提示詞行，絕不適用於刪除檢查器。

綜合結論#

兩個問題都是「可驗證性」論點在沒有編譯器的介面上的應用。機械檢查可能做到的地方（切片形狀），就應該實作——廉價的確定性驗證器是耐久的 harness，不受模型偏移或指令累積影響。機械檢查無法做到的地方（簡報品質、資料卷宗準確度），harness 就必須分層補足：把品味編碼為機器可讀的限制條件（設計系統），以經過驗證的評審與 evals 評分，在動作送出前設置閘門，並把人工判斷集中在若不加留意、沉默就會被當成成功的檢查點。Cowork 不是少了編譯器的 Claude Code——它展示的是編譯器從未存在時，harness 必須演變成什麼樣子。