Codex 進階，模型變強後，開發流程該怎麼重做？

這篇文章解決一個問題，模型已經會自己規劃、自己糾錯了，管它的那套系統該怎麼跟着升級。我的答案是產品經理 5.0。核心思路一句話能說完，把每一步怎麼做還給模型，人只負責定目標、定標準、定邊界。聽起來像偷懶，其實正相反，敢這麼放手，是因為驗收和門禁攥得比以前更緊。

用過 4.0 的朋友，或者自己搭過 Agent 系統的，應該都有體會。規則這個東西是會上癮的。AI 跳了一步，你加一條規則，它臆測了一次，你再加一條，規則庫越寫越厚，看起來越來越嚴密。直到某次模型升級，你發現它本來能用更聰明的辦法解決問題，卻被你的流程摁在原地，老老實實走你半年前設計的路線。維護 4.0 這段時間，我最深的體會就是寫得越細的部分，過時得越快。

舉個具體的例子。4.0 的 bug-fixer，我寫了一套完整的調試流程，先收集證據，再分析模式，接着提假設逐個驗證，最後實施修復，每一步做什麼、產出什麼，安排得清清楚楚。5.0 的 bug-fixer 整個文件只有 41 行，過程全刪了，留下的只有原則。不猜不試，沒證據不下結論。一次只改一個地方，因為同時改多處就沒法判斷哪個是真修復。同一個 bug 反覆修不好就強制停下，重新審視問題本身，那多半不是代碼層面的事。至於具體怎麼調試，它自己安排。我原本擔心刪成這樣會翻車，實際跑下來，它組織調試的思路比我當年寫的流程還合理。

整個行業都在往同一個方向走，人從指揮每一步，退到定義什麼算做完。大家現在聊的也不再是 vibe coding，是怎麼讓模型自己跑完一整段任務。

廢才產品經理 5.0 還是一套面向產品開發全流程的 Harness。這個概念 4.0 講過，Agent 等於模型加 Harness，模型提供智能，Harness 讓智能變得可用。前饋的 Guides 在行動前注入標準，反饋的 Sensors 在行動後檢查結果，進化的 Steering Loop 讓系統越用越好，這個骨架 5.0 一點沒動，動的是每一層的內容物。Guides 從詳細流程換成了目標、標準和邊界，執行層的固定 Sub-Agent 從四個減到兩個，進化系統從四層升級路徑縮成當場拍板的短鏈，另外多了一樣 4.0 完全沒有的東西，把一整段開發交給模型自己跑完的 /goal 自驅。主控文件裏的第一性原理寫得很直接，講規則、講需求、講標準，剩下你自己來，不需要把過程一步一步餵給你，那隻會壓低你的上限，規則只許更精煉、更準，不許膨脹。

落到數字上更直觀。5.0 的主控 AGENTS.md 一共 171 行，十一個 Skill 的主文件加起來 678 行，連進化規則和兩個子 Agent 定義全算上，整套系統 928 行。個別 Skill 帶着按需加載的附件，比如需求訪談的問題庫，那是刻意留厚的，後面會講為什麼。你要做的只是描述想法，從需求文檔到設計圖到代碼到發佈，按標準自動推進，嫌一步一步看着煩，還可以把一整個階段交出去，讓它自己跑完。

先從十一個 Skill 說起

前饋控制的邏輯沒變，在 Agent 動手之前注入標準，提高一次做對的概率。變的是注入的東西，4.0 注入方法論加執行流程，5.0 只注入目標、驗收標準和邊界，過程留白。產品開發還是拆成八個階段，每個階段對應一個 Skill，另有三個 Skill 在流水線之外，管這套體系本身。下面順着流水線走一遍，看每個環節刪掉了什麼、留下了什麼。刪得並不平均，有的環節反而變厚了。

product-spec-builder 負責需求收集。拿我手上的真實項目舉例，這期視頻做的 VibCut，一個跑在 Mac 上的視頻剪輯 Agent，就是用這套流程開發的。我開口說想做個視頻剪輯 Agent，它不接茬，先上網搜了一圈競品回來問我，剪映的智能字幕已經很成熟了，你的差異在哪。我說痛點不在轉字幕，在字幕出來之後，篩停頓、刪廢話、同步改時間線全靠手，一條 5 分鐘的口播要剪一個小時，我要的是一個能自己判斷該刪哪裏、動手改時間線、改完還能回滾的剪輯 Agent。它接着問第一版服務誰，所有人等於沒有人。問到最後，Spec 裏寫下的第一版用戶就一種人，剪口播的創作者。這個 Skill 是 5.0 裏少數不減反增的，訪談分七個階段，問題、用戶、範圍這些地基不過關，不解鎖後面的細節，另外還有一張 AI 能力對照表，主動告訴你現在 AI 生視頻、生圖、配音各做到了什麼程度，免得你不知道可以要什麼。道理不復雜，執行過程模型自己會，你腦子裏的需求它替你想不了，源頭採集的質量決定後面所有環節，該厚的地方就得厚。

design-brief-builder 管設計規範，問法是同一個路數。它的第一條原則是形態先於視覺，先認清你做的是網頁、終端工具還是對話式 Agent，再談好不好看，拿網頁那套頁面組件的思路去套終端工具，後面每一問都是錯的。它從不問你想要什麼風格，永遠給選擇題。高級感是哪種，蘋果那種大留白，還是愛馬仕那種深色配金。信息密度要 Linear 那種緊湊，還是 Notion 那種寬鬆。你說出的每個抽象詞，都會被翻譯成具體的設計屬性再向你確認，簡潔翻成大留白加剋制配色加少字重，翻得不對，你當場就能糾正。

到了設計圖和開發計劃這兩步，留下的基本只剩規矩。design-maker 通過 Pencil 或 Figma 的 MCP 連接，直接在設計工具裏生成整套設計稿，規矩有三條。Spec 裏每個有 UI 的功能都要有頁面，漏一個，開發就只能靠猜。每個頁面不只畫默認態，空狀態、加載態、錯誤態都要有。先建可複用組件再拼頁面，免得一個按鈕畫十遍、改一次改十處。頁面裏填的是真實內容，不是佔位假文。dev-planner 這邊，讀完需求和設計先上網驗證技術選型，框架版本、兼容性、有沒有現成組件，確認完再按依賴關係把項目拆成有序的 Phase，基礎設施先做，被依賴的先做，風險高的儘量排早。硬標準兩條。每個 Phase 完成後必須能編譯、能運行、能看到效果，不允許寫一堆跑不起來的半成品。計劃裏不許出現待定、回頭再補這類佔位符，每個任務要完整到一個不瞭解項目背景的人也能照着開工。

再往下是 dev-builder，刪流程刪得最狠的地方，留下來的全是紀律。改代碼前先評估影響範圍，刪一個被多處引用的東西，先全項目搜一遍引用點，一次清乾淨。優先複用已有組件和樣式，不自造輪子。按鈕、數字、卡片必須代表真實數據和真實行為，不寫死、不留裝飾性的假功能。完成聲明必須在同一條消息裏附上剛跑的驗證命令和輸出，之前編譯過了這種話不算數，沒有當場驗證就等於沒有完成。

bug-fixer 開頭講過了，從完整流程瘦身成 41 行原則。這裏補一個細節，它形成假設時一次最多三個，按可能性排序逐個驗證，被否定的記下原因不再重複驗，連續三次修復失敗強制停下重審。

流水線的出口是審查和發佈。code-review 兩階段閉環，是整套系統的質量底線，下面單獨講。release-builder 負責構建發佈，它的出發點是一句很多人栽過跟頭的話，dev 環境測通不等於打包出來能用，開發和打包後的運行環境，路徑、依賴、權限全都不同，所以必須從安裝包測起，不是從構建目錄測。發佈前有一道絕對底線叫隱私審計，對着構建產物逐項查開發者路徑、數據庫文件、環境變量、API Key、明文密碼，查到任何一項立刻停下，修完重新構建再查。能構建，不等於能發佈。

流水線之外的三個，管的是體系本身。goal-creator 替你寫自驅指令，5.0 最重要的新增，馬上單獨講。evolution-engine 消化你的糾正，提煉成規則改進建議，進化那節細說。skill-builder 負責造新 Skill，只在進化系統提議、你點頭之後才出手，它是最後手段，不是常規操作。

被問得最多的一個問題

把流程刪了，過程靠什麼組織。5.0 的答案寫在主控裏，叫規劃與執行，所有環節共用同一個模式，統共不到二十行。

任何環節開工前，主 Agent 先把活拆成有序、可獨立驗收的步驟，每步寫明目標和完成標準。然後看工作能不能隔離，選執行方式，彼此耦合的自己順着做，互不依賴的並行做，能徹底隔離、需要乾淨上下文的，spawn 子 Agent 去做。執行中守三條標準。上下文自帶，開工前把相關文檔的原文讀進來，不靠記憶和摘要。結果自檢，產出對照完成標準，用證據說話。排障自驅，沒達標就自己定位自己修，循環到達標，同一個問題反覆卡住才來找你。

這次瘦身可以這麼理解，4.0 是十一份各寫各的詳細流程，5.0 是一條通用的組織模式，加十一份驗收標準。要維護的知識從每個環節怎麼做，收斂成了所有環節怎麼組織，規則量就是這麼掉下來一個量級的。

寫 Goal 不寫過程

最能體現 5.0 思路的，是這個 4.0 裏完全不存在的玩法。

/goal 是一條自驅指令，把一個完整目標整段交出去，比如完成開發計劃裏的某個 Phase，模型就開始自己規劃和執行，驗證不過就換路子，直到目標達成，或者確實山窮水盡才回來找你，中途不用你盯着。

這東西好用的前提是 Goal 本身寫得好，而這恰恰是大多數人栽的地方。完成條件寫成把功能做完，等於沒寫，模型說做完就算做完嗎？/goal 的判定器只認看得見的證據，所以完成條件必須寫成能自我證明的形式，跑了什麼命令、貼出什麼輸出、產出哪些文件、清單逐項打勾。另外還有個硬限制，整條指令 4000 字符以內，每個字都得帶信息，套話寫進去純屬浪費額度。

說實話，寫好一條 Goal 比寫好一段提示詞難。所以 5.0 專門做了 goal-creator。你說一句接下來這個階段讓它自己跑，它結合當前項目狀態和對話上下文，替你把整條指令寫好，完成標準逐條可驗證，驗證方式寫明跑什麼查什麼，約束只寫真實存在的邊界，不灌保持代碼整潔這種放之四海皆準的廢話。你過目，複製，發送，自驅就開始了。

拿 VibCut 的開發計劃舉例，它生成的指令長這樣。

/goal 完成 DEV-PLAN Phase 6，多軌時間線核心與手動編輯。

完成的標準：
1. Phase 6 交付清單逐項實現，對照清單逐項打勾貼出
2. tsc --noEmit 零錯誤，輸出已貼
3. code-reviewer 兩階段審查 PASS，報告已貼
4. dev server 啓動無報錯，新功能可用，舊功能迴歸通過

驗證方式：
- 跑 tsc --noEmit 貼輸出，啓動 dev server 貼日誌
- spawn code-reviewer，貼兩階段結論

約束：
- 不動 Phase 7 範圍的文件，不直推 main

執行策略：目標導向，一條路不通換方法，多種都試過才停；長任務記一句進度日誌。

注意第二、三條完成標準，它把項目自己的驗收門禁寫進了 Goal。這是刻意的，自驅的完成條件必須覆蓋項目門禁，不然模型幹完活，會卡在沒過審查不讓收工的關卡上進退不得。

兩個邊界提前說清。指令它替你寫，發送必須你自己來，自驅的啓動權永遠在人手裏。還有，不是所有環節都適合自驅，需求訪談這種要你來回拍板的事，交出去等於讓模型猜你想要什麼，猜得越流暢，錯得越徹底。適合交出去的是標準清晰、證據可驗的環節，開發階段最典型。

我為什麼敢刪

回頭看那條 Goal 的完成標準，第三條寫着 code-reviewer 兩階段審查 PASS，現在講的就是它。敢刪過程的底氣全在這一層，所以這一層不但沒瘦，還更嚴了。框架裏管它叫推理型傳感器，做的是需要動腦的檢查，純機械的那部分歸 hook，後面講。

閉環和 4.0 一致。功能開發完成，主 Agent 自動 spawn 獨立的 code-reviewer 做兩階段審查，審查員是嚴格 QA 的人設，只報告不修復。Stage 1 查做對了沒有，Spec 逐條對照代碼，每條功能要麼有實現並附文件行號，要麼沒有，不存在大致匹配這個選項。Stage 2 查做好了沒有，代碼質量、安全掃描、視覺還原。Stage 1 有高優先級問題就停在 Stage 1，不往下走。審查失敗自動轉修復，質量問題回 dev-builder，確屬缺陷和安全漏洞才動用 bug-fixer，修完重新審，從 Stage 1 重來，循環到雙過才允許提交。

5.0 給審查加了兩個新維度，都是開發 VibCut 時踩出來的。一個叫引導真實性，界面上的佔位符和提示文案，必須對應真實存在的功能。VibCut 就被抓過現行，輸入框的提示寫着可以用某個符號喚起技能，代碼裏卻沒有一行處理那個符號的邏輯，這種引導一律按未實現處理。另一個叫測試真實性，不只看有沒有測試，要看測試有沒有真的證明行為是對的，用假前提把缺陷蓋成預期、斷言方向寫反、只測順暢路徑從不碰故障路徑，這些看着全綠、實際什麼都沒證明的測試，全會被點名。審查員的原則一句話，每個結論要麼有證據，要麼不成立。

落到每個 Phase 上，收尾要過四關，審查、測試完整性、編譯、功能測試，每一關都得拿出證據來。

子 Agent 從四個減到兩個

審查必須獨立這件事，牽出執行層的一個問題，哪些活配得上固定角色。4.0 有四個固定 Sub-Agent，編碼的、審查的、記反饋的、掃進化的，5.0 減到兩個，留下審查的 code-reviewer 和消化進化的 evolution-runner。

取捨標準只有一條，真正需要獨立判斷的工作，才值得單開一個隔離的上下文。審查必須獨立，寫代碼的上下文去審自己的代碼，會繼承自己全部的錯誤假設，你寫錯的前提，自檢時還是那個前提，審查的價值恰恰在於它不知道你怎麼想的，只看代碼和需求對不對得上。進化消化同理，它要冷靜地把你的牢騷提煉成通用規則，不該被當前對話帶着走。至於編碼，普通的任務分解配不上一個常設角色，主 Agent 自己規劃自己做，真需要隔離時臨時 spawn 一個執行型子 Agent，用完即走。記反饋的那個直接去掉了，活兒被一個 hook 加主 Agent 順手分掉。

隔離原則一點沒松。每個子 Agent 都是全新實例，不繼承 session 歷史，主 Agent 把 Spec 條目、交付清單、涉及文件、項目結構完整複製給它。執行型子 Agent 只編碼和自檢，不能再 spawn 子 Agent，也不能 commit，審查閉環和提交永遠握在主 Agent 手裏，一個子 Agent 的錯誤假設傳不到下一個任務。有一點 Codex 用戶要知道，Codex 只在主 Agent 顯式請求時才 spawn 子 Agent，不會自己派，所以審查閉環、進化消化這些環節，規則裏都寫明瞭由主 Agent 主動 spawn，這是適配時要注意的點。

六個 hook

子 Agent 管的是判斷要乾淨的活，另有一類事不需要任何判斷，但必須每次都對，這類交給 hook。六個 hook，4.0 一個沒刪，5.0 一個沒加。這層穩定的原因很簡單，它管的是確定性判斷，編譯過沒過、審沒審查、推沒推送，這種非黑即白的事跟模型聰不聰明無關，模型再升級，編譯必須通過這件事也不會過時。

pre-tool-shell 在 commit 前跑編譯檢查，不過就直接阻止提交，它還順手管一件事，啓動 dev server 前清掉佔用端口，端口被佔是很多靈異問題的來源。auto-push 在 commit 成功後自動推送遠程，保護分支除外。配套的提交紀律是原子化，一個功能一個 commit。stop-gate 在 Agent 準備收工時攔一道，代碼改了還沒過審查的，回去審完再停。mark-review-needed 盯着代碼文件，一有改動就標記待審查，和 stop-gate 配合，改了就跑不掉。detect-feedback-signal 監聽你的消息，發現糾正和不滿的措辭，把原話抓進進化隊列。check-evolution 在每次新開 session 時看一眼隊列，有積壓就提醒先處理。

取捨邏輯一句話，要判斷的給模型，要保證的給 hook。規則寫一百遍，模型也有走神的那一次，hook 是程序，程序不走神。

進化系統這次改大了

4.0 的進化走四層路徑，反饋先靜默記錄，同一條出現三次以上才升級成正式規則。設計得挺穩重，用起來太慢，一條明明白白的教訓，要眼睜睜看它犯滿三次。

5.0 改成短鏈。你糾正它，hook 把原話抓成信號入隊，措辭隱晦沒抓到的，主 Agent 自己識別自己補記。下次新開 session，主 Agent 第一件事 spawn evolution-runner，把積壓的信號消化成具體的改動建議，回來當場逐條問你。同意，立刻改進對應的規則文件。否了，信號和建議一起刪。點頭即生效，沒有緩衝期，也絕不揹着你改規則。有個適配細節順帶交代，消化放在 session 啓動時同步執行，是因為 Codex 的 hook 不支持異步後台任務，好在消化本身很輕，幾分鐘就還給你。

比速度更重要的是兩個新性質。先說雙向，它不光往裏加規則，還會掃描現有規則提議退休，你已經內化的、從沒觸發過的、和別條重複的，都是刪除候選，判斷標準是刪了它會不會復現當初的失敗，不會就刪，規則總量要能往下走，不然用久了規則又會重新堆起來。再說分層，通用規律才進規則文件，項目專屬的偏好，比如某個項目的文案口吻、某篇稿子的素材取捨，進的是用戶記憶，框架不被單個項目的口味污染。

舉個新鮮的例子，就發生在寫這篇稿子的過程裏。前一個工作 session，我陸續提了八條修改意見。新 session 一開，它消化完直接來問我，有四條信號指向同一個問題，講解類內容應該先給全景、再講原理、最後落價值，要不要立成一條正式的寫作規則。另外幾條是一次性的措辭調整，現有規則已經覆蓋，建議直接刪。我點頭的當場進了規則庫，搖頭的當場消失，全程幾分鐘。你現在讀的這篇文章，就是帶着那條新規則寫出來的。

文檔驅動，一個 session 只幹一件事

這套系統裏還藏着一個開發方法，值得單獨拎出來。

AI 是靠上下文驅動的，說白了就是靠文檔驅動的。模型不記得上一個對話，每個新 session 對你的項目一無所知，它的全部理解來自當場讀到的東西。Product Spec 和 DEV-PLAN 存在的意義就在這，新開一個 session，模型把文檔讀一遍，就知道做到哪了、接下來幹什麼。廢才啓動時的項目狀態檢測乾的就是這件事，掃一遍文檔和代碼的存在狀態，自動路由到當前該乾的環節。

順着這個邏輯往下推，會得到一個很實用的開發節奏，一個 session 只開發一個功能。功能做完，文檔更新，session 關掉，下一個功能開新的。原因不玄乎，上下文一長，模型的注意力會被稀釋，前面聊的需求被擠出去，後面寫的代碼開始跑偏，所有長對話都這個毛病。一個 session 一個功能，每次的上下文量都可控，模型始終在注意力最好的狀態下幹活。代價是一個習慣，變更先改文檔再動代碼，文檔是唯一事實來源，上游文檔動了，主 Agent 會提醒你檢查下游要不要跟着改，改不改由你拍板，它不擅自動手。

4.0 時代，跨 session 接續是上下文不夠用時的補救。5.0 把它倒過來，變成主動選擇的開發節奏。我覺得這是整套方案裏最值得學走的一個習慣，就算你不用廢才，這招也通用。

順着文檔再說一條 4.0 的老規矩，原樣保留。設計稿權重最高，Design-Brief 次之，Product-Spec 管功能邏輯，UI 衝突時以設計稿為準。連帶的紀律也還在，新增或修改 UI 必須同步更新設計稿，不然審查環節對照設計稿驗收，新功能就成了盲區。寫代碼前，dev-builder 會從設計工具裏讀取頁面的精確數值，寬高、間距、字號、顏色、圓角，每個任務都重新讀，不憑記憶，寫完再把代碼實際值和設計值逐項對照，有偏差先修再提交。

醜話說在前面。和 4.0 一樣，別期待一步到位，完整產品不可能一個 session 跑完，靠文檔接續，文檔不更新它就接不上。設計圖那步依賴支持 MCP 的設計工具，沒有就跳過，靠 Design-Brief 兜底。/goal 自驅不替你做產品決策，需求沒想清楚，它只會把錯的東西高效地做完。這套流程是給認真要落地的產品準備的，隨手搓個一次性 demo 犯不上。

還有一句更要緊的，這套方案對模型的要求比 4.0 更高，不是更低。詳細流程刪掉之後，活怎麼拆、做到什麼程度算合格、卡住了怎麼換路，全靠模型自己判斷。需求訪談靠它追問出真需求，追問不到位，後面全在錯誤的基準上跑。開發執行靠它誠實自檢，一個把沒驗證說成應該沒問題的模型，會污染整條流水線。審查靠它逐條對照給證據，進化靠它從你的牢騷裏提煉通用規律。底子不夠的模型，撐不住這種程度的放手。所以模型建議直接用旗艦檔，別用輕量檔省錢，省下的會在返工里加倍還回去。Sub-Agent 各有獨立上下文，token 消耗隨任務量增長，心裏要有數。初次上手建議先拿一個小項目跑通全流程，從一句想法跑到發佈，確認各環節的產出質量符合預期，再投入正經項目。

最後交代一下安裝

真決定上手的話，這裏只給個輪廓，完整的安裝步驟和每個文件的說明在配置包文檔裏，不佔文章的篇幅。這套方案我做了 Codex 和 Claude Code 兩套適配，結構完全同構，Claude Code 版把 AGENTS.md 換成 CLAUDE.md，.codex 換成 .claude，hooks.json 換成 settings.json，其餘一一對應。

以 Codex 版為例，裝完之後你的項目裏多了這些東西。根目錄一份 AGENTS.md 主控，Codex 啓動會自動讀它，171 行裝下角色、第一性原理、執行模式和全部調度規則。.agents/skills/ 下十一個 Skill 各佔一個文件夾，什麼時候被自動觸發由 SKILL.md 的 description 決定，也可以用 /skills 手動調用，訪談問題庫這類重型附件放在 references/ 裏按需加載，平時不佔上下文。.codex/ 裏是技術層，config.toml 配模型和 MCP，六個 hook 腳本加一份觸發時機的綁定，兩個 TOML 文件定義 code-reviewer 和 evolution-runner，進化規則寫在 EVOLUTION.md，信號隊列 signals.jsonl 和待拍板的 proposals.md 也在這。4.0 的 feedback 目錄和一堆模板文件，到此正式退役。跑起來之後，Product-Spec、DEV-PLAN 這些文檔會在對應環節自動生成在項目根目錄，它們就是跨 session 接續的全部依據。

把整套系統畫成一張圖，和 4.0 那張對照着看，能看出哪層瘦了、哪層換了、哪層一動沒動。

┌────────────────────────────────────────────────────────┐
│  調度層   AGENTS.md 主控（廢才）171 行                   │
│           項目狀態檢測、流程路由、規劃與執行、Skill 調度   │
├────────────────────────────────────────────────────────┤
│  引導層   Skill × 11（Guides，從詳細流程換成驗收標準）    │
│           流水線八個   需求 / 設計規範 / 設計圖 / 計劃     │
│                        開發 / 修復 / 審查 / 發佈          │
│           體系三個     自驅指令 / 進化消化 / 新 Skill 生成 │
├────────────────────────────────────────────────────────┤
│  執行層   固定 Sub-Agent × 2 ＋ 臨時執行型子 Agent        │
│           code-reviewer 獨立審查                         │
│           evolution-runner 消化進化信號                   │
├────────────────────────────────────────────────────────┤
│  檢查層   Hook × 6 ＋ Review→Fix 閉環（Sensors）          │
│           編譯門禁 審查門禁 停止門禁 信號捕捉              │
├────────────────────────────────────────────────────────┤
│  進化層   signals.jsonl → proposals.md → 逐條拍板         │
│           Steering Loop 規則可進可退                      │
└────────────────────────────────────────────────────────┘

如果你想把這套思路搬去搭自己的 Agent 系統，判斷標準濃縮成三條。給模型的知識寫成 Skill，只寫什麼時候用、要什麼輸入、按什麼標準驗收、產出什麼，過程讓它自己定，重型知識拆出去按需加載，平時不佔上下文。需要獨立判斷、乾淨上下文或真正並行的工作，才 spawn 子 Agent，單純想給功能分類不算理由。必須每次都對的檢查寫成 hook，交給程序。

一句話概括 5.0 的設計觀，模型負責聰明，結構負責可靠。

最後說一句。模型每升一級，你寫的詳細流程就過時一截，但什麼算做好不會過時，驗收標準不會過時，門禁不會過時。5.0 刪掉的從來不是約束，是那種模型不行、我得替它想好每一步的不信任。