北京
2023年初我開始用LLM輔助寫代碼，當時覺得自己效率猛漲。但連著一年多每天和這些模型、智能體打交道，我慢慢發現，那種“我變快了”的感覺，更多是生成文本的速度帶來的錯覺，不是真正想清楚問題的速度。
各大廠商聲稱AI能把開發者生產力提升20%到30%，這數字一旦進了主流輿論，就很難公開去唱反調。尤其當行業巨頭靠這個假設賺錢，少有人愿意站出來說“沒那么神”。但我想記錄自己的真實體驗，哪怕單個人的聲音改變不了什么。
過去，拿到一個任務，我會先在腦子里搭實現方案，然后一小塊一小塊地寫代碼。遇到不熟悉的庫，就去讀文檔，弄明白接口到底怎么調用。整個過程里，我的認知資源幾乎全部壓在“寫下每一行代碼，同時徹底理解它在干什么”上。而用上AI之后，這個認知流程被徹底切斷了。代碼不是我想出來的，是模型吐出來的，我切換到了另一種任務：代碼審查。
問題就從這里開始分層。第一層，同樣的任務，AI生成的代碼量普遍比以前自己寫的多出一大截。表面上好像幫你省了打字時間，實際上你要審的文本更多，把握上下文也更吃力。第二層，讀代碼和寫代碼是兩種完全不同的認知活動，就像寫一本書的人和讀那本書的人，對內容的理解程度不可能一樣。代碼作者知道每個設計決策的緣由、每處妥協的代價；代碼讀者卻只能從最終產物反推，很多隱藏意圖根本無從還原。
久而久之，一個更棘手的現象浮現出來：提交合并請求的開發者，自己常常記不清那段代碼到底做了什么。因為隔了一段時間回頭看，那段邏輯是AI替他“想出來”的，他并沒有真正和那些技術細節搏斗過。記憶里只剩下當時覺得“看著沒問題，測試也過了”的模糊印象。
如果只把代碼行數當作生產力的核心標尺，我們其實在批量制造大量難以維護的知識斷裂。我觀察到有些團隊已經在為此付出代價：新成員接手項目時，面對巨大而扁平的AI生成代碼塊，理解的缺口比以前手寫代碼時代還要深。代碼評審者得花更長時間去確認邊界條件、錯誤處理和隱藏的副作用，而寫代碼的那個人卻無法提供有效補充，因為他自己也記不清了。
我并不是要否定LLM的文本生成能力——它們確實能快速輸出合用的代碼片段、測試用例、配置文件。但過去一年多，我反復撞見的陷阱在于，人類開發者一旦把“生成速度”等同于“生產力”，就會忽略代碼被讀、被驗證、被長期維護的真實成本。那種最初看到的20%到30%的效率數字，恰恰是這套衡量標準本身的產物，而不是一個產品被真正交付到用戶手里那刻的速度。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
