WhisperLiveKit 贡献指南从 Bug 报告、开发环境搭建到可验证 Pull Request 的完整流程【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit本指南以仓库根目录的 CONTRIBUTING.md 为骨架结合仓库内的 pyproject.toml、CI 工作流、PR 模板、Issue 模板 与 benchmarks/README.md 等实际文件完整讲解 WhisperLiveKit 的贡献规范。读完本文你将掌握如何用最小可复现信息报告流式 ASR 相关的缺陷、如何在本机复现 CI 的完整校验命令、如何判断一个场景是否值得写测试以及如何提交一份经得起审阅、性能声明有据可查的 Pull Request。一、参与的边界哪些贡献受欢迎WhisperLiveKit 欢迎的贡献类型非常聚焦Bug 修复、文档、测试以及边界清晰的功能特性focused features。这里不鼓励大而全的重写或与主线无关的扩展——项目同时维护 OpenAI/Deepgram 兼容 API、流式 ASR、说话人分离与翻译等多个子系统任何改动都可能牵动接口契约与实时管线行为因此小而明确的变更远比大而模糊的变更更受欢迎。所有参与行为都遵循仓库的 行为准则 CODE_OF_CONDUCT.md这一点在 CONTRIBUTING.md 开篇即被强调也是参与的前提。二、先报告问题再动手修仓库要求参与者在动手之前先搜索已有的 issues 和 discussions避免重复提交。报告 Bug 时CONTRIBUTING.md 明确要求包含以下信息复现所用的命令或 Python 配置启动命令、后端策略、相关参数后端与模型如 faster-whisper、Canary、FunASR、simulstreaming 策略等操作系统、Python 版本、硬件完整的traceback / 日志期望行为与实际行为的对比若可以共享附上一段小体积可复现音频样本。这些字段与仓库内的 Bug 报告模板 .github/ISSUE_TEMPLATE/bug_report.yml 一一对应。模板中还要求填写的环境占位示例非常具体可直接照抄填写WhisperLiveKit: 0.x.y Install: pip OS: Ubuntu 24.04 Python: 3.12 Backend: faster-whisper Policy: simulstreaming Model: base Device: CPU模板要求报告者在提交前勾选“已搜索已有 issue/discussion”与“已用最新 release 或 main 分支复现”这说明仓库对可复现性的看重程度高于一切。安装使用类问题、方向性讨论请走 Discussions而安全问题绝不能走公开 issue——应按 SECURITY.md 走私有漏洞报告流程报告需包含受影响版本/提交、影响范围、复现步骤、相关配置与建议的缓解方案并事先移除凭据与私人数据。三、开发环境搭建CONTRIBUTING.md 给出的标准搭建流程如下git clone --recurse-submodules https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit.git cd WhisperLiveKit uv sync --extra test如果克隆时未带子模块可随时补充初始化git submodule update --init --recursive这里的“子模块”指向third_party/qwen3-asr-causal见 pyproject.toml 中[tool.uv.sources]的qwen3-asr-causal { path third_party/qwen3-asr-causal, editable true }是 Qwen3 流式 ASR 的本地源码依赖必须检出才能解析依赖。3.1 Python 版本与主开发版本从 pyproject.toml 的requires-python 3.11, 3.14可以确认支持 Python 3.11–3.13主开发版本是 3.12。这与 CI 的import-check任务在 3.11/3.12/3.13 三个版本矩阵上验证导入一致也与lint、test任务固定使用python-version: 3.12一致见 .github/workflows/ci.yml。建议贡献者在 3.12 下开发但改动涉及多版本兼容时应关注 3.11 与 3.13 的差异。3.2 按需安装后端 extras仓库通过uv sync的可选依赖extras来管理各后端CONTRIBUTING.md 要求“安装你正在修改的那个后端的 extra”。从 pyproject.toml 的[project.optional-dependencies]可以看到完整矩阵extra用途关键依赖test运行测试套件pytest、pytest-asyncio、datasets、deepgram-sdk7.8.1、psutil、matplotlibtranslation翻译后端nllwfunasrFunASR 后端funasr~1.4.1mlx-whisper/voxtral-mlxApple Silicon 上的 MLX 推理mlx、mlx-whisper仅 macOS arm64voxtral-hfVoxtral HF 流式后端transformers5.2.0、mistral-common[audio]、accelerateqwen3-vllm/qwen3-vllm-metal/qwen3-streamingQwen3 ASR 各推理模式qwen3-asr-causal 的 vllm / metal / streaming 变体canaryNeMo Canary 后端nemo-toolkit[asr]3.0,4、kaldialign、onnxdiarization-sortformerSortFormer 说话人分离nemo-toolkit[asr]3.0,4、onnxdiarization-diartDiart 说话人分离diart0.9.2仅 Python 3.13cu129/cpuPyTorch 计算后端CUDA 12.9 / CPU 版 torch 与 torchaudiolisten麦克风输入sounddevice值得注意的是pyproject.toml 还声明了大量extras 互斥冲突[tool.uv]下的conflicts列表例如cpu与cu129、qwen3-vllm与voxtral-hf、mlx-llm-mt与qwen3-streaming等不能同时安装。贡献者在安装多个后端进行联调时应先查阅该列表避免在冲突的依赖组合上浪费排障时间。3.3 测试跳过机制“有些测试在缺少可选后端依赖时会跳过skip”——这是理解本仓库测试结果的关键。仓库的测试目录 tests/ 中test_canary_backend.py、test_funasr_backend.py、test_sortformer_real_fixture.py 等后端测试都需要对应的 NeMo / FunASR / SortFormer 依赖或模型权重才能真实运行。当你看到测试被跳过先检查 skip 原因通常是缺少对应 extra再决定是安装依赖还是把该场景视为“需在 CI 或具备条件的机器上验证”。CI 的test任务只安装.[test]加 qwen3-asr-causal因此 NeMo/FunASR 场景天然依赖开发者本地按需安装验证。四、本地验证四件套让 CI 在你机器上先跑一遍CONTRIBUTING.md 给出了贡献者提交前必须通过的校验命令uv run ruff check . uv lock --check uv run pytest -q tests/ --ignoretests/test_pipeline.py --ignoretests/test_asr_coalescing_pipeline.py这三条命令与 CI 的lint和test任务逐字对应见 .github/workflows/ci.ymlruff check .代码风格与静态检查。仓库在 pyproject.toml 中固定ruff0.16.*、line-length 120并针对whisperlivekit/whisper/*等目录做了 per-file ignores如 F401/F841说明 vendored 的 whisper 代码不纳入全量严格检查uv lock --check校验锁文件 uv.lock 与依赖声明一致。CI 同样固定uv0.10.*来执行该检查任何依赖变更都必须同时更新锁文件主测试套件排除两个真实音频管线测试后跑全量单元/回归测试。这两个测试文件之所以被排除是因为它们要下载模型与真实音频、按实时速度喂数据不适合作为每次提交的快速回归。4.1 真实音频测试CI 单独运行的场景CI 中另有一个独立的测试步骤专门运行真实音频测试见 ci.yml 中 “Verify Whisper streaming boundaries with real audio” 步骤uv run pytest -q tests/test_asr_coalescing_pipeline.py这一步会下载 Whisper tiny 模型和 LibriSpeech 音频并以 1.0 倍实时速度喂给管线覆盖三类边界场景流结束end-of-stream、长静音silence、说话人切换speaker change。从 tests/test_asr_coalescing_pipeline.py 的模块 docstring 可以看出这些测试的深层意图管线使用 LocalAgreement 策略finish()不做推理HypothesisBuffer只有连续两次一致通过后才提交 token因此流结束前尚未经过第二遍确认的延迟音频可能被静默丢弃说话人切换会重置假设缓冲因此边界处的第二遍确认必须先于new_speaker()的重置被发出音频必须以speed1.0喂入——若用speed0整段音频会作为一个 chunk 一次性到达永远不会有延迟音频测试会“假阳性通过”。测试本身通过对比“coalescing 开启asr_coalesce_min_s0.75与关闭0.0”两条路径的转录尾部是否一致、以及推理调用次数是否显著减少来证明音频聚合coalescing不丢字且确实减少了推理调用。4.2 针对流式改动的定向验证CONTRIBUTING.md 特别提醒凡是改动到流式处理、缓冲、时间戳、模型加载或静音处理的贡献者都应运行相关真实模型场景uv run pytest -v tests/test_pipeline.py -k whisper-k whisper会筛选 tests/test_pipeline.py 中与 Whisper 相关的用例。需要注意完整管线矩阵可能下载大型模型因此文档同时要求记录选定的测试、后端、硬件与结果——这既是复现性的要求也是对审阅者负责的表现。五、什么才值得写一个测试CONTRIBUTING.md 用一整节定义了测试的取舍标准核心原则是优先写那些在“用户可见契约”被破坏时会失败的场景。文档明确列举了四类典型的用户可见契约停顿处丢词lost words at a pause重复的最终事件repeated final event如重复推送的结束事件会话语言泄漏leaked session language多会话/多语言场景下语言状态串扰字幕格式错误malformed subtitles或翻译结果永远到不了客户端a translation that never reaches the client。当已有场景已经覆盖了受影响的代码路径时优先扩展现有场景而非新写一个。同时文档明确反对三类低价值测试只重复常量的测试测试没有独立判断力断言私有调用顺序的测试与实现细节强耦合重构即碎用 mock 重建实现的测试等于把实现抄了一遍测不出实现错误。测试数量和覆盖率本身不是目标。这句话在仓库里是字面成立的——真正的目标是对用户可观察行为的保护。文档还点出了一个重要的方法论区分真实 WebSocket 协议检查与真实音频模型检查回答的是不同的问题二者不能互相替代。协议层测试验证的是消息契约与事件时序真实音频测试验证的是模型与流式缓冲在真实输入下的行为。贡献者应根据改动触及的层次选择对应的测试类型。六、Pull Request 规范CONTRIBUTING.md 对 PR 的要求可以总结为“聚焦、透明、可验证”保持改动聚焦一个 PR 解决一个问题解释清楚说明问题本身、改动后的行为、兼容性影响以及验证方式接口变化时同步更新示例仓库的示例/文档必须与代码一致排除无关内容不相关的格式化改动、生成文件、以及“生成的署名尾注”generated attribution trailers不应混入 PR除非是有意且已说明的兼容性变更否则保持公共 API 不变。这些要求与仓库的 PR 模板 .github/pull_request_template.md 完全对应。模板要求填写四个板块Summary改了什么、为什么改User impact行为、兼容性、性能、迁移影响Validation所用的确切测试、基准、硬件与模型Checklist搜索过 issue、补充/更新测试、更新文档、跑过ruff check .、跑过相关 pytest、未提交凭据/权重/缓存/私人数据。对照模板做最终自检是提交前最省事也最稳妥的一步。七、性能声明的证据门槛CONTRIBUTING.md 的最后一节给出了一条硬性规则性能声明必须有可复现的证据并指向 benchmarks/README.md 作为必须遵守的数据与测量规范。这意味着提交 PR 声称“延迟降低/内存减少/准确率提升”时必须提供完整的测量报告而不是一句口头结论基准必须满足可复现性要求使用固定的语料清单 benchmarks/corpora/fleurs-90.json30 条英语、30 条法语、30 条中文来自 FLEURS test split 的固定修订版音频本地缓存并校验哈希报告的 JSON 中包含假设文本、参考文本、WER/CER 编辑计数、错误明细、音频哈希、有效配置、依赖版本、硬件、源提交与工作区状态测量指标有严格定义ASR RTF推理调用耗时/音频时长、首屏文本延迟仅 speed 1 下测量非逐词延迟、结束排水耗时finalization、源端滞后source-end lag、进程 RSS每 50ms 采样一次的过程峰值与 MLX 内存峰值等基准命令的标准形式详见 benchmarks/README.mdpip install whisperlivekit[test] python scripts/prepare_fleurs_benchmark.py wlk bench --backend faster-whisper --model base --languages en \ --manifest benchmarks/corpora/fleurs-90.json --warmup --repeats 3 \ --speed 1 --json results.json特别值得注意的证据边界仅凭别名如base不能锁定模型版本发布对比前必须将别名解析到具体快照下载行为不能计入测量时间失败的样本必须保留并可见不允许静默丢弃后只报成功结果。文档还给出了一个具体的后端入选门槛示例——首批 M5 后端选择要求“finalization p95 或实测内存有至少 20% 的可复现改进、WER/CER 至多恶化 1 个绝对百分点、且无流式缺陷”并需检查三轮预热后的每一轮结果而非只看汇总。这类门槛说明在 WhisperLiveKit 里性能结论必须经得起逐样本、逐轮次的复核。八、结语把“可验证”贯穿贡献全流程回顾 CONTRIBUTING.md 的完整脉络可以看到一条贯穿始终的主线——可验证性报告问题要给出最小复现与完整环境搭建环境要用锁文件锁定依赖本地校验要与 CI 逐字一致测试要围绕用户可见契约而非实现细节PR 要说明行为影响并附上验证记录性能声明要提供可复现的测量数据。遵循这套流程既能保护流式 ASR 管线这类时序敏感系统不因贡献而退化也能让维护者与审阅者以最低成本确认你的改动安全、正确、可合并。如果你准备动手贡献建议按以下顺序走完整个流程阅读 CONTRIBUTING.md 与 CODE_OF_CONDUCT.md → 搜索已有 issue 确认无重复 → 用uv sync --extra test搭建环境 → 跑通第四节的全部校验命令 → 编写针对用户可见契约的测试 → 按 PR 模板 提交说明 → 若涉及性能声明按 benchmarks/README.md 的规范补齐测量证据。【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
WhisperLiveKit 贡献指南：从 Bug 报告、开发环境搭建到可验证 Pull Request 的完整流程
WhisperLiveKit 贡献指南从 Bug 报告、开发环境搭建到可验证 Pull Request 的完整流程【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit本指南以仓库根目录的 CONTRIBUTING.md 为骨架结合仓库内的 pyproject.toml、CI 工作流、PR 模板、Issue 模板 与 benchmarks/README.md 等实际文件完整讲解 WhisperLiveKit 的贡献规范。读完本文你将掌握如何用最小可复现信息报告流式 ASR 相关的缺陷、如何在本机复现 CI 的完整校验命令、如何判断一个场景是否值得写测试以及如何提交一份经得起审阅、性能声明有据可查的 Pull Request。一、参与的边界哪些贡献受欢迎WhisperLiveKit 欢迎的贡献类型非常聚焦Bug 修复、文档、测试以及边界清晰的功能特性focused features。这里不鼓励大而全的重写或与主线无关的扩展——项目同时维护 OpenAI/Deepgram 兼容 API、流式 ASR、说话人分离与翻译等多个子系统任何改动都可能牵动接口契约与实时管线行为因此小而明确的变更远比大而模糊的变更更受欢迎。所有参与行为都遵循仓库的 行为准则 CODE_OF_CONDUCT.md这一点在 CONTRIBUTING.md 开篇即被强调也是参与的前提。二、先报告问题再动手修仓库要求参与者在动手之前先搜索已有的 issues 和 discussions避免重复提交。报告 Bug 时CONTRIBUTING.md 明确要求包含以下信息复现所用的命令或 Python 配置启动命令、后端策略、相关参数后端与模型如 faster-whisper、Canary、FunASR、simulstreaming 策略等操作系统、Python 版本、硬件完整的traceback / 日志期望行为与实际行为的对比若可以共享附上一段小体积可复现音频样本。这些字段与仓库内的 Bug 报告模板 .github/ISSUE_TEMPLATE/bug_report.yml 一一对应。模板中还要求填写的环境占位示例非常具体可直接照抄填写WhisperLiveKit: 0.x.y Install: pip OS: Ubuntu 24.04 Python: 3.12 Backend: faster-whisper Policy: simulstreaming Model: base Device: CPU模板要求报告者在提交前勾选“已搜索已有 issue/discussion”与“已用最新 release 或 main 分支复现”这说明仓库对可复现性的看重程度高于一切。安装使用类问题、方向性讨论请走 Discussions而安全问题绝不能走公开 issue——应按 SECURITY.md 走私有漏洞报告流程报告需包含受影响版本/提交、影响范围、复现步骤、相关配置与建议的缓解方案并事先移除凭据与私人数据。三、开发环境搭建CONTRIBUTING.md 给出的标准搭建流程如下git clone --recurse-submodules https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit.git cd WhisperLiveKit uv sync --extra test如果克隆时未带子模块可随时补充初始化git submodule update --init --recursive这里的“子模块”指向third_party/qwen3-asr-causal见 pyproject.toml 中[tool.uv.sources]的qwen3-asr-causal { path third_party/qwen3-asr-causal, editable true }是 Qwen3 流式 ASR 的本地源码依赖必须检出才能解析依赖。3.1 Python 版本与主开发版本从 pyproject.toml 的requires-python 3.11, 3.14可以确认支持 Python 3.11–3.13主开发版本是 3.12。这与 CI 的import-check任务在 3.11/3.12/3.13 三个版本矩阵上验证导入一致也与lint、test任务固定使用python-version: 3.12一致见 .github/workflows/ci.yml。建议贡献者在 3.12 下开发但改动涉及多版本兼容时应关注 3.11 与 3.13 的差异。3.2 按需安装后端 extras仓库通过uv sync的可选依赖extras来管理各后端CONTRIBUTING.md 要求“安装你正在修改的那个后端的 extra”。从 pyproject.toml 的[project.optional-dependencies]可以看到完整矩阵extra用途关键依赖test运行测试套件pytest、pytest-asyncio、datasets、deepgram-sdk7.8.1、psutil、matplotlibtranslation翻译后端nllwfunasrFunASR 后端funasr~1.4.1mlx-whisper/voxtral-mlxApple Silicon 上的 MLX 推理mlx、mlx-whisper仅 macOS arm64voxtral-hfVoxtral HF 流式后端transformers5.2.0、mistral-common[audio]、accelerateqwen3-vllm/qwen3-vllm-metal/qwen3-streamingQwen3 ASR 各推理模式qwen3-asr-causal 的 vllm / metal / streaming 变体canaryNeMo Canary 后端nemo-toolkit[asr]3.0,4、kaldialign、onnxdiarization-sortformerSortFormer 说话人分离nemo-toolkit[asr]3.0,4、onnxdiarization-diartDiart 说话人分离diart0.9.2仅 Python 3.13cu129/cpuPyTorch 计算后端CUDA 12.9 / CPU 版 torch 与 torchaudiolisten麦克风输入sounddevice值得注意的是pyproject.toml 还声明了大量extras 互斥冲突[tool.uv]下的conflicts列表例如cpu与cu129、qwen3-vllm与voxtral-hf、mlx-llm-mt与qwen3-streaming等不能同时安装。贡献者在安装多个后端进行联调时应先查阅该列表避免在冲突的依赖组合上浪费排障时间。3.3 测试跳过机制“有些测试在缺少可选后端依赖时会跳过skip”——这是理解本仓库测试结果的关键。仓库的测试目录 tests/ 中test_canary_backend.py、test_funasr_backend.py、test_sortformer_real_fixture.py 等后端测试都需要对应的 NeMo / FunASR / SortFormer 依赖或模型权重才能真实运行。当你看到测试被跳过先检查 skip 原因通常是缺少对应 extra再决定是安装依赖还是把该场景视为“需在 CI 或具备条件的机器上验证”。CI 的test任务只安装.[test]加 qwen3-asr-causal因此 NeMo/FunASR 场景天然依赖开发者本地按需安装验证。四、本地验证四件套让 CI 在你机器上先跑一遍CONTRIBUTING.md 给出了贡献者提交前必须通过的校验命令uv run ruff check . uv lock --check uv run pytest -q tests/ --ignoretests/test_pipeline.py --ignoretests/test_asr_coalescing_pipeline.py这三条命令与 CI 的lint和test任务逐字对应见 .github/workflows/ci.ymlruff check .代码风格与静态检查。仓库在 pyproject.toml 中固定ruff0.16.*、line-length 120并针对whisperlivekit/whisper/*等目录做了 per-file ignores如 F401/F841说明 vendored 的 whisper 代码不纳入全量严格检查uv lock --check校验锁文件 uv.lock 与依赖声明一致。CI 同样固定uv0.10.*来执行该检查任何依赖变更都必须同时更新锁文件主测试套件排除两个真实音频管线测试后跑全量单元/回归测试。这两个测试文件之所以被排除是因为它们要下载模型与真实音频、按实时速度喂数据不适合作为每次提交的快速回归。4.1 真实音频测试CI 单独运行的场景CI 中另有一个独立的测试步骤专门运行真实音频测试见 ci.yml 中 “Verify Whisper streaming boundaries with real audio” 步骤uv run pytest -q tests/test_asr_coalescing_pipeline.py这一步会下载 Whisper tiny 模型和 LibriSpeech 音频并以 1.0 倍实时速度喂给管线覆盖三类边界场景流结束end-of-stream、长静音silence、说话人切换speaker change。从 tests/test_asr_coalescing_pipeline.py 的模块 docstring 可以看出这些测试的深层意图管线使用 LocalAgreement 策略finish()不做推理HypothesisBuffer只有连续两次一致通过后才提交 token因此流结束前尚未经过第二遍确认的延迟音频可能被静默丢弃说话人切换会重置假设缓冲因此边界处的第二遍确认必须先于new_speaker()的重置被发出音频必须以speed1.0喂入——若用speed0整段音频会作为一个 chunk 一次性到达永远不会有延迟音频测试会“假阳性通过”。测试本身通过对比“coalescing 开启asr_coalesce_min_s0.75与关闭0.0”两条路径的转录尾部是否一致、以及推理调用次数是否显著减少来证明音频聚合coalescing不丢字且确实减少了推理调用。4.2 针对流式改动的定向验证CONTRIBUTING.md 特别提醒凡是改动到流式处理、缓冲、时间戳、模型加载或静音处理的贡献者都应运行相关真实模型场景uv run pytest -v tests/test_pipeline.py -k whisper-k whisper会筛选 tests/test_pipeline.py 中与 Whisper 相关的用例。需要注意完整管线矩阵可能下载大型模型因此文档同时要求记录选定的测试、后端、硬件与结果——这既是复现性的要求也是对审阅者负责的表现。五、什么才值得写一个测试CONTRIBUTING.md 用一整节定义了测试的取舍标准核心原则是优先写那些在“用户可见契约”被破坏时会失败的场景。文档明确列举了四类典型的用户可见契约停顿处丢词lost words at a pause重复的最终事件repeated final event如重复推送的结束事件会话语言泄漏leaked session language多会话/多语言场景下语言状态串扰字幕格式错误malformed subtitles或翻译结果永远到不了客户端a translation that never reaches the client。当已有场景已经覆盖了受影响的代码路径时优先扩展现有场景而非新写一个。同时文档明确反对三类低价值测试只重复常量的测试测试没有独立判断力断言私有调用顺序的测试与实现细节强耦合重构即碎用 mock 重建实现的测试等于把实现抄了一遍测不出实现错误。测试数量和覆盖率本身不是目标。这句话在仓库里是字面成立的——真正的目标是对用户可观察行为的保护。文档还点出了一个重要的方法论区分真实 WebSocket 协议检查与真实音频模型检查回答的是不同的问题二者不能互相替代。协议层测试验证的是消息契约与事件时序真实音频测试验证的是模型与流式缓冲在真实输入下的行为。贡献者应根据改动触及的层次选择对应的测试类型。六、Pull Request 规范CONTRIBUTING.md 对 PR 的要求可以总结为“聚焦、透明、可验证”保持改动聚焦一个 PR 解决一个问题解释清楚说明问题本身、改动后的行为、兼容性影响以及验证方式接口变化时同步更新示例仓库的示例/文档必须与代码一致排除无关内容不相关的格式化改动、生成文件、以及“生成的署名尾注”generated attribution trailers不应混入 PR除非是有意且已说明的兼容性变更否则保持公共 API 不变。这些要求与仓库的 PR 模板 .github/pull_request_template.md 完全对应。模板要求填写四个板块Summary改了什么、为什么改User impact行为、兼容性、性能、迁移影响Validation所用的确切测试、基准、硬件与模型Checklist搜索过 issue、补充/更新测试、更新文档、跑过ruff check .、跑过相关 pytest、未提交凭据/权重/缓存/私人数据。对照模板做最终自检是提交前最省事也最稳妥的一步。七、性能声明的证据门槛CONTRIBUTING.md 的最后一节给出了一条硬性规则性能声明必须有可复现的证据并指向 benchmarks/README.md 作为必须遵守的数据与测量规范。这意味着提交 PR 声称“延迟降低/内存减少/准确率提升”时必须提供完整的测量报告而不是一句口头结论基准必须满足可复现性要求使用固定的语料清单 benchmarks/corpora/fleurs-90.json30 条英语、30 条法语、30 条中文来自 FLEURS test split 的固定修订版音频本地缓存并校验哈希报告的 JSON 中包含假设文本、参考文本、WER/CER 编辑计数、错误明细、音频哈希、有效配置、依赖版本、硬件、源提交与工作区状态测量指标有严格定义ASR RTF推理调用耗时/音频时长、首屏文本延迟仅 speed 1 下测量非逐词延迟、结束排水耗时finalization、源端滞后source-end lag、进程 RSS每 50ms 采样一次的过程峰值与 MLX 内存峰值等基准命令的标准形式详见 benchmarks/README.mdpip install whisperlivekit[test] python scripts/prepare_fleurs_benchmark.py wlk bench --backend faster-whisper --model base --languages en \ --manifest benchmarks/corpora/fleurs-90.json --warmup --repeats 3 \ --speed 1 --json results.json特别值得注意的证据边界仅凭别名如base不能锁定模型版本发布对比前必须将别名解析到具体快照下载行为不能计入测量时间失败的样本必须保留并可见不允许静默丢弃后只报成功结果。文档还给出了一个具体的后端入选门槛示例——首批 M5 后端选择要求“finalization p95 或实测内存有至少 20% 的可复现改进、WER/CER 至多恶化 1 个绝对百分点、且无流式缺陷”并需检查三轮预热后的每一轮结果而非只看汇总。这类门槛说明在 WhisperLiveKit 里性能结论必须经得起逐样本、逐轮次的复核。八、结语把“可验证”贯穿贡献全流程回顾 CONTRIBUTING.md 的完整脉络可以看到一条贯穿始终的主线——可验证性报告问题要给出最小复现与完整环境搭建环境要用锁文件锁定依赖本地校验要与 CI 逐字一致测试要围绕用户可见契约而非实现细节PR 要说明行为影响并附上验证记录性能声明要提供可复现的测量数据。遵循这套流程既能保护流式 ASR 管线这类时序敏感系统不因贡献而退化也能让维护者与审阅者以最低成本确认你的改动安全、正确、可合并。如果你准备动手贡献建议按以下顺序走完整个流程阅读 CONTRIBUTING.md 与 CODE_OF_CONDUCT.md → 搜索已有 issue 确认无重复 → 用uv sync --extra test搭建环境 → 跑通第四节的全部校验命令 → 编写针对用户可见契约的测试 → 按 PR 模板 提交说明 → 若涉及性能声明按 benchmarks/README.md 的规范补齐测量证据。【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
