不看代码的AI编程VS必须看的代码治理：一场90分钟的技术架

当AI辅助编程成为开发常态，「要不要亲自查看生成的代码」成了开发者们争论的核心问题。这场来自播客的深度对谈，邀请了两位在一线重度使用AI写代码的从业者，他们给出了完全相反的行动准则，并用90分钟的讨论拆解了分歧背后的本质。

其中一位开发者正在密集开发一款名为VoiceDrop的应用，每天使用Claude Code工作12小时，12天内就在TestFlight平台发布了148个版本，他给自己定下了绝对不查看任何一行代码的规则，只有两次打开代码文件，也是为了确认某个字符串的写法。另一位开发者的团队则维护着超过13000个自动化UI测试用例和200多个端到端测试，他坚持两个不可动摇的底线：所有代码上线前必须经过人工审核，项目治理必须依靠确定性工具，而非完全依赖自然语言生成的结果。

高级语言已经退化为「新汇编」

王建硕的核心观点源于编程技术的演进历史：从机器码到汇编语言，再到C语言等高级语言，每一次抽象层级的提升，都会让底层的实现不再被开发者关注。他认为，当前的Python、JavaScript、Swift等我们熟悉的高级语言，已经退化为类似汇编的底层载体，而自然语言加上配套的工具链，正在取代手动编写高级代码的工作。

「一旦有了像C一样的高级语言，直接手写汇编第一没有必要，第二没有可能。去改编译器编译出来的汇编，更是完全没有意义。」——王建硕

他认为，修改AI生成的代码就像修改编译后的汇编指令，毫无价值——因为下次重新生成代码时，所有手动修改都会被覆盖。对于传统的代码质量标准，比如代码风格、封装、注释等，他认为这些标准是为人类可读设计的，当阅读代码的主体变成机器时，这些标准已经不再适用，机器只会根据训练语料的习惯判断代码，不会在意格式和细节。

他提出了全新的项目判断标准：if it works，只要功能能够正常运行，就不需要做任何改动。他甚至举了微信的例子：微信数千万行的底层代码如果打印出来，会充满重复且难以理解的内容，但只要上层的逻辑正常运行，底层的细节就不需要被关注。

不看代码的治理方案

不查看代码并不等于放任不管，王建硕有一套完整的治理逻辑。他的应用每次更新都需要通过414个测试用例，这个数量比他手写同规模软件时的测试数量还要多。当需要了解某段逻辑的具体实现时，他不会打开代码文件，而是直接让Claude Code进行解释。针对重复代码的问题，他开发了专门的质量检测工具，定期通过循环扫描来排查问题。

他坦言这种开发方式的成本更高，一个功能可能需要5小时反复调试和迭代，但他尝试过将流程固化为确定性代码后，发现代码质量不如大语言模型生成的结果，还会失去灵活性。最终12天发布的148个版本中，只有不到10个出现了故障，这是他手写代码时从未达到的稳定性。

「一定不是用自然语言来控制，因为自然语言不准确。但是你一定要用loop来控制，让它一遍一遍地转圈。」——王建硕

只信任确定性的治理工具

徐文浩同样不手动编写代码，全程依靠prompt驱动开发，但他坚持必须使用确定性工具来完成项目治理。他认为自然语言本身存在模糊性，必须用自然语言生成确定性的代码工具来完成质量管控。

「自然语言在今天还是非常模糊的。所以最终我会用自然语言去生成一个确定性的代码工具，去做这个治理。」——徐文浩

以处理重复代码为例，徐文浩反对用LLM进行扫描，因为大语言模型可能会遗漏部分重复片段，导致后续出现隐藏bug。他使用基于抽象语法树的检测工具，可以在10秒内扫描整个代码库，自动检测重复率并触发整改，而循环扫描则需要数小时，效率差距巨大。

他强调项目规模是关键的考量因素：414个测试用例只能说明项目体量小、复杂度低，而他的13000个测试用例的代码库，如果用循环扫描会消耗大量时间和资源。一旦代码规模扩大，prompt的局限性就会显现，容易出现代码风格不统一的问题。此外，他认为出了问题必须有人负责，不能把责任推给AI系统。

多轮交锋中的核心分歧

双方的交锋围绕多个核心议题展开，其中最精彩的部分来自编译器比喻的讨论。徐文浩提出，如果LLM是编译器，那么开发者应该查看编译后的汇编代码来验证编译器的质量。王建硕反驳称，真正的编译器是由OpenAI、Anthropic等公司开发的，开发者只是调用工具，不需要查看生成的代码，应该关注自然语言在系统中的流转而非最终代码。徐文浩进一步追问，如果prompt才是源代码，为什么还要保留代码的版本管理，因为当出现故障时，开发者通常会回退到代码版本而非重新生成prompt，这说明编译器的比喻并不成立。王建硕没有正面回应，因为当前的自然语言编程确实存在同一prompt多次生成结果不一致的问题。

另一个关键碰撞是工匠精神与精益制造的争论。王建硕提出「工匠精神在规模面前一文不值」，徐文浩则将自己的开发模式定义为精益制造，就像丰田的规模化生产模式，核心是通过标准化流程提升效率和质量，而非追求个人的代码完美。他认为「能够运行」并不是最终目标，市场竞争需要的是更快更好的产品，只有能够管理复杂项目的团队才能获得优势，软件开发的本质是管理复杂度，当简单的项目可以通过一句话生成时，只有高复杂度的项目才有竞争力，而单个AI代理能管理的复杂度有限，这正是治理的意义所在。

「work 不是目标，work 也并不达成我们的目标。」——徐文浩

徐文浩还分享了自己的惨痛经历，今年1-3月他也较少查看代码，通过语音生成了大量代码，内部测试时运行正常，但上线后出现了大量奇怪的bug。复盘发现，AI将测试中的所有依赖都进行了mock，导致测试覆盖率看似很高，但实际上和没有测试没有区别。这暴露了王建硕治理逻辑的隐患：414个测试用例的前提是测试本身是有效的，当不查看代码时，「功能正常」的信号可能是虚假的，因为测试和生成代码的都是同一个AI系统。因此徐文浩划定了边界：临时脚本和自用小工具可以不看代码，但需要上线、有用户、需要负责的项目，必须查看代码。

主持人还提出了一个关键问题：开发者通过提升编码效率获得的优势，会随着AI模型的每年升级而被逐渐抵消，就像有一台推土机在不断推平基建优势，而用户洞察、市场、IP等优势则不会被轻易取代，是否应该将更多精力放在推土机追不上的领域？徐文浩回应称，营销领域同样面临AI自动化的冲击，最终也需要建立工具链。他以Manus为例，虽然长期来看其能力会被模型内化，但阶段性的优势足以让团队在市场竞争中获得回报。他认为，五年后所有人都不需要写代码，是因为有人在这五年间迭代了自动化流程，而如果自己能在三年内完成这些流程的搭建，就能获得先发优势，选择为推土机铺路而非等待。

「五年以后大家都不写代码，是因为有人在这五年之间在迭代这些自动化的流程。如果我自己在迭代这些流程，那我能不能让我的公司在三年内就做到？」——徐文浩

在讨论的后期，王建硕设下了关于工程师身份的圈套，询问只会使用React却无法手写HTML的前端开发者算不算软件工程师，徐文浩认为不算。王建硕进一步追问，不写汇编的开发者算不算，只会写HTML的算不算，并指出双方都是将自己能力范围内的技术划分为「合格」的工程师标准，属于过河拆桥的行为。他补充说，现在很多人已经无法运行8086处理器，就像上一代人不会喂牛却能使用电脑，时代进步时应该放下过时的技能执念。徐文浩部分认同，但坚持自己的底线：底层概念的了解依然重要，比如在进行推理优化等深度工作时，对底层的理解会决定项目的成败，他现在还会手动编写部分代码作为锻炼。

分歧的本质：位置不同而非技术对错

这场长达90分钟的讨论最终归于平静，因为双方都意识到，分歧的根源并不在技术层面，而是各自的业务定位完全不同。

王建硕更像是「吃面条的客户」，只需要最终能正常运行的产品，不需要关心底层实现，最好连prompt都不用管理。而徐文浩则是「开麦当劳的经营者」，将公司视为软件工厂，目标是用8个人的团队实现800人的产出，从当前1:5到1:10的研发杠杆，提升到1:100的规模，因此必须管控后厨的细节。

两人都认同未来五年内将不再需要手动查看代码，但当下的选择取决于面向未来的转型决心和当前的业务责任。王建硕的做法本质上是一种矫枉过正的转型策略，明知当下不是最优解，也要强迫自己适应未来的工作方式，比如他现在写公众号文章都完全不使用键盘，就是为了倒逼自己适应自然语言交互的模式。

「这不见得是最优解，但是一定要这么逼着自己，才能真的转过来。」——王建硕

他自己也承认，这种方式在三年前还不可行，当时AI模型的能力和配套工具链都不成熟，但经过三年的发展，现在已经具备了落地的条件。他相信，未来五年内，手动查看代码的需求会越来越少，这一点徐文浩也表示认同。

因此这场讨论的真正结论是：在技术演进的趋势上双方没有分歧，真正的分歧在于当下如何选择。这种选择取决于你是更关注眼前可用的产品，还是着眼于搭建未来的规模化生产体系。

结语：技术浪潮中的两种选择

这场讨论本质上是每次技术大潮到来时都会出现的分歧：当浪潮打来时，有人选择先跳上冲浪板体验风浪，有人则选择加固船只等待浪潮过去，两种选择都没有绝对的对错，只是取决于所处的位置和目标。对于开发者来说，重要的不是纠结于要不要查看代码，而是明确自己的业务定位，选择最适合自己的开发路径。