Ask HN：如何应对上线自己看不懂的 AI 写的代码？
Ask HN: How to deal with shipping AI-written code you don't understand?
这是 Hacker News 的 Ask HN 讨论帖，作者引用一位 Meta 工程师的 LinkedIn 帖，称如今写代码像黑箱，逐行审查 AI 生成代码不现实，可能导致上线后对系统细节缺乏真正理解，并询问其他工程师是否有同样感受、如何处理。帖子围绕理解程度与交付速度之间的取舍展开提问。适合日常用 AI 写代码、需要审查和交付 AI 生成代码的工程师阅读。
- 分级
- 值得看
- 收录时间
- 2026-10-26
原帖
I'm an engineer at Meta and I never felt this uncomfortable doing my job. I'm writing code these days and it all feels like a black box. This new standard of shipping with AI is moving so fast that if we're going to spend our time checking each line of code, it's going to take forever.
中文大意
发帖人 rzk 引用一位 Meta 工程师的 LinkedIn 帖：现在写代码像黑盒，逐行检查又太慢，于是可能交付自己并不真正理解的系统，只知道高层逻辑、不懂细节，这违背软件工程师的本能。他想知道其他工程师是否也有同感、大家怎么应对。评论区给出多种做法：写大量测试并配合多架构发布门禁、先做规划和设计文档、用可观测性与告警兜底、让 AI 解释不懂的部分、用 fuzz/变异测试验证测试本身、TDD 并让 agent 先跑端到端测试、审查测试代码、用其他 agent 做对抗式评审、把重心转向 API 与性能等可度量指标，或干脆不交付不懂的代码。适合正在用 AI 写生产代码、并关心代码质量与责任边界的工程师和团队负责人阅读。
讨论区核心观点
依据 40 条评论
- 立场强硬派：不要交付自己不懂的代码。要么弄懂，要么放慢速度、拒绝甚至换工作；不懂代码就只能算管理者，还违背工程职业本身。 出处（新标签页打开）
- 靠测试建立信心：巨量测试、多架构发布门禁、fuzz/变异测试、TDD（先看测试失败再让它通过）、端到端测试、故意注入 bug 验证测试是否有效。 出处（新标签页打开）
- 用流程和文档做关卡：长时间规划并设计好边界用例、特性设计文档、实现计划、RCA 文档、架构文档，让 AI 解释不懂的部分并自行核实。 出处（新标签页打开）
- AI 同时写代码和测试时，两者可能共享同一个盲点；需要用对抗式评审、其他 agent 互审、人工审查测试代码来补位。 出处（新标签页打开）
- 类比 ORM、MVC、Principal 工程师或创始人：本来就不可能掌握所有细节，只要可观测、性能、API 等可度量面可控，并确认“够用即可”。 出处（新标签页打开）
- 质疑这种叙事：AI 更快应该带来更多检查时间，而不是放弃质量；最终责任仍在人身上，迟早要在写作或调试阶段付出代价，按领域风险差别（如医疗、航空）决定要理解到多深。 出处（新标签页打开）