申请两台机器，说了三周没批下来。回头看审批记录，对方既没同意也没反对，只是每次都在问"这个到底是干什么用的"。技术请求被卡住的常见原因不是被驳回，而是它无法被决策：接收方听完不知道要签什么字、放行什么风险、从哪一笔账里出。
这篇讲的是把"我们需要资源"翻译成一句能被当场拍板或当场否掉的话。判据不是表达漂亮，而是对方能不能不追问地做出决定。
1. 被打回的不是请求，是"无法决策的请求"
| 形态 | 表面现象 | 真实原因 |
|---|---|---|
| 沉没 | 提了没人回，催了说"再看看" | 请求里没有可比较的选项，排不进任何队列 |
| 退回 | 被要求"再补一份材料" | 后果不可验证，只能靠感觉判断 |
| 驳回 | 明确说没有 | 需求成立但优先级排不上，而你只给了"要"没给"换" |
递上去的三句话里，往往缺的是第二句和第四句：
// 原始请求（无法决策）
我们要两台 16C32G 的机器，做新的检索服务，下个月要用。
─── 缺：不给我会怎样、给别的行不行、最晚什么时候
// 可决策版本
要：2 台 16C32G（或 1 台 32C64G 等价）
做什么用：支撑 RETRIEVAL_SVC，承接现有 SEARCH_API 的 QPS 峰值
不给会怎样：峰值时段 SEARCH_API 延迟 P99 从 X 升到 Y，超时率 Z%
什么时候要：DAYS_BEFORE 前到位，晚于该日期则本期不上线
2. 可决策请求的四个要素
| 要素 | 缺了会怎样 | 写法要求 |
|---|---|---|
| 要什么 | 对方无法估量代价 | 数量 + 规格 + 等价替代（一台大的行不行） |
| 做什么用 | 归不进任何既有预算项 | 挂到已有系统名或项目号上，别造新名词 |
| 不给会怎样 | 只能按"想要"处理，永远排在故障之后 | 可验证后果：延迟、错误率、无法交付的日期 |
| 什么时候要 | 变成"越早越好"，等于没有时间约束 | 明确到日期，并说明晚一天的代价 |
四要素齐了，请求就从"讲故事"变成"填参数"。填不出来的那一项，通常说明你自己也还没想清楚——先补那一项，别急着递。
// 四个要素的验收：填完自查，四项都能被第三方复述
要什么 → 规格 + 数量 + 等价替代（一项都不能少）
做什么用 → 挂到 SYSTEM_ID / PROJECT_ID，不用新造名词
不给会怎样 → 监控上可见的指标变化 + 时间点
什么时候要 → 日期 + 逾期后的动作
─── 任一项只能写成形容词（稳定、流畅、重要），视为未填
顺手把口径统一：说"峰值 QPS"就给出统计窗口（1 分钟还是 5 分钟），说"P99"就给出采样来源。同一个词在两份材料里口径不同，审批方第一反应是整份材料都不可信。
3. 把"资源不够"翻译成"风险与时间的对应关系"
"我们资源不够"是状态描述，无法决策。"不扩容，PEAK_DATE 之后每天有 P% 概率出现 Q%"是风险与时间的对应关系，可以被排序、可以被对冲、也可以被明确接受。
| 说法 | 决策者听到的 | 应换成 |
|---|---|---|
| 资源不够 | 你想多要 | 在 PEAK_DATE 之后，余量只剩 R% |
| 压力很大 | 情绪 | 峰值 QPS 已到 X，容量上限 Y |
| 快撑不住了 | 不可验证 | 再增加 N% 流量即触发限流，影响 M 个接口 |
| 影响很严重 | 无法比较 | 影响 ROLE_A 的核心动作，恢复时间约 T |
// 风险-时间表：一行一个时间点，让对方看到自己的选择
T0（今天） 余量 R% 正常
T1（+30d） 余量 R% 正常，需在 T0+15d 前决定
T2（+60d） 余量 0% 触发限流，影响 INTERFACE_LIST
T3（+90d） 余量负 部分功能不可用，需降级方案
─── 决策点只有一个：T1 之前是否给资源。T2 之后再决定，只剩救火
把决策点前移，是这个表唯一的作用：它让"以后再说"变成一个需要承担后果的选择，而不是一句拖延。
4. 三种不该出现的表达，和"不给会怎样"的写法
| 表达 | 为什么不成立 | 替换 |
|---|---|---|
| "我们一直这么干的" | 历史不构成理由，只构成惯性 | 现在这套的容量上限是多少，何时触顶 |
| "别人都有" | 别人的约束条件未知 | 同类系统在相同量级下的配置，差异原因是什么 |
| "以后肯定需要" | 未来需求不可验证，无法进入本期排序 | 给出触发条件：当 X 达到 Y 时再申请 |
"不给会怎样"必须写成可验证后果，不是感受：
// 可验证 vs 不可验证
不可验证：影响用户体验、系统可能不稳定
可验证：PEAK_DATE 后 P99 延迟 > SLO_TARGET，超时率 > RATE%，
受影响接口 INTERFACE_LIST，影响面为每日约 N 次调用
─── 判据：这个后果能不能在监控上被看到？看不到就不是后果，是担心
补一句代价结构：写清"后果"的同时要写"概率"。只有后果没有概率，等于要求对方为最坏情况全额付费；只有概率没有后果，等于没有请求。两者都给出，对方才有可能选择"接受风险"这条路——而接受风险本身是一个合法决策，前提是它被写下来过。
5. 一次性请求与长期编制：排序权在谁手里
| 类型 | 审批逻辑 | 典型失败模式 |
|---|---|---|
| 一次性（临时扩容、专项机器） | 按项目排期，事后归还 | 到期不归还，变成永久占用 |
| 长期编制（常驻容量、固定人力） | 按年度预算与编制排 | 用一次性名义申请，逐年续期 |
| 借用（跨团队调拨） | 按对方余量，随时可收回 | 关键路径建在别人的余量上 |
临时资源转永久占用，是技术债在资源层面的同形：申请时的理由是一次性峰值，三个月后峰值成了常态，没人回头改申请。所以一次性请求必须同时写归还条件：
// 一次性资源申请：归还条件与到期动作一起写
request:
kind: one_off
spec: "2 x 16C32G"
owner: ROLE_A
return_condition: "PEAK_DATE + 14d 或 QPS < THRESHOLD，先到者为准"
return_action: "缩容至 BASELINE_SPEC"
review: MONTHLY // 未按期归还则在月度会上被点名
排序权的归属比申请话术更决定结果：谁在排、按什么排、你有没有被排进去的资格。跨部门争夺里，你的请求通常不是和"别人的请求"比，而是和"对方的既定额度"比。知道自己被排进哪一档，比把理由写得更长有用。三个问题先问清楚：这一档额度是否已满、满的原因是哪一项占住了、占住它的是不是本年度的刚性项。答案通常会让请求的写法整体改变——不是提高说服力，而是换一个能塞进去的预算项。
6. "用更少的资源做"要自己先打，被拒之后有三条路
在提出请求之前，先给出降级方案。自己不打这张牌，对方就会替你打，而且打得更狠：
| 方案 | 代价 | 什么时候该主动给 |
|---|---|---|
| 缩范围（少做一块功能） | 交付能力下降 | 请求金额或规格明显超标时 |
| 改期（等下一轮预算） | 时间成本、错过窗口 | 时间弹性真实存在时 |
| 降级（限流、排队、异步化） | 部分体验受损 | 峰值是短时的，且可被容忍 |
| 买（外部服务替代） | 持续成本、锁定风险 | 一次性投入高但使用低频时 |
被拒之后，最差的动作是"再交一份更长的材料"。正确的动作是把拒绝变成条件：问清是"额度不够"还是"排序不在这一档"，前者走降级方案，后者走改期或换预算项。
数据能支撑判断，不能替代判断。给出一组数说明"扩容后延迟下降 X%"是支撑；要求对方"看数据自己决定"是替代——后者在跨部门场景里几乎总是失败，因为对方没有你的上下文，数据在他那里不构成判断依据。
// 请求台账：四周之后回看，能看出流程本身的问题
字段：request_id / 提出日 / 决定日 / 结果 / 补材料次数 / 临时是否转正
─── 请求到决定 > 10 个工作日 → 流程问题，不是请求写得不好
─── 一次通过率 < 50% → 四要素缺项普遍存在
─── 补材料 >= 2 次 → 后果不可验证，先改写法
台账的用处不是考核，是把你个人的挫败感变成可比较的流程数据。一个人连着被卡三次，他会认为是自己不会说话；十次请求摊在桌上，通常能看到同一条缺项——比如所有请求都没有给等价替代，于是每次都被砍规格。
排错：请求推不动的五种情形
| 现象 | 根因 | 处理 |
|---|---|---|
| 反复问"到底干什么用" | 没挂到已有系统或项目号 | 改写用途，引用既有系统名 |
| 要求补一份成本测算 | 只给了"要"，没给"省"或"换" | 补等价替代与不做的代价 |
| 说"再看看"然后没有下文 | 没给决策点日期 | 补 T1 决策点与逾期后果 |
| 批了但规格被砍一半 | 未给等价替代 | 提前给 1 台大规格或缩范围方案 |
| 临时资源到期没人提 | 归还条件缺失 | 申请时同时写 return_condition |
边界：这些情况正式申报反而是浪费
| 场景 | 为什么不必走流程 | 做法 |
|---|---|---|
| 资源充裕、额度内自主 | 审批成本高于资源成本 | 按额度直接开，事后记账 |
| 组织极小（几人团队） | 没有跨部门排序问题 | 一句话同步即可 |
| 请求量级低于审批成本 | 走流程本身消耗更多人时 | 合并申报，季度一次 |
| 支出完全按需结算 | 不存在额度分配 | 只需预算提醒，不需申报 |
| 已有长期编制覆盖 | 属于额度内使用 | 记账，不重复申请 |
自测
- 一个请求"提了三周没回音"，先怀疑请求内容还是审批流程？判据是什么？
- 四要素里哪一项缺失会让请求永久排在故障之后？
- 把"资源不够"翻译成风险与时间对应关系时，表里唯一需要标出的是什么？
- "不给会怎样"用什么标准判断写够了？
- 一次性资源为什么会变成永久占用，申请时该同时写什么？
- 被拒之后，"再补一份更长的材料"为什么是错的？