一個生成、一個評審，讓兩個 AI 互相對抗才能做出好東西（翻譯文）

原文作者：Prithvi Rajasekaran，Anthropic Labs 團隊成員。
原文連結：https://www.anthropic.com/engineering/harness-design-long-running-apps

【關於這篇文章】

你叫 AI 「自我評估」，它幾乎永遠說「很棒」，就算做出來的東西普通到不行。這是 AI 工程實作上的常見痛點，Anthropic 工程師 Prithvi Rajasekaran 花了幾個月研究這個問題，然後借用深度學習的 GAN（生成對抗網路）概念想出了解法：把「做事的 AI」和「評審的 AI」拆開，讓評審者專門挑毛病，做事者根據回饋迭代，形成有效的品質迴圈。

實際效果是：用一行提示詞就能讓 AI 自主開發功能完整的全端應用程式，從復古遊戲編輯器到瀏覽器版音樂製作軟體都有。這篇文章記錄了框架演進的完整過程、真實的執行數據和花費，以及隨著模型能力提升，什麼部分可以拿掉、什麼部分仍然關鍵。

為什麼值得讀： 這是 Anthropic 內部第一手資料，講的不是概念，是真實跑過的數字和教訓。對任何在用 Claude API 或 Agent SDK 打造應用程式的工程師來說，是目前市面上把代理框架設計原則寫得最具體的文章之一。

過去幾個月，我一直在研究兩個相互關聯的問題：如何讓 Claude 產出高品質的前端設計，以及如何讓它在無需人工介入的情況下完整開發應用程式。這項工作源於我們早期在前端設計技能和長時間執行代理框架上的探索，我和同事透過提示工程與框架設計，將 Claude 的表現大幅提升到超越基準線，但兩個方向最終都撞上了天花板。

為了突破，我開始尋找能橫跨兩個截然不同領域的新 AI 工程方法：一個由主觀品味主導，另一個則需要可驗證的正確性與可用性。受到生成對抗網路（GAN）的啟發，我設計了一個多代理結構，包含一個生成器和一個評估器。建立一個能穩定評分、且具備品味判斷的評估器，首先意味著要發展出一套評估標準，能把「這個設計好嗎？」這類主觀判斷轉化為具體可評分的條件。

我接著把這些技術應用到長時間自主寫程式上，並從早期框架工作帶來了兩個核心教訓：把開發任務分解成可處理的小塊，以及使用結構化的工件在不同工作階段之間傳遞上下文。最終成果是一個三代理架構（規劃器、生成器和評估器），能在多小時的自主寫程式過程中，持續產出功能豐富的全端應用程式。

為什麼直觀做法行不通

我們先前已說明框架設計對長時間代理寫程式的效果有重大影響。在早期的實驗中，我們使用一個初始化代理把產品規格分解為任務清單，然後一個寫程式代理逐功能實作、並在交接時傳遞工件以延續上下文。更廣泛的開發者社群也匯聚到類似的洞見，例如「Ralph Wiggum 方法」就使用 hooks 或腳本讓代理持續進入迭代循環。

但某些問題依然頑固存在，面對較複雜的任務時，代理仍然傾向於隨時間推移逐漸失控。在拆解這個問題的過程中，我們觀察到代理在執行此類任務時常見兩種失敗模式。

第一，隨著上下文視窗填滿，模型在冗長任務中傾向於喪失連貫性（詳見我們關於上下文工程的文章）。部分模型還會出現「上下文焦慮」：在它們認為即將達到上下文限制時，提前草草結束工作。上下文重置是完全清空上下文視窗、啟動一個全新代理，並透過結構化的交接文件傳遞前一代理的狀態與後續步驟，同時解決了這兩個問題。

這和對話壓縮的做法不同，壓縮是將對話的早期部分就地摘要，讓同一個代理在縮短的歷史記錄上繼續工作。壓縮雖然保留了連續性，卻無法給代理一張乾淨的工作白紙，意味著上下文焦慮仍可能存在。重置則提供了乾淨的白紙，代價是交接文件必須包含足夠的狀態讓下一個代理能接手。在我們早期的測試中，Claude Sonnet 4.5 的上下文焦慮嚴重到光靠對話壓縮不足以支撐強大的長任務表現，因此上下文重置成為框架設計的關鍵。這雖然解決了核心問題，但也為每次框架執行增加了協調複雜度、token 開銷和延遲。

第二個問題是自我評估，這是我們之前未曾處理過的。當被要求評估自己做出的工作時，代理往往以充滿自信的讚美來回應，即便在人類觀察者看來，品質明顯只是普通。這個問題在設計等主觀任務上尤為突出，因為沒有像軟體測試那樣的二元驗證標準可用。一個版面設計是否有質感，是一種判斷，而代理在評估自己的工作時，評分一貫地偏高。

然而即便在有可驗證結果的任務上，代理有時仍會表現出阻礙其完成任務的糟糕判斷力。把做事的代理和評判的代理分開，被證明是解決這個問題的強力槓桿。這種分離本身並不能立即消除評分寬鬆的問題，評估器仍然是一個傾向對 LLM 產出寬大為懷的 LLM。但把一個獨立的評估器調校成持懷疑態度，遠比讓生成器對自己的工作提出批評要容易得多。一旦外部回饋存在，生成器就有了具體的迭代依據。

前端設計：讓主觀品質可以量化評分

我從前端設計開始實驗，因為自我評估的問題在這裡最為明顯。在沒有任何干預的情況下，Claude 通常會傾向於安全、可預測的版面，技術上可用，但視覺上毫無特色。

塑造這個框架的核心洞見有兩個，第一，雖然美學無法完全化約為一個分數（個人品味永遠存在差異），但透過編入設計原則和偏好的評分標準，可以提升品質。「這個設計漂亮嗎？」很難一致回答，但「這是否符合我們的優秀設計原則？」給了 Claude 具體的評分依據。第二，將前端生成與前端評分分離，我們可以建立一個將生成器推向更強輸出的回饋迴圈。

基於此，我寫出了四個評分標準，分別給生成器和評估器代理的提示詞使用：

• 設計品質： 設計是否感覺是一個有機的整體，而不是零件的組合？強的作品意味著色彩、字型、版面、圖片等細節共同營造出獨特的情緒和識別感。
• 原創性： 是否有客製化決策的痕跡，還是充斥著模板版面、函式庫預設值和 AI 生成的慣用套路？優秀的人類設計師應能辨識出刻意的創意選擇。未修改的現成元件（或 AI 生成的典型特徵，如白色卡片上的紫色漸層）在此標準下失分。
• 工藝： 技術執行層面：字型層次、間距一致性、色彩和諧、對比比例。這是能力測驗而非創意測驗。大多數合理的實作預設就能通過；失敗意味著基礎功失誤。
• 功能性： 獨立於美學之外的可用性。使用者能否理解介面的用途、找到主要操作、不靠猜測就完成任務？

我強調設計品質和原創性，而非工藝和功能性。Claude 在工藝和功能性上的預設表現本就不錯，所需的技術能力對模型來說通常是自然而然的。但在設計和原創性上，Claude 的輸出往往充其量只是乏味。這些標準明確懲罰高度通用的「AI 味」套路，透過加重設計和原創性的比重，將模型推向更多的美學冒險。

我用帶有詳細評分分解的少樣本範例來校準評估器，確保評估器的判斷與我的偏好一致，並減少跨迭代的評分漂移。

我在 Claude Agent SDK 上建立了這個循環，保持了協調的簡潔性。生成器代理首先根據使用者提示建立一個 HTML/CSS/JS 前端。我給了評估器 Playwright MCP，讓它在評分前能直接與運行中的頁面互動。實際執行時，評估器會自主瀏覽頁面、截圖並仔細研究實作，再對每個標準評分並撰寫詳細評論。這些回饋作為下一輪迭代的輸入，流回給生成器。每次生成執行 5 到 15 輪迭代，隨著生成器回應評估器的批評，每輪通常都能將設計推向更具特色的方向。由於評估器是在主動瀏覽頁面而非對靜態截圖評分，每個循環都需要一定的實際時間，完整執行可長達四小時。我也指示生成器在每次評估後做出策略決定：如果分數走勢良好就精修當前方向，如果方法不奏效就轉向完全不同的美學風格。

跨多次執行，評估器的評估在迭代中持續改善，直到達到高原。有些生成是漸進式的改善，有些則在迭代間出現尖銳的美學轉向。

評分標準的措辭以我未完全預料到的方式引導了生成器。加入「最好的設計具有美術館級別的品質」這樣的措辭，將設計推向特定的視覺收斂，顯示與標準相關聯的提示語言直接塑造了輸出的特質。

雖然分數通常隨迭代改善，但並非總是呈現清晰的線性走勢。後期的實作整體上往往更好，但我經常看到自己更喜歡中間某輪迭代而非最後一輪的情況。實作複雜度也傾向於隨輪次增加，生成器在回應評估器回饋的過程中追求更有野心的解決方案。即便是第一輪迭代，輸出也明顯優於完全沒有提示的基準線，顯示評分標準和相關語言本身就在把模型推離通用預設，甚至在任何評估器回饋觸發進一步改善之前就已如此。

在一個值得一提的例子中，我提示模型建立一個荷蘭藝術博物館的網站。到第九輪，它產出了一個乾淨的深色主題登陸頁，視覺精緻，但大致符合我的預期。到了第十輪，它完全捨棄了這個方向，把網站重新構思為一種空間體驗：用 CSS 透視法渲染的 3D 房間，格紋地板，藝術品自由懸掛在牆上，以門道而非捲動或點擊在展廳之間導覽。這是我從未在單次生成中見過的創意飛躍。

擴展到全端寫程式

有了這些發現，我將受 GAN 啟發的模式應用到全端開發上。生成器-評估器迴圈自然對應到軟體開發週期，程式碼審查和品質保證（QA）在其中扮演著與設計評估器相同的結構性角色。

架構設計

在我們早期的長時間執行框架中，我們已透過初始化代理、逐功能作業的寫程式代理，以及工作階段間的上下文重置，解決了跨工作階段的連貫寫程式問題。上下文重置是關鍵突破：框架使用的是 Sonnet 4.5，這個版本如前所述會出現「上下文焦慮」。建立一個能在上下文重置中良好運作的框架，是讓模型保持專注的核心。Opus 4.5 本身就基本消除了這個行為，因此我得以從這個框架中完全捨棄上下文重置。代理在整個開發過程中作為一個持續的工作階段執行，上下文增長由 Claude Agent SDK 的自動壓縮功能處理。

在這項工作中，我在原始框架的基礎上建立了三代理系統，每個代理針對我在先前執行中觀察到的特定缺口：

規劃器： 我們先前的長時間執行框架要求使用者預先提供詳細規格。我想自動化這個步驟，因此建立了一個規劃器代理，它接受 1-4 句的簡短提示，並將其擴展為完整的產品規格。我提示它在範疇上要有野心，並專注於產品脈絡和高層次技術設計，而非詳細的技術實作。這樣做的原因是，如果規劃器試圖預先指定細粒度的技術細節並出錯，規格中的錯誤將會向下游的實作傳遞。讓代理受制於要交付的成果，讓它們在工作過程中自行想辦法，似乎是更聰明的做法。我也要求規劃器尋找在產品規格中融入 AI 功能的機會。（附錄中有範例。）

生成器： 早期框架中的逐功能作業方式在範疇管理上效果很好，我在此採用了類似的模型，指示生成器以 Sprint 為單位工作，每次從規格中選取一個功能。每個 Sprint 使用 React、Vite、FastAPI 和 SQLite（後來升級為 PostgreSQL）的技術棧實作應用程式，生成器被指示在每個 Sprint 結束時自我評估工作，再交接給 QA。它也擁有 git 作為版本控制工具。

評估器： 早期框架的應用程式外觀往往令人印象深刻，但在真正試用時仍存在真實的程式錯誤。為了找出這些問題，評估器使用 Playwright MCP，像真實使用者一樣點擊運行中的應用程式，測試 UI 功能、API 端點和資料庫狀態。它接著根據發現的程式錯誤，以及一套仿照前端設計實驗、調整以涵蓋產品深度、功能性、視覺設計和程式碼品質的標準，對每個 Sprint 評分。每個標準都有一個硬性門檻，任何一項低於門檻，該 Sprint 即告失敗，生成器會收到問題所在的詳細回饋。

在每個 Sprint 前，生成器和評估器會協商一份 Sprint 合約：在任何程式碼被撰寫之前，先就這塊工作的「完成」樣貌達成共識。這樣做是因為產品規格刻意保持高層次，我希望有一個步驟來彌合使用者故事和可測試實作之間的差距。生成器提出它將建構的內容以及如何驗證成功，評估器審查該提案以確保生成器在做正確的事，兩者反覆迭代直到達成共識。

溝通透過檔案進行：一個代理撰寫一個檔案，另一個代理讀取並在同一個檔案中回應，或寫一個新檔案讓前一個代理讀取。生成器接著根據商定的合約進行開發，再交接給 QA。這讓工作忠實於規格，同時不會過早過度指定實作細節。

執行框架

在第一個版本的框架中，我使用 Claude Opus 4.5，將使用者提示同時在完整框架和單代理系統上執行以作比較。我選用 Opus 4.5 是因為在我開始這些實驗時，它是我們最好的寫程式模型。

我寫了以下提示來生成一個復古電玩遊戲製作工具：

建立一個 2D 復古遊戲製作工具，功能包含關卡編輯器、角色編輯器、實體行為和可玩的測試模式。

框架的費用超過 20 倍，但輸出品質的差異立竿見影。

我預期的是一個介面，讓我可以建構關卡及其組成元素（精靈圖、實體、圖格版面），然後按下播放真正玩關卡。我先打開單一代理的輸出，初始應用程式看起來符合這個預期。

但隨著我點擊瀏覽，問題開始浮現。版面浪費空間，固定高度的面板讓視窗大半空著。工作流程也很死板。試圖在關卡中放入元素時，系統提示我先建立精靈圖和實體，但介面中沒有任何引導提示我依循這個順序。更關鍵的是，遊戲本身壞了。我的實體出現在畫面上，但什麼都沒有回應輸入。深挖程式碼才發現，實體定義和遊戲執行環境之間的連結斷了，而表面上完全看不出問題所在。

評估完單一代理執行後，我把注意力轉向框架版本，這次執行同樣從那句提示出發，但規劃步驟把這個提示擴展成分布在十個 Sprint 中的 16 項功能規格，遠超單一代理的嘗試範疇。除了核心的編輯器和遊玩模式，規格還涵蓋了角色動畫系統、行為模板、音效和音樂、AI 輔助的精靈圖生成器和關卡設計師，以及附帶可分享連結的遊戲匯出功能。我讓規劃器存取我們的前端設計技能，它讀取後為應用程式建立了視覺設計語言，並將其納入規格。對每個 Sprint，生成器和評估器協商了一份合約，定義該塊工作的具體實作細節，以及用於驗證完成度的可測試行為。

應用程式立刻展現出比單一代理執行更高的精緻度和流暢感。畫布佔滿了整個視窗，面板大小設定合理，介面具有一致的視覺識別感，與規格中的設計方向一致。我在單一代理執行中看到的部分笨拙之處確實還在，工作流程仍然沒有清楚提示你應該先建立精靈圖和實體再填充關卡，我得自己摸索，這讀起來更像是基礎模型產品直覺的缺口，而非框架設計要解決的問題，但也確實指出了一個可以透過框架內的針對性迭代進一步改善輸出品質的地方。

瀏覽各個編輯器時，新版本相對於單一代理的優勢越來越明顯。精靈圖編輯器更豐富、功能更完整，工具面板更乾淨，色彩選取器更好，縮放控制更易用。

由於我要求規劃器在規格中融入 AI 功能，這個應用程式還內建了 Claude 整合，讓我可以透過提示語言生成遊戲的不同部分，大幅加快了工作流程。

最大的差異出現在遊玩模式，我真的能移動實體並玩遊戲了。物理引擎有些粗糙，我的角色跳上平台後與其發生了重疊，感覺直覺上不對，但核心功能是運作的，這是單一代理執行未能做到的。移動一陣子後，我確實遇到了 AI 關卡建構的一些限制，有一面大牆讓我無法跳過去，卡住了我。這顯示還有一些常識改進和邊緣案例是框架可以處理的，以進一步精煉應用程式。

閱讀執行日誌，可以清楚看到評估器讓實作與規格保持一致。每個 Sprint，它都會逐一核對 Sprint 合約的測試標準，並透過 Playwright 操作運行中的應用程式，對任何與預期行為不符之處提出錯誤報告。這些合約很細緻，光是 Sprint 3 就有 27 個涵蓋關卡編輯器的標準——而且評估器的發現具體到無需額外調查就能直接採取行動。下表列出了評估器識別出的幾個問題範例：

讓評估器達到這個水準，需要真正下功夫，開箱即用的 Claude 是一個糟糕的 QA 代理。在早期執行中，我看著它識別出合理的問題，然後說服自己這些問題其實不嚴重，就批准了工作。它也傾向於進行表面測試，而非深入探測邊緣案例，因此更細微的錯誤往往得以矇混過關。調優的循環是：閱讀評估器的日誌，找出其判斷與我的判斷出現偏差的例子，然後更新 QA 的提示詞來解決這些問題。這個開發循環經過幾輪之後，評估器的評分才達到我認為合理的程度。即便如此，框架輸出仍顯示了模型 QA 能力的極限：細小的版面問題、部分地方感覺反直覺的互動，以及評估器未充分測試到的更深層巢狀功能中未被發現的錯誤。顯然還有更多驗證能力的提升空間。但與核心功能根本不運作的單一代理執行相比，提升已經顯而易見。

迭代優化框架

第一輪框架結果令人鼓舞，但它也很龐大、緩慢且昂貴。合理的下一步是在不降低性能的前提下簡化框架。這部分是常識，部分是一個更普遍原則的體現：框架中的每個元件都編碼了一個關於模型自身無法做到什麼的假設，這些假設值得壓力測試，既因為它們可能是錯的，也因為隨著模型改善，它們可能迅速變得過時。我們的部落格文章《建立有效的代理》把這個底層理念表述為「找到最簡單可行的解法，只在必要時才增加複雜度」，這是任何維護代理框架的人都會反覆遭遇的模式。

在我的第一次簡化嘗試中，我大刀闊斧地削減框架並嘗試了幾個創意新方向，但無法複製原版的性能。同時也變得難以判斷框架設計的哪些部分實際上是關鍵的，以及在什麼程度上關鍵。基於這段經歷，我轉向了更有系統性的方法：每次只移除一個元件，觀察它對最終結果的影響。

在這些迭代循環中，我們也發布了 Opus 4.6，進一步提供了降低框架複雜度的動力。有充分理由預期 4.6 比 4.5 需要更少的鷹架。從我們的發布部落格：「[Opus 4.6] 計畫更周全，能持續執行更長時間的代理任務，可在更大的程式碼庫中更可靠地運作，並有更好的程式碼審查和除錯技能來發現自己的錯誤。」它在長上下文檢索上也大幅改善。這些都是框架被建立來補充的能力。

移除 Sprint 架構

我從完全移除 Sprint 架構開始實驗，這個結構原本是為了把工作分解成塊，讓模型能連貫地作業。鑑於 Opus 4.6 的改善，有充分理由相信模型可以在沒有這種分解的情況下原生處理任務。

我保留了規劃器和評估器，因為兩者都繼續提供明顯的價值。沒有規劃器，生成器的規模就不足：給定原始提示，它會在沒有先規格化工作的情況下直接開始開發，最終建出功能比規劃器版本貧乏的應用程式。

移除 Sprint 架構後，我把評估器改為在整個執行結束時進行單次評估，而非按 Sprint 評分。由於模型能力大幅提升，它改變了評估器在某些執行中的重要程度，其效用取決於任務相對於模型自身可靠能力的位置。在 4.5 上，這個邊界很近：我們的開發任務處於生成器單獨作業表現良好的臨界點，評估器在整個開發過程中都能捕捉到有意義的問題。在 4.6 上，模型的原始能力增強了，邊界向外移動。以前需要評估器檢查才能連貫實作的任務，現在往往在生成器自己就能處理好的範圍內，對於這個範圍內的任務，評估器成了不必要的開銷。但對於仍然處於生成器能力邊緣的那部分開發任務，評估器繼續提供實質提升。

實際的含義是：評估器從來不是一個固定的是/否決策，當任務超出當前模型能可靠地單獨完成的範圍時，評估器才值得付出代價。

在結構簡化的同時，我也加入了提示，改善框架在每個應用程式中構建 AI 功能的方式，具體來說，是讓生成器建立一個能透過工具驅動應用程式自身功能的正式代理。這需要真正的迭代，因為相關知識足夠新，Claude 的訓練資料對其涵蓋很薄。但經過足夠的調優，生成器已能正確地建立代理。

更新後框架的成果

為了測試更新後的框架，我使用以下提示生成一個數位音訊工作站（DAW，一個用於創作、錄音和混音歌曲的音樂製作程式）：

使用 Web Audio API 在瀏覽器中建立一個功能完整的 DAW。

執行仍然耗時且昂貴，約 4 小時，token 費用約 $124 美元。

大部分時間耗在開發生成器上，它在沒有 Opus 4.5 所需的 Sprint 分解的情況下，連貫地執行了超過兩小時。

和之前的框架一樣，規劃器把一行提示擴展成了完整規格。從日誌可以看出，生成器模型在規劃應用程式和代理設計、接通代理，以及在交接給 QA 前測試方面，表現良好。

儘管如此，QA 代理仍然捕捉到了真實的缺口。在第一輪回饋中，它注意到：

這是一個強大的應用程式，具有出色的設計還原度、紮實的 AI 代理和良好的後端。主要的失敗點在功能完整性，雖然應用程式看起來令人印象深刻，AI 整合也運作良好，但幾個核心 DAW 功能只有顯示而缺乏互動深度：片段無法在時間軸上拖曳/移動，沒有樂器 UI 面板（合成器旋鈕、鼓墊），也沒有視覺化效果編輯器（EQ 曲線、壓縮器電表）。這些不是邊緣案例，而是讓 DAW 得以使用的核心互動，規格也明確要求了這些功能。

在第二輪回饋中，它再次捕捉到幾個功能缺口：

剩餘缺口：

• 音訊錄音仍然只是存根（按鈕切換但沒有麥克風捕捉）
• 片段邊緣拖曳調整大小和片段分割未實作
• 效果視覺化是數字滑桿，不是圖形化的（沒有 EQ 曲線）

生成器放任自行時，仍然傾向於遺漏細節或做出功能存根，而 QA 在捕捉這些最後一哩路問題供生成器修正上，仍然提供了價值。

根據提示，我預期的是一個能讓我創作旋律、和聲和鼓點組合成歌曲，並在整合代理的協助下完成創作的程式。

這個應用程式距離專業音樂製作軟體還很遠，代理的作曲技能也明顯還有很大的進步空間。此外，Claude 實際上無法聽見聲音，這讓 QA 回饋循環在音樂品味方面的效果大打折扣。

但最終的應用程式具備了功能性音樂製作程式的所有核心要素：在瀏覽器中運行的可用編排視圖、混音器和傳輸。除此之外，我能夠完全透過提示組合出一小段歌曲：代理設定了節拍和調性，鋪下了旋律、建立了鼓點節奏、調整了混音器音量，並加上了殘響。歌曲創作的核心基元已經到位，代理可以自主地使用工具，從頭到尾製作出一個簡單的成品。或許還不算完美無瑕，但正在往那個方向前進。

接下來

隨著模型持續改善，我們大致可以預期它們能夠工作更長時間、處理更複雜的任務。在某些情況下，這意味著圍繞模型的鷹架隨時間變得不那麼重要，開發者可以等待下一個模型，看到某些問題自然解決。另一方面，模型越好，就越有空間開發出能實現超越基準線的複雜任務的框架。

基於此，這項工作帶來幾個值得銘記的教訓，在正在開發的模型上做實驗、閱讀它在現實問題上的執行追蹤，並調優其性能以達到預期結果，始終是好的做法。在面對更複雜的任務時，分解任務並對每個方面應用專門代理，有時能帶來提升空間。當新模型發布時，重新審視框架通常是好的做法，去掉那些對性能不再起關鍵作用的部分，加入那些以前可能無法實現的新能力。

從這項工作中，我的信念是：隨著模型改善，有趣的框架組合空間不會縮小，而是移動了位置。對 AI 工程師而言，有意義的工作在於不斷找到下一個新穎的組合。

致謝

特別感謝 Mike Krieger、Michael Agaby、Justin Young、Jeremy Hadfield、David Hershey、Julius Tarng、Xiaoyi Zhang、Barry Zhang、Orowa Sidker、Michael Tingley、Ibrahim Madha、Martina Long 和 Canyon Robbins 對這項工作的貢獻。

也感謝 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 在撰寫本文過程中的協助。

附錄

以下是規劃器代理生成的完整計畫範例，展示如何從一句話擴展出完整的產品規格。

RetroForge - 2D 復古遊戲製作工具

概覽
RetroForge 是一個基於網路的創作工作室，專為設計和建構 2D 復古風格電玩遊戲而設計。它將經典 8 位元和 16 位元遊戲美學的懷舊魅力，與現代直觀的編輯工具結合，讓從業餘愛好者到獨立開發者的任何人，都能在不撰寫傳統程式碼的情況下，將遊戲構想付諸實現。

平台提供四個整合式創作模組：基於圖格的關卡編輯器（用於設計遊戲世界）、像素藝術精靈圖編輯器（用於打造視覺素材）、視覺化實體行為系統（用於定義遊戲邏輯），以及即時可玩測試模式（用於實時遊戲測試）。透過在整個流程中融入 AI 輔助（由 Claude 驅動），RetroForge 加速了創作過程，幫助使用者透過自然語言互動生成精靈圖、設計關卡和配置行為。

RetroForge 的目標使用者是喜愛復古遊戲美學但希望擁有現代便利性的創作者。無論是重現童年的平台跳躍遊戲、角色扮演遊戲或動作遊戲，還是在復古限制中創造全新體驗，使用者都可以快速原型設計、視覺化迭代，並與他人分享創作成果。

功能
1. 專案儀表板與管理
專案儀表板是 RetroForge 中所有創作工作的主基地。使用者需要一個清晰、有組織的方式來管理他們的遊戲專案，包含建立新專案、回到進行中的作品，以及一眼了解每個專案的內容。

使用者故事：作為一名使用者，我希望能夠：

- 建立帶有名稱和描述的新遊戲專案，以便開始設計我的遊戲
- 看到所有現有專案以視覺卡片形式呈現，顯示專案名稱、最後修改日期和縮圖預覽，以便快速找到並繼續我的工作
- 打開任何專案進入完整的遊戲編輯器工作區，以便處理我的遊戲
- 刪除不再需要的專案（附確認對話框防止誤操作），以便保持工作區整潔
- 複製現有專案作為新遊戲的起點，以便重用我的既有工作成果

專案資料模型：每個專案包含：

專案元數據（名稱、描述、建立/修改時間戳）
畫布設定（解析度：如 256x224、320x240 或 160x144）
圖格尺寸配置（8x8、16x16 或 32x32 像素）
色彩調色盤選擇
所有相關的精靈圖、圖格集、關卡和實體定義

...