AI 没有智慧,你也不会有了
文章批评'不再读代码、不再写代码'的行业风气。作者指出代码可维护性和好架构难以即时度量,其恶果需要数月甚至数年才显现,而有经验工程师依靠长期实践积累的直觉来嗅出代码异味。AI 因缺乏可度量的奖励信号,无法理解什么是可维护的代码,且从质量低劣的野生代码中学习模式,在简化代码、定义可复用函数上表现糟糕。更危险的是,依赖 AI 写代码和读代码的开发者将永远无法达到精通,因为他们不再从错误中学习。作者认为 LLM 只是工具,预言未来会有公司以'无 AI'政策作为竞争优势。
文章批评'不再读代码、不再写代码'的行业风气。作者指出代码可维护性和好架构难以即时度量,其恶果需要数月甚至数年才显现,而有经验工程师依靠长期实践积累的直觉来嗅出代码异味。AI 因缺乏可度量的奖励信号,无法理解什么是可维护的代码,且从质量低劣的野生代码中学习模式,在简化代码、定义可复用函数上表现糟糕。更危险的是,依赖 AI 写代码和读代码的开发者将永远无法达到精通,因为他们不再从错误中学习。作者认为 LLM 只是工具,预言未来会有公司以'无 AI'政策作为竞争优势。
作者以 Mole 项目(11 万行 Swift、3347 个 XCTest)为例,从产品工程师视角分享 AI 全量生成代码时代保持代码可维护性的实践经验:由工程师主导架构设计与文档沉淀;重视覆盖边界场景的单测,坚持 AI 写的代码由 AI 测试;修 Bug 时补充回归测试并把原因写入规则;用按模块拆分的 Rules 和 Skills 记录功能边界与历史决策;坚持少做无用功能避免维护成本腐化;充分利用 GitHub Actions 与 CI 兜底验证,设置流程卡点让 AI 自动化验证,从而让代码长期持续迭代、清晰可扩展。