作者 | 張凱峰

軟件行業(yè)苦降本增效久已。蔓延開去的開發(fā)周期，遙遙無望的上線時間，以及不斷冒起的缺陷，怎么看都配不上這支精兵強將的隊伍。生成式AI 似乎帶來了曙光，它的表現(xiàn)讓人耳目一新，不少人會這么想。它能自動生成代碼，成本低，可重復(fù)，即拋的能力像云上的資源，這段代碼不合適？扔掉好了，重新生成一段。很自然就會想到，是不是也不需要這么多精兵強將了，程序員們也很擔(dān)心這一點。

生成式 AI 回答我們的問題時，偶爾會拋出個煞有介事的答案，但如果你稍作檢索，就會發(fā)現(xiàn)這個答案徒有其表：不是查無此言，就是一派胡言，這與人工智能的威名不符。這即所謂生成式 AI 的幻覺，hallucination——因為沒有真實可靠的語料，它自作主張拼湊了一個假的回答。

大模型技術(shù)仍然在不斷更新，能讓人感知到幻覺程度也在逐漸降低。但在它被投入到具體的領(lǐng)域和使用場景時，幻覺效應(yīng)仍在發(fā)生，在這篇文章里我們會談到的它在軟件開發(fā)領(lǐng)域的應(yīng)用。

幻覺一：更快的速度

不同的軟件工具廠商都在迭代更新自己的代碼助手產(chǎn)品，最著名的是 GitHub 的 Copilot，他們宣稱，可以加快程序員完成任務(wù)的速度達(dá) 55%以上，那些清麗迅捷的演示視頻看起來也如飛一般。

（圖片來源：https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/）

但這是否意味著軟件的交付進度可以加快 50%？

那些作為演示的代碼是可疑的，更多程序員在自己的項目中采用Copilot的反饋似乎也表明，提速基本只會出現(xiàn)在一些常用的功能實現(xiàn)上。數(shù)組的排序，數(shù)據(jù)結(jié)構(gòu)的初始化，要不然就是一些再簡單不過的模板代碼。

可重復(fù)的工具代碼交由 AI 也就罷了。但對于一個開發(fā)中的軟件而言，有多少類似的代碼需要重復(fù)開發(fā)呢，這恐怕是值得討論的。遑論多數(shù)時候，它們只需要一次成型，封裝待用。

還有數(shù)量相當(dāng)可觀的業(yè)務(wù)代碼，程序員會以怎樣的速度來進行？你可以把足夠數(shù)量的業(yè)務(wù)代碼交由 AI 來生成，但是否安全恐怕是一個更大的問題。

這里還有兩個問題值得關(guān)注。

一是程序員對AI 提供代碼的選擇。

AI 如此容易提供多套方法的實現(xiàn)，程序員難免要嘗試從中找出最優(yōu)的選項。

這個好？還是那個好？咦，竟然有五種不同的實現(xiàn)。需要先讀懂每一種代碼的實現(xiàn)，再切換到下一種。這個實現(xiàn)的方法很優(yōu)雅，但可惜單元測試失敗了。換下一個。

程序員的好奇心被代碼助手充分?jǐn)噭印Ｐ脑骋怦R，線性的思維習(xí)慣碎落一地。程序員遺忘的不只是開發(fā)紀(jì)律，還有時間。

二是軟件自有生命周期。

很顯然，輪到程序員開始編寫代碼，很多事情已經(jīng)發(fā)生，而更多的事情還會繼續(xù)發(fā)生，直到系統(tǒng)上線。這些事情包括但不限于：收集需求，理解需求（從需求說明到用戶故事），測試，維護基礎(chǔ)設(shè)施，以及那些層出不窮的修復(fù)工作。

我的意思是說，即便AI 幫助程序員寫得再快，這個階段也只是軟件生命周期中的一部分而已。早有相關(guān)的數(shù)據(jù)統(tǒng)計，程序員日常的工作，只有 30%的時間是在編寫代碼，而更多的時間是在嘗試?yán)斫馑麄円獙崿F(xiàn)什么功能，以及設(shè)計和學(xué)習(xí)新技能上。

（圖片來源：https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/）

幻覺二：更少的 Bug

人編寫的代碼難免存在缺陷，這是軟件質(zhì)量的基本共識。而且似乎越有經(jīng)驗的程序員，越容易生產(chǎn)出隱晦的問題，要過了很久才會被發(fā)覺。線上問題更讓人提心吊膽，但這樣的擔(dān)心很難避免。

AI 生成的代碼，聽起來也很高級，是不是會帶來足夠完美的結(jié)果？很可惜，答案可能會讓人失望。

生成式 AI 背后的大模型，以互聯(lián)網(wǎng)上大量的語料作為數(shù)據(jù)來源，盡管大模型技術(shù)一直在改善，但網(wǎng)絡(luò)上已經(jīng)現(xiàn)實存在的帶有偏見的數(shù)據(jù)量十分可觀。這也包括大量飽含缺陷的代碼。

這意味著程序員在代碼助手中精挑細(xì)選的代碼，也可能存有缺陷。因為這段有缺陷的代碼，可能來自地球另一端的某個人，只是恰巧成為了地球這一端的選擇。

要命的是，生成式 AI 有放大器（amplify）的功效。簡單來說，就是如果程序員采用了存有缺陷的生成代碼，Copilot 會記錄這樣的行為，在接下來類似的場景，會繼續(xù)建議有缺陷或差不多的代碼。AI 并不能讀懂這樣的代碼，它只是被鼓勵繼續(xù)提供。我們可以預(yù)想最后的結(jié)果。

（prompt：A programmer is sitting at a computer desk, looking confused and frustrated. The computer screen shows a code editor with a pop-up window of GitHub Copilot suggesting incorrect code, symbolized by red error indicators and crossed-out lines in the code. The programmer is scratching their head, surrounded by crumpled paper, indicating multiple failed attempts. The scene conveys a sense of challenge and confusion due to the reliance on incorrect AI-generated code suggestions, leading to quality issues in software development. The room is cluttered, reflecting the chaotic situation. ）

程序員要嚴(yán)守團隊的開發(fā)紀(jì)律，保持統(tǒng)一的代碼規(guī)范，因為這樣別人才能讀懂，也意味著更容易發(fā)現(xiàn)潛在問題并修復(fù)它。但代碼助手提供的不同樣貌的代碼，似乎也提供了更多的混亂。

代碼有缺陷，只是軟件最后會爆出難以挽回的問題來源之一，甚至是很少的一部分。構(gòu)建軟件的過程，其實是知識生產(chǎn)和創(chuàng)造的過程。在軟件生命周期不同階段加入進來的各角色，共同理解和分析軟件的需求，然后轉(zhuǎn)換其為代碼，也在團隊和人員更替的過程中，傳遞這些表面為需求和代碼實則為知識的信息。

但通常，知識會衰減，知識資產(chǎn)的傳遞會不可避免地出現(xiàn)差池。讀不懂代碼，無法持續(xù)更新文檔，整個團隊又被替換，還有更多可能性。這些才是軟件不斷產(chǎn)生 Bug 和問題的原因所在。人工智能并未能解決這些軟件工程中棘手的問題，至少現(xiàn)在看短時間內(nèi)做不到。

幻覺三：更少的人

AI 的代碼助手看起來確實像見多識廣的程序員。甚至有人愿意把它當(dāng)成結(jié)對編程實踐的伙伴。用人成本一直是 IT 團隊頭疼的問題，好手太貴，合適的人招不到，從頭去培養(yǎng)熟練的程序員又需要太久時間。有了人工智能和代碼助手的加持，是否意味著可以縮編快一半的人？

AI 和代碼助手不僅無法提供上述的速度快和質(zhì)量高保障外，也期待使用者要有足夠經(jīng)驗的程序員才好，才能盡可發(fā)揮它該有的優(yōu)勢。這位有經(jīng)驗的程序員，需要有能力判斷代碼的優(yōu)劣，判定對已有生產(chǎn)代碼的影響，還需要有精心調(diào)整提示詞的耐心和技巧。

在這篇文章里，作者講述了她在使用代碼助手時諸多要留意的問題，還有你能看到的她縝密的內(nèi)心戲。因為代碼助手帶來的不確定性，可能會引起兩類風(fēng)險，一是影響到代碼的質(zhì)量，二是浪費時間。這里其實顯示的是一位足夠資深的程序員的自省能力。

也只有這樣，代碼助手才可以心安理得扮演見多識廣的新手，而經(jīng)驗程序員充當(dāng)守門員，她才是那個負(fù)責(zé)提交代碼的人。這樣說來，AI 改變的是編程體驗。

（圖片來源：https://martinfowler.com/articles/exploring-gen-ai.html，作者把代碼助手想象成一個著急幫忙、固執(zhí)、說話清楚但缺乏經(jīng)驗的角色，于是用 AI 畫出了這個卡通形象）

AI 和代碼助手在解決簡單重復(fù)性問題上，效果顯著。但在構(gòu)建軟件的過程中，有更多需要人和專業(yè)經(jīng)驗的場景，來解決復(fù)雜的問題。比如軟件系統(tǒng)日益增加的架構(gòu)復(fù)雜度和范圍，應(yīng)付市場和業(yè)務(wù)側(cè)的需求，跨角色之間的溝通和協(xié)作，還有那些更加時髦的涉及代碼倫理和安全的問題。

雖然判斷程序員是否足夠?qū)I(yè)和熟練，不像數(shù)數(shù)那樣一目了然，但我們也可以說，引入AI 和代碼助手然后減員開發(fā)團隊，能帶來的成效是不確定的，目前看弊大于利。

寫在最后

生成式 AI 的本質(zhì)是模式轉(zhuǎn)換，從文字的一種形式，轉(zhuǎn)換成另一種形式，高級的代碼助手的能力也不出其右。如果把涉足軟件構(gòu)建的 AI 代碼助手，認(rèn)為是解決諸多軟件工程難題的妙方，我們恐怕只是把復(fù)雜的問題想得過于簡單。

寫到這里，我們一直在談什么呢。

我們在談的其實是，在軟件開發(fā)上投資 AI 的成效該如何衡量。投資 AI 并不是簡單如購買代碼助手的 License，然后就可以坐享降本增效。不斷詢問“我們要如何衡量投資 AI 和代碼助手的效果？”，不如詢問“我們到底要衡量什么？”。從DORA 定義的四個關(guān)鍵指標(biāo)開始，是個明智的選擇，它們是變更前置時間、部署頻率、平均恢復(fù)時間 （MTTR） 和變更失敗率。

下面是建議的一些基本衡量原則：

• 衡量團隊效率，而不是個人績效。
• 衡量成效而不是產(chǎn)出。
• 查看隨時間推移的趨勢，而不是比較不同團隊的絕對值。
• 用儀表板上的數(shù)據(jù)開啟對話，而不是就此結(jié)束。
• 衡量有用的東西，而不是容易衡量的東西。