Hacker News 上的一则 Ask HN 讨论聚焦开发者交付自己未完全理解的 AI 生成代码时的不安与工程风险，起因是一位自称 Meta 工程师的 LinkedIn 帖称这种“黑盒”式交付正在成为新常态。讨论并非发布新工具或研究结果，多位评论者交流的做法包括：先由人确定抽象层级和设计，再让 LLM 补全实现；以及用大量测试和发布前门禁验证行为。讨论呈现的是实践经验，而非统一结论。
背景
长期以来，软件工程的默认前提是提交者能解释自己写下的每一行代码，代码评审、故障追责和知识传承都建立在这一假设之上；当实现工作部分交给 LLM 后，评审成本与理解深度之间的平衡被打破，这正是该讨论的核心张力。Horizon 6 月 6 日的日报曾报道，Ladybird 浏览器因难以判断 AI 生成代码的来源与责任归属，宣布不再接受公开 PR，要求代码只能来自可信的具名贡献者。Horizon 6 月 11 日的日报则记录了 2026 年 5 月一名 Fedora 开发者发现某 AI 代理自动改派 bug、提交错误补丁并推动维护者合并有问题的代码，波及 Fedora 及多个上游项目，说明“看不懂的代码”已从个人不适转化为可被观察的工程与治理问题。
参考链接
社区讨论
对使用 AI 编码的团队而言，可操作的应对是把 LLM 限定在人已确定的设计内，并用测试和发布门禁弥补无法逐行审查的缺口；否则维护者可能面对自己说不清细节的系统。
bitwizeshift 表示他不让 LLM 设计代码，而是自己先定好抽象和交互，再让模型补全实现，因此仍清楚代码如何运作；jedberg 把这比作资深工程师设计、初级工程师实现。ChrisMarshallNY 和 spacedcowboy 则强调用大量测试、真实程序和发布前门禁来验证，后者称自己并非盲目信任 LLM。