我經(jīng)常聽到人們把 AI 描述為“10x 開發(fā)工具”。這種說法是錯(cuò)誤的。它假設(shè)工作流保持不變，速度會(huì)提升。但事實(shí)并非如此。整個(gè)生命周期，我們圍繞它建立職業(yè)生涯、并催生了一個(gè)數(shù)十億美元的工具行業(yè)的那個(gè)生命周期，正在自我崩塌。

而大多數(shù)人還沒有注意到。

1、你學(xué)到的 SDLC 已成遺物

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

每個(gè)階段都有自己的一套工具、儀式和小型行業(yè)。需求用 Jira。設(shè)計(jì)用 Figma。實(shí)現(xiàn)用 VS Code。測試用 Jest。代碼評審用 GitHub。部署用 AWS。Datadog 用于監(jiān)控。

每一步都是離散的。按順序執(zhí)行。處處都有交接。

現(xiàn)在來看，當(dāng)工程師與編碼代理一起工作時(shí)，實(shí)際發(fā)生了什么：

graph TD    A[Intent] --> B[Agent]    B --> C[Code + Tests + Deployment]    C --> D{Does it work?}    D -->|No| B    D -->|Yes| E[Ship]    style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46

階段崩塌了。它們并沒有變得更快。它們合并了。代理不知道自己處在第幾個(gè)步驟，因?yàn)闆]有步驟。只有意圖、上下文和迭代。

2、AI 原生工程師不知道 SDLC 是什么

我花了大量時(shí)間與 Cursor 推出后才開始職業(yè)生涯的工程師交談。他們不知道軟件開發(fā)生命周期是什么。不知道 DevOps 是什么，SRE 又是什么。不是因?yàn)樗麄兪窃愀獾墓こ處煛Ｒ驗(yàn)樗麄儚奈葱枰^它。他們從未參與過沖刺計(jì)劃。他們從未估算故事點(diǎn)。他們也從未等過 PR 審查三天。

他們只是去構(gòu)建東西。

你描述你想要的。代理寫出代碼。你查看。你迭代。你交付。所有事情同時(shí)進(jìn)行。

這些工程師并不是因?yàn)樘^儀式而更糟。他們不受束縛。沖刺計(jì)劃、代碼評審工作流、發(fā)布列車、估算儀式。全部都沒有。他們繞開了整套正統(tǒng)性，直接進(jìn)入構(gòu)建階段。

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

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

讓我?guī)阕哌^ SDLC，看看它還剩下什么。

3.1 需求收集：靈活的，而非被規(guī)定

過去，需求往往由上而下傳達(dá)。項(xiàng)目經(jīng)理寫 PRD，工程師進(jìn)行估算，規(guī)格在寫第一行代碼前就被凍結(jié)。當(dāng)時(shí)開發(fā)成本很高。每個(gè)功能需要數(shù)周時(shí)間，你必須提前決定要構(gòu)建什么。

現(xiàn)在，這種約束已經(jīng)消失了。當(dāng)一個(gè)代理能在幾分鐘內(nèi)生成一個(gè)完整版本的功能時(shí)，你不再需要事先指定每一個(gè)細(xì)節(jié)。你給出方向，代理生成一個(gè)版本，你查看、調(diào)整、嘗試另一種方法。你可以生成十個(gè)版本并挑選最佳的一個(gè)。需求不再是一個(gè)階段，而是迭代的副產(chǎn)品。

那么當(dāng)受眾不是人類在協(xié)調(diào)工作流時(shí)，Jira 是什么？當(dāng) Jira 變成讓代理獲取上下文的工具時(shí)，Jira 是什么？Jira 的初衷是跟蹤穿越那些不再存在的階段的工作。如果你的“需求”只是給代理的上下文，那么工單系統(tǒng)就不再是項(xiàng)目管理工具，而是一個(gè)上下文存儲，且很糟糕。

3.2 系統(tǒng)設(shè)計(jì)：發(fā)現(xiàn)，而非被規(guī)定

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

設(shè)計(jì)過去是在編寫代碼之前完成的工作。你會(huì)在白板上勾畫架構(gòu)，爭論權(quán)衡，畫出方框和箭頭，然后去實(shí)現(xiàn)。設(shè)計(jì)與代碼之間的差距曾經(jīng)是天數(shù)甚至是數(shù)周。

這個(gè)差距正在縮小。設(shè)計(jì)正在成為通過給代理提供正確上下文來發(fā)現(xiàn)的過程，而不是你事先規(guī)定的東西。模型已經(jīng)見過比任何個(gè)人工程師都多的系統(tǒng)、架構(gòu)和模式。當(dāng)你描述一個(gè)問題時(shí)，代理不僅實(shí)現(xiàn)你的設(shè)計(jì)，還會(huì)提出通常比你自己想到的架構(gòu)更優(yōu)的方案。你正在進(jìn)行實(shí)時(shí)的設(shè)計(jì)對話，輸出的是可工作的代碼。

你仍然需要知道何時(shí)代理在過度設(shè)計(jì)或錯(cuò)過某些約束。但你是在共同設(shè)計(jì)，而不是在規(guī)定它。

3.3 實(shí)現(xiàn)：現(xiàn)在是代理的工作

這點(diǎn)很明顯。代理寫出代碼。完整的功能。帶有正確處理、類型、邊界情況的完整解決方案。

我個(gè)人認(rèn)識的高質(zhì)量工程師現(xiàn)在幾乎不再敲代碼。我們審查代理寫的內(nèi)容，給它們上下文，指引方向，專注于真正需要人類判斷的問題。

3.4 測試：并行進(jìn)行，而非按順序

代理在編寫代碼的同時(shí)編寫測試。不是事后才寫。也不是在單獨(dú)的“測試階段”中。測試是生成過程的一部分。測試驅(qū)動(dòng)開發(fā)（TDD）不再是一種方法論，而是代理默認(rèn)的工作方式。

整套 QA 作為獨(dú)立階段的功能已經(jīng)消失。當(dāng)代碼與測試一起生成、一起驗(yàn)證、一起迭代時(shí)，就不存在交接。也不再需要“把它扔給 QA”的流程。代理本身就能完成 QA。

3.5 代碼審查：放手吧

拉取請求（PR）流程將不再需要。我曾經(jīng)不是很喜歡它，但現(xiàn)在它只是過去的一個(gè)遺物。

我知道這很不舒服。代碼審查是神圣的。它是你發(fā)現(xiàn)錯(cuò)誤、分享知識、維護(hù)標(biāo)準(zhǔn)的方式。它也是一種身份認(rèn)同。我們是工程師，審查代碼是工程師的職責(zé)。但在一個(gè)由代理驅(qū)動(dòng)的世界里，執(zhí)著于 PR 工作流并不等于嚴(yán)謹(jǐn)。這是一種身份危機(jī)。

想想看。一個(gè)代理每天會(huì)生成 500 個(gè) PR。你的團(tuán)隊(duì)也許只能審查 10 個(gè)。審查隊(duì)列會(huì)堆積。這不是值得優(yōu)化的瓶頸。這是一個(gè)假瓶頸，只存在于我們強(qiáng)加給機(jī)器工作流的人類儀式之上。

這張圖不應(yīng)該存在。整個(gè)流程都是錯(cuò)的。

審查需要從頭重新考慮。要么讓它成為代碼生成本身的一部分，要么讓代理在計(jì)劃文檔中驗(yàn)證自己的工作、運(yùn)行測試、檢查回歸、驗(yàn)證架構(gòu)約束，或者由第二個(gè)代理對第一個(gè)代理的輸出進(jìn)行審查。對抗性代理會(huì)在擬變更的各個(gè)維度進(jìn)行挑戰(zhàn)。我們已經(jīng)有工具可以做到這一點(diǎn)。人機(jī)結(jié)合的審查成為例外情況，僅在自動(dòng)驗(yàn)證無法解決沖突或變更確實(shí)新穎時(shí)觸發(fā)。

沒有 PR 的世界會(huì)是什么樣子？代理直接提交到主分支。自動(dòng)化檢查、測試、類型檢查、安全掃描、行為差異、驗(yàn)證變更。如果一切通過，它就會(huì)自動(dòng)發(fā)布。如果有問題，代理會(huì)修復(fù)。只有在系統(tǒng)確實(shí)不知道如何處理時(shí)，才需要人為干預(yù)。

我們把代理能在幾秒鐘內(nèi)驗(yàn)證的變更花在人工審查上。那不是質(zhì)量保證。這是反技術(shù)守舊。

4、部署：解耦并持續(xù)

代理已經(jīng)在編寫比多數(shù)團(tuán)隊(duì)親自構(gòu)建更復(fù)雜、更專業(yè)的部署流水線。功能標(biāo)記、金絲雀發(fā)布、漸進(jìn)式擴(kuò)展、自動(dòng)回滾觸發(fā)器、曾經(jīng)需要專門平臺團(tuán)隊(duì)的發(fā)布工程能力。

關(guān)鍵轉(zhuǎn)變在于代理自然地將部署與發(fā)布解耦。代碼會(huì)持續(xù)部署，每一次變更在生成并經(jīng)過驗(yàn)證后產(chǎn)生一個(gè)制品，放在生產(chǎn)環(huán)境的門控后面。發(fā)布是一個(gè)單獨(dú)的決策，由功能標(biāo)記或流量規(guī)則驅(qū)動(dòng)。

一些團(tuán)隊(duì)已經(jīng)接近真正的持續(xù)部署與發(fā)布。代碼被生成，測試通過，制品被構(gòu)建，變更上線，全部在一個(gè)自動(dòng)化流程中完成，意圖與生產(chǎn)之間沒有人類參與。

下一步會(huì)更有意思。想象這樣一種場景：代理不僅部署代碼，還管理整個(gè)發(fā)布生命周期，監(jiān)控落地情況，基于錯(cuò)誤率調(diào)整流量比例，在延遲上升時(shí)自動(dòng)回滾，只有在確實(shí)出現(xiàn)新穎問題時(shí)才通知人類。部署的“階段”不再只是一段自動(dòng)化過程，而是一個(gè)持續(xù)自我調(diào)節(jié)的循環(huán)，永不結(jié)束。

5、監(jiān)控：唯一存活的階段，需要進(jìn)化

監(jiān)控是唯一存活的 SDLC 階段。它不僅存活下來，還是其他一切的基礎(chǔ)。

當(dāng)代理比人類審查得更快地發(fā)布代碼時(shí)，可觀測性不再只是一個(gè)可視化的儀表盤層。它成為整條生命周期的首要安全機(jī)制。其他所有保護(hù)措施——設(shè)計(jì)審查、代碼審查、QA 階段、發(fā)布簽字——都被吸收或消除。現(xiàn)在剩下的就是可觀測性。

但大多數(shù)可觀測性平臺是為人類打造的。告警、日志檢索、儀表板等都為人觀看、解讀和行動(dòng)而設(shè)計(jì)。當(dāng)變更量超過人類注意力時(shí)，這一模型就會(huì)崩潰。如果一個(gè)代理每天發(fā)布 500 個(gè)變更，而你的可觀測性設(shè)置需要人類去調(diào)查每一個(gè)異常，你就創(chuàng)造了一個(gè)新的瓶頸。你把它從代碼審查推到了事件響應(yīng)。

只有動(dòng)作的可觀測性才是有價(jià)值的。未來的可觀測性不是儀表盤，而是一個(gè)閉環(huán)系統(tǒng)，其中遙測數(shù)據(jù)成為已發(fā)布代碼的上下文，使代理能夠檢測回歸并修復(fù)它。

可觀測性層成為驅(qū)動(dòng)整個(gè)循環(huán)的反饋機(jī)制。 它不是末端的某個(gè)階段。它是整個(gè)系統(tǒng)的連接組織。

最先搞清楚這一點(diǎn)的團(tuán)隊(duì)——將可觀測性直接回饋到代理循環(huán)中，而非回到某人類的監(jiān)控系統(tǒng)——將比其他人更快、更安全地交付。否則他們將淹沒在警報(bào)中。

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

SDLC 曾經(jīng)是一個(gè)寬循環(huán)。需求 → 設(shè)計(jì) → 編碼 → 測試 → 審查 → 部署 → 監(jiān)控。線性。順序。充滿交接和等待。

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

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

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

只有一個(gè)人類的意圖和一個(gè)執(zhí)行任務(wù)的代理。

7、那么剩下的是什么？

上下文。就這么簡單。

用代理構(gòu)建的內(nèi)容質(zhì)量與你給予它們的上下文質(zhì)量直接相關(guān)。不是流程。不是儀式。是上下文。

SDLC 已經(jīng)死亡。新技能是上下文工程。新的安全網(wǎng)是可觀測性。

而且大多數(shù)行業(yè)仍在配置沒有人看的人為 Datadog 儀表板。

原文鏈接：軟件開發(fā)生命周期已死 - 匯智網(wǎng)