AI项目状态摘要要同时回答四个问题：本期做成了什么、和计划差在哪里、哪些风险还没发生但需要提前处理、下期交付什么。这份模板用一张表承载进展、偏差、风险、下一步四栏，四栏共用里程碑、工作项、负责人和日期这组对象，方便核对与交接。摘要中的工作项、负责人和日期通常来自项目管理工具，ONES Assistant可基于项目、工作项和迭代上下文生成进展分析与风险提示，可作为取数和初稿的辅助。下文先给空白表，再说明每格怎么写、哪些不能空，并附一份演示填写的完整示例。
要点总览（TL;DR）
- 模板用一张表承载四栏：进展写可验证结果、证据和对应工作项；偏差写计划值、实际值、差距、原因和影响；风险写事件、触发条件、概率、影响、应对与责任人；下一步写交付结果、负责人、时间点和依赖。
- 表头四项（项目名称、报告周期、填写人、数据截止时间）每期保持一致，四栏共用工作项、负责人、日期这组对象，摘要才能被核对和交接。
- 必填字段集中在可核对与可追责：进展必须有结果和工作项，偏差必须写影响，风险必须有应对措施和责任人，下一步必须有时间点；空缺统一标“待确认”或“无”。
- S4给出一份演示填写的完整示例，偏差与风险指向同一工作项，展示延期如何转化为风险、下一步如何依赖外部条件。
- 模板按项目阶段增减字段，字段命名与计量口径跨周期统一，调整时保留版本号和生效日期，历史摘要按原版本留存。
可直接复制的AI项目状态摘要空白模板
下表可直接复制到文档或表格工具中填写。表头固定放在表格上方，四栏各留出多行，按条目逐条填写，一条结果或一条风险占一行，避免把多件事挤在同一格。
| 表头字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 报告周期 | （如：2025年3月第2周，3月10日—3月14日） |
| 填写人 | |
| 数据截止时间 | （精确到日期与时刻，如：3月14日18:00） |
| 序号 | 进展：结果 | 证据 | 对应工作项 | 负责人 | 完成日期 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
| 序号 | 偏差事项 | 计划值 | 实际值 | 差距 | 原因 | 影响 | 对应工作项 |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 |
| 序号 | 风险事件 | 触发条件 | 概率 | 影响 | 应对措施 | 责任人 | 关联工作项 |
|---|---|---|---|---|---|---|---|
| 1 | 高/中/低 | ||||||
| 2 | 高/中/低 |
| 序号 | 下期交付结果 | 负责人 | 时间点 | 依赖 | 关联工作项 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
表格行数按实际条目增减，不建议为了凑满而拆分或合并条目。表头四项在每期摘要中保持一致，便于跨周期对比。
四栏字段说明与表达结构
四栏的写法差异来自它们回答的问题不同：进展面向已发生的事实，偏差面向计划与实际的差距，风险面向尚未发生的事件，下一步面向即将交付的结果。每栏按固定顺序组织句子，读者能快速定位关键信息。
进展：结果、证据、工作项
先写本期完成的可验证结果，再给证据，最后挂上对应工作项。结果用名词性表述，如“完成支付回调接口联调并通过回归测试”，避免写“推进了支付模块”这类无法核对的描述。证据可以是测试报告、评审记录、上线记录或文档链接。对应工作项填编号或名称，保证读者能回到原始记录核对。
偏差：计划值、实际值、差距、原因、影响
偏差栏按“计划多少、实际多少、差多少、为什么、影响什么”的顺序写。计划值和实际值使用同一口径，例如都以工作日或故事点计。差距写绝对值和比例，原因写可归因的具体事件，影响写对里程碑、范围或质量的实际后果。原因不写“资源紧张”这类笼统判断，写“后端接口联调因第三方沙箱延迟3天开放”。
风险：事件、触发条件、概率、影响、应对与责任人
风险描述尚未发生的事件，句式是“如果……则……”。触发条件写可观察的信号，如“第三方接口在3月20日前未提供正式环境”。概率用高、中、低三档并附一句判断依据。影响写对目标的具体威胁。应对措施写已决定采取的动作，责任人写具体人名，关联工作项便于跟踪闭环。
下一步：交付结果、负责人、时间点、依赖
下一步写的是下期要交付的结果，而非待办动作清单。“完成订单模块提测”是结果，“继续开发订单模块”是动作。每条结果配负责人、时间点和依赖。依赖写外部条件，如“等待测试环境扩容完成”，便于提前协调。时间点写到日期，跨团队交付写到具体交接节点。
必填与选填：哪些格子不能空
必填字段决定摘要能否被核对和交接，选填字段补充背景。空缺时用统一标注，避免留白造成误读。
| 栏目 | 必填字段 | 选填字段 | 空缺处理 |
|---|---|---|---|
| 表头 | 项目名称、报告周期、填写人、数据截止时间 | — | 不允许空缺 |
| 进展 | 结果、对应工作项、负责人 | 证据、完成日期 | 证据暂缺标“待补充”，并注明补齐时间 |
| 偏差 | 偏差事项、计划值、实际值、差距、影响 | 原因、对应工作项 | 原因未查清标“待确认”，影响必须写 |
| 风险 | 风险事件、影响、应对措施、责任人 | 触发条件、概率、关联工作项 | 概率未评估标“待评估”，应对措施不可空 |
| 下一步 | 交付结果、负责人、时间点 | 依赖、关联工作项 | 依赖不明标“待确认”，时间点不可空 |
必填的理由集中在可核对与可追责：结果没有工作项就无法回溯，偏差没有影响就无法判断优先级，风险没有责任人就无法闭环，下一步没有时间点就无法排期。选填字段在信息充分时补充，能提升摘要的可读性，但不影响基本判断。确实没有内容的格子写“无”，表示已确认不存在，与“待确认”区分开。
填写示例：一份完整的状态摘要
以下为演示情景，数据为虚构，仅用于展示四栏与模板字段的对应关系。
| 表头字段 | 填写内容 |
|---|---|
| 项目名称 | 会员中心改版 |
| 报告周期 | 2025年3月第2周（3月10日—3月14日） |
| 填写人 | 项目经理 李某 |
| 数据截止时间 | 3月14日18:00 |
| 序号 | 进展：结果 | 证据 | 对应工作项 | 负责人 | 完成日期 |
|---|---|---|---|---|---|
| 1 | 完成登录与注册流程改版并上线灰度环境 | 灰度发布记录、回归测试报告 | MEM-112 | 王某 | 3月12日 |
| 2 | 完成会员等级规则评审并冻结需求范围 | 评审纪要 | MEM-118 | 赵某 | 3月13日 |
| 序号 | 偏差事项 | 计划值 | 实际值 | 差距 | 原因 | 影响 | 对应工作项 |
|---|---|---|---|---|---|---|---|
| 1 | 积分接口联调完成时间 | 3月12日 | 3月14日未完成 | 延后2天以上 | 第三方沙箱环境延迟开放 | 联调里程碑顺延，可能影响3月21日提测 | MEM-121 |
| 序号 | 风险事件 | 触发条件 | 概率 | 影响 | 应对措施 | 责任人 | 关联工作项 |
|---|---|---|---|---|---|---|---|
| 1 | 如果第三方正式环境3月20日前未就绪，则提测时间推迟 | 3月18日仍未收到环境账号 | 中（对方上周已延期一次） | 提测推迟至少3个工作日 | 3月17日升级至双方接口人例会，准备本地模拟环境兜底 | 李某 | MEM-121 |
| 序号 | 下期交付结果 | 负责人 | 时间点 | 依赖 | 关联工作项 |
|---|---|---|---|---|---|
| 1 | 完成积分接口联调并通过冒烟测试 | 王某 | 3月19日 | 第三方正式环境账号 | MEM-121 |
| 2 | 提交会员等级模块提测包 | 赵某 | 3月21日 | 联调完成 | MEM-125 |
示例中偏差与风险指向同一工作项MEM-121，读者能看出延期如何转化为风险，以及下一步交付如何依赖外部条件。这种前后关联是摘要可交接的关键。
模板的调整与维护方法
模板需要随项目阶段和团队习惯调整，但调整应集中在字段增减和口径统一上，避免每期换一种写法导致历史摘要无法对比。
按项目阶段增减字段
启动阶段可弱化偏差栏，强化下一步的依赖与决策点；开发阶段保留完整的偏差与风险字段；上线阶段增加“上线检查项”和“回滚预案”作为风险栏的补充列。字段增减在表头下方注明适用阶段，避免不同阶段混用同一张表。
字段命名与口径统一
计划值和实际值统一计量单位，概率统一用高、中、低三档，时间统一写到日期。字段名称一旦确定，跨周期保持一致；确需改名时在模板版本说明中记录旧名与新名。填写人变更时，交接说明中注明口径是否有变化。
模板版本与历史摘要留存
每次调整模板保留版本号和生效日期，历史摘要按原版本留存，不回溯改写。这样跨周期对比时能区分“数据变化”和“口径变化”。摘要中的工作项、负责人和日期若来自项目管理工具，可在ONES中直接取数；ONES Assistant可基于项目与迭代上下文生成进展分析和风险提示，并将结果保存为工作项或Wiki页面，便于摘要与原始记录对应。是否引入工具辅助取数，取决于团队已有的项目管理实践和数据完整程度。
常见问题
进展栏写“推进了某模块”这类描述可以吗？
不建议。进展栏要写本期完成的可验证结果，例如“完成支付回调接口联调并通过回归测试”，再附证据和对应工作项。只写“推进了支付模块”无法核对完成程度，也无法回溯到原始记录。如果本期确实只完成部分工作，就写已完成的那部分结果，未完成部分放到下一步。
偏差原因一时查不清，摘要还能发吗？
可以发，但要把原因标为“待确认”，并注明计划补齐的时间。偏差栏的必填项是偏差事项、计划值、实际值、差距和影响，原因属于选填。影响必须写清楚，因为它决定这条偏差的优先级。原因查清后，在下一期摘要中补充说明，并注明是对上期条目的更新。
风险和偏差容易写混，怎么区分？
偏差是已经发生的事实，写计划与实际的差距；风险是尚未发生、可能影响目标的事件，句式用“如果……则……”。示例中积分接口联调延后属于偏差，第三方正式环境可能未按时就绪属于风险，两者可以指向同一工作项。分开写能让读者看清哪些问题已经发生、哪些还需要提前准备应对。
下一步写成待办清单行不行？
下一步写的是下期要交付的结果，不是动作清单。“完成订单模块提测”是结果，“继续开发订单模块”是动作。每条结果配负责人、时间点和依赖，依赖写外部条件，例如等待测试环境扩容。这样排期和协调有明确对象，跨团队交接时也能对齐节点。
不同项目阶段可以用同一张表吗？
可以共用基础结构，但字段按阶段增减。启动阶段可弱化偏差栏，强化下一步的依赖与决策点；开发阶段保留完整的偏差与风险字段；上线阶段在风险栏补充上线检查项和回滚预案。增减字段时在表头下方注明适用阶段，避免不同阶段混用同一张表导致口径混乱。
