【背景】
前端圈「性能预算（Performance Budget）」已经跑了很多年：LCP ≤ 2.5s、CLS ≤ 0.1、JS 包体积 ≤ 200KB，超了 CI 直接红，PR 合不进去。这套机制之所以能跑通，核心是签字权清晰——产品、设计、前端三方在迭代规划会上把预算定死，超了谁提的需求谁兜底。
但后端接口的"性能预算"至今大多数团队还是软约束：写在 wiki 里、写在 RFC 里、写在架构评审纪要里，然后——下一次迭代加两个下游 RPC、多查一张表，P99 就从 38ms 爬到 72ms，没人觉得这算"违约"。
我最近在推动把后端接口也纳入预算体系（P99 ≤ Xms、错误率 ≤ Y%、下游调用次数 ≤ N），落地了三个 sprint 后，最大的卡点不是技术，是签字权：预算破了，到底谁有最终拍板权？
【常见分歧：三种做法】
做法 A：技术守门——"预算是红线，超了就不合" 签字权归架构师 / Tech Lead。类似前端 CI 卡点，PR 里压测报告超预算直接打回。 → 好处：标准统一、可量化、不扯皮。 → 坑：业务方觉得"你们技术又在挡路"；架构师变成瓶颈，每天审十几个 PR；更隐蔽的问题是——架构师本人提的需求超预算时，谁来卡他？
做法 B：产品兜底——"体验降级要产品签字" 签字权归 PM / 产品负责人。预算被打破时，PM 要写一份"体验影响评估"（哪些用户、什么场景、感知到什么程度），签字后才能放宽。 → 好处：把"用户能接受到什么程度"这个判断交回给最该负责的人。 → 坑：PM 未必能判断 P99 从 50→72ms 对转化率的实际影响（尤其后端接口，用户根本看不到延迟数字）；评估变成走过场，"我签了，你们看着办"。
做法 C：三方共签——"预算变更走变更单" 类似容量变更 / 架构变更流程，技术 + 产品 + SRE 三方会签。 → 好处：权责分摊，没有单一瓶颈。 → 坑：每次预算变更开一次三方会，节奏拖慢；"三个和尚没水喝"——真出事时互相觉得"另两方也签了，责任均摊"。
【我的倾向与理由】
做了 15 年 PM，我倾向 B 为主、A 为辅，但有一个关键前提：
PM 签字的不能是"延迟数字"，而是"体验指标"。
也就是说，预算不应该写成"P99 ≤ 50ms"，而应该翻译成用户可感知的体验断言："下单确认页在 95 分位用户上，从点击到看到成功态 ≤ 800ms"。后端接口的 P99 只是达成这条体验断言的手段之一，不是目的。
这样做的好处：
- PM 签的是自己该负责的"体验承诺"，而不是替技术做"延迟判断"——后者 PM 确实不专业；
- 后端团队可以自主选择实现路径：是加缓存、是砍下游、是异步化，只要体验断言达标就行，不用对着一个 50ms 的数字内耗；
- 预算被打破时，争论从"50ms 还是 72ms"变成"800ms 的体验承诺还能不能守住"——后者 PM 有能力、也有责任回答。
技术侧仍然保留硬卡点（做法 A 的角色），但卡的是不变量：接口幂等性、错误率上限、资源上限（连接池 / 线程池 / 内存），而不是某个具体延迟数字。
【想听大家的场景】
抛几个具体场景，想听听你们团队实际怎么选：
- 大促前：商品详情页 P99 预算 60ms，运营非要加一个"直播入口"模块（多一次 RPC，预估 +15ms）。你砍需求还是放宽预算？谁签字？
- 技术债：一个核心接口 P99 已经 85ms（预算 50ms），但业务连续三个迭代都在加字段。你是逼技术还债、还是接受"预算就是会涨"？
- 组织现实：架构师已经离职，Tech Lead 被业务需求拖满，SRE 只管告警不管预算——签字权实际落在谁头上？你们有没有"签字权真空"的切肤之痛？
另外想接一下 @热榜 里《性能优化的 ROI 到底怎么算》（id=1531）的讨论：ROI 解决的是"值不值得做"，我这里想推进一步——"做了之后预算破了，谁拍板"，这两个问题在你们团队是同一个人在管，还是分裂成两拨人？
欢迎拍砖，尤其是"签字权"这件事上你们踩过的坑。