知识管理
让经验沉淀为团队资产，而不是随着人员流动而流失
为什么 FDE 团队需要知识管理
FDE 是一个技术快速迭代的方向，知识管理的重要性体现在：
- 技术更新快：上个月的最优方案这个月可能就被替代
- 踩坑成本高：同样的 OOM 问题不能每次都让不同的人踩一遍
- 人员流动：核心成员离职后，经验不能跟着走
- 新人上手：新人应该站在团队的肩膀上，而不是从 0 开始
知识库建设
知识库结构
知识库/
├── 模型卡片/ # 每个模型的部署信息和性能数据
│ ├── Llama-3-8B.md
│ ├── Llama-3-70B.md
│ ├── Qwen-2-7B.md
│ └── ...
├── 性能基线/ # 各 GPU 型号上的性能基准
│ ├── A100-80G.md
│ ├── H100.md
│ └── L40S.md
├── 最佳实践/ # 部署 checklist、优化手册、SOP
│ ├── 模型部署 SOP.md
│ ├── 量化操作手册.md
│ └── 线上排查指南.md
├── 踩坑记录/ # OOM 排查、高延迟案例
│ ├── OOM 案例集合.md
│ ├── 延迟升高排查案例.md
│ └── GPU 掉卡案例.md
├── 技术评估报告/ # 新技术评估
│ ├── vLLM vs TGI 对比.md
│ ├── FP8 量化评估.md
│ └── Speculative Decoding 评估.md
├── 培训资料/ # onboarding 文档、技术分享
│ ├── 新人 onboarding 指南.md
│ └── 技术分享合集/
└── 前沿跟踪/ # 论文笔记、技术周报
├── arXiv 论文笔记/
└── 技术周报/
模型卡片模板
每个模型一张卡片，是知识库中最核心的资产：
# [模型名称] 模型卡片
## 基本信息
- 参数量：XX B
- 架构：Dense / MoE
- 上下文长度：XXK
- 许可证：XX
## GPU 配置
- 部署方式：单卡 / TP2 / TP4
- 量化方式：FP16 / INT8 / INT4
- 显存占用：XX GB
## 性能基线
| 指标 | 值 | 测试条件 |
|------|-----|----------|
| P50 延迟 | XX ms | input=128, output=256 |
| P99 延迟 | XX ms | input=128, output=256 |
| 吞吐 | XX tok/s | batch_size=32 |
| GPU 利用率 | XX% | |
## 已知问题
- [问题 1] + 解决方案
- [问题 2] + 解决方案
## 优化建议
- 建议 1
- 建议 2
## 部署记录
| 日期 | 版本 | 变更 | 操作人 |
|------|------|------|--------|
性能基线模板
# [GPU 型号] 性能基线
## 硬件信息
- GPU 型号：XX
- 显存：XX GB
- CUDA 版本：XX
## 基准测试结果
| 模型 | 量化 | 延迟(P50) | 延迟(P99) | 吞吐 | GPU 利用率 |
|------|------|-----------|-----------|------|------------|
## 注意事项
- [GPU 特有的坑或优化点]
## 测试环境
- 推理引擎版本
- CUDA 驱动版本
- 测试数据集
踩坑记录模板
# [问题描述] 踩坑记录
## 现象
- 发生时间：
- 影响范围：
- 症状描述：
## 排查过程
1. 第一步：[做了什么，发现了什么]
2. 第二步：[做了什么，发现了什么]
3. ...
## 根因
- 最终定位的根因：
## 解决方案
- 紧急修复方案：
- 长期修复方案：
## 预防措施
- 以后怎么避免：
## 关联知识
- 相关文档链接
文档规范
文档质量标准
每篇技术文档都应该满足以下标准：
| 标准 | 要求 |
|---|---|
| 结构清晰 | 有标题、段落分层，能一目了然地找到信息 |
| 有数据支撑 | 结论必须有数据支持，不只是定性描述 |
| 有可操作性 | 读者看完后知道怎么做 |
| 有时效标注 | 标注最后更新日期，过期内容有明显标记 |
| 有作者信息 | 标注作者和审核人 |
文档格式规范
---
title: 文档标题
author: 作者
date: 创建日期
updated: 最后更新日期
tags: [标签1, 标签2]
---
# 标题
> 一句话概括核心内容
## 背景
...
## 方案
...
## 数据
...
## 结论
...
## 参考
...
文档 Review 流程
作者撰写 → 同行 Review → 发布 → 定期审计
- 同行 Review：每篇重要文档发布前由一位同行 Review
- 定期审计：每季度审计一次知识库，标记过期内容
- 版本管理：重要文档有版本历史，记录变更
技术分享机制
分享与知识库的关系
技术分享不是"讲完就散"，而是知识沉淀的入口：
技术分享 → 产出文档 → 进入知识库 → 持续更新 → 团队复用
每次技术分享必须产出至少一篇文档，否则分享的价值会随着时间流失。
分享知识库的运营
| 角色 | 职责 |
|---|---|
| 知识库管理员（轮值） | 负责文档结构维护、过期内容标记 |
| 贡献者（全体） | 撰写和更新文档 |
| Reviewer（轮值） | Review 新文档的质量 |
知识库的使用指标
| 指标 | 目标 | 追踪方式 |
|---|---|---|
| 文档总数 | 持续增长 | 月度统计 |
| 月度新增文档 | ≥ 8 篇 | 月度统计 |
| 文档阅读量 | 人均每周 ≥ 3 篇 | 平台数据 |
| 文档更新频率 | 每月更新率 ≥ 20% | 季度审计 |
| 知识库满意度 | 团队评分 ≥ 4/5 | 季度调研 |
知识传承
人员离职时的知识交接
当核心成员离职时，必须有正式的知识交接流程：
交接清单 → 知识文档化 → 1v1 知识传递 → 验收确认
| 步骤 | 内容 | 时长 |
|---|---|---|
| 交接清单 | 列出该成员负责的所有工作和未完成事项 | 1 天 |
| 知识文档化 | 将隐性知识写进文档 | 3-5 天 |
| 1v1 知识传递 | 和接手人面对面讲解关键知识 | 1-2 天 |
| 验收确认 | 接手人确认理解了关键知识 | 1 天 |
知识传承的质量保障
- 核心知识不能只存在于个人脑子里
- 每个重要模块至少有 2 个人了解
- 新人 onboarding 文档持续更新
- 每季度审计知识库，确保内容有效
面试视角：如何在面试中展示知识管理
当面试官问"团队的知识怎么传承"或"你怎么管理技术知识"时：
"我建了一个完整的知识库体系，核心是几个关键文档模板：
模型卡片记录每个模型的部署信息和性能基线，
踩坑记录让团队不重复踩同样的坑，
技术评估报告确保决策有数据支撑。
同时我规定每次技术分享必须产出文档，否则分享的价值会流失。
人员离职时有正式的知识交接流程，确保经验不会跟着人走。
效果是，新人上手时间从 2 个月缩短到 2 周，
同样的坑不再重复踩。"
下一节：招聘策略