北京
周三下午，一位開發(fā)者在GitHub上發(fā)布了一個叫Almide的編程語言。不是圖靈完備競賽，也不是語法糖炫技——他只想回答一個具體問題：當AI修改現(xiàn)有代碼時，語言設(shè)計能不能讓改完的代碼更容易跑通？
這個動機很務實。現(xiàn)在談AI編程，滿屏都是"生成新代碼"：寫個函數(shù)、刷個算法題、從提示詞蹦出完整實現(xiàn)。但真實工作里，更多時候是在改代碼：加個參數(shù)、換個數(shù)據(jù)結(jié)構(gòu)、修個邊界情況、重構(gòu)API、保證測試還能過。Almide的作者管這叫"修改存活率"——LLM改完代碼后，還能編譯通過、測試全綠的比例。
他搭了30個代碼修改任務當基準測試。結(jié)果有點意思：Claude Sonnet 4.6在Almide上30/30全過，同樣任務套到Rust上，大概58%的通過率。作者趕緊 disclaimer：這不是說Almide比Rust強，Rust的生態(tài)和成熟度碾壓級領(lǐng)先。選Rust當參照，只是因為它是個嚴肅的系統(tǒng)級語言，靜態(tài)類型檢查夠嚴格。
Almide本身是個實驗品。靜態(tài)類型、雙向類型推斷、泛型、窮盡式模式匹配、自動錯誤傳播的效果函數(shù)、管道操作符、版本化包管理的模塊系統(tǒng)——這些特性不稀奇。稀奇的是它的目標：生成Rust代碼或直接吐WebAssembly，編譯器本身能跑在瀏覽器里當WASM。
為什么語言設(shè)計會影響AI改代碼的成功率？作者的觀察是：LLM很擅長生成"看起來對"的代碼，但看起來對不等于真能用。改代碼時AI會犯各種小錯：改了這處調(diào)用沒改那處、返回類型對不上、漏了錯誤分支、破壞了所有權(quán)規(guī)則、局部看著合理但整體對不上、編譯過了測試掛了。有些錯是模型的問題，有些可能是語言設(shè)計的問題。
Almide的實驗還沒給出完整答案，但它把討論從"AI能寫多少新代碼"拉回到了"AI能穩(wěn)定維護多少舊代碼"。后者才是大多數(shù)程序員的真實日常。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
