产品开发工作流 🚀#
本指南介绍 Ultralytics 产品的产品规划、开发周期和发布流程。
产品理念 🎯#
核心原则#
- 快速交付，更快学习：采用 2 周迭代周期，以 MVP 优先
- 以用户为中心：优先构建用户最常提出的功能，并用数据验证
- 开源优先：公开开发，由社区反馈推动路线图
- 性能即功能：推理时间低于 1 毫秒，内存占用极低
- API 优先设计：打造简单直观、深受开发者喜爱的 API
开发价值观#
- 崇尚行动：几天内完成原型，几周内交付，而不是几个月
- 数据驱动决策：根据 GitHub 星标数、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. 实施（冲刺执行）#
冲刺规划（每 2 周一次）：
- 冲刺目标：每个冲刺设定一个明确目标
- 任务拆解：将功能拆分为耗时不到 1 天的任务
- 产能规划：将会议、PR 评审和支持工作纳入考量
- 依赖项：识别阻碍因素，并与其他团队协调
每日执行：
- 早间站会（15 分钟）：昨天的进展、今天的计划、阻碍因素
- 专注时间：安排 4-6 小时深度工作，尽量减少会议
- PR 评审：在 4 小时内评审队友的 PR
- 每日收工更新：在 Slack 更新进展，推进工单
开发最佳实践：
- 功能开关：先部署但不启用，再逐步开放
- 测试覆盖率：发布前编写测试（目标覆盖率 >80%）
- 文档：在同一个 PR 中更新代码和文档
- 性能：比较变更前后的基准测试结果，避免性能退化
- 安全：运行安全扫描，并立即修复严重问题
遵循详细的开发工作流，了解 PR 流程和代码规范。
4. 评审与 QA（与实施并行）#
代码评审（所有 PR 都必须经过）：
- 24 小时内响应：高级工程师优先处理评审
- 质量检查：代码正确性、测试覆盖率、性能影响
- 安全评审：自动扫描，并对敏感代码进行人工评审
- 文档：确认文档已更新，示例可以正常运行
- 必须获得批准：合并前至少需要 1 位高级工程师批准
QA 流程：
- 自动化测试：每次提交都会运行单元、集成和端到端测试
- 手动测试：由 QA 工程师验证关键用户流程
- 性能测试：与基准进行比较，标记性能退化
- 跨平台测试：在 CPU、GPU 和边缘设备上测试
- 用户验收：大型功能邀请部分用户参与 Beta 测试
迭代周期：
- 立即处理反馈，不要积累技术债务
- 修改后重新测试，确认修复不会影响其他功能
- 更新工单进度，及时告知利益相关方
5. 发布与上线#
发布前检查清单：
- 所有测试均已通过（单元、集成、端到端）
- 性能基准测试达到目标
- 文档完整且准确
- 更新变更日志，说明面向用户的变更
- 迁移指南（如有破坏性变更）
- 已记录回滚计划
- 已配置监控和告警
发布流程：
- 合并到 main：获批的 PR 会自动合并
- 版本号递增：采用语义化版本控制（major.minor.patch）
- 标记发布版本：在 GitHub 创建发布条目并附上变更日志
- 发布到 PyPI：自动部署到 Python Package Index
- 更新 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（错误修复）
发布计划#
- 次要版本发布：每 2-4 周一次
- 补丁版本发布：根据需要修复严重问题
- 主要版本发布：引入不兼容变更时
发布检查清单#
- 所有 CI 测试均通过
- 文档已更新
- 变更日志已更新
- 版本号已递增
- 已创建 GitHub 发布版本
- 已发布 PyPI 软件包
- 已准备公告
热修复流程#
对于严重错误：
- 从最新发布标签创建
hotfix/分支 - 修复问题并添加测试
- 加速审核流程
- 立即发布补丁版本
- 如有需要，将修复向后移植到 main
功能优先级 📊#
高优先级#
- 影响用户的严重错误
- 性能改进
- 安全问题
- 用户强烈要求的功能（社区请求 10 次以上）
中优先级#
- 易用性改进
- 新的导出格式
- 扩展平台支持
- 文档改进
低优先级#
- 锦上添花的功能
- 小幅优化
- 边缘情况处理
降低优先级#
- 面向单个用户的功能
- 过于复杂的实现
- 维护成本高的新增内容
- 超出核心使命范围
指标与成功 📈#
关键指标#
- GitHub 星标数：社区关注度
- PyPI 下载量：采用率
- 问题响应时间：支持质量
- PR 合并时间：开发速度
- 性能基准测试：速度/精度改进
功能成功标准#
在开发前定义：
- 使用指标（下载量、API 调用次数）
- 性能目标（速度、精度）
- 用户反馈（GitHub 反应、评论）
- 采用率（使用该功能的用户百分比）
沟通 💬#
内部沟通#
- GitHub Issues：功能提案和错误报告
- Slack：快速讨论和更新
- 团队会议：每周同步优先事项
外部沟通#
- GitHub Discussions：社区反馈
- Discord：用户支持与互动
- 博客文章：重大功能公告
- 文档：发布说明和指南
产品路线图 🗺️#
当前重点#
即将开展的领域#
长期愿景#
- 打造全球最佳开源目标检测方案
- 在所有平台上实现无缝部署
- 提供全面的计算机视觉工具包
- 由社区驱动创新
最佳实践 ✅#
功能开发#
- 从小处着手：先推出 MVP，之后再扩展
- 用户测试：尽早获取反馈
- 性能优先：从一开始就进行优化
- 完善文档：开发过程中同步编写文档
发布管理#
- 全面测试：CI 测试 + 手动测试
- 清晰的更新日志：说明有哪些变更，以及这些变更为何重要
- 平滑升级：尽可能保持向后兼容
- 快速修复：不要让 bug 久拖不决
社区参与#
- 及时响应：在 24 小时内回复问题
- 透明公开：分享路线图和决策
- 心怀感激：感谢贡献者
- 包容开放：欢迎各种技能水平的人参与
资源 📚#
- 开发工作流 - PR 流程和规范
- CI/测试 - 测试和质量检查
- 文档 - 编写和维护文档
- GitHub Issues - 功能请求和 bug