從失敗中重生：前端人工智慧代理落地案例的真實回顧 今天在FEDay大會上，我分享了一個關於實現前端代理的案例研究。核心內容並非慶祝勝利，而是講述一個團隊如何從“技術成功”走向“產品失敗”，以及這次失敗如何促使我們對認知框架進行關鍵性升級。 這個故事的價值不在於成功的方法論，而是我們所遇到的陷阱以及我們思維的演進。
2025年被譽為「智能體之年」。隨著Deep Research、Manus和Claude Code的發布，科技界一片沸騰。 許多團隊都在問同一個問題：“我們應該建立一個代理嗎？”
在深入探討之前，讓我先先明確一下我對人工智慧代理的定義： > AI 代理：一個大型語言模型 (LLM)，它會循環呼叫工具以實現特定目標。 - 循環中的工具：模型呼叫工具 -> 取得結果 -> 繼續推理。 - 明確終點：它的目的是實現一個目標，而不是無限循環。 - 靈活的目標來源：目標可以來自使用者或其他LLM。 - 基本記憶：透過對話歷史記錄保持上下文。
挑戰：私有設計系統 朋友的團隊正面臨一個企業級的難題：公司擁有一套完整的內部設計系統和一個私有的前端框架。然而，由於這些代碼是私有的，因此從未有公開的AI模型基於這些代碼進行訓練。通用模型根本無法產生符合其內部規範的程式碼。 目標很明確：打造一款類似「Lovable」的工具，但採用他們自己的設計系統。使用者可以上傳 Figma 設計稿或螢幕截圖，代理程式會自動產生符合內部標準的前端程式碼。 聽起來很完美，對吧？
現實檢驗：挑戰是巨大的： 1. 建立一個完整的代理系統比看起來要困難得多（使用者互動、情境工程等）。 2. 該模型必須理解並使用它從未見過的私有組件。 3. 我們需要即時瀏覽器預覽產生的程式碼。 4. 如果程式碼故障，我們需要自動修復功能。
技術上的成功：我們是如何實現的 身為技術顧問，我給的第一個建議非常務實：「先讓它運作起來，再進行最佳化。」建立代理程式並不是最難的部分；完成整個執行循環才是。
1. 基礎：Claude Agent SDK 我們沒有重新發明輪子，而是基於 Claude Agent SDK 進行開發。 - 已證實：克勞德·科德證明了這種架構是可行的。 - 即用型：內建工具涵蓋 90% 的場景。 - 可擴展：支援自訂工具、MCP（模型上下文協定）和自訂技能。 （您可以在這裡找到一些開源的原型程式碼：https://t.co/eon1eb3ECD）
2. 預覽方案：本機檔案系統 我們最初嘗試使用 Sandpack（基於瀏覽器的沙箱）進行程式碼預覽，但它在處理複雜的私人元件時表現不佳。轉折點：我們為代理程式提供了一個本機檔案系統（每個會話一個虛擬機器或目錄）。這使得代理程式可以自由地讀取、寫入、修改和編譯程式碼。
為代理程式提供本機檔案系統是最大限度發揮其功能的唯一途徑。
3. 解決「未知組件」問題 如何教導人工智慧使用它從未見過的元件庫？ 像對待新員工一樣對待它。我們將設計系統規格、元件清單和 API 文件轉換成了 Markdown 格式。 無需複雜的 RAG：我們只需允許代理程式對本機文件和「高品質參考程式碼」執行文件檢索即可。
4. 品質保證：驗證循環 為了確保程式碼真正有效，我們建立了一個自動化循環：產生 -> 驗證 -> 修復 - 工具：靜態程式碼檢查、編譯檢查和視覺化差異比較（使用 Chrome DevTool MCP）。 - 最佳化：我們將驗證工具放置在 Skill 或 SubAgent 中，以避免污染主 Agent 的上下文視窗。
「產品失敗」：上市後的沉默 系統運作正常。演示效果驚艷。我們正式上線後……幾乎沒人使用。 最初的新鮮感過後，用戶流失率飆升。我們進行了深入的分析和使用者訪談，意識到問題不在於技術，而是產品邏輯與使用者習慣的不一致。
它失敗的原因 1. 習慣阻力：設計師和專案經理習慣使用 Figma，而不是聊天視窗。從舒適圈過渡到對話式介面是一個巨大的阻力點。大多數人甚至不知道該輸入什麼。 2. 80/20 瓶頸：代理程式完美地完成了 80% 的工作。但剩下的 20% 需要手動修改，這極其耗費精力。通常，這 20% 的工作決定了程式碼是否可用。 3. 工作流程片段化：生成環境與實際開發環境脫節。開發人員必須手動複製貼上程式碼，使過程變得繁瑣。
認知升級：重新定義問題 我們意識到我們問錯了問題：「我們如何建立一個設計系統人工智慧代理？」這使得代理本身成為了目標，而不是手段。 正確的問題是：“我們的設計系統的最終目的是什麼？” 1. 全企業統一的設計規範。 2. 提高了開發效率。
轉變一：為人工智慧設計，而非為人類設計 目前的工作流程以人為中心：人工溝通、迭代修改、人工確認。未來的工作流程必須以人工智慧為中心：輸入 -> 人工智慧代理 -> 輸出。 新的設計原則： - 對人工智慧友善：選擇法學碩士容易理解的技術堆疊。 - 輕量級：僅保留設計令牌。基於對人工智慧友善的開源系統（如 shadcn/ui）進行擴展，而不是維護龐大的私有函式庫。
第二階段：從“代理人”到“技能人員” 最關鍵的轉變是放棄了「獨立代理平台」。 舊模型（孤島）：與開發者隔離的獨立代理，造成摩擦。 新模型（整合）：將設計系統變成可以嵌入現有 AI 開發環境（如 Cursor 或 Claude Code）中的技能。
什麼是技能？ 它其實就是 Markdown 文件（供 AI 閱讀）+ 自動化腳本（用於初始化專案和安裝系統）。 現在，開發人員在他們熟悉的環境中工作。當他們需要設計系統時，通用代理會呼叫這個“技能”，生成的程式碼會直接進入專案程式碼庫。 （參考方法：anthropics/skills/tree/main/skills/web-artifacts-builder）
深度洞察：4 個關鍵要點 技術成功 ≠ 產品成功 很多工程師（包括我自己）都會陷入「只要能用就成功」的迷思。使用者並不關心你的技術棧；他們只關心你的技術能否解決他們的問題，並且不會打斷他們的工作流程。 2. 設計「以人工智慧為中心」的工作流程 我們常說“以用戶為中心”，但我們必須加上一個層面：“以人工智慧為中心”。不要讓人工智慧模仿人類的工作流程，而是重新設計工作流程，讓人工智慧能夠以最高效率運行，然後讓人類享受成果。 3. 技能 > 代理人 獨立代理平檯面臨很高的普及門檻。將功能封裝成可連接現有生態系統的技能，是更務實的途徑。 4. 行動 儘管最初的產品「失敗」了，但認知上的提升卻是無價的。不親身實踐，就無法學會從「人類工作流程」過渡到「人工智慧工作流程」。
動手建造吧！ 失敗是可以接受的。它遠勝於什麼都不做。
