王建硕×徐文浩吵架局：看代码是浪费时间，还是人机唯一的桥梁
- 发布
- 2026 年 7 月 14 日
- 时长
- 1 小时 32 分
- 主播
- 徐文浩、任鑫
- 嘉宾
- 王建硕
- 收听
- 小宇宙Apple Podcasts喜马拉雅
任鑫拉来王建硕和徐文浩对质：王建硕给自己定死规矩——不允许看任何一行代码，12 天在 TestFlight 发了 148 个版本，每次改动过 414 个 test case，主张 Python、JavaScript 已沦为汇编层，"if it works 就不要管它"。徐文浩承认也不手写代码、全程 prompt 驱动，但坚持代码合并前必须有人看过，治理靠"用自然语言生成、人审核过的确定性工具"。两人吵到 90 分钟，发现对五年后无人看代码的趋势判断一致，分歧全在"今天怎么办"——王建硕要的是那碗面条，徐文浩想开麦当劳。
- 王建硕的新金线是 if it works：只要不 break 就不管代码，改编译器编译出来的汇编毫无意义
- 他不允许自己看任何一行代码，十二天在 TestFlight 发了一百四十八个版本，break 的不到十个
- 徐文浩同样只写 prompt，但坚持所有代码合并上线前必须有人看过，且治理要靠自然语言生成、人审核过的确定性工具
- 重复代码治理之争：LLM 扫八处可能只看到四处，抽象语法树工具十秒扫全库并自动触发阈值
- 编译器比喻大战：徐文浩问写编译器的人怎么可能不看汇编产出与版本管理，王建硕没有正面接
- 王建硕称工匠精神在规模面前一文不值，徐文浩反驳精益制造本来为规模而生，work 不是目标是管理复杂度
- 徐文浩今年一到三月不看代码，AI 把测试全 mock 掉造成虚假 coverage，过去两个月团队一半精力在还债
- 分歧收束为位置差异：王建硕是吃面条的，徐文浩把公司本身当产品，目标是从一比十做到一比一百的研发杠杆
本期制作
- 剪辑
- 十六颗糖
- 片头
- Shortwire - Reconfig
- 片尾
- The Midnight - Los Angeles
目录
点击跳到对应位置
- 冷开场：if it works 与代码是唯一桥梁00:00
- 任鑫开场：把两位拉来当面对质01:46
- 手搓核心代码二十到五十遍的人，为什么跳到不看代码阵营03:32
- 徐文浩：同意一半，但治理靠自然语言生成的确定性工具07:39
- 王建硕：不许自己看代码，414 个 test case 加 loop 治理10:07
- 徐文浩：13000 个测试用例，规模一上去 prompt 就限不住14:31
- 编译器比喻大战：写编译器的人看不看汇编产出17:56
- 重复代码怎么治：定期跑 skill vs 语法树工具十秒扫全库20:20
- 工匠精神在规模面前一文不值：微信汇编赌局31:49
- 徐文浩三连反击：版本管理悖论、精益制造、管理复杂度37:20
- 分歧收敛成一个比例：时间的 95:5 还是 70:3042:48
- 打个赌：五年后还要看代码吗，type-c 与软盘的取舍45:39
- 任鑫的推土机问题：harness 优势每年被模型吃掉52:13
- Word 文档的 XML 你审吗：端到端测试大战55:03
- 徐文浩踩过的坑：AI 把测试全 mock 掉，work 可能是虚假的1:00:16
- 小马过河：AI 写得好还是烂，取决于你自己的水平1:02:19
- 位置决定视角：要一个 app，还是要一条产线1:06:34
- React 工程师之辩：过了桥就拆桥、屠龙之术与种庄稼1:12:09
- 总结陈词：吃面条的 vs 开麦当劳的，一比一百的杠杆1:24:07
文稿
共 1061 句 · 点段首时间或句子从该处收听，双下划线是重点词条，其他词条悬停可见
01:46大家好，欢迎来到新一期AI炼金术。然后这一期呢主要就是拉来了王建硕同学和徐文浩同学来吵架。那个，我私下聊的时候，他们纷纷表示了对对方的观点的不同意。然后作为双方的朋友，我的态度当然是：吵起来，吵起来。来来来。
02:03我们要涨粉，我们要吵架，来，我们要炒作。所以我就煽风点火地向他们相互之间说，跟徐文浩说，王建硕在背后说了你很多坏话，然后跟王建硕说，徐文浩在背后说了你很多坏话，听你讲的都是错的。然后把他们两个今天再拉到一块儿，你俩来当面这个治理一下。
02:21王建硕就说那个史山完全不用治理，那个都是老一代的想法，年纪轻轻的搞这种老气。然后徐文浩就是说，哎，你们这帮做CEO的，就就都两手不就都只会做demo，你们根本不管大系统，你们也不管擦屁股，对。来来来，这两方同学请吵起来。
02:39我就知道你在中间，就想尽一切办法，生怕事儿响。
02:46但是那你觉得你是觉得要治理还是不要治理呢？其实我特别好奇。这个，
02:50我我其实觉得你们没那么大矛盾。你们两个讲的其实是同一件事儿，但是不能这样子，这一期就不好听了。一定要苦大仇深的，就好像你们两个敌对。我就觉得有时候要治理，有时候不要治理，就这样吧。
03:05该治理的时候治理，不该治理的时候不治理，是吧？
03:32第一个我觉得首先文浩所说说的这个治理公共厕所这件事情肯定还是需要的，对吧？这个首先，但是现在在里头的东西，汇编也需要去用顶层的方式治理，就是最终让它稳定可靠，这个肯定是最终的目的。首先来说，我这个是一直是在第一线的，可能在我们公司里面所有的工程师里面，我是对这个代码的质量、代码的品位，
03:57然后就是核心代码一定要手搓，大概二十遍到五十遍以后，然后一行不能多的那种。对于代码的，对手写的代码的quality要求。至少是我知道的周围的人中间最高的一个啊。呃，以前一直一直逼着大家去一遍一遍地重构这个代码。但是最近来说的话，我反而一下就跳到另外一个阵营里面了。
04:21我尤其拿Claude Code这个密集的、没日没夜的，大概过去又写了，尤其我在最近在写那个VoiceDrop的时候，每天的Claude Code的工作时间，我没看，大概应该已经到12个小时了。因为前面是一个月平均是每天9.5小时嘛。
04:39呃，然后现在都已经到12个小时，也就是每一周来说已经80到90个小时的工作了，相当于double了工作时间嘛。但在这个过程中间的话，我就有种感觉是说，现在的无论是Python还是那个JavaScript，或者是Swift，或者就这些语言，在整个的这个层次上面已经沦为汇编的那一层了。
05:06就是上面有一层东西。这层东西不仅仅是你所描述的那个就是自然语言，当然也包括了一堆的harness，一堆的skill，一堆的check什么，反正就外面的各种各样的一堆的栅栏，这一坨东西，然后去形成下面那一坨东西。所以那一坨以后的话，我的基本上观点也蛮清晰的，就是说一旦编译器有了，就是一旦有了像C一样的C++一样的高级语言，
05:35就直接用手写那个汇编已经，第一没有必要，第二没有可能。然后去更改编译器编译出来的汇编语言更是完全没有意义。你如果从头到尾都是手写的编译那个汇编语言我也认，对吧？比如说有一些网络的kernel那一点点东西，这个我也认了，但是它如果是编译器编译出来的，你去改它干嘛？
06:01你干嘛不改编译器？你干嘛不改上面的高层代码，而去要改它的汇编？你改完了以后，你把一个move，MOV从你的这个append左边挪到了下面，那你下一次编译不就又没了吗？所以呢，我会觉得现在的我们以前所谓的高级语言或者编程语言已经沦为了这个汇编这个层次了。
06:25所以在这个层次的话，可能我如果准确地表达我的观点的话，是说不需要去做修改和去改变它。你说治理的话，你你上一层就是比如说编程的就是自然语言的这一层的做的所有的事情都是治理吧。换句话说，你的那个C语言，你写的好一点，它你的编译出来的那个汇编语言也会好看点嘛。
06:50你C语言不写for循环，你就print一直写一百行。写来print一百，那个汇编出来也是更屎吧，就是，所以从上一层是可以来影响和治所谓的要治理下一层的，但是不要在下一层去搞任何东西了，这是我的基本观点。
07:10不知道文浩同意不
07:11你的意思就是还是要治理公共厕所，但是不能自己去打扫。但是文浩好像也没有说要自己去打扫。
07:39对。就是我觉得就是建硕有一半观点我是同意的，就是我也是这么做的，但是我觉得可能我们的分歧会在很多就更细微的地方，所以我其实我也同意，就是我们现在做所有的治理，包括我说的所有治理或者流程，我也不是说我开一个编辑器我来手写代码，
07:57也不是Copilot辅助写代码，我也是在Claude Code或者Codex里写prompt。但是我其实会有几个问题，就是听建硕刚才讲他的这个工作方式，第一个是，那你现在让Claude Code写代码，你还会去看吗？就比如说他写的这个代码是你本身我云Claude Code已经有一层harness对吧？
08:17或者你已经有各种，但是他写完一个代码，你还会有一个说，啊，人会去审核一下，然后再允许他合并，还是说其实不太审核，这就是我说这有可能在细微之处有差异的地方。第二个是就是因为我听你的观点是你认为所有的harness都是自然语言嘛，但是我觉得其实不太一样，
08:38很多时候我觉得harness是我用自然语言生成的代码，是我的治理工具。就是因为自然语言在今天它还是非常模糊的，或者说非常不准确的，因为你如果只是通过一些prompt或者一些模板告诉他说在这个步骤一定要做这个检查，我觉得它经常会遗漏，所以最终我会用自然语言去生成一个确定性的代码工具去限制或者去来做这个治理。
09:08这个是我我的基本观点。第一个是我同意说现在不太存在，包括我自己也并不会去手写代码，或者甚至不会用所谓的Copilot这种方式，让AI辅助，都是通过prompts去控制的。但是我有两个观点，到今天为止其实我一直没有松口，包括我们内部讨论的。
09:28第一个是所有的代码都需要有人审核，就是要有人看过这个代码，我们才会合并到线上。但是看过这个代码不一定是line by line看，看的重点或者重心不一样，我说的就是说我们生产线上的这些产品啊。第二个我自己的观点是说，我们去治理这个东西很多时候并不是靠自然语言治理，而是靠自然语言帮我创造出来的工具，
09:52然后这个工具的代码我人审核过确定没有问题，然后靠那个工具去治理。我我现在去看待，你知道软件开发或者软件工厂的这样一个呃，核心思路吧，就是我其实没有那么相信自然语言。对。
10:07啊，这两个的话我也蛮多的思考，也是有很多的变化。当然这里面我的观点是这样的，第一，我现在不允许自己看任何一行代码，不允许，绝对不允许。就是，而且在过去的在写VoiceDrop，我现在都不知道多少行了吧，但是这个app的过程中间打开过几次吧，
10:30两三次，但是都是去看一个字符串，就看prompt的那个文字是怎么写的。除此以外，没打开过Xcode，甚至几乎没有在本机编译过。这一层就是Swift的语言以及Node的，就是JavaScript的巨量的代码。我如果想看任何代码，我的做法就是问Claude Code，说你把那个逻辑给我讲一下，这是现在的做法，
10:55到现在为止啊。我发现可行，至少到现在，待会儿我们可以再讨论一下东西，可能它规模还不够大，可能还是什么什么。但至少我觉得这是一个很serious的project的话，还行。第二个就是说你说的那个就是自然语言不够准确，但它的确会，就比如说我蛮喜欢Superpowers的那个skill的那个TDD的。
11:19就是比如说现在我那个小app的话，每一次更改四百一十四个吧，我刚才看了一下，四百一十四个test case。也就是说你做任何的更改，你需要test case pass。那四百多个，我老实说我以前自己写这种这种规模的软件，我自己没写四百多个test case，然后这些test case的pass就是试治理的一部分。
11:44但是呢，我会比较小心，不要过早地把它变成代码。就举个例子，就是你到底你要存的是自然语言的那套东西，还是说自然语言把它形成一套，无论是Python代码还是什么JavaScript代码，然后由这个代码以后跑这个代码，因为代码是百分之百有确定性的，对吧？
12:05然后由这个代码去来治理很多东西。我本来在上个月吧，在我写那个VoiceDrop之前，我基本上比较喜欢说什么东西结束的时候，我说都给我沉淀成一套系统，沉淀了。但后来我会发现，第一，这种方式会，就是这个代码的质量没有大语言模型好。
12:28就是反而会有的时候会出bug和不确定的东西。第二，因为如果大语言模型的文字的那一部分，因为它是一个loop，一遍一遍地转loop，它有可能会需要转个十几个小、十几分钟。甚至昨天就是我做那个feature，从下午两点做到七点，它花了五个小时，就那样转一圈一圈一圈转，
12:50然后fix fix，就是就是一个feature，它就五个小时，一个feature就五个小时。它它真的转了很多圈，碰了很多壁，然后就改了很多东西。但是这整个这个过程，因为它是自然语言的，它是在一个harness里面，所以它会很灵活。
13:05但是我在想，如果要是我是自己编译出来的东西的话，可能它就最多三分钟就搞定了。因为你你run一个程序，怎么着也大概二十秒钟差不多吧，一分钟两分钟差不多了。那它基本上是写死了的。所以我会发现它的准确度和最终的quality，和现在用harness转五个小时出来的东西是天壤之别。
13:27所以现在我大概VoiceDrop，我现在已经是，我刚刚装的是一百四十八版吧，就是它整个在TestFlight里面发了一百四十八个版，在过去的十二天发了一百四十八个版，其中大概break了五六个，反正肯定在十个以内，大概五六个是发版的时候在CI那个地方break的。然后在此之前，它至少在线上TestFlight在提交给App Store的那一刻没有break。
13:58这个其实我认为是quality的一种啊，我以前自己写程序，我从来没有过这个写完了以后不break的这种情况。所以这两个的话，我会，反正我的答案就是，第一个是我不看代码了。第二个是说我就用，一定不是用自然语言来控制，因为自然语言不准确，但是你一定要用loop来控制，
14:20就是让它转圈，转一遍一遍地转圈。然后定义好
14:24你的这个loop，它还是用自然语言来控制吗？我理解，
14:27就是自然语言。是的。
14:28你的loop的控制还是以自然语言来控制嘛，对吧？然后，你刚才讲了一些数字啊，那那听到这个数字，我们要激烈起来，就我完全不同意你的观点，就是我觉得不看代码是完全不行的。因为我可以告诉你我现在的代码，我刚才我还特地看了一下我的代码库里，我有多少test case。
14:46我的端到端test case就有两百多个，我的自动化的unit test case，我们项目一个比较核心的库里现在有一万三千多个。我我觉得四百多个test case只能说明这个repo太小了，或者说这个代码的复杂度本来就很低。从这个角度来讲，我觉得这样的产品它当然可以，你不做治理，或者说也不做这个用自然语言治理就够了，
15:08因为它的复杂度本来就不高。那么对模型的智能来讲，它的确完全可以handle得住。但是你只要一旦你的代码规模上去，你的项目的复杂度上去，这件事情就是不可靠的。就是我们其实也经历过说，就是疯狂Vibe Coding的时候，那个时候其实人更多，但是我们其实过去两个月中可能有一半的精力就在花在解决当时Vibe Coding带来的问题。
15:34因为今天模型的context window其实还是很小的，它基本上智能也是有限，它基本上就一个million的token。就是一旦代码量上去，我觉得很多问题会疯狂地被暴露出来。我我举个例子啊，就比方说你让它写Python。
15:49我我典型的，比如写Python或者写JavaScript，呃，写Python它非常典型，它任何对API的调用处理，在一开始写code的时候，它全部是当成一个dict来处理的。就它不会去建对象模型啊或者怎么样。这个问题就回到这里。
16:03如果我不看代码，它今天可能是work的。你也看到了，然后它可能它突然有一天你不work了。然后这个时候其实你根本不知道问题在哪。如果你看到了这个问题，其实你当场就可以去指出这个问题。然后指出这个问题，你就可以，第一个也可以通过prompt去确立它。
16:20第二个是当你的代码规模到一定规模的时候，你会发现prompt也限制不住，因为代码规模很大，可能它会漏。漏了之后就很尴尬，就是它新的代码有些会这样写，有些会那样写，到后来这个代码就基本上就处于一个比较难维护的状态。所以从我的视角来看，这个不治理基本上是不太可行的。
16:40第二个是说，当这个代码规模上去，你用loop去检查，它消耗的token跟时间其实就更长了。我一个确定性的时间跑，比方说我现在test case是一万多，可能是你三十倍，那你可能跑五个小时，而在我这个代码规模下，它可能就得跑十五个小时。
16:56那我肯定是接受不了，它其实拖慢了我的速度，那我一定要找一个更确定性的方法来解决这些问题。就是我觉得不看代码取决于这个事情是干嘛。比方说今天我写一个明确性的工具或者脚本，或者我很多时候在给我自己的Open Code写一些skills，
17:14我其实也不看这个代码，对吧？它可能就一百行，我大概看一下prompt是什么，那个代码的Python脚本我可能也不看，因为对我来讲它错了也没什么关系，我明天再去解决它好了。但是对我要最终要上线的产品，然后它代码量也很大，这个复杂度也很高的情况下，我觉得不看基本不太可行。
17:34就我是认为不看那就是出了问题也不害我飞锅嘛，因为你又不能把OpenAI开了，对吧？也不能把Claude开了，他他把你开了，你还得求着他想办法再买个新账号用，对吧？我我是觉得说，一旦有一定数量的用户规模，一旦这个代码的复杂度有一定规模，至少今天的模型还做不到让你不看代码。
17:56第二个，我觉得一个就像你说它是个编译器，但我觉得是这样的，如果你觉得你在写编译器，任何一个写编译器的人是一定会看我写的C代码出来的汇编是什么样子，我才知道我的编译器写得好不好。不存在说我写编译器，我编译器写好了，代码跑出来，它跑一下能work，我觉得我的编译器就写完了。
18:17你一定是可以看我生成的目标代码长什么样子，来判断我的编译器写得好不好。我可以不看，我可以不改我的目标代码。但是我不可能不看我的目标代码，因为不看目标代码，我怎么知道我编译器写得好不好，对不对呢？我我其实之所以为什么我说我认同一半的观点，就是我是包括所有这些东西我都是通过prompt去写。
18:37但我觉得你如果想做一个严肃的项目，你不得不看代码，你也不得不通过一些工具去去聊，不能全把这个东西就扔给ChatGPT。
18:47刚才你说的那个harness，就是治理这件事情，我首先我同意治理啊，只不过我们的分歧是怎么治理。你是通过看代码的方式去治理，我们可能在提的不是同一个AI。不是同一个AI，是什么意思呢？是说你说AI会写成什么样的代码，你指的是不做额外干预的裸跑的Claude Code，
19:16不是，不是，我我用Claude Code，我自己我也用Superpowers，我自己还定制了一些hook，我有自己的prompt，包括我到线上，我任何一个线上都到，任何一个代码在我们这里都会进GitHub的PR。我同时有Codex跟Claude会自动给它做code review，并且我会自动让AI去看它的code review的反馈，
19:39直到改到它没有负反馈为止，而且它也有自动化测试。但是即使是这样，这个PR在合并之前，我会看那个代码，虽然不是line by line的看，我会去看一下它是实现了什么东西，它大概是怎么实现的，它的大概大的代码结构是什么样的。
19:56我可能不会line by line看这个函数写的对不对，但它到底在改哪些东西。我会去看，我我用Claude Code，我有一系列自己定制的skills跟harness跟hook。我们整个研发流程中有靠CI/CD驱动的各种各样的harness跟hook。
20:13但即使是这样，这个PR在和这个merge request或者pull request在merge前，人仍然会去扫一眼。
20:20对，这块来说的话，我的看法是说，就是刚才我们所说的不用dict啊等等这些很多的一些做法，它缺省呢，在慢慢的累积代码的时候，它一定，我会觉得这智力就跟人一样的，它一定也会犯错嘛。比如举个例子，你随时你去把那个代码拎出来，说你去给我审计一下里面有没有在多处一模一样的代码copy paste，
20:46对吧？就是到底有没有可以去把它给，就是抽象合并的这些东西。他一找，一大堆，他自己当然找得出来，一大堆到处都是，说然后跑过来说这件事情出现了十个地方。每个十个地方都是一模一样的代码，所以我需要把它给抽象出来，等等等等。就类似于这样的东西，我觉得我们会需要花更多的时间在这个层次上面来工作，
21:13来解决这样的问题。代码的duplication就是这个问题嘛，从结构上面这个问题，对吧？耦合是个问题，就是因为整个我们软件工程里面所经常性就是代码质量不好，然后没什么经验的工程师常犯的无外乎就是这个代码copy paste，
21:31然后没有没有封装，然后这个耦合度太高，然后中间的接口的不清晰，反正等等。就是我们有经验的人可以列出来十条二十条最最重要的这些principle。那这些principle呢，我觉得每一次都在代码层面去fix不是最釜底抽薪的fix方法，而是要把它放在更，
21:55就是更高一个level，而且它不见得是每一次，而是说每隔一段时间来做。比如重构的话，我也不认为天天需要重构，可能每隔个什么一个月你要把你的代码重构一遍。包括那duplication，如果没有duplication代码的话，就说明刚开始一定是overdesign了嘛，
22:12对吧？一定出现两三次以后，你才意识到说，哦，这个地方需要，就是很多地方才觉得它应该去合并。那这个东西都是要在代码层上面来工作，而不是在代码层上面看到了这里有duplication就去解决duplication。
22:28我我完全同意你说的这个，但是我觉得就方法上就是我觉得差异就非常大。第一个是比如说duplication，就像我说的，我不是靠prompt去解决的，我靠的是我用prompt让他去用我的detect duplication的工具。这个在传统软件工程中其实有很多现成的产品，它做的方式是一个确定性的方式。
22:48就我不认为它应该用个自然语言的方式，它用的方式是说我把我用呃抽象语法树，我解析这个代码，然后我根据比如说每多连续多少行有重复的这种语法树上的token出现，我可以detect出一个重复率。所以我的paradigm里是会在线上会detect重复率。
23:08超过多少就会自动触发说你必须把它降低到多少，所以我觉得所以这个是我说的，我我的逻辑应该是用prompt去生成工具去解决这个问题，因为它才是确定性的，它才是扫到了所有的代码，因为让prompt看很容易看到说八个重复的地方。我扫到了四个，那四个我优化了，另外四个我没管。
23:28那四个我没管，你会发生一个问题，就是下次我去改代码的时候，哎。那四个一样的地方我看到了，我改了一个函数，就比方说，在这个功能上，这个逻辑是正确的了，但是还有一些有点，其实原来跟它们是一样的，现在你没改，这就是暴露了一个新的bug，对吧？
23:44这是我说的，我不相信自然语言，因为有很多在传统的软件工程方式里是有确定性的解决方案的，而且今天你通过自然语言去生成工具或者配置这些工具，能更好地解决这一类问题。这第一个。第二个，我认为我自己认为为什么要看代码，我就觉得这个就跟精益生产跟精益制造是一样的。
24:06第一个是你说duplication这个事情，你不看代码你怎么知道它发生了duplication呢？对，我觉得你刚才这个说法是自相矛盾，你的第一个逻辑叫做我不看代码，第二个当这件事情发生的时候我再去解决。那么你不看代码，你怎么知道这件事情什么时候发生了呢？
24:23我问他呀。因为我知道他一定会有啊，这都是这个很多年的这个经验呀。
24:30你什么时候问他呢？
24:32这就是，这就是说，我发现Superpowers应该再再继续这个再加一些功能的地方。比如Superpowers里面没有这种，嗯，从这个维度去看那个代码。所以的话，我就需要自己做一个skill。我有一个就是quality skill那个skill set，里面其中有一个就是说关于duplication代码的这一部分，
24:53然后定期的让它跑一跑。我也不想让它每一次都跑，因为成本太高，没必要。就是，主要是花时间。
25:01问题是，问题是你像我把它变成那个工具，它每一次跑大概就是十秒钟时间。对。
25:06就是首先来说你用它变成一个工具这件事情我同意的。我没有说不同意这件事情，如果你有工具当然就好了。但是我的意思就是说，你用工具来看这个代码，它也不是一行一行看代码，而是在更高层次上面看代码。就是在Claude Code举个例子，你问他说这里面有没有duplication，他肯定不是把那个你的所有的行的代码全都load到他的那个e-mail contact里面去，
25:37然后用他的小脑子算嘛。就是我觉得现在你基本上Claude Code的解决方案全都是用你所说的那个写程序来做，只不过唯一的差别是说你写了一个可以不断复用的system，然后呢，甚至这个都是很长时间以前做的，然后交给他用，他是每次都现写一个。
26:00就比如说他就是拿这个grep和一堆的那个json相关的那一堆东西现写嘛，对吧？你问他什么问题，他不都现写一段code，然后你去run这个python的程序，这个代码吗？就是他现写的这个东西不够强壮，你可以让他把它给抽象出来，甚至说他现写的他肯定没有现成的工具好嘛，
26:21对吧？就是我的意思我也没准备，那问题比如说我让你去做一个视频处理，他现写一个FFmpeg出来，这也没必要。你就直接用那玩意儿，你就不要现写那个编解码了，这个我当然是同意的啦。就是包括那个大语言模型，我也不认为它可以用模型在脑子里面能给我算出来视频的这个解压缩，
26:45这个就转码对吧？它everything到最终一定还是就是刚才我们所说的这种真正的干活的一定还是代码，只不过这件事情我觉得已经是这个时代的common的今天应该做的事情了，对呀。所以我就觉得这个就是未来的工作方式了，已经没有什么这个悬念了。
27:46你软件开发也好，或者你做任何一个东西也好，你本质上你也得解决一个事儿，就是你得控制复杂度嘛。就是你本来这个事情已经很复杂了，那你尽可能地让你本来确定性的东西，你尽量不要去管它。尽量把精力花在说不确定性的东西上。
28:06对吧？就是说，就像你说我的价值是我的经验吗？我觉得其实如果过去说经验价值比较大，今天的他的经验更多的体现在我一想就能想到的事情，我本来都已经放在harness或者这些workflow里。但是呢，今天更有价值的是就是因为我不停地在看生产线上发生了什么事情，所以哎，我发现这个生产线或者这个产品可以进一步地优化，
28:32本身变得更有效率。就我回到前面，就是我我其实还是不太同意建硕的观点，就是虽然看起来，如果从表面上讲好像我们说的是一样的，但是我觉得其实差别挺大的。就是看起来好像我们都说，哎，我们要治理。然后哎这样让比如说我用模型是现写工具还是生成工具的差别啊，但是我我觉得有几个点我觉得差别挺大的，
28:53在于说我其实觉得它其实比较像精益制造。那像精益制造的核心逻辑是说第一个它不是个固定的流水线，就是说我只要把这个流水线搭好，反正它就在那里就不停的生产就结束了。我觉得精益制造更像你在现场说去造这个东西，你会遇到各种各样的意外。
29:12然后呢，一个是你现场需要解决这个问题，第二个你会去思考你这个流水线或者这个流程怎么做一些优化，让下一次出现这些意外比较少发生，我的效率本身能变得更高。第三个呢虽然模型非常强，那我们其实同样希望在我们有限的时间里去做出更有价值的东西。
29:32那有一部分价值往往体现在说我要做一个别人把控不了的死难度，就像今天你说我做一个blog，做一个个人网站，你可以一句话我一shot就出来。但这件事情本身就已经没有价值了。
29:46你就必须得做一个更复杂的事情，你才能在开始。那么这些简单的事情我能不能不要消耗我的token，不要消耗我的时间，不要消耗我的精力，固定好的自动化工具。第二个是我既然希望这个产线不断地优化，我那能不能就是就像我时时刻刻都在看这个产线上发生什么变化，
30:08随时都给它去做各种细节上的调整跟优化。我唯一我同意的是说，我虽然会说这次这样改，但是我其实也有一些工具会自动扫，说历史上我们改了什么东西，你帮我总结出来，所以我应该去上架一个什么工具。但是我会比较倾向于说我尽量让这些工具能跑得比较快，这样我才能在我有限的token和精力时间里做出更多的东西，
30:36会做出更复杂的东西。因为有大量的事情，我认为让AI去做，它既不确定，又很浪费时间，不如试试看，试试优化。其实试试看的目标就是为了试试优化。
31:33假设我们觉得我们在做编译器，那么我一定是会看编译器的产出的。就是不看编译器的产出，或者不看我这个流水线的产出过程，我是没有办法去思考怎么优化这个流程的。
31:46不然不要就是造这个吃饭app，好像就不需要这个。
32:30我觉得这只是个比喻啊，你可以说我不在做编译器，但我可能在做IDE。我一样要去看，就是这个IDE怎么操作，操作出来的东西是什么东西。但是我只是口喷说这IDE长什么样，那个我觉得那它产物你不看，它做不了做的东西跟你讲。
33:33这个就是你这个ID主要去会会跟的，这两个差别太大，我们就不要打比喻了。我只是在会觉得说，我我不同意我们叫精益制造。因为就是我这两天感觉呢，就是工匠精神在那个规模前面一文不值嘛。当我们的代码在一定的范围里面，就是我们为什么要有很多时候我们自己要看代码，对代码质量进行要求。
33:58它如果是work的，它如果能管理。那就不需要去管理它了。为什么人去，就是我们这帮老程序员为什么那么在乎这个代码风格，在乎这个结构清晰，在乎软件工程里面那些原则。因为那是基于everything都是人脑去管理它，然后人去读它。
34:22然后很多的东西，就是对于人来说，是如果不那么写，人脑将无法处理。举一个最简单的例子，那个我们要求所有的人，比如说C语言也好，JavaScript除了Python以外啊，你的这个回车，还有空格，对吧？空格还有type和space，对吧？
34:46然后那个那个你这个这个中间要写comment等等这些东西。但是这个要求是因为这是为人读的。那如果要是说现在的那个，如果真的就像那个混淆过的一样，你把所有的空格和所有的回车全去掉，人就没法管理了。
35:05但是大语言模型对这个事情其实它不care，就等于它生成它读的和生成。他care，他care。他开这个原因是因为他训练的语料是这样子的。如果他训练的语料，他的所有的回车跟所有的空格这些东西全都打没有，他就不出现在语料里面，他的所有训练出来的结果是一样的。
35:27因为他之所以care。因为他在训练。所以我就问你个问题，就是我们做的很多的事情中间，我认为这不是零和一啊，它是一个频谱。但我们仔细想想，我们对代码的关心里面，到底有多少仅仅是因为为了人看着可理解、可维护，而这个的标尺全是人。
35:47但如果是机器的话，它的可维护、可理解的bar和人有的地方会高，有的地方会低，反正肯定会不一样。那么它的标准就一定是不一样的。那到底新的标准是什么？我的新的这根金线就是if it works，它只要work，就不要去管它。
36:08就我给你打赌。如果要是我们俩静下心来，把那个微信的汇编语言打印出来，我不知道那个应该是几千万行的汇编语言吧。然后认认真真的去读一读它，它里面一定是疯了一样的重复，疯了一样的读不懂。然后超出我们两个的所有的智能的这个不可理解。
36:35那对你对我们来说是个问题吗？不是问题，原因是说，如果这东西没有它的C的源代码了，这是个问题，因为你再也没法去改它了。只要有C的源代码的情况下，下面再混乱都没关系。同样的道理。
36:52对于我们无论是C加加也好，对于我们现在无论是Python也好，C加加也好，对吧？这种代码只要在上一层是可以控制它，改变它，然后比较一致的能出结果。你管它下面写什么呢？唯一有一个问题我同意你，就是你在上面改，你已经没法出结果了，就老break。
37:13这我觉得要管。这是我们两个我相信我们一致的地方。他只要不break，我就不管他。同意吧？这你同意。
37:20因为他只要不break，我不同意，我完全不同意。我来跟你详详细细解释一下，为什么我完全不同意。还是回到你那个汇编，比方说，那我问的第一个问题是，你现在你的这些code有版本管理吗？
37:35版本管理当然有。你一个个版本。
37:38那他就不是汇编。
37:46就是你说的这些代码，你还会去做？
37:49你说我现在生成的。每一次提交啊，
37:52对。如果你觉得你是它不重要的，你觉得那个prompt才是源代码，你只要存那些prompt就好了。你为什么要存它的产物呢？如果我实验一期，我。你把那个东西，我可以再，对不对？
38:03这第一点就是今天一个prompt每次生成出来的东西就是不一样。你没办法控制它exactly一模一样，这是你为什么人要做版本管理。我觉得大概率你遇到一个东西break，你不是退回到上一个版本，再下一个版本用原来的prompt重新生成一遍。
38:19你还是会退到那个源代码去做model。所以我觉得编译器这个比喻本身就不对，这是第一个。第二个。我们回到说，你说要规模，你说的没错，因为精益制造本来就是为规模而生的。精益制造原来做的最好的就是丰田造汽车，所以他为什么，他就说我因为大家it works是没有用的，
38:40因为你有work，我也有work，但是我们最终是制造了一个产品在市场上竞争。如果我做的比你更快，我做的比你更好，你的虽然也work，那我就会卖的更多。对不对？这个就是it works的东西并不能参与并不能保证你能参与市场竞争并且解决问题。
39:01就是精益制造的原因是丰田说我找到一个方法我能更快更好的产出高质量的东西卖出去，所以需要精益制造。它本来就是为了规模而生。精益制造并不是传统的手工艺，对吧？找一个什么工匠精神，什么米饭仙人，来保，只能煮一锅饭，只能开一个小店。
39:19它本来就是为规模而生的。第三个是说，那为什么我认为it works这个逻辑不对？我觉得，对的，我们去管理代码，就软件工程或者软件开发，它本来不是写代码，它本来我称之为这个，我忘了是谁说的啊，反正应该也是叫，我这叫manage complexity，就管理复杂度。
39:36你就是尽量让一个东西的复杂度变低，它就比较容易管理，我就能管理一个更大scale的东西。就是我如果我今天只能做一个blog，我是没有意义的。我今天其实能不能花更短的时间做出一个iPhone，或者说就是做出一个macOS。
39:52那我要做出一个macOS，它的代码规模一下子就大了。很多个数量级。那么在这个数量级下，我觉得模型目前没有办法说one-shot或者few-shot，我一天就做完，我就得去管理这个复杂度。如果我能管理这个复杂度管得更好，我可能十天二十天就做出来了。
40:12如果说我相信模型，那你可能要学个三个月，那你其实市场竞争人数了。这个就是我觉得模型不管怎么变，就是人去读它，也是因为管理复杂度，就是我人脑放不下这种复杂度。但是AI虽然很强，但是它单个agent或者单个loop，单个agent loop里，它能管理的复杂度仍然是有限的。
40:34那么怎么让这个管理复杂度能在一个更大的scale上去work，就是为什么要治理？那怎么能治理得好？我们今天没有太好的办法，只能人去看。至少今到今天为止，模型还是会犯各种各样奇怪的错误。那当然一部分是因为人的prompt写得不好，对不对？
40:52但是你没有办法让人一下子就变成说每个人的prompt都写得非常非常非常精确，非常好，对吧？甚至某种程度上，因为模型能力太强了，你有时候会偷懒，那prompt本来就写得没那么精确，就会写得比较简单。所以这个就我是个“人类中心主义者”，就是为什么coding训练的时候，就是用人的code，因为本质上我们还是希望它是为我们人类服务的吧，
41:19不是人类为它服务的。不管模型怎么进展，它始终会面临这个问题，就是因为大家都是竞争的，它不是一个考试，对吧？就是卷子做一百分，交到一百分就结束了。本质上是很多人在互相之间在竞争。那如果我用了一些策略的方法，我能做得更快更好，那这个方法就应该用，而不是说反正它work就行。
41:43这个是我的观点。
41:45我先说我同意的部分，就是你只要有办法把我们整个这个系统做得更快更好，你觉得这个世界有人会反对吗？
41:55有没有人反对啊？
41:56对啊。所以从这一点来说的话，我们没有分歧，对不对？就换句话说，你说了一个没有人会反对的观点。
42:03我这个观点是说，work不是目标，work也并不达成我们的目标。
42:08我会觉得就是刚才我们所说的，我为什么会问这个问题呢？就是说我们需要去分清楚，就是不是所有人都同意，但是我们到底在哪一层产生了分歧，对吧？对于整个系统将来要又快又好地把它写出来，呃，这个我和你当然是，我不相信世界上有谁会在这个层面上面不同意，
42:28对不对？整个系统又好管理，然后又又又省钱，然后又快，然后出来质量又好，对吧？这是所有人的目标，对吧？这个我们肯定是一致的。那么接下来的问题就在于说，到底就是它不是一个work上面大家的分歧，是一个how上面的分歧，
42:45对吧？怎么达到，对不对？对。那怎么达到的话，那么下面的话就有两层，一个是在这条层，我画一条线，这条线就以代码，对，看不看代码这根线吧，一个是代码以下的，我们叫水面以下的东西，对吧？
43:02一个叫水面以上的东西。我们现在的冲突点是在于说，我们的精力到底应该放百分之，因为它不是零和一，对吧？你说你要看代码，你肯定不是说不看上面，你上面做的东西也很多。我说我不要看代码，我也不是说绝对一行代码都不看，我现在逼着自己一行代码都不看，这是一个习惯的转移。
43:24就明明很多时候我知道我去看一下代码会更快，但是我都是问那个Claude说，你给我做一个report出来，而不要让我自己去看代码。这个我认为是在，就是我未来的半年里面，我认为我给自己定的死规矩，就是当你在做一个巨大的浪潮的转移的时候。
43:41你必须逼自己干一些事情，这不见得是最优解，但是一定是要这么逼着自己才能真的转过来的。就比如说我们现在，我那个那个我在做那个app里面，就是就写文章，我现在在逼着自己是绝不用键盘，就是在做所有的工作里面。就是我现在公众号文章，虽然最近的我的公众号文章发得越来越水啊，第一个没时间写，第二，的确是在这个这个在写文章的时候，
44:07你需要刚开始在学习的过程中间，就是怎么样做到完全不碰键盘的情况下面去完成写作，这个其实是难的，虽然尤其在早期的时候啊。就刚才我们所说的水面之上之下，它是个比例。但是我认为这个中间，我觉得我们的分歧是在于，我会觉得我们应该把95%以上的，有的时候我觉得100%就得抬杠了，
44:32但是我觉得95%以上的时间花在这个代码层以上，就是所谓的，就是如何去生成这个代码的这一层，最多最多5%，最好是1%，甚至有可能未来有一天我觉得会到0%，就是你完全不用关心代码层以下的这个东西。这是我觉得是我们两个我现在听到的最大的分歧。
44:54我也不认为说你说95%是在代码层，5%在上面。那就是纯粹的古法编程的，坚守在最后的那一些，这个顽固不化的工程师们了，对吧？我，你也肯定不是这个，我觉得你是比较balance的，应该是说50%在上面，50%在下面，大致是这样子。
45:12甚至有70%在上面，30%在下面，大概。
45:16这一比例，这个事情很……
45:17就是这个比例没有意义，但是就是表达一个就是到底它是一个就是花的时间的，或者说attention这个分配吧。因为我们其实都是一个比例上面的差异。但即便是说在代码层花30%和花5%，我觉得这也是一个巨大的一个观点上面的差异了。
45:35因为在这一层上面来说，到底花多长时间，它其实有的时候是质的变化了。那这个时候呢，我会觉得，我们我觉得可能打一个赌，就是说我们就看未来，就是过了五年以后，到底这个世界将会变成什么样子。你如果说今天，就我的这个approach还缺很多东西。
45:57就是所以我现在就是有很多时候是在有点像学自行车，一遍一遍的摔跤，别人都已经走路走很远了，我还在那儿地上摔着呢的这个过程。但是呢，我认为这种方法，这种面向未来的方法，虽然它必然有一个前提，就是说不着急，就是你有时间这么去折腾。就我们不用看五年，我们说五三年前，老实说，我们现在这条路根本走不通，对不对？
46:24就是我们所说的，就是不看代码这条路。在三年前的代码，这个模型能力以及这个这个Claude Code还没有出来，就是这个harness的整个这些能力都没有的情况下呢，你就拎这个ChatGPT想这么干，这个三年前必死。从三年前到三到现在，我们看发生了些什么，我们再去预测未来的五年的话，我会有十足的confidence是说，
46:48如果现在还需要看一点代码的话，未来一定是越来越不需要。这点的趋势你是不是同意，还是说你认为即便到了五年以后？
46:58我同意啊。对，我这个趋势我同意。
47:00所以我们现在讨论的不是一个趋势问题，而是一个现状问题。今天这个点我们应该怎么做，对不对？对。那所以的话，其实我觉得我们两个的approach呢，是在苹果在Type C刚出来的时候，要不要取消Type A的这个老的USB的那个问题，
47:21就是最早的时候要不要取消软盘和光盘的问题。那如果要是回到现在这个问题来说的话，我认为你的那个方法肯定也可以做。我的这个方法做起来也很痛苦，但是也不能说完全不能做。唯一的问题就完全就是，即便是就出各种各样的漏水嘛，你漏水了以后你就修，漏水了以后修，反正它也是work的。
47:44但问题是在现在这个时候。我们应该选择一个面向未来的，就是如果要是同样花时间的话，我们应该去训练自己，自己这个组织，包括自己的这个所有的工具集，到底是为未来build还是为现在build。但是这里面就是有一点站着说话不腰疼啊，就是有的时候叫磨刀不误砍柴
48:08工，就是如果要是我没有那么急迫的。明天就要上线的这个压力的情况下，我肯定要花时间是面向未来。但如果要是明天就要上线了，然后就未来的这种方法今天就是不work，它就是出不来。那你不得不的情况下，我觉得也看一下代码，或者用这种方式也未尝不可。
48:30现实的问题你不解决，然后你去面向未来，这也是这个不合理的嘛。但是我如果要有选择的话，我现在的选择就是逼迫自己。我指的叫逼迫，因为现实的考量肯定有比它更轻松的路，但是一定要逼迫自己在这种转型的时候，能不看代码不看代码，能在上层解决上层解决。
48:52能用loop用这个，就是在上层用所谓的agentic的方法去解决问题，就用上层来解决。这个东西其实比你刚才所说的那个，就是所谓今天的方法来说，有点难搞。我同意，有点难搞。搞出来的效果也不见得那么完美，但是我只坚信一件事情，就是说如果花时间花在这上面是值得的。
49:18花在看代码，哪怕看再少时间的代码都是浪费时间。在现在这个年代，在今天这个时间。
49:26我觉得有一个核心，就是我觉得其实可能我们对未来的设想都是一样的。但是我们对于今天怎么做有一个比较大的差异啊，就是你做了一个选择。可能比方说你说你觉得说五年以后会那样，我今天就用五年以后的方式去工作，对吧？但我的想法是这样的，就是其实五年以后会，比如说大家都不写代码，是因为有人在这五年之间在迭代这些自动化的流程。
49:56所以五年之后。你也可以不写代码。如果我自己在迭代这些流程，那我能不能让我的公司跟团队在三年内做到看更少的代码？就是今天完全不看代码，我觉得肯定解，就有很多问题它就是解决不了。那为了让接下来看的代码越来越少，那你其实就是要不断地看，就是不断地去找到说到底哪些模型能力解决不了或者怎么样，
50:24然后把这个工具更早地比其他人build起来。我们举一个例子啊，就是这个例子。比如说以Manus为例，如果我们以终局来看，Manus这套产品没有意义，肯定它所有的能力都内化在模型里了。
50:39对不对？但是如果这些能力都内化到模型里了，我是选择说我就等这件事情，还是不是的？我做的这些事情，因为别人看到了也会把它训进模型里。但在这个过程中，阶段性我一下子有非常大的优势，所以我在这市场上能够通过竞争或者什么样的方式获得回报。
51:00也就是我不觉得说因为五年以后就都用模型了，所以我今天就应该选择一个这五年时间我不管，即使我什么也不得到，我可能五年后我也有时候我觉得是个，那我能不能在这五年时间中，我做一个使得五年那个未来能成立。也有我的一份努力，以及我能比其他人更快地做到那一点。
51:23我认为我去看代码，去做所有的治理，其实目标都是为了让内部的人看更少的代码，但是今天他就是做不到不看代码，对吧？就像这样举例，就像你说的，可能我们不是一个基模公司，但你可以做一个今天市场上有很多非常好的做code agent的公司，
51:41在美国特别是这样。其实虽然有Claude Code，有那个Codex，但美国也有很多人在用Droid或者Amp Code。那这些人其实就是在做工具，让做一个第三方的code agent，让code这个事情变得更好。而且除了他们的token，你没有办法。
51:58他不是第一方的厂商，他的产品其实在市场上其实得到了很好的反响。但是他们做这件事情本身使得未来可能就是别人对着他们的意见说一句话，这个东西就出来了。但是总要得有人做这个事情，这个事情不可能凭空掉下来。
52:13因为我希望他这边赢嘛，因为我不懂嘛。从小白的观点的话，徐文浩这边万一是真的的话，对我没什么好处。所以我讲一个，就是因为其实像我们现在传统的企业的话，其实你的竞争力来自于哪两个地方嘛。有一些比如说阿里铁军，他是靠管理嘛，我同样一群人我就用的比你好，那其实就是你认这条路嘛。
52:34还有一些人就是我们很会搞营销，比如说我其实搞得定市场侧。那如果从未来我们不讲未来终局要不要等，那同样你有一天有八个小时时间，你要把中间的时间你拿去，比如说有两件事，一个就是你去把你的那个你的agentic coding system变到比别人提高一倍的效率。
52:53另外一件事情是你把你的比如说营销，你做个IP，然后把营销广告打好。是不是应该更多的在面向用户侧的，他可能要十年之后他才会被吃掉。但是coding的这个比如说200%的效率，他每年会被吃掉20%。比如说模型每年升级，你就会发现你现在比我强一倍，然后明年你就比如我只强80%了，后年你就只比我强60%了。
53:16这件事情上是不是你在做这件事情，我不是说这个是有价值的，但是你的同样的时间如果花在比如说你去搞IP对吧，或者你去美国去搞social，搞这个，你全部花在用户侧那边，是不是它其实暂时来看啊，虽然我觉得未来也会被吃掉，但是这边被吃掉感觉就是一个五年的确定性的事情。
53:35那边那个比如说用户侧什么用户洞察什么乱七八糟，这个被吃掉。感觉它是一个十年往上的一个事情。那是不是你同样的时间花在那边的话，其实会更有价值呢？因为那边没有一个推土机在你后面赶着嘛。但是你这边的你的建设都是有价值的，你让你的效率就是比隔壁翻倍了。
53:53但是会不会明年他啥都不干，他就把你翻倍的里面50%退到了，后年你又要往前再前进一点，又过了一年啥也不干，又到了一部分。所以你在上面这种harness的效率的system的提升的话，不如把所有的精力比如说全部放在那个market opportunity discovery这些东西上面。
54:11我我我觉得你讲的一部分有一部分道理，我觉得两个。第一个是今天做marketing，其实你也是做一个像software factory一样，一个自动化的流程在做。你看没有人在做marketing的逻辑，今天所有做营销的人做的最头部的其实也都是用Agentics的，
54:28其实最终还是会变成一堆skills或者code或者tools或者怎么样。其实你还是得要去做这个东西，就并不是这个东西今天说做marketing是说不是的，我code都不要了，或者我简单就口喷两句。大概率你还是搭一个说啊，我要搞个skills，我去找到我关心的那些public，然后我有个skills把它转成我要的那个文章。
54:50只是它可能更自然一点，对吧？而且大概率我觉得那些东西的产物你一定也是会看的。他写的那篇文章你一定会看一遍才发出去，你肯定是，我不相信你完全不看就发出去。
56:20哎，对，哎，你的测试代码，它是不是测了一个真实的场景？
56:25不。那end to end的部分，
56:27一个真实的场景。
56:28是这样，end to end的部分，所以我就觉得是说一定是端到端的是最重要的。举个例子，就是编译出来的东西，你说那个什么营销你写出来的文章你看不看，我当然要看了。我自己写出来的app，或者说我自己上线的网站，我自己做的这个系统，到时候你要不要看一眼，你当然要看看页面怎么样，
56:46然后当然在我自己看之前，我当然需要有海量的测试去测了，对吧？这些我都要做的，但是问题是你要不要看他的source code，这是我们两个最大的分歧。我就问你，你为什么不看Word document的这个XML？因为XML如果写的不对，它最后的结果是不对的哦。
57:05如果XML写的错的，到最后的显示是不对的，那你...
57:09因为我直接看那个Word，我就能知道它的全部产出，因为它所有的产出，我直接看那个东西就可以了。
57:16你只是开一个word，你就知道它里面所有东西，你只要打开以后，你就知道它里面有多少东西。你要是想完整的测试一个word document，你做不到的哦。
57:26我不需要测试，我怎么怎么，就比如说我写一个word，我举个例子，我写一篇文章，我要看的内容就是它的文字跟排版，因为它的背后的source code通过文章和排版满足我的需求我都能看到了。但就以刚才并发为例啊，就是你会发现有很多，就是我帮你并发测试过了，他测试模拟的是真实的场景吗？
57:47你你怎么确定？他的测试他并发中有问题他没有测出来，这特别是今天的Claude Code，特别容易在并发跟实际上有非常多bug。
58:40对。但是这个就取决于你做，如果你今天做了给一个人用的产品，你可以就像我说的，我给我的cloud写一些脚本，或者我可以不看。但是如果你假设你要做一个面向十万人的产品，
59:29那test case干嘛？
59:31那test case的核心还是说它是不是work。我最终最终的东西就是说，只要你能verify，让我有办法能verify你给我这一堆代码，不是这一堆软件吧。就是它的一个app，比如说iOS上面app，我左看它也work，右看它也work，怎么看它都work。
59:51我不要关心它的代码，如果说你出现了一个我左看右看，然后又miss了一个方向，那我是看的问题。不是代码的问题。我只要能确定确定我的这个test，我要求的这个东西work。如果要是说我说这个东西不work，然后这个代码死活也给我做不到work，这个时候我就要去看代码。
1:00:12但是到现在为止，我还没看到过这种情况，或者还不多。
1:00:16我觉得不是，问题就在哪里呢？就是你不看代码，其实他跟你说work这件事情可能是虚假的。因为代码就不会是根据他跟你说什么才work，代码就是他那个代码写成什么样，就是怎么才是，就就是怎么来执行的。就是你会看到，也许你真的没有看见test case，因为我们系统里test case非常多，
1:00:39但有一段时间系统bug非常多，那段时间我也不怎么看代码。但后来呢我发现一个问题，他说他把所有的东西都mock掉，他等于跟没测是一样的，但他觉得我的coverage很高，我测了很多东西。当你不看代码的时候，我们如果把coding agent，不管当成是你的
1:01:00伙伴也好，手下也好，或者怎么样也好。你知道他非常厉害，或者你知道他怎么样，他总是会犯错的，他总是会漏了一些什么，因为你也总是会漏了一些什么。你跟他互相之间去看一看对方做的事情，本身就是有价值的。
1:01:43进一步地去完善Word，你叫harness也好，你叫它loop也好，让它接下来我看它可以看得更快，可以更少犯错误。
1:01:54对。如果从你这个角度说只是去get一些灵感，那我觉得无可厚非。你每个人用不同的方式去get灵感，比如我就是以这个端对端的测试去get灵感。就是当我觉得这个东西老不work了，那肯定有问题，我就想把它给解决掉。就是每个人get灵感的方法不一样而已，那这个我也认，但是代码不是一个必选项。
1:02:19还有回到刚才那个任鑫说的那段，那个我是非常同意的，这是一个巨大的空间。就是说到这个代码这个地方，我们其实就进到了另外一个我看到的，就是大家到底对AI的看法了。就是有的人觉得AI写的东西很好，有的人说它写得很烂。你会发现好和烂其实是一个小马过河的相对问题。
1:02:42就是语文水平非常烂的人觉得AI写得特别好，因为真的比他写得好。然后呢，语文水平超级好、特别会写的人会觉得AI写得烂。原因是说，大多数他做的，几乎大多数的事情，design也好，画画也好，写文章也好，写代码也好，它都会达到一个人类
1:03:06较高水平的平均值。它首先是一个较高水平，因为它的那个代码，它肯定不会去找烂的代码。就是比较好的代码的平均值。所以呢，当这件事情重要到你必须比平均值高的时候，刚才你说的那套东西其实是work的。但是对于很多刚才任鑫所举的那些例子，就是一个服装公司、外贸公司、一个做IP的公司，它只要有一套东西可以帮它拉到较高的平均值，
1:03:38对于它来说已经是补齐了它原来最短的短板，中间把它给拉齐了，对它来说就已经足够好了。那么接下来回到一个问题，就是我们在讨论的，我们到底是讨论的是什么一个scenario。就到底是你比这个较高水平的平均值是一定要拔高。
1:03:58那首先我们都在做这件事情，但是做这件事情又分了两个办法，到底是你看代码还是不看代码，对吧？就是这么来，这个几个数啊，在这儿。我同意说你看了代码，然后再做这些事情，做所有这些东西，因为我觉得你这么做肯定是有用处的。我只是在说ROI问题，就看代码来做这件事情所花的时间的ROI不划算。
1:04:21就像你如果真的有空去看任何点EXE的汇编语言，我也认为它也有好处的。但是问题你去看它干嘛？这好处太小了。我不跟你argue说有没有好处，当然有好处了。我
1:04:36从我的视角来说，肯定是ROI是高的。就是这，因为这个我也是经历过看不看看这个整个过程的，对吧？因为我这次当中可能还是有一个核心的分析，我能够明白为什么。因为我们现在在做，或者我现在主要精力在做的事儿，其实我称之为叫做能建一个软件工厂，
1:04:56让内部的工程师更大规模的输出，然后我们的业务团队或者能去卖东西。我的分工不是去解决、去搞营销这件事情，对我来讲。我的分工是说我能不能用八个人做出八百人。所以我会看每一轮AI产出的东西，然后对它做对AI本身的这个loop去做优化。
1:05:17是，我认为就是两个位置不同嘛。就第一个是我想做的事儿，或者我在做的事儿。假设我今天要做一个Claude Code的manager，或者我要做更好的一个OpenClaw。你同时你又只有很少的人和资源，那么你就需要想怎么把这个研发飞轮能够转起来。
1:05:37在这个过程中，我觉得不看代码这个飞轮一定是转得慢的。但在这个过程中，我自己并不去操心说这件事情营销怎么干。当然营销来的时候，可能也是一个营销的同事来找我，我去帮他看怎么把agent的loop能够转起来。但是我觉得你的位置可能是一个不同的位置。
1:05:55所以这个是我觉得说我们对这件事情做法可能会有非常大的不同。第一个是我们本身想做的产品不一样，第二个我们的位置不一样。就是毕竟CEO始终是可以把这个活一甩，说你们反正下边给我搞出来就可以。什么时候能要？
1:06:11听说你是写代码的CEO。
1:06:31嗯，对。我把这一段单独单独摘出来发给他。
1:06:34我觉得我们现在可以做一个总结。就是首先，我觉得最后这个文浩说的这一段其实是本质，就是你的目标是什么。对于我来说，至少在过去的，假设说这个一段时间里面，做出来一个app，界面那个design做的，我觉得还挺好看的。然后app的功能左左试右试没发现什么bug，至少用户也没，或者说即便是报一个bug，它很快能fix。
1:07:01对我来说，既然它work，还有什么他求嘛？挺好的呀，对吧？我就是it works，那我去改它代码干嘛？我去看它代码干嘛？所以我的最终的所有的出发点都在于说，我要有一个手里面的一个app。
1:07:18如果这个app有人就是迅速地给我开发好的话，我甚至连prompt我都不用管，对吧？我要的就是我脑子里面的那个app。然后呢，文浩是往底层来看，就是说我需要去怎么样写出来的代码会更好、更effective。那他就是必须要关心代码这一层。
1:07:39所以这个的确是两个我们所关心的这个视角所要看到的这个部分不一样，这我倒是完全同意的。
1:07:48我说徐文浩这边有一部分是他把公司当做他的那个产出物，而且他定义自己的公司是个AI科技公司。对。所以他这一块就好像得搞。对，
1:07:58对，是的，这个总结是对的。
1:08:17这个我自己的个人网站，我是用AI写的，我还是看了几眼代码，但可能看的非常少。我就把自己的网站改版一下，就大概看一下它是个主题嘛，它是个Jekyll的主题。我看一看，就它没有去copy paste，说每一个配置都都copy paste一遍，而是它用那个主题，
1:08:34我就确认一下另一件事情。所以从这个视角上来讲，我可能还是会去看一眼，因为我可能看一眼代码比我问它更快。对我来讲，就是我只要看这些内容的话，对我来讲看一下会更快。但是呢，肯定不会像我看现在的产品的，就像我们现在产品，就不同模块你去看的元素也不一样吧。
1:08:53比如说核心的agent loop或者manager的runtime，那会看的相对多一些。即使是你对着那个架构问，你也会反复去考虑各种细节。但有些就是说我有一个工具小本，它拍的写完了，我就基本上就瞄一眼，说哎呀，它只要不是那种一看就特别垃圾的，
1:09:10我说你改一下之外，我基本上也不看这里面的逻辑，所以我就的确是depends。那你说我们今天做个app，大概率我也不怎么看，对吧？就是如果它只是一个啊什么论坛呢，什么就是有个主页，有些东西可以看呢，我可能不看。但是如果我们要做个serious的东西，还是得看一下，就是因为不看，我心里会非常慌张。
1:09:32你确信你看是因为真的需求还是习惯？
1:09:38是真的需求啊，因为有一段时间我是不看的，然后现在就bug就特别特别多。
1:09:43它是需求，不是习惯。
1:09:45他在上一期说，他其实有一段时间不看的。
1:09:48因为我其实是个比较懒惰的人啊，就是差不多在一月份到三月份那段时间。第一个是我们当时想上一个产品，然后而且那段时间我用OpenClaw用语音写了非常多代码。我觉得好像也挺好的，但是你就会发现这个问题是。当你在内部只有几个人知道，跟这个产品上线有用户用之后，你就会发现爆发出惊人数量的各种奇奇怪怪的bug。
1:10:10后来你就发现不行，这个事儿，而且这个也和去vibe的那个人的水平高低也有关系。如果你去vibe的那些人本身更严谨，水平更高，他的确bug也会更少一些。但是我是需求，所以那个时候我发现啊，我其实在不停地探索这个边界，就是我到底哪些看，哪些不看，
1:10:31哪些我就瞄一眼就结束了，哪些我得仔细看一下。所以我就去探索，到今天为止，我是觉得说，如果这东西不用我看呢，我觉得这东西可能也不值得我来做。我其实可能是这样一个结论，就是这个事情如果我连看代码的需求都没有，那意味着我讲几句话，它会自动地生成。
1:10:49那我为什么要做它呢？
1:10:51把这几个拼在了一起，说现在是必须，然后你也认为说五年之后你就不会看了，对不对？大概率，
1:10:58我我觉得是说五年之后，我今天看的这些东西可能不再看了。但我其实会有一个好奇，就是五年之后我们有没有可能要管理一个比今天复杂度高得多的东西，然后你就还是得去看。但是我不知道看什么，也许是看paper，也许是看更复杂的DSL，或者是怎么样。
1:11:17我觉得始终我面临的一个问题是，当你的工具越来越top，你管理的事情复杂度就越来越高。我一直觉得一个好的软件工程师的核心，不是说我对不同的programming language有多熟悉，而是对这个东西的底层机制有多了解。
1:11:35而你完全不看code或者不了解这东西。是没法了解底层机制的。我其实跟很多人是反的啊，可能在六个月前，我我是完全相信Vibe Coding。但随着我觉得我做的事情越来越新鲜，就是因为模型给了你能力，我们现在在写一些MicroVM，
1:11:53那这个东西我以前没写过，我也不能完全靠口喷，我就确定它给我的这个东西跟我想要的一样，对吧？就我的knowledge，在这个过程中我还是要补充我的knowledge，而我补充我的knowledge的某种程度上，甚至我会去尝试手写一些代码，这个就像锻炼一样。
1:12:09那这块儿来说，你怎么看？刚才你说那个底层代码那个问题啊，我会有点警惕，这个是一个叫做你已经会了一个东西以后的偏见，或者说是上一个时代的人对下一个时代人的偏见。举个例子，那个我们都是做网站，我们都是从HTML开始写起来，对吧？
1:12:35那些什么fork出来，怎么监听排零端口，HTTP到底发了什么、传了什么，至少JavaScript的什么这些东西都会的，对吧？你去问一个现在的前端工程师，绝大多数的前端工程师，有很多人甚至没法儿给你手撸一个HTML页面。原因是，不是啊。
1:12:57请注意啊，那个现在就他会用React，他React用得很熟。但是你让他裸写一个，就当年两千年的时候，我们的HTML那个页面写不来的，什么还有head的标签，里面还有title，还有meta，还有meta杠equivalent，什么HTTP equivalent，
1:13:18什么这都什么tag呀，对吧？对他们来说，他们入行的第一天就是在React上面来工作的。如果让他去看他的React的代码，那就是编译出来的乱码嘛，那也是JavaScript，对不对？
1:13:32他做好的网站，你让他看一下，view source，我天，那密密麻麻的，你根本看不懂的。好。那你怎么评论这个人？这个人他不懂底层，他不懂HTTP。
1:13:44这个这个从我的视角来讲，第一个是，我觉得未来还是会有专业的软件工程师这个行业的。就是，就跟你今天有React的工
1:13:53程师是专业软件工程师吗？
1:13:56呃。我觉得不是。我很坦率地说，
1:13:59工程师是不是专业软件工程师吗？
1:14:02不是专业软件工，如果他只是个React工程师，他就不是个专业软件工。他只
1:14:28我我一直认为你只会写任何一个东西，你都不算软件工程师啊。
1:14:33我之前问你这个问题，就是说你到底把人家软件工程师这条线画在哪里？所有人都是把自己的能力线以下的划为不是软件工程师，自己能力线以上的。
1:14:45那我觉得倒没有。
1:15:19但我认为这就是叫屠龙之术了，没有意义。
1:15:22这个差别是在这里吗？
1:15:32我不会种庄稼，所以我并不是个农民。我不觉得说不是个软件工程师是个问题。
1:15:37不，我的意思是说，当时代在不断的往前发展的时候，曾经很重要的技能就放下这个执念吧，你就别去管那个什么会不会汇编，会不会C了，会不会什么HTML了。你在乎它干嘛？
1:15:53不是，我觉得是会不会汇编这件事情本身并不重要。但是举个例子啊，假设今天你要做一个科技公司或者做怎么样，你先说我想做推理优化。那你如果对这个东西有concept、有概念、有概念，这个事情你去做这个东西的，一个是有可能做成，
1:16:10一个是完全没可能。就像你说我C++，我很多年不写C++，我非常不熟练，但是我大概知道C++到编译或者是个什么过程。今天你说去CUDA做CUDA优化，在有AI的辅助下，我觉得我是可以做的。但可能另一个人是根本不可能做，我觉得就是差别在这里嘛。
1:16:29那你需不需要？就是说，就是因为今天你对一个，为什么我说React不是，就你当然可以说，呃，这是一种歧视，或者这是一种ego，但是我也可以说。
1:17:01不不不，我不是，就是发消息。
1:17:03觉得我们那我们这一代的人都是傻子吗？就是，就是连连猪中间也不会种，然后牛也不会喂。对，但对他们来说，这个技能是个最基础技能。你连牛都不会弄，你怎么搞电脑？
1:17:16你说的这句话没错，所以我真的会去看一些，就是比方说，就是我会尝试去做一些更要动手的事情。就是我一直觉得人应该更全能一点，就是因为世界变化动荡很快，对吧？种庄稼这个事实在是没有条件。
1:17:32种庄稼是因为没有条件你才放弃。如果要是真的有这条件的话，我相信你还是坚守种庄稼呢。就我的意思是不要去坚守过去的东西吧。
1:17:42我觉得不是坚守，我觉得这个是回到另外一个逻辑，非对称性风险问题。我这个人呢其实一直是比较怕死的。比方说，我们家的那个厨房门坏了，我就去淘宝上买这个，买螺丝把它修好，对吧？然后上面可能破了个洞，我去买木屑跟砂纸把它填好。我可以把它扔了。
1:17:59但是呢，第一个我倾向于把这个东西给fix了。第二个呢，我觉得动手能去解决一些力所能及的事情，它本身有价值，对吧？就像中国人在美国想要种菜一样，可能种庄稼不一定有大会，但是很多中国人跑到美国把一个花园说做成个菜园子。这个其实我父母在上海也干这个事儿，是吧？
1:18:19他们在乡下有个房子也会去种，就是种种个什么水果啊。不是说我特别偏爱这个事情，而是我觉得每这些事儿其实人都应该稍微做一下。就跟做软件开发说你是个React工程师，为什么我说如果只会写React的不是软件工程师？不是说我歧视React，而是说如果你只会写React，但是你其他东西碰都不碰，一点兴趣都不敢，
1:18:42它是什么你完全不想了解，那我觉得你的确不是个软件工程师，就你也不适合以此为职业嘛。因为你也不会有特别好的发展，你在这个职业中想要有好的发展，你总有好奇心，说，哎。我既然做我后端，那后端再干一些什么呢？哎。这个东西跑到浏览器里，浏览器原理是什么呢？
1:19:00反正你总是会到的嘛。想要知道，你总归想要试一试吧。
1:20:17我还是说你这个做法上的话，比如说你用来去看代码的那些时间，是不是如果你去学了一些更好的这个层次上的方法，比如说一个人他管大公司，然后他一步步升职嘛，那他当然是对基层的业务也了解，是有帮助的嘛。但是也可以说他其实是在比如说整个组织架构啊、什么宏观战略啊、什么PE、ST啊这些东西上他去花时间。
1:20:41是不是我们正在被AI会挤压的，其实就是把我们越来越往上层挤。就是你现在是那个跨国公司一百万人的，已经是VP了，下一任你就是CEO了，然后你再过两年又会被挤到董事长的位置上。现在再去讲，然后你的复杂度已经会大到，就像你讲的，未来的复杂度还会更高。
1:21:02是不是我们要什么，哎呀……我要理解一线业务啊，或者什么这些，或者我要理解用户啊什么的，这种东西会越来越贬值，因为你的位置被降得越来越高了。
1:21:13我觉得反而不是啊，你最典型的是你反而看，不知道美国有一个趋势，对吧？就是一堆独角兽的CTO，上市公司CTO跑去Anthropic做MTS，去做一线的人员。因为当一个事情在快速进展的时候，你其实只有在一线有手感，你才知道这个事情是怎么回事。
1:21:31其实我是特别后悔，我去年有半年时间就在管很多其实跟tech无关的事情，你可以认为是更宏观的事情。但是我觉得某种程度上讲，那六个月……因为你没有关心这个事情，你就失去了对tech的敏锐度。就是换句话说，我觉得如果说我那个时候focus在tech上，我那个时候自己写更多的代码或者看更多的代码，
1:21:54可能我们会更早做一些我们今天就决定做的技术上的决策，我们可能更早有一个更好的产品出现，我们可能更早有更好的harness infrastructure出现，对吧？可能你在竞争中会更在前面一个身位，这么个差别。对，
1:23:09其实也不那么难，我发现DeepResearch可烧token，会开一百个agent的，它还烧token。我跟你说，你死了。然后我觉得还是那个定位的问题。然后你这个定位确实就需要嘛，这个是你的那个产品嘛。
1:23:53了解。哎，我觉得今天已经讨论差不多了，最后两位同学来，反正我这边网络也不稳定，来一个最后总结，总结陈词，说段话。我们就今天说它，网络不稳定，然后终于又回来了。
1:24:07就是首先我会觉得我那个文浩讲的这些部分，就整个在一个行业里面怎么可能会没有什么共识啊，我觉得有一些东西还是共识的部分还是蛮多的。就是只不过我现在能感觉到核心的差异是，呃，哪一层工作吧。我是一个客户，我是吃面条的，老实说，只要一个面条能把我吃饱了，然后吃起来很好吃，我还要什么，
1:24:31对吧？价格合理公道，然后又好吃，除此以外我还要什么？但是作为做面条的人来说的话，他可能关心的东西就会更细致。但问题就是说这里面的比例，比如方便面来了以后，对整个这个行业的冲击，是我们需要去看到的。所以我们现在最主要是说理解我们两个之间的分歧的原因。
1:24:58但是我不确定的地方是说，当这个大潮过来的时候，原来我们觉得重要的部分到底还有多重要？这是一个我想，就是我们需要持续地思考的部分。然后另外一个就是说，是到底是面向未来来做事情，还是面向现在，这个也是一个选择问题。就换句话说，它无外乎对错问题，只外乎于自己愿意把时间花在哪里的问题。
1:25:25我只是选择了，呃，把时间花在未来的部分。虽然它的问题也非常明显，就是好多事儿其实干得也不咋地。以现在的设施来用这种方法来干，不见得是最优解。但接下来就是看你到底是要现在的最优解，还是对于未来的可能性吧。明白。
1:25:50好。我叫法拉第啊，徐文浩。好的，来。
1:25:54我先说点得罪人的话，就是所有的React工程师，我觉得今天终于到了你其实是一个选择的时候了。就是你是不是真的考虑想做一个严肃的工程师，其实今天的确可以做一个。其实我觉得本质上我跟建硕没有什么分歧啊。如果你今天只想今天做在应用层，那你不太需要看代码，所以也不太需要React工程师了。
1:26:20但是我自己想做的事儿，而且我认为未来四五年内，其实整个行业一个巨大的或者很多人都在干的事儿，就是知识工厂或者软件工厂，或者这个本质上是把很多智力劳动想过能够规模化地能够生产出来。那如果想要比较高效地做这件事儿呢，我的观点还是说它始终是一个你没办法回避去看一眼代码这个事儿。
1:26:52因为代码这个事情是通用人工智能在人和人工智能之间的唯一桥梁或者共识。就是今天人工AI，大家所有的厉害，是因为说AI特别擅长写一段代码，然后用这段代码来干一些活，而不是说它真的能干自己独立能干的事。那怎么让这件事情本身帮我们解决所有问题呢？
1:27:20我觉得就得去看一看你说了什么话，他写了什么代码，然后想想怎么能把这个事情比较高效地能够跑起来。这个所以呢，我是觉得说看看代码，甚至手写代码，至少未来四五年，我觉得肯定还是挺有用的。但到未来四五年之后呢，它的确可能变成了屠龙之术。
1:27:38但屠龙之术这个事情是这样的，它可能会有价值，对不对？它可能也毫无价值，这个取决于你能不能站在一个正确的位置，或者能不能抢到那个正确的位置。可能未来真正需要的工程师会非常少。但是它能放大的能量可能会非常大。
1:27:56可能跟Mars比，跟建硕比，我可能更技术一点，因为角色还是不一样。虽然我自己创过业，我自己做过CEO，但是其实我做过一次CEO之后，我就放弃这个职位了。那我其实更专注做一些我喜欢跟我擅长的事情。我我我我是觉得说，和好多做技术的朋友聊，我们都觉得说，未来是能够从R&D或者这种知识工作流程能做到1:
1:28:21100这样的杠杆。可能今天我们在1:5到1:10这个范围之内。但1:100这个杠杆，可能不是说你完全相信模型口喷一下这件事情就结束了。大概率你需要去建一个利用好AI杠杆的流程，其中代码可能是一些不可或缺的环节。这个是我想说的。
1:28:45好的。我觉得其实也没大的分歧，我就收收两个词啊，一个就是还是定位不一样。然后徐文浩那边的话，还是把那个公司当做系统，然后他还在优化这个系统。那所以大家也可以听到这里的话，也可以看说你最关注的是出来那碗面条，还是你想开麦当劳，对吧？
1:29:02我要把后厨给搞好了，然后我才是麦当劳。那所以两位同学这点上是不太一样的。然后还有一个地方的话，其实就是我们前几期在聊说要token maxing的时候，其实也有人在问说，诶……这个明显不对嘛，那你肯定是应该用到token嘛。
1:29:18但我觉得建硕其实他还有一个观点，其实是说为了抵抗自己的惯性，有的时候是矫枉过正的，就把自己先拖到未来的极端的情况下，然后说我们就必须，比如说我就不能碰那些文字，我就不该干嘛。我就不干了。然后往这个角度，它不见得是当下的最优解，但是它是提前把自己往未来丢，然后说我们能不能站在未来来思考，
1:29:41说什么事情是那个future-proof的。然后但是这个future-proof未必能够带来当下的一个一个效率最大化，甚至于是当下的一个一个次优解、不优解。对。所以这种东西的话，其实就还是说你在什么位置，你考虑什么问题，然后决定了我们的策略到底是什么。
1:29:59好的好的，然后谢谢两位来吵架。到时候想法更新了，觉得说，哎，我找到对方一个漏洞了，不是吵架完了经常会发生的事情，就是，哎，当时可以那样子就可以把他拍死的。我想到的话，就到时候再聊，
1:30:13就再约一期。OK，好的，好，谢谢谢谢。拜拜，拜拜，拜拜，谢谢，拜拜。拜拜，拜拜。
本期词条
重点词条
本期重点讨论的人、公司、产品和概念，按出现顺序。
人物王建硕
