幾天前，整個AI圈都被Cursor的一則重磅消息給炸暈了。
事情是這樣的：
Cursor聲稱，他們讓GPT-5.2驅動的編碼智能體連續運行了整整7天，也就是168個小時。
結果，這群AI智能體居然從零開始，寫出了一個包含300萬行程式碼、功能堪比Chrome的瀏覽器！
這聽起來實在是太誘人了——
隨著Token變得像水電一樣廉價，AI可以無限期地自我迭代，直到完成目標。
無論是作業系統、辦公軟體還是遊戲引擎，只要算力足夠，AI似乎都能給你「肝」出來。
然而，就在大家還沒從震驚中緩過神來的時候，技術社區的「列文虎克」們出手了。
他們仔細扒了扒Cursor開源的這個專案程式碼，結果發現了一個驚天大瓜——
這個所謂的「AI瀏覽器」，其實連最基本的編譯都通過不了！
在一篇技術部落格中，作者犀利地指出：
Cursor口中所謂的「突破性進展」，本質上就是一堆缺乏工程邏輯的「AI泔水」（AI Slop）。
他們所做的，其實在宣傳上玩了一手漂亮的「障眼法」，讓所有人都以為這個專案真的跑通了。
但實際上，這根本就是一堆無法運行的廢程式碼。
部落格地址：https://embedding-shapes.github.io/cursor-implied-success-without-evidence/
GPT-5.2七天肝出一個瀏覽器，是假的？
接下來，讓我們來仔細看看開發者社區的這篇「打假」文章，是如何抽絲剝繭地發現Cursor這一波宣傳的不實之處的。
首先，作者分析了一下Cursor具體都幹了什麼。
在1月14日，他們發布了一篇題為「Scaling long-running autonomous coding」的博文。
官方部落格：https://cursor.com/blog/scaling-agents
在這篇文章中，他們聊到了讓「編碼智能體自主運行數週」的實驗，其明確目標是：
了解我們能將智能體編碼的邊界推進到什麼程度，從而完成那些通常需要人類團隊花費數月時間才能完成的專案。
然後，Cursor的研究者討論了嘗試過的一些方法，分析了失敗原因，以及該如何解決問題。
終於，他們找到了某種方案，它「解決了我們大部分的協調問題，並讓我們在不依賴單一智能體的情況下，將規模擴展到非常大的專案」。
最終，這種方案實現了一種驚人的結果——
為了測試這個系統，我們給它定了一個雄心勃勃的目標：從零開始構建一個網路瀏覽器。這些智能體運行了將近一週，在1,000個檔案中編寫了超過100萬行程式碼。
同時，他們在GitHub上放出了原始碼。
GitHub專案：https://github.com/wilsonzlin/fastrender
這就奇怪了，所以這個任務，智能體成功完成了嗎？
如果你沒有被這句話成功帶節奏，就會發現這個撲朔迷離之處——
他們聲稱「儘管程式碼庫規模很大，新的智能體仍然可以理解它並取得有意義的進展」，以及「數百個worker並發運行，推送到同一個分支，衝突極少」，但他們從未真正說明這個嘗試成功沒有。
它真的能跑起來嗎？你自己能運行這個瀏覽器嗎？我們不知道，而且他們從未明確說過。
所謂的演示，只是一個短短8秒的「影片」：
在下方，他們寫道：
雖然這看起來像是一個簡單的截圖，但從零開始構建一個瀏覽器是非常困難的。
總之，從頭到尾，他們從未斬釘截鐵地承認過：這個瀏覽器是可運行且功能正常的！
打開一看：全是報錯，跑都跑不起來
總之，如果只是看README、Demo截圖，甚至是幾段宣傳性質的描述，這個專案好像真的很厲害。
可是，只要你真正clone倉庫、運行一次cargo build或cargo check，問題就會立刻暴露出來。
error: could not compile 'fastrender' (lib) due to 34 previous errors; 94 warnings emitted
可以說，這個程式碼庫距離一個「可工作的瀏覽器」還差得遠了，甚至可以說，它從未被真正成功構建過！
文章作者發現了如下多個證據。
首先，GitHub Actions在main分支上的多次近期運行全部失敗，其中甚至包含 workflow檔案本身的錯誤。
另外，如果嘗試獨立構建，就會發現報了數十個編譯器錯誤，最近的PR還都是在CI掛掉的情況下合併的。
更誇張的是，如果翻看Git的歷史記錄，從最近的提交往回追溯100個提交，簡直找不到哪怕一個能乾淨編譯的提交。
也就是說，這個倉庫從誕生起，就從未處於「能跑」的狀態。
上下滑動查看
https://gist.github.com/embedding-shapes/f5d096dd10be44ff82b6e5ccdaf00b29
現在我們根本無法確定，Cursor的研究者在這個程式碼庫上釋放的「智能體」實際上幹了什麼，但它們似乎從未運行過cargo build，更不用說cargo check了。
因為這兩個命令都會報出幾十個錯誤和大約100個警告。如果真的去修這些錯誤，報錯數量肯定還會爆炸式增長。
目前在他們的倉庫中，有一個關於此的未解決GitHub issue。
issue地址：https://github.com/wilsonzlin/fastrender/issues/98
結論已經非常明顯：
這根本就不是真正的工程程式碼，而是典型的「AI Slop」（AI泔水）。
這種低品質的程式碼堆砌，或許在形式上模仿了某種功能，但其背後缺乏連貫的工程意圖，實際上連最基本的編譯都無法通過。
在Cursor的演示中，他們大談下一步的宏偉計劃，卻對「如何運行」、「預期效果」或「工作原理」隻字不提。
而且，除了丟出一個程式碼倉庫連結，Cursor沒有提供任何可復現的演示，也沒有給出任何已知可用的版本標籤（tag/release/commit）來驗證那些光鮮亮麗的截圖。
無論初衷如何，Cursor的博文試圖營造出一個「功能正常的原型」的假象，卻遺漏了工程界最看重的基本誠實——可復現性。
他們確實沒有明確聲稱「它能正常運行」，這讓他們在字面上避開了「撒謊」的指控，但這種誤導性極強。
到目前為止，他們唯一證明的只是：
AI智能體可以瘋狂輸出數百萬個Token，但最終生成的程式碼依然是一堆無法運行的廢料。
一個「瀏覽器實驗」不需要對標Chrome，但它至少應該有一個合理的最低標準：
在受支援的工具鏈上編譯通過，並渲染一個簡單的HTML檔案。
很遺憾，Cursor的文章和公開構建均未達到這一及格線。
GitHub被衝，開發者怒了
這種把「半成品」包裝成「里程碑」的行為，徹底激怒了開發者社區。
在GitHub的Issue區，憤怒的留言刷了屏：
- 我也試了，根本跑不起來。
- 程式碼邏輯風馬牛不相及，CI全紅也敢合併？我們是在對著截圖膜拜嗎？
- 既然功能是假的，開源這個倉庫有什麼意義？為了證明AI能製造電子垃圾嗎？
還有人一針見血地指出了這種「泡沫工程」的本質：
反正投資人看不懂程式碼，甚至不知道GitHub是什麼。
只要是電腦自動寫的程式碼，業績曲線就能蹭蹭漲，機器一響，黃金萬兩……
而且在Hacker News上，也有近200條討論，將這一專案的底褲徹底扒了下來。
網友pavlov指出，所謂的「從零開始」和「定製JS虛擬機」純屬忽悠。
看一眼依賴列表（html5ever, cssparser, rquickjs）就能發現，這東西本質上就是Mozilla開發的Servo引擎的「套殼」版。
網友brabel更是哭笑不得：
這幫人居然覺得聲稱「從零手搓」是步好棋？
程式員上手第一件事就是查依賴，一眼就能看出是在調包。
唯一的解釋是，他們賭沒人會認真核實，畢竟大多數人只會看個標題就歡呼。
Anthropic太強勢，Cursor被逼急了？
雖然Cursor從未直說「這已準備好投入生產」，但他們卻用「從零構建」和「有意義的進展」這種宏大敘事，配合精心挑選的截圖，成功製造了「實驗成功」的假象。
他們最接近成功的表述是：
數百個智能體可以在同一個程式碼庫上協同工作數週，取得真正的進展。
但這句驚人的聲明，沒有任何證據支持。
沒有可工作的 commit，沒有構建說明，沒有演示。
大家並不指望它成為下一個Chrome，但如果你聲稱你已經構建了一個瀏覽器，它至少應該能夠演示被編譯 + 載入一個基本的HTML檔案，不然就是純純地愚弄大眾了。
其實Cursor這個AI自動編程一週的消息一出來，就讓人覺得有點奇怪。
最近一個月，全球AI圈的高光時刻，基本都在Claude Code身上。
Claude Code之父Boris Cherny的X發帖，基本上都會引起社區的震動。比如他說自己過去30天內沒寫一行程式碼，對Claude Code程式碼庫的貢獻，全部由Claude Code自己完成。
谷歌首席工程師Jaana Dogan所說，Claude Code一小時內，就完成了整個團隊整整一年才做完的任務。
前特斯拉AI總監Andrej Karpathy更是直言：矽谷正在經歷一場九級地震，自己從未感覺如此落後……
擴展閱讀：再見，程式員！矽谷全員AI Coding，卡帕西宣告9級地震來了
在這種形勢下，一篇「編碼智能體運行一週，自己寫出一個瀏覽器」的敘事，是多麼順應潮流，多麼吸引眼球啊。
也難怪Cursor工程師嘗試這個腦洞後，沒怎麼多想就著急地發出來，這才被火眼金睛的開發者們衝了。
AI程式員超進化：「開掛」工程師
這次「瀏覽器鬧劇」雖然慘烈，但也意外地揭示了AI編程的真實進化路徑。
Hyperbolic聯創兼CTO Yuchen Jin指出了Cursor演示中隱含的關鍵教訓：單純堆砌數量是行不通的。
讓一堆智能體平級相處、自我協調，只會帶來混亂。
· 角色分工必須明確：需要有規劃者（Planner）、執行者（Executor）和評審員（Reviewer）。
· 模型差異化：GPT-5.2更適合長程規劃任務；而Opus 4.5容易「早退」和偷懶。
· 組織架構：增加太多「管理層」智能體反而會拖累效率，這與人類公司的「大企業病」如出一轍。
HyperWriteAI的CEO Matt Shumer也在復現過程中發現，只要運行框架和能力支援到位，明確分工的AI智能體集群確實能產生實質性進展。
然而，更深層的進化不僅僅發生在AI身上，更發生在人類工程師身上。
在矽谷，一個新的流行詞正在取代老派的「10倍工程師」，那就是——「Cracked Engineer」（開掛工程師）。
這個詞，是指那些一個人能頂一個團隊的頂級開發者。
Cursor這次的翻車，恰恰是因為它Karpathy所說的「氛圍編程」陷阱——
只享受AI瘋狂生成程式碼的爽感，卻完全拋棄了工程嚴謹性。
由此誕生的，只能是那種如果不修補就無法運行的「Cursor搬運工」式廢料。
真正的「開掛工程師」是這一現象的反面。他們瘋狂使用AI，但絕不盲信AI。
他們擁有深厚的技術底蘊，能夠一眼揪出AI生成的邏輯漏洞，能夠清理像這次瀏覽器專案中出現的「電子泔水」。
正如初創公司Intology的創始人所言：
少數幾個專注且懂行的人加上AI，能比過去15個不用AI的人幹得更多。
未來的軟體開發，不會是數千個無人監管的AI智能體像無頭蒼蠅一樣亂撞（然後造出一個編譯不過的瀏覽器）；而是由一名「開掛工程師」，帶領著數十個AI Agent，精準、高效地構建出真正的產品。
而這些「開掛」的程式員，也將會淘汰那些只會「假裝在編程」的人。
參考資料：
https://embedding-shapes.github.io/cursor-implied-success-without-evidence/
https://www.theinformation.com/articles/forget-vibe-coders-cracked-engineers-rage-tech?rc=epv9gi