记录跟踪2026年要做的事情和正在做的事情。

目标

• 健康生活

  • 体重减到60kg

• 探索可能

  • 英语能力，熟练3篇演讲短文
  • 独立开发，目标完成4个独立项目 –> 进度2/4
  • 公众号输出，目标输出文章10篇 –> 进度8/10

正在做的项目

• iOS双语字幕App

• 拼了还拼小游戏外挂

• asr from scratch

• 虚拟主播

一些随想

记录一些生活工作中一些小感受和小想法

• 2026.07.04

慢下来才能更快。

• 2026.05.24

You can outsource your thinking, but you can’t outsource your understanding.
思考可以外包，但理解不能外包
虽然现在AI进展神速，但是工作/学习的底层逻辑没有变化，AI只是加速了知识的获取和帮忙个人思考，对事情的理解过程还是存在于个人的大脑，这个是AI没法替你完成的。

• 2026.03.29

每天记录和量化进度，本身就是一种负担，而且对于效率提高帮助不大，也不利于长期任务，与其每天盯着任务进度， 不如现在开始试下，里程碑式的工作方法，给自己一段时间设定一些目标，到期后来检查完成情况，中间如何只记录 据有里程碑意义的事件。

如果把个人可以买到的设备限制在最多 128GB 统一内存，什么开源模型最适合 AI Coding？买 Mac Studio、AMD 大内存小主机、DGX Spark 或多显卡工作站，和直接调用在线 API 相比，哪一种更快、更便宜？

这篇文章只讨论 AI Coding Agent：模型需要读取代码仓库、调用终端、修改多个文件、执行测试，并根据报错继续迭代。普通聊天、知识问答和只补全下一行代码的 FIM 模型不在本文范围内。

为了让比较有实际采购意义，本文增加两个约束：

1. 本地设备的统一内存或可用于推理的总高速内存不超过 128GB；
2. 所有本地方案运行同一个开源模型，在线方案也尽量调用同名模型，避免把模型能力差异误算成硬件差异。

资料和价格更新至 2026 年 7 月 19 日。硬件价格按市场数量级估算，API 价格来自官方页面，实际采购价、汇率和服务价格可能变化。

一、先说结论

在 128GB 上限内，我选择 Qwen3-Coder-Next 作为本地 AI Coding 的比较样本。它不是所有维度都绝对最强，但在“开源许可、Coding Agent 能力、模型尺寸和本地推理效率”这几个条件同时成立时，是目前最有代表性的高端本地模型之一。

我的结论是：

1. 只为降低 Token 费用，不值得专门购买本地硬件。 同名模型的 Qwen Cloud API 在短上下文下，重度个人使用约 ¥216/月；一台 ¥2万～¥5万元的本地设备通常需要很多年才能靠 API 费差价回本。
2. 已有 64GB 以上 Mac 或 48GB 显存工作站时，本地部署很有价值。 Qwen3-Coder-Next 4bit 约需 46GB，模型完整装入后可以达到可交互的 Agent 速度。
3. 64GB 是能用，96GB～128GB 才是舒服。 64GB 在加载 4bit 权重后，留给操作系统、运行时和 KV Cache 的空间有限；96GB～128GB 更适合长上下文和并行工具任务。
4. 128GB 容量不等于高性能。 Ryzen AI Max+ 395 和 DGX Spark 都能装入模型，但生成速度会受到约 256～273GB/s 内存带宽限制；专业显卡带宽更高，但价格也高得多。
5. 个人最合理的模式仍然是混合使用。 敏感代码、离线任务和高频小修改走本地；长上下文、紧急任务和复杂重构走 API。

二、为什么选择 Qwen3-Coder-Next

Qwen3-Coder-Next 是专门面向 Coding Agent 和本地开发的 MoE 模型，采用 Apache-2.0 许可证。官方模型卡给出的核心参数如下：

• 总参数量 80B，每个 Token 激活约 3B；
• 原生上下文 262,144 Token；
• 只支持非思考模式；
• 支持函数调用和 OpenAI 兼容服务；
• 可接入 Qwen Code、Claude Code、Codex、Cline、Kilo 等 Coding 工具；
• 支持 llama.cpp、MLX-LM、Ollama、SGLang 和 vLLM 等后端。

公开 Coding 基准如下：

这些成绩会受到 Agent 框架、提示词、工具集和推理参数影响，不能理解为在任何 IDE 中都有固定成功率。不过它们至少说明，这个模型的目标不是生成几个函数，而是完成仓库级软件工程任务。

为什么不选择更大的模型

总参数更大的模型不一定适合本次硬件约束。例如 GLM-5.2 的最低实用量化也需要约 223GB～245GB 总内存，128GB 设备只能依赖大量 SSD 或远程卸载。它虽然能“启动”，但权重会频繁跨层级搬运，无法获得正常的 AI Coding 交互体验。

Qwen3-Coder-Next 的优势正好相反：总参数 80B，但每 Token 只激活约 3B。根据 Unsloth 的本地运行说明：

本文默认选择 4bit。它能在 64GB 设备上运行，又比 3bit 更稳；8bit 虽然更接近原始模型，但在 96GB 设备上只剩很少空间给 KV Cache，综合体验未必更好。

三、AI Coding 性能不能只看 Token/s

Coding Agent 的完整链路通常是：

1
2

理解需求 -> 搜索仓库 -> 阅读文件 -> 规划修改 -> 编辑代码
        -> 执行命令 -> 分析报错 -> 再次修改 -> 运行测试

因此需要同时比较四种性能：

• 任务成功率：能否最终通过测试，而不是只输出看起来正确的代码；
• 首 Token 延迟：提交任务后多久开始响应；
• 生成速度：模型持续输出时的 Token/s；
• 总完成时间：包括读取上下文、工具调用、失败重试和人工纠错。

本地部署最容易只关注生成速度，但 AI Coding 中经常更慢的是长提示词的 Prefill。一次输入 50K Token 的仓库上下文，即使后续输出很快，也可能在开始生成前等待很久。

另一个常见误区是把“支持 256K 上下文”理解成“应该默认开启 256K”。上下文越长，KV Cache、Prefill 时间和内存碎片越大。个人使用建议从 16K 或 32K 开始，让 Agent 通过代码搜索按需读取文件，再根据项目逐步提高。

四、本地部署方案对比

下面所有方案都以 Qwen3-Coder-Next 4bit、单用户 AI Coding 为基础。速度等级是综合容量、内存带宽、推理后端和是否发生卸载后的相对判断，不是厂商保证值。

Unsloth 给出的经验是：量化模型完整放入计算设备后，可期待 20+ Token/s；一旦模型不能完整装入而需要分层卸载，速度会明显下降。这个数字是模型级经验，不是对每一种硬件的实测承诺。

1. 64GB Mac Studio：能用，但要控制上下文

Mac 的 CPU 和 GPU 共用统一内存，不存在传统 PC 上“系统有 64GB，但显卡只能用 24GB”的硬边界。Qwen3-Coder-Next 4bit 约 46GB，64GB Mac 可以完整加载，并通过 llama.cpp、MLX-LM、Ollama 或 LM Studio 提供本地 API。

它的主要瓶颈不是计算单元数量，而是 剩余内存和内存带宽：

• 权重加载后只剩约 18GB，操作系统、运行时和 KV Cache 都要使用这部分空间；
• 上下文开得过大时容易触发内存压力和 Swap；
• 发生 SSD Swap 后，速度会从可交互迅速下降；
• Metal 对桌面推理很成熟，但新模型的高级优化通常晚于 CUDA 后端。

因此 64GB 更适合 4bit + 16K～32K 上下文，不适合追求 256K 满上下文。

2. 96GB Mac Studio M3 Ultra：Mac 路线的性能型选择

Apple 的技术规格显示，M3 Ultra 的统一内存带宽为 819GB/s。96GB 配置运行 46GB 的 4bit 模型时，可以给 KV Cache 和其他应用留下较大空间，比 64GB 配置更适合作为长期运行的本地 Coding 服务。

8bit 约需 85GB，看起来也能加载，但只剩约 11GB，容易被系统和长上下文吃完。实际使用更建议继续选择高质量 4bit，把容量留给上下文。

主要瓶颈是：

• 没有 CUDA，无法使用只提供 CUDA Kernel 的最新优化；
• 单用户速度不错，但多人并发能力不如专业 GPU 服务；
• 长上下文仍受 KV Cache 和 Prefill 时间限制；
• 设备价格远高于调用同名 API 的费用。

3. Ryzen AI Max+ 395 128GB：容量优先的 PC 小主机

Framework Desktop 等设备可配置 128GB LPDDR5x-8000 统一内存，官方称最多可提供 96GB 图形可寻址内存，采用 256-bit 内存总线。Qwen3-Coder-Next 4bit 可以宽裕运行，8bit 也有机会完整装入。

这条路线的优点是容量大、体积小、功耗低，并且保留 Linux/Windows 环境。主要瓶颈是：

• 统一内存带宽明显低于 M3 Ultra 和高端独立显卡；
• ROCm、Vulkan、llama.cpp 对新架构的优化程度不完全一致；
• “模型能装入”不代表 GPU 能以独显级速度完成推理；
• Windows、Linux 和不同驱动版本的实际表现可能差异较大。

它适合把“运行更大模型和更长上下文”放在第一位的人，不适合单纯追求最快 Token/s。

4. DGX Spark：128GB + CUDA，但不是大显存显卡的速度

NVIDIA DGX Spark 使用 GB10 Grace Blackwell Superchip，提供 128GB 一致性内存和 NVIDIA AI 软件栈。它的价值是小体积、CUDA 环境和大容量可以同时获得，部署容器、NIM、PyTorch、SGLang 和 vLLM 类工具更接近 NVIDIA 服务器工作流。

它的核心瓶颈是约 273GB/s 内存带宽。这远低于 RTX 5090 和 RTX PRO 6000，因此不能因为名字中有“DGX”就预期获得数据中心 GPU 的生成速度。其他限制还包括 ARM64 环境的软件兼容、部分 Python Wheel 和第三方工具需要重新验证。

DGX Spark 更适合学习和验证 CUDA 部署栈，未必是单用户桌面 AI Coding 的最高性价比方案。

5. 双 RTX 3090：最便宜的 48GB CUDA 路线

两张 RTX 3090 合计有 48GB 显存，接近 4bit 模型约 46GB 的大小。它的显存带宽高、CUDA 生态成熟，二手整机价格也低于新款大内存设备。

问题是两张显卡的显存不会自动变成一块无缝的 48GB：

• 推理框架必须支持 Tensor Split 或 Tensor Parallel；
• 4bit 权重几乎占满显存，KV Cache 余量很小；
• 跨卡通信受 PCIe 或 NVLink 限制；
• 两张卡的额定功耗合计可达约 700W；
• 二手显卡还存在显存稳定性和维修历史风险。

更现实的做法是使用 3bit，或者把少量层和 KV Cache 放到系统内存。代价是量化质量或速度下降。

6. RTX 5090 + 128GB 系统内存：显卡快，卸载慢

RTX 5090 有 32GB 显存，无法完整装下约 46GB 的 4bit 模型。llama.cpp 可以把一部分层留在系统内存，从而让模型运行起来。

这条路线的瓶颈非常明确：CPU 中的权重要经过系统内存和 PCIe，不能享受显卡本地 GDDR7 的完整带宽。模型越多层卸载到 CPU，生成速度越接近系统内存方案，而不是 5090 的理论性能。

如果已经拥有 5090，这是一条新增成本很低的尝试路线；如果准备新购设备专门运行 Qwen3-Coder-Next，则不如直接选择能完整容纳模型的硬件。

7. RTX PRO 6000 Blackwell：性能最好，成本最差

RTX PRO 6000 Blackwell 提供 96GB GDDR7 ECC 显存和约 1792GB/s 带宽。Qwen3-Coder-Next 4bit 可以完整装入，并为 KV Cache 和并发保留大量空间，是本文本地方案中性能最接近理想状态的一种。

它的主要瓶颈不是技术，而是价格：单卡价格已经超过大多数个人工作站。只有在多人共享、商业服务、模型微调、专业渲染等负载能够共同分摊成本时，才可能合理。

五、推理后端怎么选

个人桌面部署建议先使用 llama.cpp 或封装它的 Ollama/LM Studio。它们对 GGUF 量化和 CPU/GPU 混合卸载支持最好。团队共享、需要并发时，再考虑 SGLang 或 vLLM。

无论使用哪一个后端，都应向 Coding 客户端暴露 OpenAI 兼容接口。这样可以把模型接入 OpenCode、Cline、Continue、Aider、Codex 或其他 Agent，而不必把工作流锁定在单一推理程序中。

六、同名模型在线 API 方案

Qwen Cloud 的 Qwen3-Coder-Next 页面提供 OpenAI 兼容 API、函数调用、结构化输出和上下文缓存。官方公布的上下文上限约 262K，最大输入约 204.8K，最大输出约 65.5K。

API 按单次请求的输入长度分档计价：

在线 API 的优势：

• 无硬件投入，开通即可使用；
• 不需要下载模型、处理驱动和量化兼容；
• 由服务端承担扩容、故障恢复和推理优化；
• 不需要为了适配 64GB 设备亲自选择量化和分配 KV Cache；服务端具体精度并未公开；
• 长上下文不会挤占本机内存。

API 的性能瓶颈则是：

• 首 Token 延迟包含公网往返、排队和长提示词 Prefill；
• 官方限制为 600 RPM、100 万 TPM，高并发时会触及配额；
• 请求超过 32K 和 128K 后，输入、输出单价都会提高；
• 速度和模型版本由服务商控制，无法固定推理 Kernel；
• 私有代码需要离开本机，必须评估数据协议、地区和合规要求。

七、API 月度成本

为了避免只看“每百万 Token”却不知道一个月花多少，下面设置三种个人 AI Coding 用量：

按 1 美元约 7.2 元人民币计算，暂不计上下文缓存可能带来的进一步优惠：

这里的上下文档位是单次请求长度，不是月度 Token 总量。一个设计合理的 Coding Agent 会通过代码搜索、摘要和缓存尽量让请求留在 32K 内；如果每轮都把整个仓库重复发送到 128K 以上，不仅费用增加，首 Token 延迟也会变长。

八、本地硬件的真实月成本

“本地 Token 免费”并不等于运行成本为零。把设备按 3 年折旧，并粗略加入每月 100 小时推理的电费，可以得到下面的数量级：

假设重度使用的 API 费用为 ¥216～¥576/月：

• ¥2万元设备的静态回本时间约为 2.9～7.7 年；
• ¥3万元设备约为 4.3～11.6 年；
• ¥5万元设备约为 7.2～19.3 年。

这还没有计算 SSD、设备残值、维护时间、硬件故障和本地 4bit 量化的能力损失。只为了省 API 费购买新机器，经济上基本不成立。

九、性能瓶颈总表

十、不同用户应该怎么选

十一、我的推荐配置

如果从零购买，我不会为了省 Token 费组建多卡服务器，而会在下面三种方案中选择：

方案 A：不买硬件，直接 API

适合大多数个人开发者。按实际用量付费，短上下文下即使重度使用也约 ¥216/月。省下的硬件预算可以购买很多年的 API，并且不需要维护模型和驱动。

方案 B：已有 64GB 设备，本地 4bit + API 兜底

这是性价比最高的本地路线。本地运行 Qwen3-Coder-Next 4bit，设置 16K～32K 上下文；同一个任务连续失败两次、上下文过长或需要更高成功率时，切换 Qwen Cloud API。

方案 C：隐私优先，新购 96GB～128GB 设备

Mac Studio 更安静省心，Ryzen AI Max 主机容量价格比更好，DGX Spark 的 CUDA 生态更完整。三者都应优先运行 4bit，而不是为了 8bit 把内存占满。额外容量应留给 KV Cache、IDE、编译和测试进程。

总结

在统一内存不超过 128GB 的条件下，Qwen3-Coder-Next 是一个很合适的高端本地 AI Coding 样本：80B 总参数、3B 激活参数、4bit 约 46GB，既有较强的公开 Coding 成绩，也能在个人可以买到的设备上完整运行。

不同本地方案的本质差异可以压缩成三句话：

• Mac Studio 用高带宽统一内存换取安静、简单，但受 Metal 生态和不可升级限制；
• Ryzen AI Max 与 DGX Spark 用 128GB 容量换取更大的模型空间，但性能瓶颈是内存带宽；
• NVIDIA 多卡或专业显卡 速度和生态最好，但瓶颈转向显存容量、跨卡通信和采购成本。

而 API 的瓶颈不是本地内存，而是网络延迟、限流、隐私和长上下文价格。以目前同名模型的价格看，个人新购硬件几乎不可能单靠节省 Token 费用回本。

所以最终建议仍然是：

没有现成硬件就先用 API；已有 64GB 以上设备就部署本地 4bit；有隐私或离线刚需再购买 96GB～128GB 设备。不要为了“本地免费”忽略折旧、速度和任务成功率。

参考资料

• Qwen3-Coder-Next 官方模型卡
• Qwen3-Coder-Next 本地运行、量化与内存要求
• Qwen3-Coder-Next 官方 API 能力与价格
• Qwen3-Coder GitHub
• llama.cpp
• vLLM
• SGLang
• Apple Mac Studio 技术规格
• Framework Desktop Ryzen AI Max
• NVIDIA DGX Spark
• NVIDIA RTX PRO 6000 Blackwell
• NVIDIA GeForce RTX 5090

Mel Spectrogram 是语音识别、音频分类、音乐信息检索里非常常见的输入特征。它做的事情可以简单理解为：把一段一维波形，变成一张“符合人耳听觉习惯”的时间-频率能量图。

1. 从一段声音开始

计算机拿到的音频通常是一串采样点：

这串数字描述了空气振动随时间变化的幅度。问题是，直接看波形很难回答这些问题：

• 这段声音里有哪些频率？
• 某个频率是在什么时候出现的？
• 对人耳来说，哪些变化更重要？

所以我们需要一种更适合分析声音的表示。

2. 为什么不能只做一次 FFT？

FFT 可以告诉我们“一整段声音里有哪些频率”，但它会丢掉时间信息。

比如一段音频里先说 “a”，后说 “i”。如果直接对整段音频做 FFT，我们只能知道整段音频总体有哪些频率，不知道这些频率分别出现在什么时候。

语音是随时间变化的信号，所以更常用的是 STFT（Short-Time Fourier Transform，短时傅里叶变换）。

STFT 的做法是：

1. 把音频切成很多短帧，比如每帧 25ms。
2. 相邻帧之间有重叠，比如每 10ms 移动一次。
3. 对每一帧分别做 FFT。
4. 把每一帧的频谱按时间排起来。

这张“横轴是时间，纵轴是频率，颜色表示能量”的图，就是 Spectrogram（声谱图）。

3. STFT 到底在算什么？

假设输入音频是 $x[n]$，第 $m$ 帧的起点是 $mH$，其中 $H$ 是 hop length。每帧先乘一个窗函数 $w[n]$，再做 FFT：

$$ X(m, k) = \sum_{n=0}^{N-1} x[n + mH] \cdot w[n] \cdot e^{-j2\pi kn/N} $$

其中：

FFT 输出的是复数，实际做特征时通常取幅度谱或功率谱：

$$ P(m, k) = |X(m, k)|^2 $$

到这里得到的是普通线性频谱。它的频率刻度是线性的，比如 0Hz、100Hz、200Hz、300Hz …

4. 为什么要用 Mel 频率？

人耳对频率的感知不是线性的。

我们对低频变化更敏感，对高频变化相对迟钝。比如：

• 300Hz 到 400Hz 的变化，人耳容易感觉明显。
• 8000Hz 到 8100Hz 的变化，人耳通常没那么敏感。

这就像看地图：市区街道很密，需要细看；荒野区域可以粗略一些。Mel 频率就是一种“听觉地图投影”：低频区域分辨率高，高频区域分辨率低。

常用的 Hz 到 Mel 转换公式是：

$$ m = 2595 \log_{10}(1 + \frac{f}{700}) $$

反过来：

$$ f = 700(10^{m/2595} - 1) $$

大致效果如下：

1
2
3
4
5
6
7
8

Hz 线性刻度:
0      1000      2000      3000      4000      5000      6000      7000      8000
|--------|---------|---------|---------|---------|---------|---------|---------|

Mel 滤波器中心频率:
0  90 190 300 430 580  760  980  1250  1600  2050  2650  3500  5000       8000
|--|--|---|---|----|----|----|----|-----|-----|-----|-----|------|----------|
低频更密，高频更稀

5. Mel 滤波器组是什么？

Mel Spectrogram 的核心不是一个神秘算法，而是一组三角形滤波器。

它们铺在线性频谱上，每个滤波器负责统计一小段频率范围内的能量。低频处滤波器更窄、更密；高频处滤波器更宽、更稀。

如果线性功率谱是 $P(m, k)$，Mel 滤波器组是 $M(i, k)$，那么第 $i$ 个 Mel 频带的能量为：

$$ S(m, i) = \sum_k P(m, k) \cdot M(i, k) $$

写成矩阵形式更直观：

$$ \text{MelPower} = \text{PowerSpectrogram} \times \text{MelFilterBank}^T $$

最终通常再做 log 压缩：

$$ \text{LogMel}(m, i) = \log(S(m, i) + \epsilon) $$

加上 $\epsilon$ 是为了避免 $\log(0)$。

Whisper 中的 Mel filter bank

Whisper 使用的 Mel filter bank 并不是在推理时临时手写生成的。OpenAI Whisper 里预先保存了 mel_filters.npz，其中 80 维版本的生成方式等价于：

1
2
3
4
5

librosa.filters.mel(
    sr=16000,
    n_fft=400,
    n_mels=80,
)

这里没有显式写出的默认参数也很重要：

1
2

htk=False
norm="slaney"

也就是说，Whisper 使用的是 Slaney 风格的 Mel 标尺，并且对 Mel filter 做了面积归一化。whisper.cpp 在模型转换时会把这组预计算好的 filter bank 写入 ggml 模型文件，运行时只是加载并使用这些系数。

面积归一化的含义是：三角滤波器不再追求每个峰值都等于 1，而是让每个滤波器覆盖区域的面积更接近一致。因为 Mel 滤波器在 Hz 轴上越往高频越宽，如果所有三角形峰值都固定为 1，高频滤波器会覆盖更多 FFT bin，自然累加出更大的能量。这会给高频 Mel band 带来额外偏置。

1
2
3
4
5

不归一化：
高频 filter 更宽 -> 累加更多频点 -> 输出偏大

面积归一化：
高频 filter 更宽 -> 峰值相应降低 -> 各频带能量更可比

因此，norm="slaney" 的好处不是让图形看起来更整齐，而是让 Mel 频带更接近“对一个频率区间的加权平均能量”，而不是简单“加权求和”。这能减少由于滤波器宽度不同造成的能量偏差，也保证推理时的输入特征分布和 Whisper 训练时保持一致。

6. 为什么模型喜欢 Log-Mel？

很多 ASR、音频分类模型并不直接吃原始波形，而是吃 Log-Mel 特征。原因主要有几个。

6.1 更接近人耳听觉

语音识别的目标不是还原波形，而是识别“人听到的内容”。Mel 刻度把频率轴变成更接近人耳感知的尺度，对语音任务很自然。

6.2 降低输入维度

以 16kHz 音频、400 点 FFT 为例，线性频谱有 201 个频率 bin。经过 Mel 滤波器组后，常见配置只保留 80 个 Mel bins。

1
2

线性功率谱:  201 维 / frame
Mel 特征:     80 维 / frame

这相当于把不必要的频率细节做了一次听觉意义上的压缩。

6.3 log 压缩更适合学习

声音能量的动态范围很大。一个很响的声音可能比很轻的声音能量大几百倍甚至几千倍。直接用线性能量，模型容易被大能量区域支配。

log 压缩可以把乘法比例变成加法差异：

1
2

energy:  1      10      100      1000
log:     0      2.3     4.6      6.9

这也更接近人耳对响度的感知方式。

7. 常见参数怎么选？

语音任务里最常见的配置：

帧长和帧移的意义：

1
2
3
4
5
6
7

16kHz 音频:
1 秒 = 16000 个采样点

win_length = 400  -> 每帧 25ms
hop_length = 160  -> 每 10ms 产生一帧

所以 1 秒音频大约产生 100 帧特征。

如果最终特征维度是 80，那么 1 秒音频大约变成：

1

100 frames x 80 mel bins

这已经很像一张小图片了。横轴是时间，纵轴是 Mel 频率，像素值是 log energy。

8. 实践：用 librosa 计算 Mel Spectrogram

先安装依赖：

1

pip install librosa matplotlib soundfile

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

def show_mel_filters_by_librosa(n_fft, n_mel, sample_rate, htk=False, norm='slaney'):
    import librosa

    filters = librosa.filters.mel(
        sr=sample_rate,
        n_fft=n_fft,
        n_mels=n_mel,
        htk=htk,
        norm=norm,
    )
    frequency_bins = librosa.fft_frequencies(sr=sample_rate, n_fft=n_fft)

    fig, axes = plt.subplots(2, 1, figsize=(12, 8))

    for i in range(n_mel):
        axes[0].plot(frequency_bins, filters[i])
    axes[0].set_title('Mel Filter Bank by librosa')
    axes[0].set_xlabel('Frequency (Hz)')
    axes[0].set_ylabel('Weight')
    axes[0].set_xlim(0, sample_rate / 2)
    axes[0].grid(True, alpha=0.3)

    img = axes[1].imshow(
        filters,
        origin='lower',
        aspect='auto',
        extent=[0, sample_rate / 2, 0, n_mel],
    )
    axes[1].set_title('Mel Filter Bank Matrix by librosa')
    axes[1].set_xlabel('Frequency (Hz)')
    axes[1].set_ylabel('Mel filter index')
    fig.colorbar(img, ax=axes[1], label='Weight')

    plt.tight_layout()
    plt.show()

    return filters

9. 与 ASR 前端的关系

在 ASR 系统里，Mel Spectrogram 通常是声学前端的第一步。

不同系统叫法可能略有差异：

现代深度学习 ASR 更常用 Log-Mel / FBank，而不是 MFCC。因为神经网络可以自己学习频带之间的组合关系，不一定需要 DCT 做进一步压缩。

10. 常见坑

10.1 采样率要对齐

模型训练用 16kHz，推理也应该用 16kHz。采样率不一致会导致频率轴整体错位。

10.2 power 和 amplitude 不要混

幅度谱是：

$$ |X| $$

功率谱是：

$$ |X|^2 $$

librosa.feature.melspectrogram(..., power=2.0) 用的是功率谱。不同框架如果这里不一致，特征数值会明显不同。

10.3 log、ln、dB 的差异

有些实现用自然对数：

1

np.log(x + eps)

有些实现用 dB：

1

10 * np.log10(x + eps)

它们表达的信息相近，但数值尺度不同。部署模型时要和训练阶段保持一致。

10.4 shape 方向要确认

librosa 常见输出是：

1

(mel_bins, frames)

ASR runtime 常见输入是：

1

(frames, mel_bins)

这里错了，模型不会报特别明显的错误，但识别结果会很离谱。

11. 总结

Mel Spectrogram 可以理解成三层变换：

1. STFT：把波形变成时间-频率图。
2. Mel 滤波器组：把线性频率轴变成更接近人耳的 Mel 频率轴。
3. log 压缩：把巨大能量范围压缩到更适合模型学习的尺度。

最终得到的 Log-Mel 特征，是一张“人耳友好 + 模型友好”的声音图片。它既保留了语音随时间变化的频率结构，又比原始波形更稳定、更低维、更容易被神经网络使用。

参考

• Exploring Mel Spectrograms: A Powerful Feature Extraction Tool for Audio Signals
• Zooming In: Understanding the Short-Time Fourier Transform
• librosa.feature.melspectrogram

第一部分：重采样的原理与处理过程

目录

1. 采样操作的本质：频谱复制
2. 重建的条件：无混叠
3. 理想低通滤波器
4. 卷积重建
5. 重采样过程
6. 为什么是 sinc 而不是其他函数

1.1 采样操作的本质：频谱复制

核心结论 — Whittaker-Shannon 插值公式：

$$x_c(t) = \sum_{n=-\infty}^{\infty} x[n] \cdot \text{sinc}\left(\frac{t - nT}{T}\right)$$

其中 $\text{sinc}(u) = \frac{\sin(\pi u)}{\pi u}$。 这意味着：任意时刻的连续值 = 离散样本与 sinc 函数的卷积。

第一步：采样定理的数学表达

设连续信号 $x_c(t)$ 的傅里叶变换为 $X_c(j\Omega)$，带宽限制在 $|\Omega| \leq \Omega_0$（即 bandlimited）。

采样（采样周期 $T$）等价于将 $x_c(t)$ 乘以冲激串：

$$x_s(t) = x_c(t) \cdot \sum_{n=-\infty}^{\infty} \delta(t - nT)$$

频域上，乘积变成卷积。冲激串的傅里叶变换仍是冲激串（周期为 $\Omega_s = 2\pi/T$）：

$$\sum_{n=-\infty}^{\infty} \delta(t - nT) \xrightarrow{\mathcal{F}} \frac{2\pi}{T}\sum_{k=-\infty}^{\infty} \delta(\Omega - k\Omega_s)$$

卷积结果：采样信号的频谱是原始频谱的无限复制：

$$X_s(j\Omega) = \frac{1}{T}\sum_{k=-\infty}^{\infty} X_c\left(j(\Omega - k\Omega_s)\right)$$

直观理解：为什么采样 = 频谱复制

时域直觉：采样就是"按快门"

1
2
3

连续信号:  ∿∿∿∿∿∿∿∿∿∿∿∿∿∿∿∿∿∿∿∿  (无限多点)
采样后:      ●     ●     ●     ●     (有限个点)
           t=0   t=T  t=2T  t=3T

数学上，这个操作是信号乘以冲激串：$x_s(t) = x_c(t) \cdot \sum_n \delta(t - nT)$。冲激串就像一把"梳子"，只在整数倍 T 的位置"抓住"信号值，其余全部归零。

频域发生了什么？

时域相乘 → 频域卷积（傅里叶变换的基本性质）。而冲激串的傅里叶变换仍然是冲激串：

1
2
3

时域:  ↑     ↑     ↑     ↑     (冲激串，周期 T)
       ↓ 傅里叶变换 ↓
频域:  ↑     ↑     ↑     ↑     (冲激串，周期 Ωs = 2π/T)

卷积一个冲激串 = 把函数复制粘贴到每个冲激的位置。 好比一张照片（原始频谱）被复印无数份，每份放在一个相框里。

复制品重叠与否：决定混叠的关键

采样率足够高（Ωs > 2Ω₀）—— 复制品之间有间隔，可以用低通滤波器完美提取原始频谱：

1
2
3
4
5
6

     ╱╲       ╱╲       ╱╲       ╱╲
    ╱  ╲     ╱  ╲     ╱  ╲     ╱  ╲
   ╱    ╲   ╱    ╲   ╱    ╲   ╱    ╲
──╱──────╲─╱──────╲─╱──────╲─╱──────╲──→ Ω
              ↑
         间隔存在，可完美重建

采样率不够（Ωs < 2Ω₀）—— 复制品重叠，原始频谱被破坏，这就是混叠：

1
2
3
4
5
6

     ╱╲     ╱╲
    ╱  ╲╱╲╱  ╲
   ╱   ╳╳╳╳   ╲       ← 重叠！原始频谱被破坏
──╱──╱──────╲──╲──→ Ω
         ↑
    高低频信息混在一起无法分离

数字例子：30Hz 信号在 40Hz 采样率下

信号最高频率 30Hz，采样率 40Hz，Ωs = 40Hz：

1
2
3
4
5
6

原始频谱: 0~30Hz 有能量

采样后频谱复制 (每 40Hz 一份):
  复制品0:  [0 ~ 30Hz]       ← 原始
  复制品1:  [40 ~ 70Hz]      ← 40+0 ~ 40+30
  复制品-1: [-40 ~ -10Hz]    ← 折叠到正频率变成 10~40Hz

复制品-1 的负频率部分（-30~-10Hz）折叠到正频率变成 1030Hz，与原始频谱的 1030Hz 重叠——30Hz 被"误认"为 10Hz，这就是混叠。

1.2 重建的条件：无混叠

若 $\Omega_s \geq 2\Omega_0$（即采样频率高于奈奎斯特频率），则复制频谱互不重叠，可以通过一个理想低通滤波器提取出原始频谱。

重建条件（采样定理）：

$$\Omega_s = \frac{2\pi}{T} > 2\Omega_0 \implies T < \frac{\pi}{\Omega_0}$$

1.3 理想低通滤波器

要完美重建 $x_c(t)$，需要让 $x_s(t)$ 通过一个理想砖墙低通滤波器 $H(j\Omega)$：

$$H(j\Omega) = \begin{cases} T, & |\Omega| \leq \Omega_c \ 0, & |\Omega| > \Omega_c \end{cases}$$

其中 $\Omega_c$ 满足 $\Omega_0 \leq \Omega_c \leq \Omega_s - \Omega_0$（通常取 $\Omega_c = \Omega_s/2 = \pi/T$）。

该滤波器的单位冲激响应（即逆傅里叶变换）为：

$$h(t) = \mathcal{F}^{-1}{H(j\Omega)} = T \cdot \frac{\sin(\Omega_c t)}{\Omega_c t}$$

令 $\Omega_c = \pi/T$，则：

$$h(t) = T \cdot \frac{\sin(\pi t/T)}{\pi t/T} = \text{sinc}\left(\frac{t}{T}\right)$$

这就是 sinc 函数！

sinc 同时完成重建与低通

sinc 卷积在频域做了一件事：只保留目标频段，切除其余复制品。从不同角度看，它有两个名字：

1
2
3
4
5
6

频域视角：

采样信号频谱:    |原始|  复制品  |  复制品  |  复制品
                      ↑
                 只提取这一块
                 = 重建 = 低通滤波 = 去除复制品

它们是同一个滤波操作的两种叫法。 重建 = 低通滤波 = sinc 卷积。

sinc 如何确定截止频率？

sinc 函数不是"带参数的滤波器"，它就是理想低通滤波器的时域形态。截止频率由 sinc 的"胖瘦"决定：

**缩放规则：**sinc 在时域越"窄"，频域的矩形窗越"宽"（时频互逆）。

1
2
3

sinc(t/T)          →  截止频率 = π/T = Ωs/2
sinc(2Wt)          →  截止频率 = W    (角频率)
sinc(2πf_c · t)    →  截止频率 = f_c  (Hz)

重采样中截止频率的选择

截止频率不是随便选的，它由目标采样率决定：sinc 的截止频率 = 目标采样率的 Nyquist 频率（$F_{\text{target}}/2$）。

**上采样（插值）：**从 $F_s$ 上采样到 $M \cdot F_s$

1
2
3
4
5
6
7

原始 Nyquist = Fs/2
新 Nyquist   = M·Fs/2

插零后频谱:   |原始|  镜像  |  镜像  |  镜像
                     ↑
              sinc 滤波器只保留这里
              截止 = 新采样率的 Nyquist = M·Fs/2

**下采样（抽取）：**从 $F_s$ 下采样到 $F_s/M$

1
2
3
4
5
6
7

原始 Nyquist = Fs/2
新 Nyquist   = Fs/(2M)

原始频谱:     |████████████████|
                      ↑
              只保留这部分，截止 = 新采样率的 Nyquist = Fs/(2M)
              然后再抽取

1.4 卷积重建

滤波器输出为输入与冲激响应的卷积：

$$x_c(t) = x_s(t) * h(t) = \left[x_c(t) \cdot \sum_{n}\delta(t-nT)\right] * \text{sinc}\left(\frac{t}{T}\right)$$

乘以冲激串后得到一系列移位冲激：

$$x_s(t) = \sum_{n=-\infty}^{\infty} x_c(nT) \cdot \delta(t - nT)$$

与 sinc 卷积：

$$x_c(t) = \sum_{n=-\infty}^{\infty} x_c(nT) \cdot \text{sinc}\left(\frac{t - nT}{T}\right)$$

核心公式的意义：

• 连续信号可以唯一地由其样本 ${x_c(nT)}$ 决定
• 每个样本乘以一个 sinc 函数，所有这些 sinc 函数叠加即重建连续信号
• sinc 函数的峰值在 $t = nT$，在其他采样点为零（正交性）

1.5 重采样过程

现在要将信号从采样率 $T_1$重采样到 $T_2$。

整数倍上采样（$T_2 = T_1/N$，增加 $N$ 倍）：

1. 在样本间插入 $N-1$ 个零 → 频谱压缩 $N$ 倍
2. 通过低通滤波器（增益 $N$）去除镜像频谱
3. 该滤波器就是 sinc 函数

有理数比上/下采样（$T_2 = \frac{P}{Q}T_1$）：

• 先上采样 $P$ 倍（插值）
• 再下采样 $Q$ 倍（抽取）
• 每一步都用 sinc 滤波

任意比值重采样：

在目标时刻 $t = mT_2$ 直接计算：

$$x[m] = \sum_{n=-\infty}^{\infty} x_1[n] \cdot \text{sinc}\left(\frac{mT_2 - nT_1}{T_1}\right)$$

1.6 为什么是 sinc 而不是其他函数？

sinc 是唯一的：在采样定理框架下，只有 sinc 能实现理论上完美的连续信号重建。任何其他核都是对 sinc 的近似，代价是高频失真（Gibbs 现象 / 振铃效应）。

1.7 物理直觉

1
2
3
4

原始连续信号:  ~~~波形~~~
采样点:          ●    ●    ●    ●
                  ↖   ↗   ↖   ↗
              每个点"抓住"一个sinc,叠加重建波形

sinc 函数是理想低通滤波器的时域响应。卷积即滤波，滤波即重建。

第二部分：工程实现：从朴素到优化

以 SpeexDSP 重采样器为例，从最原始的 sinc 插值出发，逐步引入优化手段，理解每个优化解决什么问题。

目录

1. 最原始的实现：直接算 sinc
2. 第一步优化：查表代替实时计算
3. 第二步优化：多相滤波
4. 第三步优化：Speex 的混合策略
5. 第四步优化：分数位置推进
6. 第五步优化：定点运算
7. 全景总结

2.1 最原始的实现：直接算 sinc

根据 Whittaker-Shannon 公式，要计算任意时刻 $t$ 的信号值：

$$x(t) = \sum_{n} x[n] \cdot \text{sinc}\left(\frac{t - nT}{T}\right)$$

最直觉的实现：对每个输出样本，遍历所有相关输入样本，实时计算 sinc 值。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import numpy as np

def naive_resample(x, fs_in, fs_out, num_samples_out):
    """最原始的重采样：直接算 sinc"""
    output = np.zeros(num_samples_out)

    for m in range(num_samples_out):
        t = m / fs_out
        pos = t * fs_in  # 在输入序列中的"虚拟位置"

        n_center = int(np.floor(pos))
        half_len = 16  # 只取 ±16 个点（截断 sinc）

        s = 0.0
        for n in range(n_center - half_len, n_center + half_len + 1):
            if 0 <= n < len(x):
                sinc_val = np.sinc(pos - n)  # sin(πx)/(πx)
                s += x[n] * sinc_val
        output[m] = s

    return output

问题：计算量太大

1
2
3
4
5
6
7
8

对每个输出样本:
  → 遍历 2 × half_len 个输入样本
  → 每个都要调用 np.sinc()（内部算 sin + 除法）

总计算量: num_out × 2 × half_len × (sin + 除法)

示例: 10 秒 48kHz 音频，half_len=32
  480000 × 64 = 3072 万次 sin() 调用

核心瓶颈： sin() 是很贵的运算，每次都要算。

2.2 第一步优化：查表代替实时计算

sinc 函数是固定的，可以预先计算好一张表，运行时直接查表。

1
2

优化前:  每次算 sin(πx)/(πx)     → 贵（三角函数 + 除法）
优化后:  直接查表 sinc_table[i]   → 快（一次内存访问）

新问题：精度不足。 输出位置通常是分数（比如 pos = 3.7），而 sinc 表只有固定间隔的值。需要用插值逼近任意分数位置的 sinc 值。

1
2
3
4
5
6

目标: sinc(3.7)
表里有: sinc(3.50), sinc(3.75)   ← 间隔 1/4

选项A: 线性插值   → sinc(3.7) ≈ 0.4×sinc(3.50) + 0.6×sinc(3.75)
选项B: 三次插值   → 用相邻 4 个点做 cubic 插值（更准）
选项C: 存更大的表  → oversample=16 或 32，直接取最近的（但费内存）

Speex 的 Interpolated 模式采用选项 B：存一张较稀疏的 sinc 表，用 Cubic 插值逼近任意位置。

2.3 第二步优化：多相滤波 — 避免重复计算

上面的方法对每个输出样本独立做一次卷积。但如果输入输出采样率是整数比关系，可以利用周期性复用计算。

关键观察

上采样 4 倍时，sinc 系数只有 4 种不同的偏移：

1
2
3
4
5

输出样本 0: sinc 偏移 0/4 → 系数 [a0, a1, a2, a3]
输出样本 1: sinc 偏移 1/4 → 系数 [b0, b1, b2, b3]
输出样本 2: sinc 偏移 2/4 → 系数 [c0, c1, c2, c3]
输出样本 3: sinc 偏移 3/4 → 系数 [d0, d1, d2, d3]
输出样本 4: sinc 偏移 4/4 = 0/4 → 系数 [a0, a1, a2, a3]  ← 重复！

只有 4 组不同的系数，不需要为每个输出样本重新查表。

多相滤波器结构

1
2
3
4
5
6

输入 x[n] ───┬──→ [滤波器组 a] ──→ 输出 t=0/4
             ├──→ [滤波器组 b] ──→ 输出 t=1/4
             ├──→ [滤波器组 c] ──→ 输出 t=2/4
             └──→ [滤波器组 d] ──→ 输出 t=3/4

4 组滤波器，每组只对同一个输入段计算一次

计算量从 N×M 降到 N×M/P（P = 上采样倍数）。

2.4 第三步优化：Speex 的混合策略

SpeexDSP 面对的是任意比例重采样（不是整数比），不能直接用纯多相。它的策略是根据参数自动选择查表方式。

策略一：Direct Sinc Table（den_rate 较小时）

当分母 den_rate 不太大时，直接存 filt_len × den_rate 大小的 sinc 表，精确查找。

1
2
3
4
5
6
7
8
9

den_rate = 160 (分母)
filt_len = 64  (滤波器长度)

sinc 表大小 = 64 × 160 = 10240 个系数
内存 ≈ 10240 × 2 bytes = 20KB

查找: sinc_table[j * den_rate + samp_frac_num]
      ↑                ↑
      第 j 个抽头      当前分数位置

**优点：**直接查表，零插值误差 **缺点：**内存随 den_rate 线性增长

策略二：Interpolated Sinc Table（den_rate 较大时）

**核心矛盾：**Direct 模式要存 filt_len × den_rate 个系数。当 den_rate = 48000 时：

1

filt_len=64, den_rate=48000 → 64 × 48000 = 307 万个系数 → 6MB 内存

太大了。能不能存一个小表，用插值来"猜"中间的值？

sinc 表存的到底是什么？

每个输出样本需要的 sinc 系数，就是 sinc 函数在不同偏移位置的采样值。

Direct 模式：为每个可能的分数位置都存一份

1
2
3
4
5
6
7

输出位置 0.000:  用 sinc 在 ..., -2.000, -1.000, 0.000, 1.000, ... 处的值
输出位置 0.001:  用 sinc 在 ..., -1.999, -0.999, 0.001, 1.001, ... 处的值
输出位置 0.002:  用 sinc 在 ..., -1.998, -0.998, 0.002, 1.002, ... 处的值
...

den_rate=1000 时，需要为 1000 种不同的偏移各存 filt_len 个系数
表大小 = filt_len × 1000

Interpolated 模式：只存 oversample 份，用插值补中间

1
2
3
4
5
6
7
8
9

oversample=16 时，只存 16 种偏移的系数：

偏移 0/16:  sinc 在 0.000, 1.000, 2.000, ... 处的值
偏移 1/16:  sinc 在 0.0625, 1.0625, 2.0625, ... 处的值
偏移 2/16:  sinc 在 0.125, 1.125, 2.125, ... 处的值
...
偏移 15/16: sinc 在 0.9375, 1.9375, 2.9375, ... 处的值

表大小 = filt_len × 16

完整的查找过程（数字示例）

设定：

1
2
3
4
5

信号: 48kHz → 44.1kHz 重采样
filt_len = 8  (滤波器长度，取 8 个输入样本)
oversample = 16

sinc 表大小 = 8 × 16 + 8 = 136 个系数

第一步：确定在输入序列中的位置

1
2
3
4

输入位置 pos = m × (fs_in / fs_out) = 100 × (48000/44100) = 108.8480...

整数部分: n_center = 108
小数部分: frac_input = 0.8480...

第二步：将小数部分映射到 oversample 网格

1
2
3
4

oversample_index = frac_input × oversample = 0.8480 × 16 = 13.568

整数偏移: offset = 13        ← 在 sinc 表中的基准位置
小数偏移: frac = 0.568       ← cubic 插值的输入

第三步：对每个滤波器抽头，取 4 个相邻表值做 cubic 插值

第四步：所有抽头加权求和

$$\mathrm{output}[m] = \sum_{j=0}^{7} \mathrm{sinc_value}[j] \times \mathrm{input}\big[n_{\mathrm{center}} + k_j\big]$$

Cubic 插值系数

1
2
3
4

interp[0] = -0.16667*frac + 0.16667*frac*frac*frac;
interp[1] =  frac + 0.5*frac*frac - 0.5*frac*frac*frac;
interp[3] = -0.33333*frac + 0.5*frac*frac - 0.16667*frac*frac*frac;
interp[2] =  1.f - interp[0] - interp[1] - interp[3];

这是对 sinc 函数的 MMSE（最小均方误差）最优三次逼近。

为什么用 Cubic 而不是线性？

1
2

线性插值:  在两个点之间拉直线 → 对 sinc 这种振荡形状误差大
Cubic 插值: 用三次曲线拟合 → 高频失真更小，接近直接查表精度

对比：省了多少内存？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

场景: 48kHz → 44.1kHz, filt_len=64

Direct (den_rate=48000):
  表大小 = 64 × 48000 = 3,072,000 个系数
  内存 = 3,072,000 × 2 bytes = 6 MB

Interpolated (oversample=16):
  表大小 = 64 × 16 + 8 = 1,032 个系数
  内存 = 1,032 × 2 bytes = 2 KB

节省: 6MB → 2KB，缩小 3000 倍
代价: cubic 插值引入微小误差（~0.01dB，人耳不可感知）

2.5 第四步优化：分数位置推进 — 避免除法

每个输出样本的分数位置怎么算？朴素做法：

1
2

// 朴素：每个样本都做一次除法
frac_pos = (m * fs_in) % fs_out / fs_out;

除法很贵。 Speex 用累加器避免除法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 预计算一次（整数除法，只在初始化时执行）
int_advance  = num_rate / den_rate;     // 整数部分
frac_advance = num_rate % den_rate;     // 分数累加步长

// 每个输出样本（只有整数加法和比较）
last_sample  += int_advance;            // 整数步进
samp_frac_num += frac_advance;          // 分数累加
if (samp_frac_num >= den_rate) {        // 进位
    samp_frac_num -= den_rate;
    last_sample++;
}

整个过程只有整数加法和比较，零除法，零浮点运算。

2.6 第五步优化：定点运算

浮点运算在某些平台（嵌入式 DSP 芯片）很慢。Speex 支持 16-bit 定点模式：

1
2
3
4
5
6

// 浮点版
sum += sinc_val * input_val;

// 定点版 (Q15 格式: 1 位符号 + 15 位小数)
sum += MULT16_16(sinc_val_q15, input_val_q15);
// 其中 MULT16_16 = (int32_t)a * (int32_t)b >> 15

精度换速度： 16-bit 定点的阻带衰减约 90dB，对语音应用足够。

2.7 全景总结

优化路径

各步骤对比

Speex 质量等级与滤波器参数

filt_len 越长 → sinc 截断越接近理想 → 阻带衰减越好 → 计算量越大。

参考

• Stanford CCRMA - Digital Audio Resampling
• SpeexDSP 源码：speex/libspeexdsp/resample.c

最近一直在重度使用 Claude Code，也一直被各种新名词轰炸：vibe coding、spec coding、agent、openclaw、harness 等等。刚好看到一个介绍 Claude Code 工程原理的教程，对Agent Engneer有了一些认识，记录总结一下。

教程地址：https://learn.shareai.run/en/
项目仓库：https://github.com/shareAI-lab/learn-claude-code

课程介绍

该课程包含12个递进式课程，从简单循环到隔离化的自治执行，每个课程添加一个 harness 机制，每个机制有一句格言，非常推荐大家去学习：

s01   One loop & Bash is all you need — 一个工具 + 一个循环 = 一个 Agent

s02   加一个工具, 只加一个 handler — 循环不用动, 新工具注册进 dispatch map 就行

s03   没有计划的 agent 走哪算哪 — 先列步骤再动手, 完成率翻倍

s04   大任务拆小, 每个小任务干净的上下文 — Subagent 用独立 messages[], 不污染主对话

s05   用到什么知识, 临时加载什么知识 — 通过 tool_result 注入, 不塞 system prompt

s06   上下文总会满, 要有办法腾地方 — 三层压缩策略, 换来无限会话

s07   大目标要拆成小任务, 排好序, 记在磁盘上 — 文件持久化的任务图, 为多 agent 协作打基础

s08   慢操作丢后台, agent 继续想下一步 — 后台线程跑命令, 完成后注入通知

s09   任务太大一个人干不完, 要能分给队友 — 持久化队友 + 异步邮箱

s10   队友之间要有统一的沟通规矩 — 一个 request-response 模式驱动所有协商

s11   队友自己看看板, 有活就认领 — 不需要领导逐个分配, 自组织

s12   各干各的目录, 互不干扰 — 任务管目标, worktree 管目录, 按 ID 绑定

什么是Agent/Harness

如何开发适用于自己工作流的Agent/Harness

1. 流程是怎样的
2. 需要哪些特定的知识
3. 其中需要用到哪些工具，这些工具适用的场景和使用说明

总结

1. 设计参考人类开发过程 — 每个特性都是实际工作流会用的
2. 节约 Token，按需加载 — skill 的两层 load 机制 + context 的压缩机制
3. 新名词殊途同归 — prompt/harness/skill，皆是给 Agent 提供知识背景
4. 典范案例 — Claude Code 是编码工作流与 AI 大模型结合的典范

Claude Code 与 AI 模型的关系

• Claude 模型：负责「思考」和「推理」，理解代码、分析任务、决定下一步
• Claude Code (agentic harness)：负责「赋能」和「执行」，提供工具接口、上下文管理、终端环境，让推理转化为实际操作

关系模式：Claude Code 相当于「外壳/操作系统」，Claude 模型是其中的「智能核心」。模型提出计划，Claude Code 通过工具和环境落实这些计划。

Agent 开发不过是将自身能力的一次实体化。如同那句话所说：大模型是放大器，自身能力决定了 Agent 的上限。这个时代对人的要求，反而更高了。只有人本身把工作流想清楚了，才有可以设计出高效合理的Agent流程。

当整个系统的短板是人的时候，再也没有借口可找。

参考：

1. github: learn-claude-code
2. 你不知道的 Claude Code：架构、治理与工程实践
3. 你不知道的 Agent：原理、架构与工程实践

春节期间，为了打发时间，我迷上了一款拼图小游戏。游戏规则很简单——给你一张漂亮的图片，打乱成若干块，然后在时间限制内把它拼好。听起来很休闲对不对？too young too simple。

问题在于：每次超时都要看30秒视频广告。人菜瘾又大的我，经常需要看广告才能过关。

终于在某次看了第17遍"是兄弟就来砍我"之后，我一拍桌子——不行，我要搞点事情。

📢 友情提示：本文不涉及游戏外挂或修改游戏本身，只是研究如何用程序自动操作已知的拼图图片。

二、动手干

2.1 拼图还原问题

拼图还原问题（Jigsaw Puzzle Reassembly Problem） 是计算机视觉和图像处理领域的一个重要研究课题。简单来说，就是给定一幅被打碎的图像，如何让计算机自动识别各个碎片之间的关系，并将它们重新拼合成完整的原始图像。

问题分类

根据不同的碎片特征，拼图还原问题可以分为以下几类：

本文面对的问题

回顾本文面对的拼图问题：

• ✅ 矩形分块：每块都是规整的矩形，没有传统拼图的锯齿边缘
• ✅ 网格排列：6×6、7×7、8×8 三种规格，整齐排列
• ✅ 无旋转：所有碎片都是正向朝上，不涉及旋转匹配
• ❌ 无参考图：原图被打碎后完全不可见，需要通过碎片自身特征推断位置

这属于上表中的 Type 1 类型——矩形碎片、无旋转的规则拼图。虽然是相对简单的一类，但结合"无参考图"这一约束条件，仍然需要借助图像边缘匹配等计算机视觉技术来解决。

2.2 实施方案

2.2.1 提取拼图区域

输入：含 UI 的原始截图 输出：纯拼图区域图像 + bbox

方法：基于背景颜色分割

从图像四周边缘采样获取背景色，对每个像素计算 RGB 欧氏距离。距离 > 35 的像素标记为非背景，经形态学开闭运算去噪填洞后，查找最大连通域作为拼图区域。

2.2.2 检测拼图块边界

输入：纯拼图区域图像 输出：M×N 个等大小 patch

方法：基于轴向纹理信号检测分割线

灰度化后沿行/列方向计算标准差。拼图块内部纹理有变化→信号高，块间缝隙处纹理一致→信号低。通过搜索信号局部最小值定位每条分割线，最后归一化所有 patch 为统一尺寸。

2.2.3 遗传算法拼图

输入：打乱的 M×N 个 patch 输出：还原后的 grid + 重建图像

方法：进化算法最小化相邻块边缘差异

种群 200 个随机排列个体，以相邻块边缘像素差（MSE/Median/Percentile/Huber）的总和作为适应度。轮盘赌选择父代、交叉产生子代、精英保留 Top2，连续 10 代无提升则早停。

三、最终效果展示

四、总结

这个项目大概花了我四周的周末时间，从最初的"看广告好烦"到最后的"这玩意儿居然还真能跑"，过程颇为曲折。虽然全程vibe coding，但是大方向还是需要自己去研究清楚后，再给AI讲清楚后，才能有个好的结果。

目前这个效果离我最初设想的效果，一键启动通关，还差很远，还存在不少问题，不过也算基本达到当时的目的，用了这个后，玩这个拼图游戏再也没有看过广告了。也许后面有时间，再看看没有其它能够实现一键通关的方法，比如RL之类的，现在就暂时到这里吧，毕竟只是一个副本任务。

项目地址：JigsawPuzzleReconstruction

最后，如果你也被游戏广告折磨得不行，不妨试试这个思路——有时候最好的外挂，是用自己的技术绕过广告（而不是去黑游戏服务器）。

祝大家拼图愉快，永不看广告！

模块流程

效果展示

一些感想

这也是第一个完全 AI Coding 的项目，有了 AI Coding 后有了一种自己无所不能的错觉。作为一个大龄程序员，已经放弃抵抗了，打不过咱就加入。

AI 是放大器

在做这个 Project 的过程中，对我来说最大的困难是 UI 部分。关于 AICoding 的一些感想和后续的规划 中提到的，AI 的能力约等于使用者自身的能力。最近听到"AI 是放大器"这个说法，这个比喻可真的是贴切形象了。假如 AI 可以放大 10 倍，如果应用在你熟悉的领域是 10 分，放大后就是 100 分；如果应用在你不熟悉的领域，比如 iOS 客户端开发，对我来说约等于 0 分，放大后也是约等于 0 分。那这个时候就看天吃饭了，AI 给什么就吃什么，就算有问题我也无法判断，更别说是纠正 AI 了。所以网上一堆零基础开发一个 App 上线并产生收入的，真的可能吗？难道我的使用姿势不对？

狠狠地用起来

虽然对于自己不熟悉的领域，使用 AI 产生可用代码的偶然性挺大的，不过作为 AI 协作者，AI 在学习人类的代码，人类也可以学习 AI 的代码。在这个项目中，对于自己不熟悉的客户端 UI 部分的代码，我就会让 AI 给我讲解一遍，从语法到架构、为什么这么写。在提问 → 学习 → 再提问 → 再学习的不断迭代过程中，也在慢慢提高 AI 输出自己不熟悉代码的可控性和判断力。

现在是将想法落地最好的时代。以前你可能会卡在某个问题因为找不到有效的解答而不了了之，或者因为某个技术不懂而不能落地，但是现在你随时可以通过 AI 大模型得到你想要的答案，协助你实现自己的 idea。要像大神 Karpathy 一样，因为 token 没用完而感到焦虑，不停去跟 AI 交流、提问、讨论，落地想法。去尝试将 AI 嵌入到自己的工程流程中，这个我也还没找到方向，但是我觉得这个方向是没错的。狠狠地、使劲用起来吧。

项目链接

DoubleSubtitleUseSystemAPI

这篇继续是开发日志，正在开发一款iOS端的实时双语字幕APP，由于需要用到语音识别，了解了下语音识别任务的现状和主流方案，为后面方案选择做准备。

模块流程

什么是ASR任务

ASR（Automatic Speech Recognition，自动语音识别）任务，指的是将连续的音频信号转换为对应的文本序列的过程。这是一种典型的序列到序列（Sequence-to-Sequence）的转换任务：

1

audio (连续信号)  →  text (离散 token)

从信号处理的角度来看，传统ASR需要解决以下核心问题：

1. 声学建模：将音频特征映射到音素或字符
2. 语言建模：捕捉词汇之间的概率关系
3. 对齐问题：音频帧与输出token之间的对齐

不过，在现代端到端深度学习方案中，这三个问题都被统一在一个神经网络中解决，不再需要独立的声学模型和语言模型。模型通过端到端训练自动学习如何从音频特征直接映射到文本输出。

与降噪任务的区别

在开发iOS双语字幕的过程中，我之前可能接触过降噪任务，这两者有本质区别：

简单来说：

• 降噪任务：输入一段有噪声的音频，输出干净的音频（同类转换）
• ASR任务：输入音频，输出文字（跨模态转换）

ASR的难点在于它需要"理解"音频内容并转换为语义符号，而不是简单地处理信号波形。同时，ASR任务的输入和输出也不像降噪任务那样是一一对应的关系，还需要处理对齐问题。

目前主流的实现方案

主流的ASR实现方案主要有三种：CTC、RNN-T和基于Attention的Seq2Seq。

CTC (Connectionist Temporal Classification)

CTC是一种经典的对齐方法，核心思想是不需要显式的对齐标签，而是通过"blank"机制自动学习对齐。

CTC引入了空白符（blank）和折叠机制：

• 重复的字符会被折叠（如 “aaabbb” → “ab”）
• blank符号不产生任何输出
• 通过动态规划计算所有可能路径的概率

Sequence Modeling With CTC 详细原理可参考这篇文章。

训练阶段就是使目标token序列路径的概率最大，而推理阶段就是搜索概率最大的token路径并输出，这里通常有两种方法：

RNN-T (Recurrent Neural Network Transducer)

RNN-T是CTC的扩展，引入了一个额外的预测网络（Prediction Network）来建模输出token之间的依赖关系。

RNN-T由三部分组成：

1. 编码器（Encoder）：将音频特征转换为声学表征
2. 预测网络（Prediction Network）：基于已输出的token预测下一个token
3. 联合网络（Joint Network）：结合Encoder和Prediction的输出，预测下一个token

RNN-T在输出时，不仅会输入当前帧音频数据，还会输入历史输出作为参考

Seq2Seq with Attention

基于Attention机制的序列到序列模型是目前最流行的方案，被广泛用于Whisper、Paraformer等现代ASR系统。

原理

经典结构：

1

Encoder → Attention → Decoder → Output

• Encoder：将音频特征编码为高维表征（通常使用Transformer或Conformer）
• Attention：让Decoder在生成每个token时"关注"输入的不同部分
• Decoder：自回归生成输出文本

优缺点

优点：

• 可以建模任意长度序列的依赖关系
• 识别准确率高
• 易于添加语言模型集成
• 适合大规模预训练

缺点：

• 推理延迟较高（需要完整音频或较大chunk）
• 流式识别实现复杂
• 计算资源需求大

流式模型和非流式模型

流式（Streaming）和非流式（Offline）是ASR系统根据实时性要求的两种设计模式。

什么是非流式模型

非流式模型（Offline ASR）需要等待完整音频输入后才能开始识别。

特点：

• 输入：完整的音频文件或长音频段
• 延迟：较高，需要等待音频结束
• 准确率：通常较高，因为可以看到完整的上下文
• 适用场景：视频字幕生成、会议转录、录音文件处理

什么是流式模型

流式模型（Streaming ASR）可以边接收音频输入边输出识别结果，实现实时识别。

特点：

• 输入：连续的音频流（通常是短片段，如30ms一帧）
• 延迟：低，可以做到几百毫秒内输出
• 准确率：通常略低于非流式，因为只有历史和部分未来上下文
• 适用场景：实时语音对话、语音助手、直播字幕

技术实现差异

流式模型通常需要特殊设计，如：

• Chunked Attention：将音频分成小块处理
• CTC Prefix：使用CTC的前缀解码
• Lookahead：只考虑有限的未来帧

自回归解码和非自回归解码

解码方式决定了模型如何生成输出文本。

自回归解码 (Autoregressive Decoding)

自回归解码是目前最主流的方式，特点是逐 token 生成，每个 token 的生成依赖之前所有生成的 token。

1
2
3
4
5
6

输出: "hello world"
生成过程:
  1. 生成 "h"
  2. 基于 "h" 生成 "he"
  3. 基于 "he" 生成 "hel"
  4. ...

特点：

• 优点：生成质量高，可以建模长期依赖
• 缺点：串行生成，推理速度慢（O(n) 复杂度，n为输出长度）
• 典型模型：Transformer Decoder、RNN-T

非自回归解码 (Non-autoregressive Decoding)

非自回归解码是一种并行生成方式，一次性输出整个序列。

1
2
3

输出: "hello world"
生成过程:
  1. 直接输出完整句子 "hello world"

特点：

• 优点：并行生成，推理速度快（O(1) 复杂度）
• 缺点：难以建模输出token之间的依赖，生成质量可能较低
• 典型实现：CTC、FastCorrect、Mask-Predict

对比

方案选择

OK，前面了解了这么多，都是为了后续实现最小原型产品，选择语音识别方案做准备，目标不是要训练一个SOTA模型，因此这里暂时只是粗浅的了解。

根据需求分析：

• 目标设备：iOS移动端（资源有限）
• 语言支持：多语言
• 实时性：实时输入音频，实时输出文字

选择优先级

1. 首先能跑：模型大小和计算量必须在移动端可承受范围内
2. 然后多语言：需要支持多种语言识别
3. 最后准确率：在功能可用后再优化性能

优先级一：模型能在移动端跑起来

参数量选择

移动端资源有限，模型参数量直接决定了能否运行。这里暂时没有明确的数值界限，实际运行起来再看，后面也可以用量化技术缩小模型体积。

量化技术：INT8量化可将模型体积缩小约4倍，准确率损失通常<5%；INT4可进一步缩小到1/8，但准确率下降更明显。

架构选择

建议：选择Encoder-only或轻量级的Conformer结构，参数量控制在50M以内。

优先级二：支持多语言

确认模型能在移动端运行后，需要考虑多语言支持能力。

不同模型架构的多语言能力

结论

需要支持多语言时，优先选择端到端Seq2Seq架构，这类模型的预训练版本通常已支持数十到上百种语言。

优先级三：实时性要求

实时字幕要求模型能够在接收音频的同时输出文字。

流式 vs 非流式

折中方案：使用非流式模型时，可通过"分块处理"策略模拟流式效果：

• 将音频切分为固定长度的chunk（如1秒）
• 逐块识别并拼接结果
• 通过缓存历史上下文减少误差

解码方式

建议：实时场景优先选择非自回归解码（Greedy），延迟最低。

总结

核心理念：先完成端到端流程验证，再根据实际体验进行针对性优化。移动端ASR是一个迭代过程，不必追求一步到位。

后续我会记录在iOS端的具体实现过程，各位道友记得点赞追番哦。

最近要说最热最火的话题，那一定是 AI，而其中 AI 应用场景 AI Coding 也是发展迅速，大有替代程序员的势头。最近几个月一直在使用 AI Coding，心态上经历了最初的「完了，失业要提前了」，到「稳了，还能苟几年」。下面就分享一些使用上的感受，以及面对 AI Coding 这股后浪，这个号后面的一些规划。

1. AI Coding 非常有帮助，收费的优于免费的

这几年 AI 发展迅速，早已不是当年的「人工智障」了，确实是可以作为生产力工具帮忙提升效率的。对于 AI Coding 来说，到底能提升多少效率，取决于多方面因素：比如 Coding 在日常开发中占的比重、使用 AI 的熟练程度、AI Coding 工具本身的性能等等。但不管怎么说，AI Coding 对于程序员来说都是有正向作用的，是值得花时间去用起来的。

我自己用得比较多的是 Cursor 跟 Claude Code。Cursor 是公司给配置的，Claude Code 是我自己订阅了 MiniMax 的 Coding Plan 配置的。在此之前也用过国内一些免费的 AI Coding 工具（比如 Trae 和 Qcoder），短暂的使用给我的感受就是没有付费的好用，一个问题反复折腾好几轮都没有跑通。

当然这些纯粹是个人拍脑袋的感受，使用时间不长，也没有很深入地去使用。网上也有一些使用 Trae 和 Qcoder 做出可用应用的案例。重要的是 AI Coding 确实能够提升开发效率的，大家都应该用起来。

2. AI Coding 的能力约等于使用者自身

AI Coding 在目前这个阶段还是一个被动的工具，需要使用者去给它进行规划和任务指引，因此使用者的能力边界就约等于使用 AI Coding 后的能力边界。

程序开发是一个复杂的系统工程，每个需求拆分任务后就有很多步骤。就算 AI Coding 每一步的成功率为 95%，8 步之后最终能成功的概率也只剩下 66%。另外，AI Coding 获取的需求信息主要来源于使用者，使用者在与 AI 沟通描述时，这里又得损耗一些性能，导致成功率下降。不过好消息是，使用者可以在与 AI 互动过程中不断扩展自己的能力边界，把原来了解的领域变成熟悉领域，所以理论上 AI Coding 是没有边界的。

这里给我几点启发：

1. 生产环境只在自己熟悉的范围内使用，最多只触及到了解的区域，再往外扩展能得到什么成果就只能听天由命了，试验性的尝试性的项目不受这个限制。
2. 给 AI 描述需求时，尽可能详细，就像你自己开发一样，想好整个代码的架构和目标，并记录成文档。文档不仅可以给 AI 描述需求，也可以随时给 AI 找回上下文，弥补 AI Coding 上下文有限的问题。
3. 大龄程序员凭借多年积累的经验，辅以AI Coding弥补”编程体力不足“，又可以焕发第二春了。

3. AI Coding 还只是辅助编程，使用者需要为其质量兜底

类似于汽车自动驾驶，AI Coding 现在也还只是 L2 水平，辅助编程阶段，出了事故还是得使用者来负责。所以对于生产环境使用 AI Coding 时，要对 AI Coding 生成的代码进行严格的 Review。

不过最近也看到另一种解法：随着 AI Coding 生成的代码量级快速上升，传统逐行代码 Review 的方式已经不太现实，而且效率不高。所以也有不 Review 只测试的方式来验收 AI Coding 生成的代码，在修改和生成代码的同时，让AI也生成对应的单元测试，人类负责把关单元测试的通过情况，可能也许也是一种可行的AI Coding协同方式。

后续的规划

随着 AI 的普及和渗透，获取知识、甚至获取技能都越来越轻而易举。坏的方面是，个人的知识和技能越来越贬值；乐观的方面是，个人可以利用的知识和技能也是越来越多，也越来越轻松。

最近 OpenClaw 非常火，Peter Steinberger 是其核心开发者。从其 GitHub 主页可以看到，在 Claude 爆火之前，他一直在做迭代各种各样的工具或者产品（具有完整定义功能的程序就算产品，不一定是像 WeChat/WhatsApp/TikTok 这样才算），OpenClaw的爆火不过是其多年程序迭代的一次厚积薄发。后面希望可以学习他这种方式，在做中学，在学中做，这也许是 AI 时代最快的进步方式。

后面将不再进行纯粹的单点知识分享，希望可以从打造一个真实可用的产品角度去分享打造的过程。这个产品只需要能提供完整可用的功能就行。

在这个知识和技能获取越来越便捷的时代，迭代速度也许才是制胜法宝。

OK，以上就是一些个人浅显的、混乱的感想和 2026 年的 Flag，剩下的就交给时间和执行了，各位道友记得点赞追番一起加油吧！