# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Peter Pang (@intuitiveml) · 平台：X (Twitter) · 日期：2026-04-14

> 原始來源：https://x.com/intuitiveml/status/2043545596699750791

## 中文摘要

# 為什麼你的「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

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776128734191-iaHFwEVlnbkAAYtWMjpg.jpg)

大多數公司只是將 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 貫穿其中：我們如何設計產品、如何實作產品，以及如何測試產品。如果其中任何一個環節保持手動，它就會限制整個管線。

## 大膽的決定：統一架構

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776128734184-iaHFwEjnpbEAAXeFcjpg.jpg)

我必須先修復程式庫。

我們舊的架構分散在多個獨立的系統中。一個單一的變更可能需要觸及三到四個儲存庫。從人類工程師的角度來看，這是可控的；但從 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 工單會自動關閉。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776128734151-diaHFwUNbua4AA65zjpg.jpg)

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

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

### 功能旗標與支援堆疊

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

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

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

## 功能如何從構思到生產

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776128734194-diaHFwUDbna8AAQ8Fjpg.jpg)

### 新功能路徑

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. 分流引擎重新驗證。如果已解決，工單自動關閉。

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

## 成果

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776128734178-iaHFwUohKbcAAi0cmpng.png)

在 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 建置出來的。

## 標籤

Agent, 產業趨勢, 其他, CREAO