开源贡献者的屏幕录制指南

开源项目的贡献方式正变得越来越直观。屏幕录制能帮助维护者更快理解你的改动，让 Bug 报告无可辩驳，也让你的 Pull Request 获得应有的背景说明。无论你是第一次参与贡献，还是经验丰富的维护者，这篇指南都将教你如何用 Recorded 提升开源工作流的效率。

为什么屏幕录制在开源中如此重要

文字描述终究有其局限。一段 30 秒的屏幕录制，可以取代好几段文字说明，彻底消除”你到底看到了什么、尝试了什么、你的修复究竟做了什么”这类歧义。

开源维护者每周要审查数十个 Issue 和 PR。一段清晰的视频演示能让你的提交脱颖而出，更快得到合并。

录制真正有效的 Bug 报告

作为报告者，你能做的最有价值的事，就是把 Bug 发生的过程录下来。视频 Bug 报告的优势在于：

• 消除歧义：维护者能看到和你一样的画面
• 加速分诊：无需来回追问复现步骤
• 证明可复现性：说明这不是偶发问题

如何录制一份优质的 Bug 报告

1. 捕捉完整上下文：在触发 Bug 之前就开始录制，让维护者看到操作前的环境
2. 使用缩放效果：用 Recorded 的缩放功能高亮显示出问题的 UI 元素或错误信息
3. 包含控制台输出：在 UI 旁边同时展示浏览器开发者工具或终端输出
4. 保持简短：30 到 90 秒最为理想，用编辑器剪掉无效等待时间

用视频演示 Pull Request

在 PR 描述中附上前后对比的屏幕录制，能大幅提升审查者的信心。维护者无需在本地拉取分支，就能直接看到你的改动是否有效。

PR 演示应该展示什么

• 问题所在：简短呈现原本的异常行为（10 到 15 秒）
• 你的修复：清晰演示修复后的效果
• 边界情况：展示相邻功能仍能正常运行
• 代码讲解（可选）：在编辑器中浏览关键改动

分段录制各个部分，再用 Recorded 的剪裁工具将各段干净地拼接在一起。

创建项目文档与操作指南

如果你是开源项目的维护者，视频文档的回报相当丰厚。新贡献者能更快上手，常见问题也不会一遍遍出现在 Issue 里。

最有价值的文档视频类型

• 快速上手：从克隆仓库到运行应用，2 到 3 分钟的完整操作流程
• 架构概览：配合解说，带领观众浏览代码库的目录结构
• 贡献指南：演示如何运行测试、格式化代码、提交 PR
• 功能演示：在 README 中为每个主要功能录制简短说明

将这些视频上传到项目的 GitHub Releases、Wiki，或在 README 中链接到专属的 YouTube 频道。

录制代码审查

异步视频代码审查在分布式团队中越来越受欢迎。与其撰写冗长的行内评论，不如录制你逐步审阅 diff 的过程。

视频代码审查的优势：

• 语气更清晰（不会让文字被误解为苛刻）
• 说话时可以直接指向特定代码行
• 审查者用更少时间涵盖更多内容

使用 Recorded 的光标高亮功能，让观看者能跟上你指向的位置。

开源屏幕录制的实用技巧

视频要简短：开源维护者都是志愿者，时间有限。Bug 报告尽量控制在 2 分钟以内，PR 演示控制在 3 分钟以内。

使用干净的环境：关闭无关的标签页和应用。使用专用的浏览器配置文件进行录制。

添加文字说明：利用 Recorded 的文字叠加功能，为各段内容标注”修复前”与”修复后”，或”Bug”与”已修复”。

简单 Bug 可导出为 GIF：对于简短的、循环播放的 UI Bug，直接在 Issue 中嵌入 GIF 比视频更易于即时查看。

合理选择托管方式：GitHub 的 Issue 和 PR 支持直接上传视频。较长的文档视频则适合用 YouTube 不公开链接分享。

开始使用

打开 Recorded，选择窗口捕获模式，只录制你的浏览器或代码编辑器；开启麦克风进行解说，然后点击录制。录制完成后，剪掉无效等待时间，添加缩放效果突出关键时刻，最后导出即可。

你的下一份 Bug 报告或 PR，将不言自明。