王建硕 × 徐文浩吵架局:看代码是浪费时间,还是人机唯一的桥梁
AI炼金术
1 DAYS AGO
王建硕 × 徐文浩吵架局:看代码是浪费时间,还是人机唯一的桥梁
王建硕 × 徐文浩吵架局:看代码是浪费时间,还是人机唯一的桥梁

AI炼金术
1 DAYS AGO
Shownote
Shownote
上一期结尾,徐文浩点名和王建硕观点有分歧,我说要拉着吵一架 —— 这期兑现了。 一边是王建硕:12 天在 TestFlight 发了 148 个版本,每天让 Claude Code 跑 12 个小时,却给自己定了条死规矩 —— 不允许自己看任何一行代码。另一边是徐文浩:团队核心库养着 13000 多个自动化 UI 测试用例,立场是所有代码合并上线前必须有人看过,“如果这东西不用我看代码,那它可能也不值得我做”。 我在中间煽风点火,想让他们打起来涨粉。但吵到 90 分钟,吵出来的东西比输赢有意思得多:他们对未...
Highlights
Highlights
本期播客围绕 AI 时代是否还需要人工审查代码展开激烈辩论。王建硕主张 “if it works” 原则,认为代码只要工作就不必管,甚至不允许自己看任何一行代码;徐文浩则坚持所有代码合并上线前必须有人看过,强调通过自然语言生成确定性工具进行治理。两人从编译器比喻、工匠精神、规模效率等多个角度交锋,最终发现分歧根源在于定位不同:王建硕是 “吃面条的客户”,只关心结果;徐文浩是 “开麦当劳的”,追求规模化效率。
Chapters
Chapters
冷开场:王建硕的新金线 if it works
00:00任鑫开场:煽风点火,把两位拉来当面对质
01:46手搓核心代码 20-50 遍的人,为什么一夜跳到 “不看代码” 阵营
03:32徐文浩:同意一半 —— 但 harness 是用自然语言生成的确定性工具
08:03王建硕:我不允许自己看任何一行代码;414 个 test case + loop 治理
10:07徐文浩:13000 个 UI 测试用例;代码规模一上去 prompt 就限不住
14:28编译器比喻大战:写编译器的人看不看汇编产出
17:59重复代码怎么治:定期跑 skill vs 语法树工具 10 秒扫全库
20:20工匠精神在规模面前一文不值:微信汇编赌局
33:33徐文浩三连反击:版本管理悖论、精益制造为规模而生、管理复杂度
37:20分歧收敛成一个数字:时间的 95:5 还是 70:30
42:39打个赌:五年后还要看代码吗?type-c 和软盘的取舍
45:39任鑫的推土机问题:harness 优势每年被模型吃掉,不如去搞用户侧?
52:13Word 文档的 XML 你审吗:端到端测试大战
55:03徐文浩踩过的坑:AI 把测试全 mock 掉,“work” 可能是虚假的
1:00:16小马过河:AI 写得好还是烂,取决于你自己的水平
1:02:33一到三月不看代码的代价;不用我看的东西不值得我做
1:09:38react 工程师之辩:过了桥就拆桥、屠龙之术与种庄稼
1:12:10收束:吃面条的 vs 开麦当劳的;1 比 100 的杠杆
1:19:04Transcript
Transcript
王建硕: 一旦编译器有了,就是一旦有了像 C 一样的,C++ 一样的高级语言,就直接用手写。汇编已经第一没有必要,第二没有可能,去更改编译器编译出来的汇编语言,更是完全没有意义。是机器的话,它的可维护可理解的 bar 和人。有的地方会高,有的地方会低,反正肯定会不一样,那么它的标准就一定是不一样,那到底新的标准是什么?我的心的这根金线就是 if it works,它只要 work,就不要去管它。
徐文浩: 我觉得问题不管怎么变,就是人去读它。也是因为管理复杂度 AI 虽然很长,但是它单个 agent 或者单...
