WEBVTT

00:00:00.000 --> 00:00:06.000
大家好，今天只有我。我想聊聊 AI 软件工程到底难在哪里。

00:00:08.000 --> 00:00:13.680
一方面，最近我收到一些很真诚的邮件，大家分享了自己的经历；

00:00:13.680 --> 00:00:18.000
另一方面，我也在 Twitter 上问了这个问题，收到了很多回应。

00:00:19.000 --> 00:00:22.580
我有时真的会想：

00:00:22.580 --> 00:00:28.000
用了 Claude Code 这类 agent 软件工程工具十八个月，

00:00:28.000 --> 00:00:31.000
怎么感觉什么都没改善？

00:00:32.000 --> 00:00:38.160
我知道这么说不完全对，模型显然强了很多，

00:00:38.160 --> 00:00:45.000
但那些真正棘手的问题，似乎并没有解决。

00:00:46.000 --> 00:00:48.000
有些方面反而更糟了。

00:00:48.000 --> 00:00:54.500
我觉得最常见的问题，

00:00:54.500 --> 00:01:00.220
无论是我们自己使用 agent 工具时遇到的，

00:01:00.220 --> 00:01:06.000
还是别人反馈的，归根结底都是一些基础问题还没有解决。

00:01:07.080 --> 00:01:08.080
现在，速度本身

00:01:08.080 --> 00:01:09.360
成了一个新问题。

00:01:10.000 --> 00:01:17.000
它生成的代码越来越多，我们却越来越跟不上。

00:01:18.000 --> 00:01:24.340
其实这本来也不会

00:01:24.340 --> 00:01:30.000
那么糟，只要我们愿意慢下来。可我们不愿意。

00:01:30.000 --> 00:01:34.000
我们要求自己越来越快。

00:01:34.000 --> 00:01:36.000
因为现在已经不是一个人在用这些工具了，

00:01:36.000 --> 00:01:37.000
而是整个团队都在用。

00:01:37.000 --> 00:01:43.240
不知道有多少人跟我表达过这种

00:01:43.240 --> 00:01:49.400
挫败感：别人不断把粗制滥造的代码发过来，

00:01:49.400 --> 00:01:51.000
PR 的数量多到根本看不过来。

00:01:51.000 --> 00:01:56.840
于是我们陷入了一种很尴尬的局面：模型

00:01:56.840 --> 00:02:03.000
变得非常强，却还没有强到可以让我们放心信任。

00:02:04.000 --> 00:02:09.000
而这段差距，似乎没有明显缩小。

00:02:10.000 --> 00:02:17.000
对现在的我而言，这在个人层面上也是一个大问题。我以前也写过。

00:02:17.000 --> 00:02:23.340
我不相信 Astra 能当好软件工程师，现在对 Fable 也越来越不信任，

00:02:23.340 --> 00:02:29.500
因为在训练过程中，这些模型

00:02:29.500 --> 00:02:33.000
获得奖励是因为把任务完成了，而不是因为写出了我喜欢的代码。

00:02:34.000 --> 00:02:39.000
它们现在的一些行为，在很多方面反而适得其反。

00:02:39.000 --> 00:02:42.540
比如，

00:02:42.540 --> 00:02:49.000
它们不像以前那样愿意使用编辑工具了。这意味着，当我在

00:02:49.000 --> 00:02:52.920
Pi 里看着修改不断刷过时，常常连模型在做什么都看不明白，

00:02:52.920 --> 00:02:54.000
更别说知道它在调用哪些工具了。

00:02:54.000 --> 00:02:58.000
这些事情不断发生，而我们的交付速度越来越快。

00:02:58.000 --> 00:03:00.000
代码质量却在迅速下降。

00:03:01.000 --> 00:03:06.840
而我们

00:03:06.840 --> 00:03:12.980
已经没有那么多毅力和精力，

00:03:12.980 --> 00:03:17.000
再像以前一样坚持同样严格的质量标准。

00:03:17.000 --> 00:03:21.000
我们对代码的理解也在不断流失。

00:03:21.000 --> 00:03:27.240
我觉得其中更隐蔽的危险在于：

00:03:27.240 --> 00:03:30.300
当某个场景真的非常需要

00:03:30.300 --> 00:03:35.000
我们理解代码时，却常常发现似乎已经没人懂了。

00:03:35.000 --> 00:03:40.000
以前一起工作的朋友跟我讲过这样的事。

00:03:40.000 --> 00:03:45.980
我也在 Twitter 上听人讲过类似的经历：

00:03:45.980 --> 00:03:52.380
出了故障，一群人

00:03:52.380 --> 00:03:54.000
挤在 Slack 频道里，试图弄清楚发生了什么。

00:03:54.000 --> 00:04:01.000
结果大家都只是在跟机器聊天，因为已经没人真想去理解了，更别说理解提交进去的代码。

00:04:01.000 --> 00:04:07.000
我觉得我们不应该鼓励这种局面。

00:04:07.000 --> 00:04:13.280
但我想告诉大家，

00:04:13.280 --> 00:04:15.000
现在很多人都有这样的感受。

00:04:15.000 --> 00:04:20.900
为了我们自己，也为了这个行业，

00:04:20.900 --> 00:04:24.920
我们有责任想办法解决这个问题，不能只是

00:04:24.920 --> 00:04:31.000
任由它发生，什么抵抗都不做。

00:04:31.000 --> 00:04:34.000
这是一种非常普遍的经历。

00:04:34.000 --> 00:04:38.000
别误会，

00:04:38.000 --> 00:04:39.000
我喜欢这些工具。

00:04:39.000 --> 00:04:42.000
它们确实非常迷人。

00:04:42.000 --> 00:04:49.000
很多时候，用它们的体验简直像魔法一样。

00:04:49.000 --> 00:04:53.000
但它们也让人非常沮丧。

00:04:53.000 --> 00:05:00.000
这些小机器有时会给出惊人的结果，

00:05:00.000 --> 00:05:05.520
可接下来，你又得花两个星期反复调整一个 PR，想把它改成满意的样子，

00:05:05.520 --> 00:05:09.000
却完全感觉不到在往前推进。

00:05:09.000 --> 00:05:14.000
而且这似乎是随机的。

00:05:14.000 --> 00:05:20.260
我不知道，是不是我和身边这个小圈子的人都不太擅长

00:05:20.260 --> 00:05:25.000
写提示词。毕竟有人说，只是我们提示词写错了。

00:05:25.000 --> 00:05:27.000
但我觉得，这件事本来就很难。

00:05:27.000 --> 00:05:33.460
我真的觉得，既然

00:05:33.460 --> 00:05:38.500
我们——也许不是所有人，但至少很多人——都在为此挣扎，

00:05:38.500 --> 00:05:42.000
那就应该让你知道：你不是一个人。

00:05:42.000 --> 00:05:48.220
我想，我们可能需要改变处理某些

00:05:48.220 --> 00:05:52.000
问题的方式，改变工程实践，才能真正追到问题根源。

00:05:52.000 --> 00:05:56.600
因为更好、更强的模型，

00:05:56.600 --> 00:06:03.060
眼下反倒让情况更糟了一点：它们写出的代码

00:06:03.060 --> 00:06:08.000
看着难受得多，也难懂得多。

00:06:08.000 --> 00:06:13.000
今天就聊到这里。周末愉快。