产品开发工作流 🚀#
本指南涵盖 Ultralytics 产品的产品规划、开发周期和发布流程。
产品理念 🎯#
核心原则#
- 快速交付，更快学习：采用 2 周迭代周期，以 MVP 优先
- 以用户为中心：开发用户最常请求的功能，用数据进行验证
- 开源优先：公开开发，社区反馈推动路线图
- 性能就是功能：亚毫秒级推理时间，最小化内存占用
- API 优先设计：打造简单、直观且开发者喜爱的 API
开发价值观#
- 行动导向：几天内完成原型，几周内而不是几个月内交付
- 数据驱动决策：GitHub stars、PyPI 下载量和 Discord 投票指导优先级
- 最小可行产品：快速发布 80% 的解决方案，再迭代到 100%
- 持续部署：主分支始终可用于生产环境
- 彻底透明：公开路线图、开放指标和社区意见
功能开发生命周期 🔄#
1. 发现与规划（第 1 周）#
通过以下方式识别需求：
- 用户反馈：GitHub issues（投票）、Discord 投票和社区调查
- 使用分析：功能采用率、API 端点指标和错误日志
- 性能数据：基准测试结果、推理时间和内存使用情况
- 竞争分析：跟踪竞争对手发布和市场趋势
- 内部自用：使用我们自己的工具，找出痛点
根据以下方面进行评估：
- 用户影响：影响多少用户？痛点程度（1-10）？对收入的影响？
- 技术可行性：工程投入（S/M/L/XL）？依赖项？风险？
- 战略一致性：是否推动 YOLO 的领导地位？是否支持关键垂直领域？
- 资源可用性：团队容量？相互竞争的优先事项？时间线？
- 竞争紧迫性：竞争对手会先交付吗？是否存在锁定风险？
输出：包含工作量估算和用户影响评分的优先级功能待办列表
2. 设计与规范（第 1-3 天）#
对于主要功能（工程开发时间超过 2 周）：
- 设计文档：问题陈述、拟议解决方案、考虑过的替代方案和成功指标
- 技术规范：API 设计、架构图、数据模型和边界情况
- 成功标准：量化指标（速度、准确率、采用率）和用户反馈目标
- 风险评估：技术风险、依赖项和回滚计划
- 团队评审：收集工程、产品和关键利益相关者的反馈
对于小型功能（工程开发时间少于 1 周）：
- GitHub issue：清晰的问题描述、拟议方案和验收标准
- 快速讨论：与相关工程师进行 15 分钟同步
- 通过/不通过：获得经理批准后继续
输出：获批准的规范，包含明确范围、成功指标和时间线
3. 实施（Sprint 执行）#
Sprint 规划（每 2 周一次）：
- Sprint 目标：每个 Sprint 设定一个明确目标
- 任务拆分：将功能拆分为少于 1 天即可完成的任务
- 容量规划：考虑会议、PR 评审和支持工作
- 依赖项：识别阻塞因素，与其他团队协调
每日执行：
- 晨会（15 分钟）：昨日进展、今日计划和阻塞因素
- 专注时间：4-6 小时深度工作，尽量减少会议
- PR 评审：在 4 小时内评审队友的 PR
- 日终更新：在 Slack 更新进度，推进工单
开发最佳实践：
- 功能开关：暗部署，逐步启用
- 测试覆盖率：在交付前编写测试（覆盖率目标超过 80%）
- 文档：在与代码相同的 PR 中更新文档
- 性能：对比前后进行基准测试，不得出现回归
- 安全：运行安全扫描，立即修复严重问题
遵循详细的开发工作流了解 PR 流程和代码规范。
4. 评审与 QA（与实施并行）#
代码评审（所有 PR 都必须进行）：
- 响应时间少于 24 小时：高级工程师优先进行评审
- 质量检查：代码正确性、测试覆盖率和性能影响
- 安全评审：自动扫描 + 对敏感代码进行人工评审
- 文档：确认文档已更新且示例可正常运行
- 必须获得批准：合并前至少获得 1 名高级工程师的批准
QA 流程：
- 自动化测试：每次提交都运行单元测试、集成测试和 E2E 测试
- 手动测试：QA 工程师验证关键用户流程
- 性能测试：与基线进行基准测试，标记回归问题
- 跨平台：在 CPU、GPU 和边缘设备上测试
- 用户验收：针对主要功能邀请选定用户进行 Beta 测试
迭代周期：
- 立即处理反馈，不要积累技术债务
- 变更后重新测试，确认修复不会破坏其他功能
- 更新工单进度，让利益相关者随时了解情况
5. 发布与上线#
发布前检查清单：
- 所有测试通过（单元测试、集成测试、E2E 测试）
- 性能基准测试达到目标
- 文档完整且准确
- 更新变更日志，记录面向用户的变更
- 迁移指南（如存在破坏性变更）
- 已记录回滚计划
- 已配置监控和告警
发布流程：
- 合并到主分支：获批准的 PR 自动合并
- 版本递增：语义化版本控制（major.minor.patch）
- 标记发布版本：创建包含变更日志的 GitHub release
- 发布到 PyPI：自动部署到 Python 软件包索引
- 更新 Docker：构建并推送新的容器镜像
- 部署文档：文档网站自动更新
上线沟通：
- 博客文章：为主要功能撰写技术深度解析
- 社交媒体：在 X、LinkedIn 和 Discord 上发布公告
- 电子邮件通讯：通知 5 万多名订阅者
- 发布视频：为复杂功能制作 YouTube 教程
- 社区互动：监控 Discord/GitHub，回应反馈
上线后监控（前 48 小时）：
- 监测错误率、延迟和采用指标
- 在 4 小时内响应严重错误
- 重大问题的热修复流程（周转时间 <24 小时）
- 收集用户反馈，优先处理快速见效的改进
成功衡量（前 2 周）：
- 采用率：升级用户的百分比
- 使用指标：API 调用次数、功能参与度
- 性能：推理速度、内存使用量
- 用户反馈：GitHub 反应、Discord 投票
- 错误报告：严重问题与轻微问题的比例
发布流程 📦#
版本控制#
语义化版本控制：MAJOR.MINOR.PATCH
- MAJOR：不兼容的变更
- MINOR：新功能，向后兼容
- PATCH：错误修复
示例：11.0.0 → 11.1.0（新功能）→ 11.1.1（错误修复）
发布计划#
- MINOR 版本发布：每 2–4 周一次
- PATCH 版本发布：根据严重修复的需要进行
- MAJOR 版本发布：引入不兼容变更时进行
发布检查清单#
- 所有 CI 测试通过
- 文档已更新
- 变更日志已更新
- 版本号已递增
- 已创建 GitHub 发布版本
- PyPI 软件包已发布
- 已准备公告
热修复流程#
针对严重错误：
- 从最新发布标签创建
hotfix/分支 - 修复问题并添加测试
- 加速评审流程
- 立即发布 PATCH 版本
- 如有需要，回移植到主分支
功能优先级 📊#
高优先级#
- 影响用户的严重错误
- 性能改进
- 安全问题
- 用户强烈要求的功能（10+ 个社区请求）
中优先级#
- 提升使用体验的改进
- 新的导出格式
- 扩展平台支持
- 文档改进
低优先级#
- 锦上添花的功能
- 小幅优化
- 边界情况处理
降低优先级#
- 面向单个用户的功能
- 过于复杂的实现
- 维护成本高的新增内容
- 超出核心使命范围
指标与成功 📈#
关键指标#
- GitHub Stars：社区关注度
- PyPI 下载量：采用率
- 问题响应时间：支持质量
- PR 合并时间：开发速度
- 性能基准测试：速度/准确率改进
功能成功标准#
在开始构建之前定义：
- 使用指标（下载量、API 调用次数）
- 性能目标（速度、准确率）
- 用户反馈（GitHub 反应、评论）
- 采用率（使用该功能的用户百分比）
沟通 💬#
内部#
- GitHub Issues：功能提案和错误
- Slack：快速讨论和更新
- 团队会议：每周同步优先事项
外部#
- GitHub Discussions：社区反馈
- Discord：用户支持与参与
- 博客文章：重大功能公告
- 文档：发布说明和指南
产品路线图 🗺️#
当前重点#
后续领域#
长期愿景#
- 全球最佳开源目标检测方案
- 在所有平台上实现无缝部署
- 全面的计算机视觉工具包
- 社区驱动的创新
最佳实践 ✅#
功能开发#
- 从小处着手：先构建 MVP，之后再扩展
- 用户测试：尽早获取反馈
- 性能优先：从一开始就进行优化
- 做好文档：在构建过程中编写文档
发布管理#
- 全面测试：CI + 手动测试
- 清晰的变更日志：变更内容及其重要性
- 平滑升级：尽可能保持向后兼容
- 快速修复：不要让 Bug 长期存在
社区参与#
- 及时响应：在 24 小时内回复问题
- 透明公开：分享路线图和决策
- 心怀感谢：感谢贡献者
- 包容开放：欢迎各种技能水平的参与者