gagaa-hue 部门周报/月报生成器
概述
这个技能帮助管理者将分散的个人周报合并为结构化的部门周报，或将多周周报整理为月报。核心价值在于：
- 质量把控：确保周报聚焦核心目标，而非事务清单
- 标准统一：所有完成事项有明确验收标准，延期事项有完整解决方案
- 自动归类：日常事务自动归入附件，主体只保留 3-5 项重点
工作流程
第一步：确认报告类型
主动询问用户：
请问您需要生成：
1. 周报（将成员个人周报合并为部门周报）
2. 月报（将 4 周部门周报整理为月报）
第二步：收集输入内容
生成周报时：
提示用户粘贴成员周报，并说明格式要求：
请粘贴各成员的周报内容。格式要求：
- 每个人的周报开头需标注姓名（如"姓名：张三"）
- 使用 --- 分隔不同成员的周报
示例：
姓名：张三
本周完成了XXX工作...
---
姓名：李四
本周完成了YYY工作...
然后询问公司核心目标：
请提供本期的公司核心目标（2-5 条），用于筛选重点事项。
示例：
1. 完成产品 2.0 上线
2. 用户增长达到 10 万
3. 成本优化降低 20%
生成月报时：
提示用户粘贴 4 周的部门周报：
请粘贴本月 4 周的部门周报内容（按周顺序，用 --- 分隔）。
然后提供下月的核心目标（2-5 条），用于生成下月工作计划。
第三步：解析与验证
周报模式：
识别成员：通过"姓名："标识和
---分隔符，拆分每个人的周报- 如果缺少姓名标识，提示用户："未识别到成员姓名，请确保每个人的周报开头包含'姓名：XXX'"
- 如果分隔不清晰，尝试智能识别段落边界，失败则提示用户添加
---
内容检查：
- 如果某成员的周报内容过少（少于 50 字），警告："XXX 的周报内容过少，可能影响部门周报质量"，但仍继续处理
- 提取每个人的工作事项、状态、结果
月报模式：
周次识别：检查是否提供了 4 周完整内容
- 如果只有 2-3 周，提示："检测到缺少第 X 周的周报，是否继续生成不完整月报？"
内容提取：从每周周报中提取核心事项、人效判断、未完成事项
第四步：生成部门周报
输出结构
部门周报包含以下板块：
# 部门周报 - YYYY年MM月第N周
## 1. 本周结论
[2-3 段文字，总结本周核心进展和主要结论]
本周技术部围绕 [核心目标] 推进工作。完成了 X 项，延期 Y 项，整体进度 [评估]。
主要亮点：[列出 1-2 个突破性进展]
主要问题：[列出 1-2 个阻塞点]
## 2. 重点工作
| 工作事项 | 上周承诺 | 实际结果 | 状态 | 原因与解决方案 |
|---------|---------|---------|------|--------------|
| [事项1] | [承诺内容] | [结果 + 验收标准] | 完成/延期/风险 | [原因/方案] |
| ... | ... | ... | ... | ... |
## 3. 人效判断
**整体评估**
[统计数据：完成 X 项，延期 Y 项，风险 Z 项，整体交付节奏评价]
**主要瓶颈**
[识别共性问题，如多人遇到同类阻塞、资源不足等]
**改进建议**
[具体可执行的改进措施]
## 4. 下周工作
| 交付结果 | 负责人 | 验收标准 | 时间 |
|---------|-------|---------|------|
| [结果1] | XXX | [明确的验收标准] | 周X XX:XX |
| ... | ... | ... | ... |
---
## 附件：日常工作清单
### 张三
- [日常事项1]
- [日常事项2]
### 李四
- [日常事项1]
- [日常事项2]
核心逻辑
筛选重点事项（3-5 项）：
- 将所有成员的工作事项与用户提供的"公司核心目标"进行匹配
- 选出与核心目标直接相关的 3-5 项重点工作
- 如果多人做同一项目的不同部分，合并为一行，在"负责人"列标注多人
- 其他日常事务（如"日常维护""例行会议""文档整理"等）归入附件
为什么只保留 3-5 项： 管理的本质是聚焦。部门周报是给上级和相关方看的，他们需要快速了解"这个部门本周在核心目标上的进展"，而非所有人的所有工作。大量事务清单会稀释重点，降低周报的战略价值。
验收标准生成：
完成事项必须有明确的验收口径。检查每个事项：
- 如果已有明确验收标准（如"通过 3 分钟语音测试""P95 延迟 < 5 秒""用户留存率提升 10%"），直接保留
- 如果只有模糊表述（如"开发完成""已提交""正在推进"），基于工作内容推断并生成建议的验收标准，标记为
⚠️ 待确认
为什么这样做： "完成"的定义必须明确。没有验收标准的"完成"往往意味着返工。自动生成建议标准可以提醒负责人补充，避免周报成为形式主义。
延期事项检查（四要素）：
识别状态为"延期""风险""部分完成"的事项，检查是否包含：
- 原因：为什么延期
- 解决方案：如何解决
- 负责人：谁来解决
- 新完成时间：什么时候能完成
如果缺失任何要素，在"原因与解决方案"列标记：❌ 缺失：[原因/解决方案/负责人/新时间]
为什么这样做： 延期不可怕，可怕的是延期后没有明确的挽回计划。四要素确保延期事项不是"不了了之"，而是"有人负责、有方案、有时间表"。
人效判断生成：
这部分需要你基于数据和判断，生成 2-3 段文字：
整体评估：统计完成事项数、延期事项数、风险事项数，给出整体交付节奏评价
- 示例："4 项重点任务中完成 1 项，延期 2 项，风险 1 项，整体交付节奏偏慢"
主要瓶颈：识别共性问题
- 如果多人都卡在同一个技术难题上，说明这是团队级阻塞
- 如果多人都提到"人手不足"，说明资源分配有问题
- 示例："主要问题是人数对绩效不足，技术负债较多，整体交付任务过多"
改进建议：给出具体可执行的建议
- 示例："下周需统一解决 XX 技术问题，所有人围绕完整版本推进，避免各自为战"
为什么这样做： 人效判断是管理者的核心价值。它不是简单的数据堆砌，而是对团队状态的洞察和改进方向的指引。
第五步：生成部门月报
输出结构
# 部门月报 - YYYY年MM月
## 1. 本月总结
[2-3 段文字，提炼 4 周的核心成果，聚焦最终交付，去除过程细节]
## 2. 重点工作回顾
[按项目/目标维度归类 4 周的工作，避免简单堆砌]
### [核心目标 1]
- **目标**：[描述]
- **完成情况**：[最终交付物 + 验收结果]
- **主要里程碑**：[关键节点]
### [核心目标 2]
- **目标**：[描述]
- **完成情况**：[最终交付物 + 验收结果]
- **主要里程碑**：[关键节点]
## 3. 人效趋势分析
**完成率趋势**
[对比 4 周的完成率，识别改善或恶化趋势]
**延期率趋势**
[对比 4 周的延期率，分析是否改善]
**核心瓶颈演变**
[某些问题是否持续存在？是否有新问题出现？]
## 4. 下月工作计划
| 重点事项 | 负责人（建议） | 验收标准 | 预计完成时间 |
|---------|--------------|---------|------------|
| [事项1] | XXX | [明确标准] | XX月XX日 |
| ... | ... | ... | ... |
核心逻辑
本月总结：
- 提炼 4 周的最终成果，聚焦"交付了什么"，而非"做了什么"
- 示例：不要写"本月进行了 4 次模型选型测试"，而要写"本月完成模型选型，最终选定 GLM-4-9B 并完成下载"
重点工作回顾：
- 按项目/目标维度归类，而非按周堆砌
- 如果某个项目跨越了 4 周，合并为一条，只记录最终结果和关键里程碑
- 如果某周提到的事项在后续周报中消失了，标注"未完成/已取消"
人效趋势分析：
- 计算 4 周的完成率、延期率，绘制趋势
- 识别是否有持续存在的瓶颈（如"人手不足"连续 4 周出现）
- 判断团队状态是改善、稳定还是恶化
下月工作计划：
基于以下输入生成：
- 本月未完成事项：自动滚动到下月
- 本月暴露的问题：生成对应的改进计划（如"解决 XX 技术债""优化 YY 流程"）
- 用户提供的下月核心目标：生成对应的重点任务
- 人效趋势：如果延期率持续上升，建议"减少并行任务"或"增加资源"
输出 3-5 项重点计划，每项包含：目标、负责人（建议）、验收标准、预计完成时间
第六步：保存文件并输出
- 生成的周报/月报以 Markdown 格式直接在对话中展示
- 同时自动保存为文件：
- 周报：
部门周报_YYYY-MM-DD.md（当天日期） - 月报：
部门月报_YYYY-MM.md（当月）
- 周报：
- 告知用户文件保存位置
注意事项
关于"核心目标"的理解
用户提供的核心目标是筛选重点事项的唯一依据。如果某个工作做得很好，但与核心目标无关，也应归入附件。这不是否定该工作的价值，而是确保周报聚焦战略优先级。
关于验收标准的生成
自动生成的验收标准只是建议，需要标记 ⚠️ 待确认。告诉用户："建议与负责人确认这些验收标准是否合理，并在正式发布前修改。"
关于延期事项的处理
延期是常态，但必须有明确的应对方案。如果某个延期事项连续出现在多周周报中，且每次都缺少解决方案，在人效判断中特别指出："XX 事项已延期 N 周，建议重新评估优先级或调整资源。"
关于月报的生成
月报不是周报的简单堆砌。它应该：
- 抽象层级更高：从"完成了 XX 功能"提升到"达成了 XX 目标"
- 时间跨度更长：展示整个月的演进，而非 4 周的快照
- 战略价值更强：回答"这个月团队对公司的核心价值是什么"
错误处理
缺少姓名标识：
提示："未识别到成员姓名，请确保每个人的周报开头包含姓名（如'姓名：张三'）"
缺少分隔线：
尝试智能识别段落边界（如连续空行、明显的姓名模式），如果失败则提示："请在每个人的周报之间添加 --- 分隔符"
周报内容过少：
警告："XXX 的周报内容过少（仅 XX 字），可能影响部门周报质量"，但仍继续处理
月报缺少周次：
提示："检测到缺少第 X 周的周报（只有 Y 周数据），是否继续生成不完整月报？"等待用户确认后再继续
缺少核心目标：
提示："请提供公司核心目标，以便筛选重点事项。如果暂无明确目标，可以输入'通用'，我将根据工作重要性和影响范围进行判断。"
示例
输入示例（周报模式）
姓名：张三
本周技术部围绕智能体完整链路延迟目标进行工作。
上周 4 项重点任务中，完成 1 项、部分完成 2 项、延期 1 项。
当前智能体基础链路对话路径已跑通，但端到端响应时间约 7 秒，语音打断和恢复过慢导致本周版本不可用。
---
姓名：李四
完成响应延迟测试并输出完整延迟测试数据报告。
当前平均约 37 秒，部分场景达 5 秒，缺少 P95 数据。
---
核心目标：
1. 智能体完整链路延迟压缩到 3 秒之左右
2. 完成模型选型、下载模型
3. 多项需求已经上线
输出示例（周报）
# 部门周报 - 2024年3月第2周
## 1. 本周结论
本周技术部围绕智能体完整链路延迟目标推进工作。完成了延迟测试数据报告，延迟模型选型和下载，整体进度受阻于响应时间优化。
主要亮点：完成模型选型比较，已选取 GLM-4-9B 并完成下载。
主要问题：当前智能体端到端响应时间约 7 秒，语音打断和恢复过慢，本周版本不可用。下周需统一解决延迟问题，所有人围绕完整链路版本推进。
## 2. 重点工作
| 工作事项 | 上周承诺 | 实际结果 | 状态 | 原因与解决方案 |
|---------|---------|---------|------|--------------|
| 智能体完整链路 | 完成可验收版本 | 基础对话路径跑通，但端到端响应约 7 秒 ⚠️ 待确认：能在 3 秒内完成完整对话交互 | 延期 | 原因：各模块分别开发，缺乏统一的整体链路优化。解决方案：由技术负责人统一协调，周三前统一解决延迟问题，周三完成整路验收。负责人：张三、李四。新完成时间：周三 15:00 |
| 响应延迟测试 | 主要场景控制在 4 秒以内 | 平均约 37 秒，部分场景 5 秒 ⚠️ 待确认：包含 P95 值，P95 < 5 秒 | 部分完成 | ❌ 缺失：解决方案、新时间 |
| 模型选型 | 完成候选模型比较 | 已选取 GLM-4-9B 并完成下载 ⚠️ 待确认：通过至少 3 个模型的效果、成本和延迟评测 | 完成 | - |
## 3. 人效判断
**整体评估**
3 项重点任务中完成 1 项，延期 1 项，部分完成 1 项，整体交付节奏偏慢。
**主要瓶颈**
主要问题是端到端延迟优化不足，各模块独立开发导致整体链路未打通。当前响应时间远超目标（7 秒 vs 3 秒），影响用户体验。
**改进建议**
下周需由技术负责人统一协调，所有人围绕完整链路版本推进，避免各自为战。建议周三前完成统一延迟优化，确保端到端响应时间达标。
## 4. 下周工作
| 交付结果 | 负责人 | 验收标准 | 时间 |
|---------|-------|---------|------|
| 交付智能体完整链路验收版本 | 张三 | 产品可稳定连续体验 3 分钟，语音、打断、恢复和 APP 完整链路跑通验收 | 周三 15:00 |
| 输出完整响应延迟测试数据报告 | 李四 | 包含平均值、P95、最大值及各节点耗时 | 周二 18:00 |
| 完成模型初步选型进型报告 | 算法负责人 | 至少比较 3 个模型的效果、成本和延迟 | 周五 18:00 |
---
## 附件：日常工作清单
### 张三
- 日常例会参与
- 文档整理
### 李四
- 后端日常维护
- 代码 review
文件已保存至：部门周报_2024-03-15.md