背景
上个月我们团队排下个季度 roadmap 时，开发把一条任务写成"重构订单聚合接口，消除 7 处 N+1 查询"，估时 5 人日。PM 看了说：「用户没有投诉过慢，这不算技术债，把时间让给新需求。」架构师跳出来：「这不是债务，这是设计问题，应该走架构评审流程。」开发说：「它每跑一次多打 7 条 DB，QPS 800 时每秒多 5600 条无谓查询，这就是技术债。」
三方都没错，但没人能说服另外两方。最后这条任务被搁置了——不是因为不重要，而是因为没有人有权力把它放进 roadmap。
三种典型立场（我见过真实案例）
立场 A：开发主导 "我写的代码我知道哪里有问题，技术债识别权在我。" 风险：开发倾向于把"我不喜欢的设计"都归为技术债，有些其实是功能演进的自然结果，没有真实成本。
立场 B：PM 主导 "用户感知不到的就不是债，有业务指标的才算。" 风险：很多技术债是静默累积的——连接池配置不当、索引缺失、日志级别错误——它们不产生用户投诉，直到某天 P99 突然从 40ms 跳到 400ms。到那时再修，成本是原来的 3~5 倍（我见过一个 case，索引缺失拖了 4 个月，最后全表扫描拖垮了整条链路，修复花了 2 周而不是 1 天）。
立场 C：架构师主导 "所有结构性问题都走架构评审，技术债是架构层面的事。" 风险：架构评审流程本身需要 1~2 周，对于"改一个超时参数"级别的问题，流程成本 > 修复成本，架构师成了瓶颈。
我的倾向
我做了 3 年 PM，现在的做法是：用"可量化成本 + 时间窗口"来定义技术债，而不是靠角色拍板。
具体标准（我们内部叫"债务三问"）：
- 可量化吗？ 能不能用具体数字说清代价——多打多少 DB、P99 多高、内存多占多少、启动慢多少秒？说不清楚的，先放一放，不是因为它不重要，而是因为它还没有"利息"。
- 在恶化吗？ 代码量在涨、QPS 在涨、数据量在涨——债务的"利率"是不是在上升？如果现在是 7 处 N+1 查询，半年后可能是 15 处，利率就是正的，越早修越便宜。
- 修复成本 vs 利息成本？ 修复 5 人日，但每多拖一个月利息是 2 人日（性能劣化 + 排查成本），那 3 个月内就该修。拖过 3 个月，利息累计 > 修复成本，这笔债开始"吃本金"。
用这个标准，上面那个例子：7 处 N+1、QPS 800、每秒多 5600 条查询、数据量每季度涨 20%——三问全过，技术债成立，不需要架构师拍板，也不需要 PM 同意，直接进 roadmap。
想听大家
- 你的团队有"技术债"的量化标准吗？ 还是全靠"谁嗓门大谁说了算"？
- 静默技术债（不产生用户投诉但持续恶化的）你们怎么处理？有没有一种机制能在它从"7 处 N+1"变成"15 处 N+1"之前就触发行动？
- PM 拒绝"技术债"任务时，你用什么数据说服他？ 我见过最有效的两招：一是"不修的话，下季度这个接口要重写，成本从 5 人日变成 20 人日"；二是"这条链路上有 3 个 P0 故障的根因都指向这里"。你的招是什么？
- 架构师作为"技术债裁判"，会不会变成瓶颈？ 你们有没有把"小债务"（改一个参数、加一个索引）和"大债务"（重构模块、换技术栈）分开处理的机制？
欢迎贴你们团队的真实做法，哪怕是"我们就是这么乱来的但居然没出事"——我特别想听那种。