我們恐怕只是把復雜的問題想得過于簡單。
軟件行業苦降本增效久已。蔓延開去的開發周期，遙遙無望的上線時間，以及不斷冒起的缺陷，怎么看都配不上這支精兵強將的隊伍。生成式 AI 似乎帶來了曙光，它的表現讓人耳目一新，不少人會這么想：生成式 AI 能自動生成代碼，成本低，可重復，即拋的能力像云上的資源，這段代碼不合適的話扔掉好了，重新生成一段。這是不是意味著，不需要這么多精兵強將了？
生成式 AI 在回答我們的問題時，偶爾會拋出個煞有介事的答案，但如果你稍作檢索，就會發現這個答案徒有其表：不是查無此言，就是一派胡言，這與人工智能的威名不符。這即所謂生成式 AI 的幻覺，hallucination——因為沒有真實可靠的語料，它自作主張拼湊了一個假的回答。
大模型技術仍然在不斷更新，能讓人感知到幻覺程度也在逐漸降低。但在它被投入到具體的領域和使用場景時，幻覺效應仍在發生。在這篇文章里，我會分享下生成式 AI 在軟件開發領域的應用，以及其帶來的三個幻覺。
01 幻覺一：更快的速度
不同的軟件工具廠商都在迭代更新自己的代碼助手產品，最著名的是 GitHub 的 Copilot,他們宣稱，可以加快程序員完成任務的速度達 55% 以上，那些清麗迅捷的演示視頻看起來也如飛一般。
但這是否意味著軟件的交付進度可以加快 50%？
那些作為演示的代碼是可疑的，更多程序員在自己的項目中采用 Copilot 的反饋似乎也表明，提速基本只會出現在一些常用的功能實現上。比如數組的排序，數據結構的初始化，或者是一些再簡單不過的模板代碼。
可重復的工具代碼交由 AI 也就罷了。但對于一個開發中的軟件而言，有多少類似的代碼需要重復開發呢？這恐怕值得討論。遑論多數時候，它們只需要一次成型，封裝待用。還有數量相當可觀的業務代碼，程序員會以怎樣的速度來進行？你可以把足夠數量的業務代碼交由 AI 來生成，但是否安全恐怕是一個更大的問題。
這里還有兩個問題值得關注。
一是程序員對 AI 提供代碼的選擇。
AI 如此容易提供多套方法的實現，程序員難免要嘗試從中找出最優的選項。
這個好？還是那個好？咦，竟然有五種不同的實現。需要先讀懂每一種代碼的實現，再切換到下一種。這個實現的方法很優雅，但可惜單元測試失敗了。換下一個。
程序員的好奇心被代碼助手充分攪動。心猿意馬，線性的思維習慣碎落一地。程序員遺忘的不只是開發紀律，還有時間。
二是軟件自有生命周期。
很顯然，輪到程序員開始編寫代碼，很多事情已經發生，而更多的事情還會繼續發生，直到系統上線。這些事情包括但不限于：收集需求，理解需求（從需求說明到用戶故事），測試，維護基礎設施，以及那些層出不窮的修復工作。
我的意思是說，即便 AI 幫助程序員寫得再快，這個階段也只是軟件生命周期中的一部分而已。早有相關的數據統計，程序員日常的工作，只有 30% 的時間是在編寫代碼，而更多的時間是在嘗試理解他們要實現什么功能，以及設計和學習新技能上。
02 幻覺二：更少的 Bug
人編寫的代碼難免存在缺陷，這是軟件質量的基本共識。而且似乎越有經驗的程序員，越容易生產出隱晦的問題，要過了很久才會被發覺。線上問題更讓人提心吊膽，但這樣的擔心很難避免。
AI 生成的代碼，聽起來也很高級，是不是會帶來足夠完美的結果？很可惜，答案可能會讓人失望。
生成式 AI 背后的大模型，以互聯網上大量的語料作為數據來源，盡管大模型技術一直在改善，但網絡上已經現實存在的帶有偏見的數據量十分可觀。這也包括大量飽含缺陷的代碼。這意味著程序員在代碼助手中精挑細選的代碼，也可能存有缺陷。因為這段有缺陷的代碼，可能來自地球另一端的某個人，只是恰巧成為了地球這一端的選擇。
要命的是，生成式 AI 有放大器（amplify）的功效。簡單來說，就是如果程序員采用了存有缺陷的生成代碼，Copilot 會記錄這樣的行為，在接下來類似的場景，會繼續建議有缺陷或差不多的代碼。AI 并不能讀懂這樣的代碼，它只是被鼓勵繼續提供。我們可以預想最后的結果。
程序員要嚴守團隊的開發紀律，保持統一的代碼規范，因為這樣別人才能讀懂，更容易發現潛在問題并修復它。但代碼助手提供的不同樣貌的代碼，似乎也提供了更多的混亂。
代碼有缺陷，只是軟件最后會爆出難以挽回的問題來源之一，甚至是很少的一部分。構建軟件的過程，其實是知識生產和創造的過程。在軟件生命周期不同階段加入進來的各角色，共同理解和分析軟件的需求，然后轉換其為代碼，也在團隊和人員更替的過程中，傳遞這些表面為需求和代碼實則為知識的信息。
但通常，知識會衰減，知識資產的傳遞會不可避免地出現差池。
比如，讀不懂代碼，無法持續更新文檔，整個團隊又被替換，等等。這些才是軟件不斷產生 Bug 和問題的原因所在。人工智能并未能解決這些軟件工程中棘手的問題，至少現在看短時間內做不到。
03 幻覺三：更少的人
AI 的代碼助手看起來確實像見多識廣的程序員。甚至有人愿意把它當成結對編程實踐的伙伴。用人成本一直是 IT 團隊頭疼的問題，好手太貴，合適的人招不到，從頭去培養熟練的程序員又需要太久時間。有了人工智能和代碼助手的加持，是否意味著可以縮編快一半的人？
AI 和代碼助手不僅無法提供上述的速度快和質量高保障外，也期待使用者要有足夠經驗的程序員才好，才能盡可發揮它該有的優勢。這位有經驗的程序員，需要有能力判斷代碼的優劣，判定對已有生產代碼的影響，還需要有精心調整提示詞的耐心和技巧。
在這篇文章里，作者講述了她在使用代碼助手時諸多要留意的問題，還有你能看到的她縝密的內心戲。因為代碼助手帶來的不確定性，可能會引起兩類風險，一是影響到代碼的質量，二是浪費時間。這里其實顯示的是一位足夠資深的程序員的自省能力。
也只有這樣，代碼助手才可以心安理得扮演見多識廣的新手，而經驗程序員充當守門員，她才是那個負責提交代碼的人。這樣說來，AI 改變的其實是編程體驗。
（圖片來源：https://martinfowler.com/articles/exploring-gen-ai.html,作者把代碼助手想象成一個著急幫忙、固執、說話清楚但缺乏經驗的角色，于是用 AI 畫出了這個卡通形象）
AI 和代碼助手在解決簡單重復性問題上，效果顯著。但在構建軟件的過程中，有更多需要人和專業經驗的場景來解決復雜的問題。比如軟件系統日益增加的架構復雜度和范圍，應付市場和業務側的需求，跨角色之間的溝通和協作，還有那些更加時髦的涉及代碼倫理和安全的問題。
雖然判斷程序員是否足夠專業和熟練，不像數數那樣一目了然，但我們也可以說，引入 AI 和代碼助手然后減員開發團隊，能帶來的成效是不確定的，目前看弊大于利。
04 寫在最后
生成式 AI 的本質是模式轉換，從文字的一種形式，轉換成另一種形式，高級的代碼助手的能力也不出其右。如果把涉足軟件構建的 AI 代碼助手，認為是解決諸多軟件工程難題的妙方，我們恐怕只是把復雜的問題想得過于簡單。
寫到這里，我們一直在談什么呢？
我們其實在談的是，在軟件開發上投資 AI 的成效該如何衡量。投資 AI 并不是簡單如購買代碼助手的 License,然后就可以坐享降本增效。不斷詢問“我們要如何衡量投資 AI 和代碼助手的效果？”，不如詢問“我們到底要衡量什么？”。從 DORA 定義的四個關鍵指標開始，是個明智的選擇，它們是變更前置時間、部署頻率、平均恢復時間 （MTTR） 和變更失敗率。
以下幾條基本衡量原則供參考：
衡量團隊效率，而不是個人績效。
衡量成效而不是產出。
查看隨時間推移的趨勢，而不是比較不同團隊的絕對值。
用儀表板上的數據開啟對話，而不是就此結束。
衡量有用的東西，而不是容易衡量的東西。
本文來源：36氪
文章轉載于其他網絡，如有侵權請聯系我們及時刪除！
