一句话结论
Sprint planning 其实是两件事：决定什么重要（这是你的判断），和在产能上限内把它排好序（这件事机械、容易出错，恰好是大模型擅长的）。把 backlog（用 dev-day 计）、真实产能、一句 sprint 目标、几条 anti-goal 喂给 GPT-5.5 Thinking、Claude Opus 4.7 或 Gemini 3.1 Pro，它会返回一份不超上限的提交清单、一条关键路径、两条 standup 风险、一份周五 demo 脚本。估工和最终拍板还是你来。下面这个 prompt 一步到位；文末的工具表说明什么时候该从聊天窗口切到 Jira Rovo 或 Linear。
任务场景
你在带一个小产品团队。每两周开半天 sprint planning，而这半天里大部分时间并不是在思考——而是在加 dev-day、理清谁挡着谁、再三确认你没又一次悄悄给团队压到 130% 产能。这套算术才是该交给 AI 的部分，半天于是收缩成 20 分钟，你只做真正难的决策。
AI 做不到的：告诉你 export 功能比搜索重构更重要。那是关于你客户的判断，永远是你的。它能稳定做到的：拿你的优先级和你的估算，排出一条尊重依赖、不破产能上限的顺序，再把那两条你本来要到第二周才会发现的风险提前摆出来。
哪些情况适合让 AI 来做
- 你有真正的 backlog（具体条目，不是”以后该做 X”）。
- 你能用 dev-day 而不是 story point 估工。story point 是抽象的速度单位，大模型对具体的”4d”推理远比对”5 个点”靠谱，因为 dev-day 能直接和 dev-day 产能上限相加。
- 最终拍板权在你。AI 提议顺序，你来决定上什么。
需要先给 AI 的信息
- Backlog：10–25 条，每条一行描述 + dev-day 估算。
- Sprint 长度 + dev-day 产能，并且显式算出来，例如
10 工作日 × 3 个 dev = 30 dev-day，扣每人 1 天 review、1 天 on-call = 24 dev-day。 - Sprint 目标：一句话（“稳住搜索，把 export 推到 beta”）。
- 已知依赖（“export 要先做搜索索引重构”）。
- Anti-goal（“不要开始 agentic-eval 重写”）。Anti-goal 差不多占真实 sprint planning 的一半——backlog 告诉 AI 可以做什么，anti-goal 告诉它绝不能做什么。
可直接复制的 Prompt
下面这段在任何前沿聊天模型里都能直接用。要让依赖推理最干净，用思考模式：GPT-5.5 Thinking、Claude Opus 4.7 或 Gemini 3.1 Pro。
你为我排一个 2 周产品 sprint。你不负责估工——只用我给的 dev-day 数字。
你的工作是在产能上限内排序，并把风险摆出来。
目标：稳住搜索，把 export 推到 beta。
Anti-goal：不要开始 agentic-eval 重写。
团队产能：3 个工程师共 24 dev-day。
硬规则：提交清单合计必须 <= 90% 产能（<= 21.6 dev-day），其余留作 buffer。
Backlog（一行 + dev-day 估算）：
1. 搜索索引重构 — 4d
2. Export-to-CSV V1 — 3d
3. Export-to-PDF V1 — 5d（依赖 2）
4. 修搜索 ranking edge case — 2d
5. Export beta flag 接入 — 1d
6. Beta 用户邮件通知 — 0.5d
7. Export schema 迁移脚本 — 2d
8. On-call 培训文档更新 — 1d
9. 两个已知 P1 搜索 bug — 共 1.5d
10. Spike：agentic-eval 重写 scoping — 2d
... [继续粘]
请按以下顺序输出：
1. 关键路径：必须按序完成的链条。
2. 提交清单 + 合计 dev-day（必须 <= 21.6）。
3. "不放这个 sprint"清单，每条一行原因。
4. 明天 standup 要标记的 2 条风险。每条必须点名某一具体条目、以及它滑会断什么。
5. 第二周周五的 demo 脚本：按顺序 3-4 件事。
6. 我中途会忍不住想塞、但必须拒绝的那一条。输出示例
关键路径： 搜索重构 → 迁移脚本 → CSV → beta flag → PDF。
提交的 sprint（24 中用 21.5，buffer 2.5）：
- 搜索索引重构（4d）
- 搜索 ranking edge case（2d）
- 两个 P1 搜索 bug（1.5d）
- Export schema 迁移脚本（2d）
- Export-to-CSV V1（3d）
- Beta flag 接入（1d）
- Beta 邮件通知（0.5d）
- On-call 文档（1d）
- Export-to-PDF V1（5d）
- Buffer / review（1.5d）
不放这个 sprint：
- Agentic-eval 重写 scoping（2d）：按 anti-goal 剔除。
明天 standup 风险：
- Export PDF 依赖 CSV；CSV 滑 1 天，PDF 周五就 demo 不了。
- 搜索重构估 4d；若实际跑到 6d，迁移脚本的位置就没了，CSV 也开始得晚。
周五 demo 脚本：
- 用原来挂掉的 3 条 query 演示搜索 ranking 修复。
- 在 beta-flagged 租户里演示 export-to-CSV。
- 在 staging 走一遍迁移脚本结果。
- （拉伸）演示 PDF export 原型。
会想塞但不许： “把 agentic-eval spike 偷偷加进来”——拒，这正是明写的 anti-goal。
第一版不行时怎么救
模型几乎都能在第一遍给出可用的计划；翻车也是可预测的，每种都有一句话改法贴回去：
| 哪里不对 | 为什么 | 贴回去的修正 |
|---|---|---|
| 提交清单填到约 100% 产能 | 模型太”勤快”，把上限填满 | ”重做。提交清单必须 <= 90% 产能，并显示 buffer 行。“ |
| 漏依赖（PDF 排在 CSV 前） | 它按 dev-day 装箱优化，没顾顺序 | ”在提交清单之前先把关键路径列成有序链条。“ |
| 风险太泛（“scope 可能涨”） | 没有落地要求 | ”每条风险必须点名一个具体 backlog 条目、以及它滑会断什么。“ |
| 没 demo，或拿半成品当 demo | 它把 demo 当可选项 | ”每个 demo 项都得是 stakeholder 能从头看到尾跑起来的东西。没有合格的，就说明计划排错了——重新排。“ |
| 它重新估了你的条目 | 你留了口子 | prompt 里的”你不负责估工”那句别删，它是承重的。 |
跨团队依赖
某条要等别的团队时，别让 AI 猜日期。把对方承诺的日期写进 dependencies 那行：Export schema 迁移 — 卡在 Platform 团队上线新列之前（承诺第一周周四）。模型就会绕着这个固定点排你团队的活，而不是凭空塞一个看着合理其实不对的位置。如果对方还没承诺日期，这条这个 sprint 就不可计划——把它标成风险，而不是提交项。
聊天窗口 vs. 自带这功能的工具
聊天 prompt 最快、且不花订阅之外的钱。当 backlog 已经在 issue tracker 里、重新打一遍才是瓶颈时，再换专门工具。截至 2026 年 6 月：
| 方案 | 对排期能做什么 | 价格（个人 / 每席） |
|---|---|---|
| 聊天模型（GPT-5.5 Thinking / Claude Opus 4.7 / Gemini 3.1 Pro） | 你粘 backlog，完全掌控上面那个 prompt。排序 + 风险 + demo 这件事它最合适。 | ChatGPT Plus $20/月 · Claude Pro $20/月（年付 $17）· Google AI Pro $19.99/月 |
| Jira + Rovo（Atlassian Intelligence） | 起草 user story 和验收标准，“Readiness Checker” 代理标记缺字段的 backlog 条目，Rovo 写面向 stakeholder 的 sprint 总结。AI 已打包进付费 Jira；Premium 含每席每月 70 个 Rovo credit。 | Jira Premium 约 $15.63/席/月（含 AI） |
| Linear（Agent + Triage Intelligence） | 建 issue 时做语义查重、AI 路由 triage、自动生成可直接转给 stakeholder 的每周项目总结。AI 代理每个套餐都有；Triage Intelligence + Insights 需 Business。 | Free $0（Agent beta）· Business $16/席/月（年付） |
表格来源：Atlassian — Rovo in Jira、Linear 价格页。
实话实说：Rovo 和 Linear 擅长的是排期周边的写作和卫生工作（起草工单、抓缺字段、给 stakeholder 写总结），都还替代不了”在上限内排序”这层判断——这层活上面那个聊天 prompt 仍然更强，因为产能规则和 anti-goal 都由你掌控。
容易踩的坑
- 让 AI”排优先级”却不给 anti-goal。 没有它，模型就一味追求吞吐，乐呵呵地把你叮嘱团队别碰的那件事排进去。
- 让 AI 估工。 估算里编码了只有你团队才有的上下文。AI 排你给的东西，不该凭空造 dev-day。
- 把产能填满 100%。 排到顶的 sprint，只要有一件比预估难，就会 overrun。90% 规则就是那点 buffer。
- 交一个没 demo 的 sprint。 周五要是没有任何东西能演示，你下一份计划就没有可信度。
FAQ
- 该用哪个模型？ 任何前沿模型的思考模式都能扛。难点在多步依赖推理，GPT-5.5 Thinking、Claude Opus 4.7、Gemini 3.1 Pro 都做得不错。用你已经付费的那个就行，prompt 完全一样。
- 我们团队用 story point 不用 dev-day，怎么办？ 只为这个 prompt 临时换成 dev-day（一个粗略的”每点几小时”系数就够），拿到提交清单再换回 point 回填看板。大模型对 dev-day 推理好得多，因为它能直接和产能相加。
- AI 能开 standup 吗？ 不能，但它能把 standup 笔记变成一份”burnup vs plan”的 delta——哪些超前、哪些落后、哪些现在有风险。那是另一个每日 prompt，不属于 sprint planning。
- 现在 Jira 或 Linear 是不是已经自动做这件事了？ 部分做了。截至 2026 年 6 月，Jira Rovo 和 Linear 能起草工单、标记不完整的 backlog 条目、给 stakeholder 总结 sprint，但都还不会替你提交一份”受产能约束、按依赖排序”的计划。它们管卫生工作；排序这一拍仍然走上面那种 prompt。
- 它报的 dev-day 合计能信几分？ 自己核一遍算术——模型偶尔会把一列数加错。提交前，这个合计是你唯一该亲手重加的数。