AI 時(shí)代，軟件開發(fā)的成本真的下降了 90% 嗎？資深工程師 Martin Alderson 在本文中分享了自己的最新觀察結(jié)果：AI Agent 正在大幅壓縮開發(fā)中的人力成本，讓原本需要數(shù)周甚至數(shù)月完成的項(xiàng)目，在幾小時(shí)或一周內(nèi)就能交付。同時(shí)，AI 不僅能加速新項(xiàng)目開發(fā)，還能輕松理解和維護(hù)三年以上的老舊代碼庫。這種變化釋放了巨大的潛在軟件需求，讓小團(tuán)隊(duì)也能實(shí)現(xiàn)過去整個(gè)開發(fā)小隊(duì)才能完成的產(chǎn)出。

這篇文章深入探討了成本下降背后的原因、AI 工具對(duì)開發(fā)模式的重塑，以及為什么 2026 年可能成為行業(yè)的大轉(zhuǎn)折點(diǎn)。

原文：https://martinalderson.com/posts/has-the-cost-of-software-just-dropped-90-percent/

作者 | Martin Alderson 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我做軟件開發(fā)已經(jīng)將近 20 年了，見證過不少浪潮——SaaS 的“誕生”、移動(dòng)應(yīng)用的全面崛起、區(qū)塊鏈的瘋狂炒作，以及那些總說要讓程序員失業(yè)的低代碼工具。

但隨著代理式編碼（Agentic Coding）的出現(xiàn)，軟件開發(fā)的經(jīng)濟(jì)模型正在發(fā)生劇變，這股力量將徹底重塑整個(gè)行業(yè)（甚至?xí)案鼜V的經(jīng)濟(jì)結(jié)構(gòu)）。2026 年可能會(huì)讓很多人措手不及。

之前，我也討論了為什么現(xiàn)有的評(píng)測(cè)標(biāo)準(zhǔn)可能忽略了某些關(guān)鍵躍遷，而這段時(shí)間的思考和親身經(jīng)歷，更讓我確信我們正走進(jìn)一場“十年一遇”的行業(yè)大轉(zhuǎn)折。

軟件交付成本

我開始做開發(fā)的時(shí)候，正好趕上開源開始大規(guī)模興起——而那算是自定義軟件開發(fā)成本的第一波大幅下降。我還記得，當(dāng)年用 SQL Server 或 Oracle 的授權(quán)費(fèi)用高得離譜，所以我從一開始就用開源 MySQL，它讓你能構(gòu)建定制化的網(wǎng)絡(luò)應(yīng)用，而不用承擔(dān)動(dòng)輒五六位數(shù)的年度數(shù)據(jù)庫授權(quán)費(fèi)。

后來我們經(jīng)歷了云計(jì)算（它是否真的省錢其實(shí)還有爭議，不過就先假設(shè)它在初期確實(shí)減少了部分資本支出）。最近幾年的特點(diǎn)，我覺得是“復(fù)雜性時(shí)代”。軟件工程變得——在我看來往往是不必要地——復(fù)雜了。大家一頭扎進(jìn)對(duì)人力要求極高的模式，比如 TDD、微服務(wù)、極其復(fù)雜的 React 前端，以及 Kubernetes。我甚至覺得過去幾年，軟件開發(fā)的成本幾乎沒有下降。

然而在我看來，AI Agent 會(huì)大幅降低軟件開發(fā)中的人力成本。

那 90% 的成本節(jié)省到底來自哪里？

2025 年初，我對(duì)各種 AI 編碼工具都持懷疑態(tài)度——現(xiàn)在依然如此。很多平臺(tái)看起來就是換了皮的低代碼工具（比如 Loveable、Bolt 等），或者是一些帶點(diǎn)自動(dòng)補(bǔ)全增強(qiáng)功能的 VS Code 衍生版本，用起來感覺一半有用一半煩人。

以公司里一個(gè)典型的內(nèi)部系統(tǒng)項(xiàng)目為例。假設(shè)數(shù)據(jù)模型已經(jīng)有了雛形，你要做的是構(gòu)建一個(gè) Web 應(yīng)用來管理某個(gè)“widget”類的業(yè)務(wù)對(duì)象。

按照過去的流程，你通常需要一個(gè)小團(tuán)隊(duì)來搭建 CI/CD、整理數(shù)據(jù)訪問模式、開發(fā)核心服務(wù)。然后是大量 CRUD 頁面，再加上一些儀表盤或可視化。最后（理想情況下）還得寫一套自動(dòng)化的單元測(cè)試、集成測(cè)試、端到端測(cè)試，確保質(zhì)量過關(guān)，然后大概一個(gè)月后才能上線。

而這還只是“純勞動(dòng)力”。每多一個(gè)人，溝通成本就往上疊：各種會(huì)議、任務(wù)管理、Code Review、前后端對(duì)接、等待別人解決難題，你真正寫代碼的時(shí)間往往只是全部工時(shí)很小的一部分。

用代理式編碼的 CLI 工具，這些流程里幾乎所有步驟都能在幾小時(shí)內(nèi)完成。我曾讓 Claude Code 花幾小時(shí)寫完一個(gè)復(fù)雜內(nèi)部系統(tǒng)的完整單測(cè) + 集成測(cè)試套件（300 多條）。這種規(guī)模的測(cè)試，對(duì)我自己，或我認(rèn)識(shí)、尊重的開發(fā)者來說，都得花上好幾天寫。

AI Agent 已經(jīng)非常擅長把業(yè)務(wù)邏輯規(guī)范轉(zhuǎn)成結(jié)構(gòu)清晰、可用性很高的 API 和服務(wù)。

過去一個(gè)月的項(xiàng)目，現(xiàn)在一個(gè)星期搞定。思考時(shí)間差不多，但實(shí)現(xiàn)時(shí)間直接塌縮。而且團(tuán)隊(duì)越小，溝通開銷越低，甚至反向驗(yàn)證了“布魯克斯定律”的鏡像效應(yīng)：溝通成本不再是人越多效率越低，而是人越少效率爆炸提升。一兩個(gè)開發(fā)者突然就能做到過去一個(gè)團(tuán)隊(duì)才能完成的量。

潛在需求的釋放

乍看之下，這對(duì)軟件行業(yè)似乎是個(gè)壞消息，但從經(jīng)濟(jì)學(xué)的角度并不是這樣。

杰文斯悖論（Jevons Paradox）告訴我們，當(dāng)某種東西的生產(chǎn)成本下降時(shí)，我們并不會(huì)只是“花更少的錢做同樣的量”，而是會(huì)做更多。電燈就是典型例子：蠟燭和煤氣燈銷量掉了，但整個(gè)社會(huì)的人造光源總量卻大幅增加。

這一點(diǎn)，應(yīng)用到軟件開發(fā)上，就是供需關(guān)系問題：社會(huì)對(duì)軟件有著巨大的“潛在需求”。

幾乎每家公司都有幾百甚至幾千份 Excel 表格在記錄關(guān)鍵業(yè)務(wù)流程，而這些東西本該做成 SaaS。如果一家外包公司報(bào)價(jià) 5 萬美元來把其中一個(gè)做成應(yīng)用，那只有最核心的項(xiàng)目能立項(xiàng)。但如果成本降到 5000 美元（找個(gè)不錯(cuò)的開發(fā)者配合 AI 工具即可），那就完全是另一個(gè)世界——需求會(huì)大爆發(fā)。

唯一的護(hù)城河：領(lǐng)域知識(shí)

那么開發(fā)者會(huì)被淘汰嗎？現(xiàn)實(shí)沒那么簡單。

目前，人類仍然非常重要，因?yàn)槟愕谩翱粗?AI 干活”：審核它的輸出、提出建議、避免它走偏。如果完全 YOLO 式（You Only Live Once）地放任 AI 寫代碼，項(xiàng)目很快會(huì)亂成一團(tuán)。但只要有人類的參與，AI 能幫你在短時(shí)間內(nèi)構(gòu)建質(zhì)量非常高的軟件。

掌握這些工具的開發(fā)者，會(huì)在解決業(yè)務(wù)問題時(shí)變得異常高效。而他們的領(lǐng)域知識(shí)與行業(yè)理解會(huì)成為最大的杠桿：知道什么架構(gòu)合適、用什么框架、哪些庫穩(wěn)定好用。

再疊加對(duì)業(yè)務(wù)本身的理解，你會(huì)真切感受到“傳說中的 10 倍工程師”正在變成現(xiàn)實(shí)。同樣，業(yè)務(wù)專家 + 一個(gè)熟練掌握 AI 工具的開發(fā)者這樣的組合，將變得非常強(qiáng)大。未來我們可能不再需要“一個(gè)業(yè)務(wù)專家 + 一整個(gè)開發(fā)小隊(duì)”，而是只需要兩三個(gè)人緊密配合即可。

這種組合讓迭代速度快得驚人，軟件變得幾乎是一次性的：如果方向不對(duì)，直接丟掉重來，從經(jīng)驗(yàn)中學(xué)習(xí)就行。這需要轉(zhuǎn)變心態(tài)，但真正難的是想清楚問題，而不是敲鍵盤。

不要措手不及

AI Agent 和模型仍在快速進(jìn)化，而我覺得現(xiàn)有的基準(zhǔn)測(cè)試（benchmarks）并沒有真正反映這一點(diǎn)。比如 Opus 4.5 似乎能在 10–20 分鐘的長會(huì)話中保持較好理解，不會(huì)偏離主題。我們才剛剛開始看到數(shù)千億美元資本投入到 GB200 GPU 上的成果，而我相信更新一代的模型很快就會(huì)讓這些看起來完全過時(shí)。

然而，我遇到過太多抵觸這種變化的軟件工程師。我聽過的反對(duì)理由總是雷同：LLM 會(huì)犯太多錯(cuò)誤、它理解不了某個(gè)框架、或者根本沒節(jié)省時(shí)間。

這些說法正迅速變得完全不成立，讓我想起 2007 年那些看不起 iPhone 的桌面工程師們。大家都知道后來發(fā)生了什么——網(wǎng)絡(luò)更快了、手機(jī)性能提升、移動(dòng)操作系統(tǒng)也越來越強(qiáng)大。

我認(rèn)為，工程師們需要積極擁抱這場變革。這不會(huì)一夜之間完成——大企業(yè)總體上仍然落后，被繁瑣的供應(yīng)商審批和管理結(jié)構(gòu)困住，這讓它們對(duì)小型競爭者極度脆弱。

但如果你在一家小公司或團(tuán)隊(duì)工作，并且有機(jī)會(huì)使用這些工具，就應(yīng)該抓住它。你的工作會(huì)發(fā)生變化——不過軟件開發(fā)一直都在變化。只是這一次，變化可能比任何人預(yù)料的還要快。2026 年即將到來。

我經(jīng)常聽到的一個(gè)反對(duì)意見是：LLM 只適合新項(xiàng)目。我強(qiáng)烈反對(duì)這種觀點(diǎn)。我花了不少時(shí)間去理解三年以上、原作者已離職的舊代碼庫。AI Agent 可以大幅簡化這個(gè)過程——解釋代碼功能、定位 Bug、提出修復(fù)建議。我寧愿接手一個(gè)由 Agent 協(xié)助、并有優(yōu)秀工程師監(jiān)督完成的代碼庫，也不愿接手三年前某個(gè)水平可疑的承包商寫的、沒有測(cè)試、充滿“意大利面式”類和方法的混亂項(xiàng)目。

【報(bào)名倒計(jì)時(shí)，限免】C++之父中國行 · 40周年慶典｜北京·上海開發(fā)者見面會(huì)正式開啟！

• 北京站：12月12日 · 北京金隅喜來登酒店

• 上海站：12月14日 · 上海淳大萬麗酒店