為何你的 AI-First 策略可能是錯的？ (CREAO 實踐)

原始來源與檔名：為何你的AI-First策略可能是錯的.md

來源：@intuitiveml on X — 2026-04-13

NAPKIN | 餐巾纸

餐巾紙公式

真正的 AI-First = 重構工作流 (PM + QA + CI/CD) + 統一 Monorepo + AI 自動修復循環 + 人類架構師 (Architect)

一句話

作者分享了 CREAO 團隊如何真正實踐 “AI-First”：不是讓工程師用 Cursor 寫扣，而是徹底摧毀原有的軟體開發流程，讓 AI 成為主要的建設者，人類退居為設計邊界與評估風險的「架構師」，實現 10 人團隊達到百人團隊的產出 (每天發布 3-8 次)。

餐巾紙草图

[ Fake AI-First (AI-Assisted) ]
  - PM writes spec (2 weeks) -> Dev uses Cursor (2 hours) -> QA tests manually (3 days)
  - Bottleneck: Human PM and Human QA.

[ True AI-First (Harness Engineering) ]
  - Architect writes prompt/constraints.
  - AI builds feature & tests.
  - 3x AI Review Passes (Quality, Security, Dependencies).
  - CI/CD (Deterministic).
  - Production monitoring (CloudWatch) -> AI Triage -> Auto-creates tickets.

ROUND 1: SKELETON | 骨架掃描

核心問題: 為什麼許多宣稱 “AI-First” 的公司，效率只提升了 10-20%？
核心答案: 因為他們只是在既有流程上「外掛」AI (例如用 Cursor 寫程式)。真正的 AI-First 必須重構整個迴圈。當寫程式從幾週縮短到 2 小時，原本幾週的 PM 規劃與幾天的 QA 測試就會成為致命瓶頸。必須將這些環節全數自動化。

ROUND 2: DISSECTION | 血肉解剖

架構重構: 為了讓 AI 能看懂全局，作者花了兩週將分散的微服務程式碼庫重構為一個 Unified Monorepo (單一儲存庫)。
自動化審查與修復迴圈:
- 每一個 PR 會觸發 Claude 的 3 輪並行審查 (代碼品質、資安、依賴衝突)。
- 每天早上 AI 自動抓取 CloudWatch 日誌，進行分診 (Triage)、評分嚴重性並自動建立 Linear 任務。
組織重塑:
- The Architect (架構師): 全公司只需要 1-2 位。負責設計 SOP、邊界與測試基礎設施。核心能力是「批判與找漏洞」，而非寫扣。
- The Operator (操作員): 其他人。負責審查 AI 產出的 PR、微調 UI、確認邏輯風險。

ROUND 3: SOUL | 靈魂提取

深層洞見: 「適應力 (Adaptability) 大於累積技能 (Accumulated skill)。」 作者觀察到一個殘酷的現象：資淺工程師適應得比資深工程師快。因為資深工程師很難接受自己花了十年累積的架構經驗，AI 只需要一小時就能完成。未來最值錢的能力不是快速寫出程式碼，而是具備產品品味、懂得批判 AI 決策，並設計出能約束 AI (Harness Engineering) 的系統。

AI-Native Workflow Architecture (Architectural Deep Dive)

工作流的阿姆達爾定律 (Amdahl’s Law of Workflows)

阿姆達爾定律指出，系統的整體加速比，受限於系統中無法被加速的部分。這篇文章完美驗證了這一點：如果 Coding (實作) 佔原本流程的 30%，AI 把這 30% 加速了 100 倍，整體效率頂多提升 40%。因為剩下的 PM (需求分析) 和 QA (驗證) 成了絕對瓶頸。 架構結論：在 AI 時代，開發速度 (Velocity) 取決於你的自動化驗證管道 (Deterministic CI/CD & Automated Testing) 有多強，而不是你的 AI 寫代碼有多快。沒有自動化驗證的 AI 產出，只是在快速累積技術債。

系統可見性 (Legibility for Agents)

作者將多倉庫 (Polyrepo) 轉向單一倉庫 (Monorepo) 是一個非常深刻的架構決策。對於人類工程師，微服務/多倉庫可以降低認知負擔。但對於 Agent，多倉庫是隱藏上下文的黑盒。

Monorepo 確保了 Agent 可以一次性讀取前端組件、後端 API 定義與資料庫 Schema，這對於進行 Full-stack 的 PR 生成與靜態分析至關重要。
同理，強制使用結構化日誌 (Structured Logging in CloudWatch) 也是為了讓 AI (Triage Engine) 能看懂。未來的系統架構，不僅要 Human-readable，更要 Agent-readable。