在 GitHub 上编辑页面 (EN)

产品开发工作流 🚀

本指南涵盖了 Ultralytics 产品的产品规划、开发周期和发布流程。

产品理念 🎯

核心原则

  1. 快速交付，更快学习：2 周的迭代周期，优先打造 MVP
  2. 以用户为中心：构建用户最需要的功能，并以数据进行验证
  3. 开源优先：公开开发，社区反馈驱动路线图
  4. 性能即功能：亚毫秒级的推理时间，极小的内存占用
  5. API 优先设计：开发者喜爱的简洁、直观的 API

开发价值观

  • 行动导向：几天内完成原型设计，几周内交付，而不是几个月
  • 数据驱动决策：通过 GitHub stars、PyPI 下载量、Discord 投票来引导优先级
  • 最小可行性产品：快速发布 80% 的解决方案，通过迭代达到 100%
  • 持续部署：主分支始终处于可发布生产的状态
  • 彻底透明：公开路线图、公开指标、欢迎社区建议

功能开发生命周期 🔄

发现与规划（第 1 周）

通过以下方式识别需求：

  • 用户反馈：GitHub issues（投票）、Discord 投票、社区调查
  • 使用分析：功能采用率、API 端点指标、错误日志
  • 性能数据：基准测试结果、推理时间、内存占用
  • 竞争分析：跟踪竞争对手的发布情况及市场趋势
  • 内部自测：使用我们自己的工具，找出痛点

评估标准：

  • 用户影响：受影响的用户数量？痛点程度（1-10）？收入影响？
  • 技术可行性：工程工作量（S/M/L/XL）？依赖关系？风险？
  • 战略一致性：是否推进了 YOLO 的领先地位？是否支持关键垂直领域？
  • 资源可用性：团队容量？冲突的优先级？时间表？
  • 竞争紧迫性：竞争对手是否会率先发布？是否存在锁定风险？

产出：带有工作量估算和用户影响得分的优先级功能列表

设计与规范（第 1-3 天）

针对重大功能（>2 周的工程时间）：

  • 设计文档：问题陈述、提议的解决方案、已考虑的替代方案、成功指标
  • 技术规格：API 设计、架构图、数据模型、边界情况
  • 成功标准：量化指标（速度、准确率、采用率）和用户反馈目标
  • 风险评估：技术风险、依赖项、回滚计划
  • 团队评审：来自工程、产品及关键相关方的反馈

针对小型功能（<1 周的工程时间）：

  • GitHub issue：明确的问题描述、提议的方法、验收标准
  • 快速讨论：与相关工程师进行 15 分钟的同步
  • 准入审批：经理批准通过

产出：包含明确范围、成功指标和时间表的已批准规范

实施（冲刺执行）

冲刺规划（每 2 周）：

  • 冲刺目标：每个冲刺一个明确的目标
  • 任务分解：将功能拆解为 <1 天的任务
  • 容量规划：预留会议、PR 评审、支持的时间
  • 依赖项：识别阻碍因素，协调其他团队

每日执行：

  • 晨会（15 分钟）：昨天的进展、今天的计划、阻碍因素
  • 专注时间：4-6 小时的深度工作，最小化会议
  • PR 评审：4 小时内评审队友的 PR
  • 每日结束更新：Slack 进度更新，移动工单

开发最佳实践：

  • 功能标志：暗部署，逐步启用
  • 测试覆盖率：发布前编写测试（目标 >80% 覆盖率）
  • 文档：与代码在同一个 PR 中更新文档
  • 性能：前后进行基准测试，确保无回归
  • 安全：运行安全扫描，立即修复关键问题

请遵循详细的 development workflow 进行 PR 流程和代码标准操作。

评审与 QA（与实施并行）

代码评审（所有 PR 必需）：

  • <24 小时响应时间：资深工程师优先处理评审
  • 质量检查：代码正确性、测试覆盖率、性能影响
  • 安全评审：自动化扫描 + 敏感代码的人工评审
  • 文档：验证文档是否已更新，示例是否有效
  • 需要批准：合并前至少需要 1 名资深工程师批准

QA 流程：

  • 自动化测试：每次提交均运行单元测试、集成测试、E2E 测试
  • 人工测试：QA 工程师验证关键用户流程
  • 性能测试：与基准进行对比，标记性能下降
  • 跨平台：在 CPU、GPU、边缘设备上进行测试
  • 用户验收：重大功能选择部分用户进行 Beta 测试

迭代周期：

  • 立即解决反馈，不要积累技术债
  • 更改后重新测试，验证修复不会破坏其他功能
  • 更新工单进度，保持相关方知情

发布与上线

预发布检查清单：

  • 所有测试通过（单元、集成、E2E）
  • 性能基准达到目标
  • 文档完整且准确
  • 变更日志已更新用户可见变更
  • 迁移指南（如果存在重大变更）
  • 回滚计划已记录
  • 监控和警报已配置

发布流程：

  1. 合并到主分支：批准的 PR 自动合并
  2. 版本提升：语义化版本控制（主版本.次版本.补丁版本）
  3. 标签发布：创建带有变更日志的 GitHub release
  4. PyPI 发布：自动化部署到 Python Package Index
  5. Docker 更新：构建并推送新的容器镜像
  6. 文档部署：文档网站自动更新

发布沟通：

  • 博客文章：重大功能的技术深度解析
  • 社交媒体：X、LinkedIn、Discord 公告
  • 电子邮件通讯：通知 5 万+ 订阅用户
  • 发布视频：复杂功能的 YouTube 教程
  • 社区互动：监控 Discord/GitHub，响应反馈

上线后监控（前 48 小时）：

  • 关注错误率、延迟和采用指标
  • 在 4 小时内响应重大 bug
  • 针对破坏性问题的热修复流程（<24 小时处理周期）
  • 收集用户反馈，优先处理易于实现的改进

成功衡量指标（前 2 周）：

  • 采用率：升级用户的百分比
  • 使用指标：API 调用、功能参与度
  • 性能：推理速度、内存使用量
  • 用户反馈：GitHub 反应、Discord 民意调查
  • Bug 报告：严重与次要问题的比例

发布流程 📦

版本控制

语义化版本控制：MAJOR.MINOR.PATCH

  • MAJOR：破坏性更改
  • MINOR：新功能，向后兼容
  • PATCH：Bug 修复

示例：11.0.0 → 11.1.0（新功能）→ 11.1.1（bug 修复）

发布计划

  • 次要版本发布：每 2-4 周一次
  • 补丁版本发布：根据关键修复的需求随时发布
  • 主要版本发布：引入破坏性更改时

发布清单

  • 所有 CI 测试通过
  • 文档已更新
  • 更新日志已更新
  • 版本号已提升
  • GitHub 发布已创建
  • PyPI 包已发布
  • 公告已准备就绪

热修复流程

针对关键 bug：

  1. 从最新的发布标签创建 hotfix/ 分支
  2. 修复问题，添加测试
  3. 快速通道审查
  4. 立即发布补丁版本
  5. 如有必要，回传（backport）至 main 分支

功能优先级排序 📊

高优先级

  • 影响用户的关键 bug
  • 性能改进
  • 安全问题
  • 用户高度请求的功能（10 个以上的社区请求）

中优先级

  • 用户体验改进
  • 新的导出格式
  • 扩展的平台支持
  • 文档改进

低优先级

  • 锦上添花的功能
  • 微小的优化
  • 边缘情况处理

降级处理

  • 仅供单用户使用的功能
  • 过于复杂的实现
  • 维护成本高的功能
  • 超出核心任务范围

指标与成功 📈

关键指标

  • GitHub Stars：社区兴趣
  • PyPI 下载量：采用率
  • Issue 响应时间：支持质量
  • PR 合并时间：开发速度
  • 性能基准测试：速度/精度改进

功能成功标准

构建前定义：

  • 使用指标（下载量、API 调用）
  • 性能目标（速度、精度）
  • 用户反馈（GitHub 反应、评论）
  • 采用率（使用该功能的百分比）

沟通 💬

内部

  • GitHub Issues：功能提案和 bug
  • Slack：快速讨论和更新
  • 团队会议：关于优先级的每周同步

外部

  • GitHub Discussions：社区反馈
  • Discord：用户支持和互动
  • 博客文章：重大功能公告
  • 文档：发布说明和指南

产品路线图 🗺️

当前重点

即将开展的领域

长期愿景

  • 全球最佳开源目标检测技术
  • 跨所有平台的无缝部署
  • 全面的计算机视觉工具包
  • 社区驱动的创新

最佳实践 ✅

功能开发

  • 从小处着手：先做 MVP，后续再扩展
  • 用户测试：尽早获取反馈
  • 性能优先：从一开始就进行优化
  • 做好文档记录：边开发边写文档

版本发布管理

  • 彻底测试：CI + 手动测试
  • 清晰的变更日志：说明更新内容及其重要性
  • 平滑升级：尽可能保持向后兼容
  • 快速修复：不要让 Bug 长期存在

社区参与

  • 响应迅速：在 24 小时内回复 Issue
  • 公开透明：分享路线图和决策过程
  • 心存感激：感谢每一位贡献者
  • 包容开放：欢迎各种技能水平的贡献者

资源 📚

Contributors
在 GitHub 上编辑页面 (EN)
GLglenn-jocher6