在Django項(xiàng)目里，"這個(gè)字段前端真的在用嗎"是個(gè)讓人頭疼的問題。你得查后端、翻React代碼、再問可能知情的人。答案永遠(yuǎn)散落在某處，卻從不在一個(gè)地方。沒人粗心，只是缺一份契約。

我的技術(shù)棧是Go后端配Flutter前端。確定現(xiàn)在的方案前，加個(gè)接口意味著雙倍工作量：先在Go里定義請求響應(yīng)結(jié)構(gòu)、接handler、加中間件；再在Dart里重復(fù)整個(gè)模型層，用Dio包層repository才能調(diào)用。每次改動都交同樣的稅，單筆不大，復(fù)利驚人。

我最終采用的方案本身不新鮮：從OpenAPI規(guī)范生成代碼。但讓它真正跑通，花了幾個(gè)項(xiàng)目才磨合好。這份規(guī)范不是文檔，而是所有代碼編譯依賴的單一制品——人類判斷、編譯器約束、LLM推理，都在實(shí)現(xiàn)之前在此交匯。

多數(shù)OpenAPI教程把規(guī)范當(dāng)成代碼的副產(chǎn)品，或需要并行維護(hù)的文檔。我經(jīng)過三個(gè)項(xiàng)目反復(fù)驗(yàn)證的路子正好相反：先寫規(guī)范，從它生成一切，絕不讓代碼偏離規(guī)范。

這能跑通，是因?yàn)镺penAPI結(jié)構(gòu)化、可校驗(yàn)，且在LLM訓(xùn)練數(shù)據(jù)里存在感很強(qiáng)。我讓模型設(shè)計(jì)接口時(shí)，它寫OpenAPI YAML的可靠性遠(yuǎn)高于直接寫地道Go或Dart。規(guī)范自然成了交接點(diǎn)：人類審閱、編譯器強(qiáng)制執(zhí)行、LLM在契約敲定前絕不碰實(shí)現(xiàn)。

第一次正經(jīng)嘗試是在Flutter項(xiàng)目。Dart默認(rèn)強(qiáng)類型，手動對齊Go結(jié)構(gòu)和Dart模型的摩擦從一開始就顯而易見。我在兩邊都搭了代碼生成，缺口堵上了。啟動當(dāng)前項(xiàng)目（一個(gè)研究院ERP）時(shí)，這成了起點(diǎn)而非實(shí)驗(yàn)。

單體倉庫結(jié)構(gòu)很關(guān)鍵。所有東西必須放在一起，因?yàn)橐?guī)范得是跨消費(fèi)者的唯一真相源。

目錄結(jié)構(gòu)長這樣：api/services/下按業(yè)務(wù)拆成23個(gè)yaml文件，redocly合并成openapi.yaml，還有給LLM用的自動導(dǎo)航索引。backend/gen/api/和frontend/packages/shared_api_client/lib/各自鏡像這套拆分，每個(gè)服務(wù)有自己的codegen配置和生成腳本。

規(guī)范即契約的玩法，本質(zhì)是讓人機(jī)協(xié)作有了仲裁標(biāo)準(zhǔn)。LLM擅長寫規(guī)范，人類擅長審規(guī)范，編譯器擅長守規(guī)范——各干各的強(qiáng)項(xiàng)，不再互相踩腳。