WEBVTT

00:00:00.000 --> 00:00:01.700
但你不能大声。

00:00:01.820 --> 00:00:03.160
拿着剑的时候安静一点。

00:00:03.860 --> 00:00:04.920
拿着剑的时候安静一点。

00:00:07.840 --> 00:00:10.520
显然，代码已经没有以前那么重要了。

00:00:11.480 --> 00:00:17.680
但问题是，面对这么一大堆代码，你的 agent 到底能处理得多好？

00:00:17.680 --> 00:00:20.540
毕竟它的上下文窗口是有限的。

00:00:21.300 --> 00:00:25.920
所以，生成太多代码，到头来是在坑它自己。

00:00:26.400 --> 00:00:28.100
代码还像以前一样重要吗？

00:00:28.100 --> 00:00:29.100
不，肯定没那么重要了。

00:00:30.400 --> 00:00:35.860
但我觉得代码仍然重要。Astra 很酷，

00:00:35.860 --> 00:00:38.040
Fable 也是，但它们仍然像老虎机。

00:00:38.360 --> 00:00:43.000
确实有很多代码，你不需要知道它具体做什么、怎么工作。

00:00:43.340 --> 00:00:48.700
但也有很多重要的基础设施代码，你还是得知道它在做什么。

00:00:50.340 --> 00:00:52.980
归根结底，这是控制权的问题。

00:00:53.580 --> 00:00:56.700
我个人喜欢把接口和类型掌握在自己手里。

00:00:56.700 --> 00:01:02.300
只要这些还在我的控制之下，LLM 能造成的破坏就比较有限。

00:01:02.560 --> 00:01:09.140
没错，模型现在能疯狂吐出大量代码，但这也在坑自己，因为它们的上下文窗口终究有限。

00:01:09.140 --> 00:01:13.020
一旦装不下，就会冒出更多垃圾代码。

00:01:13.020 --> 00:01:18.900
Astra 发布后，我发现一件很有意思的事：

00:01:18.900 --> 00:01:25.060
我第一次越来越不想看它生成的代码，因为实在太难看了。

00:01:25.060 --> 00:01:27.580
我是说，看着就很费劲。

00:01:27.720 --> 00:01:32.020
它会在不该压缩的地方，把代码压得特别紧，

00:01:32.020 --> 00:01:36.480
甚至在正经生成代码时也是这样。

00:01:36.680 --> 00:01:39.860
而用代码调用工具时，尤其难读。

00:01:40.220 --> 00:01:47.040
光是它写代码的方式，就让人越来越难跟上它在做什么。

00:01:47.040 --> 00:01:52.780
就像 Mario 说的，在训练过程中，

00:01:52.780 --> 00:01:54.640
它可能会因为节省 token 而获得奖励。

00:01:55.360 --> 00:01:59.940
但追求这种 token 效率的结果，就是难以阅读。

00:02:00.420 --> 00:02:06.880
我觉得这里出现了一种矛盾：即使你把

00:02:06.880 --> 00:02:11.000
接口之类的都设计好了，看到 Astra 生成的代码时，

00:02:11.000 --> 00:02:13.000
我还是忍不住想给它格式化。

00:02:13.000 --> 00:02:16.360
我已经很久很久没有这种感觉了。

00:02:16.500 --> 00:02:22.160
我基本没用过代码格式化工具，因为我觉得 LLM 会跟着现有代码的风格来写。

00:02:22.280 --> 00:02:22.900
但现在它不跟了。

00:02:23.420 --> 00:02:24.640
是啊，挺奇怪的。

00:02:24.860 --> 00:02:25.780
真的很奇怪。

00:02:25.860 --> 00:02:26.840
我也不知道接下来会怎样。

00:02:27.280 --> 00:02:32.120
但我隐约觉得，这种情况可能会越来越常见。

00:02:32.260 --> 00:02:33.520
我不知道该怎么看待它。

00:02:35.360 --> 00:02:38.020
你之前说了一点，我觉得很有意思。

00:02:38.020 --> 00:02:41.800
模型不只被训练成编程 agent，

00:02:41.800 --> 00:02:48.140
也被训练成像 OpenClaw 那样的个人助手，所以训练里可能

00:02:48.140 --> 00:02:54.280
会有这样的轨迹或要求：随便写什么

00:02:54.280 --> 00:02:58.380
破代码都行，只要完成用户要的事情。

00:02:58.380 --> 00:03:01.700
而那个用户不是技术人员，也不写生产系统，

00:03:01.700 --> 00:03:08.080
只是做些小东西，比如“帮我做一个每日新闻简报网站”。

00:03:08.300 --> 00:03:09.340
或者仿个 Minecraft，什么都行。

00:03:09.700 --> 00:03:15.640
所以，如果模型现在被训练成只要让用户满意，就可以生成粗糙代码，

00:03:15.640 --> 00:03:20.760
这本身也没问题，但会损害它们用于生产软件开发的效果。

00:03:20.760 --> 00:03:25.320
我觉得很有意思的一点是，

00:03:25.320 --> 00:03:31.120
仔细看它生成的代码，

00:03:31.120 --> 00:03:34.780
比如测试、着色器、嵌入的 JavaScript，

00:03:34.780 --> 00:03:37.940
你能明显看出这些比它平时写的普通代码差得多。

00:03:38.180 --> 00:03:41.460
我在博客里写过：好像只要偏离常规代码一层，

00:03:41.560 --> 00:03:45.600
它就开始陷入那种把东西压得特别紧的模式。

00:03:45.600 --> 00:03:47.860
但我又想，也许只有我遇到这种情况。

00:03:47.880 --> 00:03:53.520
于是我在 Twitter 上问大家：如果你周末用 Astra 做了个游戏，而且觉得效果不错，

00:03:53.520 --> 00:03:54.720
就把代码给我看看。

00:03:54.880 --> 00:03:58.100
有两个人回复说：“还好吧，没那么差。”

00:03:58.180 --> 00:04:00.540
结果我打开一看，代码真的非常糟。

00:04:01.560 --> 00:04:05.440
后来他们好像也都说：“嗯，可能确实不太好看。”

00:04:06.000 --> 00:04:11.120
问题在于，我觉得我们原本没想到它真会把代码写得这么差。

00:04:11.120 --> 00:04:16.940
我原本完全相信，模型至少能达到某种

00:04:16.940 --> 00:04:18.660
及格水平。

00:04:18.900 --> 00:04:21.300
可现在感觉它连这条底线都突破了。

00:04:21.420 --> 00:04:21.820
我也说不准。

00:04:22.020 --> 00:04:23.700
但确实感觉发生了变化。

00:04:25.020 --> 00:04:30.940
对，就在昨天，我在 Spine 的一个老 C、C++ 代码库里做修改。

00:04:30.940 --> 00:04:35.420
我又换回了 5.6 Sol，

00:04:35.420 --> 00:04:40.220
因为 Astra 就是写不出什么像样的代码。

00:04:40.420 --> 00:04:41.680
很奇怪。

00:04:41.900 --> 00:04:42.860
真的非常奇怪。

00:04:43.000 --> 00:04:44.960
我怪那些追捧模型个性的人。

00:04:46.400 --> 00:04:53.040
我想到一点：假如你认为，

00:04:53.040 --> 00:04:57.620
至少理论上，根本不用关心代码本身，

00:04:57.620 --> 00:05:00.500
因为测试覆盖率能保证代码完美运行。

00:05:00.940 --> 00:05:05.440
那么，就算分支覆盖率达到了 100%，

00:05:05.440 --> 00:05:10.300
虽然我觉得这不太可能，你真的覆盖了这个函数所有可能的输入吗？

00:05:10.300 --> 00:05:16.700
我注意到的一点是，它把代码

00:05:16.700 --> 00:05:20.240
压缩得太厉害了，

00:05:20.240 --> 00:05:25.820
光看它生成的 diff，我根本没有把握，

00:05:25.820 --> 00:05:30.800
能在不问 LLM 的情况下判断测试到底够不够。

00:05:30.800 --> 00:05:34.320
这整件事让我很苦恼。

00:05:34.320 --> 00:05:38.020
如果代码太难读——我不是说

00:05:38.020 --> 00:05:43.860
完全读不懂，而是你离代码又远了一层——

00:05:43.860 --> 00:05:49.320
你就会更依赖这种想法：“有测试，测试都过了，我那个粗糙游戏也还能玩。”

00:05:49.460 --> 00:05:51.760
所以整套东西肯定没问题吧。

00:05:52.560 --> 00:05:59.320
可如果代码让你看着就抗拒，理解它就会困难得多。

00:06:00.100 --> 00:06:04.700
到这一步，测试也变成了做样子，对吧？

00:06:04.700 --> 00:06:07.840
它只是让你觉得：“有测试，挺好。”

00:06:08.280 --> 00:06:13.100
我压根不知道它们在测什么，有没有覆盖该测的东西，反正它们存在。

00:06:13.600 --> 00:06:14.660
所以我就放心了。

00:06:16.020 --> 00:06:18.560
全都是在靠感觉。

00:06:19.620 --> 00:06:26.720
如果生成的代码让人读不下去，你就更不想检查它到底有没有道理了。

00:06:26.960 --> 00:06:31.980
感觉我们正在被一步步推离代码。

00:06:31.980 --> 00:06:32.120
好。

00:06:34.700 --> 00:06:37.940
如果用 Astra 这样的模型，它显然

00:06:37.940 --> 00:06:41.320
就是被训练来把事做成的，

00:06:41.320 --> 00:06:45.780
但你只让它负责调用工具呢？

00:06:45.900 --> 00:06:47.160
不让它负责写代码。

00:06:47.260 --> 00:06:50.440
每当它要写代码，你就说：“停下。”

00:06:50.840 --> 00:06:55.600
换个 agent，或者别的什么东西来实现。

00:06:57.080 --> 00:07:00.700
因为我真的觉得训练过程里存在冲突。

00:07:00.700 --> 00:07:05.620
要么，这种做法确实很好，我们就应该接受，

00:07:05.620 --> 00:07:10.120
比如软件工程已经解决了，眼下只剩修修补补。

00:07:10.520 --> 00:07:11.780
那我们就不再看代码了。

00:07:11.900 --> 00:07:12.920
代码长什么样也就不重要。

00:07:13.060 --> 00:07:15.040
完全针对 LLM 优化就好。

00:07:15.040 --> 00:07:20.820
要么，模型之所以这样，只是因为它们被训练去做其他事情，

00:07:20.820 --> 00:07:22.700
尤其是很擅长用代码调用工具。

00:07:23.460 --> 00:07:29.840
那么训练目标就存在冲突，你应该换个专门被训练成

00:07:29.840 --> 00:07:31.120
优秀软件工程师的模型。

00:07:31.120 --> 00:07:34.680
我真的不知道答案是什么。

00:07:34.680 --> 00:07:39.000
毕竟你打开 OpenAI 的网页，也不会看到它明确告诉你该这么做。

00:07:40.340 --> 00:07:44.440
不过，也许现在碰到的是模型容量的问题。

00:07:44.440 --> 00:07:50.680
随着模型试图覆盖越来越多用例，或越来越多

00:07:50.680 --> 00:07:57.340
垂直行业，它显然就得学会如何在这些环境里工作。

00:07:57.340 --> 00:08:03.760
那最终就意味着，留给它原本擅长的事情的参数变少了，

00:08:03.760 --> 00:08:06.000
比如软件工程。

00:08:06.300 --> 00:08:07.780
也许我们现在就撞上这个问题了。

00:08:08.160 --> 00:08:12.880
也许是因为想尽可能覆盖所有行业，

00:08:13.160 --> 00:08:19.300
结果你所在的行业，尤其是软件行业，分到的参数不够，效果就受损了。

00:08:20.060 --> 00:08:20.340
我也不知道。

00:08:20.340 --> 00:08:26.160
工程方面的 token 消耗，

00:08:26.160 --> 00:08:27.700
一直在增长。

00:08:27.740 --> 00:08:30.680
你可以逐月看到这个变化。

00:08:30.980 --> 00:08:33.760
但那些顶线数字完全没有上涨，

00:08:35.220 --> 00:08:37.700
至少看不出跟它有什么关联。

00:08:38.060 --> 00:08:39.680
当然，提交次数增加了。

00:08:39.820 --> 00:08:41.760
其他一些能统计的数量也增加了。

00:08:42.460 --> 00:08:49.020
这笔支出从公司开销里微不足道的一项，变成了相当可观的一项。

00:08:49.020 --> 00:08:54.340
也许只是我们还没弄明白，怎么真正把它用好。

00:08:55.140 --> 00:09:01.480
也可能只是整体来看，产出的东西并没有

00:09:01.480 --> 00:09:03.440
多出那么多实际价值。

00:09:04.260 --> 00:09:10.540
比如，现在大家对一款软件的基本期待，

00:09:10.540 --> 00:09:13.080
已经变成它必须做更多事情。

00:09:14.060 --> 00:09:17.620
你还得跟同一领域里的其他所有人竞争。

00:09:17.620 --> 00:09:20.320
所以，你的产品当然也得有聊天机器人。

00:09:20.700 --> 00:09:26.240
界面当然也得做到一些以前根本不需要的东西。

00:09:26.920 --> 00:09:31.480
我觉得现在做移动应用的人也比以前多了，因为门槛降低了。

00:09:31.980 --> 00:09:37.400
也许这是一种很奇怪的局面：我们被要求做得更多，

00:09:37.540 --> 00:09:40.260
但消费者的数量还是那么多。

00:09:40.560 --> 00:09:44.040
结果只是软件工程变得更贵了。

00:09:44.180 --> 00:09:45.120
我不知道这是不是答案。

00:09:45.120 --> 00:09:51.620
我觉得现在也很难衡量，毕竟

00:09:51.620 --> 00:09:57.420
整体经济不太平，油价上涨，还有各种其他因素。

00:09:57.560 --> 00:10:01.020
所以，单看 GDP 大概很不合适。

00:10:01.280 --> 00:10:07.960
但看具体公司，尤其是软件公司，我没看到它们为用户做出更多真正有意义的功能。

00:10:08.500 --> 00:10:09.580
我真的没看到。

00:10:09.580 --> 00:10:17.140
你能说出哪款软件或 SaaS 产品，在过去十二个月里发生了实质变化吗？

00:10:17.620 --> 00:10:19.700
我觉得在 AI 领域，多少还是能看到一点。

00:10:20.400 --> 00:10:23.820
对，但问题是，AI 领域做出来的这些东西，到底谁在用？

00:10:24.380 --> 00:10:24.600
是啊。

00:10:24.600 --> 00:10:29.240
我觉得 iOS 27 就是个挺有意思的例子，

00:10:29.240 --> 00:10:35.120
因为苹果内部使用 AI 工具的人显然应该更多了。

00:10:35.360 --> 00:10:41.120
我听苹果的人说，他们确实在大量使用 AI 辅助开发。

00:10:41.120 --> 00:10:46.540
但从 iOS 26 到 27，我感觉这是最

00:10:46.540 --> 00:10:49.420
无聊的一次 iOS 更新。

00:10:50.760 --> 00:10:54.180
某种程度上，它反倒像是在反驳这种说法。

00:10:55.080 --> 00:10:57.220
其实我不觉得这是坏事。

00:10:57.440 --> 00:11:03.620
我不想看到功能像寒武纪大爆发一样疯长，最后做出荷马·辛普森那辆车。

00:11:03.620 --> 00:11:10.040
但这样我就得问：agent 编程带来的额外资源，是否至少能确保

00:11:10.040 --> 00:11:11.700
交付出来的东西质量更高？

00:11:12.740 --> 00:11:14.160
我希望如此。

00:11:14.380 --> 00:11:17.660
我个人希望这样使用 agent：

00:11:17.660 --> 00:11:22.620
交付速度大致不变，但发布的每样东西质量都更高，

00:11:22.620 --> 00:11:25.340
即便数量基本一样。

00:11:25.720 --> 00:11:29.660
这才是我使用 agent 工程工具想达到的目标。

00:11:29.660 --> 00:11:35.840
但我也不知道有没有改善。看看这些公司的可用性指标，原来的几个九……

00:11:35.840 --> 00:11:38.700
［此处可用性数字转写不清，待回听］

00:11:40.120 --> 00:11:43.380
我觉得在质量方面，可能有一点体现，

00:11:43.380 --> 00:11:49.840
当然也取决于你怎么看：软件应该更安全了，因为我们不得不

00:11:49.840 --> 00:11:51.540
处理所有这些安全报告。

00:11:52.380 --> 00:11:52.460
对吧？

00:11:52.560 --> 00:11:54.000
而且我觉得……

00:11:54.000 --> 00:11:57.780
但并没有。我可以用亲身经历告诉你。

00:11:57.780 --> 00:12:00.220
它绝对没有更安全。

00:12:01.660 --> 00:12:06.260
但现在把软件放到互联网上，风险确实也更高了。

00:12:07.460 --> 00:12:11.720
我们有个同事，现在更担心

00:12:11.720 --> 00:12:17.680
智能合约和加密钱包了，因为它们已经成了

00:12:17.680 --> 00:12:21.060
自动化安全研究特别有吸引力的目标。

00:12:21.060 --> 00:12:25.100
不过，

00:12:25.100 --> 00:12:30.400
我觉得确实有一些领域，平均来说，

00:12:30.400 --> 00:12:34.300
应该修掉了更多问题。curl 就是个很好的例子，

00:12:34.300 --> 00:12:35.240
还有其他软件。

00:12:35.320 --> 00:12:36.240
这些软件已经存在非常久了。

00:12:36.240 --> 00:12:40.780
它们收到了更多有效的安全报告，于是修复了这些问题。

00:12:40.980 --> 00:12:46.860
总体来说，curl 现在可能比以往任何时候都安全。

00:12:47.260 --> 00:12:49.840
而且它也没有往里面塞一大堆粗糙的新功能。

00:12:50.480 --> 00:12:55.560
但与此同时，同样的原因也提高了整体风险……

00:12:55.560 --> 00:13:00.640
问题就在这里：安全补丁仍然要靠人来验证和应用。

00:13:01.620 --> 00:13:06.020
可发现漏洞，现在却容易了一百倍。

00:13:06.320 --> 00:13:12.740
我刚让我的“铁皮脑袋”试着破解一个老产品的

00:13:12.740 --> 00:13:14.380
DRM，结果它就真做到了。

00:13:14.840 --> 00:13:17.780
完全没用我干预。

00:13:17.780 --> 00:13:20.860
所以，真是个有意思的时代。