使用 GitHub Copilot CLI 通过对话构建音频分析器

Source: Dev.to

这是一篇提交作品，面向 GitHub Copilot CLI 挑战。

我构建的内容

mixref 是一个面向音乐制作人的 CLI 音频分析工具。它分析音频文件并提供：

• 响度指标
• BPM 检测
• 音乐调性识别
• 谱分析

问题

在制作音乐时，我经常需要：

• 检查不同流媒体平台的响度水平（LUFS）
• 快速检测 BPM 和音乐调性
• 将我的混音与参考曲目进行比较
• 查看频率分布

我想要一个快速的命令行工具，而不是打开 DAW 或多个插件。

它的功能

响度分析

• 测量 LUFS（EBU R128 标准）
• 显示真实峰值和响度范围
• 与平台目标进行比较（例如，Spotify：‑14 LUFS，YouTube：‑14 LUFS 等）

音乐分析

• 使用 librosa 检测 BPM
• 包含对半速检测的基本校正（在 3 % 阈值内时将 BPM 加倍）

演示

命令行界面

分析命令

比较命令

示例输出

$ mixref analyze track.wav

             Analysis: track.wav             
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━┓
┃ Metric              ┃        Value ┃ Status ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━┩
│ Integrated Loudness │    -6.2 LUFS │   🔴   │
│ True Peak           │    -0.8 dBTP │   ⚠️   │
│ Loudness Range      │       5.2 LU │   ℹ    │
├─────────────────────┼──────────────┼────────┤
│ Tempo               │    174.0 BPM │   ❓   │
│ Key                 │ F minor (4A) │   ❓   │
├─────────────────────┼──────────────┼────────┤
│ Sub                 │   ■■■■■■■□□□ │ 35.2%  │
│ Low                 │   ■■■■■■■■■□ │ 28.4%  │
│ Mid                 │   ■■■■□□□□□□ │ 18.1%  │
│ High                │   ■■■■■■□□□□ │ 14.2%  │
│ Air                 │   ■□□□□□□□□□ │  4.1%  │
└─────────────────────┴──────────────┴────────┘

亲自尝试

# Install from PyPI
pip install mixref

# Analyze a track
mixref analyze my_track.wav

# Compare against a reference
mixref compare my_mix.wav pro_reference.wav --bpm --key

我在 GitHub Copilot CLI 的体验

这个项目是 完全通过对话 与 GitHub Copilot CLI 完成的。我没有敲代码——我用自然语言描述了我的需求。

开发过程

1. 用描述代替编码

与其直接编写 Python 代码，我这样提问：

Create a function that calculates EBU R128 loudness using pyloudnorm.
Return integrated LUFS, true peak, and loudness range.
Include type hints and error handling.

Copilot 生成了：

• 一个使用 pyloudnorm 的可工作实现
• 完整的类型提示
• 针对边界情况的错误处理
• 带有示例的文档字符串

2. 通过对话进行调试

当 BPM 检测返回 0.0 时，我描述了问题：

"BPM detection returns 0.0. Librosa warning says:
'n_fft=2048 too large for input signal of length=2'
The stereo-to-mono conversion might be wrong."

Copilot：

• 找出了 bug（np.mean(audio, axis=0) 对数组形状不适用）
• 使用正确的格式检测进行了修复
• 更新了测试（所有测试仍然通过）

3. 构建开发工具

我请求一个 pre‑commit 质量检查脚本。Copilot 创建了 ./scripts/pre-commit-check.sh：

#!/usr/bin/env bash
echo "🔍 Running pre-commit quality checks..."
echo "1️⃣ Formatting with ruff"
echo "2️⃣ Linting"
echo "3️⃣ Type checking"
echo "4️⃣ Tests"
echo "🎉 All checks passed!"

该脚本可在推送到 GitHub Actions 之前捕获问题。

4. 测试与文档

我要求使用合成音频（不使用真实文件）编写测试。Copilot 生成了：

• 154 个测试，覆盖率约 90 %
• 生成正弦波和粉红噪声的 fixture
• 未提交任何真实音频文件

在文档方面，Copilot 设置了：

• 使用 Sphinx 的 API 文档
• 示例画廊
• 使用 termtosvg 记录的终端演示

工作良好

• 速度 – 构建功能快得多。原本可能需要数小时的工作，在专注的对话中完成。
• 代码质量 – 生成的代码遵循了我可能会跳过的约定：
  • 全程使用类型提示
  • 一致的错误处理
  • 完整的文档字符串
  • 良好的测试覆盖率（≈ 90 %）
• 学习 – 通过实现，我学习了音频处理概念（EBU R128、Camelot wheel），而不仅仅是阅读文档。
• 上下文 – Copilot 在会话之间记住了决策：
  • “使用 Rich 进行输出” → 所有命令都使用 Rich 表格
  • “测试中仅使用合成音频” → 仓库中没有真实文件
  • 整体保持一致的编码风格

挑战

• 不是魔法 – 我仍然需要：
  • 理解自己的需求
  • 审核并测试生成的代码
  • 修复边缘情况
  • 做出架构决策
• 迭代 – 有时第一次的解决方案并不完全正确。我学会了清晰描述问题并进行迭代。
• 真实音频测试 – 合成测试信号并不能捕获所有边缘情况。使用真实音频文件进行测试揭示了错误（例如 BPM 检测问题）。

真正的转变

Before: 思考 → 编码 → 调试 → 测试 → 修复
With Copilot CLI: 思考 → 描述 → 评审 → 测试

我把更多时间花在 构建什么 和 它应该如何工作 上，而把在语法和样板代码上的时间减少了。

指标

• 750 行 源代码
• 154 个测试（≈ 90 % 覆盖率）
• 19 个模块（全部进行类型检查）
• 3 个 CI/CD 工作流（测试、文档、质量检查）
• 完整的文档 使用 Sphinx

全部通过对话完成，而非手动编码。

经验教训

• 清晰的描述很重要 – 我描述得越清楚，得到的结果就越好。
• 审查所有内容 – 生成的代码需要测试和验证。
• 自然迭代 – “实际上，如果……？” 与 Copilot 配合良好。
• 测试至关重要 – 良好的测试能捕捉生成代码中的问题。

结论

GitHub Copilot CLI 改变了我进行开发的方式。与其敲代码，我更专注于描述问题和审查解决方案。

mixref 是一个功能性的音频分析工具。它正好满足我的需求；有趣的地方在于它的构建方式——完全通过对话完成。

试一试

pip install mixref
mixref analyze your_track.wav

源代码

github.com/Caparrini/mixref

使用 GitHub Copilot CLI 构建，并出于对 AI‑辅助开发的好奇。