产品开发流程 🚀

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

产品理念 🎯

核心原则

快速交付，加速学习: 2周迭代周期，MVP优先方法
以用户为中心: 构建用户需求最多的功能，并通过数据进行验证
开源优先: 公开开发，社区反馈驱动路线图
性能即功能: 亚毫秒级推理时间，最小内存占用
API优先设计: 开发者喜爱的简单直观的API

开发价值观

行动导向: 几天内完成原型设计，几周内发布，而不是几个月
数据驱动决策：GitHub 星级、PyPI 下载量、Discord 民意调查为优先事项提供指导
最小可行产品: 快速发布80%的解决方案，迭代至100%
持续部署: 主分支始终可用于生产
完全透明: 公开路线图、开放指标、社区意见

功能开发生命周期 🔄

1. 探索与规划（第1周）

识别需求 通过：

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

评估标准:

用户影响: 影响多少用户？痛苦程度（1-10）？收入影响？
技术可行性: 工程量（小/中/大/超大）？依赖性？风险？
战略一致性: 提升YOLO11的领导地位？支持关键垂直领域？
资源可用性: 团队能力？竞争优先级？时间表？
竞争紧迫性: 竞争对手会先发布吗？锁定风险？

输出: 确定优先级的功能积压，包括工作量估算和用户影响评分

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

对于主要功能（>2周的工程时间）：

设计文档: 问题陈述、建议的解决方案、考虑的替代方案、成功指标
技术规范: API设计、架构图、数据模型、边缘情况
成功标准: 定量指标（速度、准确性、采用率）和用户反馈目标
风险评估: 技术风险、依赖性、回滚计划
团队审查: 来自工程、产品和主要利益相关者的反馈

For small features (<1 week engineering time):

GitHub issue: 清晰的问题描述、建议的方法、验收标准
快速讨论: 与相关工程师同步15分钟
批准/不批准: 经理批准继续

输出: 批准的规范，包括明确的范围、成功指标和时间表

3. 实施（冲刺执行）

Sprint 计划（每 2 周）：

Sprint 目标: 每次 sprint 一个明确的目标
Task breakdown: Split features into <1 day tasks
容量规划: 考虑会议、PR 审查、支持
依赖项: 识别阻碍因素，与其他团队协调

每日执行:

早晨站立会议（15 分钟）：昨天的进展、今天的计划、阻碍因素
专注时间: 4-6 小时深度工作，尽量减少会议
PR 审查：在 4 小时内审查队友的 PR
每日结束更新：Slack 进度更新，移动工单

开发最佳实践：

功能标志：暗部署，逐步启用
测试覆盖率：在发布前编写测试（>80% 的覆盖率目标）
文档：在与代码相同的 PR 中更新文档
性能：前后基准测试，无衰退
安全性：运行安全扫描，立即修复严重问题

遵循详细的开发工作流程，了解 PR 流程和代码标准。

4. 审查与质量保证（与实施并行）

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

<24 hour response time: Senior engineers prioritize reviews
质量检查：代码正确性、测试覆盖率、性能影响
安全审查：自动化扫描 + 敏感代码的手动审查
文档：验证文档已更新，示例有效
需要批准：合并前需要 1 名以上高级工程师批准

QA 流程：

自动化测试：在每次提交时运行单元测试、集成测试、E2E 测试
手动测试：QA 工程师验证关键用户流程
性能测试：对照基线进行基准测试，标记衰退
跨平台：在 CPU、GPU、边缘设备上测试
用户验收：与部分用户进行 Beta 测试，以了解主要功能

迭代周期：

立即解决反馈，不要累积技术债务
更改后重新测试，验证修复不会破坏其他功能
使用进度更新工单，让利益相关者了解情况

5. 发布与启动

预发布清单：

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

发布流程：

合并到主分支：批准的 PR 自动合并
版本提升：语义化版本控制（主版本号.次版本号.修订号）
标记发布：创建包含变更日志的 GitHub 发布
PyPI 发布：自动部署到Python 软件包索引
Docker 更新：构建并推送新的容器镜像
文档部署：文档站点自动更新

启动沟通：

博客文章：针对主要功能的技术深度解析
社交媒体：X、LinkedIn、Discord 公告
电子邮件新闻稿：通知 50K+ 订阅者
发布视频：针对复杂功能的 YouTube 教程
社区互动：监控 Discord/GitHub，回复反馈

发布后监控（前 48 小时）：

观察错误率、延迟、采用率指标
在 4 小时内响应严重错误
Hotfix process for breaking issues (<24 hour turnaround)
收集用户反馈，优先处理快速成功事项

成功衡量（前 2 周）：

采用率：升级用户百分比
使用指标：API 调用、功能参与度
性能：推理速度、内存使用量
用户反馈：GitHub 反馈、Discord 投票
错误报告：严重问题与次要问题比例

发布流程 📦

版本控制

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

MAJOR：重大变更
MINOR：新功能，向后兼容
PATCH：错误修复

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

发布时间表

Minor 版本发布：每 2-4 周
Patch 版本发布：根据需要进行关键修复
Major 版本发布：引入重大变更时

发布清单

紧急修复流程

对于严重错误：

创建 hotfix/ 从最新发布标签创建分支
修复问题，添加测试
track 审查
立即发布补丁版本
如果需要，向后移植到主分支

功能优先级排序 📊

高优先级

影响用户的严重错误
性能改进
安全问题
高需求功能（10+ 社区请求）

中优先级

生活质量提升
新增导出格式
扩展平台支持
文档改进

低优先级

锦上添花的功能
小优化
边界情况处理

降低优先级

单用户功能
过于复杂的实现
维护量大的新增功能
超出核心任务范围

指标与成功 📈

关键指标

GitHub Stars: 社群关注度
PyPI 下载：采用率
Issue Response Time: 支持质量
PR合并时间: 开发速度
性能基准测试: 速度/准确率提升

功能成功标准

构建前定义：

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

沟通 💬

内部

GitHub Issues: 功能建议和错误
Slack: 快速讨论和更新
团队会议: 每周同步优先级

外部

GitHub Discussions: 社区反馈
Discord: 用户支持和互动
博客文章: 主要功能发布
文档: 发行说明和指南

产品路线图 🗺️

当前重点

未来领域

新的架构变体
增强的训练功能
改进的推理速度
扩展的平台支持

长期愿景

世界最佳开源对象 detect
在所有平台上无缝部署
综合计算机视觉工具包
社区驱动的创新

最佳实践 ✅

功能开发

从小处着手：先推出最小可行产品（MVP），再逐步扩展
用户测试：尽早获取反馈
性能优先：从一开始就进行优化
完善的文档：在构建时编写文档

发布管理

全面测试：持续集成（CI）+ 手动测试
清晰的变更日志：记录变更内容及其重要性
平滑升级：尽可能保持向后兼容
快速修复：不要让 Bug 长期存在

社区互动

快速响应：24 小时内回复问题
透明：分享路线图和决策
感谢：感谢贡献者
包容：欢迎所有技能水平的人

资源 📚

开发工作流程 - PR流程和标准
CI/测试 - 测试和质量检查
文档 - 编写和维护文档
GitHub Issues - 功能请求和 Bug

📅创建于1个月前 ✏️更新于1个月前