如何用 AI 制定项目计划：依赖、估时与负责人逐项核实

要用 AI 制定项目计划，应从已批准的项目说明开始，而不是给模型一个空白问题。让 AI 把既定结果拆成交付物、里程碑、依赖、负责人、风险和开放假设；在计划成为基准版本前，再由真正负责工作的人逐条确认依赖与估时。

AI 擅长整理零散笔记、发现缺失字段和提出不同结构，但除非获授权的人提供并核实，它不会知道团队实际产能、审批队列、供应商周期或隐藏技术约束。PMI 的规划指南把使命、范围、利益相关方、资源、里程碑与风险视为连贯计划的重要组成。［1］ NIST 也提醒，生成式系统可能自信地输出错误或不一致内容。［2］ 因此，看似合理的排期只能先作为假设。

关键要点

• 从获批项目说明中的结果、范围、约束和决策负责人开始。
• 先拆可验收交付物，再列活动和任务。
• 把依赖写成可确认的陈述，并指定确认人。
• AI 生成的工期、人员和顺序必须进入假设登记表。
• 每个交付物只有一个最终负责人，并有明确验收标准。
• 在确定基准版本前定义范围、排期和资源变更如何审批。

通用的带人工复核的 AI 工作流仍然适用。本文聚焦一个更具体的交付物：让不确定性足够可见、团队能真正挑战的项目计划。

交给 AI 的项目说明应包含什么？

计划无法弥补含糊的授权。提示前，准备一份一到两页的项目说明，包含以下字段：

• **问题和期望结果：**项目结束时，什么状况应该有所不同？
• **发起人和决策负责人：**谁能批准基准版本和各种取舍？
• **范围内：**包含的产品、团队、市场、系统或流程。
• **范围外：**明确排除的、容易顺手做进去的相邻工作。
• **约束：**固定日期、预算上限、政策、技术、合同和质量门槛。
• **已知干系人：**贡献者、审批人、受影响的用户、运营人员和外部各方。
• **证据：**已批准的研究、会议决定、估算和现有承诺。
• **未知项：**必须保持开放、而不是靠猜测填补的问题。

用精确的名词。“改进入职流程”不是结果。“在不取消安全审查的前提下，减少新客服人员处理受监督案例之前必须完成的步骤”则指明了一个工作流程和一条边界。它仍需可衡量的验收标准，但已给了计划者可分解的真实对象。

不要把合同、客户记录、凭据、人事细节或保密财务数据上传到未获批准的服务。只概括计划所需的内容，把敏感对照信息留在拥有它的系统中，并遵守所在组织批准的数据处理规则。

怎样从交付物树出发用 AI 制定项目计划？

活动清单看似高效，却常掩盖工作存在的理由。先从交付物开始：推动项目走向结果的、可审查的产出。交付物可以是一份已批准的设计、一个已迁移的数据集、一支经过培训的运营团队、一项经过测试的集成，或一份已签署的政策。

让 AI 只根据项目说明提出交付物树：

把已批准的结果分解为最小的一组可审查交付物。对每项交付物，说明其目的、验收证据、可能的负责人角色，以及它满足了说明中的哪项要求。不要添加范围之外的功能或承诺。含糊的项目放进待解决问题清单。暂时不要估算时间。

与发起人和各领域负责人一起审查这棵树，留意相互重叠、描述持续活动而非产出，或悄悄扩大范围的交付物。“每周协调”是一项活动；如果项目确实需要，“已批准的集成决策日志”才是交付物。

为每项交付物写下审查者能观察到的验收标准。“完成培训”是含糊的。更好的标准会指明已批准的课程、目标角色、完成记录、知识检查、例外流程，以及接受证据的负责人。标准应描述成功，而不规定不必要的实施细节。

交付物稳定之后，再把它们分解为工作包和任务。每项任务都应有明确的产出，并且只属于一项交付物。如果某项任务同时支撑几项交付物，要么定义一项共享的支撑性交付物，要么把关系写清楚，而不是重复隐藏的工作。

把里程碑定义为决策或证据点

里程碑不是每一个截止日期，而是一次有意义的状态变化：范围获批、设计被接受、关键依赖得到证实、试点获得授权、迁移完成，或运营交接签署。好的里程碑能让发起人问：“有什么证据允许我们跨过这条边界？”

对每个里程碑，记录：

• 届时将成立的状态；
• 所需的交付物和验收证据；
• 决策者或审批人；
• 目标时间窗口，以及该日期的来源；
• 阻止跨越的条件；
• 错过里程碑时会发生什么。

AI 可以把里程碑顺序与交付物树比较，标出缺失的关卡。它不能批准关卡，也不能判定不完整的证据可以接受。避免使用“第一阶段完成”这类里程碑，除非该阶段有明确无歧义的产出和验收负责人。

把外部固定的日期与计算得出的日期分开。监管申报或已预订的活动可能是固定的；模型建议“设计需要十天”则是未经确认的工期。把两者混在一起，会让生成的排期看起来比实际更确定。

把依赖写成可验证主张

依赖是句子，不是箭头。把每项依赖写成：“在条件 A 成立之前，交付物 B 不能开始或完成，原因是 R；由 P 在 D 日期前确认。”这种格式会暴露该依赖是技术、资源、合同、信息层面的，还是只出于习惯。

这张图把计划的流向与确认关卡分开。交付物之间通过明确的条件相连；里程碑是证据点；未经核实的工期和关系会留在假设登记表中，直到负责人确认。

让 AI 挑战第一版依赖图：

根据交付物树和约束，提出可能的依赖关系。对每一项，引用暗示该依赖的输入。如果依赖是推断而非明确陈述的，标为 ASSUMPTION，并写出应由哪个角色核实。找出可并行的工作和循环依赖。不要分配日期。

然后访谈实际做这些工作的人。技术负责人可能知道两项任务可以并行；采购可能发现说明中遗漏的交付周期；运营可能要求在上线前进行演练。用已确认的关系更新计划，并保留决定的来源。

检查三个陷阱。第一，伪装成依赖的偏好：“我们一向先完成所有文案再做设计”可能只是习惯，而非必需。第二，遗漏的外部队列：法务、安全、采购、本地化或供应商审查。第三，资源依赖：两项并行任务需要同一位专家，因此日程仍然冲突。

谁负责交付物和决策？

每项交付物都需要一位最终负责人，即使有很多人参与。列出五个名字，并不能说明由谁解决歧义。记录负责人角色、已知时的具体人名、贡献者、审查人或审批人，以及升级路径。

AI 可以根据模式建议角色，但它不知道谁有权限。使用 OWNER TO CONFIRM 这类占位符，而不是编造某个人，或假定某个部门会接受这项责任。拟定的负责人必须同意范围和验收标准。

把“执行”和“批准”分开。写迁移计划的人未必有权授权迁移；估算任务的工程师未必能控制人员分配；想要某项功能的产品经理未必能批准合规例外。在计划中体现这些区别。

会议记录中常常包含隐含的分工。用会议记录转行动项流程提取候选行动，但要与被点名的人确认。会上沉默不等于接受责任。

用范围和假设估时

不要问“这个项目要多久？”，而要请求一份团队可以填写的估算工作表。每个工作包都要包括范围依据、估算人、最短/最可能/最长工期、工作量、所需角色、可用性假设、外部等待时间、置信度，以及参考的同类工作。

AI 可以统一单位、找出缺失的估算，或对已确认的输入做运算。它也能提出问题：是否包含了审查时间？工期假设的是一个人还是三个人？供应商的响应时间是否与实际动手的工作量分开？即使模型自己的数字不可靠，这些问题仍有价值。

把工作量、工期和等待时间区分开。八小时的工作可能因为审批而跨越五天。增加一个人未必能让工期减半。根据未确认的可用性计算出的日期，应继续标为临时。

对于数字化的计划，维护一份结构化的来源表，并使用 AI 表格分析流程检查公式、筛选、单位和缺失值。手动重新计算关键路径和预算总额。不要让一段生成的叙述成为这些数字的唯一记录。

建立风险、假设与决策登记表

一份精简的项目计划应链接到三份持续更新的登记表：

**风险登记表：**不确定事件、原因、潜在影响、概率与影响的评级方法、触发信号、缓解措施、应急方案、负责人和复核日期。

**假设登记表：**未经核实的陈述、计划目前为何依赖它、所需证据、确认人、确认日期，以及假设不成立时的影响。AI 生成的工期和依赖在核实之前都属于这里。

**决策日志：**决策、考虑过的选项、标准、审批人、日期、理由和受影响的计划要素。这可以防止模型——或之后的编辑者——悄悄重新打开已经定下的取舍。

让 AI 扫描各登记表与计划之间的矛盾。例如，某个里程碑依赖供应商，而风险登记表却漏掉了供应商延误；某项范围排除与某条验收标准冲突；某项资源假设与会议决定相矛盾。把扫描结果当作问题来源，并逐一核实每个匹配项。

避免“项目可能延期”这类笼统的风险。写明因果条件和先行指标：“如果数据流图未能在 9 月 12 日前被接受，安全审查可能会晚于预留的时间窗口开始。”实际日期必须来自获授权的排期，而不是模型。

在确定基准版本前设好变更边界

计划不是承诺一切不变，而是就“变更如何变得可见”达成的约定。定义哪些变更需要正式批准：范围增加、验收标准变化、里程碑移动超出容差、预算变化、新的数据处理方式、供应商变更，或取消控制措施。

变更请求应写明请求的变更、原因、受影响的交付物、对进度和成本的影响、风险、替代方案、建议和决策负责人。AI 可以整理请求格式并比较版本，但不得批准变更，也不得悄悄改写基准版本。

为计划做版本管理。记录基准日期、批准角色、关联的证据和被取代的版本。不要把一段对话记录当作权威计划。把获批的成果导出到团队的记录系统，并控制谁可以编辑。

批准之前，根据需要召集交付、技术、运营、安全、财务或法务代表，对计划进行一次质询。请每位审查者专注于自己的边界。笼统的综合审查会往往只带来客气的认同，却遗漏专业约束。

计划什么时候可以确定为基准版本？

当审查者能从这份成果中回答以下所有问题时，计划就可以确定为基准版本：

• 已批准的结果和范围是什么，排除了什么？
• 哪些交付物证明了进展，每项如何验收？
• 哪些里程碑代表真正的决策或证据关卡？
• 哪些依赖已由谁确认，哪些仍是假设？
• 谁负责每项交付物、审批、风险和待解决问题？
• 哪些日期是固定的、计算得出的或临时的？
• 假设不成立或有人提出变更请求时会发生什么？
• 来源证据、登记表和决策记录存放在哪里？

做一次简短的桌面推演：某位关键负责人无法到岗、某家供应商延误，或某项需求发生变化。团队能否在不重建计划的情况下，找出受影响的交付物和决策路径？如果不能，这个结构只是装饰，并不可运作。

当项目之后需要一套可重复的操作程序时，只把观察到并获批准的流程，用 AI 辅助 SOP 或检查清单流程转换出来。计划描述的是协调推进的变化；SOP 描述的是如何执行一个周期性流程。两者不应混淆。

常见问题

小项目也能用 AI 规划吗？

可以，但成果要与规模相称：一页项目说明、交付物清单、里程碑视图、负责人表，以及小型的风险/假设记录可能已经足够。不要只因模型能生成就增加形式。对估算、依赖和审批仍要保持同样的真实性边界。

AI 能自动生成甘特图和排期吗？

它可以根据已确认的任务、依赖、日历和工期整理出甘特图，但默认并不知道这些输入。在工作负责人核实之前，把生成的顺序和日期标为临时，然后在项目的记录系统中重新计算排期。

如何核实 AI 建议的依赖？

要求模型指出暗示每项依赖的输入，并标出推断。与实际执行工作的人以及外部队列的负责人一起审查。记录确认人和理由，而不只是一根箭头。

每个任务都要一个负责人吗？

每项交付物都应有一位最终负责人。执行开始时，任务也应有明确的负责人或角色。贡献者和审批人可以有多个，但要避免让决策悬而未决的共同负责。

多久更新一次 AI 辅助项目计划？

当获批的范围、证据、估算、负责人、依赖、风险或决策发生变化时，更新记录系统。按项目情况设定复核节奏，但不要让周期性的 AI 摘要绕过变更控制覆盖已批准的基准版本。

哪些项目信息不应交给 AI？

除非工具和用途获得明确授权，否则不要提供密钥、凭据、个人记录、保密合同、受限财务数据或敏感客户信息。尽量减少输入，把详细的来源记录保存在受控系统中。

延伸阅读

• 如何使用 AI 并保留人工复核
• 如何用 AI 分析表格
• 如何把会议记录转成行动项
• 如何把流程转成 SOP 或检查清单
• 如何核查 AI 答案中的事实
• 把任务计划用于搬家安排
• 对照既定基线汇报项目状态

来源

1. PMI, Section D: Project Planning Guidelines — https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/ugcr-vol-three.pdf?v=140b6f67-0460-4920-b12a-13b965c893b2
2. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 2026 年 8 月 24 日。