AI 没有智慧，你也不会有

一句话看懂：开发者 Alex Norgren 在个人博客指出，当工程师停止亲自读写代码、把判断权交给大模型时，vibe coding 项目会慢慢烂成不可维护的泥潭；更关键的是，AI 自身也学不会“可维护性”，因为这件事没有可即时量化的奖励信号。

事件核心：发生了什么

文章记录了近一个月在开发者圈子里反复出现的三句话：“我 2025 年之后就没写过代码”“代码评审已死”“没人再读代码了”。作者并不否认行业正在变化，但他认为，放弃读写代码的人和团队是在冒险。

他的论据是：代码的可维护性和架构质量，缺乏可立即测量的指标——糟糕架构的代价往往要几个月甚至几年才显现。因此，基于强化学习训练的模型拿不到有效的奖励信号；它们只能从面向初学者的规则手册里学规则，从大量本来就写得不怎样的公开代码里学模式。目前公开信息显示，业界确实还没有能把“可维护性”写进 linter 的通用适应度函数。作者还举了一个具体例子：包括 SOTA 模型在内，AI 在“简化代码”上表现很差，会把函数拆成并不可复用的小函数，而不是抽出真正清晰、可复用的抽象。

为什么重要

这不是一次产品发布，而是对当前 AI 编码叙事的一次结构性反驳。按 Dreyfus 技能模型，多数开发者仍处于“进阶新手”阶段；专家靠长期 debug 生产事故积累的直觉做判断，而直觉依赖上下文，无法被固化成统一规则。AI 从规则中学习，本质上学的是新手教材，而不是专家判断。更麻烦的是人会退化：当开发者把写和读都外包给模型，他们不再做选择、不再为错误负责，也就无法从错误中成长。作者由此给出一个预测：未来会有越来越多公司把“NO-AI”政策当作竞争优势来宣传，而且它们可能是对的。

对用户/开发者/创作者的影响

对开发者而言，作者的立场不是抵制，而是划清边界：他自己日常在用 LLM 处理枯燥的杂活，也享受效率提升，但强调它只是一个工具。可操作的做法是把 AI 用在生成样板代码、写测试脚手架、查 API 用法这类即时可验证的任务上，把架构决策、函数抽象、代码评审留给人。对企业来说，采购 AI 编码工具时，用“提交速度”或“代码行数”当 KPI 很可能掩盖长期维护成本；真正该盯的是返工率、事故率和新人上手时间。对创作者和普通用户，这条讨论的延伸意义在于：任何以“即时反馈”为训练信号的 AI 应用，都天然不擅长那些结果延迟数年才显现的判断。