Harness Engineering 可以理解成一組讓 AI 產出安全執行的工程機制。Harness 原意包含馬具、束具與控制裝置。放在 AI 輔助開發的情境中，指的是團隊替 AI 生成程式建立一個可執行、可限制、可檢查的環境。
開發者請 AI 產生程式碼後，經常能很快取得看似完整的結果，並放進專案中執行。成果提早出現，錯誤假設、權限問題與不符合規範的內容也可能跟著進入系統。
Harness 能在程式接觸主要系統前，先安排一段受控的執行與驗證流程。受控流程需要明確定義 AI 可以修改哪些檔案、禁止接觸哪些區域、執行時能使用哪些資料、能否連接外部服務，以及產出完成後需要通過哪些測試與檢查。
團隊也可以限制執行權限、資源用量與操作範圍，並保留完整紀錄，方便後續追查問題。
對剛開始導入 AI 輔助開發的團隊來說，可以把 Harness 想成一條「AI 開發用的安全跑道」。AI 在明確範圍內產生與執行程式，未經驗證的內容不會直接碰到正式資料、主要服務與共享環境。
AI 輔助開發容易被理解成一連串簡單動作：輸入提示詞、生成程式碼，再由開發者人工檢查。
這套流程可以加快程式產出，放進複雜系統後卻可能出現不穩定的結果。許多錯誤會等到人工閱讀、整合或後續測試時才會被發現。
Harness Engineering 關注生成、執行、檢查與修正組成的回饋迴路。
AI 生成程式後，系統會先把程式放進指定環境執行，再進行自動化測試、靜態分析、安全掃描與 API 契約驗證，最後整理錯誤訊息與檢查結果。這些資訊會回到 AI 或開發者手上，成為下一次修改的依據。
測試失敗、型別錯誤、API 契約不符與安全規則違反，會提供比「看起來怪怪的」更清楚的品質訊號。AI 進行下一次修改時，也能取得明確的規格限制、錯誤內容與修正方向，減少自行推測的空間。
生成、執行、檢查與修正形成短循環後，AI 輔助開發便能接上既有工程流程。每次修改都留下可追蹤的結果，開發者可以以此判斷哪些問題適合交給 AI 繼續處理，哪些問題需要人工分析與決策。
閱讀 AI 產出的程式碼仍然重要，因為開發者需要理解系統意圖、設計取捨與潛在風險。
只靠閱讀，難以完整確認程式行為是否符合需求。程式碼可能結構清楚、命名合理，實際執行時仍會在例外流程、邊界資料或系統整合中失敗。
Harness Engineering 會先把 AI 產出放進可驗證的流程。需求規格可以轉成行為測試，API 規則可以轉成契約測試，團隊的程式規範可以轉成靜態分析規則，安全要求也能轉成掃描條件。
這些檢查會把主觀判斷轉成明確的驗證結果，讓團隊知道產出是否符合既定條件。
AI 提高程式產出速度後，團隊也需要提高驗證速度。驗證流程無法跟上時，工程師會面對大量待審內容，程式碼審查也可能只剩快速瀏覽。
Harness 可以先處理低階、重複且適合自動化的檢查，讓開發者把注意力放在需求意圖、架構方向與高風險邏輯。
Harness Engineering 也代表一套明確的工作方式。團隊先定義 AI 可以在哪些範圍內行動，再決定產出後要如何執行與檢查，最後把結果帶回修正流程。
這樣一來，AI 產出的程式會先留下證據，再進入後續審查。
AI 生成程式時，會根據提示詞、既有程式碼與常見設計模式推測解法。
需求描述不完整時，AI 會自行補上缺少的流程與設計，讓程式看起來可以運作。這種補完能力能加快開發，也可能讓產出超出原定的需求範圍。
例如需求只要求「新增會員折扣計算」，AI 可能同時加入快取、建立新的折扣類型、調整既有資料結構，甚至修改其他訂單流程。
這些變更可能補足了完整的設計，也可能偏離團隊既定的架構方向。開發者若只確認功能能否執行，便可能忽略新增的耦合、影響範圍與維護成本。
需求邊界需要清楚說明這次任務涵蓋哪些行為與變更範圍。
哪些檔案可以修改、哪些 API 必須維持不變、哪些資料表禁止調整，以及哪些業務規則需要保留，都應寫進生成條件與檢查流程。團隊也可以限制變更檔案數量，並在出現跨模組修改時要求人工確認。
約束 AI 產出可以避免一次看似合理的生成帶入額外設計、隱藏假設與不必要的變更。任務範圍寫得越具體，後續閱讀、測試與程式碼審查時，就越容易看出這次修改碰到了哪些地方。
軟體開發包含許多設計細節，需求文件很難全部列出。錯誤代碼命名、資料驗證位置、交易邊界、日誌格式、例外處理與 API 回傳格式，經常需要依照團隊慣例與既有系統脈絡決定。
AI 沒有取得明確限制時，會採用它認為合理的方式完成程式。這個做法可能不適合目前的系統。AI 可能使用專案中少見的框架功能、加入不同的錯誤處理方式，或把業務規則放在不適合的層級。
這些差異會讓相似功能出現不同寫法，增加理解與修改的成本。
設計細節分散後，也會影響後續維護。下一位工程師處理相似功能時，可能無法判斷應該沿用哪一種寫法。AI 再次讀取專案並生成程式時，也會把既有的不一致視為參考，產生更多不同的實作方式。
AI 生成流程需要把團隊慣例整理成可執行的限制。這些限制可以寫進提示詞模板、程式碼生成規則、靜態分析設定、測試案例與程式碼審查檢查清單。
規則能被反覆套用後，同一類問題便能維持一致的處理方式，AI 也比較不會在每次任務中換一種寫法。
AI 生成程式的約束，不能只寫成一句「請依照最佳實務」。最佳實務過於抽象，也會因技術背景與系統情境不同而產生不同解讀。
較有效的做法，是把約束整理成三個來源：需求規格、架構決策與團隊規範。
需求規格負責說明行為邊界。它會告訴 AI 哪些情境必須成立、哪些情境需要拒絕，以及成功或失敗時系統應該回傳什麼結果。
行為驅動開發（Behavior-Driven Development, BDD）的 Gherkin（Given-When-Then） 範例很適合轉成這類約束，因為它能把抽象需求整理成可執行、可驗證的行為。
架構決策負責限制設計方向。若團隊已經規定業務邏輯只能放在 Domain 層、外部服務必須透過 Adapter 呼叫、跨系統整合需要遵守既有契約，這些條件都應納入 AI 的生成規則。
架構決策紀錄（Architecture Decision Records, ADR）也能提供重要上下文，協助 AI 理解系統限制與過去的設計取捨。
團隊規範則用來維持實作一致性。命名規則、錯誤處理格式、測試寫法、日誌欄位、安全掃描門檻與拉取請求說明格式，都屬於這一類。這些細節會直接影響團隊能否長期閱讀、修改與維護 AI 產出的程式。
約束條件越清楚，AI 的工作範圍就越明確。開發者也能依照同一組條件檢查產出，減少每次程式碼審查都重新判斷標準的負擔。
Harness Engineering 會把需求規格、架構決策與團隊規範接進生成與驗證流程，讓任務先在既定範圍內收斂。
AI 生成的程式進入主要系統前，需要先在受控環境中執行。本地沙箱（Local Sandbox）讓開發者可以快速執行、觀察與驗證 AI 產出，同時避免程式直接影響正式資料、共享環境與外部服務。
沙箱也能限制系統層級的命令執行權限，例如封鎖危險的 Shell 命令、限制網絡出站（Outbound）流量，避免非預期的工具/命令執行。
沙盒環境可以包含獨立資料庫、測試用設定檔、受限的環境變數，以及能夠重新建立的執行狀態。
開發者可以在沙盒中啟動服務、執行測試、查看錯誤訊息，發現問題後也能快速重置環境。這會讓試錯留在可清理的地方，AI 生成內容也能先通過基本的執行與行為檢查。
剛開始建立沙盒的團隊，可以先從基礎設定著手。例如使用 Docker Compose 啟動本地資料庫與相依服務，將測試金鑰和正式金鑰分開，並禁止本地測試流程連接正式 API。
這些設定可以避免 AI 產出的程式在測試期間寫入錯誤資料、發送真實通知，或呼叫未經允許的外部服務。
沙盒能夠穩定重建後，開發者可以先確認程式能否啟動、是否通過基本測試，以及執行過程是否產生異常副作用，再決定是否進入程式碼審查與整合流程。
AI 生成的程式經常需要使用外部依賴，例如付款服務、簡訊服務、第三方 API、檔案儲存、通知系統與其他內部服務。
測試時若直接呼叫這些服務，可能產生成本、污染資料，甚至影響實際業務。因此，Mock 與 Stub 的用途，是把外部依賴控制在可預期的範圍內。
Mock 可以檢查程式是否按照預期方式呼叫外部服務，例如傳入的參數是否正確、呼叫次數是否符合規則，以及呼叫失敗時是否完成必要處理。
Stub 則提供固定回應，避免測試結果受到外部服務狀態影響。例如讓付款服務分別回傳成功、失敗與逾時，藉此檢查 AI 產出的錯誤處理邏輯。
從 Harness Engineering 的角度來看，Mock、Stub 與沙盒環境都能用來隔離風險。
沙盒限制程式在什麼環境執行，Mock 與 Stub 則決定測試期間能接觸哪些外部能力，避免驗證過程直接影響真實資料與業務流程。
Mock 與 Stub 需要反映重要的依賴行為，不能只提供能讓測試通過的回應。測試應涵蓋失敗、逾時、權限不足、資料格式異常與重複呼叫等情境。
若 AI 產出的程式只能處理成功流程，進入正式系統後仍可能在外部依賴異常時發生錯誤。
AI 產出的程式要能被可靠驗證，測試資料與環境狀態就需要重複建立。
若每次執行測試時使用的資料都不同，開發者便難以判斷錯誤來自 AI 產出、測試資料、環境設定，或外部依賴的狀態。
可重複建立的測試資料可以包含固定的種子資料、明確的案例資料，以及每次測試前後的清理機制。
例如驗證會員折扣功能時，需要準備不同的會員等級、商品類型、優惠活動與訂單狀態。這些資料透過腳本自動建立後，AI 產出的程式便能在相同條件下反覆執行與驗證。
環境狀態也需要受到控制。時間、時區、亂數、佇列訊息、快取內容、檔案狀態與資料庫交易，都可能改變測試結果。
這些狀態若未固定，AI 完成一次修正後，下一次執行仍可能出現不同錯誤，讓開發者無法確認修改是否有效。
良好的 Harness 會讓開發者使用同一個指令重建環境、載入測試資料、執行檢查並取得穩定結果。
每次測試都從明確狀態開始，AI 的修正前後就能在相同條件下比較，問題是否已被修正也比較容易判斷。
AI 生成的程式若涉及 API、事件、訊息格式或跨服務整合，就需要透過契約驗證（Contract Verification）保護系統邊界。
契約是不同系統之間約定的互動格式，內容包含請求欄位、回應結構、錯誤代碼、事件名稱、資料型別與必填規則。
AI 可能根據需求描述與現有程式自行調整欄位名稱、增加回應內容，或改變錯誤格式。這些修改在單一服務內可能可以正常運作，進入跨系統流程後，可能造成下游服務解析失敗、前端畫面異常，或事件消費端無法處理資料。
契約驗證會把系統邊界轉成可執行的檢查規則。當 AI 修改 API 或事件格式時，驗證流程會確認變更是否符合既有契約。若出現欄位刪除、型別改變或必填規則調整等破壞性變更，團隊就能在本地環境或 CI 階段發現。
AI 能在短時間內產生大量變更，API 與事件格式也可能在修改過程中被意外調整。契約驗證納入 Harness 後，開發者可以把注意力放在契約是否需要調整、調整理由是否成立，以及這項變更會影響哪些團隊與服務。
AI 產出的程式即使看起來合理，仍需要透過自動化測試確認行為是否符合需求。閱讀程式碼可以協助開發者理解設計與風險，測試則會用具體情境檢查系統面對不同輸入、狀態與例外條件時的反應。
自動化測試會把需求中的行為規則轉成可執行的檢查。行為驅動開發（Behavior-Driven Development, BDD）用 Gherkin 描述使用情境，再將這些情境轉成測試案例。AI 完成程式後，團隊便能依照同一組行為規則驗證執行結果。
測試案例需要涵蓋成功與失敗路徑。AI 可能產生一段可以處理正常輸入的程式，面對空值、權限不足、重複提交、資料不存在或狀態不合法時卻發生錯誤。這些情境若未納入測試，問題就可能進入後續整合流程或正式環境。
在 Harness Engineering 中，自動化測試是一道基本檢查點。AI 產出需要先通過明確的行為驗證，再交由開發者進行設計與風險判斷。
低階錯誤先被攔下來，程式碼審查才比較能聚焦在需求意圖、架構設計與後續維護性。
自動化測試主要確認程式行為，靜態分析（Static Analysis）則能在程式執行前，檢查安全、品質與可維護性風險。
AI 產出的程式可能格式完整、命名清楚，內部仍可能存在重複邏輯、過度複雜的條件判斷、不安全的資料處理，以及不符合團隊規範的寫法。
靜態分析工具可以先處理這些適合機械化檢查的問題。例如型別錯誤、未處理例外、未使用變數、循環複雜度過高、SQL 注入（SQL Injection）風險、密鑰硬編碼、相依套件弱點，以及不符合格式規範的程式碼，都可以交由工具檢查。
這類檢查對 AI 輔助開發很有幫助，因為 AI 在不同任務中可能產生不同的實作方式。團隊若只依賴人工程式碼審查，就需要反覆指出相同問題，增加審查負擔。
將靜態分析納入 Harness 後，許多基本品質問題便能在本地環境或 CI 階段先被攔截。
靜態分析的作用，是把明確規則轉成可自動執行的檢查。規則越清楚，AI 產出就越容易被校準。
工具先處理可機械化判斷的部分，開發者再檢查設計是否符合系統方向、變更是否擴大耦合，以及程式邏輯是否符合業務語意。
AI 產出的程式若修改 API、事件或跨系統資料格式，就需要透過契約測試（Contract Testing）確認系統邊界是否受到影響。
系統之間的互動依賴既有約定，內容包含欄位名稱、資料型別、必填規則、錯誤代碼、狀態碼、事件名稱與版本資訊。
AI 為了補完整程式，可能自行調整回傳格式或加入看似合理的欄位。這些變更在單一服務內可能正常運作，進入前端、下游服務或事件消費端後，卻可能造成解析失敗、欄位對應錯誤或資料判斷異常。單元測試主要檢查服務內部邏輯，未必能完整發現這類跨系統問題。
契約測試會把系統之間的約定轉成可執行檢查。當 AI 修改服務端 API 時，測試可以確認回應是否符合消費端期待。當 AI 調整事件發布邏輯時，測試也能確認事件內容是否符合既有 Schema。
契約測試也能提早提醒團隊，這次修改已經影響其他系統。若契約確實需要調整，團隊就要進入版本管理、相容性評估與下游通知流程，並確認各消費端的調整時程。
這能避免 AI 在生成過程中直接改變系統邊界，讓跨系統變更回到可追蹤的協作流程。
測試失敗只能告訴團隊結果不符合預期，完整的日誌與執行資訊則能協助團隊找出失敗原因。AI 產出需要進入短回饋迴路時，診斷資訊越明確，下一次修正就越能對準問題。
Harness 可以收集測試輸出、錯誤堆疊、執行時間、輸入資料、環境設定與關鍵日誌，再將這些內容整理成開發者與 AI 都能使用的修正訊號。
例如測試案例失敗時，系統除了標示失敗，也應指出發生問題的情境、預期結果、實際結果，以及對應的錯誤訊息與程式位置。
日誌內容也需要明確規範。AI 產出的程式若缺少必要紀錄，錯誤發生後便難以追查。
日誌數量過多或格式不一致，也會增加判讀成本。團隊可以先定義重要流程需要記錄的欄位，例如請求識別碼、使用者識別、交易狀態、外部服務回應與錯誤分類，並限制敏感資料不得寫入日誌。
Harness 應具備「日誌洗滌」能力，僅提取最核心的錯誤訊息、行數與差異對照，避免丟入冗長日誌。避免造成上下文爆表、Token 成本飆升，甚至引發 LLM 無法精準聚焦關鍵錯誤的現象。
日誌與執行結果能穩定提供診斷資訊後，AI 便能根據具體訊號進行修正。開發者也可以判斷問題來自需求理解、程式邏輯、測試資料或環境設定，而不必只靠最後一行錯誤訊息猜測原因。
Harness Engineering 若要進入日常開發流程，可以先從提交程式前的檢查開始。Pre-commit Hook 是開發者在提交程式碼前自動執行的檢查點，適合放入格式化、Lint、型別檢查、簡單單元測試與敏感資訊掃描這類靜態程式碼分析。
這個階段的目標，是把低成本、快速回饋的問題提早攔下。AI 產出的程式若有格式不一致、未使用變數、型別錯誤、明顯違反命名規範，開發者不需要等到拉取請求（Pull Request, PR）才發現。
前端專案可以搭配 ESLint 檢查 JavaScript 或 TypeScript 程式碼，後端服務也可以依語言選擇對應的分析工具檢查格式與常見品質問題。
Pre-commit Hook 適合處理明確、快速、可重複的檢查。它不適合放入執行時間太長的完整測試，否則會打斷開發節奏。
團隊可以把它視為第一層護欄，先確認 AI 產出的程式沒有基本品質問題，再讓變更進入本地驗證或 拉取請求流程。
當開發者使用本地編碼代理（Local Coding Agent）協助修改程式時，Harness 可以直接放在代理運行環境裡。
這個位置很重要，因為 AI 在產生與修改程式時，會同時讀取檔案、執行指令、觀察錯誤，再根據結果繼續調整。
本地沙箱可以用 Docker 建立。團隊可以準備 Docker Compose，啟動測試資料庫、Mock 服務、Stub API 與必要的背景服務，讓 AI 產出的程式在受控條件下執行。
這樣可以避免 AI 在測試時連到正式資料庫、呼叫真實付款服務，或寫入共享測試環境。若功能涉及外部依賴，團隊也可以用 Mock Server 或 Stub 回應固定資料，讓測試結果比較穩定。
在這個階段，AI 可以被允許執行特定指令，例如安裝相依套件、跑單元測試、跑局部整合測試或啟動服務。
不過指令範圍需要被限制，例如禁止讀取正式金鑰、禁止存取正式環境、禁止修改特定目錄。這些限制能讓 AI 在本地加速嘗試，也讓開發者保留安全邊界。
當 AI 產出的程式進入拉取請求，Harness 機制就需要進入持續整合與持續交付管線（Continuous Integration and Continuous Delivery Pipeline, CI/CD Pipeline）。
這一層檢查代表團隊共同接受的合併門檻，結果不再只影響個人開發環境，也會影響整個專案是否允許變更進入主幹。
CI/CD Pipeline 可以放入較完整的驗證，例如完整單元測試、整合測試、契約測試、安全掃描、依賴套件檢查、程式品質分析與建置驗證。
SonarQube 適合用來觀察程式品質、安全熱點、重複程式碼與複雜度。Pact 可以用來做契約測試，確認 API 提供端與消費端之間的約定沒有被 AI 產出破壞。靜態程式碼分析工具也可以在 CI 中再次執行，避免有人略過本地檢查。
CI/CD 的價值，在於把團隊規範轉成共同且可追蹤的規則。
當 AI 產出的程式違反契約、測試失敗或品質門檻未通過，管線會把結果呈現在拉取請求的內容中。開發者可以根據這些訊號修正程式，審查者也能先看到自動化檢查結果，再集中討論需求意圖、架構方向與高風險邏輯。
只把工具擺進流程，不會自動形成 Harness。團隊需要先定義每個工具出現的位置，以及它負責攔下哪一類風險。
Pre-commit Hook 適合處理快速品質檢查，本地沙箱適合支援 AI 在受控環境中嘗試，CI/CD Pipeline 則適合建立合併與交付前的共同門檻。
完整的流程可以是：AI 在本地代理中修改程式，Docker 沙箱提供可重複執行環境。開發者提交前由 Pre-commit Hook 執行 ESLint 或基本測試。拉取請求建立後由 CI/CD 執行 SonarQube、Pact、完整測試與安全檢查。檢查結果再回到開發者與 AI，作為下一輪修正的依據。
這樣的設計能讓 Harness 成為一條分層的安全跑道。越靠近個人開發環境，檢查越快、越輕量。越靠近合併與部署，檢查越完整、越嚴格。
AI 可以在這條跑道上快速產出與修正，團隊則透過工具、流程與人工判斷，確認產出是否能進入後續交付。
AI 產出的程式在測試失敗後，不能只把原始錯誤訊息直接丟回修正流程。錯誤訊息多半零碎，AI 可能只修正表面問題，沒有理解真正失敗的行為。
Harness Engineering 需要把失敗結果整理成 AI 可以使用的修正訊號。完整的修正訊號應包含測試情境、預期結果、實際結果與相關限制。
例如訂單折扣測試失敗時，回饋內容若只寫「執行失敗」，AI 很難判斷規則差異。較明確的描述是：「會員等級為 Gold、商品類型為一般商品，且活動折扣已套用時，系統應回傳九折後的金額，實際結果卻套用了八折」。
這類回饋能讓 AI 對準行為差異，避免只根據錯誤行數修改程式。測試名稱、Gherkin 描述、失敗時的輸入資料、預期輸出、實際輸出與限制條件，都可以納入修正訊號。
開發者也需要避免讓 AI 在缺少脈絡的情況下反覆嘗試。若同一類測試多次失敗，問題可能來自需求理解、測試資料、架構位置或規格內容。
這時應先由開發者判斷失敗來源，再決定是否交由 AI 繼續修正。
AI 修正程式時，只提供錯誤訊息多半不夠。錯誤訊息能指出失敗位置，規格與限制則能說明修正方向。若只提供失敗堆疊，AI 可能採用最短路徑讓測試通過，同時帶入新的設計偏差。
較穩定的做法，是把三類資訊一起回饋給 AI。第一類是執行結果，例如測試失敗、型別錯誤、靜態分析警告、安全掃描結果與契約測試錯誤。第二類是需求規格，例如使用者情境、驗收條件、Gherkin 範例與例外規則。第三類是工程限制，例如可修改的檔案範圍、不得變更的 API 契約、禁止引入新套件，以及必須沿用的錯誤格式。
這些資訊會形成明確的修正邊界。AI 能掌握失敗位置，也能知道哪些修改方式不可採用，才不會為了通過單一測試而改動其他模組或破壞既有設計。
例如契約測試指出回應欄位格式錯誤時，回饋內容應包含失敗的契約規則、既有 API Schema、消費端期待格式，以及「不得修改公開 API 欄位名稱」等限制。AI 才能在既定邊界內調整服務端邏輯，保留現有系統契約。
動態修正不適合一次要求 AI 大幅重寫整個功能。較穩定的做法，是讓 AI 在短循環中處理小範圍問題。每一輪只處理一組失敗原因，完成修改後重新執行測試與檢查，再根據新的結果進入下一輪。
短循環可以降低變更風險。AI 一次修改太多檔案時，開發者很難判斷哪些修改解決了問題，哪些修改又帶來新的錯誤。
每輪修正都限制在明確範圍內，檢查結果就較容易理解，程式碼審查也能集中在該次變更。
流程接著形成固定節奏：AI 產生修正、Harness 執行測試、系統整理失敗結果，再由 AI 根據回饋進行下一次調整。
每一輪都保留變更紀錄、測試結果與修正依據，讓開發者能追蹤 AI 修改了哪些內容，以及每次修改帶來的影響。
每一次修正後的驗證，不能只執行失敗的測試，必須自動重新執行全套單元測試，確保無新產生的副作用，避免出現修正了 A 測試，卻意外弄壞原本通過的 B 功能」的現象。
短循環也能協助團隊提早辨識方向錯誤。若 AI 連續幾輪都無法解決同一個問題，可能代表輸入脈絡不足，或需求、測試與設計之間存在不一致。此時應先由開發者重新檢查規格、架構與測試資料，再決定後續修正方式。
AI 可以協助快速嘗試修正，停止點仍需要由開發者決定。自動修正若缺少界線，AI 可能為了通過檢查而改動過多內容，也可能沿著錯誤方向反覆調整，增加程式理解與維護的難度。
自動修正迴路也應設定 Token 使用上限（Cost Budget Guardrail），防止 AI 在小錯誤上陷入死循環並消耗大量 API 額度。
團隊可以先定義停止條件。例如同一個問題修正超過三輪仍未通過、修改範圍超出原定檔案清單、AI 嘗試變更公開契約、需要新增套件，或測試已通過卻出現架構偏移。
遇到這些情況時，流程應停止自動修正，交由開發者判斷問題來源與後續處理方式。
進入程式碼審查後，開發者除了確認最終測試結果，也需要檢查 AI 修正過程留下的紀錄。
審查內容包含修改了哪些檔案、移除了哪些邏輯、是否繞過既有測試、是否改變原定設計意圖，以及修改結果是否增加後續維護成本。
Harness Engineering 讓 AI 能在受控環境中生成、執行、檢查與修正，也保留開發者的最終判斷權。AI 可以加快嘗試，開發者仍要根據完整紀錄判斷產出能否進入正式審查與後續交付。
iThome鐵人賽
看影片追技術