重要 ≠ 紧急——把 flag 和 priority 分开用
多数团队里 flag 和 priority 是同一套标签，这是错的——flag 是"重要"，priority 是"紧急"，两 个独立维度混着用，最后没人再信这些标签。
- 概念正交：flag 标注价值，priority 标注时间压力，本质两个独立维度
- 艾森豪威尔矩阵：4 象限，重要 × 紧急的二维划分，对应 4 种处理方式
- Covey 第二象限：重要但不紧急才是真正该花时间的区域
- 常见误判：把领导催当成紧急，把上线崩溃当成不重要
- GTD 执行维度：情境、时间、精力、优先级四维决策当下动作，不是只看 priority
- 工程实践：GitHub 一个 priority label 不够，重要 vs 紧急必须分开建
- 反模式：所有 bug 都标 P0、所有任务都标 important，标签沦为装饰
- 结论：分得开重要和紧急，才知道当下到底该做什么
一句话先说
flag 标注"重要性"，priority 标注"紧急程度"，两者正交，混用就是混乱的开始。
这不是咬文嚼字。任何带任务流转的系统——看板、Issue 列表、个人 TODO——只要把这两个维度压成一套标签，迟早都会出现"所有东西都是 P0""所有人都说很重要"。
结果就是系统失语，谁也不信这些标签。
剩下的文章讲清楚三件事：为什么必须分开、用经典理论验证、怎么在工程实践里落地。
多数团队的现状：flag 和 priority 混着标
打开任何一个团队的 Issue 列表，大概都是这种场景：
- 一个 bug：「登录失败」标 P0（最高优先级）
- 一个新需求：「支持深色模式」也标 P0
- 一个会议邀请：「下周三 kickoff」还是标 P0
- 一个技术债：「重构日志模块」继续标 P0
所有人都在抢优先级，所有人也都知道——P0 越多，P0 就越没有意义。
根因就是 flag 和 priority 共用一套标签：
| 维度 | 回答的问题 | 误用后会变成什么 |
|---|---|---|
| flag（重要） | 这件事对长期目标有没有价值？ | 一切都被说成"重要" |
| priority（紧急） | 这件事现在必须做吗？ | 一切都被说成"紧急" |
这两个问题经常被一起讨论，但答案不绑定。一个重构可能让系统 6 个月后少出 30% 的事故（重要，但不紧急）；一个客诉必须今天回复客户（紧急，但不重要）。
很多团队以为自己在排 priority，其实是在排"谁喊得最响"。
艾森豪威尔矩阵：把这两个维度拆开
经典答案来自 Dwight Eisenhower——美国二战时期的盟军最高统帅，后来当了总统。他有句经常被引用的话：
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.
我有两类问题，紧急的和重要的。紧急的往往不重要，重要的往往不紧急。
后人把它画成了艾森豪威尔矩阵（Eisenhower Matrix），也叫四象限法：
四个象限的处理方式完全不同：
| 象限 | 典型场景 |
|---|---|
| 危机区 | 线上崩溃、合同到期、客户流失——必须立即亲自处理，没有任何缓冲时间 |
| 核心区 | 架构优化、能力建设、健康管理、长期能力投资——价值最高但最容易因为不紧急而被无限推迟。这才是真正该花时间的区域。 |
| 分心区 | 不重要的会议、别人催的事、可有可无的协作请求——制造忙碌的假象，最容易吃掉 "核心区" 的时间。原则：能委托就委托，能拒绝就拒绝。 |
| 浪费区 | 刷短视频、闲聊、消遣性淘宝、无目的刷信息流——纯粹的精力消耗，无法产生任何长期价值。最干净的处理方式是从源头删除（屏蔽、退订、关闭通知）。 |
几乎所有时间管理书籍的核心都指向同一句话：
真正的护城河在 "核心区"，因为 "危机区" 都是 "核心区" 没做好的结果。
一个系统出事故，是因为 "核心区" 的监控和容灾没做。一个员工亚健康，是因为 "核心区" 的锻炼和休息没做。
Covey 的真正洞察：第二象限才是命门
Stephen Covey 在 《高效能人士的七个习惯（The 7 Habits of Highly Effective People）》 里把这个矩阵继承了下来，并给了它一个明确的优先级排序：
习惯三：要事第一（First Things First）
真正的优先级不是 "危机区"，是 "核心区"。
Covey 用"日程表"和"使命"做了个隐喻：
- 按"日程表"过一天：处理一切找上门的事，"危机区" 越来越多，"核心区" 越来越少
- 按"使命"过日子：主动把时间投到 "核心区"，"危机区" 反而越来越少
多数人"忙"恰恰是因为 "核心区" 荒废了——拿几个常见场景对号入座：
- 健身卡办了不去 → 体检出问题 → 请假看病 → 项目延期 → 救火加班
- 系统没监控 → 服务挂了 → 半夜被叫醒 → 黑着眼圈开会 → 关键决策失误
- 技术债不还 → 每改一个 bug 都心惊胆战 → 每次上线都是豪赌 → 团队士气崩
每一个 "危机区" 的崩塌，背后都是 "核心区" 缺失了 6 个月。
Covey 把习惯三命名为"要事第一"而不是"急事第一"，原因就在这里——要事不一定是急事，但它是真正决定长期结果的事。
GTD 的启示：执行靠 4 个标准，不是 1 个
David Allen 在 Getting Things Done 里提供了一个更冷静的执行视角：
当事情已经分类好（决定哪件事在哪个清单），决定当下做哪一件的标准不是 priority 一个维度，是 4 个：
- 情境（Context）：在哪？手头有什么工具？会议室 vs 工位决定能做的事不同
- 时间：有多少时间？10 分钟等电梯 vs 2 小时大块时间，候选不一样
- 精力：精力充沛还是疲惫？疲劳时别碰高难度决策
- 优先级：重要 + 紧急各占多少——最后才轮到这一票
Allen 的潜台词是：如果只看 priority，会把最疲劳的时间用来做最重要的事——这是失败组合。
很多团队实践 GTD 或类似系统时栽跟头，就是因为把"决策当下做什么"和"事情本身的优先级"混淆。前者需要 4 维状态信息，后者只需 2 维（重要、紧急）。
工程实践也是这个道理：在 GitHub 上看到 100 个 open issue，不是按 priority 排序就解决一切——还要看现在能不能联网（在不在工位）、能不能集中精力（是不是开完一天的会）、手头有没有这台机器的环境（情境）。
优先级告诉系统"什么事更重要"，执行标准告诉人"现在能做什么"。
工程实践：怎么把 flag 和 priority 真正分开
理论说完了，落地才是难题。GitHub Issues 和 Linear 上见过最常见的两种反模式：
反模式 A：只有 priority，没有 flag
GitHub 默认只有 priority 标签（P0/P1/P2）。结果：
- 重构（很重要但不紧急）和线上崩溃（紧急且重要）被标成一样的 P0
- 没人能 在 backlog 里区分"哪些东西出 bug 一定要修" vs "哪些东西长期不做系统会崩"
反模式 B：有 flag 也有 priority，但 flag 没人填
Linear、Jira 这类工具支持两个维度，但很多团队默认 flag 可选，于是所有事项只填 priority，没 flag——又退回到了 A。
落地关键是强制 + 工具结构：
- priority 严格区分：用 P0/P1/P2/P3 + SLA（响应时间要求），这一列直接驱动告警和 oncall 排班
- flag 独立标签：用布尔值或
area:critical-path/area:tech-debt这类语义化标签，让 reviewer 强制选 - PR 模板加一行：「这个 PR 涉及哪类区域？critical-path / feature / tech-debt / chore」——强制分类
- 定期审视 flag 而非 priority：每周 sprint review 单独扫一遍"flagged 为 critical 但本 sprint 没动"的事项，这才是系统健康度的真实信号
MoSCoW 法则（Must / Should / Could / Won't）也是一种 flag 维度的实践，比 priority 更精细——它强制思考"不做会怎样"，而不是"什么时候做"。
反模式：标签通胀，最后没人信
最后说大家最容易栽进去的反模式——标签通胀（Label Inflation）。
发生路径：
- 团队引入 P0/P1/P2 标签
- 第一个月真有事标 P0，大家都重视
- 越来越多"重要的事"被标成 P0，因为它们"也很重要"
- 三个月后打开看板，全是 P0，每个 P0 都没人响应
- 真正事故发生时，oncall 怀疑——"这是不是又是那种 P0？"
- 灾难发生
有标签不可怕，怕的是标签没有"刻度"。 P0 的代价是什么？P1 是不是同一个意思？这些问题没共识，标签就是噪音。
最简的防通胀方法是给 priority 配 SLA：
| 优先级 | SLA（首次响应） | SLA（解决） |
|---|---|---|
| P0 | 15 分钟 | 4 小时 |
| P1 | 1 小时 | 24 小时 |
| P2 | 1 个工作日 | 1 周 |
| P3 | 下一个 sprint | 不承诺 |
有了 SLA，"什么是 P0"就不再是讨论题——是算术题：4 小时能解决的事才有资格叫 P0。
一句话原则
flag 决定"这件事不做会怎样"；priority 决定"这件事什么时候必须做完"。
把这两个维度分开建、分开看、分开评，标签才有信息量；混着用，标签就是噪音。
Covey 说得最狠也最准确— —"重要而紧急"的事之所以越来越多，是因为"重要而不紧急"的事做得越来越少。这不是鸡汤，是数学——欠 "核心区" 的债，"危机区" 一定连本带利收回。
References
- Stephen R. Covey. The 7 Habits of Highly Effective People —— 1989，高效能人士的七个习惯，习惯三"要事第一"
- David Allen. Getting Things Done —— 2001，GTD 原始著作，四维执行模型
- Eisenhower Matrix —— 重要与紧急二维划分的最初提出者
- MoSCoW method —— 优先级标记的工程实践，区分 Must / Should / Could / Won't