00:00:00Cursor 宣布在其平台中发布了 GPT 5.2 Codex,
00:00:05这是一个专为长时间运行任务设计的新前沿模型。但这实际上并不是我视频的重点。我视频的真正重点是 Cursor 首席执行官 Michael Truel 的这篇帖子,
00:00:18他在帖子中提到他们使用了这个模型——我猜至少是这样,
00:00:23他们提到的是 GPT 5.2,
00:00:25而不是 Codex,
00:00:27但我想他指的是 Codex——他们用这个模型仅凭 AI 就构建了一个浏览器,
00:00:33据我理解是这样的,
00:00:35因为它不间断地运行了一周。所以 Cursor 中的 AI 运行了一周时间,
00:00:41构建出了一个浏览器。
00:00:43它在数千个文件中编写了超过三百万行代码,
00:00:47而且渲染引擎是从零开始编写的,
00:00:50它处理了 HTML 解析、
00:00:53CSS 层叠,
00:00:54以及所有你期望浏览器具备的功能。然而,
00:00:58这里有一个重要的限制:它勉强能用。我完全理解 Cursor 团队的立场。仅靠 AI 独立编写出一个基本能用的浏览器,
00:01:10这确实令人印象深刻。但是,
00:01:13尽管我从未开发过浏览器,
00:01:16可能永远也不会,
00:01:17但可以说,
00:01:18真正复杂的是把它从 80% 推进到 100% 的那些部分。而且这不仅仅适用于浏览器。如果你曾经做过任何事情,
00:01:30即使是在编程之外,
00:01:32你也会知道对于大多数项目来说,
00:01:35困难的部分是在你完成 80% 之后才开始的。而且我甚至还没有谈到营销之类的问题,
00:01:43那才是超级困难的。
00:01:45我说的只是构建本身。对于许多项目、
00:01:49许多软件来说,
00:01:50你不需要达到100%,
00:01:52但80%或70%可能还不够。而正是那额外的部分可能超级难以实现,
00:01:59AI可能无法帮你做到。我是说,
00:02:02仅靠AI的话。我想在这里说清楚,
00:02:06因为那个视频很容易被误解或曲解。我对AI是100%积极的态度。我一直在用它。比如,
00:02:15buildmygraphic.com的大部分代码都是AI写的。不过不是通过vibe coding,
00:02:25而是根据我的指令,
00:02:27由我审查代码,
00:02:28在需要调整的时候由我亲自进入代码进行修改。但我在这个网站上大量使用了AI。我还刚刚发布了我的AI开发者课程的重大更新,
00:02:41在课程中我会带你了解如何高效使用GitHub Copilot和Cursor,
00:02:49探索它们提供的不同功能,
00:02:52帮助你更好地利用AI。因为我相信,
00:02:55而且我在其他视频中也分享过,
00:02:58AI是开发者的未来。它是一个超级有用的工具,
00:03:03大量且高效地使用它将至关重要。这一点我完全确信。但我不太确信纯粹形式的vibe coding能带我们走到那一步。这一点可能值得解释一下。因为我认为,
00:03:19在vibe coding和代理工程之间存在一个光谱。当然,
00:03:25你也可以说完全不使用AI也是一种选择。但我再次强调,
00:03:31我确信你应该使用AI。问题在于你在这个光谱上的哪个位置?你在这里吗?在这里吗?在中间吗?你可以在任何位置。但存在不同的权衡或者说用例。问题也在于你如何定义vibe coding。我理解的vibe coding,
00:03:53完全是关于让AI编写代码,
00:03:56没有代码审查,
00:03:57不理解代码库,
00:03:59也不传递任何代码特定的指令,
00:04:02比如使用这个模式或使用这个包。所以真的是对代码一无所知。这就是我定义的100%的vibe coding。当然外面肯定还有许多不同的定义。这只是我所说的vibe coding。在我看来,
00:04:21这种形式的编码对于商业产品、
00:04:24真正的产品来说没有未来。但是,
00:04:28它对于其他事物、
00:04:29其他类型的产品可能很棒。所以我认为vibe coding可以很好地用于个人实用工具,
00:04:38或者一次性软件。就是那种你用一两次、
00:04:42不太在意的东西,
00:04:44或者也许是免费软件,
00:04:46你不向人们收费,
00:04:48因此它运行得好不好其实无所谓。你可以提出这些论点,
00:04:53我会说这些是纯vibe coding可行的用例。你完全可以用AI来请求一个做某事的脚本,
00:05:02你不在乎它是否涵盖所有边缘情况,
00:05:06是否可能有一些潜在bug,
00:05:08因为如果它能为你完成工作,
00:05:11你就满意了。这完全没问题。你可以很好地进行vibe coding。现在在光谱的另一端,
00:05:20我们有代理工程。通过代理工程,
00:05:24也就是我所做的、
00:05:25我认为是未来的方式,
00:05:27你把AI当作一个工具来使用。这并不意味着你只把它用于简单任务,
00:05:34这可以包括复杂任务。这对我来说非常重要,
00:05:38因为很容易搞错,
00:05:40但这可以包括复杂任务。但这意味着你对想要使用的模式、
00:05:46库等有明确的指令。这也意味着你会以某种方式审查代码,
00:05:51也可以包括借助其他AI工具进行自动审查,
00:05:55但你会时不时地查看代码以了解发生了什么。这还意味着当AI卡住时,
00:06:02或者当你想让它开始某个特定实现时,
00:06:06你知道某个接口应该是什么样子或者想使用哪种模式,
00:06:11你会亲自进入代码,
00:06:13这样AI就可以完成你的思路。可以这么说,
00:06:17我认为这才是未来。今年,
00:06:20代理工程,
00:06:21至少是我的未来。当然,
00:06:23我可能在这一点上是错的。也许几年后,
00:06:27vibe coding是唯一的方式,
00:06:31因为AI太强大了,
00:06:33可以做所有事情。我不认为会这样,
00:06:36但绝对有可能。不过我认为现在唯一错误的决定是不在这个光谱上的任何位置。你应该在这里的某个地方。你绝对应该使用AI。我在其他视频中也分享过这一点。然而,
00:06:52回到这个帖子,
00:06:53我对那种「差不多能用」的态度有意见。正如前面提到的,
00:06:59我在cursor这个帖子的背景下理解它。还值得注意的是,
00:07:05显然cursor团队有点想转变叙事,
00:07:09或者也许想再次获得更多关注,
00:07:12特别是在X平台上,
00:07:14过去几周一直被使用Claude code配合Rolf循环让AI以vibe coding启发的方式构建一切的开发者所主导。cursor团队想展示你也可以用cursor来执行长时间运行的任务,
00:07:34让AI自主构建软件,
00:07:36这是有道理的,
00:07:37因为这显然是现在获得大量关注的东西,
00:07:41特别是在X上。所以我完全理解这一点。而且,
00:07:46我想再次明确,
00:07:47cursor是一个了不起的工具。我只是对这种「差不多能用」的态度有意见,
00:07:55因为我认为它在加速。随着AI的发展,
00:07:59它越来越成为一种趋势。我们已经看到这种情况持续多年了。早在AI出现之前我们就看到了,
00:08:08像iOS或Windows这样的操作系统变得更糟了。它们充满bug。你可以在视频游戏中看到这一点,
00:08:18它们在首日往往无法游玩。你可以在这么多软件中看到这一点。这与AI无关。
00:08:26软件质量变得更糟了。我能理解。我们可以快速迭代。你可以快速修补。这就是过去15年左右发展起来的思维模式。而这种思维模式我看到正在随着AI的出现而持续并加速,
00:08:43因为有了AI,
00:08:44你当然可以快速修补问题。
00:08:47如果你在进行全盘AI编程,
00:08:50那么你可能不会太在意bug,
00:08:53因为反正可以瞬间修复它们。代码库中糟糕的代码质量可能也无关紧要,
00:09:01因为不需要人类深入其中。AI能搞清楚并修复它。如果你的修复方案是一堆if语句来处理所有可能出错的情况,
00:09:12而不是一个简洁的实现,
00:09:15这可能也不重要。再次强调,
00:09:18这绝对是我们可能拥有的一种未来。我不认为这会是未来,
00:09:24我当然也不希望这是未来,
00:09:27但我们确实可能走向那样的未来。不过我也认为,
00:09:32作为开发者、
00:09:33作为构建软件的公司,
00:09:35高质量软件将会有真正的市场——第一天就不出问题的软件,
00:09:41不糟糕的软件。你也可以用AI来构建更好的软件。没有任何法则强迫你必须快速行动并牺牲软件质量。你可以利用AI构建更好的软件,
00:09:55两全其美,
00:09:57将你的技能与AI结合,
00:09:59把AI当作审查代码的额外双眼。我希望我们能更多地朝这个方向发展,
00:10:06因为我相信,
00:10:08虽然大多数人可能不会这样做,
00:10:11但对于那些确实构建高质量软件、
00:10:14确实试图两全其美的公司和开发者来说,
00:10:18将会涌现出宝贵的机会。