当我拒绝 AI 代码，即使它能运行

当“能用”的代码仍然被拒绝时

• 许多人认为，“能跑、测试全绿”只是最低门槛。
• 常见的拒绝原因包括：无法解释实现思路、变更范围比问题本身还大、过早抽象、推理与维护更困难，或者过度信任 AI 输出而不是自己真正理解。
• 不少人指出，这和优秀审查者对人类编写的代码应当采取的标准完全一致（例如对初级开发者或外包代码）。

风险、责任与适用领域

• 对安全关键或高价值系统（支付、基础设施、核心后端）的审查要求更高，而内部工具、个人项目或简单静态站点则可以宽松一些。
• 值班和支持预期：如果你在凌晨 3 点无法调试或解释这段代码，就不该发布它。
• 有些人认为，把自己没有真正审查过的 AI 代码合并进关键系统是不道德的。

AI 生成代码的质量

• 常见抱怨包括：过度抽象、过度设计、重复的工具函数、不必要的列/字段、前端做数据清洗而不是正确使用后端/数据库，以及在复杂领域里出现“代码沙拉”。
• LLM 被描述为会增加熵；如果缺乏强约束，它们往往不会收敛，反而会发散。
• 细微 bug（例如 ML 数据泄漏、会计边界条件）很容易被 AI 漏掉，也很难被新手发现。
• 也有人反驳说，平均水平的 agent 在基础结构和代码整洁度上已经超过了许多“企业”程序员。

工作流与护栏

• 有些人会搭建复杂的辅助系统：针对“AI 式写法”的自定义 lint 工具、严格的 pre-commit 检查、由脚本强制执行的 TDD、多模型交叉审查，以及定期的 AI 辅助审计。
• 另一些人主要把 AI 当作结对编程伙伴：用于制定计划、写小片段、语法帮助、跨语言/框架迁移，或把注释级伪代码展开成实现。
• 也有人公开合并自己并不完全理解的 AI 代码，依赖测试和对故障的快速反应；另一些人则认为这很冒险，甚至不负责任。

组织动态与激励机制

• 现有的糟糕激励——奖励大而快的提交和牛仔式作风——被认为会被 AI 放大，从而更快积累技术债。
• 有些人预见会出现类似“软件破产”的失败，或者至少是交付变慢、高级开发者流失严重，以及可能也会失败的重写尝试。

中间地带与长期担忧

• 关于“不使用 AI”与“完全 agentic 开发”之间是否存在稳定的“中间地带”，仍有争论。
• 人们担心技能退化、理解债务，以及未来会出现没人真正理解的系统。
• 也有人把 AI 看作“更快的键盘”，并认为真正的瓶颈仍然是人的理解和架构，这些不能外包出去。