655對14的壓縮：當AI取代開發團隊時實際發生了什麼

TL;DR:我們進行了一個標準的655人天企業建設——兩年半的典型人類產出——並在14天內由一位工程師完成。不是因為我們找到了魔法提示，而是因為我們把AI視為一個工作團隊，而不是一位巫師。公式：220頁規範 → 基於衝刺的逆向文檔 → 每3個衝刺進行一次嚴格的整合測試 → 具有對抗檢查的多模型委員會。停止將AI視為自動完成功能。開始將其視為需要藍圖、工頭和質量控制的施工隊。

我是James，水星科技解決方案的CEO。

來自我在香港灣仔的辦公室——2026年7月

幾週前，我告訴我們的首席架構師做一件在大多數董事會上會讓我被嘲笑的事情：將一個範圍為655人天的項目在兩週內交付。

不是原型。不是最小可行產品。是一個完整的企業系統——資料庫架構、微互動、安全層、整合API，所有內容。

傳統工程經理的回應是可以預測的。"你不能那樣壓縮軟體開發。" "品質會受到影響。" "總會有人需要重構整個系統。"

他們不明白的是：限制從來不是打字速度。限制是決策。

當你消除人類猶豫不決的瓶頸時——當架構被鎖定、範圍被凍結、工作團隊不再休息——你得到的不是10倍的速度。你得到的是一個 相變。

這不是一個關於提示技巧的故事。這是一個關於 AI時代的系統工程的故事。

楊文理陷阱（或：為什麼大多數AI專案失敗）

《銀河英雄傳說》的粉絲們都知道楊的名言："贏得勝利的最有效方法是讓敵人失去戰鬥的意志。"

大多數 AI 開發專案以相同的方式失敗——不是因為技術失敗，而是因為 意志侵蝕。團隊一開始很強勁，週末產生了 10,000 行程式碼，然後發現 AI 偏離了，架構不一致，沒有人能分辨什麼是有效的，什麼是幻覺。

他們失去了戰鬥的意志。

原因很簡單： 他們把 AI 當作編碼助手，而不是生產系統對待。

你不會要求建築團隊在建築師仍在草圖階段時開始澆築混凝土。但這正是大多數 "氛圍編碼者" 所做的——他們通過提示向前推進，發現矛盾，修補它們，並以機器速度創造技術負債。

我們做了相反的事情。我們將 系統工程學科 應用於 AI 勞動力。結果是荒謬的。

步驟 1：220 頁藍圖（以規格為先的架構）

在生成任何程式碼之前，我們的架構師花了一週時間撰寫一份 220 頁的規格文件。

不是使用者故事。不是線框圖。一個 完整的建築藍圖涵蓋：

• 每個資料庫架構和關係

• 每個 API 端點、請求/回應格式和錯誤案例

• 每個微互動和狀態轉換

• 每個安全邊界和存取控制矩陣

• 每個衝刺交付物及驗收標準

傳統的反對意見："但那是瀑布式開發！那太慢了！"

胡說。在人工智慧時代，瓶頸不是執行 — 而是 問題定義。人工智慧可以在明確定義的問題上產生大約 50-100倍的人類產出。但如果給它模糊的問題，它會自信地為你建造一座在微風中就會倒塌的教堂。

把它想像成核融合與煤炭的比較。融合的能量無限強大 — 但前提是你能控制它。規範就是你的磁性約束。沒有它，你得不到能量。你得到的是一次爆炸。

**655對14的方程式：** AI執行速度（約50倍）× 規格清晰度（約0.95）× 人類監督（約0.3）= 約14倍的日曆壓縮

人類充當主建築師。AI是施工隊。藍圖必須完美無瑕，因為施工隊不會質疑它——它只是建造。

步驟2：反向文件循環（強制問責）

這是大多數AI專案出錯的地方：AI編寫代碼，卻沒有人驗證它實際建造了什麼。

我們用我稱之為的過程解決了這個問題反向文件化。

在每個衝刺之後，我們將原始代碼輸入到一個單獨的 LLM，並給予一個指令：「記錄這段代碼實際上做了什麼。」

然後我們將這份反向工程的文件與我們的 220 頁規範進行比較。

如果它們匹配？衝刺接受，進入下一步。

如果它們不一致？我們在幻覺擴大之前捕捉到了它AI 誤解了一個需求，走了捷徑，或引入了違反架構的邏輯。我們立即修正了它。

這不是測試。這是機器速度下的對齊驗證。AI 寫作。AI 文件化。人類比較。重複進行。

在 14 天內，我們大約執行了這個循環40 次。試著讓人類工程師做到這一點。

步驟 3：消除 AI 漂移（整合作為不可妥協的條件）

AI 開發中最危險的失敗模式並不是明顯的錯誤。它是 漂移。

大型語言模型在長時間對話中會失去上下文。當它們在撰寫第 12 次衝刺時，會忘記第 2 次衝刺的約束。慢慢地、無法察覺地，架構開始衰退——直到你擁有六種不同的身份驗證實作、三種資料庫連接模式，以及一個認為自己在與不再存在的 API 交談的前端。

傳統測試在最後才會捕捉到這一點。到那時，你正在解開一團麻煩，成本超過了最初的建置。

我們每 3 次衝刺進行了 嚴格的整合和安全測試。不是軟性檢查。完整的測試套件：

• API 合約驗證

• 資料庫完整性檢查

• 安全邊界測試（身份驗證、授權、注入）

• 端到端工作流程驗證

如果測試失敗，我們會停止。我們會修正。我們會驗證。然後我們繼續。

**防漂移規則：** 在漂移發生之前進行測試。在機器速度下，技術負債以指數方式累積——而不是線性。

這是 氛圍編碼 和 系統工程。一個在第三個月之前感覺很快。另一個在你意識到你在兩週內發貨之前感覺很慢。

步驟 4：多模型委員會（對抗性質量控制）

AI 開發中最大的錯誤？ 使用一個模型來處理所有事情。

單一模型有盲點。它們在可預測的方式上自信地錯誤。它們優化一致性，而不是正確性。而且它們永遠不會說 "我對這部分不確定。"

我們使用了 三個不同的模型，每個模型都有特定的任務：

| 模型 | 角色 | 任務 | |-------|------|------| | 模型 1 (程式碼) | 建構者 | 根據規格生成執行程式碼 | | 模型 2 (紅隊) | 突破者 | 編寫旨在突破模型 1 程式碼的整合/安全測試 | | Model 3 (Scribe) | 翻譯者 | 閱讀程式碼庫，生成可讀的文件 |

這不僅僅是平行處理。它是對抗性質量控制。

Model 2 的整個工作是找出 Model 1 錯誤的地方。Model 3 的工作是揭示人類需要理解的複雜性。人類架構師負責協調、裁決和決策。

把它想像成機器速度下的 OODA 循環觀察（模型 3）、定位（人類）、決策（人類）、行動（模型 1）——模型 2 不斷對這個循環進行壓力測試。

沒有單一的失敗點。沒有單一模型的幻覺不受挑戰。委員會自我檢查，讓人類不必捕捉所有細節。

模式：從程式設計師到系統工程師

這是沒有人想聽到的事：純粹的程式設計師時代正在結束。

不是因為 AI 寫出更好的程式碼——雖然它確實如此。因為 AI 使執行自由，而自由執行改變了人類需要擅長的技能。

當混凝土昂貴時，泥水匠是有價值的。當混凝土變便宜時，建築師變得有價值。這種變化在軟體領域也在發生。

**新的價值層級：** 1. **問題定義**（規格） 2. **系統整合**（使各部分協同工作） 3. **風險管理**（捕捉偏差、安全性、邊緣案例） 4. **執行**（程式碼 — 現在已商品化）

整天撰寫 CRUD 端點的工程師正在被自動化。設計系統、管理 AI 勞動力並驗證整合的工程師正變得不可替代。

停止管理語法。開始管理系統。

這對你的組織意味著什麼

如果你是 CTO、工程副總裁或考慮 AI 開發的創始人，這是你的行動計畫：

停止：詢問「我們如何更快地編寫程式碼？」開始：詢問「我們如何如此精確地定義問題，以便 AI 能夠完美執行？」

停止：讓工程師隨意編碼以應對架構。開始：在任何 AI 生成的程式碼進入你的資料庫之前，要求詳細的規格。

停止：專案結束時的測試。開始：每 2-3 次衝刺執行嚴格的整合測試，至少。

停止：對所有事情使用一個 AI 模型。開始：建立一個具有對抗性檢查的多模型委員會。

停止：招聘打字快速的程式設計師。開始：招聘能夠從架構、整合和風險的角度思考的系統工程師。

655到14的壓縮不是一種噱頭。這是一個正常的預覽。

掌握以規格為先的多模型對抗性人工智慧工程的組織，將在幾週內交付出競爭對手需要幾年才能交付的產品。那些無法做到的組織將在2027年向他們的董事會解釋為什麼他們的人工智慧計畫「沒有如預期那樣成功」。

結論

我們之所以能達到 47 倍的壓縮，並不是因為我們是天才，而是因為我們把 AI 當作它實際上是的東西：一個需要治理的工作力量，而不是一根需要更好提示的魔法棒。

220 頁的規範是困難的部分。反向文檔循環是紀律。多模型委員會是安全系統。14 天的交付只是當你把系統做對時會發生的事情。

未來屬於系統工程師，而不是語法打字員。問題是你是否會成為其中之一。

水星科技解決方案：加速數位化。