Back to Details

rapid-triage-reasoning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Rapid Triage Reasoning (RTR)

快速分诊推理（RTR）

Purpose: Make defensible decisions under extreme time pressure. RTR accepts that perfect is the enemy of good when time is the critical constraint.
目的：在极端时间压力下做出合理可辩护的决策。当时间是关键限制因素时，RTR认同「完美是优秀的敌人」这一理念。

When to Use Rapid Triage Reasoning

何时使用快速分诊推理（RTR）

Use RTR when:
  • Decision needed in minutes, not hours
  • Production incident requiring immediate action
  • Hard deadline with no extension possible
  • Stakes of delay exceed stakes of suboptimal choice
  • "No decision" is worse than "imperfect decision"
Don't use RTR when:
  • You actually have time (even if it feels urgent)
  • Decision is irreversible AND high-stakes (take the time)
  • Problem requires deep analysis (flag for later, make temporary decision)
  • You can buy time by acknowledging the problem
RTR vs Other Patterns:
  • ToT: When you need THE BEST (RTR: when you need SOMETHING GOOD NOW)
  • HE: When you need THE CAUSE (RTR: when you need TO ACT before knowing cause)
  • BoT: When you need ALL OPTIONS (RTR: when you need ONE OPTION FAST)
适用场景：
  • 需在几分钟而非几小时内做出决策
  • 需要立即处理的生产事故
  • 无延期可能的硬性截止日期
  • 延迟决策的风险大于次优选择的风险
  • 「不做决策」比「不完美决策」更糟糕
不适用场景：
  • 你实际上有充足时间（即便感觉很紧急）
  • 决策不可逆且风险极高（请花时间慎重考虑）
  • 问题需要深度分析（标记后延后处理，先做临时决策）
  • 你可以通过告知问题来争取时间
RTR与其他模式对比：
  • ToT：追求最优解时使用（RTR：需要当下做出足够好的决策时使用）
  • HE：需要找到原因时使用（RTR：需要在查明原因前采取行动时使用）
  • BoT：需要列出所有选项时使用（RTR：需要快速选出一个选项时使用）

Core Methodology: RAPID Framework

核心方法论：RAPID框架

R - Recognize Constraints

R - 识别约束条件

Goal: Explicitly acknowledge time pressure and scope limits
Process (30 seconds):
  1. State the hard deadline: "Decision needed by [TIME]"
  2. State consequences of delay: "If we don't decide by then, [CONSEQUENCE]"
  3. State quality floor: "Minimum acceptable outcome is [THRESHOLD]"
  4. Acknowledge what you're sacrificing: "We may miss [OPTIMIZATION]"
Template:
markdown
undefined
目标：明确承认时间压力和范围限制
流程（30秒）：
  1. 明确硬性截止时间：「需在[时间]前做出决策」
  2. 说明延迟的后果：「如果届时未做出决策，将导致[后果]」
  3. 设定质量底线：「最低可接受结果为[阈值]」
  4. 承认需要牺牲的内容：「我们可能会错过[优化项]」
模板：
markdown
undefined

Time Constraint Recognition

时间约束识别

Deadline: [Specific time or duration] Cost of Delay: [What happens if we miss deadline] Quality Floor: [Minimum acceptable outcome] Acceptable Sacrifice: [What we're giving up for speed]

**Example:**
```markdown
截止时间：[具体时间或时长] 延迟成本：「如果错过截止时间会发生什么」 质量底线：「最低可接受结果」 可接受的牺牲：「为了速度我们需要放弃的内容」

**示例：**
```markdown

Time Constraint Recognition

时间约束识别

Deadline: 5 minutes (users experiencing errors NOW) Cost of Delay: Every minute = ~100 failed transactions Quality Floor: Stop the bleeding, even if not root cause fix Acceptable Sacrifice: May need to revisit with proper fix later

---
截止时间：5分钟（用户当前正遭遇错误） 延迟成本：每延迟一分钟约有100笔交易失败 质量底线：先止损，即便不是根本原因修复 可接受的牺牲：后续可能需要重新进行合理修复

---

A - Assess Available Options

A - 评估可用选项

Goal: Generate options you can actually execute in time
Process (1-2 minutes):
  1. List ONLY options executable within deadline
  2. Don't waste time on options that require unavailable resources
  3. Include "do nothing / wait" as explicit option
  4. Include "reversible quick fix" options
  5. Maximum 4 options (cognitive limit under pressure)
Feasibility Filter:
markdown
| Option | Executable in Time? | Reversible? | Keep? |
|--------|---------------------|-------------|-------|
| [Option 1] | Yes/No | Yes/No | Yes/No |
| [Option 2] | Yes/No | Yes/No | Yes/No |
Discard any option where "Executable in Time" = No
Template:
markdown
undefined
目标：生成能在规定时间内实际执行的选项
流程（1-2分钟）：
  1. 仅列出能在截止时间内执行的选项
  2. 不要在需要不可用资源的选项上浪费时间
  3. 将「不采取行动/等待」作为明确选项
  4. 包含「可快速回滚的临时修复」选项
  5. 最多列出4个选项（压力下的认知极限）
可行性筛选表：
markdown
| 选项 | 能否在规定时间内执行？ | 是否可回滚？ | 保留？ |
|--------|---------------------|-------------|-------|
| [选项1] | 是/否 | 是/否 | 是/否 |
| [选项2] | 是/否 | 是/否 | 是/否 |
丢弃所有「能否在规定时间内执行？」为「否」的选项
模板：
markdown
undefined

Viable Options (Max 4)

可行选项（最多4个）

Option 1: [Name]

选项1：[名称]

  • Action: [Specific steps]
  • Time to Execute: [Minutes]
  • Reversible: [Yes/No/Partially]
  • 行动：[具体步骤]
  • 执行时间：[分钟]
  • 可回滚：[是/否/部分可回滚]

Option 2: [Name]

选项2：[名称]

...
...

Option N: Do Nothing / Wait

选项N：不采取行动/等待

  • Action: Accept current state
  • Rationale: [When this is actually correct]

---
  • 行动：接受当前状态
  • 理由：「何时该选择此选项」

---

P - Prioritize by Reversibility

P - 按可回滚性优先排序

Goal: Prefer reversible actions when uncertain
Reversibility Hierarchy:
  1. Fully Reversible (Prefer): Can undo with no lasting effects
  2. Partially Reversible: Can mitigate but not fully undo
  3. Irreversible (Caution): Cannot undo, permanent consequences
Decision Rule:
  • If uncertain AND options have similar outcomes → Choose most reversible
  • If one option clearly better AND irreversible → Still okay if confidence >70%
  • If uncertain AND must choose irreversible → Get second opinion if ANY time remains
Quick Assessment Matrix:
markdown
| Option | Expected Outcome | Confidence | Reversibility | Score |
|--------|------------------|------------|---------------|-------|
| A | [Outcome] | [%] | [1-3] | [Calc] |
| B | [Outcome] | [%] | [1-3] | [Calc] |

Score = Confidence × (Reversibility + 1) / 4
Prefer highest score
目标：不确定时优先选择可回滚的行动
可回滚性层级：
  1. 完全可回滚（优先选择）：可撤销且无持久影响
  2. 部分可回滚：可缓解但无法完全撤销
  3. 不可回滚（谨慎选择）：无法撤销，会产生永久后果
决策规则：
  • 若不确定且选项结果相似 → 选择最易回滚的选项
  • 若某选项明显更优且不可回滚 → 若置信度>70%仍可选择
  • 若不确定且必须选择不可回滚选项 → 只要还有时间就寻求第二意见
快速评估矩阵：
markdown
| 选项 | 预期结果 | 置信度 | 可回滚性 | 得分 |
|--------|------------------|------------|---------------|-------|
| A | [结果] | [%] | [1-3] | [计算值] |
| B | [结果] | [%] | [1-3] | [计算值] |

得分 = 置信度 × (可回滚性 + 1) / 4
优先选择得分最高的选项

I - Implement with Checkpoints

I - 带检查点执行

Goal: Start acting while maintaining ability to course-correct
Process:
  1. Begin executing chosen option IMMEDIATELY
  2. Set checkpoint at 25% and 50% of remaining time
  3. At each checkpoint: Is it working? Continue or pivot?
  4. Document what you're doing (brief notes, not essays)
Checkpoint Template:
markdown
undefined
目标：开始行动的同时保持调整方向的能力
流程：
  1. 立即开始执行选定的选项
  2. 在剩余时间的25%和50%节点设置检查点
  3. 在每个检查点确认：行动是否有效？继续执行还是转向其他选项？
  4. 记录正在执行的内容（简短笔记，无需长篇大论）
检查点模板：
markdown
undefined

Execution Log

执行日志

Started: [Time] Action: [What we're doing]
开始时间：[时间] 行动：[我们正在执行的内容]

Checkpoint 1 (25%): [Time]

检查点1（25%）：[时间]

  • Working? [Yes/Partially/No]
  • Continue? [Yes/Pivot to Option X]
  • 是否有效？[是/部分有效/否]
  • 是否继续？[是/转向选项X]

Checkpoint 2 (50%): [Time]

检查点2（50%）：[时间]

  • Working? [Yes/Partially/No]
  • Continue? [Yes/Pivot to Option X]

**Pivot Rules:**
- Pivot if current action is clearly not working
- Don't pivot just because you thought of something better
- Pivot to next option in priority list, don't re-analyze

---
  • 是否有效？[是/部分有效/否]
  • 是否继续？[是/转向选项X]

**转向规则：**
- 若当前行动明显无效则转向
- 不要只因想到更好的选项就转向
- 转向优先级列表中的下一个选项，无需重新分析

---

D - Document for Follow-up

D - 记录以便后续跟进

Goal: Enable proper analysis after the crisis
Process (do WHILE acting, not after):
  1. Note what you tried and results
  2. Flag items for post-incident review
  3. Capture hypotheses you didn't have time to test
  4. Note any technical debt created
Template:
markdown
undefined
目标：危机过后能进行合理分析
流程（行动时同步进行，而非事后）：
  1. 记录尝试过的行动及结果
  2. 标记需要事后审查的事项
  3. 记录没时间验证的假设
  4. 记录产生的任何技术债务
模板：
markdown
undefined

RTR Decision Record

RTR决策记录

Situation: [1-sentence summary] Time Pressure: [Why urgent] Decision Made: [What we chose] Rationale: [Why, in 1-2 sentences] Outcome: [What happened]
场景：[一句话总结] 时间压力：「为何紧急」 做出的决策：「我们选择的内容」 理由：「1-2句话说明原因」 结果：「发生了什么」

Follow-up Required

后续跟进需求

  • [Investigation or fix needed]
  • [Technical debt to address]
  • [Root cause analysis with HE]

---
  • [需要调查或修复的事项]
  • [需要处理的技术债务]
  • [使用HE进行根本原因分析]

---

Time Budgets by Scenario

不同场景的时间分配

ScenarioTotal TimeRAPID
5-minute incident5 min30s1m30s2.5m30s
15-minute deadline15 min1m3m2m8m1m
30-minute decision30 min2m5m3m18m2m
1-hour critical60 min3m10m7m35m5m
If you have >1 hour, consider if RTR is actually needed
场景总时间RAPID
5分钟事故5分钟30秒1分钟30秒2.5分钟30秒
15分钟截止日期15分钟1分钟3分钟2分钟8分钟1分钟
30分钟决策30分钟2分钟5分钟3分钟18分钟2分钟
1小时关键决策60分钟3分钟10分钟7分钟35分钟5分钟
如果时间超过1小时，请考虑是否真的需要使用RTR

Pre-Built Triage Patterns

预构建的分诊模式

Pattern 1: Production Incident Triage

模式1：生产事故分诊

markdown
undefined
markdown
undefined

Incident Triage (5 minutes)

事故分诊（5分钟）

Immediate Questions (1 min)

即时问题（1分钟）

  1. What's the user impact? [Severity 1-4]
  2. Is it getting worse? [Yes/No/Stable]
  3. When did it start? [Time]
  4. Any recent changes? [Yes/No]
  1. 用户影响如何？[严重程度1-4]
  2. 情况是否在恶化？[是/否/稳定]
  3. 何时开始的？[时间]
  4. 近期是否有变更？[是/否]

Triage Decision Tree (1 min)

分诊决策树（1分钟）

  • Recent deploy? → Rollback first, investigate second
  • External dependency down? → Failover or graceful degradation
  • Resource exhaustion? → Scale up or restart
  • Unknown? → Enable verbose logging, restart if safe
  • 近期有部署？→ 先回滚，再调查
  • 外部依赖故障？→ 切换故障转移或优雅降级
  • 资源耗尽？→ 扩容或重启
  • 原因未知？→ 启用详细日志，若安全则重启

Action (3 min)

行动（3分钟）

[Execute chosen action, monitor]
[执行选定行动，监控]

Document (ongoing)

记录（持续进行）

[Brief notes for postmortem]
undefined
[事后分析的简短笔记]
undefined

Pattern 2: Meeting Decision Triage

模式2：会议决策分诊

markdown
undefined
markdown
undefined

Meeting Decision (2 minutes before deadline)

会议决策（截止日期前2分钟）

Frame (15s)

框架（15秒）

"We need to decide [X] in the next 2 minutes"
「我们需要在接下来2分钟内决定[事项X]」

Options (30s)

选项（30秒）

"Our options are: A, B, or defer to [person/time]"
「我们的选项有：A、B，或推迟至[人员/时间]再决定」

Quick Poll (30s)

快速投票（30秒）

"Any strong objections to [recommended option]?"
「有人强烈反对[推荐选项]吗？」

Decide (15s)

决策（15秒）

"Going with [option]. We can revisit in [timeframe] if needed"
「我们选择[选项]。如有需要可在[时间范围]内重新讨论」

Document (30s)

记录（30秒）

[Note decision, rationale, revisit date]
undefined
「记录决策、理由及重新讨论日期」
undefined

Pattern 3: Technical Triage

模式3：技术分诊

markdown
undefined
markdown
undefined

Technical Decision Under Pressure

压力下的技术决策

Constraint Check (30s)

约束检查（30秒）

  • Time available: [X minutes]
  • Reversibility requirement: [High/Medium/Low]
  • Blast radius if wrong: [Small/Medium/Large]
  • 可用时间：[X分钟]
  • 可回滚性要求：[高/中/低]
  • 错误的影响范围：[小/中/大]

Option Generation (1 min)

选项生成（1分钟）

  • Conservative option: [Safest choice]
  • Aggressive option: [Fastest/best if works]
  • Middle ground: [Balance]
  • 保守选项：[最安全的选择]
  • 激进选项：[如果成功则最快/最优]
  • 折中选项：[平衡方案]

Selection (30s)

选择（30秒）

IF blast radius = Large → Conservative ELSE IF time < 10min → Aggressive (if reversible) ELSE → Middle ground
如果影响范围=大 → 保守选项 否则如果时间<10分钟 → 激进选项（如果可回滚） 否则 → 折中选项

Execute

执行

[Go with selected option]

---
[执行选定选项]

---

Common Mistakes

常见错误

  1. Fake Urgency: Treating everything as urgent
    • Fix: Ask "What happens if I take 30 more minutes?"
    • If answer is "nothing much" → Not RTR territory
  2. Analysis Paralysis Under Pressure: Freezing when time is short
    • Fix: Force yourself to pick within time budget
    • Any decision > No decision (usually)
  3. Skipping Documentation: "I'll remember later"
    • Fix: Document WHILE acting, even if brief
    • Future you will thank present you
  4. Cowboy Decisions: Using time pressure to avoid review
    • Fix: RTR still requires stating rationale
    • "No time to explain" is a red flag
  5. Not Following Up: Making RTR decisions permanent
    • Fix: Always flag for follow-up
    • RTR is triage, not treatment
  1. 虚假紧迫感：将所有事情都视为紧急
    • 解决方法：问自己「如果我多花30分钟会怎样？」
    • 如果答案是「没什么大不了」→ 不属于RTR适用场景
  2. 压力下的分析瘫痪：时间紧迫时陷入停滞
    • 解决方法：强迫自己在时间分配内做出选择
    • 通常来说，任何决策都比不做决策好
  3. 跳过记录：「我之后会记得的」
    • 解决方法：行动时同步记录，即便很简短
    • 未来的你会感谢现在的自己
  4. 鲁莽决策：利用时间压力逃避审查
    • 解决方法：RTR仍需要说明理由
    • 「没时间解释」是危险信号
  5. 不跟进：将RTR决策变为永久决策
    • 解决方法：始终标记需要跟进的事项
    • RTR是分诊，而非最终解决方案

RTR Quality Metrics

RTR质量指标

Unlike other methodologies that optimize for decision QUALITY, RTR optimizes for:
MetricTargetMeasurement
Decision TimeWithin deadlineDid we decide in time?
Quality FloorMet minimum thresholdDid outcome meet minimum?
Reversibility PreferenceChose reversible when uncertainCould we undo if wrong?
Follow-up Rate100% get follow-upDid we revisit the decision?
Regret Rate<20%Would we decide differently with more time?
Acceptable RTR Outcome: Decision made in time, met quality floor, documented for follow-up.
RTR is NOT about making perfect decisions. It's about making good-enough decisions fast enough to matter.
与其他优化决策质量的方法论不同，RTR优化的是：
指标目标衡量方式
决策时间在截止时间内完成是否按时做出决策？
质量底线达到最低阈值结果是否符合最低要求？
可回滚性偏好不确定时选择可回滚选项出错时能否撤销？
跟进率100%进行跟进是否重新审视了决策？
后悔率<20%如果有更多时间，我们会做出不同的决策吗？
可接受的RTR结果：按时做出决策，达到质量底线，已记录以便跟进。
RTR并非追求完美决策，而是做出足够好的决策，且速度快到足以产生影响。

Integration with Other Patterns

与其他模式的集成

RTR as Starting Point:
  • RTR (triage) → HE (root cause after stabilization)
  • RTR (quick fix) → ToT (proper solution design)
  • RTR (incident) → AR (post-incident security review)
RTR Escalation: If during RTR you realize:
  • This is actually not urgent → Exit RTR, use appropriate pattern
  • This requires expertise you lack → Escalate, don't guess
  • The options all look terrible → Document and escalate
RTR作为起点：
  • RTR（分诊）→ HE（稳定后进行根本原因分析）
  • RTR（临时修复）→ ToT（设计合理的解决方案）
  • RTR（事故）→ AR（事后安全审查）
RTR升级： 如果在使用RTR时你发现：
  • 实际上并不紧急 → 退出RTR，使用合适的模式
  • 需要你不具备的专业知识 → 升级上报，不要猜测
  • 所有选项都看起来很糟糕 → 记录并升级上报

Output Template

输出模板

markdown
undefined
markdown
undefined

RTR Decision Record: [Situation]

RTR决策记录：[场景]

Constraints

约束条件

  • Deadline: [When]
  • Cost of Delay: [What]
  • Quality Floor: [Minimum acceptable]
  • 截止时间：[何时]
  • 延迟成本：[会发生什么]
  • 质量底线：[最低可接受标准]

Options Considered

考虑的选项

  1. [Option A] - [Time: Xm, Reversible: Y/N]
  2. [Option B] - [Time: Xm, Reversible: Y/N]
  3. [Option C] - [Time: Xm, Reversible: Y/N]
  1. [选项A] - [时间：X分钟，可回滚：是/否]
  2. [选项B] - [时间：X分钟，可回滚：是/否]
  3. [选项C] - [时间：X分钟，可回滚：是/否]

Decision

决策

Chosen: [Option] Rationale: [1-2 sentences] Confidence: [%] (lower is expected in RTR)
选定：[选项] 理由：[1-2句话] 置信度：[%]（RTR中置信度较低是正常的）

Execution

执行

  • Started: [Time]
  • Checkpoints: [What happened]
  • Outcome: [Result]
  • 开始时间：[时间]
  • 检查点：[发生了什么]
  • 结果：[最终结果]

Follow-up Required

后续跟进需求

  • [Item 1]
  • [Item 2]
  • [事项1]
  • [事项2]

Post-Incident Review

事后审查

[To be completed after crisis passes]

---
[危机过后完成]

---

Version History

版本历史

V1.0 (Current):
  • Initial release
  • RAPID framework (Recognize, Assess, Prioritize, Implement, Document)
  • Pre-built patterns for incidents, meetings, technical decisions
  • Time budgets for different scenarios
  • Integration points with HE, ToT, AR for follow-up
V1.0（当前版本）：
  • 初始发布
  • RAPID框架（Recognize识别、Assess评估、Prioritize优先排序、Implement执行、Document记录）
  • 针对事故、会议、技术决策的预构建模式
  • 不同场景的时间分配
  • 与HE、ToT、AR集成的跟进点