駛向未來，卻只盯著後照鏡：AI Coding 的「紅旗法案」陷阱

[TL;DR] 重點快讀

• 目前主流 AI 工具仍停留在「後照鏡」階段，過度依賴對話介面限制了技術潛力。
• 高效開發者需區分「在場（即時修正）」與「缺席（機械式執行）」兩種工作狀態。
• 「人在迴路」已成為現代開發瓶頸，應追求人類在槓桿支點上的「監督」而非「參與」。
• 透過 Custom Skills 封裝團隊標準，才能解決 AI 在不同模式切換時的失憶問題。

每一次技術革命，都會重新劃分人與機器的界線。而我們正眼睜睜看著歷史重演。

1964 年，Marshall McLuhan 說過一句讓我至今背脊發涼的話：

「我們是用後照鏡來看著未來，倒車入庫。」(We drive into the future using only our rearview mirror.)

他說的是電視。當年的人們把電視當成「有畫面的廣播」來用。五十年後，我們拿著智慧型手機拍照、傳訊、滑短影音，至於「打電話」？那已經是這台設備最不重要的功能了。

現在的 AI Coding 工具，正卡在這個「後照鏡」階段。

打開市面上任何主流工具，你看到的都是一樣的東西：一個輸入框，一段對話，你來我往。在本質上，這只是把 AI 當成一個更聰明的搜尋引擎，或者一個剛好會寫程式的 ChatGPT。這是在用舊思維套用新技術。

但在 Qoder，當我們追蹤了數千名開發者的行為數據後，發現了一個殘酷的真相。那些真正的高手？他們根本不是用「一種」方式在跟 AI 互動。

兩種截然不同的工作靈魂

數據顯示，高效能開發者會根據任務需求，在兩種完全分裂的狀態下切換。

第一種狀態，我們稱為「在場 (Present)」。

這感覺你一定很熟。你在 Debug 一個莫名其妙的錯誤，你在探索新的架構，或者你在解開一團糾纏了三年的商業邏輯。這類任務有個共同點：方向還不明確。你需要即時看到 AI 的輸出，隨時修正，快速迭代。

賈伯斯在 1980 年代把個人電腦稱為「大腦的腳踏車」。這就是那個狀態。你在踩踏板，工具放大你的力量。

第二種狀態，我們稱為「缺席 (Absent)」。

寫一批單元測試、依照規格遷移 API、幫五十個檔案重新命名。這裡的目標像水晶一樣透徹，驗收標準清晰，執行過程幾乎是機械式的。

這更像是把工作交給一個值得信任的同事。你不需要盯著他做，你只需要在他做完後檢查。

問題來了：為什麼我們要用同一種工具、同一種互動模式，來處理這兩種截然不同的工作？

這就是為什麼 Qoder 拒絕妥協。我們為這兩種狀態，打造了兩個完全不同的模式。

Editor Mode：當你需要「在場」

我們稱之為 Editor Mode。

設計哲學很簡單：放大你的判斷力，而不是取代你的參與。

這不是讓你打字變快，而是讓你變成一支軍隊：

• 多重代理並行 (Multi-Agent Parallel)：你可以同時開好幾個對話視窗。一個 Agent 在重構 Auth 模組，另一個在寫測試，第三個在檢查安全漏洞。你在思考架構，他們在處理細節。這不是「更快的單執行緒」，這是「管理一個小團隊」。
• Browser Agent：AI 不只寫 Code，它能打開真的瀏覽器，驗證前端行為，抓出真正的錯誤。以前是你自己測，現在 AI 說：「代碼好了，我已經在瀏覽器裡跑過一遍，沒問題。」
• Planning Agent：遇到複雜任務，AI 會先給你看執行計畫。不是模糊的「我來處理」，而是具體的步驟拆解。你可以在它動手前批准、修改或駁回。

這些功能的共同點？你還在迴路裡 (In the loop)。AI 放大你的能力，但方向盤在你手上。

Quest Mode：別做那個「拿紅旗的人」

另一種模式，我們稱為 Quest Mode。

這裡的哲學完全翻轉：你定義目標，AI 獨立執行，你只負責驗收。

這裡我要丟出一個可能得罪很多人的觀點：「Human in the loop (人在迴路)」並不總是好事。

Ivan Zhao 在他的文章《Steam, Steel, and Infinite Minds》裡提過這段歷史。1865 年，英國通過了《紅旗法案 (Red Flag Act)》。法律規定，每一輛機動車輛前方，必須有一個人拿著紅旗步行開道。

這就是早期的「Human in the loop」。為了安全，人必須在場。

結果呢？這條法律把人類變成了效率的瓶頸。

今天很多 AI 工具都犯了同樣的錯誤。它們要求開發者隨時在場，檢查每一行代碼，確認每一個決定。這就像是要求主管親自去檢查流水線上的每一顆螺絲。

我們真正想要的，是人類站在槓桿的支點上，監督整個迴路，而不是被困在迴路裡當瓶頸。

Quest Mode 的設計，就是要將你從執行迴路中徹底解放。

我們的口號很狂，但很真實：Quest on, Hands off.

流程是這樣的：

1. Brief (10分鐘)：描述你要什麼。
2. Walk away (1小時)：Quest 自動作業，你可以去開會、去吃飯，甚至去睡覺。
3. Review (10分鐘)：回來檢查結果，批准部署。

Quest 1.0 引入了更深層的 Agent 架構，遵循三個原則：

• 先問再做 (Asks first)：動手前，Quest 會主動釐清需求。「用什麼 Tech stack？」「錯誤訊息怎麼顯示？」「有哪些 Edge cases？」先對齊，再執行。
• 無人值守 (Works unsupervised)：一旦對齊，它就獨立運作。它不需要你看著它。這是一種新的信任模型：不是「我看著你做」，而是「你做完我檢查」。
• 完全可追溯 (Fully traceable)：每一個決定都有 Log，每一個動作都能 Rollback。你不在過程中監督，但你可以在事後審計一切。

當上下文被整合，工作變得可驗證，開發者將從騎腳踏車進化到開車，再從開車進化到全自動駕駛。

從水車到蒸汽機：工廠不再需要河流

讓我用歷史學家的角度，告訴你為什麼「雙模式」比「單一聰明模式」更重要。

工業革命早期，英國的紡織廠都建在河邊，因為需要水車提供動力。當蒸汽機出現時，第一代工廠主做了什麼？他們只是把水車拆掉，換成蒸汽機。

其他的都沒變。工廠還是在河邊，工人還是一樣配置，生產流程還是一樣。

效率提升了嗎？只有一點點。

真正的突破發生在他們意識到「蒸汽機不需要河流」的時候。

他們把工廠搬到了離工人、港口和原料更近的地方。他們圍繞著蒸汽機重新設計了整個生產流程。後來電力出現，他們甚至拿掉了中央傳動軸，把馬達直接裝在機器旁邊。

那才是生產力真正爆炸的時刻。

現在大多數的 AI Coding 工具，就像是那些還賴在河邊的舊工廠。它們把更強的模型 (蒸汽機) 硬裝在舊的對話介面 (水車) 上。

Qoder 的 Editor 與 Quest 模式分離，就是我們試圖把工廠搬離河邊的嘗試。

雙軌制的「標準軌距」：Custom Skills

雙模式架構會帶來一個挑戰：你的 Coding Standard 怎麼辦？

在 Editor Mode，AI 知道「我們團隊用 TypeScript strict mode」。切換到 Quest Mode 後，它會失憶嗎？

如果每次切換都要重新教一遍，雙模式的效率優勢就會被溝通成本吃光。

這讓我想起另一段歷史。

19 世紀，美國鐵路有幾十種不同的軌距 (Track Gauge)。火車跨區時，必須停下來卸貨、轉車、再裝貨。直到 1886 年，南方鐵路公司在兩天內將 1.3 萬英里的鐵軌全部改成標準軌距，美國鐵路網才真正連通。

Custom Skills 就是我們的「標準軌距」。

延伸閱讀 : Qoder

在 Qoder 0.3.1，你可以把團隊標準封裝成 Skills、Sub-Agents 和 Slash Commands：

• /review-component：你團隊的 React Review 清單
• /security-audit：你組織特定的漏洞掃描規則
• /generate-tests：你的覆蓋率要求和 Mocking 風格

重點是：定義一次，隨處使用。

在 Editor Mode，AI 即時遵循你的標準。在 Quest Mode，AI 在無人值守時繼承同樣的標準。

一位大型雲端公司的資料工程師告訴我們，他把 SQL 分析規則寫成 Skills 後，理解複雜邏輯的時間從兩三天降到了一天。快了 300%。無論是他自己 Debug 還是丟給 AI 跑批次任務，標準永遠一致。

從佛羅倫斯到東京

讓我把鏡頭拉得更遠一點。

文藝復興時期的佛羅倫斯，你用腳走完這座城市只需要 40 分鐘。生活的節奏取決於雙腳能走多遠，聲音能傳多遠。

後來，鋼骨結構造就了摩天大樓，鐵路連接了腹地，電梯、地鐵、高速公路隨之而來。像東京、重慶這樣的巨型城市誕生了。

它們不是「變大版」的佛羅倫斯。它們是完全不同的生存方式。

今天的軟體開發，仍然是「佛羅倫斯式」的。

團隊規模受限於「會議室能塞多少人」，專案節奏受限於「等某人回訊息」，架構複雜度受限於「一個人的腦袋能裝多少東西」。我們在用人類尺度的工具，去挑戰工業尺度的難題。

當開發者真正掌握了雙模式——在 Editor Mode 全神貫注，在 Quest Mode 徹底放手——軟體開發會變成什麼樣子？

也許，就像是從佛羅倫斯搬到了東京。

更快，更槓桿化，但一開始會讓你暈頭轉向。每日站會、雙週衝刺、季度規劃這些舊節奏可能都不再適用。新的節奏將會誕生。

兩條鐵軌已經鋪好。是要繼續盯著後照鏡，還是換個檔位駛向未來？

選擇權在你。