如果你關(guān)注 AI 編程的邊界又對編譯器和 C 底層實現(xiàn)感興趣這個項目值得花時間研究一下有人花掉 20 億 Tokens讓大模型寫出了一個完整的 C 編譯器項目標題也很直白——I Spent 2B Tokens Writing a C Compiler So You Dont Have To。20 億 Tokens 是什么概念按主流大模型 API 的計費標準這已經(jīng)是一筆不小的成本投入。更關(guān)鍵的是這個實驗把 AI 寫代碼的能力邊界從補一個函數(shù)、修一個 Bug直接推到了從零構(gòu)建編譯工具鏈的層面。編譯器不是普通應用它涉及詞法分析、語法分析、語義分析、中間表示、代碼生成和運行時支持任何一個環(huán)節(jié)出錯產(chǎn)出的程序都無法執(zhí)行。如果大模型能獨立寫出一套可用的 C 編譯器那 AI 在復雜工程任務上的上限就需要重新評估了。這篇文章會從幾個角度拆解這個項目項目本身解決了什么問題、20 億 Tokens 花得值不值、它能不能在你的機器上跑起來、怎么驗證生成的編譯器真的可用、以及如果你想用類似思路做 AI 輔助開發(fā)有哪些坑可以提前避開。無論你是 C 程序員、編譯器初學者還是研究 AI 編程能力的開發(fā)者這篇內(nèi)容都能給你一個比較完整的判斷依據(jù)。1. 核心能力速覽能力項說明項目類型基于大語言模型生成的 C 編譯器實驗項目Token 成本標題注明約 20 億 Tokens約 2B Tokens主要功能C 源代碼編譯、可執(zhí)行文件生成、語法/類型檢查具體支持范圍需以項目倉庫為準輸出產(chǎn)物編譯器可執(zhí)行程序、IR 中間表示、目標代碼/匯編或二進制硬件門檻運行編譯器和編譯產(chǎn)物對硬件要求不高普通開發(fā)機即可復現(xiàn) AI 生成過程需要大模型 API支持平臺Linux / macOS 優(yōu)先Windows 可通過 WSL 或本地工具鏈運行啟動方式命令行工具API 接口編譯器本身不提供 HTTP API但可作為命令行工具被腳本和 CI 系統(tǒng)集成批量任務支持多源文件編譯、測試套件運行、批量回歸適合場景編譯器原理學習、AI 編程能力評估、C 前端實驗、自動測試從這張表可以看出這個項目不是一個面向普通用戶的一鍵編譯器而是偏向?qū)嶒炐再|(zhì)的工程樣本。它最大的價值不在于替代 GCC 或 Clang而在于展示大模型生成復雜系統(tǒng)軟件的可能性以及巨量 Token 投入后的真實產(chǎn)出質(zhì)量。2. 適用場景與使用邊界在做任何部署和測試之前先想清楚你想從這個項目里獲得什么。不同目標的讀者使用方式完全不同。2.1 適合誰第一類學習編譯器原理的開發(fā)者。如果你一直在看龍書《編譯原理》但缺少實踐樣例這個項目可以幫你直觀看到詞法分析、語法樹、中間表示和代碼生成在真實代碼里是怎么組織的。哪怕最終編譯器只實現(xiàn)了 C 子集它依然是一個完整可運行的工程骨架。第二類研究 AI 編程能力的開發(fā)者。這類讀者關(guān)心的核心問題不是編譯器本身而是20 億 Tokens 換來的代碼質(zhì)量如何。你可以把項目源碼當作評估樣本分析大模型在長上下文、多文件、高復雜度工程上的表現(xiàn)甚至自己設(shè)計更小規(guī)模的復現(xiàn)實驗。第三類做自動化和測試平臺的同學。項目提供的編譯入口如果封裝成命令行工具可以進入 CI 流程用來做AI 生成代碼能否通過編譯的回歸測試也可以當作編譯錯誤分析的測試素材。2.2 不適合什么不要把它當作生產(chǎn)級編譯器使用。從工程經(jīng)驗看任何大模型生成的編譯工具鏈在標準庫支持、優(yōu)化能力、異常處理、可移植性上都不可能達到 GCC/Clang 的成熟度。如果你需要編譯真實業(yè)務 C 代碼直接用系統(tǒng)的 GCC、Clang 或 MSVC不要在這個實驗項目上投入時間。另外如果你完全不了解 C 基礎(chǔ)語法和編譯流程直接去看這個項目會非常吃力。建議先掌握基本的編譯過程概念再回來分析源碼。2.3 合規(guī)與安全邊界使用這個項目時要額外注意三點。項目由大模型生成其源碼許可證和生成工具的使用條款需要提前閱讀避免商用后出現(xiàn)授權(quán)問題。項目的編譯結(jié)果如果有運行時行為應該只在隔離的測試環(huán)境里運行不要直接處理涉及到人臉、隱私、密鑰和版權(quán)數(shù)據(jù)的輸入。如果你基于這個項目做二次開發(fā)發(fā)布前要確認源碼中不包含違反模型服務條款的內(nèi)容同時保留生成日志方便溯源。3. C 編譯器技術(shù)背景為什么 Tokens 消耗巨大只看20 億 Tokens這個數(shù)字很難有體感先看一下 C 編譯器包含哪些模塊你就能理解為什么這個項目會消耗如此多的 Token。編譯器整體上分為前端、中端和后端。前端負責把 C 源代碼解析成抽象語法樹AST這一階段涉及詞法分析器和語法分析器的邏輯。C 是所有主流語言中語法最復雜的語言之一解析 C 代碼要處理模板、運算符重載、命名空間、類繼承、Lambda 表達式、移動語義、異常處理等大量規(guī)則用自然語言向大模型描述這些規(guī)則本身就要消耗大量上下文。中端負責語義分析和中間表示生成。類型檢查、符號表管理、作用域解析、控制流分析都在這一階段完成。中間表示有多種形態(tài)包括類似三地址碼、SSA 形式或自定義 IR。大模型需要保持狀態(tài)一致寫出的代碼才能在多個編譯階段之間正確傳遞信息。后端負責目標代碼生成和優(yōu)化。寄存器分配、指令選擇、棧幀布局、優(yōu)化 Pass 和匯編輸出都在這里完成。要讓生成的代碼真正可執(zhí)行后端必須針對特定平臺生成正確的指令序列這對大模型的準確度要求非常高。從工程體量看一個最小可用的 C 編譯器前端至少需要幾千行代碼加上中間表示和后端代碼總量可能超過數(shù)萬行。如果用大模型逐段生成、反復迭代調(diào)試20 億 Tokens 并不是一個夸張的數(shù)字。實際上編譯器是典型的狀態(tài)密集、邏輯嚴格、錯誤難以定位的軟件類型比生成一個 Web 應用或工具腳本的難度高一個量級。4. Token 成本模型與投入產(chǎn)出分析這個項目的標題已經(jīng)傳達了一個信息為了寫編譯器作者花掉了 2B Tokens。那這筆投入到底值不值可以拆成成本、收益兩個維度來分析。4.1 成本維度從公開計費模型看如果全部使用高級推理模型2B Tokens 的成本會非常高。如果項目使用了更經(jīng)濟的模型或批量 API甚至可能通過自托管模型完成那成本會大幅下降。從項目標題推測作者可能有 GPU 集群或評測資源支持屬于研究性投入。對普通開發(fā)者來說不建議直接復刻同等規(guī)模的實驗。更合理的做法是用小模型或蒸餾模型在特定子任務上做測試例如讓模型只生成詞法分析器或者只生成 IR 定義然后再逐步擴展到全流程。4.2 收益維度這筆投入的核心收益不是得到一個編譯器而是獲得了一套實驗數(shù)據(jù)和過程記錄。你能從源碼里看到大模型如何處理以下問題如何在多個源文件之間保持接口一致如何在語義分析中處理 C 的類型系統(tǒng)如何在生成代碼后完成錯誤定位和修正如何把自然語言描述的編譯規(guī)則轉(zhuǎn)化為可執(zhí)行的代碼邏輯這些信息對研究大模型軟件工程能力的團隊非常有價值因為單獨的指標評測比如 HumanEval 分數(shù)只能說明能不能寫函數(shù)而這個項目能說明能不能寫一個完整系統(tǒng)。4.3 普通開發(fā)者怎么借鑒如果你不打算復刻編譯器的全部開發(fā)過程可以把這個項目當作 AI 輔助編碼的案例來參考。在你自己使用 GPT、Claude、DeepSeek 等模型寫 C 項目時實踐中的幾條做法是給模型的任何生成任務都附上最小可運行示例讓模型先輸出核心數(shù)據(jù)結(jié)構(gòu)再輸出業(yè)務邏輯把大文件拆分成有明確接口描述的多個小文件避免模型在超長上下文中丟失狀態(tài)要求模型為每個函數(shù)生成測試用例確保生成的代碼能立刻驗證。這和標題中2B Tokens的底層邏輯是一致的大模型寫復雜系統(tǒng)不是一次 Prompt 就能完成的需要大量迭代、糾錯和回歸。5. 環(huán)境準備與前置條件在克隆項目倉庫并嘗試編譯之前先把本機環(huán)境準備好。這個項目本質(zhì)是一個編譯器工具鏈開發(fā)和測試環(huán)境可以參考下面的清單。5.1 推薦系統(tǒng)Linux 和 macOS 優(yōu)先因為編譯器實驗項目往往依賴 Unix 風格的工具鏈和腳本。如果你只有 Windows優(yōu)先使用 WSLWindows Subsystem for Linux或 Windows 自帶的開發(fā)者模式而不是直接在 cmd 里硬跑。5.2 需要安裝的依賴先列出判斷項目可運行性時最常用的依賴項具體版本以項目 README 為準Python 3.10 或更高版本一些自動化腳本可能基于 Python 編寫構(gòu)建工具CMake、Make 或 NinjaC 編譯器GCC 或 Clang用來編譯項目本身以及測試編譯產(chǎn)物Python 虛擬環(huán)境工具venv 或 conda用于隔離 Python 依賴如果你打算復現(xiàn)大模型生成編譯器的過程還需要準備大模型 API 的訪問憑證或者本地推理環(huán)境。5.3 VSCode 配置開發(fā)環(huán)境很多讀者習慣用 VSCode 看代碼這里給出一套通用配置。創(chuàng)建.vscode/tasks.json文件配置構(gòu)建任務{(diào) version: 2.0.0, tasks: [ { label: build-compiler, type: shell, command: cmake --build build, group: { kind: build, isDefault: true } } ] }創(chuàng)建.vscode/c_cpp_properties.json讓 IntelliSense 能正確解析項目頭文件路徑{ configurations: [ { name: Linux, includePath: [ ${workspaceFolder}/include, ${workspaceFolder}/src ], defines: [], compilerPath: /usr/bin/g, cStandard: c17, cppStandard: c17, intelliSenseMode: linux-gcc-x64 } ], version: 4 }5.4 磁盤和內(nèi)存從編譯器項目的常規(guī)體量來看源碼、構(gòu)建產(chǎn)物和測試文件一般不會太高普通開發(fā)機的磁盤空間足夠。但如果你要把整個 2B Tokens 的生成日志、中間版本和測試數(shù)據(jù)全部拉下來分析建議預留足夠的存儲空間。內(nèi)存方面編譯大型 C 文件時編譯器進程本身可能占用較多內(nèi)存建議 8GB 以上。6. 安裝部署與啟動方式這個項目的啟動方式取決于它是否提供了一鍵構(gòu)建腳本。這里給出通用的部署流程你可以根據(jù)自己的項目結(jié)構(gòu)調(diào)整具體命令。6.1 拉取源碼git clone https://github.com/your-project/ai-cpp-compiler.git cd ai-cpp-compiler注意上面是通用示例實際倉庫地址需要根據(jù)項目 README 確認。不要盲目運行來源不明的 clone 命令。6.2 創(chuàng)建 Python 虛擬環(huán)境如果項目包含 Python 輔助腳本python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果項目倉庫沒有requirements.txt文件說明它可能不需要 Python 依賴可以跳過。6.3 構(gòu)建編譯器本體標準 CMake 構(gòu)建流程mkdir -p build cd build cmake .. make -j$(nproc) cd ..如果項目提供的是build.sh或makefile則直接執(zhí)行對應腳本./build.sh啟動編譯器通常可以這樣驗證./mycc --version如果命令返回了版本信息或編譯器的基本信息說明構(gòu)建成功。此時可以準備第一個測試源文件。6.4 編譯第一個 C 文件新建一個最簡單的測試文件hello.cppint main() { return 0; }然后使用項目生成的編譯器進行編譯./mycc hello.cpp -o hello ./hello echo $?如果echo $?輸出0說明編譯器成功生成了可執(zhí)行文件并且程序正常退出。這是一個最基本的冒煙測試。實際項目中的命令參數(shù)可能不同需要以項目文檔說明為準。通常編譯器工具都會支持輸入文件、輸出文件和若干編譯選項。7. 功能測試與效果驗證拿到一個編譯器項目后最重要的事情是弄清它的能力邊界。不要只測一個 Hello World 就下結(jié)論建議按下面的測試維度系統(tǒng)過一遍。7.1 基礎(chǔ)語法支持測試第一組測試變量、常量、運算符、控制流程。// test_01.cpp int main() { int a 3; int b 4; int c a * b 2; if (c 10) { return 0; } else { return 1; } }期望結(jié)果編譯通過運行返回0。如果編譯器在這一步就報錯說明它對 C 的基礎(chǔ)語法支持還不完整。7.2 函數(shù)與作用域測試第二組測試函數(shù)定義、參數(shù)傳遞、返回值、局部變量遮蔽。// test_02.cpp int add(int x, int y) { return x y; } int main() { int result add(3, 5); return result - 8; }期望結(jié)果編譯通過運行返回0。這一步能驗證符號表和類型檢查邏輯是否正常工作。7.3 類型系統(tǒng)測試第三組測試整數(shù)類型、布爾類型、隱式類型轉(zhuǎn)換。// test_03.cpp int main() { int i 42; bool flag true; if (flag) { i i 1; } return i - 43; }期望結(jié)果編譯通過運行返回0。這里主要看類型檢查器對基本類型和轉(zhuǎn)換的處理能力。7.4 錯誤診斷測試一個好的編譯器不僅要能編譯合法代碼還要能在非法代碼上給出有效報錯。準備一個包含語法錯誤和類型錯誤的文件// test_error.cpp int main() { int a ; return not an int; }期望結(jié)果編譯器返回非零退出碼并輸出報錯信息。報錯位置是否精確、信息是否可讀是判斷代碼生成質(zhì)量的重要指標。7.5 編譯器輸出檢查除了運行結(jié)果還可以檢查編譯器生成的中間產(chǎn)物。如果項目支持輸出 IR./mycc --emit-ir test_01.cpp從輸出的中間表示可以判斷編譯器是真正完成了解析 - 語義分析 - 中間表示的全流程還是只做了一個簡單的文本替換。7.6 判斷標準整個驗證過程遵循一條原則先看能不能編譯成功再看能不能正確運行最后看錯誤診斷和輸出質(zhì)量。如果前兩步通過就說明編譯器的主體框架是成立的。如果第三步也能做好說明后端代碼生成邏輯比較完整。8. 接口 API 與命令行集成方式這個項目本身不提供 HTTP API但作為命令行工具它可以很好地被外部系統(tǒng)集成。如果你想把項目的編譯器接入自己的測試平臺或 CI 流程可以參考下面的方式。8.1 命令行調(diào)用封裝先用一個簡單的 Shell 腳本封裝編譯入口#!/bin/bash # build_and_run.sh COMPILER./mycc SOURCE$1 OUTPUT${SOURCE%.cpp}.out $COMPILER $SOURCE -o $OUTPUT if [ $? -ne 0 ]; then echo COMPILE_FAILED: $SOURCE exit 1 fi $OUTPUT exit $?8.2 Python 批量調(diào)用如果你需要批量編譯一批 C 文件并用 Python 匯總結(jié)果可以寫一個簡單的測試驅(qū)動腳本import subprocess import pathlib compiler ./mycc test_dir pathlib.Path(./tests) results [] for cpp_file in sorted(test_dir.glob(*.cpp)): proc subprocess.run( [compiler, str(cpp_file), -o, tmp_bin], capture_outputTrue, textTrue, timeout30 ) if proc.returncode 0: run_proc subprocess.run([./tmp_bin], capture_outputTrue, textTrue, timeout10) results.append({ file: cpp_file.name, compile: PASS, runtime: run_proc.returncode, stdout: run_proc.stdout.strip() }) else: results.append({ file: cpp_file.name, compile: FAIL, stderr: proc.stderr.strip() }) for r in results: print(r)這個腳本的邏輯很通用先編譯再運行最后把每個文件的編譯狀態(tài)和運行返回碼匯總輸出。你可以把它接到 Jenkins、GitHub Actions 或自建的回歸系統(tǒng)里。8.3 批量任務設(shè)計建議如果要做批量測試需要注意三點一是給每個編譯任務設(shè)置超時時間避免某個源文件讓編譯器陷入死循環(huán)二是按目錄組織測試用例例如tests/basic、tests/error、tests/advanced三是把編譯日志保存到單獨目錄方便排查失敗原因。8.4 注意端口和服務邊界編譯器不是網(wǎng)絡服務所以不需要考慮端口占用問題。但如果你把編譯接口封裝成 Web API比如用 FastAPI 包一層那就必須考慮訪問控制。不要讓任意用戶上傳任意 C 代碼到你的服務器上編譯因為惡意代碼可能在服務器上執(zhí)行系統(tǒng)命令。如果確實要開放建議使用 Docker 容器隔離并且配置資源限額。9. 資源占用與性能觀察編譯器項目跑起來之后觀察資源占用是評估代碼質(zhì)量的一個重要手段。編譯器本身的內(nèi)存占用、編譯速度、生成代碼的執(zhí)行效率都能反映生成代碼的工程水平。9.1 編譯階段資源占用在編譯大型測試文件時通過htop或系統(tǒng)任務管理器觀察編譯進程。如果編譯器在語義分析階段內(nèi)存暴漲說明符號表或語法樹的管理不夠高效。如果編譯時間異常長說明算法復雜度過高。跑一個對比測試time ./mycc large_test.cpp -o output_ai time g large_test.cpp -o output_gcc對比兩個命令的輸出時間可以直觀看到 AI 生成編譯器的性能差距。這個對比沒有絕對的及格線但通常會明顯低于 GCC/Clang這并不意外。9.2 生成代碼的執(zhí)行效率編譯器生成的程序運行速度也是重要指標?？梢杂靡恍┯嬎阈蜏y試代碼同時用 two 編譯器編譯然后比較運行時間。這里尤其適合把循環(huán)計算作為測試樣例因為循環(huán)優(yōu)化是編譯器后端最容易拉開差距的地方。9.3 Token 消耗側(cè)觀察如果你是復現(xiàn)實驗的開發(fā)者還需要關(guān)注 Token 消耗的分布。一次完整的編譯開發(fā)流程通常包括需求描述、代碼生成、錯誤修復、回歸測試、重構(gòu)優(yōu)化。建議記錄每一輪 Prompt 的輸入 Token 和輸出 Token這樣能看出消耗到底花在哪個環(huán)節(jié)。一個常見的現(xiàn)象是代碼生成只占少部分 Token大量 Token 消耗在錯誤修復和反復測試上。10. 常見問題與排查方法在部署和測試 AI 生成編譯器時有幾類問題是比較典型的。下面整理了一張排查表。問題現(xiàn)象可能原因排查方式解決方案構(gòu)建階段 cmake 失敗缺少依賴或版本不匹配查看 cmake 日志和項目 README安裝對應版本依賴編譯命令找不到編譯器二進制未生成或路徑不對檢查 build 目錄下的可執(zhí)行文件重新構(gòu)建或設(shè)置環(huán)境變量編譯后運行報段錯誤生成的代碼在后端階段出錯先用--emit-ir檢查中間表示簡化測試代碼定位到具體語法特性大文件編譯內(nèi)存不足數(shù)據(jù)結(jié)構(gòu)效率低觀察編譯進程內(nèi)存占用縮小測試文件分批驗證C 標準庫支持缺失項目只實現(xiàn)了語言核心查看支持范圍說明避免使用標準庫測試核心語法VSCode IntelliSense 報錯includePath 配置不對檢查c_cpp_properties.json按項目實際目錄調(diào)整 includePath測試腳本卡住某個測試觸發(fā)死循環(huán)使用timeout命令運行為每個測試設(shè)置超時生成代碼許可證不確定使用大模型生成源碼閱讀項目許可證和使用條款商用前做法律審查編譯錯誤信息過于混亂錯誤定位不精確查看報錯行號是否準確用錯誤恢復機制改進前后端這里的核心原則是不要一上來就懷疑項目完全不能用先縮小問題范圍。編譯器類問題大多是某個語法特性沒實現(xiàn)或某個階段的狀態(tài)傳遞有誤基本都可以通過簡化測試用例來定位。11. 最佳實踐與使用建議如果你要把這個項目跑起來做研究或者想從中學到編譯器和大模型工程的思路下面幾條建議值得參考。11.1 先小后大先簡單后復雜第一次接觸項目時不要試圖編譯一個大型 C 程序。從最簡單的main函數(shù)開始逐步加入變量、函數(shù)、類、模板。每增加一個特性記錄一次結(jié)果建立一張支持特性清單。這樣做的好處是當測試失敗時你能明確知道是哪一步引入的問題。11.2 保留穩(wěn)定的構(gòu)建環(huán)境因為項目可能涉及多個依賴建議在容器或虛擬環(huán)境里搭建構(gòu)建環(huán)境。記錄完整的依賴版本把構(gòu)建命令固化成一個腳本。如果以后需要復現(xiàn)直接執(zhí)行腳本即可。11.3 把測試用例分類管理在項目目錄下建立三個子目錄tests/ basic/ # 基礎(chǔ)語法測試 error/ # 錯誤診斷測試 advanced/ # 類、模板、高級特性測試每個測試文件用數(shù)字前綴命名保持執(zhí)行順序清晰。這樣不管是手動測試還是自動化腳本都能穩(wěn)定復現(xiàn)結(jié)果。11.4 注意日志與生成過程溯源如果你是做 AI 生成實驗維護一份詳細日志非常關(guān)鍵。記錄每一次 Prompt、每一次代碼輸出、每一次編譯失敗和修復操作。這不僅是復盤的基礎(chǔ)也是評估 Token 消耗分布的依據(jù)。后續(xù)如果要把實驗結(jié)果寫入論文或博客這份日志就是最權(quán)威的數(shù)據(jù)來源。11.5 警惕安全邊界編譯器項目如果被封裝成在線服務一定要做權(quán)限隔離。不要讓外部用戶隨意提交源代碼進行編譯執(zhí)行。即便在本地也不要直接編譯來源不明的代碼避免潛在的惡意代碼在編譯或運行階段觸發(fā)系統(tǒng)調(diào)用。更穩(wěn)妥的做法是在 Docker 容器中執(zhí)行所有編譯和測試。11.6 對生產(chǎn)使用保持謹慎從項目性質(zhì)來看它是AI 生成編譯器的實驗驗證并非生產(chǎn)工具。如果你的項目組想使用 AI 生成的 C 編譯能力不要直接套用這個編譯器建議先用它在隔離環(huán)境跑通完整測試再考慮在輔助工具鏈中使用。生產(chǎn)環(huán)境的編譯任務仍然交給成熟的編譯器。12. 從 2B Tokens 看 AI 編程的邊界與啟發(fā)回到最初的問題花 20 億 Tokens 寫一個 C 編譯器到底值不值從項目產(chǎn)出來看它至少證明了幾個關(guān)鍵事實。第一大模型能夠生成長鏈條、多階段、狀態(tài)密集的復雜系統(tǒng)代碼。編譯器是計算機科學里難度最高的軟件類型之一涉及大量中間狀態(tài)和嚴格格式要求這個項目能跑通說明生成式模型的上限遠超傳統(tǒng)認知。第二巨量 Token 的消耗表明當前的大模型在生成復雜系統(tǒng)時仍需要大量迭代和糾錯。與其說寫編譯器是這次實驗的核心不如說調(diào)試編譯器才是真正消耗 Token 的地方。這對所有 AI 編程工具的研發(fā)方向都有參考價值減少錯誤、提升第一次生成準確率比單純擴大模型規(guī)模更關(guān)鍵。第三這類項目的工程價值低于研究價值。對普通開發(fā)者它不一定能替代任何現(xiàn)有工具但對編譯器研究者、AI 應用工程師和框架開發(fā)者它的源碼、測試結(jié)果和開發(fā)過程都是寶貴的數(shù)據(jù)資產(chǎn)。如果你準備動手嘗試建議的第一步不是克隆倉庫而是先想清楚自己的目標。是想學習 C 編譯器結(jié)構(gòu)還是想評估大模型的代碼生成能力還是想把 AI 生成編譯器的思路借鑒到自己的項目里目標不同投入的時間和關(guān)注點也完全不同。從實踐角度來看先跑通項目自帶的 Hello World 測試再逐步擴大測試范圍最后把編譯器和測試腳本接入你的自動化流程。整個過程中最值得關(guān)注的不是項目能不能完美編譯 C而是它在哪些方面做得超出預期哪些方面暴露了生成式模型的局限。把這些觀察記錄下來你會對 AI 編程的能力邊界擁有更真實的判斷。