当 AI 开始写代码，“整洁代码”反而更值钱了
AI 会写代码了，但它并没有魔法
最近一两年，关于“程序员是否会被 AI 取代”的讨论已经快把互联网聊包浆了。有人兴奋地说，以后需求提给智能体，测试一下结果就行；也有人半开玩笑地表示，终于不用再读同事留下的“祖传代码”了。来自 yanist.com 的这篇文章，讲的恰恰是这股乐观情绪里一个很容易被忽视的问题：AI 会写代码，不代表代码结构从此不重要。
作者借用了《Clean Architecture》里一个很经典的判断：代码有两种属性，一种是“价值”，也就是它能不能跑、够不够快、功能对不对；另一种是“结构”，也就是它究竟是怎么组织起来的。前者大家都看得见，老板看功能上线，用户看体验是否顺滑；后者则像城市地下的排水系统，平时没人夸，一旦乱了，代价会在未来几个月甚至几年里慢慢找上门。
这套说法放到 AI 编程时代，居然不但没过时，反而更刺耳了。因为很多人以为，大模型既然能“看懂代码”，团队就不必再在命名、分层、模块化这些老生常谈的工程纪律上花力气。可问题是，AI 并不是无所不知的上帝，它更像一个记忆有限、容易分神、按上下文收费的超级实习生。你给它的项目越混乱，它就越容易在文件堆里绕晕，最后交出一份“看起来能跑，但谁也不敢继续改”的答卷。
脏代码，不只折磨人，也折磨模型
“整洁代码”这个概念在程序员圈子里并不新鲜。可在今天，它多了一层非常现实的商业含义：这不仅关乎开发体验，还关乎 token 成本、调用延迟，以及 AI 输出是否稳定。
文章里提到，编码智能体的生产力同样受制于代码库状态。原因其实很好理解。现在的大模型虽然上下文窗口越来越大，但上下文不是免费午餐。上下文越长，模型推理负担越重，注意力越容易稀释，成本也跟着往上走。说白了，如果一个简单改动本来只需要看两个文件，结果因为项目结构混乱、函数依赖纠缠、命名全靠“感觉”，模型就可能被迫翻十几个目录、读几十个文件，像在一间没有标签的仓库里找一颗螺丝。
这和人类程序员的认知负荷其实很像。一个经验丰富的工程师，面对一套边界清晰、测试完整、模块职责明确的系统，往往能很快定位问题；可如果项目里充斥着“万能工具类”“神秘配置项”“复制粘贴再魔改”的历史遗迹，再厉害的人也得先花时间考古。AI 也一样，只不过它的“考古成本”是按 token 结算的，而且一旦上下文污染严重，模型还可能一本正经地胡说八道。
这里最值得行业警惕的一点是：过去坏结构的代价，很多时候只是“开发慢一点”；现在坏结构会直接放大为“双重损失”——既拖慢人，也拖慢机器。团队一边为 AI 编程工具付订阅费、API 费，一边又把模型扔进一锅乱炖似的代码库里，最后发现自动化并没有想象中那么神。这事听起来有点黑色幽默：我们花了很多钱请来一个很聪明的助手，却不给它一张像样的地图。
为什么今天谈“整洁代码”，比五年前更现实
如果把时间拨回五年前，关于整洁代码的讨论多少还有点“工程师自我修养”的意味。有人把它视为专业主义，有人则嫌它过于理想化，觉得业务压力面前，能上线就不错了。可到了 2026 年，这个话题突然变得非常务实。
因为软件开发的主角正在悄悄变化。越来越多公司开始把 AI 从“代码补全工具”升级为“任务代理”：让它读 issue、修改代码、补测试、提 PR，甚至自动回应 review 意见。这和早年的 GitHub Copilot 时代已经不是一个量级。Copilot 更像副驾驶，人在方向盘前；而现在流行的 coding agents，目标是直接替你跑完一段旅程。
问题也就在这里。副驾驶看错一个路牌，你还能及时纠正；但如果让代理自己上路，路线规划、道路标识、交通规则就必须足够清楚。一个结构清晰的代码库，本质上是在给 AI 铺设“可导航”的道路：模块边界像路网，测试像护栏，命名像路牌，目录结构像地图图层。反过来，混乱的项目就像在城中村里开自动驾驶，巷子又窄又乱，导航信号还时灵时不灵，别说效率，安全都成问题。
这也是为什么我觉得，未来软件团队的核心竞争力，可能不再只是“谁先接入了最强模型”，而是“谁的代码库更适合被模型消费”。这听起来有点陌生，但实际上和工业时代的流水线逻辑很像：机器并不会自动让所有工厂变得高效，真正决定产能的，往往是工艺、流程和组织方式。AI 也是同理。模型是发动机，代码结构是路况。
人机协作时代，代码审查反而更不能省
原文最后给了几个很朴素的建议，我反而觉得它们很接近现实。第一，给智能体派任务时，别只说“做出什么功能”，还要说“代码应该怎么组织”。第二，保持仓库本身的风格一致，因为模型很擅长模仿环境。第三，review 不能省，至少现阶段绝对不能。
这几条看似保守，实际上很重要。尤其是第三点。现在不少团队对 AI 写代码的态度，已经从“辅助”滑向“托管”——让它生成，再让测试兜底，仿佛只要功能通过，结构烂一点也无所谓。可问题在于，测试通常只能验证一部分外部行为，未必能及时发现内部结构正在劣化。今天 AI 为了赶任务把逻辑塞进一个巨型函数里，测试可能照样全绿；但三周后另一个智能体再来改这个功能，代价就会成倍上升。
这也是一个很有意思的争议点：当编码智能体越来越强，我们到底应该更关注结果，还是继续坚持过程质量？我的判断是，二者不能二选一。软件不是一次性交付的作文，而是要持续维护、持续迭代的系统。只盯结果不看结构，短期像是在省时间，长期往往是在透支团队未来的速度。
这让我想起 DevOps 刚兴起时的一句老话：If it hurts, do it more often。放到今天可以稍微改一下：如果 AI 总在你的代码库里迷路，那问题很可能不在 AI，而在路本身。与其抱怨模型“不够聪明”，不如先问问自己的仓库是不是像个迷宫。
好代码，正在从“工匠精神”变成“AI 基础设施”
过去大家提“好代码”，多少带点审美意味：优雅、克制、可读，像程序员的职业洁癖。可现在，它越来越像一种基础设施。你是否有清晰的模块边界，是否方便写测试，是否能让新成员快速接手，这些问题不再只是管理层口中的“最佳实践”，而会直接影响 AI 工具的投入产出比。
更进一步看，这可能会反过来改变软件工程的考核方式。未来企业采购 AI 编程工具时，恐怕不该只看模型排行榜，也要看自身代码库的“AI 适配度”。如果一个团队的仓库长期缺少文档、接口混乱、历史包袱极重，那么再先进的 coding agent 也很难发挥作用；相反，那些一直坚持工程规范的团队，可能会在 AI 时代吃到一轮延迟兑现的红利。
我甚至怀疑，接下来会出现一批新的服务和工具，专门做“面向智能体的代码治理”：不是单纯盯复杂度指标，而是评估一个仓库对模型是否友好，哪些模块最容易造成上下文膨胀，哪些目录最适合拆分，哪些命名最容易让智能体误解。这类工具今天看起来像细分市场，几年后可能会成为企业工程体系的一部分。
说到底，AI 没有终结软件工程，它只是把那些原本可以拖着不解决的问题，提前摆到了台面上。过去你可以忍受几分混乱，因为总有老员工兜底；现在你希望把更多工作交给智能体，就必须先把地基打平。这个逻辑一点也不浪漫，但非常真实。写给人看的代码，顺便也会更适合机器；而写得像谜语一样的代码，最后连最强的模型也救不了你。