今天小编分享的科技经验：惊天反转？全球首个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 有关的事情。
目前有太多的炒作，有很多人在散播各种信息，声称这些是真实的，但实际上并非如此。所以，请一定不要忘记对一切持有怀疑的态度。这很重要。
好了，这就是我在这个视频中要分享的内容。在我们下次见面之前，请始终记住互联网上充满了误解，任何否认这一点的人都可能在试图向你推销某种东西。祝大家一切顺利。
