讓 AI 誕生的職業，會因為 AI 失業嗎？
上個月，初創公司 Cognition AI 用精妙絕倫的 Demo 演示了 AI 軟體工程師 Devin，一夜之間在 X 上捲起風暴之餘，也讓更多程式設計師發出了如上疑問。
在官方的定義中，Devin 被描繪為世界上第一位完全自主的 AI 軟體工程師，大有要取代程式設計師的意思。
例如，Cognition AI 想讓 Devin 完成一個任務：測試大語言模型 Llama 在三個 API 提供商上的性能。
他們發了一段用自然語言寫的提示詞，接下來，雙手離開鍵盤，一切都交給 Devin。
然後，Devin 便開始像人類程式設計師一樣寫代碼，順利構建和部署了一個可視化的網站，既完成了任務，結果又賞心悅目，走進閱卷老師的心坎里。
然而，幾天前，一位 YouTuber 在逐幀分析 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 有關的事情。
目前有太多的炒作，有很多人在散播各種資訊，聲稱這些是真實的，但實際上並非如此。所以，請一定不要忘記對一切持有懷疑的態度。這很重要。
好了，這就是我在這個影片中要分享的內容。在我們下次見面之前，請始終記住網際網路上充滿了誤解，任何否認這一點的人都可能在試圖向你推銷某種東西。祝大家一切順利。
