产品开发工作流 🚀#

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

产品理念 🎯#

核心原则#

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

开发价值观#

行动偏向：几天内完成原型，几周内发布，而不是几个月
数据驱动决策：GitHub stars、PyPI downloads、Discord polls 指导优先级
最小可行性产品：快速发布 80% 的解决方案，迭代至 100%
持续部署：main 分支随时可用于生产环境
极度透明：公开路线图、开放指标、社区投入

功能开发生命周期 🔄#

1. 发现与规划（第 1 周）#

通过以下方式识别需求：

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

进行评估：

用户影响：受影响的用户数量？痛点级别（1-10）？收入影响？
技术可行性：工程工作量（S/M/L/XL）？依赖项？风险？
战略契合度：推进 YOLO 领导地位？支持关键垂直领域？
资源可用性：团队产能？冲突的优先级？时间线？
竞争紧迫性：竞争对手会先发布吗？锁定风险？

产出：带有工作量估计和用户影响评分的优先级功能 backlog

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

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

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

对于小功能（<1 周工程时间）：

GitHub issue：清晰的问题描述、提议的方法、验收标准
快速讨论：与相关 engineers 进行 15 分钟同步
Go/No-go：经理批准继续推进

产出：具有明确范围、成功标准和时间线的已批准规范

3. 实现（Sprint 执行）#

Sprint 规划（每 2 周）：

Sprint 目标：每个 sprint 一个清晰的目标
任务拆解：将功能拆分为 <1 天的任务
产能规划：考虑会议、PR 评审、支持
依赖项：识别阻塞点，与其他团队协调

日常执行：

晨会（standup）（15 分钟）：昨天的进度、今天的计划、阻塞点
专注时间：4-6 小时深度工作，尽量减少会议
PR 评审：在 4 小时内评审队友的 PR
日终更新：Slack 进度更新，移动 tickets

开发最佳实践：

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

遵循详细的 development workflow 了解 PR 流程和代码标准。

4. 评审与 QA（与实现并行）#

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

<24 小时响应时间：高级工程师优先处理评审
质量检查：代码正确性、测试覆盖率、性能影响
安全评审：自动化扫描 + 针对敏感代码的手动评审
文档：验证 docs 已更新，示例可正常运行
所需批准：合并前需要 1 名以上高级工程师批准

QA 流程：

自动化测试：每次 commit 都运行单元测试、集成测试、E2E 测试
手动测试：QA 工程师验证关键用户流程
性能测试：与基准进行对比测试，标记性能倒退
跨平台：在 CPU、GPU、边缘设备上进行测试
用户验收：主要功能面向部分用户进行 Beta 测试

迭代周期：

立即处理反馈，不积累技术债
更改后重新测试，验证修复不会破坏其他功能
用进度更新 tickets，让利益相关者保持知情

5. 发布与上线#

发布前检查清单：

所有测试均已通过（单元测试、集成测试、E2E）
性能基准达到目标
文档完整且准确
Changelog 已更新面向用户的更改
迁移指南（如有破坏性更改）
回滚计划已记录
监控和警报已配置

发布流程：

合并到 main：已批准的 PR 自动合并
版本提升：语义化版本控制（major.minor.patch）
标记发布：创建带有 changelog 的 GitHub release
PyPI 发布：自动部署到 Python Package Index
Docker 更新：构建并推送新的容器镜像
Docs 部署：文档网站自动更新

上线沟通：

博客文章：针对主要功能的技术深度解析
社交媒体：X、LinkedIn、Discord 公告
电子邮件通讯：通知 50K+ 订阅者
发布视频：复杂功能的 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 周一次
补丁版本发布：根据需要用于关键修复
主要版本发布：引入破坏性更改时

发布检查清单#

热修复流程#

对于严重 bug：

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

功能优先级排序 📊#

高优先级#

影响用户的严重 bug
性能提升
安全问题
高度请求的功能（10+ 个社区请求）

中优先级#

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

低优先级#

锦上添花的功能
微小优化
极端情况处理

已降低优先级#

针对单个用户的功能
过于复杂的实现
维护成本高的添加项
超出核心使命范围

指标与成功 📈#

关键指标#

GitHub Stars：社区兴趣
PyPI Downloads：采用率
Issue Response Time：支持质量
PR Merge Time：开发速度
Performance Benchmarks：速度/准确率提升

功能成功标准#

在构建前定义：

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

沟通 💬#

内部#

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

外部#

GitHub Discussions：社区反馈
Discord：用户支持与互动
Blog Posts：重大功能公告
Documentation：发布说明和指南

产品路线图 🗺️#

当前重点#

后续领域#

长期愿景#

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

最佳实践 ✅#

功能开发#

从头做起：先做 MVP，再行扩展
用户测试：尽早获取反馈
性能第一：从一开始就进行优化
做好文档：在构建的同时编写文档

版本发布管理#

彻底测试：CI + 手动测试
清晰的变更日志：变了什么，为什么重要
平滑升级：尽可能保持向后兼容
快速修复：别让 Bug 拖延

社区参与#

响应迅速：在 24 小时内回复 issue
透明公开：分享路线图和决策
心怀感激：感谢贡献者
包容开放：欢迎所有技能水平的人

资源 📚#

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

贡献者

GLglenn-jocher⁶

创建时间 2025年8月27日更新时间 3个月前