需求到上线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）
整体流程概览
5.1 第一步：需求理解（时间占比：10%）
没理解需求就动手，是最常见的浪费。
| 项目 | 内容 |
|---|---|
| 输入 | 需求文档 / 产品口头描述 / Issue 单 |
| 活动 | 理解业务问题、用户场景、边界条件、验收标准 |
| 输出 | 需求理解确认记录（口头或书面） |
| 检查点 | 能用一句话说清功能价值；能画出用户操作流程图；明确了验收标准；与产品/需求方确认理解一致 |
操作内容：
a) 业务问题澄清
- 这个功能解决什么用户痛点？
- 预期的业务价值是什么？如何衡量？
- 不做这个功能会怎样？
b) 用户场景分析
- 目标用户是谁？
- 用户在什么场景下使用？
- 用户的操作路径是什么？
c) 边界条件确认
- 正常流程是什么？
- 异常情况有哪些？如何处理？
- 有什么限制/约束（性能、安全、兼容性）？
d) 验收标准对齐
- DoD（完成的定义）是什么？
- 有没有参考的产品/设计稿？
- 上线时间要求是什么？
沟通技巧
不要只问"要做什么"，要问"为什么要做"。理解业务目标，才能做出正确的技术取舍。
5.2 第二步：方案调研（时间占比：20%）
不要从零开始。先看看业界怎么做的。
| 项目 | 内容 |
|---|---|
| 输入 | 需求理解确认记录 |
| 活动 | 业界方案调研、方案对比、风险评估 |
| 输出 | 方案对比表、技术选型建议、风险清单、参考资料 |
| 检查点 | 了解了业界主流方案；能说出推荐方案的理由；识别了主要风险 |
时间盒限制：
简单功能：30 分钟
中等功能：2 小时
复杂功能：半天
时间到了就做决策，不要追求完美信息。操作内容（按领域熟悉度选择）：
a) 陌生领域调研
如对领域不熟悉，使用 垂直领域深度学习SOP（在新窗口打开） 的方法：
- 问 AI：在该领域中，业界公认的最佳实践是什么？有哪些被广泛采用的开源项目/库？
- 对比 2-3 个主流方案：各自的优缺点、适用场景、社区活跃度、学习成本
- 找争议点：搜索"XX vs YY"，看 GitHub Issues/Discussions 中的讨论，了解各方案的 trade-off
- 问 AI 批判性问题：这个方案有什么安全隐患？在什么场景下会失效？有没有更简单/更现代的替代方案？
b) 熟悉领域调研
- 回顾项目中类似功能的实现
- 检查是否有可复用的组件/模块
- 了解是否有技术债务需要处理
- 确认技术栈是否有升级/变化
c) 调研产出
| 产出物 | 内容 |
|---|---|
| 方案对比表 | 2-3 个方案的优缺点对比 |
| 技术选型建议 | 推荐方案 + 理由 |
| 风险清单 | 已知风险和应对策略 |
| 参考资料 | 文档/文章/开源项目链接 |
5.3 第三步：方案设计（时间占比：20%）
先想清楚再动手，磨刀不误砍柴工。
| 项目 | 内容 |
|---|---|
| 输入 | 方案调研产出 |
| 活动 | 编写设计文档、进行设计评审 |
| 输出 | 技术设计文档 |
| 检查点 | 完成设计文档；通过技术评审（如有）；识别了主要风险和应对策略 |
设计评审检查项：
| 检查项 | 说明 |
|---|---|
| 简单性 | 是否过度设计？有没有更简单的方案？ |
| 可测试性 | 方便测试吗？需要 Mock 什么？ |
| 可回滚性 | 上线后出问题能回滚吗？ |
| 可观测性 | 出问题能排查吗？日志/监控够吗？ |
| 边界情况 | 异常情况考虑到了吗？ |
操作内容：
按以下模板编写技术设计文档：
# [功能名称] 技术设计
## 1. 背景
- 业务背景
- 要解决的问题
## 2. 方案概述
- 整体思路（一句话）
- 核心设计决策
## 3. 架构设计
- 架构图
- 模块划分
- 数据流向
## 4. 详细设计
- 核心流程
- 数据模型
- 接口设计
- 关键算法/逻辑
## 5. 非功能性设计
- 性能考量
- 安全设计
- 可扩展性
- 可观测性
## 6. 风险与应对
- 已知风险
- 应对策略
- 降级方案
## 7. 实施计划
- 分阶段实施
- 里程碑注意：设计和实现出现偏差是正常现象。关键是重大偏差及时同步、实现后更新设计文档、记录偏差原因以积累经验。
5.4 第四步：编码实现（时间占比：30%）
代码是写给人看的，顺便能在机器上运行。
| 项目 | 内容 |
|---|---|
| 输入 | 技术设计文档、项目编码规范 |
| 活动 | 编码、自测、提交代码、Code Review |
| 输出 | 功能代码、单元测试代码 |
| 检查点 | 功能完整实现；代码通过 Code Review；无新增 Lint/Type 错误 |
a) 编码前准备
b) 编码原则
| 原则 | 说明 |
|---|---|
| 小步提交 | 每个 commit 只做一件事 |
| 先写测试 | 复杂逻辑先写测试用例 |
| 及时重构 | 发现坏味道立刻重构 |
| 写好注释 | 解释"为什么"，不是"是什么" |
c) 代码自查清单
## 功能正确性
- [ ] 实现了所有需求点
- [ ] 边界情况处理正确
- [ ] 错误处理完善
## 代码质量
- [ ] 命名清晰，符合规范
- [ ] 没有重复代码
- [ ] 函数/方法长度合理
- [ ] 没有过度设计
## 安全性
- [ ] 输入验证
- [ ] 权限检查
- [ ] 敏感数据处理
- [ ] SQL 注入 / XSS 等防护
## 性能
- [ ] 没有明显的性能问题
- [ ] 数据库查询合理
- [ ] 没有内存泄漏风险5.5 第五步：测试验证（时间占比：15%）
测试不是为了找 Bug，而是为了建立信心。
| 项目 | 内容 |
|---|---|
| 输入 | 功能代码、需求验收标准 |
| 活动 | 各类测试执行、Bug 修复 |
| 输出 | 测试结果记录、Bug 修复记录 |
| 检查点 | 自测全部通过；测试用例覆盖核心场景；Bug 修复并验证 |
a) 测试类型
| 类型 | 内容 | 责任人 |
|---|---|---|
| 单元测试 | 核心逻辑的边界条件 | 开发 |
| 集成测试 | 模块间交互正确性 | 开发 |
| E2E 测试 | 用户流程正确性 | 开发/测试 |
| 功能测试 | 需求符合性 | 测试/产品 |
| 回归测试 | 不影响现有功能 | 测试 |
b) 自测清单
## 基础功能
- [ ] 主流程走通
- [ ] 各种输入组合测试
- [ ] 边界值测试
## 异常处理
- [ ] 网络异常
- [ ] 数据异常
- [ ] 并发场景
## 兼容性
- [ ] 浏览器兼容（如适用）
- [ ] 移动端适配（如适用）
- [ ] 旧数据兼容
## 性能
- [ ] 响应时间可接受
- [ ] 大数据量场景5.6 第六步：上线部署（时间占比：5%）
上线不是终点，而是验证的起点。
| 项目 | 内容 |
|---|---|
| 输入 | 测试通过的代码、上线审批（如需） |
| 活动 | 上线前检查、部署执行、上线后验证、监控观察 |
| 输出 | 上线完成确认、监控记录 |
| 检查点 | 功能上线正常；无重大 Bug；监控告警正常 |
a) 上线前检查
## 准备工作
- [ ] 代码已合并到主分支
- [ ] 配置项已确认
- [ ] 数据库变更已执行（如需要）
- [ ] 上线公告已发布（如需要）
## 回滚准备
- [ ] 有回滚方案
- [ ] 回滚步骤已验证
- [ ] 关键人已通知
## 监控准备
- [ ] 监控指标已配置
- [ ] 告警规则已设置
- [ ] 值班人员已确认b) 上线后验证
## 功能验证
- [ ] 核心功能正常
- [ ] 边界情况正常
- [ ] 用户反馈渠道畅通
## 监控观察
- [ ] 错误率正常
- [ ] 响应时间正常
- [ ] 资源使用正常
## 持续关注
- [ ] 24 小时内关注监控
- [ ] 收集用户反馈
- [ ] 记录待优化点6 质量检查（Quality Checks）
6.1 各阶段检查汇总
| 阶段 | 关键检查项 | 检查方式 | 不通过处理 |
|---|---|---|---|
| 需求理解 | 一句话价值描述 + 用户流程图 + 验收标准 | 自查 + 与需求方确认 | 返回需求方补充信息 |
| 方案调研 | 方案对比表 + 选型理由 + 风险清单 | 自查 | 继续调研或寻求技术负责人指导 |
| 方案设计 | 设计文档 + 评审通过 + 风险应对 | 评审会 / 文档 Review | 修改设计后重新评审 |
| 编码实现 | 功能完整 + Code Review 通过 + 无 Lint 错误 | 自查 + 代码评审 | 修改代码后重新 Review |
| 测试验证 | 自测通过 + 核心场景覆盖 + Bug 清零 | 自测 + 测试报告 | 修复后重新测试 |
| 上线部署 | 功能正常 + 无重大 Bug + 监控正常 | 上线验证 + 监控确认 | 执行回滚方案 |
6.2 不可跳过的检查项
以下检查项在任何场景下（包括紧急需求）均不可跳过：
- 需求确认（与需求方对齐理解）
- 自测（核心路径功能验证）
- 回滚方案（上线安全保障）
7 异常处理（Exceptions）
| 异常场景 | 处理方式 | 升级条件 |
|---|---|---|
| 调研超时 | 按时间盒规则强制决策，选择当前最优方案 | 超过时间盒 2 倍仍无结论 |
| 设计与实现偏差 | 重大偏差及时同步团队，实现后更新设计文档 | 偏差影响核心架构决策 |
| 上线后出 Bug | 评估影响范围 → 能快速修复则修复 → 影响大则先回滚 → 事后复盘 | 影响 > 10% 用户或核心流程 |
| 需求变更 | 评估变更影响范围，重新走受影响阶段的流程 | 变更影响已完成阶段的工作 |
| 技术方案不可行 | 回退到方案调研阶段，重新评估替代方案 | 需要更换核心技术选型 |
| 测试发现重大缺陷 | 回退到编码实现阶段修复，必要时回退到设计阶段 | 缺陷源于设计层面的问题 |
8 与 AI 协作指南
8.1 需求理解阶段
帮我分析这个需求：
[粘贴需求描述]
请回答：
1. 核心用户价值是什么？
2. 可能的边界情况有哪些？
3. 有没有我没注意到的隐含需求？8.2 方案调研阶段
我要实现 [功能描述]，使用 [技术栈]。
请告诉我：
1. 业界主流的实现方案有哪些？
2. 各方案的优缺点和适用场景？
3. 有什么已知的坑需要避免？
4. 推荐的学习资源？8.3 方案设计阶段
请帮我 Review 这个设计方案：
[粘贴设计文档]
请指出：
1. 有什么潜在的问题？
2. 有没有更简单的方案？
3. 安全性考虑是否完善？
4. 可扩展性如何？8.4 编码实现阶段
- 让 AI 生成代码框架
- 让 AI 解释复杂代码
- 让 AI 帮写单元测试
- 让 AI Review 代码8.5 测试验证阶段
请帮我设计测试用例：
功能：[功能描述]
边界条件：[列出已知的]
请补充我可能遗漏的测试场景。9 快速上手清单
9.1 接到新功能时
9.2 每日开始开发前
9.3 提交代码前
9.4 上线前
10 参考文档（References）
- 垂直领域深度学习SOP（在新窗口打开） - 陌生领域调研方法
- 源码阅读SOP（在新窗口打开） - 学习开源项目实现
- 技术文档编写SOP - 写好设计文档
11 修订记录（Revision History）
| 版本 | 日期 | 修订人 | 修订内容 |
|---|---|---|---|
| v1.0 | 2026-03-25 | — | 初始版本 |
| v2.0 | 2026-05-11 | — | 重构为标准 SOP 格式，增加目的、适用范围、术语定义、角色与职责、质量检查、异常处理、修订记录等章节；保留六步法核心方法论 |
记住：功能开发不是从写代码开始的。理解需求、调研方案、设计架构，每一步都在为成功铺路。遇到陌生领域，先找最佳实践，再动手实现。