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