作者丨Boris Tane

譯者丨明知山

策劃丨Tina

AI 智能體并不是讓軟件開發(fā)生命周期變得更快，而是直接終結(jié)了它。

我經(jīng)常聽到人們把 AI 稱為“10 倍開發(fā)者工具”，這種定位是錯(cuò)誤的。這種觀點(diǎn)假設(shè)開發(fā)流程不變，AI 只是提升了速度，但事實(shí)并非如此。整個(gè)開發(fā)生命周期——那個(gè)我們賴以建立職業(yè)生涯、催生出數(shù)百億產(chǎn)業(yè)的體系——正在崩塌。

而大多數(shù)人尚未察覺。

你所了解的 SDLC 已成為過去

這是我們大多數(shù)人學(xué)過的經(jīng)典軟件開發(fā)生命周期：

每個(gè)階段都有對(duì)應(yīng)的工具、流程和配套產(chǎn)業(yè)：Jira 管需求、Figma 做設(shè)計(jì)、VS Code 寫代碼、Jest 做測(cè)試、GitHub 審代碼、AWS 管部署、Datadog 做監(jiān)控。

每一步都是離散、按序執(zhí)行的，交接無(wú)處不在。

而現(xiàn)在，工程師使用編程智能體時(shí)真實(shí)發(fā)生的卻是：

開發(fā)階段徹底崩塌了。它們不是變快了，而是徹底融合。智能體并不清楚自己處于哪一步，因?yàn)楦揪蜎]有步驟，只有意圖、上下文與迭代。

AI 原生工程師

不知道什么是 SDLC

我花了很多時(shí)間與那些在 Cursor 出現(xiàn)后才開啟職業(yè)生涯的工程師交流。他們不知道什么是軟件開發(fā)生命周期，也不知道什么是 DevOps，什么是 SRE。這并非因?yàn)樗麄儾粔騼?yōu)秀，而是他們從不需要這些。他們從未做過敏捷規(guī)劃，從未估算過故事點(diǎn)，也從未為等待 PR 審核而苦等三天。

他們只管把東西做出來。

你說出需求，智能體編寫代碼，你查看、迭代、發(fā)布，所有環(huán)節(jié)同步推進(jìn)。

這些工程師并沒有因?yàn)槭∪シ蔽目d節(jié)而變得平庸，反而因此掙脫了束縛。沖刺規(guī)劃、代碼審核流程、發(fā)布節(jié)奏、估算儀式——全都沒有。他們跳過了整套所謂的正統(tǒng)流程，直接動(dòng)手構(gòu)建。

說實(shí)話，我很羨慕。

每個(gè)階段都在崩塌

讓我?guī)е阒匦聦徱?SDLC，看看它還剩下什么。

需求收集：靈活流動(dòng)，而非硬性規(guī)定

在過去，需求是自上而下傳遞的。產(chǎn)品經(jīng)理撰寫 PRD，工程師進(jìn)行評(píng)估，規(guī)范在編碼開始前就已凍結(jié)。這在構(gòu)建成本高昂的年代是合理的——當(dāng)每個(gè)功能都需要數(shù)周時(shí)間才能完成時(shí)，你必須提前確定要做什么。

這種限制已經(jīng)不復(fù)存在。當(dāng)智能體能在幾分鐘內(nèi)生成一個(gè)完整的功能時(shí)，你無(wú)需提前定義每一個(gè)細(xì)節(jié)。你只需要給出方向，智能體構(gòu)建出一個(gè)版本，你再進(jìn)行評(píng)審、調(diào)整和嘗試不同的方案。你可以生成十個(gè)版本，然后從中選擇最優(yōu)的一個(gè)。需求不再是一個(gè)獨(dú)立階段，而是迭代過程的副產(chǎn)品。

那么，當(dāng)協(xié)作對(duì)象不再是需要跨流程溝通的人，而是能直接理解上下文的智能體時(shí)，Jira 成了什么？它不過是在追蹤那些早已不復(fù)存在的階段工作。如果你的“需求”只是喂給智能體的上下文，那么工單系統(tǒng)就不再是項(xiàng)目管理工具，而是一個(gè)上下文存儲(chǔ)庫(kù)——而且是一個(gè)極其糟糕的存儲(chǔ)庫(kù)。

系統(tǒng)設(shè)計(jì)：在實(shí)踐中探索，而非事先規(guī)定

系統(tǒng)設(shè)計(jì)依然重要，但其實(shí)現(xiàn)方式正在發(fā)生根本性轉(zhuǎn)變。

設(shè)計(jì)曾經(jīng)是編碼前的必經(jīng)步驟：你在白板上勾勒架構(gòu)、探討各類取舍、繪制方框與箭頭，然后動(dòng)手實(shí)現(xiàn)。設(shè)計(jì)與編碼之間相隔數(shù)天甚至數(shù)周。

這個(gè)差距正在縮小。設(shè)計(jì)不再是提前定好的方案，而是通過為智能體提供恰當(dāng)上下文在交互中逐步探索出來的結(jié)果。模型見過的系統(tǒng)、架構(gòu)與設(shè)計(jì)模式遠(yuǎn)超任何一位工程師。當(dāng)你描述問題時(shí)，智能體不只是實(shí)現(xiàn)你的設(shè)計(jì)，還會(huì)給出往往比你獨(dú)自思考更優(yōu)秀的架構(gòu)。你們實(shí)時(shí)進(jìn)行設(shè)計(jì)對(duì)話，最終直接輸出可運(yùn)行的代碼。

你仍然需要判斷智能體是否存在過度設(shè)計(jì)或遺漏了約束條件。但你們是在協(xié)作完成設(shè)計(jì)，而不是由你單方面規(guī)定方案。

實(shí)現(xiàn)：現(xiàn)在是智能體的工作

這一點(diǎn)顯而易見。智能體直接編寫代碼——完整的功能，包含錯(cuò)誤處理、類型定義與邊界情況的全套解決方案。

就我個(gè)人而言，我已經(jīng)不認(rèn)識(shí)還在逐行手寫代碼的人了。我們審核智能體生成的內(nèi)容，為它提供上下文、把控方向，只專注于真正需要人類判斷的問題。

測(cè)試：并行進(jìn)行，而非串行

智能體會(huì)在編寫代碼的同時(shí)完成測(cè)試，而非事后補(bǔ)充，也不存在單獨(dú)的“測(cè)試階段”。測(cè)試是生成過程的一部分。TDD 不再只是一種方法論，而是智能體默認(rèn)的工作方式。

原本獨(dú)立的 QA 階段已經(jīng)徹底消失。當(dāng)代碼與測(cè)試一同生成、一同驗(yàn)證、一同迭代時(shí)，就不再有交接環(huán)節(jié)，沒有“拋給 QA”這回事。智能體本身就能完成 QA 工作。

代碼評(píng)審：沒必要再做了

PR 流程早已該被淘汰。我從來都不認(rèn)同這套模式，而如今它更是成了過去時(shí)代的遺留產(chǎn)物。

我知道這會(huì)讓人難以接受。代碼評(píng)審向來被視為金科玉律，是你發(fā)現(xiàn)漏洞、傳遞知識(shí)、守住標(biāo)準(zhǔn)的方式，也是一種身份認(rèn)同——我們是工程師，評(píng)審代碼本就是工程師該做的事?？稍谥悄荏w驅(qū)動(dòng)的世界里，死守 PR 流程并非嚴(yán)謹(jǐn)，而是一種身份危機(jī)。

想想看，一個(gè)智能體一天能生成 500 個(gè) PR，而你的團(tuán)隊(duì)可能只能審核 10 個(gè)。審核隊(duì)列只會(huì)不斷積壓。這根本不是值得優(yōu)化的瓶頸，而是偽瓶頸——只是我們把人類的工作儀式，強(qiáng)行套在了機(jī)器的工作流程上。

這樣的流程根本不該存在，整套模式都已經(jīng)過時(shí)了。

評(píng)審機(jī)制必須被重新審視。它要么成為代碼生成的一部分——由智能體依據(jù)設(shè)計(jì)文檔自檢、運(yùn)行測(cè)試、排查回歸、驗(yàn)證架構(gòu)約束，要么由第二個(gè)智能體評(píng)審前者的輸出。對(duì)抗式智能體檢驗(yàn)變更邏輯，嘗試從各個(gè)維度進(jìn)行破壞。我們已經(jīng)有這些工具了。人類評(píng)審將變成例外處理，只有在自動(dòng)驗(yàn)證無(wú)法解決沖突或變更涉及真正創(chuàng)新的內(nèi)容時(shí)才介入。

沒有 PR 的世界會(huì)是什么樣子？智能體直接提交到主分支，自動(dòng)執(zhí)行檢查、測(cè)試、類型校驗(yàn)、安全掃描、行為差異驗(yàn)證。如果全部通過，就自動(dòng)發(fā)布；如果不通過，由智能體自行修復(fù)。只有當(dāng)系統(tǒng)確實(shí)無(wú)法處理時(shí)，人類才會(huì)介入。

我們把評(píng)審時(shí)間浪費(fèi)在查看智能體幾秒就能驗(yàn)證的代碼變更上，這不是質(zhì)量保證，這是盧德主義。

部署：解耦且持續(xù)的

智能體已經(jīng)在構(gòu)建比大多數(shù)團(tuán)隊(duì)手工打造的、更復(fù)雜、更專業(yè)的部署流水線。功能開關(guān)、金絲雀發(fā)布、漸進(jìn)式推出、自動(dòng)回滾觸發(fā)機(jī)制——這些過去需要專業(yè)平臺(tái)團(tuán)隊(duì)才能實(shí)現(xiàn)的發(fā)布工程能力，如今智能體都能完成。

關(guān)鍵轉(zhuǎn)變?cè)谟谥悄荏w天然地將部署與發(fā)布解耦。代碼持續(xù)部署，每一個(gè)變更在生成并驗(yàn)證后都會(huì)生成可進(jìn)入生產(chǎn)環(huán)境的工件，并隱藏在開關(guān)之后。發(fā)布則是獨(dú)立的決策，由功能開關(guān)或流量規(guī)則來驅(qū)動(dòng)。

一些團(tuán)隊(duì)已經(jīng)在接近真正意義上的持續(xù)部署與發(fā)布。代碼生成、測(cè)試通過、制品構(gòu)建、變更上線，全程自動(dòng)化，從需求構(gòu)思到上線生產(chǎn)無(wú)需人工介入。

下一步會(huì)更有趣。想象一下，智能體不僅負(fù)責(zé)部署代碼，還能管理整個(gè)發(fā)布生命周期：監(jiān)控發(fā)布進(jìn)程、根據(jù)錯(cuò)誤率調(diào)整流量比例、延遲飆升時(shí)自動(dòng)回滾，只在出現(xiàn)全新問題時(shí)才通知人類。所謂的部署“階段”不只是自動(dòng)化，而是演變成一個(gè)持續(xù)、自我調(diào)節(jié)的過程，永遠(yuǎn)不會(huì)結(jié)束。

監(jiān)控：唯一幸存的階段，

而且需要進(jìn)化

監(jiān)控是 SDLC 唯一幸存的階段，它不僅僅是幸存了下來，更成為一切的基礎(chǔ)。

當(dāng)智能體發(fā)布代碼的速度遠(yuǎn)超人工審核時(shí)，可觀測(cè)性就不再是可有可無(wú)的儀表盤，而是整個(gè)研發(fā)生命周期的核心安全機(jī)制。以往的所有保障手段——設(shè)計(jì)評(píng)審、代碼審核、QA 階段、發(fā)布審批——要么被整合，要么被淘汰。監(jiān)控成了唯一的留存，也是最后一道防線。

但大多數(shù)可觀測(cè)性平臺(tái)都是為人類設(shè)計(jì)的。告警、日志檢索、儀表盤——全都面向人類的查看、解讀與操作。當(dāng)變更速度超出人類所能跟上的范圍，這個(gè)模式就會(huì)徹底失效。如果一個(gè)智能體一天發(fā)布 500 次變更，而你的可觀測(cè)系統(tǒng)還需要人工排查每一個(gè)異常，你就制造了新的瓶頸——只是把瓶頸從代碼審核轉(zhuǎn)移到了故障響應(yīng)。

沒有實(shí)際行動(dòng)的可觀測(cè)性只是昂貴的存儲(chǔ)消耗?？捎^測(cè)性的未來不在于儀表盤，而在于閉環(huán)系統(tǒng)——遙測(cè)數(shù)據(jù)會(huì)成為代碼發(fā)布智能體的上下文，讓它能夠自動(dòng)檢測(cè)并修復(fù)問題。

可觀測(cè)性將成為驅(qū)動(dòng)整個(gè)閉環(huán)的反饋機(jī)制，它不再是最后一個(gè)環(huán)節(jié)，而是整個(gè)系統(tǒng)的核心紐帶。

率先想明白這一點(diǎn)的團(tuán)隊(duì)——讓可觀測(cè)性直接反饋給智能體循環(huán)，而不是推送到人類的告警設(shè)備——將能更快、更安全地持續(xù)發(fā)布。沒能理解的團(tuán)隊(duì)，只會(huì)淹沒在無(wú)窮無(wú)盡的告警里。

新的生命周期是一個(gè)更緊湊的循環(huán)

傳統(tǒng)的 SDLC 是一個(gè)寬松的大循環(huán)：需求→設(shè)計(jì)→編碼→測(cè)試→審核→部署→監(jiān)控。它是線性、串行的，交接與等待無(wú)處不在。

新的生命周期是一個(gè)更緊湊的循環(huán)。

意圖。構(gòu)建。觀察。重復(fù)。

沒有工單。沒有沖刺。沒有故事點(diǎn)。沒有排隊(duì)等待的 PR。沒有獨(dú)立的 QA 階段。沒有發(fā)布火車。

只有明確意圖的人類和執(zhí)行任務(wù)的智能體。

那么還剩下什么？

上下文，就這些。

你用智能體構(gòu)建出的產(chǎn)品質(zhì)量與你提供給它們的上下文質(zhì)量直接成正比。決定結(jié)果的不是流程，不是形式，而是上下文。

SDLC 已死。新的核心能力是上下文工程，新的安全防線是可觀測(cè)性。

而行業(yè)里的大多數(shù)人，還在配置著沒人去看的 Datadog 儀表盤。

https://boristane.com/blog/the-software-development-lifecycle-is-dead/

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