评审会上没人反对，进度表排得整整齐齐，第三周却卡住了：三个模块都在等对方先交接口，谁也没法动。项目管理的失败很少发生在执行阶段，多数在拆解和排序的时候就埋下了。AI 能把这两件事的初稿做得很快，但它不知道你团队的真实产能，也不知道谁下周要休假。下面按五步讲清这条链路，以及哪几个判断只能自己下。
拆不到可验收，排期就是猜
工作分解结构（WBS）的要求只有一条：末级任务能被单独指派、单独验收。做不到这一条，后面的排期、进度、责任全都悬空。「开发用户反馈系统」是一个项目，不是任务；「完成反馈表单前端页面，含提交与校验，通过验收用例一到五」才是任务。
拆解时有两个动作能明显提高质量。一是用动词开头，让每个任务对应一个可交付的动作；二是给每个末级任务标一个估算单位——人天、故事点，或者「半天以内、一到三天、三天以上」这种粗粒度区间。粗粒度估算看着不专业，实际比精确到小时的数字更可靠，因为它不假装自己知道。
五步走完，从目标到复盘
五步的产出物不一样，漏掉哪一步，后一步都会加倍费劲：
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 目标与验收 | 一句话目标，加三条验收条件 | 目标写成「提升体验」，没法验收 |
| 工作分解 | 三级 WBS，末级任务含角色与工时区间 | 拆到「开发」就停，无法指派 |
| 排期草案 | 依赖关系、关键路径、缓冲时间 | 把 AI 给的日期当承诺，忽略评审与联调 |
| 风险清单 | 按影响排序的表，每条含触发信号、应对动作、责任人 | 只列风险不落人，清单越长越没人看 |
| 周会与偏差修正 | 每周更新的偏差表，加一到两处调整 | 只报完成百分比，不报阻塞 |
第三步最容易出事。AI 给的排期是一张没有摩擦的图：任务首尾相接，没有人等评审，没有环境搭建，没有联调。把它当承诺发出去，第一次延期就会摧毁整张表的可信度。正确用法是当草稿，自己往里加缓冲、加依赖、加假期。
它给的排期为什么总是偏乐观
三个原因。它不知道你的产能：五个人不等于五个人的工时，会议、支持、临时插入的需求都要占掉一部分。它不知道等待：代码评审要等、测试环境要等、外部接口要等，这些时间在任务表上不显示，却真实存在。它学的是「一般项目」，而公开叙述里的项目本来就偏向顺利。
校准的办法不复杂。把过去两三个项目的计划工时和实际工时摆在一起，算出你们团队的偏差系数，再用它去乘 AI 给的估算。这个系数通常大于一，具体多少因团队而异，但只要有，就比没有强。
风险清单的价值在那几条你没想到的
让 AI 列风险，它会给出一份很全的清单：需求变更、人员流动、技术选型、第三方依赖。这份清单的用法是扫一遍，挑出「我确实没想到」的那两三条。剩下的通用项，你本来就知道。
每条风险要落到三个字段才有用：触发信号，什么现象出现说明它正在发生；影响程度，延期多久、影响哪个里程碑；应对动作，本周能做的一件具体事。再加一个责任人。没有责任人的条目，三个月后还在原地。
还可以让它换个立场再列一遍。「假设你是挑剔的投资人，指出这个方案最致命的三个问题」「从运维角度看，上线后最可能出什么事」——换角色比换措辞有效，因为不同角色关注的是不同的失效模式。
谁做什么、砍掉什么，它替不了你
AI 能算出任务之间的依赖，算不出张工和李工谁更适合带这块；能列出十个风险，不能决定为了赶工期先放弃哪一个；能给出三种排期方案，不能替你跟业务方谈延期。这些判断涉及人、资源和部门之间的博弈，输入根本不在它的上下文里。
边界因此很清楚：它产出的是决策的输入，决策和责任留在你这边。把它的输出直接转发给上级，等于把判断也一起交出去了。反过来，用它把选项铺开、把每种选择的代价写清楚，再自己拍板，这是它最合适的位置。想让流转自动化，可以看智能体在固定流程里的用法，但自动化的是流转，不是取舍。
喂进去的背景，决定它答得多准
同一个拆解请求，只给一句「帮我把这个项目拆成任务」，得到的是通用模板；把团队规模、技术栈、已有系统、外部依赖、历史延期原因一并说清，得到的东西才能直接用。这属于信息量的问题，不是措辞的技巧。上下文能放多少、怎么放，上下文窗口的容量与用法里有更细的说明。
写请求时把约束写在前面：两个月、四个人、不能改动的老系统、必须复用的登录模块。约束越具体，它给的方案越少空话。这类写法的通用规则，提示词里该放哪些约束可以对照着看。
有一条要自己守住：客户名单、财务数据、未公开的排期，不要往公开工具里贴。信息一旦离开你的环境，就收不回来了。
速查：AI 辅助项目管理的五条
- 拆解只认一个标准：末级任务能不能单独指派和验收
- 排期当草稿，缓冲、依赖、假期自己加
- 用历史项目的实际工时算出偏差系数，再去乘估算
- 每条风险都要有触发信号、应对动作、责任人
- 砍需求、分人、谈延期，自己拍板
