最近認真、仔細讀了一份今年八月才發布的官方文件，把整套用 AI 開發軟體的流程，完整整理成一個六階段的迴圈。讀完之後心裡有一種很奇妙的感覺，前面憑著每天實際踩過的坑慢慢摸索出來的習慣，幾乎每一項都能對到這份地圖裡的某一格。完全不是我抄了這份文件才這樣做，是先做了才發現，原來這些做法早就有一個更完整、更成熟、更嚴謹的架構把它們框在一起。今天想花一整篇完整的篇幅，好好把這個對照講清楚，不留任何模糊地帶。
這件事也讓我重新認真、仔仔細細地想了很久，自己這整套習慣到底是怎麼一點一點長出來的。回想起來，沒有一個環節是先讀了什麼理論再照著做，全部都是遇到一個具體的麻煩，想辦法解決，解決完覺得這個做法還不錯，下次遇到類似的情況就繼續用，慢慢累積成一套習慣。這種從實作裡長出來的東西，好處是每一條都經過真實情境的驗證，不是憑空想像出來的，壞處是零散，彼此之間的關聯性得靠自己慢慢摸索，不像一份設計完整的架構文件，一開始就把整體的脈絡講清楚，讓人一眼就能看懂每一塊拼圖該擺在哪個位置。
這份文件講的核心概念，簡單來講一句話，就是要把傳統一條直線走到底的軟體開發流程，徹底改造成一個完整的六階段迴圈，分別是規劃、設計、建置、測試、部署、維護，六個環環相扣、缺一不可的階段。每個階段結束的時候，都必須把這一階段的產物提交進版本控制，下一個階段從讀取這份產物開始接手，而不是憑空、憑印象接手。整條鏈完整串起來大致是這樣，先有一份講清楚問題跟目的的意圖文件，接著變成一份講清楚規格的設計文件，再變成一份講清楚具體怎麼動手的計畫文件，然後是實際的程式碼改動跟測試，再來是真正通過審查的合併請求，最後如果真的出了事故，事故紀錄又會變成下一輪的意圖文件，整個迴圈重新轉動一次。
這條交接鏈最讓我佩服的地方，不是每一份文件個別看起來多完整、寫得多漂亮，是它們串起來之後，變成一條完整的稽核軌跡。任何一個階段出了問題，都可以順著這條鏈往回找，找到是哪一份文件、哪一個判斷出了偏差，不用靠人的記憶去拼湊當初到底發生了什麼，這種可回溯性，本身就是對抗遺忘、對抗時間拉長之後細節失真最有效的辦法。這種設計思路，跟我自己在維護規則檔的時候堅持要留下來歷的想法，根本是同一件事的不同應用，只是這次應用的對象從一份規則檔，擴大成整條開發流程本身。
這個設計最讓我在意的一句話，是人類的判斷力始終留在這個迴圈的上方，負責核准跟究責，不會被任何一個階段吃掉。這句話讀起來平淡，但它其實回答了一個我一直隱隱約約在處理、卻沒有講得這麼清楚的問題，AI 做得越多、越快，人到底該站在哪個位置。答案不是站在每一個細節旁邊盯著，是站在整個迴圈的上方，決定每一階段的產物能不能被接受。
這句話之所以讓我特別有感觸，是因為我自己一路走過來，也隱約一直在往這個方向調整，只是一直沒有找到一個夠乾淨、夠精準的說法把它講出來。剛開始接觸這整套工作方式的時候，很直覺地會想盯緊每一個細節，覺得只有這樣才安心，才對得起自己該負的責任。慢慢發現這種盯法根本撐不住，AI 動作的速度一旦快起來，人根本跟不上，盯細節反而變成整個流程裡最慢的那一段，慢到拖累了整體的效率。後來調整成不盯每一步、只盯每一階段的產出，才真正找到一個跟得上速度、又不會把判斷力完全交出去的平衡點，這份文件把這整個調整過程，用短短一句話講得比我自己反覆想過好幾次還要更清楚、更精確。
規劃階段的產物是一份意圖文件，內容包含問題是什麼、預期的結果是什麼、會影響到哪些人跟系統、有什麼限制、還有哪些問題還沒有答案。這份文件寫完，由負責的人核准，之後的每一步都從這份文件出發。
這幾個欄位分開來看，每一個都不算特別新穎的概念，這些道理其實大家多少都懂，但把它們湊在一起、規定成每次都要填的固定格式，效果比單獨看每一項要大得多。固定格式最大的好處，是它會逼著寫的人，去面對自己原本可能刻意迴避的問題，像是限制條件這一欄，如果沒有這個欄位，很容易在興頭上直接跳過，不去正視這件事實際上會受到什麼制約，有了這個欄位，等於是強迫自己在動手之前，先誠實面對一次現實的邊界在哪裡，而不是等到撞上邊界才發現當初完全沒想過這件事。
這跟我前面講過的逼問需求，根本是同一件事的兩種說法。當時講的是，需求講得再順，都可能只是講得順而已，得反覆逼問才能把真正的問題挖出來。逼問到最後產出的東西，其實就是這份意圖文件，只是我當時沒有特別把它命名成這樣。差別在於，這份文件裡特別列了一節專門放還沒有答案的問題，這個做法我覺得比我當時的做法更進一步，因為它把「還不確定」這件事本身也變成一個正式的、會被記錄下來的欄位，而不是留在對話裡講完就算了。
以前逼問完需求，那些還沒想清楚的地方，通常就這樣散落在冗長的對話紀錄裡，沒有人特別把它們集中起來。等到後面真的卡到那個沒想清楚的環節，才回頭去翻對話紀錄，往往要花不少力氣才能找回當初到底是哪裡沒討論清楚。專門留一節記錄未解問題，等於是把這件事從「靠事後回想」變成「當下就攤開來看」，這個小小的欄位設計，我覺得比整份文件其他部分都更值得學起來直接套用。
設計階段的產物是一份規格文件，講清楚具體要做成什麼樣子。這個階段最關鍵的一個機制，是組織累積下來的規範，像是品牌調性、安全要求、法遵要求，是在寫規格的當下就被套用，而不是等到幾週後審查的時候才被發現不符合。
這種「規範在寫的當下就套用」的設計，讓我想到一個自己一直深信不疑的道理，與其事後糾正，不如一開始就把犯錯的空間收窄。事後糾正的成本，不只是改動本身的成本，還包含了已經投入下去、後來發現方向錯了那部分的心力損耗，這部分損耗是收不回來的，沒辦法透過事後補救把它要回來。一開始就把規範放進來，等於是把犯錯的空間先收窄一輪，就算後面還是難免出現需要調整的地方，範圍也會小很多，不至於整段推翻重來，重頭再走一次同樣的路。
這件事直接呼應了我講過的，畫面跟架構要先吵完架再動手。當時的重點是先把爭議攤開來，用 artifact 做出可以看得到的版本讓人判斷，不要等到動手做完才發現方向錯了。官方這份文件把這個道理講得更明確，把規範檢查提前到設計階段，本質上跟「先吵架再動手」是同一種思路，都是把成本高的錯誤盡量往前挪，挪到修正成本還很低的階段。
這個「往前挪」的思路，講起來簡單，我自己卻是花了不少次踩坑才真正體會到的。早期的做法是先讓東西動起來，規範跟品味這種比較主觀的東西，等後面看得到成品了再來調整。這樣做的問題是，等到成品出來才發現方向不對，要改的往往不是表面的細節，是牽一髮動全身的結構，改起來的代價跟一開始就講清楚，完全不是同一個量級。官方文件把這個道理講得更直接，規範不是審查階段才登場的角色，是從設計那一刻就該在場的角色，這句話等於把我自己摸出來的教訓，講成了一條該被寫進流程裡的準則。
建置階段講了一個我覺得整份文件裡最扎實、也最值得直接搬來用的部分，三層護欄。第一層是機構知識，把每次犯錯改正的內容寫回一份精簡的檔案，這份檔案在每次工作開始的時候都會被完整讀入，所以必須保持精簡。第二層是建議性的政策控制，用來確保某些做法被一致套用，但不是強制的。第三層是決定性的強制控制，直接擋掉或放行，不需要人參與，像是擋掉對受保護路徑的編輯、自動跑格式化工具、把憑證擋在改動之外。
這三層的排列順序，我覺得也藏著一個值得反覆留意的邏輯，越往上一層，涉入的判斷力越強，能造成的傷害也越大，所以越往上一層，反而要越謹慎地限制它能做的事，不能讓權限跟判斷力一起無限往上膨脹。第一層機構知識最溫和，就算寫得不夠好，最多也只是讓工作效率打點折扣。第二層建議性政策已經開始涉及該不該這樣做的判斷，但終究還是建議，不服從也不會直接出事。第三層決定性控制最強硬，直接決定了能不能做，正因為它的力道最重，才需要用最明確、最不依賴判斷力的方式去設計，不能讓任何模糊地帶偷偷滲透進來。
這三層護欄，我一眼就認出來是我前面講規則檔維護的那一天在講的同一件事，只是講得更有系統。同一個錯誤犯兩次，修正就該寫回那份檔案，這條規則我自己也在用，官方文件把它寫成一條明講的準則。更關鍵的是它把「建議」跟「強制」分成兩層，這個分法補上了我當時沒有講清楚的一塊，有些規則只能靠提醒，真正不能出錯的地方，得靠寫死的機制擋掉，不能只靠一份寫得再仔細的文件期待大家自己遵守。
這個分層讓我重新想了一遍自己規則檔裡的每一條內容，哪些其實只是提醒，哪些真的攸關安全、不能有任何僥倖空間。以前這兩種混在同一份規則檔裡，讀起來語氣都差不多，很難一眼分辨哪一條真的不能妥協。分成兩層之後，才發現原來絕大多數的內容都只是建議性質，真正需要寫死擋掉的沒有想像中那麼多，這個發現本身也讓我對規則檔該有多長，多了一層新的判斷依據，不是每一條規則都值得用同樣重的方式去對待，也不是每一條都需要被寫死才能真正發揮作用。
測試階段有一個修 bug 的固定順序，先寫一個會失敗的測試、提交，再要求在不改動測試的前提下讓它通過。這個順序本身就是一種防呆，防止用改測試的方式偷渡過關，而不是真的把問題解決掉。另外還區分了兩種檢查，一種是整個任務跑的過程中反覆做的自我檢查，另一種是任務做完之後、換一個全新的視角重新做的最終確認，兩種各有各的用途，缺一不可。
這個修 bug 的固定順序，讓我想起自己前面提過的一個很好用的判準，問「換一個合理的替代實作，這些斷言會不會照樣通過」。先寫一個會失敗的測試再提交，本質上就是在強迫自己先確認這個測試真的抓得住問題，如果測試寫完就直接過了，那代表這個測試根本沒有真正測到重點，這種順序把「測試本身有沒有效」這件事，變成一個可以被驗證的步驟，而不是憑感覺相信測試寫得夠仔細。
這跟我一直強調的驗證不自驗，是同一個原則的兩種實作方式。自己不能既是球員又是裁判，這件事我在講除錯跟審查的時候都提過，這份文件把它落實成一個具體的機制，任務跑的當下用一種檢查方式，跑完之後換一個乾淨的視角再檢查一次，兩種檢查的目的跟時機都不一樣，不能互相取代。
這個區分乍看只是一個小小的名詞定義，實際想過一輪之後，讓我意識到自己以前有點把這兩種檢查混為一談，覺得只要有做檢查就算數，只要有一道流程掛著檢查的名字就夠了，沒有特別在意檢查發生的時機跟檢查者的視角乾不乾淨。過程中的自我檢查，抓的是明顯的、當下就看得出來的問題，這種檢查因為還帶著剛做完這件事的思路，很容易漏掉自己一開始就沒想到的盲點。跑完之後換一個全新視角的檢查，抓的正是這種盲點，因為它沒有被前面的思路綁住，能用一種比較陌生的角度重新審視整件事。兩種檢查各自負責不同種類的問題，缺一種都會留下漏洞。
部署階段講的核心原則，是職責分離必須被保留，因為寫出這段程式碼的那個角色，沒有辦法核准自己寫的東西。真正碰觸到正式環境的動作，會被一道強制關卡卡住，卡住的條件如果不滿足，這個動作就是不能執行的，不是等人事後發現才補救。
這種把關卡直接嵌進流程裡的做法，跟單純訂一條規則要求大家遵守，效果完全不一樣，差別大到幾乎是兩種不同等級的可靠性。規則寫得再清楚，終究要靠人自己記得、自己遵守，總有疏忽的時候，再自律的人也不例外。關卡嵌進流程之後，不遵守就是動作直接被擋下來，根本不會走到需要靠記性或自律的那一步，這種設計把整件事的可靠程度，從依賴人的自覺，提升到依賴系統本身的結構，這個提升我覺得是這份文件裡分量最重的一個轉變，也是最值得帶回自己日常工作裡的一個轉變。
這件事跟我講規模化 code review 那天反覆強調的核心想法完全對得上，一個人可以靠自己的判斷力決定審得夠不夠，一群人合作的時候，光靠判斷力不夠，得靠一套讓人事後也能查核的流程。這份文件把這個道理套用到部署這個更高風險的動作上，寫程式的角色跟核准部署的角色，天生就不能是同一個，這條界線劃在流程裡，不是劃在信任裡。
這句「劃在流程裡，不是劃在信任裡」，我覺得是整份文件裡最值得反覆咀嚼、放在心裡慢慢回味的一句話，短短幾個字，卻把整套設計的核心邏輯講得非常精準。信任這種東西沒辦法被穩定地複製，今天信任這個角色，不代表明天遇到不同的情境還會做出一樣可靠的判斷。流程不一樣，流程一旦設計好，不管換誰、換哪個角色去執行，結果的可靠程度都差不多，這才是真正能規模化的東西。我自己在講規則檔跟審查流程的時候，反覆繞著同一個道理打轉，這句話算是把那個道理，用最精簡的方式講了出來，比我自己講的任何一種說法都更直接。
信任跟流程這兩種依靠，適用的規模其實完全不一樣，越早搞清楚這件事，越不會在錯的階段選錯依靠的東西。人數少、彼此夠熟悉的時候，靠信任運作起來反而比較輕鬆自然，不用花力氣去設計一套完整的流程。規模一旦大起來，信任的成本會急遽上升，因為要維持同樣程度的信任，需要花更多時間去認識、去確認每一個角色的可靠度，這個成本遠比設計一套流程還要昂貴，而且會隨著規模一起持續放大。這也是為什麼這份文件會特別強調流程而不是信任，它描述的場景，本來就是一個規模已經大到信任撐不住的組織，換成一個小團隊來讀，很多做法可能反而顯得太重。
維護階段裡最讓我印象深刻、反覆回想的設計，是異常的偵測完全交給不涉及模型判斷的決定性腳本去做，只有真正超出正常範圍一定程度，才會讓模型介入，而且介入的第一步永遠是唯讀的診斷，要再往上一個門檻，才輪到可以真正採取行動，而且能採取的行動也僅限於開一個進審查關卡的請求，或者觸發一個事先就核准過的固定處理程序。診斷完的結果，會被寫成跟規劃階段同樣格式的意圖文件，整個迴圈就這樣接回最開頭，重新轉一次。
這種分級反應的設計，跟前面反覆提過的模型資源分層，其實是同一套思路的延伸應用，只是這次套用在異常偵測跟回應這件事上。機械性的偵測用最便宜的方式做，真正需要判斷力的地方，才動用比較貴的資源，而且動用的深淺也要分層，不是一有異常就急著把最強的資源跟最大的權限一次全部打開。這種分層做得越細，整套系統浪費在小題大作上的成本就越低，也越能把真正該被謹慎對待的事，留給真正謹慎的處理方式，不會讓小事跟大事互相搶奪同一批有限的注意力。這種分級反應的設計，我覺得特別值得細看，也特別值得直接搬回自己的日常工作裡試著套用一次。小幅度的異常只記錄下來，不去驚動任何人，這件事本身就避免了一種很常見的浪費，把注意力耗在還不算嚴重的波動上。中等程度的異常才讓模型去看，而且看完只能講、不能動手，這一層卡得很巧妙，模型的判斷力在這裡發揮作用，但風險還是被限制在唯讀的範圍裡。只有真正嚴重的異常，才會打開讓模型可以真正動手的權限，而且動手的方式也被限制在兩種安全的路徑裡，一種要先過審查關卡，一種是照著事先講好的固定程序走，模型沒有辦法憑自己的判斷力直接做出任何全新的、沒被預先核准過的動作。
這跟我講除錯跟規則維護那幾天的精神完全一致，查清楚問題只是一半，真正的完成是把學到的東西寫回一個下次會被讀到的地方。差別是這份文件把「寫回去」這件事，跟「重新規劃」直接接在一起，變成同一個閉環的兩端，讀到這裡我才真正理解，為什麼我自己講的那套習慣，感覺上一直卡在最後一步收不了尾，因為它本來就該接回最開頭，不是一條走到底就結束的直線。
這個發現讓我重新、也更徹底地檢視了自己以前對「維護」這件事的理解。以前會把維護想成整條流程的尾巴，做完前面所有事情之後，才輪到維護出場，做完維護，這一輪就算徹底結束了。現在會把維護想成整個迴圈裡最關鍵的一個轉折點，它不是尾巴，是連接尾巴跟開頭的那個接口。一旦用這種方式理解維護，很多以前覺得瑣碎、可以隨便做做的收尾動作，重要性一下子就不一樣了，因為它們決定的不只是這一輪做得好不好，是下一輪能不能順利接得上，這種接得順不順，往往要到下一輪真的卡住的時候，才會被真正發現。
把這份文件整份讀完之後，我覺得該講的不只是哪裡對得上，也該講哪裡對不上。這份文件描述的場景，假設的是一個已經有平台團隊、有既定的分支保護機制、有專門的發布負責人、有持續整合跟監控管線的組織。我自己是一個人在跑這整套流程，很多地方沒辦法照搬，得換成簡化的版本，像是三層護欄裡的強制關卡，我沒有一整套自動化的 hook 系統去擋，很多時候是靠自己養成的檢查習慣去補這個位置，這跟真正寫死在系統裡的強制機制，可靠程度是不一樣的。
這種可靠程度的落差，我覺得值得老實攤開來講，不要假裝自己一個人做到的東西，跟一整個平台團隊支撐起來的機制是同一個等級，那種假裝對誰都沒有好處。靠養成的習慣去補位，最大的風險是狀態不好的時候容易鬆懈，一個真正寫死的強制機制不會有這種問題，它不會因為今天比較累、比較趕，就悄悄放你一馬。我自己現在會刻意提醒，凡是靠習慣撐著的環節，都算是比較脆弱的一環，該找機會慢慢把它們換成真正寫死的檢查，而不是永遠依賴自己那天夠不夠自律，這種自律終究會有失守的一天。
另外這份文件本身也沒有附上任何具體的成效數字，講的是設計上為什麼這樣安排比較合理，不是拿實際測出來的數據去證明真的更快更好。我自己讀的時候會不斷提醒自己，這是一份講清楚原則跟架構的文件，不是一份已經被驗證過成效的報告，套用的時候，還是得靠自己實際跑一遍、量出真正的結果，不能因為官方寫出來了，就跳過驗證這一步直接照單全收。這件事說起來也挺諷刺，一份講整套流程都要靠驗證才能信任的文件，它自己也一樣需要被同樣的標準檢驗過，才能真正被信任。
這種帶點自我指涉意味的諷刺感，讓我想起自己前面講規則檔維護的時候提過的雙重身分，任何一份被拿來當作判斷依據的東西，本身都不能豁免於被檢驗，就算它來自一個很有份量、很值得信賴的來源也一樣。來源夠權威，最多只能讓人多一點理由相信這份文件背後經過了認真的思考跟琢磨，不能取代自己實際驗證的那一步。我看過不少人一看到官方發的東西，直接就當成標準答案套用，這種心態我覺得反而是這份文件真正想避免的，它整份講的都是要靠驗證才能信任，結果讀的人卻用一種完全不驗證的態度去讀它，等於連文件的精神都沒讀進去，只學到了表面的六個階段名稱，卻漏掉了骨子裡那套驗證優先的態度。
回頭把前面講過的每一件事重新想過一輪，我覺得最有價值的不是這份文件本身的六個階段名稱，是它背後那個反覆出現的原則，人類的判斷力永遠留在迴圈上方，決定性的控制跟建議性的控制要分清楚，每一階段的產物都要老實留下紀錄，讓下一個接手的人不用從零開始猜。這幾件事，剛好就是我一路反覆在講的東西，只是這次終於看到它們被放在同一張完整的地圖上，各自對應到一個明確的位置。
這種發現本身，我覺得有一種特別的價值，值得單獨拿出來仔細講清楚，不只是順帶提一句帶過而已。獨立摸出一套方法，跟後來發現有人已經把它整理成一份更完整的架構，這兩件事帶來的感受完全不一樣，前者容易讓人懷疑自己是不是想太多、太執著在一些瑣碎的細節上，後者則會反過來給一種確認感，原來這些細節不是自己想太多，是真的有一個更大的架構在支撐著它們。這種確認感，我覺得比單純讀一份新文件學到新知識，還要更踏實一點。
iThome鐵人賽
看影片追技術