去年秋天，技术求我帮一位做独立游戏的技术求朋友排查卡顿。他用的技术求引擎是Unity，画面很简单，技术求2D像素风，技术求按理说跑起来该毫无压力。技术求结果在他那台配置不低的技术求笔记本上，帧率就是技术求上不去，一开战斗场景就掉到二十几。技术求我们查了三天，技术求最后发现罪魁祸首是技术求一张1024×1024的贴图——它被无脑地塞进了UI图集里，而那张图实际显示在屏幕上的技术求尺寸只有64×64。GPU每帧都在为这块“巨大”的技术求纹理做采样，显存带宽就这么被白白吃掉了。技术求

这事让我想起很多技术要求的技术求本质。它们不是冰冷的条条框框，而是前人踩过的坑，用血泪写成的“避雷指南”。你写“纹理尺寸尽量控制在2048以内”，背后可能是一个美术同学在凌晨三点对着黑屏崩溃；你写“接口必须做幂等处理”，背后是一次线上支付重复扣款的严重事故。技术要求真正的价值，在于把那些隐性的、容易忽略的代价，提前摆到台面上来。

但技术要求也分好坏。坏的技术要求像一堵墙，它告诉你“不能这么做”，却不告诉你“那该怎么做”。我以前见过一份文档，通篇都是“禁止使用全局变量”“禁止修改公共类”“禁止直接操作数据库”，看得人头皮发麻。结果新人来了根本不知道从哪下手，老员工也嫌约束太多，最后文档被扔在角落里吃灰，该违规的照样违规。

好的技术要求更像一张地图，它标注了哪些路是危险的，同时也会画出几条安全的路径。比如同样是限制全局变量，高明的写法会是：“如果需要共享状态，优先考虑依赖注入或事件总线。如果确实要用全局变量，必须在注释里说明原因，并保证只在初始化阶段写入。”这样既给了约束，也给了出口，还留了判断的空间。

还有个容易被忽略的点：技术要求必须能落地验证。你写“代码要清晰易读”，这算要求吗？算，但没法检查。换成“函数行数不超过80行，超过则需要拆分”“命名必须能表达意图，禁止使用a、b、c这种无意义变量”，这就可执行了。我见过最离谱的一份要求，写着“系统应具备良好的用户体验”，当时我就笑了——这种话说了等于没说，谁会觉得自己的系统体验差呢？

技术要求还应该有时效性。技术栈在变，业务在变，去年合理的限制今年可能就是阻碍。比如早年移动端Web要求图片必须压缩到100KB以内，现在5G都普及了，这要求就显得过时。定期审视和修订技术要求，和写新的要求同样重要。我那位做游戏的朋友后来把图集规范改成了“按实际显示尺寸分级”，卡顿问题迎刃而解，而那份新规范里，第一条就写着：“所有贴图，先问一句，它真的需要那么大吗？”

说到底，技术要求不是用来炫技的，也不是用来限制人的。它是在团队协作中，大家达成共识的一种方式。写得好的技术要求，读起来像一位资深工程师在你旁边小声提醒：“哥们儿，这条路我走过，前面有坑，你绕一下。”——这就够了。