模型會自己開車之後：我們把導航框架砍掉重練，開源了 flightwake

過去兩年，教 AI 寫程式的主流做法是「導航」：research → plan → execute → verify，一關一關過，每一步都有檢查點。我們自己也造了一套這樣的 stage-driven 導航框架，天天在用，兩個月 12 個專案、2,000 多次提交就是靠它撐起來的。

然後 Fable 5 世代的模型出來，我們發現一件尷尬的事：模型不需要導航了。它自己會開車。

你把目標講清楚，它自己會探索、自己會拆解、自己會驗證。以前框架幫模型補的那些「規劃能力」，現在是在跟模型搶方向盤——而且常常是框架開得比較差。

所以我們做了一個決定：把自己用了兩年的導航框架砍掉重練，重寫成完全相反的東西，並且開源。它叫 flightwake——不是導航，是行車記錄器。

再強的模型，也有四件事做不到

砍掉導航不等於什麼都不要。我們盤點兩年的協作紀錄，發現有四個問題是結構性的——不會隨模型變強而消失：

1. Session 必死，context 有限。 每個對話視窗總有關掉的一天，沒有記錄的話，下一個 session 接手就是一場 git 考古。
2. Git 記 what，不記 why。 Commit 能告訴你改了什麼，但不會告訴你「為什麼不選另一條路」、「那個坑的根因是什麼」。
3. 長 session 紀律會漂移。 工作拉長之後，「測試還沒跑就說完成」這種事，再強的模型也會發生。
4. Claude、Codex、Gemini 和人類互不共享狀態。 除非狀態進了 git，否則每個 agent、每個人都活在自己的平行世界。

這四件事的共同點：它們缺的不是智力，是持久性與紀律。導航框架補錯了東西。

砍掉導航之後，留下三樣東西

flightwake 的核心原則一句話講完：記錄追隨工作，不引導工作。預設一切直接動手，框架不擋在前面；但它在旁邊記錄，像行車記錄器一樣。具體只有三個構件：

行車記錄器——append-only 的三份檔案：DECISIONS.md（每個關掉其他選項的決策，一行含 why）、TRAPS.md（非顯而易見的坑，症狀、根因、繞法）、records/（每段工作收尾時的飛行紀錄）。都是純 Markdown，都進 git。

警示燈——少數幾條硬防護，跟模型強弱無關：測試綠、typecheck 乾淨才算完成；動到正式環境的變更必須在紀錄裡留驗證證據；破壞性操作先向使用者確認。

路標——一份永遠反映現況的 STATE.md：現在在哪、進行中什麼、下一步從哪接。任何新 session（不管是哪家的模型，還是一個人類同事）讀完就能接手。我們自己實測：冷啟動到安全接手不到 2 分鐘，邊際成本 3–5K tokens、API 時間約 19 秒。

成本模型也跟導航框架相反：事件觸發。做了決策才寫一行、踩了坑才登記、收尾才寫紀錄——一個什麼都沒觸發的 session，一個 token 都不多付。不像關卡制框架，每件事不管大小都要繳過路費。

儀表板：紅色就是該收尾了

裝上選配的 status line 之後，終端機底部會常駐一條儀表：health 顏色、STATE 落後幾個 commit、context 用量。它不只顯示狀態，還會在對的時機提示下一個指令——context 快滿了提示你收尾、剛開新 session 提示你冷啟動。紅色 = 該交接了；綠色 = 下個 session 可以乾淨接手。

設計原則跟框架本體一致：提示給人、義務表給模型，兩邊都是被動觸發。你不用背任何規則。

給一般開發者的分階段實戰手冊

開源前我們發現一個真正的缺口：很多開發者的問題不是「模型不夠強」，而是跟強模型協作時，不知道自己該做什麼。

所以 repo 裡附了一份 docs/workflow.md——分階段實戰手冊，每個階段講兩件事：你做什麼、對模型說什麼。它的前提認知是：

模型的能力不是瓶頸，你的瓶頸是「現在該做什麼、該說什麼」。你負責方向盤（要什麼、算不算完成、值不值得繼續），模型負責開車（怎麼做、動手、驗證）。

手冊把一個開發循環拆成六個階段：開工先恢復狀態（什麼都別做，先聽回報）；決定做什麼（說 what 不說 how，做錯會心痛的事先要方案再放行）；實作中放手不打斷（只在方向錯時喊停，喊停要給理由）；驗收只認證據（測試輸出貼上來，不收口頭報告）；收尾或交接（做完了「收尾」、沒做完「交接」，兩個都不做就關視窗是最常見的錯）；出事了先止血（health 不是綠色就不疊新工作）。

每一階段都有給熟手的進階摺疊，但主線刻意寫到「會寫程式就能照做」。整份手冊你真正要背的只有一條：開工先 /fw-coldstart，其他義務模型會自己觸發。人的工作從「記流程」變成「做判斷」——我們認為這就是強模型時代人的位置。

最誠實的 demo：它記錄了自己的誕生

flightwake 的 repo 裡有一個 .flightwake/ 目錄——那不是範例資料，是這個專案用自己管理自己的真實紀錄：從缺口清單、自我安裝、開源前的準備、到 npm 發布上線，每一份飛行紀錄都是 agent 邊做邊寫的。想知道這套框架用起來長什麼樣，直接翻它自己的行車記錄就是了。

工程上的堅持也順便交代：零依賴（只用 Node 內建模組 + git）、純 Markdown、MIT 授權、npm 發布走 trusted publishing 並附 SLSA provenance。誠實的但書：目前模板與 CLI 是繁體中文（我們是台灣團隊，英文預設值排在下一版），效能數字的樣本數也還小——方法論全部公開在 repo 的 benchmarks 文件裡，歡迎自己跑一輪把數據 PR 進來。

npx flightwake init

這跟中小企業有什麼關係？

表面上這是一個開發者工具的故事，但它解決的問題你一定眼熟：關鍵知識只存在某個人（或某個對話視窗）的腦子裡，人一走、視窗一關，全部歸零。

交接靠考古、決策沒人記得為什麼、「做完了」沒有證據——這些不是 AI 協作才有的病，是每家公司都有的病。flightwake 是我們對這個病開給自己的藥方，開源只是把藥方公開。同一套精神——狀態進檔案、決策留 why、驗收只認證據——也用在我們每一個客戶專案上。

flightwake 已列入我們的自有產品。如果你的團隊也在跟 AI 協作、也被交接和紀律問題咬過，歡迎試用；如果你想要有人幫你把這套紀律導入公司的開發或營運流程，找我們聊聊。