為什麼你的「AI-First」策略很可能是錯的

我們 99% 的生產環境程式碼都是由 AI 編寫的。上週二，我們在上午 10 點發布了一項新功能，中午進行了 A/B 測試，下午 3 點因為資料顯示成效不佳而將其下架。我們在下午 5 點發布了一個更好的版本。三個月前，這樣的週期需要六週才能完成。

我們並非透過在 IDE 中加入 Copilot 來達到這一點。我們拆解了整個工程流程，並圍繞著 AI 進行了重建。我們改變了規劃、建置、測試、部署以及組織團隊的方式。我們改變了公司內每個人的角色。

CREAO 是一個 Agent 平台。我們有 25 名員工，其中 10 名是工程師。我們在 2025 年 11 月開始建置 Agent，兩個月前，我從零開始重構了整個產品架構和工程工作流程。

OpenAI 在 2026 年 2 月發表了一個概念，精準捕捉了我們一直在做的事情。他們稱之為「harness engineering」（裝備工程）：工程團隊的主要工作不再是編寫程式碼，而是啟用 Agent 來執行有用的工作。當出現故障時，解決方案絕不是「再努力一點」。解決方案是：缺少了什麼能力？我們該如何讓 Agent 能夠理解並執行它？

我們是自己得出這個結論的。當時我們還沒有為它命名。

AI-First 不等於使用 AI

大多數公司只是將 AI 外掛到現有的流程中。工程師打開 Cursor，產品經理 (PM) 用 ChatGPT 起草規格，QA 團隊嘗試用 AI 生成測試。工作流程依然如故。效率提升了 10% 到 20%，但結構上什麼都沒有改變。

這叫「AI 輔助」(AI-assisted)。

「AI-First」意味著你必須以「AI 是主要建置者」為前提，重新設計你的流程、架構和組織。你不再問「AI 如何幫助我們的工程師？」，而是開始問「我們該如何重組一切，讓 AI 負責建置，而工程師負責提供方向與判斷？」

這種差異是乘數效應的。

我看過許多團隊聲稱自己是 AI-First，卻依然執行著相同的衝刺 (Sprint) 週期、相同的 Jira 看板、相同的每週站會，以及相同的 QA 簽核流程。他們只是把 AI 加入了迴圈中，卻沒有重新設計這個迴圈。

這其中常見的一種形式被稱為「vibe coding」。打開 Cursor，不斷下 Prompt 直到程式碼能運作為止，提交，然後重複。這只能產出原型。生產系統需要穩定、可靠且安全。當 AI 編寫程式碼時，你需要一個能夠保證這些特性的系統。你負責建置這個系統，而 Prompt 只是消耗品。

我們為什麼必須改變

去年，我觀察了團隊的工作方式，發現了三個會毀掉我們的瓶頸。

產品管理瓶頸

我們的 PM 花了數週時間研究、設計並定義功能規格。產品管理幾十年來一直都是這樣運作的。但 Agent 可以在兩小時內實作一個功能。當建置時間從數月縮短到數小時，數週的規劃週期就變成了限制因素。

花幾個月時間思考，然後在兩小時內建置出來，這是不合理的。

PM 需要進化為具備產品思維的架構師，以迭代的速度工作，否則就必須退出建置週期。設計必須透過「快速原型-發布-測試-迭代」的迴圈來完成，而不是透過委員會審查規格文件。

QA 瓶頸

情況如出一轍。在 Agent 發布功能後，我們的 QA 團隊花了數天時間測試邊緣案例。建置時間：兩小時。測試時間：三天。

我們用 AI 建置的測試平台取代了手動 QA，用來測試 AI 編寫的程式碼。驗證速度必須與實作速度同步。否則，你只是在舊瓶頸的下游十英尺處，又建置了一個新的瓶頸。

人力瓶頸

我們的競爭對手有 100 倍甚至更多的人力在做類似的工作。我們只有 25 人。我們無法透過招聘來達到同等規模。我們必須透過重新設計來達成目標。

三個系統需要 AI 貫穿其中：我們如何設計產品、如何實作產品，以及如何測試產品。如果其中任何一個環節保持手動，它就會限制整個管線。

大膽的決定：統一架構

我必須先修復程式庫。

我們舊的架構分散在多個獨立的系統中。一個單一的變更可能需要觸及三到四個儲存庫。從人類工程師的角度來看，這是可控的；但從 AI Agent 的角度來看，這是晦澀難懂的。Agent 看不到全貌，無法推論跨服務的影響，也無法在本地執行整合測試。

我必須將所有程式碼統一到一個單一的 Monorepo 中。原因只有一個：讓 AI 能看見一切。

這是在實踐「harness engineering」的原則。你將系統中越多部分轉化為 Agent 可以檢查、驗證和修改的形式，你獲得的槓桿效應就越大。碎片化的程式碼對 Agent 來說是隱形的，而統一的程式碼則是清晰可讀的。

我花了一週時間設計新系統：規劃階段、實作階段、測試階段、整合測試階段。然後又花了一週時間，利用 Agent 重構了整個程式庫。

CREAO 是一個 Agent 平台。我們使用自己的 Agent 來重建運行 Agent 的平台。如果產品能自我建置，那它就能運作。

技術堆疊

以下是我們的堆疊以及每個組件的功能。

基礎設施：AWS

我們運行在 AWS 上，使用自動擴展的容器服務和斷路器回滾機制。如果部署後指標惡化，系統會自動還原。

CloudWatch 是中央神經系統。所有服務都進行結構化日誌記錄，擁有超過 25 個警報，自動化工作流程每天查詢自定義指標。每一項基礎設施都公開了結構化、可查詢的訊號。如果 AI 無法讀取日誌，它就無法診斷問題。

CI/CD：GitHub Actions

每一項程式碼變更都會通過六階段管線：

Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release

每個 Pull Request 的 CI 閘門都會強制執行型別檢查、Linting、單元與整合測試、Docker 建置、透過 Playwright 進行的 End to End (端到端) 測試，以及環境一致性檢查。沒有任何階段是可選的，也不允許手動覆寫。管線是確定性的，因此 Agent 可以預測結果並推論故障原因。

AI 程式碼審查：Claude

每個 Pull Request 都會觸發三次使用 Claude Opus 4.6 的平行 AI 審查：

• 第一輪：程式碼品質。 邏輯錯誤、效能問題、可維護性。
• 第二輪：安全性。 漏洞掃描、身份驗證邊界檢查、注入風險。
• 第三輪：依賴掃描。 供應鏈風險、版本衝突、授權問題。

這些是審查閘門，而不僅僅是建議。它們與人類審查並行，能在大規模作業下捕捉人類遺漏的問題。當你每天部署八次時，沒有任何人類審查員能對每個 PR 保持專注。

工程師也會在任何 GitHub issue 或 PR 中標記 @claude，以獲取實作計畫、除錯會話或程式碼分析。Agent 可以看到整個 Monorepo，上下文會在對話中延續。

自癒回饋迴圈

這是核心部分。

每天 UTC 上午 9:00，自動化健康工作流程會執行。Claude Sonnet 4.6 會查詢 CloudWatch，分析所有服務的錯誤模式，並生成一份執行級別的健康摘要，透過 Microsoft Teams 發送給團隊。沒人需要主動要求。

一小時後，分流引擎 (Triage Engine) 啟動。它會將來自 CloudWatch 和 Sentry 的生產環境錯誤進行分群，根據九個嚴重性維度對每個群組進行評分，並在 Linear 中自動生成調查工單。每張工單都包含範例日誌、受影響的使用者、受影響的端點以及建議的調查路徑。

系統會進行去重。如果現有的問題涵蓋了相同的錯誤模式，它會更新該問題。如果之前已關閉的問題再次出現，它會偵測到回歸並重新開啟。

當工程師推送修復程式時，同樣的管線會處理它。三次 Claude 審查進行評估，CI 進行驗證。六階段部署管線透過開發與生產環境進行推廣，並在每個階段進行測試。部署後，分流引擎會重新檢查 CloudWatch。如果原始錯誤已解決，Linear 工單會自動關閉。

每個工具處理一個階段，沒有工具試圖包辦一切。每日週期創造了一個自癒迴圈，錯誤在最少的人工干預下被偵測、分流、修復並驗證。

我曾告訴《Business Insider》的記者：「AI 會提交 PR，而人類只需要審查是否存在風險。」

功能旗標與支援堆疊

Statsig 處理功能旗標。每個功能都在閘門後發布。發布模式：先對團隊啟用，然後進行漸進式百分比發布，最後完全發布或下架。終止開關 (Kill switch) 可立即關閉功能，無需重新部署。如果功能導致指標惡化，我們會在幾小時內將其撤下。糟糕的功能在發布當天就會被終止。A/B 測試也透過同一個系統運行。

Graphite 管理 PR 分支：合併佇列會重新基底 (rebase) 到主分支，重新執行 CI，只有在通過時才合併。堆疊式 PR 允許以高吞吐量進行增量審查。

Sentry 報告所有服務的結構化例外，並由分流引擎與 CloudWatch 合併，以獲取跨工具的上下文。Linear 是面向人類的層級：自動建立帶有嚴重性評分、範例日誌和建議調查的工單。去重功能防止了雜訊，後續驗證會自動關閉已解決的問題。

功能如何從構思到生產

新功能路徑

1. 架構師將任務定義為結構化的 Prompt，包含程式庫上下文、目標和限制條件。
2. Agent 分解任務、規劃實作、編寫程式碼並生成自己的測試。
3. 開啟一個 PR。三次 Claude 審查進行評估。人類審查員檢查戰略風險，而非逐行檢查正確性。
4. CI 驗證：型別檢查、Linting、單元測試、整合測試、End to End 測試。
5. Graphite 的合併佇列進行重新基底、重新執行 CI，通過則合併。
6. 六階段部署管線在每個階段進行測試，並推廣至開發與生產環境。
7. 為團隊開啟功能閘門。進行漸進式百分比發布。監控指標。
8. 如果有任何惡化，可使用終止開關。嚴重問題可透過斷路器自動回滾。

錯誤修復路徑

1. CloudWatch 和 Sentry 偵測到錯誤。
2. Claude 分流引擎評分嚴重性，建立帶有完整調查上下文的 Linear 問題。
3. 工程師進行調查。AI 已經完成了診斷。工程師驗證並推送修復程式。
4. 經過相同的審查、CI、部署和監控管線。
5. 分流引擎重新驗證。如果已解決，工單自動關閉。

兩條路徑使用相同的管線。一個系統，一個標準。

成果

在 14 天內，我們平均每天進行 3 到 8 次生產環境部署。在我們舊的模式下，那整整兩週的時間甚至無法產生一次生產環境發布。

糟糕的功能在發布當天就會被撤下。新功能在構思當天就能上線。A/B 測試即時驗證影響。

人們以為我們是用品質換取速度。但使用者參與度上升了，支付轉換率也上升了。我們產出的結果比以前更好，因為回饋迴圈更緊密。每天發布比每月發布能學到更多。

新的工程組織

未來將存在兩種類型的工程師。

架構師 (The Architect)

一到兩個人。他們設計教導 AI 如何工作的標準作業程序 (SOP)。他們建置測試基礎設施、整合系統、分流系統。他們決定架構和系統邊界。他們定義 Agent 的「好」是什麼樣子。

這個角色需要深刻的批判性思考。你要批評 AI，而不是盲從它。當 Agent 提出計畫時，架構師要找出漏洞。它錯過了哪些故障模式？它跨越了哪些安全邊界？它累積了哪些技術債？

我擁有物理學博士學位。博士學位教給我最有用的東西，就是如何質疑假設、壓力測試論點，以及尋找缺失的部分。批評 AI 的能力將比產出程式碼的能力更有價值。

這也是最難填補的角色。

操作員 (The Operator)

其他人。工作內容很重要，但結構不同。

AI 將任務分配給人類。分流系統發現錯誤、建立工單、呈現診斷結果，並將其分配給合適的人。該人員進行調查、驗證並批准修復。AI 製作 PR，人類審查是否存在風險。

任務包括錯誤調查、UI 優化、CSS 改進、PR 審查、驗證。這些需要技巧和專注力，但不需要舊模式所要求的架構推論能力。

誰適應得最快

我注意到一個我沒預料到的模式：初級工程師比資深工程師適應得更快。

缺乏傳統實踐經驗的初級工程師感到被賦權。他們擁有能放大影響力的工具，不需要克服十年累積下來的習慣。

擁有深厚傳統實踐經驗的資深工程師最痛苦。他們兩個月的工作量，AI 一小時就能完成。在建立了一套稀缺技能多年後，這是一件很難接受的事。

我不是在做價值判斷，我只是在描述我觀察到的現象。在這次轉型中，適應力比累積的技能更重要。

人性的一面

管理層崩潰

兩個月前，我 60% 的時間花在管理人員上。協調優先級、主持會議、提供回饋、指導工程師。

現在：不到 10%。

傳統的 CTO 模式要求你賦權團隊進行架構工作、培訓他們、授權給他們。但如果系統只需要一兩名架構師，我必須親力親為。我從管理轉向了建置。我大多數日子從早上 9 點寫程式到凌晨 3 點。我設計系統的 SOP 和架構，我維護這個裝備。

壓力更大，但我享受建置的過程，而不是協調。

爭論減少，關係更好

我和共同創辦人以及工程師的關係比以前更好。

轉型前，我和團隊的大部分互動都是協調會議。討論權衡、辯論優先級、爭論技術決策。這些對話在傳統模式中是必要的，但也令人疲憊。

現在我仍然和團隊交談，但我們聊的是其他事情。非工作話題、隨意對話、公司旅遊。我們相處得更好，因為我們不再為了那些可以由系統輕鬆完成的工作而爭論。

不確定性是真實存在的

我不會假裝每個人都很開心。

當我不再每天和每個人交談時，一些團隊成員感到不安。CTO 不跟我說話代表什麼？我在這個新世界中的價值是什麼？這些都是合理的擔憂。

有些人花更多時間爭論 AI 是否能完成他們的工作，而不是實際去執行工作。過渡期會產生焦慮。我沒有完美的答案。

但我有一個原則：我們不會因為工程師引入了生產環境錯誤而開除他。我們會改進審查流程、加強測試、增加護欄。這同樣適用於 AI。如果 AI 犯了錯，我們就建置更好的驗證、更清晰的限制、更強大的可觀測性。

超越工程領域

我看到其他公司採用 AI-First 工程，卻讓其他一切保持手動。

如果工程部門在幾小時內發布功能，但行銷部門需要一週時間來宣傳，那麼行銷就是瓶頸。如果產品團隊仍然執行每月的規劃週期，規劃就是瓶頸。

在 CREAO，我們將 AI 原生運作推廣到每個職能：

• 產品發布說明：由變更日誌和功能描述自動生成。
• 功能介紹影片：AI 生成的動態圖形。
• 每日社群貼文：AI 編排並自動發布。
• 健康報告與分析摘要：從 CloudWatch 和生產資料庫中由 AI 生成。

工程、產品、行銷和成長都在一個 AI 原生的工作流程中運行。如果一個職能以 Agent 的速度運作，而另一個職能以人類的速度運作，那麼人類速度的職能就會限制一切。

這意味著什麼

對工程師而言

你的價值正在從「程式碼產出」轉向「決策品質」。快速編寫程式碼的能力每個月都在貶值。評估、批評和指導 AI 的能力則越來越有價值。

產品感或品味很重要。你能在使用者告訴你之前，就看出生成的 UI 是錯的嗎？你能在 Agent 提出的架構提案中，看出它遺漏的故障模式嗎？

我告訴我們 19 歲的實習生：訓練批判性思考。學習評估論點、發現差距、質疑假設。學習什麼是好的設計。這些技能會產生複利效應。

對 CTO 和創辦人而言

如果你的 PM 流程比建置時間還長，就從那裡開始改。

在擴展 Agent 之前，先建置測試裝備。沒有快速驗證的快速 AI，只是移動速度很快的技術債。

從一位架構師開始。找一個能建置系統並證明其有效的人。在系統運行後，再讓其他人加入操作員角色。

將 AI 原生推向每個職能。

預期會遇到阻力。有些人會反對。

對產業而言

OpenAI、Anthropic 和多個獨立團隊在相同的原則上達成了共識：結構化上下文、專業化 Agent、持久記憶和執行迴圈。「Harness engineering」正在成為標準。

模型能力是推動這一切的時鐘。我將 CREAO 的整個轉變歸功於過去兩個月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型將進一步加速這一進程。

我相信一人公司將變得普遍。如果一位架構師配合 Agent 可以完成 100 個人的工作，許多公司將不再需要第二名員工。

我們還在早期階段

我交談過的大多數創辦人和工程師仍然以傳統方式運作。有些人考慮做出轉變，但很少有人真正做到。

一位記者朋友告訴我，她就這個話題採訪了大約五個人。她說我們比任何人都走得更遠：「我不認為有人像你們這樣徹底重構了整個工作流程。」

任何團隊都有現成的工具可以做到這一點。我們的堆疊中沒有任何專有技術。

競爭優勢在於「圍繞這些工具重新設計一切」的決策，以及「吸收成本」的意願。成本是真實存在的：員工的不確定性、CTO 每週 18 小時的工作時間、資深工程師對自身價值的質疑，以及舊系統消失但新系統尚未證明的兩週過渡期。

我們吸收了這些成本。兩個月後，數據說明了一切。

我們建置了一個 Agent 平台，而且我們是用 Agent 建置出來的。