作者 | 張凱峰

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

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

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

幻覺一：更快的速度

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

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

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

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

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

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

這里還有兩個問題值得關注。

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

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

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

程序員的好奇心被代碼助手充分攪動。心猿意馬，線性的思維習慣碎落一地。程序員遺忘的不只是開發紀律，還有時間。

二是軟件自有生命周期。

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

我的意思是說，即便AI 幫助程序員寫得再快，這個階段也只是軟件生命周期中的一部分而已。早有相關的數據統計，程序員日常的工作，只有 30%的時間是在編寫代碼，而更多的時間是在嘗試理解他們要實現什么功能，以及設計和學習新技能上。

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

幻覺二：更少的 Bug

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

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

生成式 AI 背后的大模型，以互聯網上大量的語料作為數據來源，盡管大模型技術一直在改善，但網絡上已經現實存在的帶有偏見的數據量十分可觀。這也包括大量飽含缺陷的代碼。

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

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

（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. ）

程序員要嚴守團隊的開發紀律，保持統一的代碼規范，因為這樣別人才能讀懂，也意味著更容易發現潛在問題并修復它。但代碼助手提供的不同樣貌的代碼，似乎也提供了更多的混亂。

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

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

幻覺三：更少的人

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

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

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

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

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

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

雖然判斷程序員是否足夠專業和熟練，不像數數那樣一目了然，但我們也可以說，引入AI 和代碼助手然后減員開發團隊，能帶來的成效是不確定的，目前看弊大于利。

寫在最后

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

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

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

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

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