项目管理 on Liangweidong's blog

项目全流程概述：从启动到运维的七阶段方法论

Sun, 15 Mar 2026 00:00:00 +0800

背景：这是一份 2008 年整理的"瀑布式软件项目"全流程方法论。本文写于 2026 年 3 月——站在 18 年后再回看，它定义了中文 IT 行业最经典的角色分工、阶段物、评审机制。大多数中型项目的"项目管理"模板，至今仍是这套骨架。

一、为什么 2026 年还要读瀑布流

也许你会问：都 2026 年了（距离 2008 年这份方法论已经 18 年），谁还用瀑布流？

事实上，瀑布流仍然是强约束、弱变更、合规优先项目的首选——政府/国企/医疗/工业软件。这些项目里：

需求一次性评审拍板，改一次合同 = 改一次报价
阶段物是审计/验收的依据（BRD、MRD、PRD、需求规格、概要设计……少一份不签字）
角色边界清晰：产品经理、研发项目经理、研发工程师、测试工程师，谁负责什么、产物是什么、有没有评审，全部白纸黑字

When to use：当你的项目周期 ≥ 3 个月、参与方 ≥ 3 个（含客户/监理/外部审计）、变更成本极高时，这套流程就是底座。敏捷会在它的某些阶段上叠加，但不会取代。

二、流程全景（7 阶段）

阶段	关键角色	核心产物	评审机制
0 启动	产品经理、研发项目经理、客户/上级	会议纪要、研发周报、需求调研、业务梳理	启动会评审
1 需求	产品经理、研发工程师	产品原型、业务流程图、里程碑、任务分解、概要需求	需求评审会
2 设计	UI 设计师、研发工程师	界面效果图、UI 规范、需求规格、概要设计、通讯协议、表结构	设计评审会
3 开发	研发工程师	源代码、技术预研报告、功能评审记录	功能评审
4 测试	测试工程师、研发工程师	测试实例、测试结果报告、操作手册、维护手册	测试报告评审
5 运维	运维工程师、研发工程师	上线方案、监控配置、应急预案	上线评审
6 日常	全员	周报、月报、培训记录	部门例会
7 管理	部门负责人	考核指标、绩效系数、年度总结	部门评审

Tip：从"启动 → 日常/管理"是横向的 7 个阶段，每个阶段都有输入 / 处理 / 输出 / 评审四件套。少一个，流程就不闭环。

三、阶段 0：项目启动

启动阶段是"把人和事定下来“的阶段。关键动作：

确定项目方向——产品经理和项目干系人对齐。干系人包括：
- 产品型项目：公司领导、产品总监、技术总监
- 客户型项目：客户方领导、主要执行人
组建项目组——研发项目经理、研发工程师、测试团队
建立项目管理制度：
- 每阶段评审必须有《会议纪要》
- 启动起研发项目经理每周提供《项目研发周报》
- 测试阶段测试工程师每周提供《项目测试周报》
需求调研——产品经理输出《需求调研》文档，方法主要是背景资料调查 + 访谈
业务梳理——四步法：
- 明确项目目标
- 梳理项目涉及的角色
- 每个角色要做的事项
- 划分端口、模块、功能

常见坑：启动会只发个通知就开始写代码，没产出物。结果需求阶段返工、设计阶段推翻，项目结束时成本是预算的 1.5-2 倍。

四、阶段 1：需求阶段

需求阶段是”把业务画出来“的阶段。关键动作：

产品原型——产品经理提供最简单也最接近成品的原型，线框图形式。还会产出：
- 业务流程图：不同节点不同角色的操作
- 页面跳转流程图：界面之间的跳转关系
需求讲解——产品经理面向整个团队宣讲
项目里程碑——研发项目经理根据需求明确《项目里程碑》
产品开发计划——明确详细阶段时间点
项目任务分解——把工作包拆到人/天
概要需求——研发工程师按分工初步理解业务，评估技术可行性

4.1 文档层次：BRD / MRD / PRD

在更大的组织里，需求阶段会按三个层次产出文档：

文档	回答的问题	受众
BRD（Business Requirement Document）	商业论证：要不要做？	决策层
MRD（Market Requirements Document）	市场需求：如何做能赚钱？	产品/运营/市场/研发
PRD（Product Requirement Document）	产品需求：做成什么样？	研发/测试/交互

Why 三层：

外包项目：甲方出 BRD+MRD，乙方对接出 PRD / 需求分析报告 / 需求规格说明书

自研项目：业务部门出 BRD+MRD，产品经理出 PRD，项目经理出需求分析报告，研发经理出需求规格说明书

BRD 的 5 大块：研发背景、可行性分析、产品规划、商业模式、投资与收益、风险及对策。

PRD 的核心：产品概述、产品框架、数据需求、功能性需求、非功能性需求、系统上线需求。

五、阶段 2：设计阶段

设计阶段是”把业务变成可实现的图纸"。关键动作：

界面效果图 + UI 设计规范——UI 设计师输出，标注每个控件尺寸；规范统一字号、间距、按钮尺寸
需求规格——研发工程师基于界面效果图输出，包含最终要实现的一切要素
概要设计——模块划分、接口定义、数据结构
通讯协议——前后端、客户端与服务端的接口约定
表结构设计——数据库 schema

5.1 概要设计的两个误区

Tip：概要设计阶段最常踩的两个坑：

❌ 过于重视业务流程（应该画图、不该写流程）

❌ 过于重视细节实现（应该定接口、不该写算法）

5.2 概要设计的标准结构

一份合格的概要设计应当覆盖以下内容（顺序自上而下）：

原则——评价总体设计的可行性、检查模块是否完整、评估开发工作量
总述——需求或目标、环境、局限
总体设计——组织结构、功能、处理流程、模块、模块间关系、运行环境（输出：系统结构图、系统流程图、数据流程图）
外部接口——外部用户、软硬件接口
模块设计——每个模块"做什么"、“怎么做”、逻辑位置、物理位置
数据结构——逻辑结构、物理结构
容灾设计——出错信息、出错处理
监控设计——运行模块组合、控制、时间
用户界面设计
安全设计
其它设计
制定规范——设计原则、代码规范、接口规约、命名规则

六、阶段 3：开发阶段

编码阶段看似就是"写代码"，实际包含：

技术预研——对关键技术点做 POC
需求确认——编码中发现需求模糊点，反查需求
联调——服务端、移动端、外部系统的联调
功能评审——编码完成后团队过一遍

2026 年补充：18 年后回看，“技术预研"这一步在当下分布式 / 大模型 / 云原生环境下变得比 2008 年更重要——选错技术栈，不是返工 1 周的问题，是整条技术债要背 3-5 年。

七、阶段 4：测试阶段

测试是”证明系统符合规格“的阶段。关键动作：

测试实例——按阶段设计，未通过的提交至 Jira 分配给开发
修改回归——研发改完重新提交测试
测试结果报告——功能测试结果、压力测试结果
操作手册 / 维护手册——每个端口都要写

Tip：测试实例的设计要兼顾正常流程 + 异常流程 + 边界条件。只测正常流程，上线后必出生产事故。

八、阶段 5：系统上线

与客户/上级达成一致后，系统进行试运行，稳定后上线。

试运行期通常 2-4 周，验证：

数据迁移正确性
性能指标（响应时间、并发量、错误率）
业务流程跑通
备份/恢复演练

九、阶段 6 & 7：日常与管理

日常阶段是”项目结束后的运维期"，包括：

故障响应
用户反馈处理
小版本迭代
数据备份与恢复

管理阶段是"对人评价“的阶段，考核指标包括：

工作态度
软件质量（bug 等级/个数、回归次数、重要模块系数）
工作难易度（功能性、可靠性、易用性、高效性、可维护性、可移植性、功能点数、复杂度）
工作效率/能力（完成百分比、工作经验）
主动性
沟通能力
程序规范程度

9.1 程序规范程度的 5 级评估

文档编写的及时性和可查阅性，按滞后天数分 5 级：

等级	描述	滞后天数
1	非常及时，随意可查阅	0 天
2	非常规范，较及时，可查阅近期文档	≤ 3 天
3	较规范，较及时，一般可查阅近期文档	3-6 天
4	较规范，不及时，常难查阅	≥ 6 天
5	不规范，不及时，常难查阅甚至无文档	—

9.2 绩效系数参考

绩效分	绩效系数	备注
≥ 100	1.3	超出预期
95 - 99	1.15	略超预期
85 - 94	1.0	达标

十、核心 5 点提炼

阶段物是法律证据——所有评审、纪要、文档、报告都是项目结束时对账/审计/验收的依据。少一份都可能卡付款。
角色边界必须清晰——产品/研发/测试/运维，谁负责什么产物，谁有最终签字权，提前在启动会定清楚。
变更必须走流程——需求变更单、技术变更单、紧急变更单，没有单子不动代码。
周报不是形式——研发周报和测试周报是项目经理对客户/上级同步进度的唯一窗口，写得烂就丢信任。
手册要趁热写——操作手册和维护手册测试期间就要开始写，别拖到上线后。

十一、常见 5 个坑

跳过需求评审——直接进开发，最后发现做出来不是客户要的东西
概要设计变成详细设计——把实现细节写进概要设计，导致接口反复改
测试实例覆盖不全——只测正常流程不测异常流程，上线后出生产事故
没有维护手册——运维靠"老人记忆”，老人一走系统就瘫
绩效考核靠感觉——没有数据化指标，年终评优变成"谁关系好"

十二、和敏捷的关系

瀑布流不等于落后，敏捷不等于先进。实际项目里：

底层用瀑布：合同/范围/阶段物/验收
上层用敏捷：需求池/Sprint/迭代评审/回顾会

混合模式：

0 启动 / 1 需求：瀑布（拍板）
2 设计 / 3 开发 / 4 测试：敏捷（迭代）
5 运维 / 6 日常 / 7 管理：瀑布（运维 + 考核）

十三、2026 年回望

18 年后再读这份方法论，有几个仍然成立的判断：

角色分工的边界——产品、研发、测试、运维的职责切分，至今没有过时；只是协作工具从邮件/共享文件夹换成了 Jira/Slack/飞书
阶段物的严肃性——BRD/MRD/PRD 在 2026 年的互联网大厂依然在用，只是"敏捷化"了产出节奏（每个 Sprint 出一份精简版）
周报的价值——周报是项目经理对干系人同步进度的最低成本手段，没有替代品

也有一两个明显过时的判断：

Jira 作为测试 bug 流转工具——2026 年的中型团队更多用 GitHub Issues / Linear / 飞书项目
压力测试的边界——2008 年主要靠 LoadRunner，2026 年已经是 k6 / Locust / 云厂商 PTS 标准化
运维靠人值班——2026 年的中等规模系统早已 SRE 化、告警自愈、ChatOps 化

但底层的 7 阶段骨架、输入/处理/输出/评审四件套、阶段物即法律证据的判断——18 年后依然站得住。这也是为什么我把这套方法论重新整理出来：给在 2026 年进入 IT 行业的新人，一份"知道流程为何长这样"的参考。

参考资料

《项目全流程》方法论原始整理稿（2008）
《需求文档 / 需求分析报告 / 需求规格说明书》模板（2008）
《概要设计》标准结构（2008）
团队内部 7 阶段项目复盘记录

2024 视角（项目全流程：阶段不变，工具全换）

2026 年再写一篇——“骨架不变，工具全换”：

0 启动——DOR（Definition of Ready） + DOD（Definition of Done） 取代模糊的"评审会"。启动产出物在 2024 年已经从"会议纪要 + 共享文档"升级为Jira Initiative → Epic → Story 三级结构 或 飞书项目 / Linear。
1 需求——BRD/MRD/PRD 三件套在 2024 年互联网大厂仍有效，但文档形式从 Word 转向 Notion / 飞书 / Confluence，并要求每条需求带"用户故事 + 验收标准 + 度量指标"。LLM 工具（GitHub Copilot、Cursor、Trae）能自动从 PRD 草稿生成用户故事和边界用例。
2 设计——C4 模型（Context / Container / Component / Code）+ ADR（Architecture Decision Records） 取代大段 Word 描述。一个 ADR = 一个决策 + 上下文 + 后果，git 一并管理。Mermaid / PlantUML 取代 Visio。
3 开发——GitOps（Argo CD / Flux）+ Trunk-Based Development + Feature Flags（LaunchDarkly / Unleash）取代"长分支 + 合并冲突"。AI 代码评审（GitHub Copilot Review、Coderabbit）已成 PR 标配。
4 测试——契约测试（Pact）+ E2E 自动化（Playwright）+ 性能测试左移（k6 / Grafana k6 Cloud）+ AI 生成测试用例（Diffblue、腾讯 IAST）取代纯人工测试。
5 运维——SRE + GitOps 持续发布 + Observability 三大支柱（Prometheus + Loki + Tempo / OpenTelemetry）+ ChatOps（PagerDuty + Slack）取代人工值班。
6 日常——数据驱动的运维（SLO/SLI 看板）+ SRE 错误预算 取代"故障后开复盘会"。
7 管理——OKR + KPI 双轨——OKR 驱动方向、KPI 驱动执行。HR 系统 + Jira 数据 自动生成绩效，不再"凭感觉评优"。

额外 4 个 2024 视角：

AI 工具是新一代"阶段物"：需求阶段用 LLM 拆解用户故事；设计阶段用 LLM 生成 ADR 草稿；开发阶段用 Copilot / Cursor；测试阶段用 AI 生成用例；运维阶段用 AIOps（异常检测 + 自愈）。
远程办公让"会议"不再是默认协作方式——异步优先（Async-First）+ 文档驱动（Doc-Driven）+ 决策记录（ADR）成为新基础。
数据合规：等保 2.0、GDPR、CCPA 让阶段物"合规性"要求大幅上升——日志、审计、用户授权必须全生命周期留痕。
DevSecOps 嵌入：安全不再是"上线前扫描一下"，而是从需求阶段就介入（SAST/DAST/SCA/IaC 扫描全在 CI 中）。

结论：2008 年的"7 阶段骨架"在 2024 年仍可用，但每个阶段内的工具、产物格式、协作方式都经历了 2-3 次代际升级。新人最该学的不是"流程长啥样"，而是**“每个阶段的产物在 2024 年用什么工具、什么格式、谁在什么时候产出”**——这才是 IT 项目管理的"现代工程实践"。

项目全流程模板实战：从启动会议到年终总结的 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+ 项目管理最大的范式转移。

禅道、FRP 内网穿透、RustDesk：项目管理与远程协作工具链

Tue, 15 Mar 2022 00:00:00 +0800

小团队想要"项目管理 + 远程办公"的基础设施，开源圈有几款久经考验的组合：

禅道（Zentao）：国产老牌项目管理软件，支持需求/任务/缺陷/Bug 全生命周期，开源版免费。
FRP（Fast Reverse Proxy）：把内网服务（如家里的 NAS、办公室的服务器）暴露到公网，比 ssh 反向隧道更稳定。
RustDesk：开源远程桌面（TeamViewer 替代品），服务端自建——数据完全可控。

这三者搭配，就构成一套"自建、不依赖第三方、够用"的远程协作工具链。

阅读对象：小团队 admin / 运维 / 想从 TeamViewer/钉钉/企业微信项目里迁出来的同学。 覆盖范围：禅道 Docker 部署（v18.3/21.4）、升级流程；FRP 客户端配置（tcp 代理 ssh/mysql）；RustDesk 服务端 docker-compose、Key 生成、客户端使用。

一、禅道项目管理（Zentao）

禅道是国产开源项目管理的代表，2009 年发布，2021 年起进入"专业版/企业版/旗舰版/IPD"矩阵。开源版（zentao 18.x / 21.x）就够中小团队用。

1.1 版本对比

版号	类型	适合
`zentao 18.x`	开源版（PHP 7）	经典稳定
`zentao 21.x`	开源版（PHP 8）	新项目推荐
`pro+数字`	专业版	甘特图、APP、LDAP
`biz / max / ipd`	企业版/旗舰版/IPD	中大型企业

1.2 Docker 部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 拉镜像
docker pull easysoft/zentao:18.3

# 启动
docker run -d --name zentao --restart=always \
 -p 9999:80 \
 -v /home/docker/zentao/pms:/www/zentaopms \
 -v /home/docker/zentao/mysql:/var/lib/mysql \
 -e MYSQL_ROOT_PASSWORD={{REDACTED}} \
 easysoft/zentao:18.3

关键参数：

-v /home/docker/zentao/pms:/www/zentaopms：禅道代码、附件的持久化

-v /home/docker/zentao/mysql:/var/lib/mysql：MySQL 数据的持久化

这两个目录必须是空目录（首次启动会初始化）

1.3 访问与初始化

访问 http://<宿主机IP>:9999：

几分钟后跳到登录页
数据库密码 = 启动时的 MYSQL_ROOT_PASSWORD（{{REDACTED}}）
选"全生命周期"模式
设置管理员账号（密码 6+，大小写+数字）

完整初始化流程约 3-5 分钟。

1.4 21.4 版本（PHP 8）

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


docker pull hub.zentao.net/app/zentao:21.4

# 21.4 支持外部 MySQL（推荐）
docker run -it \
 -v /home/docker/zentao/data:/data \
 -p 80:80 \
 -e ZT_MYSQL_HOST=<mysql_host> \
 -e ZT_MYSQL_PORT=3306 \
 -e ZT_MYSQL_USER=root \
 -e ZT_MYSQL_PASSWORD={{REDACTED}} \
 -e ZT_MYSQL_DB=zentao \
 -e ZT_REDIS_HOST=redis \
 -e ZT_REDIS_PORT=6379 \
 -e ZT_REDIS_PASSWORD={{REDACTED}} \
 -e ZT_CACHE_TYPE=redis \
 hub.zentao.net/app/zentao:21.4

21.x 把 MySQL 拆出来做外部依赖，更适合"禅道 + 业务共享一套 MySQL"的场景。

1.5 升级

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


# 1. 停止并删除旧容器
docker stop zentao
docker rm zentao

# 2. 备份数据
cp -rp /home/docker/zentao/pms /home/docker/zentao_pms_$(date +%Y%m%d)
cp -rp /home/docker/zentao/mysql /home/docker/zentao_mysql_$(date +%Y%m%d)

# 3. 拉新镜像
docker pull hub.zentao.net/app/zentao:21.4

# 4. 重新启动（沿用旧数据目录）
docker run --name zentao \
 -p 80:80 \
 --network=zentaonet \
 --ip 172.172.172.172 \
 -v /home/docker/zentao/pms:/www/zentaopms \
 -v /home/docker/zentao/mysql:/var/lib/mysql \
 -e MYSQL_INTERNAL=true \
 -d hub.zentao.net/app/zentao:18.7

升级关键：数据目录 + MySQL 目录保留，只换镜像。禅道会自动检测版本、跑升级 SQL。

1.6 备份脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 1. 停禅道
docker stop zentao

# 2. 打包
tar -czf /backup/zentao_$(date +%Y%m%d).tar.gz \
 /home/docker/zentao/pms \
 /home/docker/zentao/mysql

# 3. 启动
docker start zentao

二、FRP 内网穿透

FRP（Fast Reverse Proxy） 是一个高性能的反向代理应用，可以把内网机器的 SSH、MySQL、Web 服务暴露到公网。比 ssh -R 稳定，比 ngrok 私有化。

2.1 架构

1
2
3
4


[内网机器 A] [公网 VPS]
 frpc ──tcp──► frps :7000
 ssh:22 ─────► 公网 IP:6190
 mysql:3306 ───► 公网 IP:6191

2.2 公网 VPS 部署 frps

1
2
3
4
5
6
7


# 下载服务端
wget https://github.com/fatedier/frp/releases/download/v0.52.3/frp_0.52.3_linux_amd64.tar.gz
tar xf frp_0.52.3_linux_amd64.tar.gz
cd frp_0.52.3_linux_amd64

# 启动服务端
./frps -c frps.ini

frps.ini 关键配置：

1
2
3
4
5
6


[common]
bind_port = 7000
dashboard_port = 7500
dashboard_user = admin
dashboard_pwd = {{REDACTED}}
token = {{REDACTED}}

2.3 内网机器部署 frpc

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


mkdir -p /home/docker/rp
cat << 'EOF' > /home/docker/rp/frpc.toml
serverAddr = "1.2.3.4" # 公网 VPS IP
serverPort = 7000
auth.method = "token"
auth.token = "{{REDACTED}}"

[[proxies]]
name = "office-ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6190

[[proxies]]
name = "office-mysql"
type = "tcp"
localIP = "127.0.0.1"
localPort = 3306
remotePort = 6191
EOF

2.4 Docker 启动 frpc

1
2
3
4
5


docker run -d --restart=always \
 --name frpc \
 --network host \
 -v /home/docker/rp/frpc.toml:/etc/frp/frpc.toml \
 snowdreamtech/frpc:0.52.3

多台内网机器：每台跑 frpc，分配不同的 remotePort 即可。frps 自动路由。

2.5 验证

1
2
3
4
5


# 在公网 VPS 测试 SSH 到内网机器
ssh -p 6190 user@1.2.3.4

# 在业务服务器连内网 MySQL
mysql -h 1.2.3.4 -P 6191 -u root -p

三、RustDesk 远程桌面（自建 Server）

TeamViewer 商业版贵、向日葵限速。RustDesk 是开源替代品（Rust 写的），服务端自建、客户端开源，远程控制数据不经过第三方。

3.1 架构

1
2
3
4
5


[被控端] ──tcp/udp──► [RustDesk Server] ◄──tcp── [主控端]
 21115 (NAT)
 21116 (ID 注册)
 21117 (Relay)
 21118 (WebSocket)

3.2 服务端 docker-compose

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


mkdir -p /home/docker/rustdesk/data
cat << 'EOF' > /home/docker/rustdesk/docker-compose.yaml
version: "3"
services:
 rustdesk-server:
 container_name: rustdesk-server
 ports:
 - 21115:21115
 - 21116:21116
 - 21116:21116/udp
 - 21117:21117
 - 21118:21118
 - 21119:21119
 image: rustdesk/rustdesk-server-s6:latest
 environment:
 - "RELAY=internal.example.com:21117"
 - "ENCRYPTED_ONLY=1"
 volumes:
 - /home/docker/rustdesk/data:/data
 restart: unless-stopped
EOF

docker-compose -f /home/docker/rustdesk/docker-compose.yaml up -d

关键参数：

RELAY：内网穿透地址，客户端连接不上时走 relay

ENCRYPTED_ONLY=1：强制端到端加密（防止 relay 服务器偷看）

3.3 提取服务端 Key

1
2


cat /home/docker/rustdesk/data/id_ed25519.pub
# 输出形如：YFdhkFcz19pQBzEbCdf2weNt3PSmyzeHHyhRkKhyTI0=

Key 必须在客户端配置，否则连不上自建 server。

3.4 客户端使用

下载地址：github.com/rustdesk/rustdesk/releases

Windows / macOS / Linux / Android / iOS 全平台。

配置 ID Server：

打开 RustDesk → 设置 → 网络
ID 服务器：<公网IP或域名>
Key：粘贴上一步提取的 id_ed25519.pub
中继服务器：<公网IP>:21117

客户端 ID 是自动生成的（如 825 391 728），告诉对方这个 ID 就能远程。

3.5 防火墙开放端口

1
2
3
4
5
6
7
8
9


# Ubuntu/Debian
ufw allow 21115:21119/tcp
ufw allow 21116/udp
ufw reload

# CentOS
firewall-cmd --add-port=21115-21119/tcp --permanent
firewall-cmd --add-port=21116/udp --permanent
firewall-cmd --reload

四、组合：自建远程协作套件

角色	工具	替代品
项目管理	禅道（自建）	Jira（商业）、Teambition、飞书项目
文档协作	（可选）Outline / BookStack	Confluence、Notion
远程桌面	RustDesk（自建）	TeamViewer、向日葵
内网穿透	FRP（自建）	ngrok（商业）、cpolar
即时通讯	（可选）Rocket.Chat / Mattermost	钉钉、企业微信、Slack

小团队 5-20 人成本几乎为 0（VPS 一年 200 元），数据全在自己手里。

五、扩展阅读

禅道开源版：zentao.net
FRP 官方仓库：github.com/fatedier/frp
RustDesk 官方仓库：github.com/rustdesk/rustdesk
RustDesk Server 镜像：hub.docker.com/r/rustdesk/rustdesk-server
FRP 镜像：hub.docker.com/r/snowdreamtech/frpc