北京
如果同一個項目做兩遍，一遍手寫代碼，一遍交給AI，結果會差多少？
一位開發者在完成自己的氣象站系統后，決定做個實驗。他保留了所有原始需求，假裝那個手寫版本不存在，全程用"氛圍編程"的方式——只提需求，不碰代碼，看看AI到底能走多遠。
工具選擇上，他試遍了免費方案：Gemini、OpenRouter、本地Ollama，要么額度耗盡，要么跑不動。最后同事推薦了OpenCode，搭配默認模型Big Pickle，才算穩定下來。
數據表面很驚人。手寫版本花了約28小時，AI版本只花了7小時，提速四倍。但細究起來，這個數字充滿陷阱。
手寫階段他得現學Python和Pimoroni硬件庫，代碼結構反復推倒重來，版本控制里提交了幾十次。AI版本提交次數更少，不是因為他更高效，而是作為"氛圍編程者"，他根本不看代碼，自然也沒什么可提交的。
更隱蔽的是決策路徑的差異。Web應用部分，手寫版本用了16小時完成功能，剩下的12小時全花在迭代——試不同的氣象統計維度，調整數據呈現方式。AI版本直接套用了他最終選定的方案，跳過了整個探索過程。
代碼質量方面，他用SonarQube做了掃描。非AI版本的傳感器讀取模塊有45條可維護性警告，全是命名規范問題——他習慣Java和PHP的駝峰命名，Python的snake_case看不順眼，手動標成了誤報。天氣顯示屏的代碼直接復制了Pimoroni官方示例，也一并排除在統計之外。
這個實驗的誠實之處在于：它暴露了"開發速度"這個指標的脆弱性。當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.
