前言
這是"互聯網的錯誤"節目。我是卡爾。要說的第一件事就是，這里有個謊言。這個視頻分為三部分。首先，我們會討論那個聲明。然后會談論原本應該做什么。Devin 實際上做了什么，它如何做到的，及其效果如何。
AI 的發展和過度炒作
我從業軟件行業已經 35 年了。我并不反對高新科技。但我確實反對過度炒作。這也是我做這個視頻的原因。Devin 在大約一個月前被推出。被吹噓為世界上第一個 AI 軟件工程師。我并不認同它是第一個軟件工程師。我已經對此拍攝了一個視頻。我會在簡介里放上鏈接。但今天要談論的是一個具體的聲明。即視頻簡介的第一句話。"看 Devin 如何通過處理混亂的 upwork 任務來賺錢。"這個聲明是不正確的。你在視頻里看不到這一點。視頻里并未發生這種情況。然而，更糟糕的是，由于一些人不斷重復并夸大這一說法，引發了公眾的恐懼、不確定感和疑慮。他們這么做可能是為了增加點擊率，或者希望自己的內容能夠走紅，或者只是想跟上時代的潮流。總的來說，對 Devin 的炒作簡直瘋狂。而這個聲明似乎成為了這場炒作的支點。
為了記錄，我個人認為生成式 AI 很酷。我經常使用 GitHub Copilot。我使用 ChatGPT、Llama 2、Stable Diffusion。所有這些工具都很酷。但是，撒謊關于這些工具的功能對所有人都是不公正的。因此，Devin 完成了一些令人印象深刻的工作。我希望這家公司本可以保持真誠，簡單地承認這一成就。但他們沒有這么做。他們不得不假裝它的功能遠超實際。
現在，我無意貶低那些真正開發 Devin 的工程師們的貢獻。我認為 Devin 在很多方面都很出色。特別是，我不是要針對視頻中的那位朋友。謊言不在視頻中，而是在視頻的描述和公司發出的推文中，以及那些一再重復這一謊言的文章和人們中。這種行為不應被接受。公司不應該在沒有受到指責的情況下撒謊。人們也不應該未經核實就重復互聯網上的言論。我知道這似乎是徒勞無功，但我愿意為此堅持到底。由于沒有看到其他人在解釋這是個謊言，看來要解決這個問題，我需要親自出馬。在你覺得這種謊言無傷大雅之前，請認識到這確實能造成實質的傷害。你可能是有一定技術背景的觀眾，請記住，很多人只看標題，不讀正文，他們并沒有技術背景。這些謊言導致非技術人員錯誤地認為人工智能的能力遠超當前水平，從而引發了多種問題。
人們對于 AI 的懷疑不足，對 AI 的輸出也缺乏必要的警覺性。目前對 AI 盲目信任已讓許多人面臨困境。可以搜索"AI Lawyer fake cases" 或"AI fake scientific papers"了解具體情況，這些只是一些顯著的案例。這種情況也對真正的軟件專業人員造成了傷害，因為有人會信任 AI 生成的代碼，這意味著網絡上將出現更多的錯誤，而現在網絡的狀態已經很糟糕了，漏洞和黑客活動層出不窮。糟糕的代碼越多，對每個人的生態環境的影響就越惡劣。
Devin 應該完成的工作
現在我們來討論第二部分。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 到底做了什么呢？如果沒有賺錢，它究竟產出了什么，工作做得好不好呢？
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 的屬性。我在谷歌上搜索了這個問題，找到了 GitHub 上的一個相關評論。我按照該評論中的建議修改了代碼行，這樣確實解決了問題。我還附上了一個鏈接，展示了我是從何處獲得這個解決方案的靈感，因為我對 Apex 的工作原理并不是非常熟悉。能在網絡上找到幫助真是太好了。解決這個問題總共花了我大約一分鐘七秒的時間，只需這么短的時間我就修正了錯誤。這只是一個快速的谷歌搜索而已。
以下是我所做的修改的具體內容。這是我最初狀態和最后狀態之間的差異。這是 requirements.txt 文件的一處修改。最開始使用的是 torch 1.4.0 版本，我使用了最新版本的 torch，即 2.2.2，或者至少是一個比較新的版本。在過去的一小時里，可能已經有了更新的版本。然后在右邊，這是 Devin 視頻中的最后一屏，左邊是我的視頻，也就是最后的輸出。它們兩個大同小異。我的框框是黃色的，他們的是紅色的。我不清楚哪個更好或者更差。不過我只花了 36 分鐘，Devin 花的時間稍微多一點。
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 自身生成的代碼。在視頻的最后，講述者說道："做得好，Devin。"而實際上，Devin 完成的任務對于 AI 來說的確很酷。
如果你幾個月前問我，一個 AI 面對這個問題可能會有什么樣的表現，我可能會預測它的表現會比 Devin 實際上的要差。說實話，在我看來，這真的相當令人印象深刻。但在 Upwork 工作應該完成的任務背景下，尤其是在一些人聲稱 Devin 從 Upwork 接活并完成的情況下，再加上公司的聲明，即這段視頻將展示 Devin 如何通過工作獲得報酬，這些都只是謊言，我不能確定我是否會稱贊 Devin 的工作。所以，如果你們正在開發 AI 產品，那很好。AI 是有價值的，我經常使用它，我希望它能變得更加優秀。請繼續開發 AI 產品，但請一定要如實告訴大家關于它們的事情。
如果你是一名記者，博主或者影響者，千萬不要盲目地轉發和擴大互聯網上的信息，而不進行必要的核實，沒有查證它們是否真實。如果你對某些信息是否真實感到困惑，或者你自己無法確定它們是否真實，那么請向其他人詢問，或者干脆不要轉發這些信息。因為許多人并不會去查看信息的原始來源，他們只看標題，然后就會誤以為這些信息是真實的。這確實讓人遺憾，但這就是我們的現實。如果你現在正在使用互聯網，那么，請，為了所有重要的事情，對你在互聯網或新聞上看到的一切，尤其是任何可能與 AI 相關的內容，都要持保留和懷疑的態度。
目前有太多的炒作，有很多人在散播各種信息，聲稱這些是真實的，但實際上并非如此。所以，請一定不要忘記對一切持有懷疑的態度。這很重要。
結語
好了，這就是我在這個視頻中要分享的內容。在我們下次見面之前，記住互聯網上充滿了誤解，任何否認這一點的人都可能在向你推銷某種東西。祝大家一切順利