AI 写的代码看不懂，你敢上线吗？
Ask HN: How to deal with shipping AI-written code you don't understand?
我在使用 AI 生成代码时遇到了困境：当 AI 写出的代码我完全无法理解，却又要将其部署到生产环境时，该如何权衡风险与效率？我担心盲目信任 AI 会带来隐患，但又渴望利用其提升开发速度。大家是如何处理这种‘黑盒’代码的？
我早已退休，只对自己负责。在质量与速度之间，我选择做个顽固的守门人。但我并不排斥进步，只是必须确保每一步都经得起推敲。
我的编译器前端能自动将标准 C 代码转化为 GPU 并行代码，无需人工修改。实测 Mandelbrot 算法加速了 187 倍，且校验和完全匹配，证明逻辑正确。
这个系统不仅能自动调度本地 GPU，还能管理局域网内的多机资源。它通过测量延迟和计算时间，智能决定将任务分配给哪台设备，实现真正的零开销加速。
HN 评论区
171- ChrisMarshallNY
测试。
大量的测试。我通常会与 LLM 进行交互式测试。既然我花在编码上的时间少了，就能把更多时间花在测试上。
据我的经验，使用 LLM 时，我做的测试比我自己写代码时还要多。我找不出编码错误，但确实能发现实现错误。
另外值得一提的是：我曾用 LLM 跑过一堆我自己写的、非常成熟的代码，我敢发誓那些代码是“完美”的，结果它还是找出了不少问题。
人无完人。信任，但需验证。
- 4ndrewl
这就是每个产品经理每天的感受。
如果你是一个靠 LLM 提示词来交付产品的“提示词工程师”，你的产出更像产品经理，而不是软件工程师。
- spacedcowboy
我逐渐开始接受这样一个观点：只要它能跑，我就满意了。以前我也不会亲自检查所有同事的代码，我只是信任他们干得不错。
但这并不意味着我盲目信任 LLM——我的项目是一个自动向量化编译器。我让它写了数以亿计的测试用例，并且有它编译过的真实、非平凡的程序。我在发布前运行一个“门禁”（gate），在 5 种不同的架构上字面意义上要跑好几个小时。说这段代码经过了测试……简直是轻描淡写。
我觉得有帮助的是长时间的规划会议，深入细节，理清边界情况，设计测试用例，也就是付出真正的工作和努力。一旦这些完成了，让它通宵运行并交付一个主要的生产功能就更容易了。
我仍然会审查代码，但扪心自问，我没法说审查了所有内容，有时在复杂的提交中我会漏掉一些东西。我尽量保持提交小而独立，但有时在兼顾“不要搞坏东西”的原则下，这并不容易做到。
所以归根结底：我在这个项目上干了大概 6 个月，到目前为止，这对我很有效。就像你随着时间的推移逐渐适应一位同事的怪癖一样。
我要说的是，据我的经验，代码质量相当高。也许这是因为前期规划阶段投入了大量精力，我不确定，但我似乎没有遭受人们抱怨的那种“垃圾代码”（slop）。个人情况可能不同（YMMV）。
- solatic
这与 AI 出现之前首席工程师（Principal level engineer）的生活并没有太大区别。你从技术上监督许多工程师在他们各自系统上的工作，但你不可能亲自审查所有代码。你明白人工代码审查可以减少但无法消除发布到生产环境的 bug 数量和严重程度。你脑子里没有底层的细节，只有高层的架构。你设计这些工程师之间如何协作，同时不越界干涉。
时间会告诉我们，从“信任人类理解底层系统”转向“信任花哨的计算器”是否正确。但到目前为止，它是行得通的。
- asimovDev
我今天也在为此挣扎。正在做一个功能，AI 审查标出了一个问题，所以我得去修。我一天内迭代了好几次，完全筋疲力尽，因为每次迭代都很复杂，修复代码大概要改 1000 行。最后终于定稿了一个我觉得至少稍微能放心提交审查的版本，但像这样的一天工作简直让人精疲力竭，整个晚上我都感觉糟透了（我正准备去睡觉，我可能会做噩梦，梦见自己按下了回车键，开启了毫无意义的计划中的自动模式——那种真正的噩梦感）。