项目全流程模板实战：从启动会议到年终总结的 8 阶段可复用模板

Mon, 15 Dec 2025 00:00:00 +0800

之前在项目全流程：瀑布式 7 阶段 + BRD/MRD/PRD 文档体系写过流程和方法论。但日常真正用得多的不是"流程怎么走"，而是**“启动会议纪要怎么写”、“需求调研清单长啥样”、“运维日报格式”**——这些可复用的具体模板。本篇把 8 个阶段的实战模板一次性整理好，下载即用。

本文写于 2025 年 12 月——站在行业角度，把 5+ 年项目实践中沉淀的"会议纪要 / 调研清单 / 设计模板 / 测试用例 / 运维报表 / 年终总结"全部公开。

阅读对象：项目经理、技术负责人、想统一团队文档规范的工程师 覆盖范围：8 阶段（启动 / 需求 / 设计 / 开发 / 测试 / 运维 / 日常 / 管理）实战模板，全部可直接套用

一、为什么需要模板

团队文档"五乱现象"：

乱格式：A 用 docx、B 用 md、C 用 wiki、D 写纸上
乱命名：“需求 v1.0”、“需求 v1.0(2)"、“需求-最终版”、“需求-最终版-真的不改了”
乱内容：该有的章节没有，不该写的写了一堆
乱责任人：会议纪要没人写 / 写了没人跟 / 跟了没结果
乱归档：项目结束找文档，散落在 5 个工具 10 个目录里

模板的价值：

团队成员看一眼就懂怎么写
格式统一便于归档检索
关键字段不遗漏（日期、责任人、deadline）
历史项目可对比——格式一致才能横向比较

二、阶段 1：启动阶段模板

2.1 启动会议纪要模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


# XX 项目启动会议纪要

## 基本信息
- **项目名称**：XX 业务系统
- **会议时间**：2025-XX-XX 14:00-16:00
- **会议地点**：XX 会议室 / 腾讯会议
- **会议主持**：XX（PM）
- **记录人**：XX
- **参会人员**：XX、XX、XX、XX（甲方）；XX、XX、XX（乙方）

## 项目背景
（一段话说明为什么要做这个项目，业务驱动是什么）

## 项目目标
1. 业务目标：覆盖 XX 场景，提升 XX 效率
2. 技术目标：高可用 XX%，日均处理 XX 单
3. 时间目标：2025 年 12 月 31 日前上线
4. 质量目标：P0/P1 缺陷 < X 个，P2 缺陷 < X 个

## 项目范围
### 包含（In Scope）
- 模块 A：XX 功能
- 模块 B：XX 功能
### 不包含（Out of Scope）
- 模块 C：（后期规划）
- 模块 D：（明确不做）

## 关键里程碑
| 阶段 | 时间 | 交付物 | 负责人 |
|---|---|---|---|
| 需求确认 | 2025-XX-XX | PRD 终稿 | XX |
| 概要设计 | 2025-XX-XX | 概要设计文档 | XX |
| 详细设计 | 2025-XX-XX | 详细设计文档 | XX |
| 开发完成 | 2025-XX-XX | 可测试版本 | XX |
| 系统测试 | 2025-XX-XX | 测试报告 | XX |
| UAT 验收 | 2025-XX-XX | UAT 报告 | XX |
| 正式上线 | 2025-XX-XX | 上线报告 | XX |

## 资源分配
- **产品**：XX
- **前端**：XX、XX
- **后端**：XX、XX
- **测试**：XX
- **运维**：XX
- **设计**：XX

## 风险评估
| 风险项 | 等级 | 应对措施 | 负责人 |
|---|---|---|---|
| XX 人员变动 | 高 | 提前知识共享 | XX |
| 第三方接口不稳定 | 中 | 提前 mock 联调 | XX |
| 客户需求变更 | 高 | 走变更控制流程 | XX |

## 沟通机制
- **日站会**：每天 9:00-9:15（钉钉会议）
- **周例会**：每周一 14:00-15:00
- **月例会**：每月最后一个周五
- **紧急沟通**：钉钉 / 微信

## 遗留问题
- [ ] XX 接口文档待客户提供
- [ ] XX 流程待 XX 确认

---

**下次会议**：2025-XX-XX 14:00

2.2 启动会议检查清单

1
2
3
4
5
6
7
8


启动会议必答 7 问：
1. 项目目标是？（业务 / 技术 / 时间 / 质量）
2. 项目范围是？（in / out）
3. 关键里程碑是？（按阶段列）
4. 资源是否到位？（人员 / 设备 / 预算）
5. 风险预判是？（3-5 个 top 风险）
6. 沟通机制是？（日 / 周 / 月 / 紧急）
7. 客户方对接人是？（PM / 业务 / 技术）

三、阶段 2：需求阶段模板

3.1 需求调研清单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


# XX 模块需求调研清单

## 一、业务背景
1. 当前痛点是什么？
 - 问题 1：XX
 - 问题 2：XX
2. 业务目标是什么？
 - 提升 XX 效率
 - 降低 XX 成本
3. 关键指标（KPI）？
 - 订单处理时间从 5 分钟降到 30 秒
 - 错误率从 2% 降到 0.1%

## 二、用户角色
| 角色 | 描述 | 关键诉求 |
|---|---|---|
| 管理员 | 系统配置 | 简单配置界面 |
| 操作员 | 日常业务 | 流程清晰 |
| 审计员 | 事后审计 | 完整日志 |

## 三、核心场景
### 场景 1：XX 操作
1. 用户：操作员
2. 入口：XX 页面
3. 流程：步骤 1 → 步骤 2 → 步骤 3
4. 成功结果：XX
5. 失败处理：XX

### 场景 2：XX 操作
...

## 四、功能性需求
### FR-001：XX 功能
- 描述：用户可以在 XX 页面 XX 操作
- 优先级：P0
- 验收标准：
 - [ ] 步骤 1 成功
 - [ ] 步骤 2 成功
 - [ ] 异常情况正确处理

## 五、非功能性需求
- 性能：QPS ≥ 1000，RT ≤ 200ms
- 可用性：99.9%
- 安全性：通过等保三级
- 兼容性：Chrome / Edge / Safari 最新版

## 六、约束条件
- 必须对接 XX 已有系统
- 必须使用 XX 技术栈
- 数据库必须用 MySQL 8.0

## 七、待澄清问题
- [ ] XX 业务规则待客户确认
- [ ] XX 字段定义待 XX 提供

3.2 BRD / MRD / PRD 模板速查

文档	受众	重点	模板要点
BRD（Business Requirements Document）	高管 / 业务方	为什么要做、ROI 多少	业务背景、商业价值、投入产出
MRD（Market Requirements Document）	产品 / 市场	市场分析、竞品对比	市场规模、竞品分析、差异化
PRD（Product Requirements Document）	开发 / 测试	具体做什么、怎么做	用户故事、流程图、原型、字段定义

四、阶段 3：设计阶段模板

4.1 概要设计文档

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101


# XX 系统概要设计说明书

## 1. 引言
### 1.1 编写目的
本文档描述 XX 系统的概要设计方案，作为详细设计、开发和测试的依据。

### 1.2 背景
- 系统名称：XX
- 任务提出者：XX
- 开发者：XX
- 用户：XX

### 1.3 参考资料
- 《XX 系统需求规格说明书》v1.0
- 《XX 项目启动会议纪要》

### 1.4 术语定义
- SaaS：软件即服务
- SLA：服务等级协议

## 2. 设计概述
### 2.1 任务和目标
实现 XX 功能，满足性能 / 可靠性 / 扩展性要求。

### 2.2 运行环境
- 服务器：CentOS 7.6 / Ubuntu 22.04
- 中间件：Nginx / Tomcat / MySQL / Redis / Kafka
- 编程语言：Java 17

### 2.3 条件与限制
- 必须兼容 XX 老系统
- 不能使用商业数据库
- 项目周期 6 个月

## 3. 系统详细需求分析
### 3.1 功能需求
| 编号 | 名称 | 优先级 | 描述 |
|---|---|---|---|
| FR-001 | 用户登录 | P0 | 用户名密码登录 |
| FR-002 | 订单创建 | P0 | 创建新订单 |
| FR-003 | 报表导出 | P1 | 导出 Excel |

### 3.2 性能需求
- 峰值 QPS：5000
- 平均 RT：≤ 200ms
- 数据库响应：≤ 50ms

## 4. 总体方案确认
### 4.1 系统总体结构
![系统架构图]

分层：
- 接入层：Nginx + SLB
- 网关层：Spring Cloud Gateway
- 业务层：Spring Boot 微服务
- 数据层：MySQL + Redis + ES

### 4.2 系统详细界面划分
- 前端：Web（H5） + 小程序 + 移动 App
- 后端：API 服务 + 后台管理系统

## 5. 系统详细设计
### 5.1 系统结构设计
**微服务划分**：
- user-service（用户中心）
- order-service（订单中心）
- payment-service（支付中心）
- notification-service（消息中心）
- gateway-service（API 网关）

### 5.2 系统功能模块详细设计
（采用 HIPO 图分解模块）

### 5.3 模块接口设计
- order-service → payment-service：HTTP REST
- order-service → notification-service：Kafka 消息
- user-service → order-service：gRPC

## 6. 数据库系统设计
### 6.1 数据库选型
- 主库：MySQL 8.0（InnoDB 引擎，utf8mb4）
- 缓存：Redis 7.0
- 搜索：Elasticsearch 8.x

### 6.2 数据库 ER 图
![ER 图]

### 6.3 核心表结构
```sql
CREATE TABLE `t_order` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `order_no` varchar(32) NOT NULL COMMENT '订单号',
 `user_id` bigint(20) NOT NULL,
 `amount` decimal(10,2) NOT NULL,
 `status` tinyint(4) NOT NULL DEFAULT '0',
 `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
 `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (`id`),
 UNIQUE KEY `uk_order_no` (`order_no`),
 KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

7. 接口设计

（详见《接口设计文档》）

8. 性能设计

读写分离：主库写 / 从库读
分库分表：orders 表按 user_id 哈希 64 张
缓存：热点数据 Redis 缓存
消息队列：异步任务用 Kafka

9. 安全设计

鉴权：JWT Token
数据传输：全站 HTTPS
密码加密：BCrypt
敏感数据：脱敏存储 / 脱敏展示
防 SQL 注入：MyBatis 参数化
防 XSS：前端转义 + 后端过滤
防 CSRF：Token 机制

10. 部署设计

部署方式：Kubernetes
副本数：每个微服务 ≥ 3 副本
自动扩缩容：CPU > 70% 扩容，< 30% 缩容

11. 监控设计

业务监控：Prometheus + Grafana
链路追踪：SkyWalking
日志聚合：Loki / ELK
告警：钉钉 / 邮件 / 飞书

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32



### 4.2 详细设计文档（关键模块）

**只对核心模块做详细设计**（用户量大 / 业务复杂 / 风险高的）：

```markdown
# 订单创建详细设计

## 1. 模块编号
MODULE-ORDER-CREATE-001

## 2. 模块名称
订单创建

## 3. 输入
- 用户 ID
- 商品列表（SKU + 数量）
- 收货地址
- 优惠码（可选）
- 支付方式

## 4. 处理
1. 参数校验
2. 风控检查（防刷单）
3. 库存预占（Redis DECR）
4. 价格计算
5. 订单写入（事务）
6. 库存扣减（异步）
7. 消息发送（Kafka）

## 5. 算法描述
### 5.1 库存预占算法

查 Redis 库存：GET stock:sku:{skuId}
检查库存 ≥ 请求数量
扣减：DECRBY stock:sku:{skuId} {qty}
设置预占标记：SET prehold:order:{orderId} {skuId}:{qty} EX 600
失败回滚：INCRBY stock:sku:{skuId} {qty}

1
2

### 5.2 价格计算

总价 = sum(商品单价 × 数量) 优惠 = 满减 + 优惠券 + 会员折扣实付 = max(总价 - 优惠, 0.01)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17



## 6. 输出
- 成功：order_no, pay_url, expire_at
- 失败：错误码 + 错误信息

## 7. 异常处理
| 异常 | 处理 |
|---|---|
| 库存不足 | 释放预占 + 提示 |
| 用户风控 | 拒绝 + 记录日志 |
| 支付失败 | 30 分钟内可重试 |
| 系统异常 | 全局回滚 + 告警 |

## 8. 性能指标
- 期望 QPS：1000
- RT 目标：≤ 200ms
- 99 线：≤ 500ms

五、阶段 4：开发阶段模板

5.1 Git Commit 规范

1
2
3
4
5


<type>(<scope>): <subject>

<body>

<footer>

type 必填：

feat：新功能
fix：修复 bug
docs：文档
style：代码格式（不影响逻辑）
refactor：重构
perf：性能优化
test：测试
chore：构建 / 工具

示例：

1
2
3
4
5
6
7
8


feat(order): 支持拼团订单创建

新增拼团业务逻辑：
- 拼团订单写入独立表 t_group_buy
- 拼团成功后批量更新普通订单
- 失败时 24h 自动退款

Closes #123

5.2 Code Review 检查清单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Code Review Checklist：
- [ ] 代码符合团队规范（命名 / 格式 / 注释）
- [ ] 没有重复代码（DRY）
- [ ] 函数 / 类职责单一（SRP）
- [ ] 关键路径有日志
- [ ] 异常处理正确
- [ ] 单元测试覆盖
- [ ] SQL 性能（避免 SELECT * / 避免 N+1）
- [ ] 安全（SQL 注入 / XSS / 越权）
- [ ] 配置外化（不硬编码）
- [ ] 文档 / 注释更新

5.3 提测清单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# XX 模块提测清单

## 提测信息
- **模块名称**：XX
- **提测版本**：v1.0.0
- **提测人**：XX
- **提测时间**：2025-XX-XX
- **测试人**：XX
- **预计测试时间**：3 天

## 提测内容
### 新功能
1. 用户登录（FR-001）
2. 订单创建（FR-002）
3. 报表导出（FR-003）

### 修复 Bug
1. 修复 #123 订单重复创建
2. 修复 #456 库存显示错误

## 已知问题
- [ ] 性能未优化
- [ ] 国际化未完成

## 配置文件
- 数据库：10.0.1.100:3306 / order_db
- Redis：10.0.1.101:6379
- 测试账号：test / {{TEST_PASS}}

## 提测说明
- 部署地址：https://test.example.com
- 源码地址：https://git.example.com/order-service
- 接口文档：https://wiki.example.com/api/order

六、阶段 5：测试阶段模板

6.1 测试用例模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


# XX 模块测试用例

## TC-001：用户登录成功
- **模块**：用户中心
- **优先级**：P0
- **前置条件**：存在账号 test@example.com / {{PWD}}
- **步骤**：
 1. 打开登录页
 2. 输入邮箱 test@example.com
 3. 输入密码
 4. 点击"登录"
- **期望**：跳转到首页，显示用户名

## TC-002：用户登录密码错误
- **模块**：用户中心
- **优先级**：P0
- **前置条件**：存在账号 test@example.com
- **步骤**：
 1. 打开登录页
 2. 输入邮箱 test@example.com
 3. 输入错误密码 "wrong"
 4. 点击"登录"
- **期望**：提示"密码错误"，不跳转

## TC-003：用户登录连续 5 次失败
- **模块**：用户中心
- **优先级**：P1
- **前置条件**：账号未被锁定
- **步骤**：
 1. 连续 5 次输入错误密码
- **期望**：账号被锁定 30 分钟，提示"账号已锁定"

6.2 缺陷报告模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# 缺陷报告 #001

## 缺陷信息
- **标题**：订单提交后未生成订单号
- **模块**：订单中心
- **严重程度**：P0（阻塞主流程）
- **优先级**：紧急
- **发现人**：XX
- **发现时间**：2025-XX-XX
- **指派人**：XX

## 复现步骤
1. 登录账号 test@example.com
2. 选择商品 A 加入购物车
3. 点击"提交订单"
4. 查看订单列表

## 期望结果
订单列表中应该有一个新订单，订单号 = "OD20250315001"

## 实际结果
订单列表为空，控制台报 500 错误

## 截图
[图：500 错误]

## 错误日志

java.lang.NullPointerException at OrderService.createOrder:124

1
2
3
4



## 修复建议
OrderService.createOrder 第 124 行：orderNoGenerator.generate() 返回 null，
可能是 Redis 连接失败导致 ID 生成器初始化失败

6.3 性能测试报告模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# XX 系统性能测试报告

## 测试信息
- **测试时间**：2025-XX-XX
- **测试人**：XX
- **测试工具**：JMeter 5.5 / wrk
- **测试环境**：生产等配（4 核 8G × 3 节点）

## 测试场景
### 场景 1：登录接口
- 并发：100
- 持续时间：5 分钟
- 期望 RT：≤ 200ms
- 期望 QPS：≥ 500

## 测试结果
| 指标 | 实测 | 期望 | 结论 |
|---|---|---|---|
| 平均 QPS | 680 | ≥ 500 | ✅ |
| 平均 RT | 145ms | ≤ 200ms | ✅ |
| P99 RT | 320ms | ≤ 500ms | ✅ |
| 错误率 | 0.02% | ≤ 0.1% | ✅ |

## 性能瓶颈
1. 数据库连接池不够（100 并发只够 50）
 - 优化：调大 hikariCP.maximumPoolSize=200
2. Redis pipeline 未用
 - 优化：批量操作改用 pipeline

## 优化建议
1. 引入 Redis 缓存（首屏加载提速 50%）
2. 数据库读写分离
3. 接口合并（10 个接口合并成 1 个）

七、阶段 6：运维阶段模板

7.1 运维日报模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


# 运维日报 - 2025-XX-XX

## 值班信息
- **值班人**：XX
- **值班时间**：00:00-24:00
- **联系方式**：{{PHONE}}

## 系统状态
- **整体状态**：✅ 正常
- **核心服务**：✅ 正常
- **数据库**：✅ 正常（主从延迟 0.5s）
- **缓存**：✅ 正常
- **消息队列**：✅ 正常（积压 0）

## 业务指标
- **日活用户**：10.2 万（环比 +5%）
- **订单数**：3.5 万（环比 +8%）
- **支付金额**：{{AMOUNT}}（环比 +12%）
- **接口 QPS**：平均 1200，峰值 3500
- **错误率**：0.05%

## 告警记录
| 时间 | 内容 | 等级 | 处理人 | 状态 |
|---|---|---|---|---|
| 14:23 | 订单接口 RT 飙升至 800ms | P1 | XX | 已处理 |
| 18:30 | Redis 内存使用 75% | P2 | XX | 监控中 |

## 变更操作
- 10:00 XX 服务发版 v1.2.3（XX 提交）
- 15:30 扩容 order-service 副本数 3→5

## 待办事项
- [ ] XX 数据库主从延迟监控告警规则待优化
- [ ] XX 证书下月到期需续期

## 明日计划
- 03:00 订单服务滚动发版
- 09:00 XX 项目联调

7.2 故障报告模板（Postmortem）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


# 故障复盘报告 - 2025-XX-XX XX 故障

## 故障信息
- **故障名称**：XX 服务不可用
- **故障时间**：2025-XX-XX 14:30 - 15:45（持续 75 分钟）
- **影响范围**：XX 功能不可用，影响 XX 用户
- **业务影响**：订单损失 {{AMOUNT}}
- **故障等级**：P0

## 时间线
| 时间 | 事件 | 操作人 |
|---|---|---|
| 14:30 | 告警：订单服务 RT > 5s | 系统 |
| 14:35 | 值班人介入 | XX |
| 14:40 | 确认数据库连接池耗尽 | XX |
| 14:50 | 重启 order-service，临时恢复 | XX |
| 15:00 | 再次告警，确认是 Redis 大 Key 阻塞 | XX |
| 15:20 | 删除大 Key，服务恢复 | XX |
| 15:45 | 监控观察 15 分钟无异常 | XX |

## 根因分析
订单服务依赖 Redis 中的用户信息缓存，**XX 业务在 14:00 写入了一个 1.2GB 的大 Key**（单用户订单数据），**导致 Redis 单线程阻塞**。

**根因**：
- 业务代码 **未对写入数据做大小限制**
- 监控未对 Redis 大 Key 告警

## 改进措施
| 措施 | 负责人 | Deadline |
|---|---|---|
| Redis 写入数据大小限制（< 1MB） | XX | 2025-XX-XX |
| 监控增加 Redis 大 Key 告警（> 100MB） | XX | 2025-XX-XX |
| 业务代码评审增加"单 Key 大小"检查项 | XX | 长期 |
| 数据库连接池按业务分级 | XX | 2025-XX-XX |

## 经验教训
- **缓存不是万能的**：写入也可能拖慢服务
- **大 Key 是定时炸弹**：必须监控 + 限制
- **告警覆盖要全**：不能只看 QPS / RT，**也要看数据本身**

7.3 上线变更单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


# 上线变更单 - 2025-XX-XX

## 变更信息
- **变更标题**：XX 服务发版 v1.2.3
- **变更类型**：功能发布
- **申请人**：XX
- **审核人**：XX
- **变更时间**：2025-XX-XX 02:00-04:00
- **影响范围**：XX 模块 / XX 接口

## 变更内容
- 新增 XX 功能（需求 #123）
- 修复 XX bug（缺陷 #456）
- 性能优化 XX（压测提升 20%）

## 变更步骤
1. [ ] 备份当前版本配置
2. [ ] 滚动发版 order-service:v1.2.3
3. [ ] 健康检查（30s 内）
4. [ ] 关键接口冒烟测试
5. [ ] 监控观察 1 小时
6. [ ] 关闭变更工单

## 回滚方案
- 命令：`kubectl rollout undo deployment/order-service`
- 数据回滚：本次无 DDL，无需数据回滚
- 预计回滚时间：5 分钟

## 风险评估
| 风险 | 等级 | 应对 |
|---|---|---|
| 新版本引入 bug | 中 | 1 小时监控窗口 |
| 缓存击穿 | 低 | 限流保护 |
| 第三方接口超时 | 低 | 重试 3 次 |

## 审批
- [ ] 申请人：XX
- [ ] 审核人：XX
- [ ] 运维：XX
- [ ] PM：XX

八、阶段 7：日常阶段模板

8.1 周报模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# XX 周报 - 第 XX 周（2025-XX-XX ~ 2025-XX-XX）

## 本周完成
- ✅ XX 模块开发完成
- ✅ XX 接口联调通过
- ✅ 修复 XX bug（#123, #456）

## 下周计划
- [ ] XX 模块开发
- [ ] XX 模块联调
- [ ] XX 模块提测

## 风险与问题
1. **XX 接口响应慢**（P1）
 - 现象：RT 800ms
 - 影响：用户投诉
 - 进展：已定位是数据库慢 SQL，索引待加
2. **XX 人员变动**
 - XX 同学下月离职
 - 需要招人 / 知识共享

## 数据指标
- 需求完成率：60%（12/20）
- 缺陷修复率：80%（16/20）
- 代码提交：32 commits

8.2 月报模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


# XX 项目月报 - 2025 年 XX 月

## 项目总览
- **项目阶段**：开发 / 测试 / 试运行
- **整体进度**：60%（计划 65%）
- **风险等级**：中

## 本月里程碑
| 里程碑 | 计划 | 实际 | 偏差 |
|---|---|---|---|
| 需求确认 | 04-15 | 04-18 | +3 天 |
| 概要设计 | 04-30 | 04-30 | 准时 |
| 详细设计 | 05-15 | 进行中 | - |

## 关键指标
- 需求完成：30 / 50（60%）
- Bug 修复：40 / 50（80%）
- 代码提交：120 commits
- 联调通过：15 / 20（75%）

## 资源投入
- **开发**：12 人 × 22 天
- **测试**：3 人 × 10 天
- **运维**：2 人 × 5 天

## 主要问题
1. **第三方接口不稳定**：
 - 现象：调用 XX 接口超时率 10%
 - 应对：已加超时重试 + 降级方案
2. **人员不足**：
 - 后端缺 1 人
 - 已启动招聘

## 下月计划
- 完成全部 50 个需求开发
- 完成系统测试
- UAT 启动

九、阶段 8：管理阶段模板

9.1 部门年终总结模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


# 2025 年部门年终总结

## 一、项目完成情况
- **总数**：本年完成 15 个大型项目 + 20 个小型项目
- **按时交付率**：70%
- **延期率**：20%（平均延期 15 天）
- **取消率**：10%

### 重点项目
1. **项目 A**（XX 客户 ERP）
 - 按时交付，质量达标，客户非常满意
 - 难点：数据迁移 + 系统集成
2. **项目 B**（零售电商）
 - 因需求变更延期 1 个月交付
 - 客户最终满意
3. **项目 C**（移动应用）
 - 按时交付，后期性能问题已优化

## 二、团队绩效
- **人员规模**：XX 人（年初 X → 年末 X）
- **代码提交**：平均 +15%
- **Bug 率**：下降 10%
- **培训**：组织 XX 次技术分享
- **新工具引入**：Jira / Confluence / 飞书

## 三、技术创新
- **微服务架构**：覆盖 XX 项目
- **云原生**：K8s / Docker 全栈
- **AI 应用**：XX 场景
- **数据库**：升级到 MySQL 8.0

## 四、客户反馈
- **正面**：85% 客户表示满意
- **负面**：高峰期响应慢（已修复）
- **NPS 评分**：8.5/10

## 五、问题与不足
1. 需求变更管理不规范
2. 测试覆盖度不够
3. 文档沉淀不足
4. 跨部门协作效率低

## 六、明年规划
- **项目管理**：引入敏捷 + Scrum
- **技术创新**：AI / 区块链深入
- **团队建设**：技术培训 + 文化建设
- **客户管理**：满意度提升到 90%

9.2 个人年终总结模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# 2025 年个人年终总结 - XX

## 一、本人工作
### 项目贡献
- 项目 A：负责 XX 模块，**提前 1 周交付**
- 项目 B：解决 XX 难题，**节省 XX 工时**
- 项目 C：性能优化，**QPS 提升 3 倍**

### 技术成长
- 学习 XX 技术栈
- 主导 XX 方案设计
- 输出 XX 篇技术文档

## 二、绩效数据
- 需求完成：XX 个（超出 XX%）
- 代码质量：Bug 率 < 1%
- 团队贡献：带新人 XX 名

## 三、问题反思
- XX 决策考虑不周
- XX 沟通效率低
- XX 技术深度不够

## 四、明年规划
- **业务**：承接更重要项目
- **技术**：深入 XX 领域
- **管理**：带 XX 人小团队
- **学习**：XX 认证 / 培训

十、模板使用建议

10.1 不要"全用”

小项目（< 1 个月）：只需要周报 + 提测清单
大项目（> 3 个月）：全流程模板都用
个人开发者：只需要 git commit + 周报

10.2 模板要"活"用

格式可以微调（但保留关键字段）
章节可以根据项目裁剪（但不要全删）
结合团队实际情况（但不要"无中生有"）

10.3 模板要"持续迭代"

每季度 review 一次
收集"用得不顺"的地方
改进后通知全员

10.4 模板要"轻量"

不要追求完美格式——能用就行
不要堆砌图表——数据 > 形式
不要写大段废话——说人话

十一、配套工具推荐

工具	用途	模板
语雀	知识库 / 文档	概要设计、需求、复盘
Confluence	团队 Wiki	启动会议、设计、决策记录
飞书 / 钉钉	沟通 / 审批	周报、日报、变更单
Notion	文档 + 数据库	需求跟踪、缺陷管理
Jira / 禅道	需求 / 任务	需求、Bug、Sprint

生产推荐组合：

小型团队：语雀 + 钉钉 + GitHub Issues
中大型团队：Confluence + Jira + 飞书 / 钉钉
外企 / 国际化：Notion + Linear + Slack

十二、最佳实践清单

所有文档放同一处——避免散落
关键字段必填——日期 / 责任人 / 状态
会议纪要 24h 内发出——避免遗忘
周报同一天提交——建立节奏
故障复盘 1 周内完成——趁热打铁
缺陷 / 需求有唯一编号——可追溯
模板持续迭代——每年 review 一次
配合自动化——CI/CD / 监控减少手写
重要文档双语——外企必备
历史归档——项目结束后 1 年内可查

十三、与其他阶段的衔接

当前模板	产出	下一阶段模板
启动会议	目标 / 范围 / 里程碑	需求调研
需求调研	PRD / 用户故事	概要设计
概要设计	系统架构 / 接口	详细设计
详细设计	模块设计 / 算法	提测清单
提测清单	测试范围	测试用例
测试用例	用例 / 缺陷	性能测试
性能测试	性能指标	上线变更
上线变更	上线操作	运维日报
运维日报	每日状态	月报 / 年终

形成闭环：每个阶段的输出是下个阶段的输入。

下一步

想看 项目全流程 7 阶段方法论（瀑布式）→ 项目全流程：瀑布式 7 阶段
想看 架构设计基础（概要 vs 详细）→ 架构设计基础
想看 敏捷开发协作（22 款 CI 工具）→ 敏捷开发协作
想看 JDK 自建镜像实战（容器化基础）→ JDK 自建镜像实战

2024+ 视角（模板升级：从静态文档到 AI + 工具链）

2025 年写的 8 阶段模板，在 2024-2026 年的"AI 时代"有几条升级路径：

AI 辅助生成阶段物：
- LLM 拆解用户故事：粘贴 PRD 一段，AI 自动拆成 N 个 Story + 验收标准 + 边界用例
- AI 生成测试用例：给定接口契约，AI 自动出 50+ 用例（正常 / 异常 / 边界 / 安全）
- AI 评审代码 / ADR：Copilot Review / Coderabbit 自动给 PR 提建议
模板从 Word 转向 Wiki + LLM Prompt：
- 启动会议纪要 → Notion / 飞书模板 + LLM 摘要
- 概要设计 → Mermaid + ADR + Confluence
- 测试用例 → 表格化 + 自动同步到 TestRail / Zentao
协作工具栈推荐（2024-2026）：
- 小团队（< 10 人）：Notion + Linear + Slack + GitHub
- 中大型（10-100 人）：Confluence + Jira + 飞书 + GitLab
- 外企/国际化：Notion + Linear + Slack + GitHub Enterprise
绩效数据自动化：
- Jira / Linear 自动统计：Story 完成率、Bug 修复率、PR 数、Code Review 数
- GitLab / GitHub 统计：commit 数、loc、活跃时间
- Sentry / Datadog 统计：故障率、MTTR
LLM 时代的新模板：
- Prompt 库模板：每个阶段都沉淀"经过验证的 Prompt"
- Agent 工作流模板：需求 Agent + 设计 Agent + 测试 Agent 的协作模板
- 知识库 RAG 模板：把团队历史文档喂给向量库，新人提问直接得到历史答案
SRE 化运维日报：
- 2025 年的运维日报已经不需要人手写——Prometheus + Grafana + ChatOps 自动汇总
- 模板保留，但使用频率下降到周/月级别
AIGC 时代的"反模板"提醒：
- 模板能提升下限，但会扼杀创新——小项目/创新业务别套全模板
- AI 生成的文档必须人工 review——LLM 会"自信地胡说"
- 关键决策必须有 ADR——不能被模板/AI 替代

核心升级逻辑：模板的"格式统一"价值在 2024 年依然存在，但"内容生成"价值已经被 AI 接管——团队需要把精力从"写文档"转向"评审文档 + 决策 + 沉淀知识"。这也是 2024+ 项目管理最大的范式转移。

运维日报 on Liangweidong's blog