去年我还在认真执行「函数不超过 20 行」的规矩。今年我让 AI 写了一个 300 行的数据处理函数，跑得好好的，我盯着屏幕想了半天——这规矩到底是给谁定的？
给人定的。
传统代码规范的底层假设是：写代码的是人，人会犯错，人的工作记忆有限，人会在凌晨三点把变量名写成 tmp2_final_v3。所以我们发明了一整套规矩来约束自己。
现在写代码的不只是人了。那这套规矩还管用吗？
命名规范：反而更重要了，但服务对象变了
AI 不怕长变量名。你让它写 userAuthenticationTokenExpirationTimestamp，它不会嫌烦。它也不会因为 i j k 嵌套三层循环就搞混。
但问题是——你还要读这些代码。
AI 生成的代码有个毛病：命名风格不统一。同一个项目里，一会儿 camelCase 一会儿 snake_case，一会儿缩写一会儿全称。它不是不会命名，是不在乎一致性。
所以命名规范不但不能扔，还得加一条：给 AI 的 prompt 里必须写清楚命名约定。以前是 code review 时人盯人，现在是 prompt 里先把规矩说死。
函数长度：该松绑了
「一个函数不超过 20 行」「单一职责原则」——这些规矩的本质是什么？是因为人脑一次只能处理 7±2 个信息块。函数太长，人读不下来，容易出 bug。
AI 没有这个限制。它能一口气生成 200 行逻辑自洽的函数，而且不会因为「太长了」就在第 150 行走神。
我现在的做法是：AI 生成的代码，不强求拆函数。但如果这段代码以后要人来改，那还是得拆。判断标准从「函数多长」变成了「谁来维护」。
纯 AI 维护的工具脚本？随便写。人要碰的核心业务逻辑？老规矩不变。
注释：从解释 what 变成解释 why
以前写注释是告诉下一个人「这段代码在干什么」。现在 AI 生成的代码，what 层面基本不需要注释——代码本身就是 AI 理解需求后的产物，逻辑通常是清晰的。
但 why 层面的注释变得更重要了。
为什么选了这个算法而不是那个？为什么这里用了递归而不是迭代？为什么超时设成 30 秒？这些决策背景，AI 不会主动告诉你。你不写下来，三个月后你自己都不记得当时的 prompt 是怎么写的。
我现在会在 AI 生成的关键代码旁边加一行：// 选择 X 方案是因为 Y 场景下性能更好，见 prompt: Z。丑是丑了点，但管用。
DRY 原则：AI 天生反 DRY
Don’t Repeat Yourself，程序员的信条。但 AI 写代码的时候，它倾向于重复。
你让它在三个地方处理用户验证，它会在三个地方各写一遍几乎一样的逻辑。不是它不会抽象，是它没有「维护成本」的概念。对 AI 来说，复制粘贴和抽象封装的成本是一样的——都是生成几十个 token 的事。
这是个真问题。因为重复代码的维护成本是人来承担的。改一个地方忘了改另外两个，bug 就来了。
所以 DRY 不能扔。但执行方式变了：不是在写的时候要求 AI 遵守 DRY，而是在 review 的时候人来做抽象。AI 负责快速生成，人负责结构优化。分工变了。
设计模式：大部分可以降级
工厂模式、策略模式、观察者模式——这些东西的本质是什么？是在语言表达能力不够的年代，用固定套路来解决常见问题。
现在 AI 写代码，它不需要「记住」设计模式。你告诉它需求，它直接给你最合适的实现。有时候恰好是个策略模式，有时候不是，但它不在乎这个名字。
我觉得设计模式在 AI 时代的价值从「编码指南」降级成了「沟通词汇」。人和人讨论架构的时候说「这里用观察者模式」，大家秒懂。但你不需要强迫 AI 按设计模式来写——它有自己的方式，通常也不差。
唯一的例外是团队协作。如果五个人都在改同一个模块，统一的设计模式还是有价值的。但这个价值是给人的，不是给 AI 的。
该新增的规范
扔掉一些旧规矩的同时，有些新规矩该立起来了：
prompt 版本管理。 你用什么 prompt 生成的代码，记下来。prompt 改了，生成的代码行为可能完全不同。这比 git blame 更重要。
AI 生成代码的测试覆盖率要求。 人写的代码，你大概知道哪里容易出错。AI 写的代码，你不知道。所以测试覆盖率不是「建议」，是「必须」。我的标准是 AI 生成的代码测试覆盖率至少 80%，人写的可以酌情降低。
上下文边界声明。 AI 生成代码时的上下文窗口是有限的。一个函数如果依赖了上下文窗口之外的逻辑，AI 可能会做出错误假设。在代码里标注「这段逻辑依赖 X 模块的 Y 行为」，能帮 AI 在下次修改时不犯蠢。
极端情况：如果压根不打算 review 呢？
前面说的所有东西，都有一个隐含前提——人还是会看这些代码的。
但现实是，很多项目人根本不打算看。
内部工具、一次性脚本、数据迁移、原型验证、个人项目——这些东西不涉及安全，不涉及用户数据，坏了重新生成一个就行。你真的需要给一个用完就扔的 ETL 脚本写注释、拆函数、遵守 DRY 吗？
不需要。
如果人从一开始就不打算 review 代码，那传统代码规范几乎可以全部扔掉。命名？AI 自己能读懂就行。函数长度？无所谓。注释？给谁看？设计模式？多此一举。
这时候唯一重要的规范只剩两条：
第一，能跑。 测试通过，输出正确，不崩溃。代码写得再丑，跑得对就行。AI 生成，AI 验证，人只看结果。
第二，能重新生成。 与其花时间让代码「可维护」，不如确保你能用同样的 prompt 重新生成一份。代码变成了一次性产物，prompt 才是真正的源码。坏了不修，重新生成。
这听起来很疯狂，但想想看——我们已经在这么干了。有多少人写 shell 脚本的时候会遵守代码规范？有多少人会给 SQL 查询写单元测试？这些「用完就扔」的代码一直存在，只是以前量不大。AI 把这个量放大了十倍百倍。
当然，边界在哪里很重要。「不打算 review」不等于「不需要负责」。涉及用户数据、支付、权限控制的代码，哪怕你觉得是小项目，也不能用这个心态。但一个内部数据看板、一个日志分析脚本、一个帮你批量重命名文件的小工具？放过它吧。
代码规范的适用范围正在缩小。不是因为规范不好，是因为越来越多的代码根本不值得被「规范」。
说到底
代码规范从来不是目的，是手段。手段服务于目的，目的是写出能用、好维护的代码。
但「好维护」这个目标本身也在被重新定义。有些代码不需要维护，只需要能重新生成。
写代码的主体变了，手段就得跟着变。死守「函数不超过 20 行」跟死守「代码必须手写」一样，都是把手段当成了信仰。
该留的留，该扔的扔。别让规矩变成仪式。