为什么我会拒绝 AI 写的代码，哪怕它能跑
文章摘要
作者在这篇文章中提出了一个反直觉但越来越重要的观点：能运行的 AI 代码不应该被自动接受。虽然 AI 让代码实现速度大幅提升，但真正的挑战转移到了对生成结果的审查与验证上。作者强调，工程师必须对 AI 生成的方案保持批判性的监督，而不是被动地照单全收。
文章的核心论证围绕几个要点展开。首先是认知负担问题：审查别人（或 AI）写的代码会带来精神疲劳，即便遵循了”先规划、小步迭代”等最佳实践也无法完全消除这种负担。其次是经验的价值：作者发现，当他拒绝 AI 的方案并重新来过时，结果变好的关键并不在于换了更强的模型，而在于”屏幕背后的那个人”——他自己更深入的分析带来了更优的结果。
作者列出了五条拒绝 AI 代码的具体标准：一是当他无法独立地讲清楚这个实现思路时；二是当改动的范围超出了实际要解决的问题时；三是当代码引入了过早的抽象时；四是当方案在本地能跑但降低了系统整体清晰度时；五是当对输出的盲目自信盖过了他自己的真正理解时。
文章的核心警告是：“能运行、能让 CI 变绿的代码，仍然可能是一个糟糕的方案。” 作者主张在 AI 自动化的同时必须保留强制性的人工审查，强调卓越的工程实践需要经验丰富的开发者来引导，而不能交给 AI 自主决策。
HN 评论精华
Aurornis（高赞） 指出，即便经过精细的规划，AI 仍然常常为简单的任务构造出”一大堆复杂的抽象”。他给出的关键洞察是：在你深度熟悉的代码库上，AI 往往力不从心；但对于用你不熟悉的语言写一次性、用完即弃的代码，AI 表现得相当不错。
abhgh 提出了一个危险的场景：缺乏领域专业知识的初级开发者用 AI 做机器学习时，无法识别诸如数据泄漏（data leakage）这类微妙的错误。模型一开始甚至”拒绝看到”这个问题，直到被明确质疑才承认。
figassis 分享了在支付系统（高风险领域）上与 AI 协作的经验：尽管代码看起来能跑、也通过了测试，AI 却生成了”代码沙拉”——成百上千个不必要的、复杂的、重复的抽象。他的结论是：”有些东西它就是无法真正理解。”
关于”黑盒问题”，neonstatic 给出了尖锐评价：”阅读 AI 代码是一种浪费……理解它所花的时间，还不如自己直接写。”因为自己写代码时理解是自然发生的，而阅读生成的代码则需要反复琢磨才能搞懂。
ffsm8 批评了 AI 那句”你说得对，应该反驳”的谄媚回应（sycophancy），认为这纯属幻觉——模型只是生成连贯的文字，并不真正理解正确性，因此这种”附和式确认”对解决实际问题毫无意义。
jameslaneyno9 提出了一个务实的折中方案：在代码生成之前审查计划，而不是在成品代码出来之后再拒绝。他给出的数据很有说服力——审查计划只需 0.7 小时，而审查 PR 需要 16 小时；在 165 份计划中拒绝了 13 份，从源头上避免了无谓的编码工作。