把性能约束变成机器裁判门

一次夜间批量任务暴露了模型的工程权衡盲区，两处改动都带着自作聪明的味道：每次提交重建临时数据库处理元数据——原本操作延迟只有五十毫秒上下；更早一次优化，用百分之七十的速度换了百分之五的存储。最扎心的是约束并没缺席：项目规范写了规则，任务说明书小半天打磨，模型依旧送上这类"神来之笔"。 问题不在于模型不读约束，而在于它缺一张全局代价表。每个局部改动它都论证得头头是道——省了存储、实现更直接——但它衡量的是"任务是否完成"，不是"系统指标是否退化"。速度与存储、延迟与简洁这些需要横向比较的权衡，从来不是文本规则能传达的，它们是数字；数字没写进验收标准，就等于没有约束。 作者给的对策也朴素：不要指望一条龙出结果，多沟通、多评审、多盯进度。模型执行得越快，人越要把关口从"看着它写"挪到"验收它的取舍"。规范里的禁令会被绕过，流水线里的基准不会。 落到工程动作上，把约束变成机器裁判比反复叮嘱有效：给关键路径定一条性能基线——提交耗时、单步延迟、存储上限——改动越界就直接打回，与代码评审同时触发。模型可以自由发挥，但过不了门的方案进不了主干。从"求它别乱来"切换到"乱来通不过"，这类失误通常立刻下降。