先說結論
最近回頭看自己的 AI 使用方式，我發現一件很有意思的事。
我幾乎不會把每個步驟一條一條寫死給 AI。
我平常說的，大概就是：「我想贏」「把我的工作量降下來」「不要半路停掉」「確認到底有沒有真的做完」。
很粗。真的很粗。
但只要認真去滿足這種粗粒度目標，AI 就會被迫把條件拆開、定義完成標準、設計驗證方法，並在曾經失敗的地方繼續加上防護欄。
結果，流程慢慢從「人每次都親自檢查」變成：讓 AI 做、讓 AI 查，再用外部證據核對，只把異常交回給人。
查了一圈後才發現，這和 OpenAI 在 2026 年公開的一套「AI 運行環境工程」做法很接近。OpenAI 將這類做法稱為 Harness Engineering；簡單說，就是為 AI 代理設計運行環境、約束、工具和回饋迴路，讓它能在明確邊界內自主完成工作。
人負責意圖和邊界，AI 代理負責執行。
不過，這種方法在個人專案裡很強，一進公司就會突然變難。
個人專案是沒有政治的獨裁國家。
一搬進公司，議會立刻開會。
起點只有兩個：想贏，想少做一點
上層目標簡單得離譜。
玩卡牌遊戲時，我想贏。
做文章流程或自動化時，我想減少自己要做的事。
這兩個目標非常強。
做模擬器、跑大量對局、加入搜尋演算法都可以。
但最後只剩一句：「所以勝率提高了嗎？」
做文章自動處理、多語言、品質檢查、佇列、雜湊、重試也都可以。
但最後還是一句：「所以我的工作變少了嗎？」
技術可以愈來愈複雜，目的卻不需要一起變複雜。
因為目的很穩，具體手段就可以很大膽地交給 AI。
不把每一步寫死。需要時，連「應該是什麼樣子」也讓 AI 一起推導
人沒有必要每次都從零開始設計完成條件。
例如只給一個目標：
「把最新文章在不需要人介入的情況下，以正確狀態一路送到正式發布。」
接著可以讓 AI 自己往下拆：
- 「最新」到底按什麼判斷
- 「正確」到底是什麼意思
- 翻譯是否對應目前原文
- 原本要處理 50 筆，只成功 1 筆就結束，算不算完成
- 只提交到 GitHub 能不能叫作「已發布」
- 是否還需要檢查真實網站
也就是說，人主要握住的是目標和不可違反的條件，更細的驗收標準可以讓 AI 展開。
當然，AI 產生的標準本身也可能出錯。
所以接下來仍然需要驗證。
我大量使用 AI，但「AI 說做完了」不算證據
從外面看，很像把一切都丟給 AI。
其實也差不多：執行丟給 AI，檢查也丟給 AI。
本人最好連日誌都不要看。
理想狀態是：
執行 → 自動檢查 → 正常就簡短報告 → 異常才帶著原因和修復方案回來。
重點是，不能把 AI 的自我申報直接當成完成條件。
不是一句「做完了」就結束，而是去拿可以從外部觀察的東西：處理數量、測試結果、雜湊值、GitHub 上實際存在的檔案、真實網址、線上頁面內容等。
如果只是讓同一個 AI 在同一段上下文裡「檢查一下自己剛才做的事」，它很可能把同一個誤解重複兩遍。
所以更強的結構會把產生、檢查、外部證據拆開。
人不需要把所有內容都親自讀一遍。
但也不能只接受一句「已經確認」。
說得粗暴一點就是：
「我不看。你去查。但把證據拿回來。」
每一個卡點，都是「這裡還殘留著人工工時」
如果真的想把工作量壓下去，中間那些小小的手動作業都會變得非常刺眼。
每次都得在這裡點一下。
這個例外只能靠人判斷。
失敗以後還得有人去看日誌。
發布之後還得人工確認。
一般做法很容易變成：「算了，這一點手工就手工吧。」
但如果目標本來就是「減少我的工作」，那它就是尚未完成的項目。
只要發現某一步必須靠人努力才能成立，就代表那一步的設計還沒有結束。
這樣一來，錯誤就不只是事故。
如果系統本來應該跑 50 筆，卻跑 1 筆就正常退出，不是把剩下 49 筆補跑完就結束。
要問的是：「為什麼跑 1 筆也能被判定成正常完成？」
如果舊翻譯被當成最新版，也不是只改那一篇。
要把規則改到：「為什麼舊翻譯以後不能再被判成正常？」
失敗不斷升級成規則，人類的工作就會一點一點消失。
會說「我不懂」的主管還算好。更可怕的是把現實改掉的評審
2026 年 8 月，Zenn 上有一篇文章《AI 讓我們的生產力變成 3 倍，也讓我們把團隊落在了後面》，談到 AI 使用速度加快後，主管已經無法充分評審成員產出的情況。
裡面有一句很有代表性的話，大意是：「我目前還不能完全理解，但我覺得你說的是對的。」
作為評審，這當然不算強。
但管理上還有一種更危險的情況。
明明不懂，卻為了維持上位者的位置，在事後改寫事實和標準。
事前沒有標準，看到結果以後再說「正常人當然會這樣做」。
你去詢問，他說「自己想」；你自己往前推，他又說「誰叫你擅自做的」。
到了這一步，大家就不是在往正確答案靠近了，因為「正確答案」本身會移動。
反過來，如果一個人能承認「這個我現在評不了」，就還有補救空間：增加專業評審、把檢查項目自動化、強制輸出依據和未確認事項。
能力不足可以補。
會移動的判定標準，會直接把品質保證系統本身拆掉。
現在回頭看，我大概知道自己為什麼討厭「儀式化品質改善」了
品質管制，也就是常說的 QC，小組活動原本的目標，是讓第一線小組持續改善品質和工作方式。
日本科學技術聯盟對 QC 小組的說明，同樣把它描述為第一線員工持續進行管理和改善活動。
問題不是品質管制本身。
問題出在「真正改善」讓位給「把品質改善的樣子完整演出來」的時候。
先弄一個主題。
做幾張圖。
套進一套固定的 QC 改善步驟。
做發表資料。
評審。
鼓掌。
結束。
這就不是持續改善，而是「持續改善角色扮演大賽」。
相比之下，現在用 AI 跑的循環反而樸素得多。
失敗。
找原因。
找重現條件。
修改退出條件和檢查規則。
再跑。
確認同一種失敗以後不能再偽裝成「正常完成」。
沒有漂亮的發表會。
但下一輪確實會少一點人工工時。
諷刺的是，這反而更接近品質管制最初那種「持續改善」的味道。
回過神來，已經很像 OpenAI 的 AI 運行環境工程了
OpenAI 在 2026 年 2 月公開了 Harness Engineering，介紹以 Codex 為中心、由 AI 代理主導的開發方式。這裡所說的「AI 運行環境工程」，指的是把環境、規則、工具、檢查和回饋設計好，讓 AI 可以在安全邊界內自主推進工作，而不是靠人逐步下指令。
文章中提到，他們替內部產品設定了「人工手寫程式碼 0 行」的限制，並估算整體建置速度大約是傳統手寫方式的 10 倍。
真正重要的並不只是快。
更關鍵的是：人的主要工作從寫程式碼，轉向設計環境、表達意圖、建立回饋迴路。
OpenAI 還強調，邊界、正確性、可重現性這類關鍵約束應該集中強制執行；在這些邊界之內，則給 AI 代理很大的自主空間。
這和這裡的做法非常像。
「怎麼實作」不用每一步都管。
但「這些東西絕對不能破」要明確。
一旦失敗，就把失敗變成下一輪的文件、測試、靜態檢查或工具規則。
本人也許只是單純覺得「細節太麻煩，我不想看」，最後卻自然變成了替 AI 代理搭一套能自己繼續跑下去的腳手架。
不是先學了思想再實踐。
是因為懶，從另一條山路爬到了同一座山頂。
這點還挺好笑。
個人專案是零政治的獨裁國家。公司裡則會開議會
個人專案裡，這種方法特別強。
所有者是自己。
使用者是自己。
評審者也是自己。
成功的定義者還是自己。
「想在卡牌遊戲裡贏」，就看勝率有沒有上升。
「想少做一點」，就看人工介入有沒有減少。
目標函數只有一條，所以無論 AI 在中間做出多複雜的系統，最後都可以拉回兩個非常簡單的問題：
所以更能贏了嗎？
所以我的工作變少了嗎？
個人專案就是一個沒有政治的獨裁國家。
而且獨裁者還很懶，於是 AI 官僚體系瘋狂自動化。
公司就不一樣了。
你說「減少工時」，馬上會長出一串其他目標：現場操作習慣、稽核、審批權、既有系統、責任、績效、部門存在感。
《哈佛商業評論》在 2025 年討論企業導入 AI 時，也把主要障礙概括為人員、流程和組織政治，而不只是單純的技術問題。
個人專案裡，確定目標狀態之後，讓 AI 最佳化就行。
公司裡，連「目標狀態應該是什麼」本身都要談判。
而且不是所有政治都毫無意義。
為了稽核和問責而保留人工審批，可能非常合理。
但也可能只是因為有人不想失去審批權。
對 AI 來說，這兩種情況最後都只是同一個約束：「需要人工批准」。
這個約束到底該不該存在，最後仍然是人類社會的問題。
最後：也許人真正需要握住的，只剩「目的」和「現實」
AI 時代，人不一定還要親自設計所有步驟、完成所有實作，再親自檢查全部結果。
確定目的。
讓 AI 產生目標狀態和標準。
讓 AI 實作。
讓 AI 檢查。
拿外部證據核對。
失敗了，就把失敗變成下一輪規則。
還有人工工時，就把那裡列為下一個改善對象。
如果這個循環能穩定運作，人對每個實作細節的了解需求會明顯下降。
但仍有兩個問題很難完全外包：
我們到底想實現什麼？
這個目的和現實真的一致嗎？
所以最終的角色分工，也許會愈來愈像這樣：
人：決定目的，觀察現實。
AI：填滿中間的一切。
個人專案裡，非常舒服。
放進公司，議會開會。
政治依然很強。
