一、两条开发路线：只看结果还是审查产物
时间点：00:05–17:59
话题概括：王建硕把 Python、JavaScript 类比为 AI 时代的“汇编”，主张把注意力移到产品是否工作；徐文浩同意用自然语言驱动开发，但坚持代码合并前必须有人审查。
王建硕用 loop 代替逐行阅读
王建硕介绍，他在 12 天内为 VoiceDrop 发布了 148 个 TestFlight 版本，每天让 Claude Code 工作约 12 小时，并刻意不看任何一行代码。他并非放弃治理：每次改动要经过 414 个测试用例，需要理解逻辑时让模型解释，还会定期运行质量检查。他的新标准是“if it works”，认为机器维护代码的方式不必继续服从人类阅读习惯。
徐文浩用自然语言生成确定性工具
徐文浩同样采用 prompt 驱动，但不相信仅靠自然语言就能稳定治理大规模代码。他举例说，模型扫描重复代码可能漏项，而基于抽象语法树的工具可以在全库执行确定性检查。因此他的路线是：用自然语言生成工具，再由人审核工具与代码产物。
二、编译器比喻与规模化软件治理
时间点：17:59–55:03
话题概括：双方围绕“谁在写编译器”、为何仍要保留代码版本、规模与工匠精神的关系继续争论，分歧逐渐落到产品复杂度与组织目标上。
版本管理暴露了比喻的边界
王建硕认为真正的“编译器”由前沿模型公司开发，应用开发者不必查看模型生成的底层产物。徐文浩则追问：如果 prompt 才是源代码，为何遇到故障时仍会回退到上一版代码，而不是仅靠原 prompt 重新生成。这一问题指出，当前生成过程还没有完全具备传统编译器的确定性。
“能工作”不是所有团队的共同终点
王建硕认为工匠精神会被规模压过；徐文浩则用丰田精益制造反驳，认为精益本来就是为规模而生。徐文浩把软件开发定义为管理复杂度：简单产品可以一句话生成，但真正有竞争力的系统往往超出个人和单次 agent loop 的上下文，需要可持续的工程治理。
三、真实代价与最终分歧
时间点：01:00:16–01:19:04
话题概括：徐文浩复盘过度 vibe coding 的质量债务，双方最后发现，争议根源不是对五年后趋势的判断，而是今天各自所处的位置不同。
测试覆盖率也可能给出虚假安全感
徐文浩回顾年初不太看代码的实践：产品上线后出现大量问题，复盘发现 AI 曾把测试中的依赖全部 mock 掉，覆盖率看似很高，实际上没有验证真实链路。团队随后用两个月时间偿还这段开发留下的债务。他据此强调，不查看代码时，“work”本身也可能是误判。
吃面条与开麦当劳对应不同目标
王建硕把自己定位为“吃面条的客户”，只需要手中的 App 好用；徐文浩则想建立能够把研发杠杆从 1 比 5、1 比 10 提升到 1 比 100 的生产线，因此必须观察后厨。任鑫据此总结：王建硕是在用矫枉过正的方式，主动把自己推向五年后的工作方法；它未必是当下的统一最优解，却是一种有意的能力转换。