[FDE的模式探討-2] 一人FDE的能力邊界:AI能補到哪，補不到哪

上次想到一半的那個問題，我繼續往下推了：我一個人壓縮掉整支FDE小隊之後，Echo和Delta兩端分別能覆蓋到什麼程度？

這個問題的答案，取決於一個更具體的追問：AI工具鏈到底能把Delta端——搭系統、寫代碼、做對接——壓到多低？

2025年2月，前OpenAI創始成員Andrej Karpathy提出了一個概念叫「Vibe Coding」——用自然語言描述意圖，AI寫代碼，人負責審查和方向把控。這個概念在Claude 3.5發布後真正爆發，因為AI編程能力終於到了切實可用的門檻。

到底有多可用？GitHub做過一項受控實驗：使用Copilot的開發者，完成HTTP伺服器任務的速度比對照組快55.8%。多篇行業報告引用的效率提升區間是2到5倍。翻譯成人話就是：以前一個人幹一週的活，現在半天到兩天就能搞定。

這聽起來像是Delta端已經被壓扁了。如果AI能把寫代碼的效率提升到這個程度，那一個人靠AI工具鏈補位Delta端，似乎完全可行。我剛開始做的時候也是這麼想的。

但這裡有個陷阱。

IEEE TSE期刊上Yutian Tang等人發表的一項研究測試了AI在多種編程語言上的表現：成功率差異很大，取決於任務難度——但整體來看，AI寫出來的代碼，能跑不代表邏輯正確。它能跑，但它做的是不是你要它做的事，你得自己判斷。

我看到這些研究的時候，第一反應是：這不就是我每天踩的坑嗎？

有企業級研究說得更直接：AI工具確實提供了淨生產力提升，但這些好處並不總是所有用戶都能體驗到。他們的結論是——AI「轉移」而非「消除」開發者的工作負載。

這才是關鍵。AI不是把Delta端消滅了，而是把Delta端的工作從「寫代碼」轉移到了「判斷代碼」。我不用再一行行敲鍵盤了，但我得一行行讀AI寫出來的東西，判斷哪些能用、哪些是垃圾、哪些看起來對但跑起來會出問題。

這就引出了一個更深的問題：如果Delta端的工作從「寫」變成了「判斷」，那它跟Echo端有什麼區別？Delta和Echo是不是正在合併？

答案是：合併了一半。

2026年，Karpathy在Sequoia AI Ascent大會上命名了Vibe Coding的演進方向——Agentic Engineering。核心轉變是：將人從執行循環中抽離，AI Agent自主完成「寫代碼→運行→檢查→修正→繼續」的完整閉環。

翻譯成人話就是：以前我跟AI對話，每輪得花30秒到2分鐘審查AI的輸出，一個複雜功能可能要來回20到50輪——我是瓶頸，注意力卡在執行循環裡，沒法同時做別的事。現在，AI Agent可以自己跑完整個循環，我只需要定義目標、設定約束、最後審查結果。

這就是我補位Delta端的技術機制。以前FDE小隊裡有專人負責搭建系統、有專人負責接入工具、有專人負責測試——現在我一個人通過AI Agent就能讓這些角色自動運轉。Claude Code可以在終端裡自主運行相當長的時間，Cursor可以連接各種外部服務，Replit可以從零到一端到端搭建應用。相比Vibe Coding時代，功能交付時間顯著縮短。

但這裡有個容易被忽略的細節。

Agentic Engineering把人從執行循環中抽離了，但抽離出來的人要做什麼？答案是三件事：定義目標、設定約束、審查結果。這三件事，本質上都是Echo。

我告訴AI Agent「我要一個能根據會員標籤自動發送成效廣告的模組」——這是定義目標。我補上「要接Google Ads API、預算超支要報警、品牌調性不能跑偏」——這是設定約束。AI Agent跑完之後，我打開產出物，判斷這東西能不能用——這是審查結果。

Delta端的自動化程度越高，Echo端的權重就越大。因為AI跑得越快，我判斷的頻率就越高；AI能做的事越多，我選擇做什麼的責任就越重。

所以Delta和Echo沒有合併——它們是此消彼長。Delta端被AI壓縮得越扁，Echo端就越突出。寫代碼變便宜了，判斷什麼值得寫，反而更金貴。這句話我在第一篇說過，現在我看到了它的技術原因。

那麼，Echo端到底有哪些東西是AI補不了的？我把自己踩過的坑整理了一下，歸納成四條。

以前我寫需求文檔給工程團隊，工程師能讀懂我的模糊描述，自己補上缺漏。現在我寫規格說明給AI Agent，AI會精確地按我說的做——包括我沒說清楚的部分。我說「做一個會員標籤系統」，AI可能給我搭了一個功能齊全但完全不符合我業務流程的東西。我以為自己說清楚了，AI理解的是另一回事。這不是AI的問題，是我的規格說明沒到位。

很多用AI做產品的人，最大的痛點不在AI寫不出代碼，而在自己說不清楚要什麼。方向錯了，及時停止比硬改更重要。這條我交了不少學費才學會。

這四條，每一條都是我在實踐中碰過的牆。AI能幫我做選項，但做不了判斷。

這就是我面對的能力邊界：Delta端可以靠AI工具鏈補位，但補位之後，Delta端的工作並沒有消失，而是轉移到了Echo端——我從「寫代碼的人」變成了「判斷代碼的人」。AI不是替我幹活，是把我的活從手上的活變成了腦子裡的活。

這個判斷在學術研究裡已經看到了證據。但真正踩過這些坑的人知道，研究描述的只是輪廓。

我失了業，決定自己做CMO行銷工具。我用Cursor寫前端，用Claude Code跑後端邏輯，用MCP協議把各種AI工具串起來——程式碼管理、檔案讀寫、搜尋查詢，全部通過配置文件接上，不用自己寫整合代碼。以前需要三個人分別負責的「理解需求+搭建系統+接入工具」，現在我一個人通過配置就能讓AI Agent完成。

但我在實踐中踩的坑，全部出在Echo端。

需求描述不夠清晰，AI的執行就不對——我以為自己說清楚了，AI理解的是另一回事。同一個prompt，兩次執行出來的代碼可能完全不同，所以Git的版本管理重要性比傳統開發高出十倍。方向錯了的時候，硬改不如及時停止、開新窗口重來。AI變慢了、開始重複了，不是AI壞了，是我的需求約束沒給夠。

我做的每一個決策——選什麼框架、怎麼拆模組、UI布局怎麼描述、測試結果要不要接受——都是Echo端的判斷。AI幫我把這些判斷的執行成本壓到了最低，但判斷本身，一個也少不了。

這就是我的真實寫照：我不是少了一支團隊，我是把整支團隊的判斷力壓進了一個人的腦子裡。AI工具鏈是我的Delta小隊，但Echo只有我自己。

一個人能不能扛住這個轉移，取決於我的領域經驗有多深、我的判斷力有多準。這條邊界畫在哪裡，決定了我是真的一人FDE，還是只是用了AI的SOHO。