产品开发工作流 🚀

本指南涵盖 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）
性能基准达到目标
文档完整且准确
更新用户可见变更的更新日志
迁移指南（如有破坏性变更）
已记录回滚计划
已配置监控和告警

发布流程：

合并到 main：批准的 PR 自动合并
版本号升级：语义化版本（major.minor.patch）
打 Tag 发布：创建带更新日志的 GitHub release
PyPI 发布：自动部署到 Python Package Index
Docker 更新：构建并推送新容器镜像
文档发布：文档站自动更新

发布沟通：

博客文章：主要功能的技术深度解析
社交媒体：X、LinkedIn、Discord 公告
邮件简报：通知 5 万以上订阅者
发布视频：复杂功能的 YouTube 教程
社区互动：监控 Discord/GitHub，回应反馈

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

关注错误率、延迟、采用指标
4 小时内响应关键 bug
针对破坏性问题的热修复流程（< 24 小时周转）
收集用户反馈，优先处理快速胜利项

成功度量（前 2 周）：

采用率：升级用户的百分比
使用指标：API 调用、功能参与度
性能：推理速度、内存使用
用户反馈：GitHub 反应、Discord 投票
Bug 报告：关键 vs. 次要问题比例

发布流程 📦

版本管理

语义化版本：MAJOR.MINOR.PATCH

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

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

发布节奏

次要版本：每 2-4 周
修订版本：根据关键修复需要
主版本：引入破坏性变更时

发布清单

热修复流程

关键 bug 的处理：

从最新发布 tag 创建 hotfix/ 分支
修复问题，添加测试
快速通道评审
立即发布修订版
如需要则反向移植到 main

功能优先级 📊

高优先级

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

中优先级

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

低优先级

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

已降级

仅服务单一用户的功能
过于复杂的实现
维护负担重的新增项
超出核心使命范围

指标与成功 📈

关键指标

GitHub Stars：社区关注度
PyPI 下载量：采用率
Issue 响应时间：支持质量
PR 合并时长：开发速度
性能基准：速度/准确度的提升

功能成功标准

构建前定义：

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

沟通 💬

内部

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

外部

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

产品路线图 🗺️

当前重点

即将到来的领域

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

长期愿景

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

最佳实践 ✅

功能开发

从小处着手：先 MVP，再扩展
用户测试：尽早获取反馈
性能优先：从一开始就优化
文档完善：边构建边写文档

发布管理

充分测试：CI + 手动测试
清晰的更新日志：变更内容、为何重要
平滑升级：尽可能保持向后兼容
快速修复：不要让 bug 拖延

社区互动

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

资源 📚

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

Get Started