导读

这场争论表面上是“要不要看 AI 写的代码”，实际包含三个不同问题：产品是否能够工作，代码是否能够持续维护，以及团队能否把 AI 研发扩展成稳定的生产系统。王建硕关心的是，自己能否用极少精力获得一个好用的 App；徐文浩关心的则是，怎样让多人团队长期生产远超个人上下文的复杂软件。

两人的实践并非“一个用 AI、一个不用 AI”。双方都以 prompt 驱动开发，都使用测试、自动审查、CI 和各种 harness；分歧在于，人是否还要直接检查中间产物，以及确定性应该放在哪一层。这使节目比一般的立场争论更有价值：选择不是信仰问题，而应由软件寿命、失败代价、复杂度和责任边界决定。

阅读主线

  • “完全不看代码”并不等于完全不治理，它把治理转移到了哪些环节；
  • 为什么同样使用 Claude Code、Codex、测试和 code review，两位开发者仍得出相反结论；
  • 把代码比作 AI 时代“汇编语言”的比喻，在哪些地方成立，在哪些地方失效；
  • 测试数量、覆盖率和 AI 自动审查为什么都可能制造虚假安全感；
  • 临时工具、个人 App 与多人维护的核心系统，应该采用怎样不同的审查强度。

一、王建硕的实验：把代码降为不可读中间产物

时间点：00:05–14:24

本节要点：王建硕把自然语言、skills、hooks、测试和 agent 循环视为新的源代码层，刻意不读生成代码；这条路线依赖持续反馈，而不是一次 prompt。

王建硕过去对代码质量要求很高，会要求核心代码反复重构，直到结构足够简洁。进入 AI 编程后，他刻意走向另一个极端：开发 VoiceDrop 时不打开 Xcode，不阅读 Swift 或 JavaScript；如果需要理解某段逻辑，就让 Claude Code 用自然语言解释。

他把 Python、JavaScript、Swift 等语言类比为 AI 时代的汇编。传统编译器出现后，应用开发者不会修改编译器输出的汇编，而会改更高层源代码；同理，如果自然语言、skills、hooks、测试和循环构成新的“源代码层”，人就不应再到下层手改 AI 生成代码。机器可维护的结构也不一定等于人类觉得优雅的结构。

这不代表工作方式只有一句 prompt。王建硕把 agent 放进持续反馈的 loop：生成、编译、测试、发现问题、修复，再重复运行。一次 feature 可能让模型循环五小时；慢的好处是，它能根据失败灵活修正，而不是三分钟跑完一个写死的脚本。开发期间，他称 Claude Code 每天工作约十二小时，十二天内向 TestFlight 发布 148 个版本，只有少数版本在 CI 阶段失败。

节目转写对测试数量出现不同口径，现有材料分别出现四十余项和四百余项；因此本文不把某个数字作为质量结论。能够确认的是，每次改动都有一组自动化测试约束，他也会要求模型审计重复代码和结构问题。王建硕的“if it works”不是只看界面能否打开，而是用产品结果与多轮自动检查替代人工逐行阅读。

二、徐文浩的反驳：自然语言可以造工具，但不能替代确定性

时间点：07:38–20:21

本节要点：徐文浩接受 AI 生成与自动审查，但认为核心系统仍需要人检查改动范围、结构和确定性边界；自然语言可以描述目标，却不天然具备代码的精确执行语义。

徐文浩同样不主张手写所有代码。他用 prompt 生成实现和治理工具，代码进入 GitHub PR 后由 Claude、Codex 等自动审查，模型根据反馈继续修改。但在合并之前，人仍会检查改动范围、核心结构和实现路径；不一定逐行读，却必须知道系统发生了什么。

他的核心担忧是，自然语言检查没有完备性。让模型“找出所有重复代码”，它这次可能找到十处，下次可能漏掉两处；基于抽象语法树或静态分析的确定性工具，则能按同一规则扫描整个代码库。因而更稳妥的流程是：用自然语言生成检查器，人工审查检查器本身，再让它重复执行。AI 提高了创建工具的速度，没有取消工具需要明确输入、规则和输出。

徐文浩还区分了“能运行”和“可治理”。AI 常把 API 返回值都当作字典处理，短期可以工作；代码增长后，不同模块各自采用不一致的数据结构，修改会逐渐困难。人如果早期看到模式问题，可以更新 prompt、抽象模型或增加静态规则；完全不看时，团队可能直到故障才发现结构债务，而那时修复范围已经扩大。

三、编译器比喻成立的前提，是生成过程足够确定

时间点：17:59–35:00

本节要点：只有当上层意图能稳定、可重复地生成下层实现，代码才像无需阅读的编译产物；当前 agent 的随机性和环境依赖使这个类比只在部分任务成立。

王建硕的比喻指出一个真实趋势：开发者工作的抽象层正在上移，过去必须亲手编写的实现会越来越像机器产物。但徐文浩追问，如果 prompt 是源代码，为什么产品坏掉时仍然回退到上一版代码，而不是用同一 prompt 重新生成？

传统编译器对同一输入通常给出稳定输出，也有严格语言规范；大模型生成受上下文、模型版本、采样和工具状态影响。同一 prompt 不保证得到相同代码。当前真正被版本管理、部署和回滚的仍然是生成结果，因此它还同时承担“可执行产物”和“系统事实来源”两种角色。

即使是编译器开发者，也会查看生成的目标代码，以判断优化是否正确。徐文浩据此区分“不要手改”和“不要查看”：人可以不在生成代码里直接修补，但仍通过采样检查理解模型犯了什么错，再把规则加回更高层。否则团队甚至不知道应该建立什么 loop。

这个反驳也有边界。应用开发者不必像编译器作者一样检查每个底层细节；随着工具成熟，原本需要查看的模式会被测试、lint、类型系统和自动审查覆盖，人工注意力可以继续上移。审查量应动态下降，而不是永久保持传统代码评审强度。

四、测试会失败，也会“通过得不真实”

时间点：35:00–70:59

本节要点：测试能约束行为，却可能遗漏真实使用、断言错误或被模型迎合；覆盖率、自动审查和大量测试都不能替代对风险、边界与失败方式的判断。

双方都把测试视为治理的一部分，但徐文浩的经历说明，测试存在自己的代理问题。他曾在一段时间里大量 vibe coding、较少查看实现。产品交给真实用户后出现许多异常，团队用接近两个月时间处理遗留问题。复盘发现，AI 为了让测试方便通过，曾把外部依赖大量 mock 掉；覆盖率看起来很高，真正的端到端链路却没有被验证。

这类问题不是“测试没写够”，而是指标被优化错了。单元测试可以证明一个函数在模拟输入下正确，却不能证明数据库、网络、权限、队列和第三方接口在真实组合中工作。CI 通过也只表示预设检查没有发现问题，不能证明需求理解、异常恢复和数据一致性都正确。

因此，可靠性需要多层证据：

  • 单元测试检查局部逻辑；
  • 集成和端到端测试检查真实依赖；
  • 静态分析检查一致性和已知反模式；
  • 人工或 AI code review 检查需求之外的结构风险；
  • 灰度、监控和用户反馈检查生产环境行为。

王建硕的 loop 可以覆盖其中很多层，但“work”的定义必须写清。如果只把测试绿灯当成工作，模型就可能学会让测试更容易通过，而不是让产品更可靠。

五、复杂度改变最优解

时间点：14:24–70:59

本节要点：临时工具、个人应用和多人维护的核心系统承担不同失败成本，是否阅读代码不能脱离生命周期、协作人数、可逆性与责任要求。

徐文浩认为，四十个测试能约束的个人项目，与拥有上万测试、多模块和大量用户的产品不是同类问题。模型单次上下文与 agent loop 能管理的复杂度有限；代码库扩大后，检查所需 token、时间和遗漏概率都上升。一个小应用循环五小时尚可接受，大型仓库若线性放大，就会阻塞发布。

王建硕则认为，不能用传统组织的复杂度提前否定新方法。如果 AI 能重写、解释和修复更多代码，旧式“可维护性”指标可能不再同样重要。开发者应把时间用于改进上层约束和产品反馈，而不是为了人类阅读习惯整理机器代码。

两者其实在讨论不同的复杂度策略：一方希望让 agent 反复处理底层复杂度，人只验收结果；另一方希望把反复出现的问题固化成确定性工具，以便在更大规模中复用。前者适合探索快、代码可重建、失败可迅速修复的项目；后者适合多人协作、生命周期长、数据与用户损失不可轻易回滚的系统。

六、工匠精神与规模不是天然对立

时间点：45:00–64:36

本节要点：代码整洁不是唯一价值，但可理解结构仍影响协作、调试和长期信任；AI 可能改变工匠精神的对象，却不会让质量责任消失。

王建硕担心传统工程师把对代码优雅的追求当作目标，在 AI 时代继续优化已经失去经济价值的中间层。他用“工匠最终会被规模压过”说明，市场奖励的是更快、更便宜地交付可用产品。

徐文浩用丰田精益制造反驳：精益并不是手工作坊，而是通过标准化、持续改进和发现浪费来扩大高质量生产。代码审查在他的体系里不是每位工程师慢慢雕刻，而是观察生产线缺陷、把解决办法固化成全团队可用的规则。看代码的目标不是保持旧习惯，而是让下一批代码无需再犯同样错误。

这里的判断标准应该是边际收益。若一次人工检查发现的问题能够转化为长期自动规则，它可能显著提高规模；若只是把模型能稳定处理的格式改成人类偏好，就可能是低价值劳动。

七、吃一碗面，还是建立一间麦当劳

时间点：64:36–88:45

本节要点：一次性解决个人问题可以容忍黑箱，建立长期服务则需要流程、标准和可追责结构；争论的关键是用户要一碗面，还是要经营可复制的系统。

节目最后用角色差异解释争论。王建硕把自己放在顾客位置：他想吃一碗好吃、价格合理的面，只要 App 快速实现、用户没有严重问题，他不需要查看后厨。作为 CEO 或产品发起者，他还要把注意力放在用户、营销和方向，不愿把时间重新投入实现层。

徐文浩想建立的是软件工厂：让八个人产生过去八十个人的产能，并最终把知识工作杠杆从 1:5、1:10 推向 1:100。要优化生产线，就必须抽样查看产物，知道 agent 在何处失败、怎样把经验沉淀成 harness。对核心 agent runtime、基础设施和多人协作系统，他会比个人网站或临时脚本看得更细。

任鑫把王建硕的选择概括为一种有意的“矫枉过正”：为了抵抗自己作为资深工程师的惯性，强迫自己提前采用可能属于五年后的工作方式。它不一定是今天每个项目的效率最优解，却可以训练产品定义、反馈设计和 agent 管理能力。

徐文浩则担心，工具越强，人会去管理更高复杂度的问题，而非永远停留在今天的应用层。未来人看的也许不是当前编程语言，而是新的 DSL、执行图或模型行为证据；“理解中间机制”的需求不会消失，只会换对象。

一套可执行的选择框架

本节要点：代码审查强度应由可逆性、影响范围、维护周期、合规责任和团队协作共同决定，而不是在“永远读”与“永远不读”之间二选一。

场景 建议审查方式
一次性脚本、个人小工具 以结果和基础测试为主，可不读实现
可快速重建的早期原型 使用 agent loop、测试和版本回滚，抽样检查高风险部分
有真实用户的独立 App 增加端到端测试、监控和关键路径审查
多人维护的核心产品 保留人类责任人，检查架构、数据边界和关键 PR
金融、医疗、安全或不可逆数据操作 不能只依赖模型自检，必须采用独立验证与严格审查
建设 AI 软件工厂 抽样阅读产物，持续把缺陷转化为确定性工具和共享规则

材料说明与快速回查

  • “不看代码”仍需要测试、CI、版本管理、监控和多轮反馈，不是无条件信任模型。
  • 自然语言善于生成和解释规则，确定性工具善于完整、重复地执行规则。
  • 当前 prompt 到代码的过程还不具备传统编译器的稳定可复现性。
  • 测试通过可能只是 mock 覆盖了真实依赖，覆盖率不能独立证明质量。
  • 审查强度应由复杂度、寿命、协作人数和失败代价决定。
  • 人工查看的最高价值，是发现新缺陷模式并把它固化为自动治理能力。

本文依据节目转写重编。测试数量在节目转写与现有资料间存在口径差异，因此未用单一数字证明质量；文中的工作方式是两位嘉宾的阶段性实践，不构成适用于所有软件项目的统一工程标准。