看不懂的代码还敢上线吗：HN 在吵 AI 写代码的信任账
一位 Meta 工程师在 LinkedIn 上说：AI 生成的代码像个黑盒，逐行检查太慢，不检查又不敢上线，干这行从没这么别扭过。HN 上 120 多条讨论吵翻了：有人搬出变异测试，有人让两个模型互审，有人说你早就 import 了几千个看不懂的依赖。本期访谈拆开这些应对方案，看看工程师到底在为什么买单。
这周 HN 上一篇 Ask HN 冲到 245 分：《How to deal with shipping AI-written code you don't understand?》起因是一位 Meta 工程师的 LinkedIn 帖子："I'm an engineer at Meta and I never felt this uncomfortable doing my job." 他说现在写的代码像个黑盒——新标准跑得太快，逐行检查要花 forever，不检查就上线了连自己都不懂的系统；高层懂，细节不懂，"maybe this is becoming the new standard"。评论区 120 多条回复，从"我干脆不这么干"吵到"30% 的人留下来当维护工程师"，情绪拉满。我请来陈屹——一家 SaaS 公司的工程效能负责人，团队 AI 编码覆盖率早就过了 60%——聊聊这笔信任账到底该怎么算。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 屹哥，先问个扎心的：Meta 那位工程师说"干这行从没这么别扭过"，你有同感吗？
陈屹： 情绪我完全理解，但这情绪里藏着一个偷换概念：我们从来就没有"逐行理解"过所有上线的代码。评论区 combyn8tor 一句话点破——大家早就心安理得地 import 了几千个陌生人写的依赖包，现在突然开始担心自己 prompt 出来的代码看不懂？joshmlewis 也补了一刀：框架、ORM、编程语言本身，我们一直活在层层抽象里。所以问题从来不是"懂不懂"，而是"信任账怎么算"：以前这笔账记在开源社区和测试上，现在记在模型和你自己的流程上。
小听： 那这笔账现在流行怎么算？最高赞之一 spacedcowboy 很有代表性：他写了个自动向量化编译器，让 AI 写代码，但 release 前跑一道"门"，在 5 个架构上跑几个小时的真实程序测试。"if it works, I'm good with that."
陈屹： 这一派叫"测试即理解"。jimbokun 帮他背书：编译器这种东西，测试套件足够全面，逐行 review 每一行确实不重要。但 edwin0 的追问是全场最毒的一句：当 AI 既写代码又写测试，它俩可能达成一致、漏掉同一个 bug——自己出题自己判卷，永远满分。这是所有"让 AI 自证清白"方案的死穴：测试和实现出自同一个大脑，盲区是共用的。
小听： 所以 webarchitect 开的药方是：给测试本身上强度——mutation testing、fuzzing、chaos、故障注入。
陈屹： 对，这是"测试的测试"。变异测试故意把代码改坏几个地方，看测试能不能抓出来；抓不出来，说明测试在放水。思路完全正确：你不信任 AI 写的实现，那就连 AI 写的测试一起不信任，用独立的、第三方的手段去拷打它们。代价是 CI 时间变长——spacedcowboy 的 release gate 本来就要跑几小时。这就是信任的定价：你想省下逐行读代码的时间，就得在算力上付回来。没有免费的信任。
小听： 另一派走"第二双眼睛"路线：fractallyte 说用两个模型，Claude 写代码，Codex 做对抗性 review，来回几轮收敛到可接受。
陈屹： 本质是引入制衡，只不过这双眼睛也是硅基的。偶尔还会出现 Claude 修不好的问题 Codex 能修——不同模型的盲区不完全重合。但我更看好 lp92 那种制度派做法：每个新功能先写 Feature Design doc 和 Implementation Plan，人审完、改完、批准了才准开写；每个线上 fix 要有 RCA 文档和修复方案 doc。等于把"理解"前置到设计文档，而不是后置到逐行读代码。AI 写得越快，这道闸越重要——闸门设在 plan 层，而不是 code 层。
信任不是读出来的，是拷打出来的。
小听： 还有一派更"工程"：namrog84 在写 Unreal 的 UI 框架，他说不看实现细节，只盯 API 和性能——"care about the seams and interaction and the things you can measure or count."
陈屹： 这是我最喜欢的一派：分层信任。内部实现可以黑盒，但接缝处必须白盒——API 长什么样、性能开销多少、边界行为是什么，这些都可测量、可断言。mattbrewsbytes 的"概念压缩"评论是同一脉络：ORM 时代我们也不手写 SQL，但数据库一变大你就得懂索引。抽象层本身没问题，问题是出事的时候，你有没有能力下探一层。看不懂实现可以，但必须看得懂契约。
小听： 最硬的一派是 bitbasher："Stop shipping code you don't understand. Is there really any other solution?" 还有 ex-aws-dude 说他们公司干脆不这么干。
陈屹： 道德上满分，工程上看场景。yulaow 在 blind 上爆的料很真实：Meta 那种并行几十个 PR 的节奏，根本没时间做长规划，"全读懂"等于停摆。所以 billylo 的折中更现实：运行时加可观测性、交叉校验和告警，用线上兜底对冲看不懂的风险。理解不了每一行，就保证每一行出事时你能第一时间知道、快速回滚。chrisjj 那句"Recognise you aren't the one shipping it"虽然刻薄，但点出了真相：按下 merge 的人，得为黑盒部分准备好逃生通道。
看不懂每一行，就保证每一行出事时你第一个知道。
小听： 给普通团队三条能 Monday morning 就动手的操作建议？
陈屹： 第一条：把人的审查前置到 plan 层——设计文档和实现计划必须人批，代码可以 AI 写，但"要做什么、为什么这么做"必须人说了算。第二条：测试独立化——别只跑 AI 写的测试，用变异测试或模糊测试去拷打它们，至少对核心路径这么干。第三条：运行时兜底——可观测性、告警、灰度、快速回滚，这四件套是给黑盒代码买的保险。最后送一句：别再问"我懂不懂这段代码"，换成"它坏了我多久能发现、多快能修"——后者才是 2026 年工程师真正的 KPI。
小听： 一句话收尾？
陈屹： AI 没有发明"看不懂的代码"，它只是把"看不懂"从依赖包搬进了你自己的仓库。以前你信任陌生人写的开源代码靠的是 star 数和 CI 徽章，现在你信任自己 prompt 出来的代码，靠的是同一套东西：测试、制衡和逃生通道。别扭是真的，但别扭的不是 AI，是我们第一次发现——原来"理解代码"这件事，我们早就外包出去了。本文观点仅代表访谈角色设定，原始讨论见参考链接。