從 vibe coding 到 AI 員工團隊自動化，淺聊 AI 編程的 4 個階段
整理版優先睇
AI編程分四個階段，關鍵係診斷自己喺每個場景嘅實際位置，唔好以為一個階段通行所有業務環節。
呢篇文章係作者周知嘅經驗分享，佢喺AI編程已經做到第四階段，但其他業務場景（例如客戶服務、內容營銷）仲喺二、三階段。佢想幫讀者搞清楚：AI編程唔係單一能力，而係四個完全唔同嘅能力階段，由Vibe Coding到智能體團隊自動化。整體結論係：階段唔係你個人嘅固定等級，而係每個業務環節獨立嘅位置，你要分場景診斷先至有用。
文章定義咗四個階段：階段一Vibe Coding係全憑感覺，唔睇代碼，典型工具係Claude對話框；階段二協作Coding係你主導架構，AI幫手實現，好似導航幫司機帶路；階段三編排Coding係你設計任務結構，AI agent自主執行，你可以30分鐘唔掂鍵盤；階段四智能體團隊自動化係多個agent分工寫碼、審碼、測試、部署，你只做CEO設定目標同最終驗收。每個階段都有對應嘅工具、常見錯覺同行動公式。
最重要嘅啟發係：階段四唔代表所有場景都到咗。作者自己都話，佢喺客戶服務、內容營銷等場景仲係二、三階段。所以讀者要誠實診斷自己喺每個業務場景嘅實際階段，然後針對性升階，而唔係盲目追求最高階段。行動起點係：揀一個功能，用任務描述語言交畀AI，全程唔手寫代碼，睇下自己喺邊個階段。
- 結論：AI編程四個階段嘅本質係人機分工演化，由「你只睇結果」到「你係CEO」。
- 方法：每個階段都有行動公式，例如階段二嘅「review每行AI代碼，揾出3處唔同意見」係升階核心。
- 差異：階段一係感覺驅動，階段二係理解驅動，階段三係結構驅動，階段四係系統驅動。
- 啟發：階段唔係個人層級，而係每個業務場景獨立，要分場景診斷。
- 可行動點：用任務描述語言測試自己係咪到咗階段三，例如叫Claude Code完整實作一個功能，全程唔手動寫碼。
內容片段
┌──────┐ ┌──────┐ ┌──────┐│ 你 │ ───▶ │ AI │ ───▶ │ 結果 │。└──────┘ 說話 └──────┘ 生成 └──────┘。 ▲ │ └────────跑不通就繼續說───────┘。你的角色：只看結果 · 不看代碼。AI 的角色：每次從零生成 · 沒有上下文記憶。Vibe Coding：全憑感覺嘅初階
呢個階段嘅核心係你唔寫代碼，只描述想要嘅嘢，AI生成，你睇結果。跑唔通就繼續講，直到得為止。Andrej Karpathy喺2025年2月創造咗呢個詞，Collins Dictionary仲將佢列為年度詞彙之一。
你唔關心代碼點寫，只關心佢跑唔跑
典型場景係用Cursor或Claude.ai對話框，要求「我要一個登錄頁面，藍色按鈕」，然後將生成嘅代碼粘入項目。代表工具包括Claude.ai對話框、ChatGPT、早期GitHub Copilot Chat。
常見錯覺：以為自己高效用AI，其實只係將Stack Overflow換成AI
階段一有個極端變種叫「我也不」，連睇代碼都唔睇，完全託付。升階判據係你開始問具體問題，例如「呢個函數點解返回undefined」。
協作Coding：你主導，AI加速
呢個階段你主導架構，AI負責實現。你能睇得明輸出，發現問題，畀到精準修改指令。好似你揸車，AI係導航——你要識揸車，先判斷到佢導錯。
典型工具：GitHub Copilot Tab模式、Cursor非Agent模式、Tabnine
Greptile報告話超過80%聲稱用AI編程嘅開發者，其實只係停留喺呢個階段——將AI當做高級補全工具。
升階判據：每次畀AI嘅任務係幾大塊？中間要插手幾次？
- 1 如果你調一次AI，改10行以內，然後自己繼續寫：階段二
- 2 如果你開始可以畀AI「實現呢個功能，包括測試，我去飲杯水」：準備進階段三
編排Coding：你係指揮，AI係樂團
呢個階段你唔寫代碼，你設計任務結構，將問題拆成AI可執行嘅單元，然後編排執行、驗證結果。你嘅思維單位由「文件」或「函數」變成「任務」。
Karpathy升級咗vibe coding概念，改叫Agentic Engineering——99%時間唔寫代碼，係編排agent寫代碼
典型場景：喺Cursor Agent模式畀AI一個GitHub issue，叫佢做完包括前後端同測試，然後你去做其他嘢，返嚟review PR。代表工具包括Claude Code、Cursor Composer、Devin等。
量化指標：連續30分鐘唔掂鍵盤，AI仲喺度工作
常見錯覺係以為「agentic」就係叫AI做多幾步。其實核心係你設計嘅任務結構質量。爛結構，AI做100步都亂；好結構，20步出產品級結果。
升階判據：當你覺得單個agent速度係瓶頸，想同時跑多條任務線，你就準備進階段四。
智能體團隊自動化：你係CEO，agent係團隊
呢個階段多個AI agent並行運行，各自承擔專門角色——寫碼、審碼、測試、部署——你只負責目標設定同最終驗收。呢個係2026年嘅前沿，開始改變軟件行業結構。
Stripe嘅Minions系統每週自動生成並合併超過1,300個pull request
呢個唔係demo，係生產環境。LangChain博客叫呢個做Agentic Engineering嘅終態：一羣AI agent好似真實軟件團隊咁運轉。
常見錯覺：以為係大公司先玩得起，但Stripe Minions係由小團隊實驗開始
升階判據：如果你連階段三都未穩定，唔好跳步。要先學識清晰拆解任務，先設計到合理嘅agent角色分工。
自我診斷：你企喺邊度？
作者自己話，佢AI編程已經到第四階段，但客戶服務、內容營銷等場景仲係二、三階段。佢提醒：階段唔係你個人嘅位置，係每個具體業務環節嘅位置。
好多人卡喺一個錯覺：以為搞掂AI編程就係搞掂AI，其實係兩件事
更深層嘅問題：任務結構設計能力係咪可以跨場景遷移？如果唔係，每個場景都要從頭爬階梯。AI降低咗某些場景門檻，但每個場景都重新畫咗一條階梯。
AI編程唔係一種能力，而係四種完全唔同嘅能力。
01一、階段一：Vibe Coding（全憑感覺，包括「我都唔理」）
┌──────┐ ┌──────┐ ┌──────┐
│ 你 │ ───▶ │ AI │ ───▶ │ 結果 │。
└──────┘ 說話 └──────┘ 生成 └──────┘。
▲ │
└────────跑不通就繼續說───────┘。
你的角色：只看結果 · 不看代碼。
AI 的角色：每次從零生成 · 沒有上下文記憶。
定義你唔寫code，你描述想要啲咩，AI生成，你睇結果，覺得唔啱就繼續講。
2025年2月，Andrej Karpathy——OpenAI聯合創辦人、前Tesla AI負責人——喺X上面創造咗一個詞：vibe coding。佢原先嘅意思係「完全投入喺感覺裏面，擁抱指數，甚至忘記code嘅存在」。Collins Dictionary將呢個詞列為2025年度詞彙之一。
呢個就係階段一嘅本質。
你唔關心code點寫出嚟，你只關心佢行唔行得通。提示詞send出去，等結果，行得通就係成功，行唔通就繼續講。
典型場景用Cursor或者Claude.ai對話框，描述「我要一個登入頁面，藍色按鈕，帶Google OAuth」，然後將生成嘅code貼落項目度。出bug就不斷貼，直到行得通。
代表工具Claude.ai對話框、ChatGPT、早期GitHub Copilot Chat（只用chat而唔用agent模式）。
常見錯覺好多人以為自己高效緊用AI，但實際上只係將Stack Overflow換成AI。本質操作模式冇變——遇到問題、揾答案、貼上、祈禱。
階段一有一個更加極端嘅變種，就係「我都唔理」——連code都唔睇，完全交畀人。呢個唔算獨立嘅階段，而係vibe coding嘅完全形態。Karpathy講嘅「忘記code嘅存在」，就係指呢個狀態。
升階判據如果你問AI嘅問題越來越具體（「呢個function點解return undefined」「呢度嘅非同步邏輯係咪有競爭條件」），即係你開始向階段二行。如果你仲係靠描述結果嚟驅動AI，你就喺階段一。
行動公式讀明AI畀你嘅至少30%嘅code，然後再讀30%，直到你睇得出邊度可能會出問題。
02二、階段二：協作Coding（你識code，AI係加速器）
┌────────────────────┐
│ 你（設計 + 判斷） │ ◀──────┐。
└────────────────────┘ │
│ 寫代碼框架 │ review
▼ │ 通過/修改
┌────────────────────┐ │
│ AI（Tab 補全 + 加速）│ ───────┘。
└────────────────────┘ 10 行內輸出。
你的角色：主導架構 · 看懂每一行 · 給精準指令。
AI 的角色：實現已知方案 · 不做決策。
定義你主導設計，AI負責實現。你睇得明輸出，發現到問題，畀到精準修改指令。
呢個係大部份有編程背景嘅開發者，喺2024-2025年進入嘅階段。
你睇我打個比喻（呢個比喻我想咗幾日，可能都唔算特別貼切）。以前你寫code，係自己踩單車。階段一係叫AI幫你踩，你閂咗眼坐喺後面。階段二係你自己揸車，AI係導航——佢可以令你快好多，但你要識揸車，判斷到佢導錯咗。
典型場景用Cursor嘅Tab補全功能，完成一個function嘅實現；用Copilot寫單元測試；喺Claude Code裏面問「呢段SQL查詢嘅性能瓶頸喺邊」——然後自己判斷建議合唔合理。
代表工具GitHub Copilot（Tab模式）、Cursor編輯器（非Agent模式）、Tabnine、Amazon CodeWhisperer。
常見錯覺以為自己已經喺「用AI編程」嘅前沿。
你睇，喺2024年，呢個的確係前沿。到2026年，呢個只係標配。
Greptile嘅《AI編程現狀》報告顯示，超過80%聲稱喺「使用AI編程」嘅開發者，實際上停留喺呢個階段——將AI當成更好嘅code補全工具。（來源：greptile.com/state-of-ai-coding · 具體百分比有待驗證）
升階判據量化指標有兩個——你每次畀AI嘅任務有幾大塊，以及你中間要插手幾次。
如果你叫一次AI，改10行以內，然後自己繼續寫：階段二。
如果你開始可以畀AI佈置「實現呢個功能，包括測試，我去飲杯水」：準備進階段三。
行動公式揾一個你完全識嘅功能，叫AI全部寫，然後review每一行，找出3處你會寫得唔一樣嘅地方。呢個review能力，係升階嘅核心資產。
03三、階段三：編排Coding（你係指揮，AI係樂團）
┌─────────────────┐
│ 你（拆任務結構） │ ← 寫任務描述 + 驗收標準。
└─────────────────┘
│
▼
┌──────────────────────────────────┐
│ AI Agent（自主跑端到端） │。
│ 讀代碼 → 找依賴 → 重構 → 測試 → 提交 │。
└──────────────────────────────────┘
│
▼ 30 分鐘不碰鍵盤
┌─────────────────┐
│ 你（review PR） │ ← 接受 / 改任務描述重跑。
└─────────────────┘
你的角色：設計任務圖 · 不碰代碼。
AI 的角色：端到端執行 · 自主補全決策。
定義你唔寫code，你設計任務結構，將問題拆解成AI可執行嘅單元，然後編排執行、驗證結果。
呢個階段有個關鍵轉折點。
你唔再以「文件」或「函數」為單位思考，而係以「任務」為單位。你唔係寫code，你係設計一個令AI可以高效完成嘅任務圖。
Karpathy自己喺2026年2月升級咗vibe coding嘅概念，改叫「Agentic Engineering」——你99%嘅時間唔係寫code，而係編排agent寫code。Anthropic嘅《2026 Agentic Coding趨勢報告》將呢個轉變定義為呢一年最重要嘅範式轉移。
典型場景喺Cursor Agent模式裏面，畀AI一個GitHub issue連結話「將呢個功能做完，包括前後端同測試」，然後去做其他嘢，返嚟review PR。或者用Claude Code從命令列啟動一個任務鏈——讀code庫、揾依賴、重構、跑測試、提commit。
CIO Magazine嘅報道入面描述咗呢個場景：從vibe coding到多agent編排，架構師嘅思維從「點樣寫」轉向「點樣拆」。
代表工具Claude Code（終端機命令列agent）、Cursor Composer（多文件agent模式，2026年5月啱啱發佈Composer 2.5）、Devin（雲端自主軟件工程師）、GitHub Copilot嘅agent mode。
一個量化指標：如果你可以連續30分鐘唔掂鍵盤，AI仲喺度做緊嘢，你好大機會喺階段三。
常見錯覺好多人以為「agentic」就係叫AI做多幾步。唔係。階段三嘅核心唔係AI做幾多步，係你設計嘅任務結構質素。差嘅任務結構，AI做100步都係亂嘅。好嘅任務結構，20步就出到產品級結果。
升階判據你開始覺得單一agent嘅速度係瓶頸，想同時跑多條任務線——呢個想法出現嘅時候，你就準備好進階段四嘞。
行動公式揀一個本來要自己花半日嘅功能，淨係用任務描述語言畀Claude Code或者Cursor Agent，叫佢完整實現。全程唔好手動寫code。成功咗，恭喜你進入階段三。失敗咗，檢查嚇你嘅任務描述喺邊度模糊咗。
04四、階段四：智能體團隊自動化（你係CEO，agent係團隊）
┌──────────────┐
│ 你（CEO） │ ← 目標設定 + 最終驗收
└──────────────┘
│ 業務需求
▼
┌──────────────┐
│ Agent 編排層 │
└──────────────┘
↙ ↓ ↓ ↘
┌────┐┌────┐┌────┐┌────┐
│寫碼││審碼││測試││部署│
│Agt ││Agt ││Agt ││Agt │
└────┘└────┘└────┘└────┘
↘ ↓ ↓ ↙
┌──────────────┐
│ 完整 feature │
└──────────────┘
你的角色：不碰代碼層 · 只設目標 + 最終驗收。
AI 的角色：多 agent 並行 · 角色分工 · 同行評審。
定義多個AI agent並行運行，各自承擔專門角色（寫code、審code、寫測試、做review、部署），你負責目標設定同最終驗收。
呢個係2026年嘅前沿，亦係真正開始改變軟件行業結構嘅階段。
Stripe喺2026年3月被報道：佢哋嘅「Minions」系統——一套自主AI agent網絡——每星期自動生成並合併超過1,300個pull request，全程接入CI/CD管道，唔需要開發者手動寫一行code。呢個唔係demo，呢個係生產環境。
LangChain嘅博客將呢個階段叫做「Agentic Engineering」嘅終極狀態：一羣AI agent好似真實軟件團隊咁運作——有人寫code，有人review，有人測試，有人部署，有人監控。
arxiv上面一篇2026年嘅論文（Agyn系統）專門研究咗multi-agent團隊架構：單一agent嘅問題在於將異質職責壓喺一個agent上；多agent引入角色分工、同行評審、結構化協作，呢個先係真正嘅軟件團隊自動化。
典型場景一間初創公司嘅CTO喺朝早9點畀團隊嘅AI系統提交一個產品需求，傍晚6點就攞到一個可以上線嘅功能，中間冇一個人類工程師參與code層面嘅工作。呢個場景喺2026年已經開始出現喺早期採用者身邊。
代表工具Devin（Nubank案例：8-12倍效率提升、企業採用量月增40%，來源：digitalapplied.com · 有待驗證）、OpenDevin（開源）、GitHub Copilot Agent Mode + Actions編排、Claude Code + MCP工具鏈編排、Anthropic Managed Agents（有待驗證具體發佈時間線）。
SWE-bench Verified基準：Claude Opus 4.5已經達到80.9%，即係top agent可以自主解決GitHub真實issue嘅能力已經超過80%。
常見錯覺以為呢個係「大公司先玩得起嘅嘢」。
錯咗。Stripe嘅Minions架構係由小團隊實驗開始嘅。2026年最大嘅機會，唔係有幾多資源，而係邊個最先將多agent流水線行得通。
升階判據如果你而家連階段三都未穩定，唔好急住跳去階段四。階段四需要你先可以清晰拆解任務（階段三嘅核心技能），先設計到合理嘅agent角色分工。跳步會令multi-agent系統嘅錯誤好難溯源。
行動公式揾一個可以拆成三條獨立任務線嘅項目（例如：前端 + API + 測試），分別用三個Claude Code session並行跑，最後手動合併review。呢個係階段四嘅最小可行實踐。
05你企喺邊度
我自己，講真，AI編程呢件事，已經喺第四階段嘞。
可以用Claude Code同時跑三條任務線，自己淨係做最後嘅合併review。呢套流程覆蓋咗我AI編程場景嘅大約75%。淨低25%係邊界情況——複雜bug定位、跨模塊重構、同客戶對需求——呢啲仲要我自己介入。
但寫到呢度我先意識到一件事，係我前面冇講清楚嘅——。
階段唔係「你呢個人」嘅位置，而係「你每個具體業務環節」嘅位置。
我AI編程去到第四階段。但OPC嘅其他場景——客戶服務、內容營銷、產品交付、社羣營運——我大部份仲喺階段二、階段三。
好多人卡喺一個錯覺入面——以為搞掂咗AI編程，就係搞掂咗AI。
呢個係兩件事。
階段四唔係「你喺所有場景都到階段四」，而係「你喺某個場景到咗階段四」。呢個區分，我自己諗清楚都用咗一年。
更深一層我冇諗清楚嘅係——任務結構設計嘅能力，係一種可以跨場景遷移嘅通用技能，定係每個垂直場景都要重新建立一次嘅領域直覺？
如果係後者，即係話：你喺AI編程到咗階段四，唔會自動令你喺客戶服務都到階段四。每個場景都要從頭爬一次階梯。
AI降低咗某啲場景嘅門檻，但佢喺每個場景入面都重新畫咗一條階梯。
你自己喺邊啲場景入面、邊啲階段上面？
更加重要嘅係：呢四個階段，係能力台階，定係思維框架？
你以為自己喺邊個場景嘅邊個階段，同你實際喺嘅之間嘅差距——先係你今年真正要補嘅嗰門課。
周知 · 我哋一齊同AI覺醒超級個體
AI 編程不是一種能力。是四種完全不同的能力。
01一、階段一：Vibe Coding（全憑感覺，包括"我也不"）
┌──────┐ ┌──────┐ ┌──────┐
│ 你 │ ───▶ │ AI │ ───▶ │ 結果 │。
└──────┘ 說話 └──────┘ 生成 └──────┘。
▲ │
└────────跑不通就繼續說───────┘。
你的角色：只看結果 · 不看代碼。
AI 的角色：每次從零生成 · 沒有上下文記憶。
定義：你不寫代碼，你描述想要什麼，AI 生成，你看結果，感覺不對就繼續說。
2025 年 2 月，Andrej Karpathy——OpenAI 聯合創始人、前特斯拉 AI 負責人——在 X 上造了一個詞：vibe coding。他原話的意思是"完全投入到感覺裏，擁抱指數，甚至忘記代碼的存在"。Collins Dictionary 把這個詞列為 2025 年度詞彙之一。
這就是階段一的本質。
你不關心代碼是怎麼寫的。你只關心它跑不跑。提示詞發出去，等結果，跑通了就是成功，跑不通就繼續提。
典型場景：用 Cursor 或 Claude. ai 對話框，描述"我要一個登錄頁面，藍色按鈕，帶 Google OAuth"，然後把生成的代碼粘進項目。出 bug 就繼續粘，直到跑通。
代表工具：Claude. ai 對話框、ChatGPT、早期 GitHub Copilot Chat（只用聊天不用 agent 模式）。
常見錯覺：很多人以為自己在高效使用 AI，實際上只是把 Stack Overflow 換成了 AI。本質操作模式沒變——遇到問題、找答案、粘貼、祈禱。
階段一有一個更極端的變種，就是"我也不"——連看代碼都不看，完全託付。這不算獨立的階段。這是 vibe coding 的完全形態。Karpathy 說的"忘記代碼的存在"，指的就是這個狀態。
升階判據：如果你問 AI 的問題越來越具體（"這個函數為什麼返回 undefined""這裏的異步邏輯是不是有競態條件"），說明你開始往階段二走了。如果你還在靠描述結果來驅動 AI，你在階段一。
行動公式：讀懂 AI 給你的至少 30% 的代碼，然後再讀 30%，直到你能看出哪裏可能出問題。
02二、階段二：協作 Coding（你懂代碼，AI 是加速器）
┌────────────────────┐
│ 你（設計 + 判斷） │ ◀──────┐。
└────────────────────┘ │
│ 寫代碼框架 │ review
▼ │ 通過/修改
┌────────────────────┐ │
│ AI（Tab 補全 + 加速）│ ───────┘。
└────────────────────┘ 10 行內輸出。
你的角色：主導架構 · 看懂每一行 · 給精準指令。
AI 的角色：實現已知方案 · 不做決策。
定義：你主導設計，AI 負責實現。你能看懂輸出，能發現問題，能給出精準修改指令。
這是大多數有編程背景的開發者，在 2024-2025 年進入的階段。
你看我打個比方（這比喻我想了幾天，可能也不算特別貼）。過去你寫代碼，是自己騎自行車。階段一是讓 AI 幫你騎，你閉着眼睛坐在後面。階段二是你自己開車，AI 是導航——它能讓你快很多，但你必須會開車，能判斷它導錯了。
典型場景：用 Cursor 的 Tab 補全功能，完成一個函數的實現；用 Copilot 寫單元測試；在 Claude Code 裏問"這段 SQL 查詢的性能瓶頸在哪"——然後自己判斷建議合不合理。
代表工具：GitHub Copilot（Tab 模式）、Cursor 編輯器（非 Agent 模式）、Tabnine、Amazon CodeWhisperer。
常見錯覺：以為自己已經在"用 AI 編程"的前沿了。
你看，在 2024 年，這確實是前沿。到 2026 年，這只是標配。
Greptile 的《AI 編程現狀》報告顯示，超過 80% 聲稱在"使用 AI 編程"的開發者，實際上停留在這個階段——把 AI 當更好的代碼補全工具。（來源：greptile. com/state-of-ai-coding · 具體百分比待驗證）
升階判據：量化指標有兩個——你每次給 AI 的任務有多大塊，以及你中間要插手幾次。
如果你調一次 AI，改 10 行以內，然後自己繼續寫：階段二。
如果你開始能給 AI 佈置"實現這個功能，包括測試，我去喝杯水"：準備進階段三了。
行動公式：找一個你完全懂的功能，讓 AI 全寫，然後 review 每一行，找出 3 處你會寫得不一樣的地方。這個 review 能力，是升階的核心資產。
03三、階段三：編排 Coding（你是指揮，AI 是樂團）
┌─────────────────┐
│ 你（拆任務結構） │ ← 寫任務描述 + 驗收標準。
└─────────────────┘
│
▼
┌──────────────────────────────────┐
│ AI Agent（自主跑端到端） │。
│ 讀代碼 → 找依賴 → 重構 → 測試 → 提交 │。
└──────────────────────────────────┘
│
▼ 30 分鐘不碰鍵盤
┌─────────────────┐
│ 你（review PR） │ ← 接受 / 改任務描述重跑。
└─────────────────┘
你的角色：設計任務圖 · 不碰代碼。
AI 的角色：端到端執行 · 自主補全決策。
定義：你不寫代碼，你設計任務結構，把問題拆解成 AI 可執行的單元，然後編排執行、驗證結果。
這個階段有個關鍵轉折點。
你不再以"文件"或"函數"為單位思考，而是以"任務"為單位。你不是在寫代碼，你在設計一個讓 AI 能高效完成的任務圖。
Karpathy 自己在 2026 年 2 月升級了 vibe coding 的概念，改叫"Agentic Engineering"——你 99% 的時間不在寫代碼，你在編排 agent 寫代碼。Anthropic 的《2026 Agentic Coding 趨勢報告》把這個轉變定義為這一年最重要的範式遷移。
典型場景：在 Cursor Agent 模式裏，給 AI 一個 GitHub issue 連結說"把這個功能做完，包括前後端和測試"，然後去做別的事情，回來 review PR。或者用 Claude Code 從命令行啓動一個任務鏈——讀代碼庫、找依賴、重構、跑測試、提 commit。
CIO Magazine 的報道里描述了這個場景：從 vibe coding 到多 agent 編排，架構師的思維從"怎麼寫"轉向"怎麼拆"。
代表工具：Claude Code（terminal 命令行 agent）、Cursor Composer（多文件 agent 模式，2026 年 5 月剛發佈 Composer 2.5）、Devin（雲端自主軟件工程師）、GitHub Copilot 的 agent mode。
一個量化指標：如果你能連續 30 分鐘不碰鍵盤，AI 還在工作，你大概率在階段三。
常見錯覺：很多人以為"agentic"就是讓 AI 多做幾步。不是。階段三的核心不是 AI 做多少步，是你設計的任務結構質量。爛任務結構，AI 做 100 步也是亂的。好的任務結構，20 步能出產品級結果。
升階判據：你開始覺得單個 agent 的速度是瓶頸，想同時跑多條任務線——這個想法冒出來的時候，你準備好進階段四了。
行動公式：選一個本來要自己花半天的功能，只用任務描述語言給 Claude Code 或 Cursor Agent，要求它完整實現。全程不要手動寫代碼。成功了，恭喜你進階三。失敗了，檢查你的任務描述在哪裏模糊了。
04四、階段四：智能體團隊自動化（你是 CEO，agent 是團隊）
┌──────────────┐
│ 你（CEO） │ ← 目標設定 + 最終驗收
└──────────────┘
│ 業務需求
▼
┌──────────────┐
│ Agent 編排層 │
└──────────────┘
↙ ↓ ↓ ↘
┌────┐┌────┐┌────┐┌────┐
│寫碼││審碼││測試││部署│
│Agt ││Agt ││Agt ││Agt │
└────┘└────┘└────┘└────┘
↘ ↓ ↓ ↙
┌──────────────┐
│ 完整 feature │
└──────────────┘
你的角色：不碰代碼層 · 只設目標 + 最終驗收。
AI 的角色：多 agent 並行 · 角色分工 · 同行評審。
定義：多個 AI agent 並行運行，各自承擔專門角色（寫代碼、審代碼、寫測試、做 review、部署），你負責目標設定和最終驗收。
這是 2026 年的前沿，也是真正開始改變軟件行業結構的階段。
Stripe 在 2026 年 3 月被報道：他們的"Minions"系統——一套自主 AI agent 網絡——每週自動生成併合並超過 1,300 個 pull request，全程接入 CI/CD 管道，無需開發者手動寫一行代碼。這不是 demo，這是生產環境。
LangChain 的博客把這個階段叫"Agentic Engineering"的終態：一羣 AI agent 像真實軟件團隊一樣運轉——有人寫代碼，有人 review，有人測試，有人部署，有人監控。
arxiv 上一篇 2026 年的論文（Agyn 系統）專門研究了 multi-agent 團隊架構：單 agent 的問題在於把異質職責壓在一個 agent 上；多 agent 引入角色分工、同行評審、結構化協作，這才是真正的軟件團隊自動化。
典型場景：一家初創公司的 CTO 在早晨 9 點給團隊的 AI 系統提交一個產品需求，傍晚 6 點拿到一個可以上線的功能，中間沒有一個人類工程師參與代碼層面的工作。這個場景在 2026 年已經開始出現在早期採用者身邊。
代表工具：Devin（Nubank 案例：8-12x 效率提升、企業採用量月增 40%，來源：digitalapplied. com · 待驗證）、OpenDevin（開源）、GitHub Copilot Agent Mode + Actions 編排、Claude Code + MCP 工具鏈編排、Anthropic Managed Agents（待驗證具體發佈時間線）。
SWE-bench Verified 基準：Claude Opus 4.5 已達 80.9%，意味着 top agent 能自主解決 GitHub 真實 issue 的能力已經超過 80%。
常見錯覺：以為這是"大公司才玩得起的東西"。
錯了。Stripe 的 Minions 架構是從小團隊實驗開始的。2026 年最大的機會，不是有多少資源，是誰最先把多 agent 流水線跑通。
升階判據：如果你現在連階段三都還沒穩定，不要急着跳階段四。階段四需要你先能清晰拆解任務（階段三的核心技能），才能設計出合理的 agent 角色分工。跳步會導致 multi-agent 系統的錯誤難以溯源。
行動公式：找一個可以拆成三條獨立任務線的項目（比如：前端 + API + 測試），分別用三個 Claude Code session 並行跑，最後手動合併 review。這是階段四的最小可行實踐。
05你站在哪裏
我自己，說實話，AI 編程這件事，已經在第四階段了。
能用 Claude Code 同時跑三條任務線，自己只做最後的合併 review。這套流程覆蓋了我 AI 編程場景的大約 75%。剩下 25% 是邊界情況——複雜 bug 定位、跨模塊重構、跟客戶對需求——這些還得我自己介入。
但寫到這裏我才意識到一件事，是我前面沒說清楚的——。
階段不是"你這個人"的位置。是"你每個具體業務環節"的位置。
我 AI 編程到了第四階段。但 OPC 的其他場景——客戶服務、內容營銷、產品交付、社羣運營——我大部分還在階段二、階段三。
很多人卡在一個錯覺裏——以為搞懂了 AI 編程，就是搞懂了 AI。
這是兩件事。
階段四不是"你在所有場景都到階段四"。是"你在某個場景到了階段四"。這個區分，我自己想清楚也用了一年。
更深一層我沒想清楚的是——任務結構設計的能力，是一種可以跨場景遷移的通用技能，還是每個垂直場景都要重新建立一次的領域直覺？
如果是後者，那意味着：你在 AI 編程到了階段四，不會自動讓你在客戶服務到階段四。每個場景都得從頭爬一遍階梯。
AI 降低了某些場景的門檻。但它在每個場景裏都重新畫了一條階梯。
你自己在哪些場景裏、哪些階段上？
更重要的是：這四個階段，是能力台階，還是思維框架？
你以為自己在哪個場景的哪個階段，和你實際在的之間的差——才是你今年真正要補的那門課。
周知 · 我們一起和 AI 覺醒超級個體