用 ChatGPT 拆解项目任务，先写清最终交付物、截止时间、可投入工时与必须等待的确认，再要求每项任务包含完成标准。拿到清单后，把工时相加并检查前后依赖；“看起来安排满了”不代表计划可执行。
本文用一场小型读书交流活动的准备工作作演示。需求、工时与参考清单均为本站自拟教学材料，不是实际项目记录或模型实测；估时只是该例的计划假设，需要根据你的熟练程度重新评估。
把“准备一场活动”改成明确交付物
本例目标是周五18:00前交付可供负责人审核的活动材料包，包括一页通知、一个不收集真实数据的报名表草稿和一份60分钟流程。活动日期、地点、名额及报名字段需要负责人确认。完成材料包不等于已经获批，也不包含实际对外发布和现场执行。
执行人周三、周四、周五每天各能投入2小时，总计6小时。负责人只负责确认活动条件并审核材料；他的等待时间不计入执行人的工作工时，但可能影响材料完成的日历时间。不能因为“我只需做30分钟”就假定当天一定能等到回复。
把这些边界交给 ChatGPT，可以减少它擅自新增海报制作、采购或现场布置等任务。若这些工作确实有必要，应列入范围变更，并重新估时，不应悄悄塞进原来的6小时。
给任务清单规定五个字段
要求按“任务—依赖—预计工时—交付物—验收标准”输出。任务应具体到可以检查是否完成，例如“完成通知草稿并标记待确认字段”，比“做好宣传”更可操作。
验收标准应描述可观察结果。本例通知需要包含时间、地点、对象、名额和报名方式；缺失项明确标为待确认，不能用想象的内容填满。报名表只是供审核的样稿，用虚构输入检查字段和提示，不提前开放真实报名。
一份可以逐项核对的参考清单
T1｜需求核对，30分钟。无前置依赖；交付一份问题清单，列出活动时间、地点、名额、报名字段与确认负责人。验收要求是所有未知项都能被识别，不能把发出问题当作已经得到确认。
T2｜通知草稿，60分钟。依赖T1梳理的范围；交付一页草稿，对未确认信息保留占位。验收要求是信息项齐全、文字一致，并标出需要负责人确认的位置。
T3｜报名表草稿，45分钟。依赖T1明确报名目的；交付字段清单及样稿，用虚构信息演示正常填写和漏填提示。哪些个人信息确有必要尚未确认时，只列待讨论字段，不收集真实信息。
T4｜活动流程，60分钟。依赖T1的活动目标；交付60分钟流程：开场5分钟、两轮交流各20分钟、讨论10分钟、结束5分钟。验收时核对5+20+20+10+5=60，并说明流程需要负责人审核。
T5｜交叉核对与修改，75分钟。依赖T2、T3、T4草稿；逐项核对通知、表单和流程的时间、名称与报名要求，形成修改记录。如果负责人尚未确认条件，交付待确认清单，不能标记为可对外发布。
T6｜整理交付，30分钟。依赖T5；交付文件目录、版本说明及剩余问题。验收要求是负责人能找到对应版本，明确哪些内容可以审、哪些仍待定。
这些任务合计30+60+45+60+75+30=300分钟，即5小时。余下60分钟作为修改缓冲；它已包含在6小时总预算内，不能另外再承诺6小时工作加1小时缓冲。
把任务放回真实可用的时间里
参考排法是：周三做T1、T2和T3的前30分钟，合计120分钟；周四完成T3剩余15分钟、T4的60分钟和T5前45分钟，合计120分钟；周五完成T5剩余30分钟与T6的30分钟，另留60分钟缓冲，总共120分钟。
把任务分到两天时要保留工作中间状态，不能把“开始核对”写成“核对完成”。T5只能在三份草稿齐备后开始；T6只能在核对后整理。这个案例由一人执行，同一时段不能安排两项都需要本人处理的任务。
如果负责人到周五仍未回复，计划的合格交付可以是“供审核材料包及待确认事项”，因为它符合最初范围；但不能承诺活动已经可以发布。若要求改成“周五前完成正式发布”，应先确认审批时间、权限和未决条件，再修改计划。
工时不够时怎么追问
不要只说“再压缩一点”。应告诉它剩余时长、必须完成的交付物和允许推迟的内容，要求说明删减后影响什么。例如只有3小时，就保留需求核对与通知草稿，其他交付物是否顺延需重新约定；不能单纯把每项预计时间砍半。
如果生成的清单忘记核对、修改或交付，可追问“这份计划有哪些返工与等待环节没有安排？”如果它为未知条件填了具体数字，应要求恢复为待确认项，列出需要向谁询问的问题。
开始执行前做最后四项检查
第一，所有任务都服务于约定交付物，没有凭空扩大范围。第二，工作工时与等待时间分开，逐日时长没有超过可用时间。第三，前置任务完成后才能开始依赖它的工作。第四，每项都有可核对的完成标准，尚未审批的内容不能标为已获批。
任务清单需要随着实际进度调整。每天记录完成了什么、剩余多少、出现了哪些新限制，再把变化交给 ChatGPT 重新安排；保留旧版本，检查新计划是否只是隐藏了延误。下方模板适合整理计划，最终承诺和对外发布仍由实际负责人决定。