那份200页的开发规范，该删了
你的团队有没有这样一份文档？
名字叫《XXX开发规范V3.2》，Word格式，200多页，目录就占了8页，最后更新时间是两年前。新人入职第一天被甩过来一份，翻了三页就放弃了——不是因为看不懂，是因为看着看着产生了一种在读《刑法》的错觉。老人们心知肚明这东西没人看，但谁也不敢删——它的地位类似于公司门口的灭火器，平时积灰，但你不能说它没用。
这份文档真正的作用只有一个：事故复盘的时候，Leader可以打开它说”规范里写得清清楚楚，是你没看”。完美甩锅，一气呵成。
你可能觉得这是执行力的问题——”规范定了没人执行，是团队管理不行”。但我想说一个反直觉的结论：90%的技术规范，从写下第一行的那一刻起，就注定会失败。 因为它们不是败给了执行力，而是败给了人性。
规范失效的第一因：权责分离
掘金上有一篇帖子曾经引发过大量共鸣，大意是吐槽：架构师花三天写了一份”微服务开发规范”，要求所有服务必须统一错误码格式、统一日志规范、统一接口文档模板。写完发到群里，附一句”大家遵照执行”。
然后呢？没有然后了。
问题出在哪？制定规范的人不承担执行成本。
架构师写规范的时候，坐在会议室白板前，手持马克笔，意气风发。他不需要每天在CRUD的泥潭里跟这些格式规则肉搏。他不知道”统一错误码格式”意味着每个开发者每次写接口都要多花15分钟去翻那个Excel码表——对，没错，码表还是Excel的，因为Confluence上那份三个月前就没人更新了。他也不知道”统一日志规范”意味着debug的时候不能随手 console.log 了，得用那个又臭又长的 logger.info({module: 'xxx', action: 'xxx', ...})。手打一遍，光花括号就能数错。
而一线开发者呢？他们每天被需求追着跑，产品经理在背后催，deadline在头顶悬着。你让他花15分钟查错误码表？他的选择一定是：先随便写一个 code: -1，心里默念”等有空再改”。程序员嘴里的”等有空”，跟你妈说的”下次再说”是一个意思——永远不会来。
制定者不执行，执行者没参与。 这是一种经典的权责分离。就好比让从不做饭的人来设计厨房——灶台高度一定不对，抽油烟机的开关一定在你够不着的地方。
规范失效的第二因：反馈缺失
我问你一个问题：为什么交通规则能执行得下去？
你可能会说”因为有交警”。没错，但更本质的原因是——闯红灯有即时反馈。摄像头拍下来，12分200块，下个月驾照就要出问题了。这个反馈回路又快又疼，所以绝大多数人会老老实实等绿灯。
现在看看技术规范的反馈回路：
写了个不规范的代码 → Code Review时可能被发现（如果reviewer仔细看的话）→ 改不改取决于deadline紧不紧 → 下次还是一样。
这个反馈回路有多少问题？第一，发现的概率不确定（reviewer可能不看这个点）；第二，发现到纠正之间有巨大延迟（可能已经过了好几天）；第三，不纠正也没有实际后果（又不扣工资）。
没有即时反馈的规则，本质上就不是规则，而是建议。 而建议这种东西，你知道的——在deadline面前一文不值。
这就是为什么 ESLint 比任何代码规范文档都有效。不是因为 ESLint 的规则更好，而是因为它的反馈是即时的：你写了一行不合规的代码，编辑器马上标红，CI直接挂掉。你不修就合不进去，没得商量。
好的规范自带红绿灯，烂的规范只有一份交规文档。
规范失效的第三因：成本转嫁
最后一个根因比较隐蔽，我把它叫做”成本转嫁”。
什么意思？就是规范的制定成本很低，但遵守成本很高，而且这两个成本由不同的人承担。
架构师花一个下午写出”所有接口必须使用统一的Response包装类”，成本很低，成就感拉满——发完群消息的那一刻，他觉得自己拯救了整个项目的架构。
但执行这条规范的一线开发者呢？他得记住这个包装类在哪个包里、怎么导入、泛型怎么写、异常情况怎么处理。写到一半发现文档里的示例代码跟实际版本对不上，还得去翻源码。如果项目里有20条这样的规范，那就是20个额外的心智负担——相当于脑子里同时开了20个Chrome标签页，卡是必然的。
人的工作记忆容量是有限的，心理学上叫”米勒法则”——大约7个加减2个信息块。你给了20条规范，等于让一个只有8G内存的机器跑20个Docker容器。结果不是一个个慢慢挂，而是直接OOM，一条都不跑了。
更狠的是，很多规范叠加在一起还会互相冲突。”代码要简洁”和”错误处理要完善”，这两条在具体代码里天天打架。到底听哪个？开发者不知道。就像你妈让你”多吃点”和你女朋友让你”少吃点”，你最终的选择一定是——谁在场听谁的，谁都不在就随便。
让规范自我执行的三个设计原则
说了这么多问题，该说解法了。我总结了三条原则，核心思想只有一个：别指望人去遵守规范，让系统替你执行。
原则一：能自动化检查的，绝不靠人review。
ESLint、Prettier、SonarQube、commitlint……这些工具存在的意义就是把”规范”变成”代码”。规范文档说”缩进用两个空格”，没用；Prettier直接帮你格式化了，你想不遵守都不行。
一个判断标准：如果一条规范不能被写成一条lint规则或CI检查，那它大概率会失效。 不是说这条规范不好，而是人类就是靠不住，你得认。
原则二：规范条数控制在20条以内。
这不是我随便说的数字。还是米勒法则的逻辑——扣掉日常工作中已经占用的心智资源，能分给”规范记忆”的最多也就十几个槽位。
我见过最有效的团队规范就写在一张A4纸上，打印出来贴在工位旁边，一眼扫完。200页的规范文档？那不是规范，那是百科全书。百科全书是用来查的，不是用来守的。
如果你的规范超过20条，不是开发者能力不行，是你的规范设计不行。 砍到20条以内，逼自己想清楚哪些是真正重要的。
原则三：每条规范必须标注”为什么”，不只是”是什么”。
“commit message必须使用conventional commits格式。”
这是一条典型的”是什么”型规范。开发者看到的第一反应是——”又多了一个要记的东西，烦不烦”。
但如果你这么写：”commit message使用conventional commits格式——因为我们的changelog是自动生成的，如果格式不对，发版时就没法自动归类这个改动，需要人工补，上次小王加班到晚上11点就是因为这个。”
同一条规范，加上”为什么”之后，遵守率能翻倍。因为人在理解了原因之后，规范就从”强加的规则”变成了”合理的约定”。人会抵触权威，但不会抵触道理。
那份200页的文档，该删了
写到这里，回到开头那份《XXX开发规范V3.2》。
真正有效的技术规范长什么样？不是一份文档，而是三样东西的组合：
一份20条以内的团队约定，贴在wiki首页，每条都标注了”为什么”。一套CI流水线里的自动检查，卡住不合规的代码不让合入。以及最重要的——团队在日常协作中形成的肌肉记忆。
规范不在文档里，在CI流水线里，在团队的肌肉记忆里。
那份200页的文档？删了吧。不敢删也行——至少别再往里面加东西了。
下次想给团队定规范的时候，先问自己三个问题：这条规范能不能自动化检查？不能的话，你真的需要这条吗？能的话，为什么还没配到CI里？
想清楚这三个问题，你的规范就已经赢过了90%的团队。
好的规范像空气——你感觉不到它的存在，但它一直在起作用。 如果你的团队每天都在讨论”要不要遵守规范”，那说明规范本身就有问题。真正成功的规范，是让人在不知不觉中就做对了事情。