---
url: /blog/feature-development-sop/index.md
---
# 需求到上线 SOP

> **核心理念**：从需求到上线，每一步都有章可循。遇到陌生领域，先找最佳实践，再动手实现。

***

## 1 目的（Purpose）

本 SOP 为功能开发提供标准化操作流程，解决以下常见问题：

| 痛点 | 后果 |
|:---|:---|
| 直接开始写代码 | 边写边改，返工多次 |
| 不了解最佳实践 | 重复造轮子，踩已知的坑 |
| 需求理解偏差 | 做出来的东西不是产品要的 |
| 缺少设计阶段 | 代码难以维护和扩展 |
| 测试不充分 | 上线后 Bug 频出 |

**核心目标**：建立从"我要做一个功能"到"功能安全上线"的完整可控路径，确保每个阶段有明确的输入、输出和检查点。

***

## 2 适用范围（Scope）

### 2.1 适用场景

* 接手新功能开发
* 技术方案设计
* 陌生领域功能探索
* 跨团队协作的功能交付

### 2.2 不适用场景

* 纯 Bug 修复（参考 Bug 修复流程）
* 紧急线上故障处理（参考故障应急流程）
* 日常运维配置变更

### 2.3 变体说明

| 场景 | 调整方式 |
|:---|:---|
| **紧急需求** | 压缩设计文档和调研，但不可跳过需求确认、自测、回滚方案 |
| **陌生技术栈** | 先花 1-2 小时快速学习基础，找参考实现，跑通最小 Demo 后再正式开发 |
| **大型功能** | 拆分多个小功能，分阶段上线，每阶段独立验证 |

***

## 3 术语定义（Definitions）

| 术语 | 定义 |
|:---|:---|
| **六步法** | 本 SOP 定义的功能开发核心流程：需求理解 → 方案调研 → 方案设计 → 编码实现 → 测试验证 → 上线部署 |
| **DoD** | Definition of Done，完成的定义，即功能达到可交付状态的验收标准 |
| **时间盒** | 为特定阶段设定的最大时间限制，防止过度投入 |
| **回滚方案** | 上线后出现问题时，恢复到上一稳定版本的操作计划 |
| **Code Review** | 代码评审，由非代码作者对代码质量、逻辑正确性进行审查 |

***

## 4 角色与职责（Roles）

| 角色 | 职责 | 参与阶段 |
|:---|:---|:---|
| **开发工程师** | 执行完整六步法，产出代码和文档 | 全流程 |
| **产品/需求方** | 提供需求说明，确认验收标准，参与功能验收 | 需求理解、测试验证 |
| **技术负责人** | 技术评审，架构把关，风险审批 | 方案设计、编码实现 |
| **测试工程师** | 功能测试、回归测试，Bug 反馈 | 测试验证 |
| **运维工程师** | 部署执行，监控配置，回滚支持 | 上线部署 |

***

## 5 操作流程（Procedure）

### 整体流程概览

```mermaid
flowchart LR
    A[需求理解] --> B[方案调研]
    B --> C[方案设计]
    C --> D[编码实现]
    D --> E[测试验证]
    E --> F[上线部署]

    A -->|10%| A
    B -->|20%| B
    C -->|20%| C
    D -->|30%| D
    E -->|15%| E
    F -->|5%| F
```

### 5.1 第一步：需求理解（时间占比：10%）

> 没理解需求就动手，是最常见的浪费。

| 项目 | 内容 |
|:---|:---|
| **输入** | 需求文档 / 产品口头描述 / Issue 单 |
| **活动** | 理解业务问题、用户场景、边界条件、验收标准 |
| **输出** | 需求理解确认记录（口头或书面） |
| **检查点** | 能用一句话说清功能价值；能画出用户操作流程图；明确了验收标准；与产品/需求方确认理解一致 |

**操作内容：**

**a) 业务问题澄清**

* 这个功能解决什么用户痛点？
* 预期的业务价值是什么？如何衡量？
* 不做这个功能会怎样？

**b) 用户场景分析**

* 目标用户是谁？
* 用户在什么场景下使用？
* 用户的操作路径是什么？

**c) 边界条件确认**

* 正常流程是什么？
* 异常情况有哪些？如何处理？
* 有什么限制/约束（性能、安全、兼容性）？

**d) 验收标准对齐**

* DoD（完成的定义）是什么？
* 有没有参考的产品/设计稿？
* 上线时间要求是什么？

::: tip 沟通技巧
不要只问"要做什么"，要问"为什么要做"。理解业务目标，才能做出正确的技术取舍。
:::

***

### 5.2 第二步：方案调研（时间占比：20%）

> 不要从零开始。先看看业界怎么做的。

| 项目 | 内容 |
|:---|:---|
| **输入** | 需求理解确认记录 |
| **活动** | 业界方案调研、方案对比、风险评估 |
| **输出** | 方案对比表、技术选型建议、风险清单、参考资料 |
| **检查点** | 了解了业界主流方案；能说出推荐方案的理由；识别了主要风险 |

**时间盒限制：**

```
简单功能：30 分钟
中等功能：2 小时
复杂功能：半天

时间到了就做决策，不要追求完美信息。
```

**操作内容（按领域熟悉度选择）：**

**a) 陌生领域调研**

如对领域不熟悉，使用 [垂直领域深度学习SOP](./垂直领域深度学习SOP.md) 的方法：

1. 问 AI：在该领域中，业界公认的最佳实践是什么？有哪些被广泛采用的开源项目/库？
2. 对比 2-3 个主流方案：各自的优缺点、适用场景、社区活跃度、学习成本
3. 找争议点：搜索"XX vs YY"，看 GitHub Issues/Discussions 中的讨论，了解各方案的 trade-off
4. 问 AI 批判性问题：这个方案有什么安全隐患？在什么场景下会失效？有没有更简单/更现代的替代方案？

**b) 熟悉领域调研**

1. 回顾项目中类似功能的实现
2. 检查是否有可复用的组件/模块
3. 了解是否有技术债务需要处理
4. 确认技术栈是否有升级/变化

**c) 调研产出**

| 产出物 | 内容 |
|:---|:---|
| 方案对比表 | 2-3 个方案的优缺点对比 |
| 技术选型建议 | 推荐方案 + 理由 |
| 风险清单 | 已知风险和应对策略 |
| 参考资料 | 文档/文章/开源项目链接 |

***

### 5.3 第三步：方案设计（时间占比：20%）

> 先想清楚再动手，磨刀不误砍柴工。

| 项目 | 内容 |
|:---|:---|
| **输入** | 方案调研产出 |
| **活动** | 编写设计文档、进行设计评审 |
| **输出** | 技术设计文档 |
| **检查点** | 完成设计文档；通过技术评审（如有）；识别了主要风险和应对策略 |

**设计评审检查项：**

| 检查项 | 说明 |
|:---|:---|
| **简单性** | 是否过度设计？有没有更简单的方案？ |
| **可测试性** | 方便测试吗？需要 Mock 什么？ |
| **可回滚性** | 上线后出问题能回滚吗？ |
| **可观测性** | 出问题能排查吗？日志/监控够吗？ |
| **边界情况** | 异常情况考虑到了吗？ |

**操作内容：**

按以下模板编写技术设计文档：

```markdown
# [功能名称] 技术设计

## 1. 背景
- 业务背景
- 要解决的问题

## 2. 方案概述
- 整体思路（一句话）
- 核心设计决策

## 3. 架构设计
- 架构图
- 模块划分
- 数据流向

## 4. 详细设计
- 核心流程
- 数据模型
- 接口设计
- 关键算法/逻辑

## 5. 非功能性设计
- 性能考量
- 安全设计
- 可扩展性
- 可观测性

## 6. 风险与应对
- 已知风险
- 应对策略
- 降级方案

## 7. 实施计划
- 分阶段实施
- 里程碑
```

**注意**：设计和实现出现偏差是正常现象。关键是重大偏差及时同步、实现后更新设计文档、记录偏差原因以积累经验。

***

### 5.4 第四步：编码实现（时间占比：30%）

> 代码是写给人看的，顺便能在机器上运行。

| 项目 | 内容 |
|:---|:---|
| **输入** | 技术设计文档、项目编码规范 |
| **活动** | 编码、自测、提交代码、Code Review |
| **输出** | 功能代码、单元测试代码 |
| **检查点** | 功能完整实现；代码通过 Code Review；无新增 Lint/Type 错误 |

**a) 编码前准备**

* \[ ] 拉取最新代码，创建功能分支
* \[ ] 确认开发环境正常
* \[ ] 阅读项目编码规范
* \[ ] 了解现有代码结构

**b) 编码原则**

| 原则 | 说明 |
|:---|:---|
| **小步提交** | 每个 commit 只做一件事 |
| **先写测试** | 复杂逻辑先写测试用例 |
| **及时重构** | 发现坏味道立刻重构 |
| **写好注释** | 解释"为什么"，不是"是什么" |

**c) 代码自查清单**

```markdown
## 功能正确性
- [ ] 实现了所有需求点
- [ ] 边界情况处理正确
- [ ] 错误处理完善

## 代码质量
- [ ] 命名清晰，符合规范
- [ ] 没有重复代码
- [ ] 函数/方法长度合理
- [ ] 没有过度设计

## 安全性
- [ ] 输入验证
- [ ] 权限检查
- [ ] 敏感数据处理
- [ ] SQL 注入 / XSS 等防护

## 性能
- [ ] 没有明显的性能问题
- [ ] 数据库查询合理
- [ ] 没有内存泄漏风险
```

***

### 5.5 第五步：测试验证（时间占比：15%）

> 测试不是为了找 Bug，而是为了建立信心。

| 项目 | 内容 |
|:---|:---|
| **输入** | 功能代码、需求验收标准 |
| **活动** | 各类测试执行、Bug 修复 |
| **输出** | 测试结果记录、Bug 修复记录 |
| **检查点** | 自测全部通过；测试用例覆盖核心场景；Bug 修复并验证 |

**a) 测试类型**

| 类型 | 内容 | 责任人 |
|:---|:---|:---|
| **单元测试** | 核心逻辑的边界条件 | 开发 |
| **集成测试** | 模块间交互正确性 | 开发 |
| **E2E 测试** | 用户流程正确性 | 开发/测试 |
| **功能测试** | 需求符合性 | 测试/产品 |
| **回归测试** | 不影响现有功能 | 测试 |

**b) 自测清单**

```markdown
## 基础功能
- [ ] 主流程走通
- [ ] 各种输入组合测试
- [ ] 边界值测试

## 异常处理
- [ ] 网络异常
- [ ] 数据异常
- [ ] 并发场景

## 兼容性
- [ ] 浏览器兼容（如适用）
- [ ] 移动端适配（如适用）
- [ ] 旧数据兼容

## 性能
- [ ] 响应时间可接受
- [ ] 大数据量场景
```

***

### 5.6 第六步：上线部署（时间占比：5%）

> 上线不是终点，而是验证的起点。

| 项目 | 内容 |
|:---|:---|
| **输入** | 测试通过的代码、上线审批（如需） |
| **活动** | 上线前检查、部署执行、上线后验证、监控观察 |
| **输出** | 上线完成确认、监控记录 |
| **检查点** | 功能上线正常；无重大 Bug；监控告警正常 |

**a) 上线前检查**

```markdown
## 准备工作
- [ ] 代码已合并到主分支
- [ ] 配置项已确认
- [ ] 数据库变更已执行（如需要）
- [ ] 上线公告已发布（如需要）

## 回滚准备
- [ ] 有回滚方案
- [ ] 回滚步骤已验证
- [ ] 关键人已通知

## 监控准备
- [ ] 监控指标已配置
- [ ] 告警规则已设置
- [ ] 值班人员已确认
```

**b) 上线后验证**

```markdown
## 功能验证
- [ ] 核心功能正常
- [ ] 边界情况正常
- [ ] 用户反馈渠道畅通

## 监控观察
- [ ] 错误率正常
- [ ] 响应时间正常
- [ ] 资源使用正常

## 持续关注
- [ ] 24 小时内关注监控
- [ ] 收集用户反馈
- [ ] 记录待优化点
```

***

## 6 质量检查（Quality Checks）

### 6.1 各阶段检查汇总

| 阶段 | 关键检查项 | 检查方式 | 不通过处理 |
|:---|:---|:---|:---|
| **需求理解** | 一句话价值描述 + 用户流程图 + 验收标准 | 自查 + 与需求方确认 | 返回需求方补充信息 |
| **方案调研** | 方案对比表 + 选型理由 + 风险清单 | 自查 | 继续调研或寻求技术负责人指导 |
| **方案设计** | 设计文档 + 评审通过 + 风险应对 | 评审会 / 文档 Review | 修改设计后重新评审 |
| **编码实现** | 功能完整 + Code Review 通过 + 无 Lint 错误 | 自查 + 代码评审 | 修改代码后重新 Review |
| **测试验证** | 自测通过 + 核心场景覆盖 + Bug 清零 | 自测 + 测试报告 | 修复后重新测试 |
| **上线部署** | 功能正常 + 无重大 Bug + 监控正常 | 上线验证 + 监控确认 | 执行回滚方案 |

### 6.2 不可跳过的检查项

以下检查项在任何场景下（包括紧急需求）均不可跳过：

* 需求确认（与需求方对齐理解）
* 自测（核心路径功能验证）
* 回滚方案（上线安全保障）

***

## 7 异常处理（Exceptions）

| 异常场景 | 处理方式 | 升级条件 |
|:---|:---|:---|
| **调研超时** | 按时间盒规则强制决策，选择当前最优方案 | 超过时间盒 2 倍仍无结论 |
| **设计与实现偏差** | 重大偏差及时同步团队，实现后更新设计文档 | 偏差影响核心架构决策 |
| **上线后出 Bug** | 评估影响范围 → 能快速修复则修复 → 影响大则先回滚 → 事后复盘 | 影响 > 10% 用户或核心流程 |
| **需求变更** | 评估变更影响范围，重新走受影响阶段的流程 | 变更影响已完成阶段的工作 |
| **技术方案不可行** | 回退到方案调研阶段，重新评估替代方案 | 需要更换核心技术选型 |
| **测试发现重大缺陷** | 回退到编码实现阶段修复，必要时回退到设计阶段 | 缺陷源于设计层面的问题 |

***

## 8 与 AI 协作指南

### 8.1 需求理解阶段

```markdown
帮我分析这个需求：
[粘贴需求描述]

请回答：
1. 核心用户价值是什么？
2. 可能的边界情况有哪些？
3. 有没有我没注意到的隐含需求？
```

### 8.2 方案调研阶段

```markdown
我要实现 [功能描述]，使用 [技术栈]。

请告诉我：
1. 业界主流的实现方案有哪些？
2. 各方案的优缺点和适用场景？
3. 有什么已知的坑需要避免？
4. 推荐的学习资源？
```

### 8.3 方案设计阶段

```markdown
请帮我 Review 这个设计方案：

[粘贴设计文档]

请指出：
1. 有什么潜在的问题？
2. 有没有更简单的方案？
3. 安全性考虑是否完善？
4. 可扩展性如何？
```

### 8.4 编码实现阶段

```markdown
- 让 AI 生成代码框架
- 让 AI 解释复杂代码
- 让 AI 帮写单元测试
- 让 AI Review 代码
```

### 8.5 测试验证阶段

```markdown
请帮我设计测试用例：

功能：[功能描述]
边界条件：[列出已知的]

请补充我可能遗漏的测试场景。
```

***

## 9 快速上手清单

### 9.1 接到新功能时

* \[ ] 理解需求，确认验收标准
* \[ ] 评估是否需要调研
* \[ ] 估算时间，拆分任务

### 9.2 每日开始开发前

* \[ ] 明确今天要完成的目标
* \[ ] 确认没有阻塞问题
* \[ ] 拉取最新代码

### 9.3 提交代码前

* \[ ] 自测通过
* \[ ] 代码自查
* \[ ] 提交信息清晰

### 9.4 上线前

* \[ ] 测试通过
* \[ ] 设计文档更新
* \[ ] 回滚方案准备好

***

## 10 参考文档（References）

* [垂直领域深度学习SOP](./垂直领域深度学习SOP.md) - 陌生领域调研方法
* [源码阅读SOP](./源码阅读SOP.md) - 学习开源项目实现
* [技术文档编写SOP](./技术文档编写SOP.md) - 写好设计文档

***

## 11 修订记录（Revision History）

| 版本 | 日期 | 修订人 | 修订内容 |
|:---|:---|:---|:---|
| v1.0 | 2026-03-25 | — | 初始版本 |
| v2.0 | 2026-05-11 | — | 重构为标准 SOP 格式，增加目的、适用范围、术语定义、角色与职责、质量检查、异常处理、修订记录等章节；保留六步法核心方法论 |

***

> **记住**：功能开发不是从写代码开始的。理解需求、调研方案、设计架构，每一步都在为成功铺路。遇到陌生领域，先找最佳实践，再动手实现。