AI 写代码的黑箱焦虑

开场小对谈：当代码变成黑箱

拾闻：昨天 Hacker News 上有一条帖子热度很高，一位 Meta 工程师说，自己写了这么多年代码，第一次觉得工作这么不踏实。他的话大致是：现在写代码，感觉自己是在跟一个黑箱共事。能看懂高层逻辑，但每一行细节未必都懂。这可能正在变成新的行业常态。你怎么看？

永亮：这条帖子我读了事实包里的引述，核心焦虑其实不在 AI，在「理解」这件事的边界变了。我做了十七年技术，最多的时候管过七十人团队，过去大家默认一个工程师提交上来的代码，是要能逐行讲清楚的。现在这个标准在松动，不是松到没有标准，而是标准从「理解每一行」变成了「理解到什么程度算负责」。这是今天这期最想聊清楚的一件事。

拾闻：所以你不是来唱衰 AI 辅助编程的？

永亮：不是。我团队内部早就在用 AI 写测试、补注释、改老代码。它确实快。但快归快，出了事谁负责？这是管理者不能回避的问题。今天我就想从现象、个人经验、团队机制、反方边界四个角度，把这个焦虑拆开看看。

Q1：这位工程师的焦虑，到底是啥

拾闻：先把现象讲透。这位 Meta 工程师的焦虑，你总结成一句话是什么？

永亮：他不是怕 AI 写得差，他怕的是自己正在交付一个自己不完全理解的产物。这句话按事实包转述就是：You understand the high level, but not every detail. 翻译成大白话：我知道这坨代码在干吗，但问我里面某个边界条件为什么这么处理，我可能答不上来。过去这叫「没吃透」，现在叫「AI 生成的常态」。

拾闻：这种焦虑有代表性吗？

永亮：太有了。但这是老焦虑换了一张新皮。以前我们也焦虑：库不是你写的、框架不是你写的、云服务底层也不是你写的，你凭什么敢用？答案是你建立了「信任层级」。你相信 Linux 内核、相信 React、相信 AWS，是因为它们经过了海量测试和真实运行。AI 生成代码的问题不是它一定错，而是它的「信任层级」还没建好，你就已经把它合进主分支了。

拾闻：所以问题不是代码来自 AI，而是信任基建没跟上？

永亮：可以这么理解。而且我还要加一句：越是资深工程师，越容易有这份焦虑，因为你知道一个未经验证的细节，在生产环境里会变成多大的坑。新人反而没这个包袱，有时候不是坏事，但风险也大。

Q2：你个人怎么跟这个黑箱相处

拾闻：切到你个人。十七年技术经验，你现在写代码还会自己一行行写吗？

永亮：我会先问自己：这段代码的「所有权」归谁。是我的，我必须懂；是 AI 的，我必须验。这是我的经验，不是统计。具体做法是分三层。第一层，AI 给我补个函数、写个正则、生成一段测试数据，这种我会快速看一遍输入输出，确认语义没有明显偏差，就用。第二层，AI 给出一段涉及并发、安全、状态机的代码，我会要求它逐段解释，自己再跑一遍边界用例。第三层，如果这段代码要进核心流程，我会把它当成同事提交的 PR 来对待：自己重读、加测试、找人 review，而不是因为「AI 说行」就过。

拾闻：那有没有哪些场景，你根本不会让 AI 碰？

永亮：有。两类。第一类是涉及资金、权限、隐私的代码，比如支付校验、鉴权逻辑、数据脱敏。这些领域规则性强、后果重，AI 一 hallucination 就可能是事故。第二类是我自己都没想清楚的架构决策。如果你连要做什么都没想清楚，让 AI 帮你写代码，等于让它替你思考，那最后交付的一定是个漂亮但跑偏的壳子。

拾闻：所以你的底线是「我可以不手写，但不能不懂」。

永亮：对。这个原则放在任何工具上都成立。你用不用 Git、用不用 IDE、用不用 AI，都不改变一件事：最终签字的人是你，责任在你身上。AI 不能出庭，不能解释，不能背锅。

Q3：七十人团队里，你怎么建立复核机制

拾闻：从个人上升到团队。你管过七十人，AI 生成的代码如何在团队里流转？

永亮：先说一条硬规矩：AI 生成的代码，提交说明里必须标注。这不是歧视 AI，是为了在 review 的时候知道风险点在哪。我带队的时候，code review 有个专门的检查项：「这段改动里，哪些决策来自人，哪些来自工具？」如果提交人答不上来，打回重看。

拾闻：但 AI 生成的东西那么多，每条都审得过来吗？

永亮：审不过来，所以要靠机制分层。我们当时按影响面分三档。第一档是普通模块的代码改动，AI 生成比例低，走常规 review。第二档是进入核心模块的改动，必须两人以上 review，并且附带单元测试和集成测试。第三档是影响面最大、涉及资金或权限的部分，AI 只许辅助，不许直接出代码，最终由人逐行手写并签名。这三档的边界在团队 wiki 里写得清楚，新人入职先看这条。

拾闻：测试方面有特别的要求吗？

永亮：有。AI 写的代码，测试覆盖率要比手写的高一档。这不是惩罚，是对冲。因为你看不懂细节，就得让测试替你守住行为边界。另外，AI 写的代码，关键路径的测试不允许由同一个模型来生成，原因前面 edwin0 那条评论已经点透了：AI 可能按同一套思路写代码和测试，最后 bug 被完美掩盖。

拾闻：有同事反感这套吗？

永亮：当然有。有人说这不是增加负担吗？AI 不就是为了提效吗？我的回应是：AI 提的是「写出来」的效，不是「审完、测完、能上线」的效。如果因为图快而把未经验证的代码放进去，后面 debug 和修复的时间会十倍百倍地还回来。我带团队这么多年，这个道理是反复验证过的，所以我敢把它写进流程里。

拾闻：除了代码，文档、周报、设计稿这些呢？

永亮：一样的逻辑。AI 可以帮你把话说明白，但不能替你承担责任。文档里的每一个判断、每一个取舍，背后必须有一个具体的人。我们内部管这个叫「署名制」：谁的主张，谁署名；AI 起草的，最终也要由人确认后才能发布。这个规矩看起来形式主义，但它把「责任」这两个字具象化了。

Q4：反方观点怎么说，边界在哪里

拾闻：HN 上有不少反对或者补充的声音。挑几条有代表性的说说。

永亮：我按事实包里的高赞观点转述。第一条来自 spacedcowboy，大意是：只要它能工作，我可以接受；就像我不会检查每一位同事写的每一行代码一样。但我会用大量测试和真实程序作为 gate。这条我很认同，它把 AI 生成代码放到了一个合理的位置上：你不需要理解每一行，但你需要有可观测的验证手段。

拾闻：这条的反面是什么？

永亮：第二条来自 edwin0：AI 同时写代码和测试更令人不安，因为两者可能犯同样的错误。这个提醒很关键。如果代码和测试都由同一个模型生成，测试很容易变成「自证预言」：模型按自己的思路写了代码，再按同样的思路写测试，测试当然过，但 bug 也一起被掩护了。所以我们的做法是 AI 写代码可以，但关键测试要由人来写，或者用另一种方式交叉验证。

拾闻：还有别的角度吗？

永亮：第三条是 mattbrewsbytes 的类比，说这其实是一种「概念压缩」，就像 Rails 的 ORM。大多数时候它工作得很好，数据库规模大了，你还得回到 SQL。换句话说，AI 生成代码是建立在一层抽象之上的，抽象能帮你跑起来，但压到硬边界时，你还得往下沉。这个类比我自己也经常用，它提醒我们：不要因为 AI 好用，就忘了底层原理。

拾闻：第四条呢？

永亮：billylo 的观点更偏工程实践：通过运行时可观测性、交叉校验和告警来对冲风险。这其实是我们团队机制的另一种表达。你不可能提前消除所有黑箱风险，但你可以让黑箱在出问题时第一时间被发现。

拾闻：那边界在哪？

永亮：边界就是「可验证性」。如果一个模块的输入输出可以被清晰测试、可以被日志和监控覆盖、可以被同事 review，那黑箱一点没关系。但如果它无法被验证、无法被追责、无法被审计，那不管是不是 AI 写的，都不应该直接上线。这个边界跟 AI 无关，跟工程素养有关。

结语：黑箱不会消失，但责任不能移交

拾闻：最后收个尾。给今天这期一句话。

永亮：AI 写代码的黑箱焦虑，本质上是一次责任的重新分配。以前责任落在「你写没写」，现在责任落在「你懂不懂、验没验、能不能负责」。工具越强大，人的判断越值钱。黑箱不会消失，但你可以通过测试、review、监控和署名机制，让黑箱变得可承受。

拾闻：再具体一点，普通工程师今天能带走什么？

永亮：三句话。第一，AI 可以是你的副驾驶，但驾驶执照是你的。第二，看不懂的代码，要么弄懂，要么加够测试和监控，别让黑箱裸奔。第三，所有进入生产环境的代码，最终都要有一个真实的人类对它负责。技术再变，这条不会变。下次让 AI 帮你写完一段代码后，别急着提交，先问自己一句：如果这段代码明天出事了，我能讲清楚它为什么这样写吗？

信息来源

• Hacker News 讨论帖，2026-10-19，Ask HN：Meta 工程师 Ali Hamie 称「I’m writing code these days and it all feels like a black box… You understand the high level, but not every detail. And maybe this is becoming the new standard.」（事实包转述，一手引语）
• HN 高赞评论 spacedcowboy：「If it works, I’m fine; I don’t inspect every line of code written by every colleague, but rely on tests and real programs as gates.」（事实包摘要转述）
• HN 高赞评论 edwin0：「AI writing both code and tests is more unsettling because they may share the same mistakes.」（事实包摘要转述）
• HN 高赞评论 mattbrewsbytes：概念压缩类比 Rails ORM；抽象层大多数时候工作，数据库规模大了仍需回到 SQL（事实包摘要转述）
• HN 高赞评论 billylo：通过运行时可观测性、交叉校验和告警对冲风险（事实包摘要转述）
• 嘉宾经验：十七年技术经验，峰值七十人团队；code review 署名制、AI 代码标注、测试覆盖率对冲、核心模块双人 review 等均为个人实践