一句话总结
你要在 48 小时内给干系人一份能反应的一页项目计划：里程碑、依赖、风险登记表，以及每个里程碑可测的”完成”标准。AI 擅长结构（枚举里程碑、暴露依赖、起草 RAID 风险登记表），不擅长工作量估算和你的组织真实约束。把目标、截止、团队、已知约束喂给它，用下面的 prompt 拿到里程碑表、明确的关键路径和 Top 5 风险登记表，然后由人重新核估每一个日期。截至 2026 年 6 月，推荐模型：用 Claude Opus 4.7 或 GPT-5.5 的 Thinking 模式推理依赖关系，并把计划存进 Claude Project 或 ChatGPT Project，让上下文贯穿整个项目生命周期。
任务场景
项目要开工，两天内要给干系人看一份能反应的计划。不是甘特图，是一页计划：列里程碑、依赖、风险，以及每个里程碑”完成”长什么样。陷阱是：在会上读起来漂亮，第一次和现实碰就崩。任务是诚实地写范围，不是写漂亮。
哪些地方 AI 帮得上，哪些帮不上
AI 善于结构：枚举里程碑、暴露依赖、列风险类别（技术、组织、市场、监管）。它不懂工作量估算，也不知道你的组织真实约束——谁有空、谁休假、哪个团队欠你人情。所以分工是固定的：AI 起骨架和风险类别，懂团队的人来填每一个日期和工作量估算。
| 步骤 | 由谁做 | 原因 |
|---|---|---|
| 列里程碑和依赖 | AI | 快、全、没有近因偏差 |
| 起草风险登记表的类别 | AI | 把你在压力下会忘的类别都翻出来 |
| 估工作量和日期 | 人（和工程师一起） | AI 不知道谁实际有空 |
| 命名关键路径 | AI 起草，人确认 | AI 排依赖链，你来 sanity check |
| 决定不做什么 | 人 | 这是 AI 替不了你的判断 |
需要给 AI 的输入信息
- 目标：一句话定义”成功”
- 截止日期：硬还是软，原因
- 预算：钱、人数、日历时间
- 团队：角色、资深度、投入比例
- 已知约束：技术、监管、跨团队依赖
- 明确不做的范围
- 过去类似项目：做对的、做错的
输入越单薄，模型越会编出”看着合理但其实错”的日期。如果只能填三栏，先填目标、团队、截止。
Prompt
帮我起一页项目计划，两天后要展示。
目标（一句话）：[line]
截止：[date，硬 / 软]
预算：[钱 / 人 / 日历]
团队：[角色 / 资深度 / 投入]
已知约束：[技术 / 监管 / 跨团队]
明确不做：[列表]
过去类似项目（赢 / 输）：[notes]
请输出：
1. 里程碑（4-7 个），每个含：名字、可测的验收、owner、
截止、依赖
2. 关键路径：最长的依赖链，明确写出来
3. 风险登记表（RAID 式）：Top 5 风险，含概率（低 / 中 / 高）、
影响（低 / 中 / 高）、以及指定的缓解责任人
4. 决策日志：第一周必须拍板的 3 件事，含 owner
5. 成功指标：2-3 个先行 + 1 个滞后，各附定义
6. 沟通节奏：谁听、听啥、多久一次
规则：
- 诚实估时。如果某里程碑不确定性超过 50%，标
[UNCERTAIN: 需要 spike]，不要硬猜日期。
- 里程碑是可观察的结果，不是任务。
- 每个里程碑只有一个 owner。高不确定项目再加一句：在计划里内置一个第 2 周重估点，附明确的 Go / No-Go 标准。
好的输出长什么样
让它输出一页里程碑表——里程碑 / owner / 截止 / 依赖 / 验收 / 完成？——下面是单独的 RAID 风险表、列表式决策日志，沟通节奏写成一段。草稿阶段别用甘特图：形状会盖住你想压力测试的依赖逻辑。
风险登记表是大多数 AI 计划掉链子的地方，所以要明确要 RAID 格式。RAID 指风险（Risks）、假设（Assumptions）、问题（Issues）、依赖（Dependencies，有的团队 D 用 Decisions），是 PMO 级团队的标准项目跟踪产物。每一条都要有 owner，“团队”不算 owner。一份能用的登记表长这样：
| 风险 | 概率 | 影响 | 缓解 | owner |
|---|---|---|---|---|
| 认证厂商 API 中途变更 | 中 | 高 | 锁定 SDK 版本，用适配层隔离 | 后端 lead |
| 设计师 3 月请假两周 | 高 | 中 | 把设计评审提前到 2 月 | PM |
| 数据迁移比预估大 | 中 | 高 | 第一周做一次规模评估 spike | 数据工程 |
假设比风险衰减得快，所以把计划赖以成立的假设标出来，每条加一个重新验证的日期——光这一个习惯，就能抓住大多数悄悄跑偏的计划。
怎么判断 AI 给的结果能不能直接用
- 每个里程碑都有”可测”的验收（“API 部署到 staging，集成测试全过”），不是含糊（“API 准备好”）。
- 关键路径被明确写出来，不是暗示。
- 风险贴你的项目，不是模板套话（“范围蔓延”不算风险；“支付厂商的 PCI 审核要 6 周，不是 2 周”才算）。
- 沟通节奏真实——每日站会 + 周度高管简报，不是 3 个常设周会。
- “不做的范围”没有在需求里又悄悄冒出来。
容易踩的坑
- 没列风险——所有缺风险的计划都是许愿单。
- 里程碑没有验收——“完成”变成扯皮。
- 让 AI 在没有工程师托底的情况下估工作量。
- 把里程碑和任务搞混——里程碑是可观察的结果，不是 to-do。
- 没有决策日志——项目卡在没拍板的事上。
- 里程碑没有 owner 或多人共担——责任稀释。
用哪个 AI 工具（2026 年 6 月）
任何前沿模型都能起草，但差别体现在依赖推理和”计划在 kickoff 之后还活不活”上：
| 工具 | 起计划强在 | 持久化 | 价格（2026 年 6 月） |
|---|---|---|---|
| Claude Opus 4.7（Claude Pro） | 推理依赖链和风险取舍 | Claude Projects：共享指令 + 上传文档，约 20 万 token 知识库 | $20/月（Pro） |
| GPT-5.5 Thinking（ChatGPT Plus） | 结构化表格、快速迭代 | ChatGPT Projects：最多 20 个知识文件，512 MB | $20/月（Plus） |
| Gemini 3.1 Pro（Google AI Pro） | 从长文档里抽取上下文；Workspace 集成 | Gems + 100 万 token 上下文；Google Drive 实时同步 | $19.99/月（AI Pro） |
多数计划工作，用 Claude Opus 4.7 或 GPT-5.5 的 Thinking 模式起草——两者都会认真推理依赖链，而不是急着甩一个列表。然后把计划、约束和动态 RAID 登记表存进 Claude Project 或 ChatGPT Project，让每次重排都从活的上下文开始，而不是从空白对话。如果源材料在 Google Docs 里，Gemini 3.1 Pro 凭 100 万 token 窗口和 Drive 同步可以直接吃进来，不用复制粘贴。
一个关于模型边界的提醒：它们都不知道你的日历。把模型给的每一个日期当成待验证的假设，交给真正干这活的人重新核估。
FAQ
先写 PRD 还是先写项目计划？ PRD 说做什么，项目计划说怎么交付。先写 PRD，再排交付。参考 PRD 草稿。
敏捷还是瀑布，prompt 要变吗？ 迭代和阶段的排法不同，但里程碑、owner、可测的验收对两者都适用。敏捷下把里程碑写成”每个 sprint 末的结果”。
多久重排一次？ 周度软检（假设变了吗？）+ 每个里程碑完成时硬检。RAID 登记表要实时更新，不是等下次开会——一份滞后于现实的登记表比没有还糟。
给了团队名单，AI 能估工作量吗？ 不能。它能给个日期，但它不知道谁实际有空、你的团队交付多快。把它的日期当起点，和负责这块的工程师一起重新核估。
RAID 登记表是什么？ 一份动态记录风险（Risks）、假设（Assumptions）、问题（Issues）、依赖（Dependencies，或 Decisions）的文档。它是 PMO 级团队的标准跟踪记录，完整模板见 Asana 的 RAID log 指南。
相关
- PRD 草稿：计划之前的产品定义
- 写用户故事：把里程碑拆成用户故事
- 功能优先级：决定哪些里程碑进来
- Roadmap 规划 AI：多项目视图
- 上线 Checklist：最后那一个里程碑
- AI 任务拆解教程：把里程碑拆成任务
- 项目规划 Prompt：从目标到 Sprint 计划