项目周报

---
name: 项目周报
description: >
  输入本周进展要点，输出结构化项目周报，涵盖完成事项、进行中、延期、风险、下周计划与决策需求。
  当用户要求"项目周报"、"写周报"、"本周汇报"、"进度汇报"、"工作周报"、"项目状态"、"weekly report"、"周报整理"时触发此技能。
argument-hint: "输入本周进展，例如：本周完成了访谈5场，数据分析初稿完成，PPT还在制作中"
name_en: "weekly-status-report"
description_en: >
  Enter this week's progress highlights to produce a structured project weekly report covering
  completed items, in-progress items, delays, risks, next week's plan, and decision requests.
  Trigger when the user asks for a "weekly report", "write a weekly report", "this week's update",
  "progress report", "work weekly", "project status", "weekly report", or "weekly roundup".
---

<!-- 主要修改：1.优化触发词新增"进度汇报/工作周报/项目状态" 2.连接器精简为Notion 3.新增能力层级图和连接器表 4.新增周报版本管理分支（内部版vs客户版具体差异） -->

# /项目周报 -- 从进展要点生成结构化咨询项目周报

**独立能力（无需连接器）**

- 周报标准七板块结构（完成/进行中/延期/风险/下周/决策/资源）
- 红黄绿灯状态判定标准（量化阈值）
- 风险分级矩阵 + 常见延期原因预防清单
- 需决策事项选项化（给选项不给开放题）

**增强能力（连接器加持）**

- ~~Notion -> 将周报自动发布至 Notion

## 连接器（可选增强）

| 连接器 | 增强能力 |
|--------|---------|
| **~~Notion** | 将结构化周报自动发布至 Notion，方便团队协作和历史归档 |

> 没有连接器也完全可以使用——周报以 Markdown 格式直接输出，用户可手动复制到目标平台。

将碎片化的项目进展信息整理为结构化的咨询项目周报。遵循"一页纸原则"——管理层用3分钟看完所有关键信息。内嵌周报标准七板块结构、红黄绿灯状态判定标准、风险分级矩阵和常见项目延期原因预防清单。**需决策事项须给选项而非开放题——管理层选择比思考更高效。**

## 调用方式

```
/项目周报 <本周进展要点>
```

## 输入要求

用户需提供以下信息（可分批补充）：

1. **项目名称**：当前项目或工作流名称
2. **本周进展**：完成了什么、正在做什么、遇到什么问题
3. **工作计划基准**（如有）：原计划本周应完成什么（对比实际进展）
4. **团队动态**（可选）：人员变动、协作情况
5. **客户反馈**（可选）：客户本周的关键反馈或决策
6. **上周遗留**（可选）：上周未完成事项的跟进情况
7. **周报版本**（可选）：内部版/客户版（决定内容口径和详略）

> 分支判断——项目状态决定周报侧重：
> - **项目按计划进行**（绿灯）→ 简报模式，聚焦下周计划和预防性风险提示
> - **轻微延迟（<1周）**（黄灯）→ 详细说明延迟原因+追赶计划，证明"可控"
> - **重大延迟（>2周）或方向性问题**（红灯）→ 危机模式，必须提出"范围/时间/资源 三选二"的决策请求

> 分支判断——周报版本决定内容口径：
> - **内部版**（给项目经理/合伙人）→ 含内部资源消耗、成本信息、团队问题、内部风险
> - **客户版**（给甲方项目负责人）→ 侧重进展、交付物、需甲方配合事项，措辞更正式；隐去内部资源和成本细节

## 执行流程

### 步骤一：信息解析与分类

- 将用户输入拆解为：已完成 / 进行中 / 延期 / 风险
- 识别隐含的决策需求和资源缺口
- 对模糊描述追问确认（标注[待确认]）

> 注意：用户经常低报风险和高报进度。如用户说"基本完成"应追问具体完成百分比；如说"有点延迟"应追问延迟几天及影响范围。

### 步骤二：状态灯判定

**红黄绿灯判定标准**：

| 状态 | 判定标准 | 管理含义 | 后续行动 |
|------|---------|---------|---------|
| **绿灯** | 进度偏差<3天，无重大风险，关键交付物按期 | 项目可控，无需干预 | 常规周报即可 |
| **黄灯** | 进度偏差3-7天，或有中等风险，或客户反馈需调整 | 需关注，可能需要调整 | 说明追赶计划，标注需关注事项 |
| **红灯** | 进度偏差>7天，或有重大风险，或关键交付物延期，或方向性问题 | 需立即决策和干预 | 必须提出决策请求，给出选项 |

### 步骤三：周报结构生成（一页纸原则）

按以下七大板块组织内容：

**1. 本周完成事项**（按优先级列出已交付成果）
- 每条须有可验证的交付成果（"完成了调研"不够具体，应为"完成了XX行业桌面调研报告初稿，共35页"）

**2. 进行中事项**（标注进度百分比与预计完成时间）
- 须标注是否在计划内，如有偏差说明原因

**3. 延期事项**（说明延期原因与补救计划）

**常见项目延期原因及预防清单**：

| 延期来源 | 常见原因 | 预防措施 |
|---------|---------|---------|
| **客户侧** | 数据延迟提供 | SOW中约定时间+提前1周催促 |
| **客户侧** | 审批/决策慢 | 提前锁定审批人日程+给deadline |
| **客户侧** | 需求变更/新增 | 变更管理流程+影响评估 |
| **团队侧** | 资源冲突（多项目并行） | 提前锁定资源+项目优先级排序 |
| **团队侧** | 能力不足/学习曲线 | 项目初期预留学习时间+安排辅导 |
| **团队侧** | 低估工作量 | 参考历史项目+人天估算表 |
| **外部** | 政策变化/市场突发 | 保持信息敏感度+快速响应机制 |

**4. 风险与问题**

**风险分级标准**：

| 级别 | 影响x概率 | 说明 | 处理方式 |
|------|---------|------|---------|
| **高风险** | 影响大 + 概率高 | 可能导致项目延期/交付质量下降/客户不满 | 需立即决策，本期周报必须升级 |
| **中风险** | 影响中 或 概率中 | 可能影响部分工作包进度 | 需持续关注，制定预案 |
| **低风险** | 影响小 + 概率低 | 影响有限，可控 | 纳入监控清单，无需专项行动 |

**5. 下周计划**（明确责任人与交付日期）

**6. 需决策事项**——这是周报最核心的板块
- 每个决策事项须包含：**背景**（为什么需要决策）→ **选项**（给2-3个选项，含利弊分析）→ **建议**（推荐哪个选项及理由）
- **不给开放题**：不写"下周方向请领导指示"，而写"下周建议聚焦方案A（原因XX），或可选择方案B（利弊XX），建议选A"

**7. 资源需求**（人力、预算、外部支持需求）

### 步骤四：关键指标提炼

- 提取本周关键里程碑达成情况
- 计算项目整体进度（已完成工作包数/总工作包数 或 已消耗人天/总预算人天）
- 标注红黄绿灯状态

**关键指标追踪表**（如有工作计划基准）：

| 指标 | 计划值 | 实际值 | 偏差 | 状态 |
|------|-------|-------|------|------|
| 项目整体进度 | XX% | XX% | +/-XX% | G/Y/R |
| 已消耗人天/总预算 | XX/XX | XX/XX | - | G/Y/R |
| 交付物完成 | X/Y个 | X/Y个 | - | G/Y/R |
| 关键里程碑 | 按期/延期 | - | - | G/Y/R |

### 步骤五：输出与发布

**如果连接了 ~~Notion：**
1. 将周报自动发布至 Notion
2. 保持七板块结构和表格格式
3. 返回文档链接，方便团队和管理层查阅

**如果未连接：**
1. 以 Markdown 格式直接输出完整周报
2. 用户可手动复制到目标文档平台

## 输出格式

```markdown
# [项目名称] 项目周报
**报告周期**：YYYY.MM.DD - YYYY.MM.DD（第X周/共Y周）
**报告人**：[待填写]
**整体状态**：G正常 / Y关注 / R预警
**版本**：[内部版/客户版]

> **一句话摘要**：[本周核心进展与关键风险概述]

## 关键指标
| 指标 | 计划 | 实际 | 偏差 | 状态 |

## 一、本周完成事项
- [x] 事项1 -- 交付成果描述

## 二、进行中事项
| 事项 | 进度 | 责任人 | 预计完成 | 是否在计划内 |

## 三、延期事项
| 事项 | 原计划 | 延期原因 | 追赶计划 | 新计划 |

## 四、风险与问题
| 风险 | 级别 | 影响范围 | 概率 | 应对措施 | 责任人 |

## 五、下周计划
- [ ] 计划1 -- 责任人 -- 截止日期

## 六、需决策事项
### 决策1：[主题]
- **背景**：[为什么需要决策]
- **选项A**：[描述] | 优势：[XX] | 风险：[XX]
- **选项B**：[描述] | 优势：[XX] | 风险：[XX]
- **建议**：选择[X]，理由：[XX]

## 七、资源需求
- 类型：具体需求描述
```

## 质量标准

- **完整性**：七大板块缺一不可，无内容的板块标注"本周无"
- **可追溯**：每项完成事项对应可验证的交付成果（不接受"进行中"作为完成描述）
- **风险前置**：风险描述包含影响范围、概率和应对方案
- **决策友好**：需决策事项提供背景、选项和建议，而非仅抛问题
- **时间明确**：所有计划事项均标注截止日期和责任人
- **状态可视**：整体状态用红黄绿灯直观呈现
- **一页纸原则**：管理层应能在3分钟内抓住所有关键信息
- **偏差量化**：延期和风险须量化（偏差几天、影响多少人天），不可只定性

## 红线规则

1. **不隐瞒延期和风险**：周报是项目健康度的晴雨表，隐瞒延期等于放大风险
2. **需决策事项不给开放题**：不可写"请领导指示"，必须给出具体选项和推荐建议
3. **不虚报进度**：标注60%进度的事项须确实完成了60%的工作
4. **不回避难以启齿的问题**：如果客户侧出了问题，必须如实反映，措辞需diplomatic
5. **周报不可迟交**：咨询项目周报通常在每周五下午或周一上午提交
6. **不写无法验证的完成事项**：每条完成事项须有明确的交付物证据

## 灰色地带处理

1. **进度难以精确量化** → 将模糊工作拆分为可量化的里程碑，或用时间投入替代进度百分比
2. **客户问题但不宜直接写在周报中** → 用中性措辞描述，不指责具体个人
3. **团队成员表现问题** → 周报中不点名批评，描述为"XX交付物需补充完善"，人员问题通过内部管理渠道解决
4. **好消息与坏消息如何平衡** → 原则是"先结果后风险"——先展示本周成果和进展，再提出问题和风险，最后给出解决方案
5. **周报应报给谁** → 通常有两个版本——(1)内部版（含内部资源和成本信息）(2)客户版（侧重进展和需甲方配合的事项）。在输入中确认版本，避免信息泄露

## 输入不足处理

- 仅提供本周进展要点时：输出基础周报框架，标注"信息有限，建议补充项目名称、上周遗留事项后获得更完整周报"
- 缺少关键信息时：主动向用户追问最重要的 2-3 个数据点（如项目名称、风险事项、需决策问题）
- 绝不编造数据、案例或市场信息——无法验证的信息标注[需验证]
- **快速模式**：用户提供完整进展信息 → 直接输出结构化周报
- **引导模式**：用户仅说"帮我写周报" → 先追问项目名称和本周进展，再结构化输出

## Agent 工具增强

- **WebSearch**：搜索行业动态、政策变化等外部风险信号，补充风险板块
- **文件处理**：支持读取用户上传的工作计划Excel、上周周报、会议纪要等，自动对比计划vs实际
- **代码执行**：进度计算、人天消耗分析、趋势预测等使用Python确保精度
- **图像识别**：可解读用户上传的甘特图截图、项目看板截图等

## 相关技能

- `/CEO汇报`：将周报中的关键发现升级为高管级别的一页纸汇报
- `/方案框架`：周报发现的进度偏差可用于调整方案框架的工作计划
- `/写报告`：周报积累的数据和发现是最终报告撰写的素材来源