每个 backlog 都有一个”tech debt”标签，下面挂着 50 张没人动的 ticket。真正的解法不是再开一次梳理会，而是一个打分函数。好的优先级 Prompt 会按影响、工作量、衰减风险给每条债打分，最后只交给你本季度值得投入的 5 件事。下面 12 个模板就是干这个的，而且能干净地对应到 SAFe 里用的 WSJF（Weighted Shortest Job First）经济学。
TL;DR
- 用
(影响 + 时间紧迫度 + 风险) ÷ 工作量给债打分——这就是 WSJF 的换种说法。排序后只投前 5 件。 - 把 DECAY（衰减）和影响分开看：“Compounding”类的债每拖一个月都更贵，所以哪怕今天影响不大也要往前插队。
- AI 打分、人定夺。模型看不到你的招聘计划、客户承诺，也看不到路线图上的欧盟上线——这些要作为上下文喂进去。
- 在 1M token 的模型上跑，让它能读完整个仓库：Claude Opus 4.7 或 Sonnet 4.6（1M 上下文，2026 年 6 月）、Gemini 3.1 Pro（1M）、或 GPT-5.5。要做全仓审查就用 Claude Code 驱动。
- 每季度技术债大约控制在产能的 15-25%；一次投入别超过 5 件，否则一件都做不利索。
适合哪些人
写季度技术债计划的 tech lead、要不要花一个 sprint 做清理的创业者、为重构争取预算的工程师。
怎么对应到 WSJF
经典的 SAFe 公式是 延迟成本 ÷ 工作量，其中延迟成本 = 用户业务价值 + 时间紧迫度 + 风险降低，每项用改良斐波那契刻度（1、2、3、5、8、13、20）打分。这里的模板用同样的结构，只是换成对债务更顺口的叫法：
| WSJF 项 | Prompt 里的叫法 | 它衡量的东西 |
|---|---|---|
| 用户业务价值 | IMPACT | 用户可见的痛 + 拖慢研发速度 |
| 时间紧迫度 | DECAY | 不管它的话成本涨得多快 |
| 风险降低 | IMPACT 里的 risk 维度 | 宕机、安全、合规敞口 |
| 工作量 | EFFORT | 修它要 S / M / L 周 |
如果团队已经在跑 WSJF，就把债和需求放进同一批打分，让两者在同一张表上竞争。如果没有，影响 × 衰减 ÷ 工作量这套更轻，也照样能向管理层讲清楚。规范定义见 SAFe 的 WSJF 文档。
什么时候不建议用这套 Prompt
别拿它去正当化 rewrite——那是另一场对话。也别在没有业务上下文（营收 / 截止 / 招聘）的情况下跑；一个不知道路线图的模型只会去优化代码的”漂亮”，而不是钱。
该在哪个模型上跑（2026 年 6 月）
技术债打分最吃”能不能一次性装下整个代码库”。截至 2026 年 6 月：
| 模型 | 上下文 | 擅长 |
|---|---|---|
| Claude Opus 4.7 | 1M token | 跨模块衰减分析、依赖追踪（SWE-bench Verified 87.6%） |
| Claude Sonnet 4.6 | 1M token | 日常主力——更便宜，同样 1M 上下文 |
| Gemini 3.1 Pro | 1M token | 单条 Prompt 塞最大仓库 |
| GPT-5.5 | 最高 1M（完整窗口需 ChatGPT $200 Pro） | 长时间的 agentic 审查（Terminal-Bench 2.0 82.7%） |
要做交互式的全仓审查，把这些 Prompt 放进 Claude Code 跑（只跑 Anthropic 模型），让模型自己打开文件，而不是靠你粘贴。如果你只要排序、而且条目都已经列好，上面四个里随便哪个在单次对话里都够用。
Prompt 结构公式
每个优先级 Prompt 都要带这六个要素：
- 角色：模型扮演谁（SRE / Release Captain / staff 工程师 / QA Lead）。
- 上下文：技术栈 / 分支 / 失败日志 / diff / dashboard URL，外加路线图事实（招聘、上线、EOL 日期）。
- 目标：一个具体可交付物——排序表、ticket 列表、runbook、或一页计划。
- 限制：模型不能做什么（别自动修、别瞎造文件路径、别建议 rewrite）。
- 输出格式：编号清单、markdown 表格、JSON、或 unified diff。
- 信号：1-2 条”好输出”示例，或一条用来避开的反例。
12 个可直接复制的 Prompt 模板
1. impact × effort × decay 打分
Score each debt item: (a) IMPACT (1-5): user-visible / dev-velocity / risk, (b) EFFORT (S / M / L weeks), (c) DECAY (Stable / Growing / Compounding). Final score = IMPACT × DECAY weight ÷ EFFORT. Output a ranked table. Treat any "Compounding + L effort" specially — those eat the future.2. “为什么是现在”过滤
For each debt item, answer: "What changes in the next 90 days that makes this urgent?" (e.g., hiring 3 backend devs, launching to enterprise, EU rollout, framework EOL). Drop items whose answer is "nothing".3. 相关项打包
Cluster these [nItems] debt items into themes. For each theme: top 1-2 items + bundled cleanup that can ride along. Bundling cuts overhead — but only if items share files / mental model. Don't bundle unrelated items.可替换变量： [nItems]
4. sunset 候选
Identify code / features eligible for sunset: (1) Low usage + high maintenance cost, (2) Replaced internally but never removed, (3) Behind a feature flag that's been on for > 12 months. Output: candidates + a decommission plan.5. 入职摩擦债务
Audit debt that slows new-hire onboarding: (1) Undocumented build steps, (2) Magic env vars, (3) Local dev requires manual seed, (4) "Just ask [person]" knowledge. Prioritise the items that block a new hire in the first week.可替换变量： [person]
6. 速度影响债务
Audit debt that slows weekly velocity: (1) Tests > 10 min, (2) PRs that need 3+ approvals due to ownership ambiguity, (3) Build flake > 5%, (4) Areas of code requiring "specialist" review. Output top 3 + ROI estimate.7. 风险导向债务
Audit debt that creates production risk: (1) Single points of failure, (2) Manual deploy steps, (3) No rollback for X service, (4) Logs missing for critical path, (5) Off-team-owned code blocking incident response. Severity-rank.8. 成本-延迟模型
For 5 candidate debts, estimate cost-of-delay: (a) Pain today (hours / quarter), (b) Pain in 1 year if untouched, (c) Fix cost. Output ROI = (FuturePain - TodayPain) / FixCost. Recommend top 3 to fund this quarter.9. 给管理层看的叙事
Take these 3 prioritized items and write a 200-word narrative for a product / business audience: (1) Each item in plain language, (2) Business consequence if untouched, (3) Engineering investment + outcome, (4) Why now. No jargon.10. 反打包：别把清理塞进 feature PR
Audit the last 10 feature PRs for hidden cleanup. List places where cleanup was bundled, making the PR harder to review. For each: extract the cleanup into a follow-up ticket. Output ticket drafts.11. 债务冻结计划
We can't fix this quarter — design a debt FREEZE plan: (1) Areas we'll stop adding to until cleaned up, (2) Compatibility shims to keep new features off the bad code, (3) Comms to the team. Output a 1-page plan.12. 复盘 → 债务 ticket
Convert this post-mortem into 1-3 debt tickets: title, problem, acceptance criteria, owner, decay class. Don't re-litigate the incident — focus on prevention.一个实例
给模板 1 喂四条真实条目，模型会返回这样一张表。重点是排序揭示了什么，而不是具体分数：
| 条目 | IMPACT | EFFORT | DECAY | 得分 | 结论 |
|---|---|---|---|---|---|
| 认证库落后 2 个大版本（Q4 EOL） | 3 | M | Compounding | 高 | 现在做——衰减把它顶到更显眼的活之上 |
| CI 偶发失败（8% 失败率） | 4 | S | Growing | 高 | 做——又便宜，又在拖累全队 |
| 重写遗留报表模块 | 5 | L | Stable | 低 | 推迟——痛但稳定，本季度不碰 |
| 整理日志格式 | 2 | S | Stable | 低 | 跳过——锦上添花，无衰减 |
报表重写”感觉上”是最大的一件，但 stable + L 工作量把它压了下去。认证升级看起来很无聊，直到 DECAY（一个硬 EOL）把它顶到最前。这种翻转，正是这个 Prompt 的全部价值。
容易踩的坑
- 把声音大当优先级——最不爽的工程师不总是对的。
- 不估工作量——每条看起来都”重要”。
- 没衰减模型——Compounding 类无声却费钱。
- 一季度想做超过 5 件——一件也做不利索。
- 没业务叙事——管理层看不懂的就不会出钱。
- 把债务修复塞进 feature PR——两边都看不清（见重构范围过宽）。
- 换掉的代码不退役——会在仓库里阴魂不散。
优化技巧
- 显式给 DECAY 打分：Stable 可以等，Compounding 不能。
- 每季度最多 5 件，再多就是许愿。
- 相关项可以打包；但 feature 和 cleanup 绝不能进同一个 PR。
- 把成本-延迟模型用钱或工时让管理层看见。
- 每季度重排一次——上下文变得比 backlog 还快。
- 每件指定一个 owner、一个截止时间。
- 优先级顺序：sunset > refactor > 容忍。rewrite 几乎都是好几年的绕路。
FAQ
- 技术债该投多少时间？: 常见是产能的 15-25%，legacy 重的上调、纯新项目下调。要追踪它，否则会悄悄滑到 0%。
- 让 AI 直接定优先级？: 不行——AI 打分、人定夺。模型看不到招聘计划和客户承诺，所以把这些喂进去，并把输出当成一份排序草稿。
- Compounding 是什么意思？: 修晚了显著更贵的债——比如每周都在加宽的 schema、对废弃库越来越深的依赖。它对应 WSJF 里高的时间紧迫度。
- 没即时营收怎么说服管理层？: 用模板 8 的成本-延迟模型，把结果换算成研发工时或风险敞口（如宕机概率），这样管理层才能给它定价。
- 哪个模型能做全仓债务审查？: 截至 2026 年 6 月，任何 1M 上下文的模型——Claude Opus 4.7、Sonnet 4.6 或 Gemini 3.1 Pro——都能装下一个中等规模的仓库。要让模型自己打开文件做 agentic 审查，就用 Claude Code 跑这些 Prompt。
- 什么时候才该 rewrite？: 几乎从不。先试 sunset，再试 refactor。整体 rewrite 通常是好几年的绕路，最后只会用新名字重造一遍同样的债。