任务场景
项目要开工，两天内要给干系人看一份能反应的计划。不是甘特图，是一页计划：列里程碑、依赖、风险，以及每个里程碑”完成”长什么样。风险是：在会上读起来漂亮，但第一次和现实碰就崩。任务是诚实地写范围，不是写漂亮。
哪些情况适合让 AI 来做，哪些情况不要
AI 善于结构：枚举里程碑、暴露依赖、列风险（技术、组织、市场、监管）。但它不懂工作量估算和你的组织真实约束——谁有空、谁休假、哪个团队欠你。先把这些信息插进去，再让它估。
需要给 AI 的输入信息
- 目标——一句话定义”成功”
- 截止日期（硬还是软，原因）
- 预算：钱、人数、日历时间
- 团队：角色、资深度、投入比例
- 已知约束（技术、监管、跨团队依赖）
- 明确不做的范围
- 过去类似项目——做对的 / 做错的
可直接复制的 Prompt
帮我起项目计划，两天后要展示。
目标（一句话）：<line>
截止：<date，硬 / 软>
预算：<钱 / 人 / 日历>
团队：<角色 / 资深度 / 投入>
已知约束：<技术 / 监管 / 跨团队>
明确不做：<列表>
过去类似项目（赢 / 输）：<notes>
请输出：
1. 里程碑（4-7 个），每个含：名字、可测的验收、owner、截止、依赖
2. 关键路径——最长的依赖链
3. 风险登记：Top 5，含概率（低 / 中 / 高）、影响、缓解
4. "可能炸的地方"——最可能的 3 种失败模式
5. 决策日志：第一周要拍板的 3 件事，含 owner
6. 成功指标：2-3 个先行 + 1 个滞后，附定义
7. 沟通节奏：谁听、听啥、多久一次
诚实估时。如果某里程碑不确定性 > 50%，标 [UNCERTAIN: 需要 spike]。高不确定项目：“计划里内置一个第 2 周重估点——明确 Go / No-Go 标准。“
建议让 AI 输出成什么样
一页表：里程碑 / owner / 截止 / 依赖 / 验收 / 完成？。下面是风险登记表、决策日志、沟通节奏一段。草稿阶段不要用甘特图——形状会盖住逻辑。
怎么判断 AI 给的结果能不能直接用
- 每个里程碑都有”可测”的验收（“API 部署到 staging，集成测试全过”），不是含糊（“API 准备好”）
- 关键路径被明确写出来
- 风险贴你的项目，不是模板套话
- 沟通节奏真实——每日站会 + 周度高管简报，不是 3 个周会
- “不做的范围” 没有在需求里又冒出来
容易踩的坑
- 没列风险——所有缺风险的计划都是许愿计划
- 里程碑没有验收——“完成”变成扯皮
- 让 AI 没有信息地估工作量——工程估必须工程师做
- 把里程碑和任务搞混——里程碑是可观察的结果，不是 to-do
- 没有决策日志——项目就卡在没拍板的事上
- 每个里程碑没 owner——责任稀释
实操加深
做「用 AI 起项目计划：里程碑、依赖、风险、验收标准」这类任务时，AI 输出质量主要取决于输入包是否完整。至少给它受众、原始材料、目标格式、你要做的决策，以及一好一坏两个参考。第一轮先要求保留事实，第二轮再优化结构、语气或表达，不要让模型一边猜事实一边润色。
拿到结果后单独做一次复核：有没有遗漏限制、编造细节、行动项不清、语气和真实场景不符。最终稿最好能马上使用，包含明确对象、下一步和判断标准，而不是还需要别人重新解释一遍。
FAQ
- PRD 还是项目计划？ PRD 说做什么，项目计划说怎么交付。PRD 端参考 PRD 草稿。
- 敏捷还是瀑布？ 迭代和阶段排法不同，但里程碑都适用。
- 多久重排？ 周度软检 + 里程碑完成时硬检。
相关
- PRD 草稿 ——计划之前的产品定义
- 写用户故事 ——把里程碑拆成用户故事
- 功能优先级 ——决定哪些里程碑进来
- Roadmap 规划 AI ——多项目视图
- 上线 Checklist ——最后那一个里程碑
- AI 任务拆解教程 ——把里程碑拆成任务
- 项目规划 Prompt：从目标到 Sprint 计划