代碼智能體進化：從寫單文件到搭完整系統

凌晨兩點，一個Python智能體正在自動創建文件夾結構、寫領域模型、搭數據庫層、跑單元測試——全部自己完成，人類只在開頭給了段自然語言描述。

這不是科幻。Anthropic最新實驗把"代碼生成"推進到了"系統生成"：一個智能體，輸出的是完整的多文件項目，帶分層架構、帶測試、能直接運行。

從"寫代碼"到"搭系統"的跨越

之前的智能體實驗已經證明：生成代碼、運行、觀察報錯、迭代修復，這條路在單文件場景下跑得通。Python、Go、TypeScript都驗證過。

但真實工程不是單文件。

真實系統=結構+邊界+契約+代碼。四層抽象，缺一不可。這次實驗直接挑戰：智能體能不能生成完整的代碼倉庫，而不只是代碼片段？

實驗目標很明確：用Clean Architecture（整潔架構）做一個筆記應用，Python多文件項目，帶pytest單元測試驗證。

最終生成的目錄結構長這樣：

project_agent_coded_python_clean_arch/

domain/

models.py ← 領域模型，純業務邏輯

application/

services.py ← 應用服務，編排用例

infrastructure/

db.py ← 數據庫實現，技術細節

api/

main.py ← 接口層，FastAPI入口

tests/

test_notes.py ← 單元測試

四層邊界清晰，依賴方向向內指向領域層。這是教科書級的架構，現在由智能體自動生成。

智能體的五步閉環

這次的核心升級是工作流：生成→運行→驗證→測試→修復。

執行命令只有一行：python agent_coder_python_clean_arch.py

智能體接手后自動完成：

第一步，生成多文件項目。不是逐段請求，而是一次性輸出JSON對象，鍵是文件路徑，值是文件內容。原子化寫入，避免中間狀態混亂。

第二步，啟動服務。cd進目錄，python api/main.py，驗證能跑起來。

第三步，運行測試。pytest執行，拿到具體失敗信息。

第四步，根據報錯迭代修復。失敗→分析→重寫→再測，直到全綠。

生成的測試代碼長這樣：

from fastapi.testclient import TestClient

from api.main import app

client = TestClient(app)

def test_create_note():

response = client.post("/notes", json={"content": "test"})

assert response.status_code in (200, 201)

data = response.json()

assert "id" in data

assert data["content"] == "test"

def test_get_notes():

response = client.get("/notes")

assert response.status_code == 200

assert isinstance(response.json(), list)

POST和GET兩個接口，狀態碼斷言、返回結構校驗、數據類型檢查，覆蓋完整。

關鍵配置：給智能體的"任務書"

實驗代碼里有一段GOAL常量，值得逐行拆解——這就是人類工程師的輸入，其余全是智能體輸出：

目標：Clean Architecture筆記REST API，Python實現

結構：domain/models.py、application/services.py、infrastructure/db.py、api/main.py、tests/test_notes.py

技術棧：FastAPI框架、SQLite數據庫

功能：POST /notes創建筆記、GET /notes獲取列表

交付標準：包含pytest測試、python api/main.py可直接運行

注意約束的精確性。沒有說"用數據庫"，而是指定SQLite；沒有說"寫測試"，而是指定pytest；沒有說"分層架構"，而是給出具體文件路徑。模糊需求是智能體的噩夢，精確契約是它的燃料。

generate_repo函數的核心設計：強制返回JSON格式，文件路徑映射到內容。這解決了多文件項目的關鍵難題——一致性。如果逐文件生成，上下文可能漂移；一次性JSON輸出，架構完整性在生成瞬間就被鎖定。

為什么這事值得工程師警惕

變化很清晰：從"代碼生成"到"驗證過的系統構建"。

之前的AI編程助手，賣點是補全、是續寫、是幫你少敲鍵盤。這次的實驗指向另一個方向：架構決策自動化、項目初始化自動化、測試驗證自動化。

三層影響值得細想：

對初級工程師，入門門檻在降低，但"看懂架構"的能力反而更重要。智能體能生成Clean Architecture，但你能不能判斷它生成的對不對？能不能在出錯時定位是哪層邊界 violated？

對技術負責人，代碼審查的對象變了。以前審的是diff，現在可能要審的是智能體的GOAL描述——需求寫得夠不夠嚴謹，約束夠不夠完整，直接決定輸出質量。

對工具鏈廠商，IDE的戰場正在轉移。不是誰家的補全更準，而是誰能把"生成→運行→測試→修復"的閉環做得更穩。這要求深度集成執行環境，而不只是編輯器插件。

實驗代碼里有個細節：WORKDIR = "project_agent_coded_python_clean_arch"，os.makedirs(WORKDIR, exist_ok=True)。智能體自己管理文件系統，自己創建沙盒。這意味著它可以并行跑多個實驗、可以回滾、可以對比不同架構方案的輸出。工程化的空間打開了。

還有個隱藏信號：測試驅動。不是生成完代碼再補測試，而是測試作為驗證環節硬編碼進工作流。pytest失敗會觸發修復循環，這接近真正的測試驅動開發（TDD）自動化。

Clean Architecture被選為實驗目標不是偶然。它的價值在于邊界清晰——領域層不依賴任何外層，測試可以繞過基礎設施直接測核心業務。這種架構對智能體友好，因為每層職責單一，出錯時定位范圍小。反過來，智能體生成這種架構也更容易保證正確性。

但硬幣的另一面：復雜架構的涌現行為怎么驗證？這個筆記應用只有POST和GET，如果擴展到權限、緩存、事件溯源，智能體還能不能保持分層純凈？實驗沒回答，但這是下一個關口。

實用判斷：現在能用來做什么

這個實驗不是產品，是信號。它驗證的技術路徑，短期內有三處落地場景：

第一，項目腳手架升級。不是生成個模板就結束，而是根據你的技術選型（FastAPI還是Django、SQLAlchemy還是Peewee），生成帶完整測試的初始結構，且保證能跑通。

第二，遺留系統重構的探路工具。把舊代碼的描述喂給智能體，看它生成的Clean Architecture版本長什么樣，對比差距，輔助決策重構范圍。

第三，學習架構的交互式教材。改一改GOAL里的約束，觀察輸出怎么變——"去掉infrastructure層會怎樣？""把SQLite換成PostgreSQL需要改哪些文件？"實時反饋比看書高效。

長期看，這個方向指向"可驗證的生成式工程"。代碼生成不是終點，生成后能自證正確才是。pytest通過只是最低門檻，類型檢查、靜態分析、安全掃描、性能基準，都可能被編進驗證流水線。

工程師的核心競爭力，正在從"寫代碼的速度"轉向"定義問題的精度"和"驗證策略的設計"。智能體負責生成，你負責確保生成的東西值得信任。