作者 | Pierre Pureur, Kurt Bittner

譯者 | 明知山

AI 正逐漸成為軟件開發(fā)的強(qiáng)大工具。在 之前的文章 中，我們介紹了幾種 AI 助力團(tuán)隊(duì)構(gòu)建軟件架構(gòu)的方式。當(dāng)團(tuán)隊(duì)不再滿足于將 AI 僅作為頭腦風(fēng)暴的輔助工具，而是進(jìn)一步用它來生成 最小可行架構(gòu)（MVA） 的實(shí)現(xiàn)代碼時，架構(gòu)設(shè)計工作的本質(zhì)也將隨之發(fā)生實(shí)質(zhì)性改變。

軟件架構(gòu)關(guān)乎決策，但 AI 生成的代碼卻是黑盒

“任何足夠先進(jìn)的技術(shù)都與魔法無異。” ——Arthur C. Clarke

AI 的代碼生成能力有時看上去近乎神奇，但也隨之帶來一個難題：我們無法真正看清或理解 AI 為何生成某段代碼——這是模型本身的工作機(jī)制決定的。團(tuán)隊(duì)可以借助 AI 為 MVP 生成代碼，而這一過程會隱式地做出關(guān)于 MVA 的相關(guān)決策。在此過程中，團(tuán)隊(duì)需要考慮以下幾個架構(gòu)問題：

1. 當(dāng) AI 生成 MVP 時，團(tuán)隊(duì)無法控制 AI 做出的架構(gòu)決策。他們或許可以就部分決策向 AI 詢問，但大量決策依然是不透明的，因?yàn)?AI 并不理解它所學(xué)習(xí)的代碼為何要那樣設(shè)計。這與我們 之前的文章 中討論過的框架問題類似：框架會替你做出決策，但你并不總能知曉這些決策具體是什么。

2. 從開發(fā)團(tuán)隊(duì)的角度來看，AI 生成的代碼在很大程度上就是一個黑盒；即便能夠理解，也沒人有足夠的時間去逐一梳理。軟件開發(fā)團(tuán)隊(duì)本就面臨巨大的時間壓力，他們借助 AI 來部分緩解這種壓力，卻也同時抬高了業(yè)務(wù)方對生產(chǎn)力的預(yù)期。如此一來，開發(fā)團(tuán)隊(duì)反而更沒有時間去理解 AI 在代碼生成過程中所做出的架構(gòu)決策。

3. 從某種意義上說，AI 就像一座生產(chǎn)技術(shù)債務(wù)的工廠，和我們遇到的幾乎所有技術(shù)債務(wù)一樣，它往往只有在出現(xiàn)問題時才會被“償還”。AI 生成的代碼本身并非為可維護(hù)性而設(shè)計，最終也只能靠更多的 AI 生成代碼來替換。這就引出了一個關(guān)于系統(tǒng)可持續(xù)性的開放性問題：團(tuán)隊(duì)寄希望于未來的 AI 編碼引擎，能用更優(yōu)質(zhì)、更可持續(xù)的代碼來替換現(xiàn)有代碼。

能體現(xiàn)這三類挑戰(zhàn)的一個典型場景是：AI 生成的代碼需要以滿足 QAR（質(zhì)量屬性需求，如安全需求）的方式與現(xiàn)有系統(tǒng)對接。在可預(yù)見的未來，AI 生成的代碼始終需要與現(xiàn)有系統(tǒng)集成，而這種集成通常通過 API 完成。開發(fā)團(tuán)隊(duì)必須確保整個系統(tǒng)體系的質(zhì)量屬性需求依然能夠得到滿足。

評估 AI 生成的黑盒的行為的唯一方法是實(shí)驗(yàn)

正如我們在之前的 文章 中所探討的，團(tuán)隊(duì)需要回答關(guān)于其架構(gòu)的三個問題；使用 AI 并不會改變這一點(diǎn)，盡管它能幫助他們更快地評估這些問題：

• 成本最高、也最需要優(yōu)先考慮的決策，是開發(fā)一款本身就不值得開發(fā)的產(chǎn)品。借助 AI 生成（全部或部分）解決方案能夠幫助團(tuán)隊(duì)更高效、更省力地通過 MVP 驗(yàn)證客戶需求。

• 如果產(chǎn)品值得開發(fā)，那么代價第二高的決策就是構(gòu)建出性能不足、無法按業(yè)務(wù)場景擴(kuò)展的系統(tǒng)。AI 雖能幫助團(tuán)隊(duì)更快得到可實(shí)測的設(shè)計，但一旦方案無法擴(kuò)展或性能不佳，團(tuán)隊(duì)只能讓 AI 重新生成其他方案。如果到最后所有生成的方案都無法滿足 QAR，他們就只能手動構(gòu)建解決方案，而此時已經(jīng)浪費(fèi)了大量時間在評估那些被否決的方案上，甚至可能已經(jīng)破壞了整個業(yè)務(wù)可行性。

• 在這些問題都得到滿足后，接下來最關(guān)鍵的決策便與生命周期成本相關(guān)——即如何讓系統(tǒng)在整個生命周期內(nèi)具備可維護(hù)性與可支撐性，而這正是 AI 生成方案最容易出現(xiàn)問題的地方。和我們用過的所有代碼生成工具一樣，AI 生成的代碼并非為可維護(hù)性而設(shè)計，一旦出錯或失效，就只能通過新的提示詞（或用原有提示詞搭配新模型）重新生成。

對 AI 生成的系統(tǒng)進(jìn)行面向 QAR 的實(shí)證測試，或許才是真正理解 AI 生成架構(gòu)適用性的唯一方法。架構(gòu)設(shè)計的關(guān)鍵在于判斷哪些 QAR 對系統(tǒng)架構(gòu)影響最大。團(tuán)隊(duì)永遠(yuǎn)沒有足夠的時間測試所有內(nèi)容，因此明確測試重點(diǎn)至關(guān)重要。

AI 將架構(gòu)設(shè)計的重心轉(zhuǎn)向了如何驗(yàn)證架構(gòu)

團(tuán)隊(duì)需要培養(yǎng)新的技能與洞察力來應(yīng)對這一挑戰(zhàn)。一些傳統(tǒng)技術(shù)，例如架構(gòu)評審、代碼審查與檢查、安全評審等，在面對大量 AI 生成代碼時既不現(xiàn)實(shí)也低效。利用 AI 來審查代碼或許是一種可行方案，但由于 AI 生成的代碼本身并非為直接維護(hù)而設(shè)計，代碼審查對其作用其實(shí)十分有限。

因此，架構(gòu)工作的性質(zhì)將從前期設(shè)計轉(zhuǎn)向?qū)?QAR 的實(shí)證評估，也就是對 MVA 進(jìn)行驗(yàn)收測試。在這一轉(zhuǎn)變過程中，開發(fā)團(tuán)隊(duì)需要協(xié)助業(yè)務(wù)方明確 MVP 的測試與評估方式。相應(yīng)地，開發(fā)團(tuán)隊(duì)必須大幅提升對系統(tǒng)架構(gòu)進(jìn)行實(shí)證測試的能力。以下是可用于此目的的部分技術(shù)列表：

• 性能和可擴(kuò)展性測試，重點(diǎn)關(guān)注系統(tǒng)滿足其 QAR 的程度。

• 可用性測試，用于評估用戶完成特定任務(wù)的有效性，確保系統(tǒng)易用且高效。

• 變更案例，包括直接影響 QAR 的架構(gòu)變更案例，以及間接影響 QAR 的“功能”變更案例。

• 道德黑客測試，采用與黑客相同的工具對系統(tǒng)進(jìn)行探測，在惡意攻擊者利用漏洞前發(fā)現(xiàn)安全隱患。

• Chaos Monkey——Netflix 開發(fā)的開源工具，用于幫助發(fā)現(xiàn)并修復(fù)系統(tǒng)漏洞。它會隨機(jī)終止生產(chǎn)環(huán)境中的虛擬機(jī)實(shí)例與服務(wù)，以此測試系統(tǒng)的彈性。

對包含 AI 生成代碼的系統(tǒng)進(jìn)行測試變得愈發(fā)重要，測試重心需要從功能測試轉(zhuǎn)向架構(gòu)測試。在此過程中，開發(fā)團(tuán)隊(duì)需要找到并應(yīng)用能盡可能自動化這些測試手段的工具。

軟件架構(gòu)仍然是關(guān)于決策和權(quán)衡

使用 AI 生成 MVA 并不會改變軟件架構(gòu)的基本邏輯：團(tuán)隊(duì)仍然需要對權(quán)衡做出決策。團(tuán)隊(duì)需要清楚可能存在哪些權(quán)衡，并在給 AI 的提示詞中明確表述這些權(quán)衡。此時，AI 就像一個智能搜索引擎，去尋找能平衡這些權(quán)衡的解決方案。如前所述，這些方案仍需經(jīng)過實(shí)證評估，但確實(shí)能為團(tuán)隊(duì)節(jié)省探索潛在方案的時間。

我們將這種方法稱為 “Caveat Prompter”，你必須先理解問題與設(shè)計權(quán)衡，否則無法向 AI 提供足夠信息，也就無法生成優(yōu)質(zhì)結(jié)果。這意味著團(tuán)隊(duì)在編寫 AI 提示詞時，需要明確權(quán)衡點(diǎn)與替代方案，讓 AI 能在生成的代碼中體現(xiàn)這些考量。

結(jié)論

AI 生成的代碼是否會終結(jié)軟件架構(gòu)？答案是否定的。團(tuán)隊(duì)依然需要做出架構(gòu)決策與權(quán)衡，但必須更清晰地闡述這些權(quán)衡及其背后的邏輯，才能在提示詞中把這些思路傳遞給 AI。

然而，與任何技術(shù)一樣，AI 在解決部分問題的同時，也帶來了新的挑戰(zhàn)。如果開發(fā)團(tuán)隊(duì)依賴 AI 生成代碼來打造成功的 MVP 和 MVA，其實(shí)是在進(jìn)行一場危險的博弈——他們交付的系統(tǒng)可能在未來某個時刻崩潰，而自身卻無力修復(fù)。更糟的是，AI 生成代碼的質(zhì)量可能會隨時間下降，新模型更容易出現(xiàn)靜默卻致命的故障模式，因?yàn)樗鼈兪怯帽扰f模型質(zhì)量更差的代碼（通常本身就是 AI 生成的）訓(xùn)練出來的。這會讓團(tuán)隊(duì)越來越難以改進(jìn)依賴 AI 生成代碼的系統(tǒng)。

除了將軟件架構(gòu)的重心轉(zhuǎn)向?qū)嵶C驗(yàn)證外，團(tuán)隊(duì)還需要從新的角度思考可維護(hù)性：當(dāng) AI 的行為可能發(fā)生變化，甚至完全無法使用時，他們未來是否還能支撐這套系統(tǒng)？

https://www.infoq.com/articles/ai-generated-mvp/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。