今天小編分享的科技經驗：驚天反轉？全球首個AI程式員被揭演示造假，再次“震撼”硅谷，歡迎閲讀。
讓 AI 誕生的職業，會因為 AI 失業嗎？
上個月，初創公司 Cognition AI 用精妙絕倫的 Demo 演示了 AI 軟體工程師 Devin，一夜之間在 X 上卷起風暴之餘，也讓更多程式員發出了如上疑問。
在官方的定義中，Devin 被描繪為世界上第一位完全自主的 AI 軟體工程師，大有要取代程式員的意思。
例如，Cognition AI 想讓 Devin 完成一個任務：測試大語言模型 Llama 在三個 API 提供商上的性能。
他們發了一段用自然語言寫的提示詞，接下來，雙手離開鍵盤，一切都交給 Devin。
然後，Devin 便開始像人類程式員一樣寫代碼，順利構建和部署了一個可視化的網站，既完成了任務，結果又賞心悦目，走進閲卷老師的心坎裏。
然而，幾天前，一位 Youtube 博主在逐幀分析 Devin 的宣傳視頻以及上手復現 Demo 後，發現過于完美的 Devin 似乎只是「活」在視頻裏。
一方面，Devin 并不能按照雇主的要求去完成完整的任務，另一方面，Devin 也缺乏作為一個合格工程師與雇主溝通方案和确認具體需求的能力。
網友 @dotey 分享了原視頻的編譯版本，附上地址：https://baoyu.io/youtube-subtitle/tNmgmwEtoWE
我們也為你準備了視頻編譯文本：
這就是「互聯網的錯誤」節目。我是卡爾，現在有個謊言想要告訴你們。這個視頻分為三個部分。
首先，我們将讨論這個説法。我們将讨論應該做什麼，Devin 實際上做了什麼，以及它是如何做到的并且做得如何。
我從事軟體行業已經 35 年了。我并不反對 AI，但我真的反對炒作，這就是我這樣做的原因。
一個月前，Devin 被吹捧為世界上第一個 AI 軟體工程師，我不相信它是第一個軟體工程師，我已經制作了一個關于這個的視頻。我會在説明中提供鏈接。但今天是關于具體主張的。即視頻簡介的第一句話——「看 Devin 通過雜亂的 upwork 任務來賺錢。」這種説法是謊言。但你在視頻中看不到這一點，它也不會在視頻中發生。
更糟糕的是，人們因為試圖獲得點擊或病毒式傳播或者只是想跟上時代的潮流。而不斷重復和美化這一説法，并引發了人們的炒作和恐懼、不确定性和懷疑。總的來説，關于 Devin 的炒作是瘋狂的。這句話似乎是很多人所依據的。
需要説明，我個人認為生成式 AI 很酷。我本人定期使用 GitHub Copilot。我也使用 ChatGPT、Llama 2、Stable Diffusion。所有這些工具都很酷。但是，謊報這些工具能做什麼對所有人都是不公正的。因此，Devin 做了一些令人印象深刻的事情，我希望這家公司本可以保持真誠，簡單地承認這一成就。但他們沒有這麼做。他們不得不假裝它的功能遠超實際。
現在，我無意貶低那些真正開發 Devin 的工程師們的貢獻。我認為 Devin 在很多方面都令人印象深刻，特别是，我不是要針對視頻中的那位朋友。謊言不是在視頻本身中，而是在視頻的描述以及公司的推文中。
然後它們出現在很多地方，人們一遍又一遍地重復着這種謊言。這不應該是好事。公司不應該在沒有受到指責的情況下撒謊。人們也不應該未經核實就重復互聯網上的言論。我知道這似乎是徒勞無功，但我願意為此堅持到底。
由于沒有看到其他人在解釋這是個謊言，看來要解決這個問題，我需要親自出馬。在你覺得這種謊言無傷大雅之前，請認識到這确實能造成實質的傷害。
你可能是有一定技術背景的觀眾，請記住，很多人只看标題，不讀正文，他們并沒有技術背景。這些謊言導致非技術人員錯誤地認為人工智能的能力遠超當前水平，從而引發了多種問題。
而這些謊言所做的是讓非技術人員相信 AI 比現在更有能力，人們最終對 AI 的懷疑也缺乏必要的警覺性。目前對 AI 盲目信任已讓許多人面臨困境，其中 AI 律師偽造案件或 AI 偽造科學論文都是比較突出的例子。
這也傷害了真正的軟體專業人士，因為會有一些人相信 AI 生成的代碼。因為有人會信任 AI 生成的代碼，這意味着網絡上将出現更多的錯誤，而現在網絡的狀态已經很糟糕了，漏洞和黑客活動層出不窮。糟糕的代碼越多，對每個人的生态環境的影響就越惡劣。
我們接着來讨論第二部分，Devin 應該完成的工作是什麼？這是視頻的開始或較早的部分。請注意，螢幕左下角标有我已經給你即将分析的每一幀都标上了時間碼。現在我們來到了視頻的 2.936 秒處，如果你對某個具體細節感興趣，或想要知道更多我讨論内容的背景信息，你可以自行查看。
這就是 Devin 在 Upwork 上所做的工作。我們一會兒再讨論。首先，請查看螢幕左側頂部，注意看，他們搜索了這個。所以這不是一些随機的工作。這不是 ...Devin 可以在 Upwork 上承擔任何工作，對不對？這是他們精心挑選的。這并不一定具有欺騙性。你可能也會這麼期待。但請記住，這意味着 Devin 在其他大部分工作上可能比這一次的表現還要差，而這次的表現就已不盡人意。
再來看看那個特定請求的細節，在下面，那才是客户真正需要的。我想要利用這個庫來進行推理。你需要提供詳細的操作指南。我不想讨論完成這項工作預計需要的時間。Devin 沒有提及這一點。那沒關系，我不在乎這個。但你看，這才是 Devin 實際被告知的内容。而這是直接復制并粘貼給 Devin 的。我希望利用這個模型在庫中進行推理。這是那個存儲庫。請自己弄清楚。
好了，回到工作本身。你需要提供的是如何在 AWS 的 EC2 上操作的詳細指南。簡單地説「請自己弄明白」和提供 AWS 的 EC2 實例操作的詳細指導是不一樣的。鄭重聲明，視頻末尾的這份報告是 Devin 生成的報告，裏面根本沒有提及客户實際所需。
那麼，這份工作的最終成果應該是什麼呢？首先，你要明确的是怎樣開始這項工作。你将需要在雲端配置一個實例。确定實例的大小、類型、所需的内存等，這些都要弄清楚。你需要向客户詢問，他們是更傾向于一個運行更快但成本更高的實例，還是一個更經濟但運行較慢的實例？這個系統需要持續在線嗎？随時可以處理提交的任務并給出回應嗎？還是你打算啓動它，運行後卻關閉以節省開支？
你如何處理你需要進行推理分析的資料？如何處理你需要分析的圖片？你打算如何把這些上傳到伺服器？可以設立一個網頁界面來處理。你也可以通過 SSH 上傳，或者放在 S3 bucket 裏。那輸出結果的訪問方式又是怎樣的呢？這些都是你必須了解的問題。
好了，這也是我之前視頻裏提到的。
作為一名軟體工程師，軟體開發人員的工作中 AI 不擅長的部分、難點、關鍵、復雜、耗時的部分主要是與客户、上司及其他利益相關者的溝通。弄清楚實際需要處理什麼，反復讨論「這麼做會簡單很多，我們就這麼做如何？」這些都是 AI 目前無法完成的任務，而這些恰恰是我們所做的非常重要的事情。
這只是從 AI 做錯事開始的。遺憾的是，這是在 upwork 上的情況。因此，對于那些未來可能會遇到這個情況的人來説，像這樣的提案請求很糟糕。如果可能，盡量避免。合理的提案請求流程會包含問答環節。他們會説明他們的需求，你向他們提出問題，其他供應商也會提出問題。他們回答所有問題，将答案發送給每個人，然後競标就開始了。
既然我們不能在 Upwork 中做到這一點，因為平台不支持，接下來最好的做法 ( 雖然并不是很好 ) 是你羅列所有問題，選擇那些可以最大限度減少你工作量的答案。然後在你的提案開頭明确説明，「這些是我所做的假設。如果這些假設有任何不符，可以重新協商，但這意味着成本會上升。」
因為你要盡可能地低報價，同時确保客户明白你的出價是基于這些假設的，如果這些假設中的任何一個，他們希望以不同的方式完成，他們将不得不支付更多。這不是一個好的競标過程，但如果你必須做這種競标過程，那就是你的方法。
此任務的交付内容應該包括：哪種雲實例類型、哪種作業系統和鏡像的使用以及如何設定、安裝環境 ( 關于 CUDA、APEX、PyTorch，如果你不熟悉這些并不重要 ) 。
這是一個四年前的庫，你要麼更新這個庫以便适用于現代 Python 及其庫，或者你需要解釋如何安裝一個四年或更舊的環境，必須選擇這兩種方案中的一種。你需要向客户解釋如何将數據上傳至實例，他們如何從實例下載輸出結果等。
我也實際上復現了 Devin 做的事情。稍後我們會更多地談論這個問題。
這是我使用的實際實例的規模。我選擇了 Vulture 而不是 AWS，因為 AWS 的界面復雜不易操作，不太适合制作視頻。而且最重要的是，到這個視頻被編輯和發布時可能已經有新版本發布，導致數據出錯。
因此，這種方式穩定性更高，操作也更簡單。對于這項工作，為客户着想，本來打算在 AWS 上完成的。我們不知道 Devin 使用了什麼樣的圖片。他們沒有透露任何信息。
如果你是個受虐狂，這裏有個鏈接，可以看到完整視頻，我會現在放在描述中。整整 35 分鍾 55 秒，復制 Devin 所做的一切。如果你真的沒事幹，不妨看看。我認為透明度很重要，這視頻雖然無聊，但至關重要。我希望那些制造 Devin 的公司及其他在網上發表此類聲明的人，能夠真的發布原始視頻，讓我們在必要時可以核實他們的聲明。
好的，接下來的部分。考慮到 Devin 沒有按客户的要求行事，報告裏也沒有包含客户要求的内容，而且 Devin 實際也沒有得到任何報酬，那 Devin 到底做了什麼呢？如果它沒有賺錢，那它究竟產出了什麼，實際做得好不好呢？
這是視頻的一個截圖，也就是被提到的 Repo。我們稍後再回到這樣的螢幕。
這是 Devin 第一次真正的變動。這是一個名為 requirements.txt 的檔案，它規定了代碼的依賴庫版本。并且它必須改變一些事情，因為這個代碼庫最初依賴的一些庫是四年前的版本，而現在其中一些庫出售，不再提供下載，所以不得不進行了一些修改。
這裏提到 Devin 實際上正在更新代碼。這種説法在某種程度上是可以成立。我認為這更多的是在修改配置檔案，而非代碼更改，但這也説得過去。Devin 能夠做到這一點确實令人贊嘆。如果這個工具僅僅是調整了所有 requirements.txt 以使它們一致，那将大大節省我的時間。這将是一個很棒的功能。
所以，能做到這一點很好。我不确定是否将其稱為代碼，但這是真正需要完成的工作的很小一部分。
與客户的要求相比，他們基本上希望建立自己的推理能力。Devin 被告知只使用樣例數據就可以，因此這正是我復現 Devin 操作時所做的。通常情況下，應該比這更復雜，但我們将展示 Devin 實際所做的。好的，Devin 很早就遇到了一個錯誤。我沒有遇到這個錯誤，馬上你會看到原因。在這裏仔細看，這是一個命令行錯誤。
在頂部，我們遇到了與打開影像、檔案未找到、無此檔案或目錄相關的錯誤。這個錯誤出現在一個名為 visualize_detections.py 的代碼檔案中。我沒有遇到這個問題，是因為在那個代碼庫中不存在名為 visualize_detections.py 的檔案。我不确定那個檔案從哪來的，但關于這個問題的更多信息稍後會提供。
回到命令行，如果你放大視窗的其他部分，你會發現，Devin 将一些内容寫入一個名為 inspect_results.py 的檔案中接着運行 Python 執行這個檔案結果出現了語法錯誤。在 Python 檔案中使用反斜杠 n 是運行不了的。echo 命令也不該這麼使用。這可能是由于人為疏忽而進行的操作，然後你會突然意識到，「哦，對了，我應該改變我的方法。」
但現在看來，Devin 在創建這些含錯誤的檔案後，又進行了修正。
視頻中提到 Devin 實際上是在進行打印行調試。這很酷，這是我們很多人做的事情，在某些情況下，使用打印行調試确實很有用，能看到 Devin 也能這樣做，感覺很酷。但這裏也出現了另一個我之前沒有注意到的錯誤。Devin 正在嘗試解決這個問題。
評論裏説，「Devin 正在添加代碼，追蹤數據流直至徹底理解。」我對此沒問題。我不确定在這種情境下使用「理解」這一詞是否恰當。我不相信 Devin 真的能理解任何事物，我對此表示懷疑。
不過，我們一直将這樣的東西拟人化，這也是語言使用上的一種便利。因此，我不會因此而嚴厲批評他們。但話雖如此，讓我們來看看 Devin 實際在做什麼。放大觀察這一部分，可以看到一個奇特的循環。它正在讀取一個檔案，并把數據讀入一個緩衝區。這是 update_image_ids.py 檔案。
再次説明，這個檔案在客户要求我們使用的代碼倉庫中不存在。實際上，我在 GitHub 上搜索了所有可能的位置，只有兩處存在帶有這個名稱的檔案。螢幕上顯示三個的原因是其中一個是另一個的分支版本，它們與 Devin 正在使用的檔案完全不同。所以我不清楚這個檔案從何而來，我們也一無所知。
但問題在于 Devin 此處正在調試一個自己創建的檔案，而這個檔案完全不在項目代碼倉庫中。這非常不妥。對于那些可能不太專心看視頻的觀眾，或是那些沒時間或沒精力去查看代碼庫的人，或沒有時間檢查代碼倉庫的人，這段視頻給人的感覺是 Devin 正在識别并修正 Upwork 用户提出需要我們檢查的代碼庫中的錯誤。
這并非真相。Devin 自行生成錯誤，随後自己調試并修復了這些錯誤。這似乎不符合 Devin 的常規操作。這既不是人們普遍認為 Devin 應該做的，也不是很多撰寫關于 Devin 的文章和視頻的人士所描述的。
事實上，Devin 并沒有修復它在互聯網上發現的代碼，也沒有修復客户要求它修復的代碼。而是在修正自己生成的錯誤代碼。這完全不是大多數看這個視頻的人所認為的情況。更糟糕的是，沒有理由這樣做。這是那個代碼庫中的 readme 檔案。
正如前面提到的，我們會回到這個頁面。該庫中有一個名為 infer.py 的檔案，正如視頻中 Devin 所做的那樣。readme 檔案説明了其功能及使用方法。在右側，甚至還有一個小按鈕，你可以點擊它來復制整條命令，粘貼至你的命令行視窗，然後按下回車。如果你看過我演示如何重現結果的長視頻，這正是我所做的。我復制粘貼了這個代碼，修改了路徑名後按下回車，它就開始運行了。
我認為開發這個檢測道路損壞的代碼倉庫的人已經盡可能地簡化了使用説明，但 Devin 似乎還是沒能理解。因此他不得不自己創建了一個混亂的項目。這段代碼，關于讀入緩衝區的部分，是很糟糕的，對嗎？這是幾十年前在 C 語言，這種更低級的語言中才會用的方法。而 Python 有更有效的處理方式。
正如 Devin 正在發現的，這樣的代碼很難調試。它復雜，難以處理，很容易出現小錯誤，我想這正是 Devin 現在嘗試解決的問題。我不完全确定具體是什麼出了問題，但看起來像是字元偏移了，導致 JSON 沒有被正确解析。但我要説的是，現在這種方法已經過時了。我們在 Python 中不會這樣做。這不是我在代碼審查時會接受的，尤其是來自一個初級開發者的。這種做法引起的問題比它解決的要多。這是非常糟糕的做法。
此外，代碼倉庫裏确實存在一個真正的錯誤，Devin 沒有找到也沒有修復。Devin 剛剛創建了一堆其他的東西。
就像我説的，我自己復現了 Devin 的工作。這是鏈接，将會在視頻描述中提供。我使用了 Torch 2.2.2，這是比 Devin 使用過的版本更新的版本。回看之前的 requirements.txt 檔案，我遇到的主要困難是安裝一個叫做 Apex 的軟體包，需要配合正确版本的 CUDA，也就是 NVIDIA 的驅動程式。這非常棘手。
我最終不得不從源碼開始構建，這個過程大約占了我工作總時間的 16 分鍾，共 36 分鍾。可能有一個更簡單的方法來做到這一點，但對于 16 分鍾的編譯時間來看，這似乎是最快捷的方法。我确實把硬編碼從 requirements.txt 檔案中删除了。Devin 只是更改了一些數字，我認為我的方式更好，但技術上無論哪種方式都可以。
在下一張幻燈片中，實際上有一個需要修復的錯誤，我将會展示那是什麼。總共花了我大約 36 分鍾，具體來説是 35 分 55 秒來完成我所做的事。
待會當我們讨論 Devin 花費的時間時，這會很重要。這是我上傳的那個長視頻的截圖，雖然沒列出，但我提供了鏈接，歡迎觀看完整視頻。放大查看。所以，真正的錯誤在于名為 dataset.py 的檔案第 33 行。問題是 torch 模塊缺少一個名為 underscore six 的屬性。通過 Google 搜索，我在 Github 上發現了一個評論。我按照該評論中的建議修改了代碼行，這樣确實解決了問題。
我還附上了一個鏈接，展示了我是從何處獲得這個解決方案的靈感，因為我對 Apex 的工作原理并不是非常熟悉。能在網絡上找到幫助真是太好了。解決這個問題總共花了我大約一分鍾七秒的時間，只需這麼短的時間我就修正了錯誤。這只是一個快速的 Google 搜索而已。
以下是我所做的修改的具體内容。這是我最初狀态和最後狀态之間的差異。這是 requirements.txt 檔案的一處修改。最開始使用的是 torch 1.4.0 版本，我使用了最新版本的 torch，即 2.2.2，或者至少是一個比較新的版本。在過去的一小時裏，可能已經有了更新的版本。然後在右邊，這是 Devin / 視頻中的最後一個螢幕，左邊是我的視頻，也就是最後的輸出。它們或多或少是一樣的。我的框框是黃色的，他們的是紅色的。我不清楚哪個更好或更差。但我只花了 36 分鍾，Devin 花的時間稍微多一點。
這裏是 Devin / 視頻的早期部分。時間戳 3 月 9 日下午 3.25 的。在視頻的後半部分，你可以看到另一個時間戳，就是 3 月 9 日晚上 9.41。那麼我們看到的是 6 小時 20 分鍾的間隔。我完全不知道這 6 小時 20 分鍾裏發生了什麼。我希望像 Devin 那樣，他在等人的時間較長，因為這個過程花這麼長的時間實在沒有道理。
這簡直是瘋了，因為我只用了大約半個小時。另外一個我猜想，可能就是他們讓它過夜，然後第二天再回來處理，因為又有一個時間戳，是第二天下午 6 點的。希望這個過程并沒有持續這麼長時間。所以我估計用了六個小時，但實際上可能花了一天兩小時。
只是，我不知道為什麼會花費那麼長時間，畢竟這樣的效率不高。當你逐幀查看時，你會發現螢幕上出現了一些奇怪的命令行操作。這裏有一個奇怪的錯誤。看看這個命令「head -N 5 results.json | tail -N 5」。這是什麼意思呢？它表示取這個 JSON 檔案的前五行，然後再取這些行的最後五行。這完全沒必要。
沒有理由這樣做，沒有人會這樣做，而這正是 AI 無法感知的事情。當你稍後回過頭來看，你就會發現自己正在試圖調試什麼。然後到處都是這些無關緊要的東西。這讓找出問題的關鍵變得非常困難。其實，正确的做法應該是「head -5 results.json」。那個 -N 是多餘的。只要説 -5 就可以，不需要那些多餘的東西。
這種情況就是，當 AI 現在生成内容時，會讓事情變得更復雜，希望這種情況能變得更好。但現在 AI 生成的東西中有很多都很愚蠢。比如它在 Python 中執行操作的方式，就像你在 C 中執行操作的方式，然而現在沒有人會用 Python 這麼做。即使它現在能正常工作，但是生成式 AI 的現狀就是它完成的工作糟糕、復雜、混亂，這不僅給每個人增加了更多的工作，如果你将來要嘗試去維護它，修復其中的錯誤，或者更新到新的版本，或者做任何類似的事情，都會非常困難。
讓我們看一下 Devin 認為需要完成的任務列表。如果你看左邊，就會看到我接下來會詳細介紹的復選框。具體是什麼并不重要，只是看一下數量而已。這一系列復選框給人的感覺是 Devin 完成了一些復雜或困難的任務。當你觀看視頻，看到這些信息快速滾動過去，你可能會覺得，哇，Devin 做了很多事情。
然而，為了復制 Devin 的結果，我只需要在雲實例上設定合适硬體的環境，并實際運行兩個帶有正确路徑的命令。這些東西看起來就像 Devin 做了很多工作，完成了很多任務。然而，只要你設定好環境，實際上你只需要運行兩個命令。這些代碼修正全都無關緊要，因為它們都是 Devin 自身生成的代碼。
然後在最後旁白視頻中的人説，幹得好，德文。而現在實際上，Devin 完成的任務對于一個 AI 來説的确很酷。
如果你幾個月前問我，一個 AI 面對這個問題會做些什麼，我可能會預測它的表現會比 Devin 實際上的要差。説實話，就我而言，這真的相當令人印象深刻。但在 Upwork 工作應該完成的任務背景下，尤其是在一些人聲稱 Devin 從 Upwork 接活并完成的情況下，再加上公司的聲明，即這段視頻将展示 Devin 如何通過工作獲得報酬，這些都只是謊言，我不太認同「幹得漂亮」這句旁白。
因此，如果你們正在開發 AI 產品，那很好。AI 是有價值的，我經常使用它，我希望它能變得更加優秀。請繼續開發 AI 產品，但請一定要如實告訴大家關于它們的事情。
如果你是一名記者，博主或者有影響力的人，千萬不要盲目地轉發和擴大互聯網上的信息，而不進行必要的核實，沒有查證它們是否真實。如果你對某些信息是否真實感到困惑，或者你自己無法确定它們是否真實，那麼請向其他人詢問，或者幹脆不要轉發這些信息。因為很多人并不會去查看信息的原始來源，他們只看标題，然後就會誤以為這些信息是真實的。
這的确讓人感到遺憾，但這就是我們的現實。如果你現在正在使用互聯網，那麼出于對所有神聖事物的熱愛，請對你在互聯網上看到的一切或新聞上看到的一切持懷疑态度，尤其是任何可能與 AI 有關的事情。
目前有太多的炒作，有很多人在散播各種信息，聲稱這些是真實的，但實際上并非如此。所以，請一定不要忘記對一切持有懷疑的态度。這很重要。
好了，這就是我在這個視頻中要分享的内容。在我們下次見面之前，請始終記住互聯網上充滿了誤解，任何否認這一點的人都可能在試圖向你推銷某種東西。祝大家一切順利。
