任务场景
你在带一个小产品团队。每两周开半天 sprint planning。让 AI 排序——风险、依赖、demo——把半天留给真正难的决策。
哪些情况适合让 AI 来做
- 你有真正的 backlog（不是”以后该做 X”）。
- 你能给 AI dev-day 单位的产能（AI 对”story point”这种任意单位不靠谱）。
- 最终决策权在你——AI 提议顺序，你来 commit。
需要先给 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 重写”）
可直接复制的 Prompt
你为我排一个 2 周 sprint。
目标：稳搜索 + export 上线 beta。
Anti-goal：不开始 agentic-eval 重写。
产能：3 个工程师共 24 dev-day。
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. 提交的 sprint list（合计 dev-day ≤ 产能）。
2. "不放这个 sprint"清单 + 原因。
3. 关键路径（必须有序的链）。
4. 明天 standup 要标记的 2 个风险。
5. 周二的 Friday demo 脚本：按顺序 3-4 件事。
6. 我中途会忍不住想塞但必须拒绝的那条。输出示例
提交的 sprint（24 dev-day，用 22.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（2.5d）
不放这个 sprint：
- Agentic-eval 重写 scoping（2d）：按 anti-goal 剔。
关键路径： 搜索重构 → 迁移脚本 → CSV → beta flag → PDF。
明天 standup 风险：
- Export PDF 依赖 CSV；CSV 滑 1 天，PDF 周五 demo 不了。
- 搜索重构估 4d；如果实际 6d，迁移脚本要被挤掉。
周五 demo 脚本：
- 演示搜索 ranking 修复（3 条原来挂掉的 query）。
- 在 beta-flagged 租户里演示 export CSV。
- staging 里走一遍迁移脚本结果。
- （拉伸）PDF export 原型。
会想塞但不许： “把 agentic-eval spike 偷偷加进来”——按 anti-goal 拒。
怎么改输出
- AI 过载产能——硬规则：“提交清单 ≤ 90% 产能，留 buffer”。
- 漏依赖——要求”先列关键路径再列提交清单”。
- 风险太泛——要求”每条风险点名具体一项 + 它滑会断什么”。
- 没 demo 脚本——重申：“Friday demo 不可缺；没东西 demo = sprint 失败”。
容易踩的坑
- 让 AI “排优先级”没 anti-goal——anti-goal 占 sprint planning 一半。
- 让 AI 估工——估工是你的事，AI 只排你给的东西。
- 把产能填满 100%——一定 overrun。
- 没 demo——没 demo 的 sprint 让下一次 plan 失去信任。
实操加深
做「用 AI 做版本迭代规划：2 周 sprint 不开半天会」这类任务时，AI 输出质量主要取决于输入包是否完整。至少给它受众、原始材料、目标格式、你要做的决策，以及一好一坏两个参考。第一轮先要求保留事实，第二轮再优化结构、语气或表达，不要让模型一边猜事实一边润色。
拿到结果后单独做一次复核：有没有遗漏限制、编造细节、行动项不清、语气和真实场景不符。最终稿最好能马上使用，包含明确对象、下一步和判断标准，而不是还需要别人重新解释一遍。 A stronger version of this workflow also defines the handoff. Decide who will use the output, what they should do next, and what information would make them reject it. If the deliverable is copy, test whether it has a single clear action. If it is analysis, test whether it separates observation from recommendation. If it is planning, test whether dates, owners, and tradeoffs are explicit enough for someone else to execute. One final check: compare the finished result against the original goal in a single sentence. If that sentence is hard to write, the output is probably polished but unfocused. Tighten the goal, remove decorative language, and rerun only the weak section instead of regenerating the entire piece. 最后再用一句话核对成品是否回应了最初目标：谁会用它、要采取什么行动、成功标准是什么。如果这句话写不清楚，说明内容只是变长了，还没有真正变准。优先补目标、边界和验收标准，再局部重跑薄弱段落。
FAQ
- 我们用 story point 怎么办？ Prompt 里临时翻成 dev-day，内部再换回。
- 跨团队依赖怎么写？ 把对方承诺的日期写进 dependencies；AI 会绕开。
- AI 能开 standup 吗？ 不能——但它能把 standup 笔记总结成”burnup vs plan delta”。另一个 Prompt。