北京
AI編碼工具總被描繪成效率神器，似乎只要插件一裝，代碼就能10倍速飛濺而出。但來自工程實際運營的數據，可能讓所有樂觀預期都尷尬地沉默了。一家名叫Faros.ai的研發遙測公司，直接接入了Jira、GitHub和CI/CD流水線，量化追蹤了使用AI輔助編程的團隊與不使用AI的團隊的真實表現差異——結果遠非“10倍效能神話”，反倒指向一個讓人不安的結論：我們大規模使用大語言模型的方式，平均來看，很可能正在毀滅價值。
事情的起點是今年3月Faros發布的一份報告，覆蓋了22000名開發者、4000個工程團隊，是對LLM在軟件交付流程中實際影響的罕見大規模對比。報告里最刺眼的數字，莫過于個人產出和系統交付的致命背離：開發者們的“生產率”——也就是完成單個任務的速度——確實提升了，最高能達到2倍左右，這對于個體而言是不小的進步。可一旦把目光拉到整個價值流，意外就來了：衡量團隊真正向用戶交付價值的部署頻率，反而下降了11%。這就像每個廚師都炒菜更快了，但客人等菜的時間卻變長了。
作者Jake May特意辨析了一個運營學上的關鍵區分：生產率（productivity）和吞吐量（throughput）根本不是一回事。生產率只看工人把手頭活兒干完的速度，但吞吐量衡量的是整個系統有多少成品真正流向了客戶。一個功能分支被寫完，離上線還隔著代碼審查、測試、集成和發布，LLM帶來的個人加速很可能被這些環節的隱性摩擦消耗殆盡。更觸目驚心的一個指標是代碼刪除比例，報告沒有展開細節，但高刪除率往往暗示批量產出的代碼質量堪憂，寫得多、扔得也多，返工成本默默侵蝕著效率增益。
當然，這里有一個需要注意的樣本細節：完整的系統級數據只來自將遙測管線接入CI/CD的10%客戶，實際落在約2200位開發者和400個團隊上。這個子樣本是否足夠推及整體，自然會有不同看法。作者認為，子樣本規模已經大到足以讓統計均值描述整體的分布中心，至少在討論趨勢時，這份數據提供的信息比任何主觀感受更可靠。
“這個圖讓我震驚，它是對我們使用LLM的方式的殘酷控訴。”Jake May用這樣一句感嘆鎖定了立場。如果個人效率的提升不能轉化為更頻繁的價值交付，反而附帶上更高的代碼刪除負擔，那所謂的“適度提升”背后，可能藏著更大的系統性損耗。看清這些被忽略的指標，或許比追趕任何新工具都更需要這行人的清醒。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
