小技巧的复利：工程效率藏在细枝末节里

一篇“没有大道理”的文章

技术社区里常青的一类文章，不讨论架构，也不谈方法论，只是老老实实列出一串小技巧：终端的反向搜索可以接上模糊匹配；数据库允许不带表名就跑一个查询，用来验证函数的返回；执行计划加上 analyze，就能看到真实耗时；正则里的单词边界断言；把指标值取对数做分桶；给接口请求复用同一个连接对象，延迟就降下来；用 git 的字符串追踪，找出某段代码是哪次提交引入的。

作者的说法很朴素：日常研发效率里，出乎意料的一大块来自这些知识颗粒。

为什么它值钱

大重构的收益曲线是台阶式的：一年一次，一次抬高一截，还要担风险。小技巧的收益曲线是复利的：一天用十次，每次省下几分钟。

更重要的是门槛。理解一套分布式架构需要大量前置知识，而知道“数据库可以不带 FROM 直接 SELECT”几乎不需要。知识颗粒越小，能用上它的人越多，扩散越快。

技巧会随人流失，规范不会

小技巧最大的问题是它活在个人脑子里。老师傅在，一切顺畅；老师傅走了，团队重新踩一遍坑。所以真正有价值的动作，是把技巧从个人习惯变成团队资产：把高频命令写进项目的脚本目录，把“该加上的那个参数”写进代码模板，把排查经验写进新人上手的检查清单。

为什么很多团队不做

因为它不产生可汇报的进度。重构有里程碑，技巧沉淀没有。这也解释了为什么“提效”常常只剩下一句口号：真正有效的手段太零碎，装不进季度计划的表格里。

一句话

与其等一次大改造，不如先把团队里那二十条反复出现的顺手操作抄下来。工程能力很多时候不是被设计出来的，是被攒出来的。