随着AI生成代码速度加快，真正的瓶颈转向了代码审查环节。即使遵循良好实践，作者仍感到认知过载。相比直接使用AI生成的代码，作者更倾向于先深入理解问题，再引导AI生成更优方案，而非被动接受初始输出。

标题：即使AI代码能运行，我为何仍会拒绝它

随着AI编码速度越来越快，真正的瓶颈已转向审查AI生成的大量代码。我指的不只是同事（及其智能体）的拉取请求，而是你自己的编码智能体完成任务后，你面对git diff时的感受。

即便我遵循良好实践——比如先制定计划、将大任务分解为小阶段、逐步提交小改动——在审查自己并未真正思考过的代码时，仍会感到认知过载。

在编码智能体出现之前，接到任务后，我会先探索代码库、思考不同方案、进行实验，最后才着手实现。这个过程可能需要数天来整合所有上下文。当我最终提交拉取请求时，信心更足，向同事解释每项改动也更容易。

我必须承认，借助AI完成大型任务仍需要数天时间。我常常会拒绝AI的所有改动，从头开始。第一次和第二次会话的差异不在于大语言模型本身，而在于屏幕后的人。有了更多时间深入理解待解决的问题，我就能引导智能体找到更优方案，而不是被它牵着走。

我拒绝AI代码的原因越来越明确：

• 当我无法用自己的语言解释其实现思路时，我会拒绝。
• 当改动范围远超问题本身时，我会拒绝。
• 当它在未证明必要性之前就引入抽象时，我会拒绝。
• 当它在本地能运行却让系统更难理解时，我会拒绝。
• 当我更相信输出结果而非自身理解时，我会拒绝。

工程师们常常过快接受AI生成的改动，这正是我主张在AI审查之外必须有人工审查的原因。现实是，能运行且通过CI测试的代码仍可能是糟糕的解决方案，而工程学的本质始终是交付恰当、可扩展且易维护的方案。

我使用编码智能体已有一段时间。尽管它们令人印象深刻，但仍需要优秀的工程师引导它们走向卓越的解决方案。是的，编码智能体不仅能帮你写代码，还能协助完成任务，但这并不意味着它们目前就能以可持续的方式自主完成工作。

根据评论内容，总结如下主要观点及论据：

观点一：AI代码即使通过测试，也可能存在质量问题，应谨慎接受。 - 论据：代码通过CI测试不代表是好的解决方案，工程需要可扩展、可维护的代码（评论2：datadrivenangel）。AI常生成复杂抽象，而人类能找到更优雅、可维护的实现（评论3：Aurornis）。 - 关键引用：评论2："The reality is that code that runs and makes the CI green can still be a bad solution"；评论3："A lot of incidents where it would create some giant complex set of abstractions... I could find ways to do much more elegantly."

观点二：AI代码可能导致工程师技能退化，增加“理解债务”。 - 论据：工程师快速使用AI后，对未亲自编写的代码缺乏信心，难以解释变更（评论6：rvz）。代码库应保持人类可读，否则维护成本会飙升（评论7：eranation）。 - 关键引用：评论6："we are speed-running the deskilling of engineers into comprehension debt"；评论7："Keeping your codebase human readable... will save costs for LLMs to maintain it."

观点三：可通过工具和流程改进，使AI代码可接受。 - 论据：通过定制linter、自动化检查、多AI互审，可减少人工审查负担（评论10：cadamsdotcom）。使用TDD和规范驱动开发，可完全信任AI输出（评论14：piterrro）。 - 关键引用：评论10："create custom scripts that check for every single dumb AI-ism... put them in hooks"；评论14："Full automode where I use spec driven development and TDD... I do not look at the code at all."

观点四：AI代码的接受度取决于项目性质。 - 论据：对临时性、非关键项目可接受AI代码；对生产系统、高价值代码需理解其行为（评论4：summerlight）。AI代码在深度领域可能超越人类，但会导致代码库趋同于“企业级标准”（评论13：jdw64）。 - 关键引用：评论4："I am usually okay with agents driving e2e implementations if this won't make life noticeably worse"；评论13："AI tries to standardize the rest accordingly... entire codebase converges toward enterprise level standard code."

观点五：拒绝AI代码与拒绝同事代码本质相同，应坚持工程标准。 - 论据：软件工程的核心是拒绝“能工作”的代码，追求“正确”的代码（评论5：ecshafer）。若无法解释代码变更，就不应合并（评论8：AmareshHebbar）。 - 关键引用：评论5："Software Engineering is all about rejecting code that works for the right code that works"；评论8："If I can't explain the code without rereading the diff, I probably shouldn't merge it."

平衡性总结： 评论呈现明显分歧。一方强调AI代码的潜在风险（质量、理解债务、技能退化），另一方认为通过工具化、流程化可有效管理AI输出。中间立场则根据项目场景灵活决策，并指出AI可能改变代码库的整体风格。