用 AI 创建项目状态报告，要把获批基线与实际值和预测进行比较。每一项偏差和决定都必须由负责人核实。

先建立受控的 AI 流程。状态报告是一份注明日期的管理记录，它不能代替获批的项目计划，也不是在结果出来之后改写基线的地方。

关键要点

先固定报告周期、状态日、受众、决策需求和报告负责人。

把基线、实际和预测值放在不同字段中，并附上证据和置信度。

风险、当前问题、依赖、变更和决定分开记录。

只使用预先批准的 RAG 定义和升级阈值。

保留未知信息和分歧，而不是让 AI 把叙述写得看似完整。

要求有具名的数据负责人和一位最终承担责任的批准者。

用 AI 创建项目状态报告要证明什么？

一份有用的报告要回答三个问题：在状态日项目处于什么位置；这个位置与获批计划相比如何；现在需要哪项获授权的决定或行动。英国政府职能标准 GovS 002 把治理、规划、控制和可追溯性视为相互关联的项目交付实践。［1］

报告应当能根据其来源台账重现。审核人需要看到每一项陈述分别由哪个进度计划版本、成本台账、质量记录、收益度量、风险登记册、问题日志和变更记录支持。没有这些引用的润色叙述，不是可靠的控制手段。

不要混淆不同的时间概念：

字段	含义	示例
基线	用于比较的获批承诺	获批的里程碑日期为 9 月 30 日
实际	状态日经核实的情况	验收测试于 10 月 3 日完成
预测	当前基于证据的预期	预计 10 月 18 日部署
偏差	按获批规则计算的差异	比基线晚 18 天
置信度	预测所依据证据的质量	中等；供应商日期尚未确认

GAO 把可靠的进度计划描述为一种工具，用于对照获批计划衡量绩效，并理解延误和变更的影响。［2］因此，预测不是修订后的基线。更改基线必须经过项目正式的变更控制流程。

先收集什么？

针对确切的报告截止点建立一份来源台账。最快又安全的做法，是请每位数据负责人提交一份简短的结构化更新，而不是把一堆未经控制的文档直接丢给模型。

至少收集：

获批的范围、里程碑、进度、预算、质量和收益基线；
实际完成的证据和已验收的交付物；
附有假设和置信度的预测日期或成本；
来自权威登记册的未关闭风险、问题、依赖和变更请求；
自上次报告以来已作出的决定，以及现在需要作出的决定；
以往的承诺、负责人、截止日期和关闭证据；
组织的 RAG 定义和升级政策。

现行的 Gate 2 评审指南要求对进度、风险、问题、依赖、约束、决定、成本、收益和正式变更进行控制。［3］请使用与你的治理体系相关的字段；不要未经调整负责人和审批安排，就把政府的检查清单照搬到私营项目中。

记录冲突，而不是悄悄把它们化解掉。如果交付负责人说某个里程碑已完成，但质量部门尚未验收，就同时保留这两项事实，并把验收标为未完成。如果财务和项目办公室使用不同的成本截止日，就标注两个日期，并询问承担责任的负责人报告应采用哪一个口径。

删除报告决策不需要的信息。个人数据、合同敏感细节、凭据、原始客户记录和私人通信应留在获批系统中。只要可能，就只给模型提供最小化的摘录或合成示例。

如何设计状态报告模板？

每个报告周期一条记录，每个重要状态项一行。下面这组字段能让遗漏一目了然：

分组	必填字段
控制	报告 ID、版本、周期、状态日、负责人、审批者
基线	基线 ID、批准日、范围、里程碑、预算、质量、收益
当前情况	计划、实际、预测、偏差、置信度、证据引用
例外	风险、问题、依赖、变更请求、假设
行动	待决事项、行动负责人、期限、升级路径
审批	数据复核、质疑记录、批准日、分发范围、变更日志

对每个状态领域，都问同一组严谨的问题：批准的是什么？截至状态日，经核实的情况是什么？接下来预期会怎样？偏差是由哪条规则得出的？答案有什么证据支持？谁能更正或批准它？

在对任何项目数值分类之前，先写好 RAG 规则。例如，组织可以用特定的预测偏差和恢复条件来定义黄色。如果没有获批规则，就展示事实并写明“未分配评级”，不能让 AI 根据语气猜颜色，也不能让它自创阈值。

如何约束 AI？

向 AI 提供报告契约、来源台账、允许的转换方式和禁止做出的决定。要求它输出一份结构化草稿，外加一份例外清单。

有边界的指令应要求模型：

只使用提供的记录，并保留其标识；
区分基线、实际和预测值；
除非提供了确定性的计算结果，否则不做任何计算；
把无依据或相互冲突的陈述标为 NEEDS_REVIEW；
把风险、问题、依赖、变更和决定分开；
只应用提供的 RAG 定义；
不引用获批摘录以外的任何机密材料；
生成一份证据映射，把每条摘要主张对应到其来源记录。

要明确写出：不得编造 RAG 状态、完成百分比、偏差原因、预测、恢复日期、负责人、批准或决定。模型可以建议更清楚的措辞，但不能把缺失的证据变成事实。

只要一份草稿，而不是五个有说服力的版本。多个版本会诱导人们按自信程度或语气而不是证据来挑选。报告事关重大时，保存提示、模型输出、来源台账版本和审核人的修改。

如何核对数值？

在语言模型之外执行确定性的核对。日期、合计、偏差、挣值指标、阈值和汇总，应由电子表格或受控的报告系统用锁定的公式计算。

对每一条重要记录：

把基线值与某个获批基线标识对应起来；
把实际值与完成、验收、台账或度量记录对应起来；
找出预测背后的假设和负责人；
用获批公式重现偏差；
确认报告截止点和数据的新鲜度；
把当前预测与上一份报告比较；
用引用的问题、风险、依赖或变更记录解释任何变化。

不要仅仅因为十项任务关闭了九项，就报告“完成 90%”。各项任务的工作量、关键程度、验收标准或依赖可能都不同。如果项目没有获批的进度度量方法，就直接报告已完成和未完成的交付物。

同样，只有评级定义允许时，绿色的进度状态才能和一个未解决的验收缺陷同时存在。要把质量例外展示出来，而不是让一个总体颜色把它抹掉。

如何分开例外？

风险是不确定的未来事件；问题是已经发生的事情。依赖是项目所依靠的事物；变更请求提议修改获批基线；决定请求则要求获授权的人作出选择或批准。把它们合并成一段“关注事项”，会掩盖责任归属和时间。

使用一张简洁的例外表：

类型	证据	影响	负责人	期限/触发条件	需要的决定
风险	风险记录	未来可能的影响	风险负责人	触发日期	批准应对措施
问题	问题记录	当前影响	问题负责人	解决日期	逾期时升级
依赖	依赖记录	所需的输入/输出	接口负责人	需要日期	优先级冲突
变更	变更请求	对基线的拟议影响	变更负责人	委员会会议日期	批准或否决

AI 草稿可以缩短文字，但不能把风险改成问题，不能暗示拟议的变更已获批准，也不能把沉默描述成同意。把每一项决定请求与项目的授权安排和治理日程进行比较。

面向高管时，先写决定、按获批方案衡量的交付信心，以及影响结果的少数几项例外。只有在底层状态通过审核之后，才使用高管摘要流程。

如何批准和更正？

采用三层审核。第一层，由工作流和数据负责人确认证据、截止日期和计算。第二层，由报告负责人检查各部分之间是否一致，并质疑过于乐观或无依据的措辞。第三层，由承担责任的决策者批准版本和分发范围。

审核记录应包括：

来源台账和基线的版本；
尚未弥补的证据缺口，以及由谁接受；
数据负责人审核后所做的修改；
RAG 和升级规则的版本；
批准人、批准时间和分发名单；
发布后发出的更正。

不要覆盖已发出的报告。创建一个写明原因的更正版本，并按政策保留原件。把决定和已批准的变更录入相关系统，而不只是写进下一期的叙述中。

项目收尾后，在单独的经验总结流程中分析反复出现的报告缺口。如果报告引发了面向相关方的信息传达，就把已批准的事实移入一份变更沟通计划；状态报告本身不应变成宣传稿。

拦截哪些错误？

出现以下情况时，退回草稿：

用最新预测而不是获批基线来比较实际值；
在没有引用批准的情况下更改基线；
把“未知”变成零、已完成、绿色或按计划进行；
混淆风险、问题、依赖、变更和决定；
未检查时效就重复上一期的叙述；
声称了证据无法证明的原因；
指派的负责人没有相应权限，或尚未接受该行动；
用平均值、颜色或笼统的安抚语掩盖分歧；
升级事项中遗漏了决定、期限或后果；
暴露的敏感来源材料超出了决策所需。

NIST 的生成式 AI 配置文件列出的风险包括虚构内容、数据隐私、信息完整性和人类过度依赖。［4］把流畅的措辞当作需要核实的输出，而不是项目健康的证据。

总结

固定周期、状态日、受众、基线和报告规则。
在向 AI 提示之前，收集经过最小化、由负责人核实的证据。
把计划、实际、预测、偏差、置信度和证据分开。
保持风险、问题、依赖、变更和决定之间的区别。
使用确定性计算和预先批准的 RAG 阈值。
只发出经数据负责人和承担责任的批准者审核的版本。

常见问题

只靠会议记录可以吗？

不可以。会议记录可以提示可能的更新，但不能证明获批基线、实际完成情况、已认可的成本或预测。应先把每一项主张与其权威记录核对一致。

AI 可选红黄绿吗？

只有当它是在对经核实的输入机械地应用获批规则，而且结果经过独立核对时才可以。如果规则或输入缺失，就不分配评级。

实际与预测有何区别？

实际描述的是状态日经核实的情况。预测描述的是对未来结果的当前预期，应当附上假设和置信度。

可在报告里改项目基线吗？

不能只为了让偏差消失而修改。只有经过项目获授权的变更控制流程才能更改基线，之后新基线会有自己的标识和批准记录。

高管需要多少细节？

包括理解结果、例外、决定、负责人和期限所需的证据。把支撑记录放在受控附录或来源系统中，而不是用原始细节塞满摘要。

未知怎么写？

标明未知，写出缺失的证据及其负责人，说明对决策的影响，并设定解决日期。不要把未知转换成零或有利的状态。

谁批准？

数据负责人确认各自负责的部分，承担责任的项目权力方则按治理模式批准整份报告。报告负责人负责协调，但并不继承所有的批准权。

发出后发现错呢？

保留已发出的版本，并按记录政策发布一份可追溯的更正或替代版本。悄悄覆盖会破坏审计轨迹，并可能让读者使用不同的事实。

免责声明：本文提供一般性的项目报告信息。请遵守你所在组织的治理、会计、记录、安全和保证要求。

来源：

GOV.UK — Government Functional Standard GovS 002: Project Delivery — https://www.gov.uk/government/publications/project-delivery-functional-standard
U.S. Government Accountability Office — Schedule Assessment Guide — https://www.gao.gov/products/gao-16-89g
GOV.UK — Gate 2 Review: Delivery Strategy — https://www.gov.uk/government/publications/gate-review-2-delivery-strategy/gate-2-review-delivery-strategy
NIST — Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

如何用 AI 创建项目状态报告：对照获批基线核实进度与偏差