作者 |張凱峰.
策展 |凌敏.
長期以來，軟體行業一直在降低成本和提高效率。 龐大的開發周期，無望的發布時間，以及不斷湧現的缺陷，都配不上這支精英團隊。 生成式AI似乎帶來了曙光，其表現令人耳目一新，很多人會這麼認為：生成式AI可以自動生成**，成本低，可重複，也就是說，丟擲的能力就像雲上的資源一樣。 這是否意味著不需要那麼多精銳士兵？
生成式人工智慧偶爾會為我們的問題丟擲乙個險惡的答案，但如果你稍微搜尋一下，答案是不費吹灰之力的：它要麼不存在，要麼是無稽之談，這與人工智慧的聲望不符。 這就是所謂的生成式人工智慧的幻覺，它拼湊出乙個虛假的答案，因為沒有真實可靠的語料庫。
大型模型技術仍在更新中，人們感知幻覺的程度正在逐漸下降。 但是，當它被投入到特定的領域和用例中時，幻覺效應仍在發生。 在這篇文章中，我將分享生成式人工智慧在軟體開發中的應用，以及它帶來的三種幻覺。
不同的軟體工具供應商正在迭代他們的助手產品，最著名的是 GitHub 的 Copilot，它聲稱可以將程式設計師完成任務的速度提高 55% 以上，而這些清晰的演示看起來就像在飛翔。
但這是否意味著軟體的交付速度可以提高 50%？
那些用作演示的程式設計師是可疑的，越來越多的程式設計師在他們自己的專案中採用 Copilot 的反饋似乎表明，加速大多只出現在少數常用的功能實現中。 例如，對陣列進行排序、初始化資料結構或一些簡單的模板。
可重複的工具**留給 AI。 但是對於乙個正在開發的軟體，有多少類似的**需要重新開發？恐怕這值得討論。 更不用說大多數時候，它們只需要模塑一次，包裝即可使用。 還有相當大的業務量**，程式設計師會以多快的速度完成？您可以將足夠數量的業務**交給 AI 進行生成，但安全性可能是乙個更大的問題。
這裡還有另外兩個問題需要關注。
一是程式設計師是人工智慧的最佳選擇。 人工智慧非常容易實現多套方法，以至於程式設計師不可避免地不得不嘗試找出其中的最佳選擇。
這很好？或者這樣好嗎？嘿，有五種不同的實現。 在切換到下乙個實現之前，您需要閱讀每個實現。 這種實現很優雅，但不幸的是，單元測試失敗了。 替換下乙個。程式設計師的好奇心被**助手充分激起了。 心是猿，線性思維習慣被打破了。 程式設計師忘記的不僅僅是開發規則，而是時間。
二是軟體自身的生命週期。
顯然，當輪到程式設計師開始編寫時，已經發生了很多事情，在系統上線之前，還會有更多事情發生。 這些事情包括但不限於：收集需求、理解需求（從需求描述到使用者故事）、測試、維護基礎結構以及那些正在進行的修復。
我的意思是，無論人工智慧幫助程式設計師編寫的速度有多快，這個階段都只是軟體生命週期的一部分。 據統計，程式設計師每天只花30%的時間在寫作上，更多的時間試圖理解他們想要實現什麼功能，以及設計和學習新技能。
人寫的**難免會有缺陷，這是軟體質量的基本共識。 而且似乎程式設計師越有經驗，就越有可能產生需要很長時間才能發現的晦澀難懂的問題。 網路問題更可怕，但這種擔憂是難以避免的。
AI生成的**，聽起來也很高階，它會帶來足夠完美的結果嗎？不幸的是，答案可能令人失望。
生成式AI背後的大模型是基於網際網絡上大量的語料庫**，儘管大模型的技術一直在改進，但網路上已經存在的有偏見的資料量是相當大的。 這也包括大量的缺陷品。 這意味著程式設計師在助手中挑選的內容也可能有缺陷。 因為這個有缺陷的**，來自世界另一端的人可能恰好是地球這一邊的選擇。
可悲的是，生成式人工智慧具有放大器的力量。 簡而言之，如果程式設計師使用有缺陷的構建，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 **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. ）
程式設計師應該嚴格遵守團隊的開發紀律，保持一致的**規範，因為這樣別人就可以閱讀它，並且更容易發現潛在的問題並修復它。 但助手提供的不同似乎也帶來了更多的混亂。
*有缺陷，但只是其中的乙個問題，軟體最終會爆發成無法挽回的問題**，哪怕是一小部分。 構建軟體的過程實際上是知識生產和創造的過程。 在軟體生命週期不同階段加入的角色，共同理解和分析軟體的需求，然後轉化為第乙個需求，並在團隊和人員流動的過程中傳達這些膚淺的需求和知識資訊。
但通常情況下，知識會衰減，知識資產的交付不可避免地會導致池子的貧乏。 例如，我看不懂**，我不能一直更新文件，整個團隊被替換，等等。 這些是軟體不斷產生錯誤和問題的原因。 人工智慧一直無法解決軟體工程中的這些棘手問題，至少在短期內無法解決。
人工智慧的助手看起來確實像訊息靈通的程式設計師。 有些人甚至願意將其視為結對程式設計實踐中的合作夥伴。 招聘人員的成本一直是 IT 團隊頭疼的問題，因為好人太貴了，找不到合適的人，而且從頭開始培訓熟練的程式設計師需要很長時間。 有了人工智慧和**助手的加持，是不是意味著一半的人可以縮小規模？
人工智慧和助手不僅不能提供上述速度和高質量的保證，還期望使用者有足夠的經驗豐富的程式設計師來充分發揮他們的優勢。 這個有經驗的程式設計師需要具備判斷**的優缺點的能力，判斷對現有生產的影響**，也需要有耐心和技巧去仔細調整提示詞。
在這篇文章中，作者談到了她在使用**助手時需要注意的諸多問題，以及她一絲不苟的內心戲。因為助手帶來的不確定性，可能會造成兩類風險，一類是影響第一類的質量，二類是浪費時間。 這裡展示的是乙個足夠有經驗的程式設計師的內省。
只有這樣，助理才能安心地扮演訊息靈通的新手，而經驗豐富的程式設計師則充當守門員，而她是負責提交的人。 通過這種方式，人工智慧正在改變程式設計體驗。
作者將助手想象成乙個急於幫忙、固執、說話清晰但缺乏經驗的角色，所以他用AI畫了這個**形象）。
人工智慧和助手可以有效地解決簡單和重複的問題。 但是在構建軟體的過程中，有更多的場景需要人員和專業知識來解決複雜的問題。 例如，軟體系統的架構複雜性和範圍不斷增加，對市場和業務需求的響應，跨角色的溝通和協作，以及更時尚的道德和安全問題。
雖然判斷乙個程式設計師是否足夠專業和熟練還不如計數那麼明顯，但我們也可以說，引入AI和助手再減少開發團隊的結果是不確定的，目前弊大於利。
生成式AI的本質是模式轉換，從一種形式的文字到另一種形式的文字，高階助手的能力也是無與倫比的。 如果我們將涉足軟體構建的人工智慧助手視為許多軟體工程挑戰的解決方案，那麼我們只是將複雜的問題視為過於簡單化。
在這一點上，我們在談論什麼？
我們真正談論的是如何衡量在軟體開發中投資人工智慧的有效性。 投資人工智慧並不像購買助手許可證，然後坐下來降低成本和提高效率那麼簡單。 不斷問，“我們如何衡量投資人工智慧和助手的有效性？而不是問，“我們到底要測量什麼？”。從 DORA 定義的四個關鍵指標開始是乙個明智的主意：變更提前期、部署頻率、平均恢復時間 （MTTR） 和變更失敗率。
以下是一些基本的測量原則供參考：
衡量團隊效率，而不是個人績效。 衡量結果，而不是輸出。 檢視隨時間推移的趨勢，而不是比較不同團隊的絕對值。 使用儀表板上的資料開始對話，而不是就此結束。 衡量有用的東西，而不是容易衡量的東西。 原文鏈結：生成式AI給軟體開發帶來的三大錯覺：速度、高質量、人少 生成式AI 張凱峰 InfoQ 專題文章。