自建美股期权新挂牌收益率监控：从选型到树莓派部署

记录一次从"随手问问"到"跑起来的树莓派服务"的完整过程：期权数据源怎么选、 期权价格构成和Delta/IV这些指标到底怎么用、新挂牌合约监控系统怎么设计、 上线后踩的几类坑（计算逻辑、产品设计、运行环境、部署运维）、一次真实 历史数据回测的探索过程（yfinance/IBKR碰壁，MarketData.app走通）、 从历史统计到"单持仓vs历史基准"对比工具、独立于通用筛选的重点关注清单， 以及完整的部署和日常运维步骤。附可直接照抄的配置和命令。

起点：一个简单的需求

最初的想法很朴素：卖美股期权（covered call / cash-secured put）的时候， 想要一个自动化的收益率追踪工具——输入股票代码、行权价、方向（卖put还是 卖call）、目标年化收益率，系统自动跟踪报价，一旦达到目标就发Telegram通知， 内容包括触发时间、当前报价、方向、收益率。

这个需求本身不复杂，年化收益率公式也很直接：

sell_put:  annual_yield = premium / strike * (365 / days_to_expiry)
sell_call: annual_yield = premium / underlying_price * (365 / days_to_expiry)

（premium建议用bid价，不要用mid价——流动性差的合约mid价容易虚高， 后面会讲到为什么。）

真正花时间的地方，是把"数据从哪来"这件事想清楚。

数据源选型：一圈比较下来

选型过程大致是这样的排除法：

最后选定的策略：先用yfinance把整套逻辑验证通，未来想长期稳定跑， 再迁移到Tradier或Alpaca。数据源在代码里做成了一个可替换的接口 （QuoteProvider），换源不用动上层业务逻辑。

巴菲特式价值投资研究：A股核心组合 + 美股/新兴市场补充审查

本文以巴菲特、芒格的价值投资框架为出发点，在A股中筛选了23只具备"高股息、经营稳定、护城河清晰"特征的标的（其中2只作为风险警示案例单列，不参与组合权重），并对每一只标的过去十年（部分回溯至上市以来）的年报进行了逐年审查，重点核查净利润是否真的"不大幅波动"。审查发现，多只市场公认的"高股息稳定股"，历史上其实经历过远超预期的利润波动甚至真实亏损。第九至十二节给出基于审查结果修正后的A股组合配置建议；第十三节起是境外补充研究，覆盖美股和新兴市场标的，采用同一套审查方法论但不并入A股权重表。

更新说明：本文历经八轮扩充。第一至六轮详见下方"范围调整说明"之前的记录（紫金矿业、格力电器/招商公路/中国平安/五粮液、海螺水泥/国投电力/建设银行/内蒙华电/上汽集团、中石油中石化、现金流因子核实、美的库卡与格力钛/双汇的双向复查）。第七轮补充了A股回购注销生态研究，包括美的近5年回购注销详细历史、全市场回购收益率与注销比例统计，以及宁德时代、海尔智家两只新标的的十年审查（详见第八节延伸）。第八轮是境外补充研究——对高通(QCOM)做了完整十年审查、整理了约20只美股高股息标的、核实了"回购注销文化"里ROE/ROIC失真的方法论问题（AutoZone、O’Reilly等负资产案例）、推荐了10只美股回购注销标的，并审查了Mohnish Pabrai持仓的KSPI（哈萨克斯坦）和BIM（土耳其"好市多"）两只新兴市场标的，发现了货币贬值周期对美元计价股价的系统性冲击规律（详见第十三、十四节）。

范围调整说明：应读者要求，银行股（招商银行、建设银行）和房地产/建材周期股（海螺水泥）自第七轮起调整为审查记录，不纳入A股组合权重——这不是因为审查发现了新的风险，而是读者明确表示"银行看不懂、地产不予考虑"，希望组合聚焦在自己有能力判断的领域。这三只标的的详细审查内容仍完整保留在第二、四、五节，供参考对照。

一、筛选逻辑与审查方法

价值投资的核心不是找"股息率高"的股票，而是找护城河深、现金流可预测、管理层理性分配资本的生意。市场上很多"高股息股"其实是靠周期顶部的高分红伪装成"稳定股"，一旦周期反转，股息和利润会同步塌陷。

因此，本文对每只标的做了三件事：

1. 拉出近十年（或上市以来）净利润的逐年数据，标记出现负增长甚至亏损的年份；
2. 追溯每一次大幅波动的原因——是天气/大宗商品价格这类外生周期因素，还是需求结构性变化、公司治理问题、食品安全/合规事件这类更值得警惕的内生风险；
3. 核查分红政策在利润下滑年份是否依然坚持，这是判断管理层是否真正"以股东回报为先"的试金石。

二、25只标的十年审查结论一览

三、新增标的深度审查：紫金矿业

紫金矿业是资源类股票里质地和成长性都相当突出的公司，值得单独展开审查，原因是它的风险结构和其他标的都不一样——既不是纯粹的商品价格周期，也不是需求结构性变化，而是叠加了资源并购、安全生产、股价估值三重因素。

巴伦西亚室内游泳池踩雷/避雷指南：地铁可达 + 直营 vs 委托经营实测对比

最近因为想带孩子就近学游泳、周末自由泳，花了不少时间把巴伦西亚市内几家室内恒温泳池挨个查了一遍。核心诉求很简单：室内、恒温、能直接买单次票游泳也能报课、地铁方便。查下来发现坑还不少，官方网站信息也有互相"张冠李戴"的情况，索性整理成一篇笔记，给有同样需求的朋友参考。

筛选标准

• 室内恒温泳池（排除露天季节性泳池）
• 支持单次买票游泳，同时可以单独报名儿童游泳课程
• 地铁沿线或换乘方便
• 卫生、服务、设备维护口碑过关

一个容易被忽略的关键区别：直营 vs 委托经营

巴伦西亚市立体育基金会（FDM）名下的"市立泳池"，很多人以为都是同一个管理体系、同一套票价，其实不是。有些是 FDM 直接运营（gestión directa），有些是委托给第三方公司或协会运营（gestión indirecta），两者的票价体系、办卡规则可能完全不同：

逐个泳池实测印象

Campanar（🏊 综合评分高，但要挑时间去）

• Google 4.4/500+条评价，官方口碑"设施完整、打扫及时”
• 但多条独立点评反复提到中午和训练时段泳道拥挤，非会员的多次卡在周末使用上还可能受限
• 个别设备（计时钟、储物柜）偏旧
• 结论：适合错峰去，高峰时段（尤其周六上午）要有心理准备

El Carmen（🏊 规模小但不挤，直营票价透明）

• Google 4.2分左右，服务口碑好，员工评价高
• 官方排班表明确写出"Baño Libre"专属时段（周六 8:30–14:30），确定性强
• 缺点：老建筑，空调/整体维护偏旧；曾有过维修后长期未公布复工时间的历史投诉
• 20米4条泳道，规模比 Campanar 小，但点评反而没有拥挤投诉

Malilla（设施新，但票务独立）

• 25米室内池+教学池，设施新，儿童项目齐全
• 独立票务体系，不确定跟 FDM 直营馆是否同价，需单独确认
• 交通不在地铁沿线，需要公交接驳

Ayora（地铁最方便，但维护投诉多）

• 地铁站几乎就在门口，交通体验第一
• 但更衣室"脏"“需要翻新"的投诉反复出现，官方账号也曾公开承认在改善淋浴区
• 团课（Aquagym）人满为患的投诉也不少

Benimàmet

• 25米室内池+教学池，规模不小
• 曾有更衣室脏、有蚊虫、接待冷淡的具体投诉
• 官网标注的最近地铁站信息前后矛盾，建议致电确认交通方式

Petxina（⚠️ 一度以为的"黑马”，实为踩雷案例）

• 地铁 L1 线 Túria 站直达，评分高达4.3/1200+条评价
• 但深挖后发现：泳池自2024年10月起因屋顶结构问题关闭，健身房等"旱地"区域2025年才恢复，泳池翻修工程款早已批下但截至查证时仍未确认正式复开
• 教训：高分老评论不代表现在能用，尤其遇到"官网刚宣布恢复运营"这种消息时，一定要分清楚"整个中心"和"泳池部分"是不是一回事

Nazaret / Font de Sant Lluís

• 确认是 FDM 直营,但都偏远、缺乏地铁覆盖，主要靠公交，只有在其他选项都不合适时才考虑

一些踩坑心得

1. 官网信息也会"张冠李戴"：查到过某泳池页面挂着的名字、地址、电话其实属于另一个独立设施，评分和管理方也搞混过，多方交叉核对很有必要。
2. “评分高"不等于"现在能用”：碰到过泳池实际因维修关闭超过一年，但网上高分评论还是几年前积累下来的老数据。查证前，最好搜一下最近一年内有没有"关闭"“维修"“重开"相关的新闻。
3. 直营 vs 委托经营，直接影响票价和规则：同样叫"市立泳池”，背后的运营方可能完全不同，买次卡、周末使用规则都可能不一样。
4. 周六上午这种黄金时段，最好找到"官方排班表"而不是笼统的营业时间：营业时间不等于自由泳时段，两者有时候是分开的。
5. 有具体细节的负面评论（比如官方账号公开回应改善某问题）比笼统的星级更有参考价值。

写在最后

目前个人倾向：El Carmen 更适合看重"人少+票价透明"的场景，Campanar 更适合看重"交通最直达"但能接受高峰期拥挤的场景。如果你也在巴伦西亚找室内泳池，建议打电话直接确认三件事：儿童单次票价格、自由泳具体时段、以及最近有没有维修/关闭安排——网上的信息永远滞后于现实。

教堂讲道录音"发闷发空"是怎么回事：一次频谱分析实录

起因是一段教堂讲道录音，主观感觉"比较空洞"。这篇整理了完整的排查过程——怎么用频谱分析定位问题、为什么会这样、试过哪些软件修复方案、最后到底该怎么办。全程没有玄学，每一个结论都配了实测数据。

一、“空洞"到底是什么意思

日常说一段录音"空洞"“发闷"“不清楚”，背后其实通常是两类问题：

1. 混响太重——声音在房间里"荡"出来的回声尾巴太长，把每个字的尾音和下一个字的头音糊在一起
2. 频率失衡——负责"清晰度"的中高频（3000Hz以上，人耳分辨辅音、齿音靠的就是这部分）太弱，负责"厚重感"的中低频（150-1000Hz）又太强

这两个问题经常同时出现，而且互相成因——原因下面会讲到。

二、怎么"看见"声音的问题（给非专业人士的频谱基础）

耳朵听到的是一整团混在一起的声音，但任何声音都可以拆解成不同频率成分的叠加，就像一束白光可以用棱镜拆成七种颜色。这个拆解过程叫频谱分析。

拆开之后，声音里"哪个频段能量多、哪个频段能量少"就能被量化成具体数字，而不是"听感"这种主观描述。举几个和人声相关的频段的直觉对应：

拿实际录音跑一遍频谱分析，就能看到这段录音的频段能量到底是怎么分布的，而不是靠"感觉比较空"这种模糊描述。

三、实测诊断：这条录音到底哪里出了问题

拿这条30秒的样本实测下来，频段能量分布是这样的：

150-1000Hz这个区间加起来占了82.5%的能量，3000Hz以上加起来只有1.4%。翻译成人话：这条录音里绝大部分能量堆在"发闷"的频段，负责"清晰"的频段几乎是空的。这就是"空洞感"在数字上的样子。

除了频段分布，还测了另外两个指标：

• 混响衰减时间（估算约1.2秒）：语音说清晰、可懂度高，理想的混响衰减一般在0.3-0.6秒；教堂这种石材/瓷砖地面、高穹顶的空间，衰减到1.5-2.5秒也很常见。1.2秒不算最夸张，但已经足够让字与字的尾音互相重叠。
• 左右声道相关性（0.86）：这个是用来排除"两个麦克风收到的信号互相干涉，产生梳状滤波"这种问题的——数值不低，说明"空洞感"不是这个原因造成的，可以排除。

四、根本原因：为什么会这样

这条录音是用手持录音笔（Tascam DR-05X）录的，放置位置离讲道者大约20米。

这里有个声学概念叫临界距离——房间里"直接从声源传过来的声音"和"被墙壁反射后再传过来的混响声音"能量相等的那个距离。超过这个距离，麦克风收到的信号就会被混响"淹没"，直达声占比很低。对于教堂这种中大型、混响时间在1秒左右的空间，临界距离通常也就几米，很少会超过10米。

20米远远超出了临界距离。这解释了前面测到的全部现象：

• 麦克风收到的几乎是"扩散声场"（房间到处反射后混在一起的声音），而不是"干净"的直达声
• 房间的低频驻波（房间形状导致的低频共振）在扩散声场里天然占主导，对应测出来的150-1000Hz能量堆积
• 高频在空气里衰减快，扩散声场里高频比例本来就低，对应测出来的3000Hz以上几乎消失
• 录音里能听到明显的混响拖尾，对应测出来的~1.2秒衰减时间

关键结论：这不是设备故障，也不是参数没调好，是录音距离超出了物理极限决定的。

五、试过的软件修复方案，和为什么都不够理想

既然是"录制阶段"的问题，理论上后期能做的都是有损的补救。但为了搞清楚软件能做到什么程度，实际测了四条路：

1. EQ均衡（削低中频、提升高频）

思路很直接：用均衡器把过多的150-400Hz削掉一部分，把几乎消失的4000-8000Hz提升回来，让残留的高频信息在可闻范围内被放大。

ffmpeg -i input.wav -af \
"loudnorm=I=-23:TP=-3:LRA=7, \
highpass=f=85, \
equalizer=f=250:t=q:w=1.5:g=-5, \
equalizer=f=450:t=q:w=1.2:g=-3, \
equalizer=f=4500:t=q:w=1:g=4, \
equalizer=f=8000:t=q:w=1:g=2, \
acompressor=threshold=-22dB:ratio=2.5:attack=8:release=120:makeup=3, \
loudnorm=I=-16:TP=-1.5:LRA=11" \
output.wav

效果：主观听感上清晰度确实有提升，但混响本身（1.2秒的拖尾）完全没有改变，只是把残留的高频信息"放大"到了可闻范围，本质是化妆不是治病。优点是绝对安全，不会引入任何副作用。

私人播客搭建指南（本地录音 → 不对外发布的 RSS）

场景：Tascam DR-05X 录的音频（讲道之外的个人用途，比如私下的谈话记录、不方便公开的内容），只想自己或指定的少数人用播客 App 收听（可调速、断点续播、离线下载），不提交 Apple Podcasts / Spotify 审核，不出现在任何公开目录。

架构选择说明：这一版指南采用"存储与出口分离、Pi 自己对外服务"的方案——原因是西班牙 LaLiga 转播期间会协调运营商封锁 Cloudflare、Backblaze 等多个 CDN/托管商代理网络的 IP 段打击盗播，而这些 IP 背后往往同时挂着几千个互不相关的正常网站，一并被误封。只要走的是"多租户共享 IP 代理转发流量"，换哪家云厂商都治标不治本；真正解决办法是让实际提供服务的 IP 只属于你自己。被封的是 Cloudflare 的代理网络（橙色云朵），不是它的 DNS 解析服务，所以 DNS 这一层继续用 Cloudflare 完全没问题——只要关掉代理（灰色云朵，DNS-only），流量直接打到你家 IP，根本不经过 Cloudflare 网络。

1. 先明确一个关键前提：RSS 播客的"私有"本质上是"不可枚举"，不是"加密"

播客协议本身没有账号登录的概念，播客 App 只认一件事：一个 RSS feed 的 URL。所谓"私有播客"，行业里（Patreon、Supercast 这类会员播客平台）用的都是同一个原理：

• URL 本身包含一段无法被猜到的随机字符串，不做目录列表、不被搜索引擎收录、不提交到任何播客目录
• 只要知道这个 URL 就能订阅，所以"私有"约等于"不公开的地址"，不是真正意义上的账号鉴权

自己一个人用，这个强度完全够。因为这一版是 Pi 自己对外提供服务（不是第三方托管），如果以后想分享给一两个人、要真正的访问控制，也可以在自己的 Web 服务器上直接加 HTTP Basic Auth（见第 6 节），比依赖第三方的"访问控制产品"更彻底——权限完全在自己手上，不用再考虑对方是不是又被列进了某个封锁名单。

2. 架构总览：Pi 400 直接对外服务，云存储只做离线备份

Tascam 录音 → inbox/ → 本地处理（复用现有 enhance_audio/whisper 函数）
                              │
                              ▼
                   本地磁盘：~/private-podcast/media/
                   （这就是最终对外提供下载的文件，不上传到任何公开可访问的第三方）
                              │
                ┌─────────────┴─────────────┐
                │                             │
                ▼                             ▼
        Caddy（本机 :80/:443）        可选：同步一份到 B2 私有 bucket
        直接对外提供 RSS + 音频          （纯备份，从不公开这个 bucket 的域名，
        文件，走家庭宽带出口               只有你自己用 B2 后台/密钥能访问）
                │
                ▼
     DDNS（Cloudflare DNS-only）把域名指向
     家里当前的公网 IP，自动更新
                │
                ▼
        播客 App 通过这个域名订阅

核心逻辑：把"存数据"和"对外服务"彻底拆开。B2（或任何对象存储）只用来防止 Pi 的 SD 卡/硬盘损坏导致录音丢失，这个 bucket 永远不公开，播客 App 和听众根本不知道它的存在，自然也不会因为 B2 的 IP 被列进某个封锁名单而受影响。真正对外提供服务的，是只属于你自己、没有任何第三方共享的家庭宽带 IP。

本文记录了「叶牧讲道」播客自动化系统从最初的云端构想，到最终在 Raspberry Pi 400 上稳定运行的完整过程：架构如何演进、踩过哪些坑、每个坑是怎么修的。原始素材来自与 GPT、Gemini、Claude 三个 AI 反复讨论、审查、修 bug 的散乱记录，这里按主题重新整理成一篇完整文档。

一、项目概述

目标

将 YouTube 播放列表中的讲道视频，自动转换为符合 Apple Podcasts / Spotify 标准的播客节目，并全自动发布，全程无需人工干预。

最终技术栈

• 硬件：Raspberry Pi 400（家用键盘一体机，4GB RAM）
• 下载：yt-dlp（配合 Deno 作为 JS Runtime 解 YouTube 签名挑战，详见第七节）
• 音质优化：RNNoise（ffmpeg arnndn 滤镜）+ ffmpeg loudnorm（EBU R128 响度标准化）
• 语音转录：whisper.cpp（本地，零成本，比 Python 版快约 3 倍）/ openai-whisper（Python 版，兜底）
• AI 摘要：Google Gemini API（gemini-2.5-flash，免费层）
• 存储：Cloudflare R2
• 发布：GitHub + Cloudflare Pages（自动部署 RSS）

完整处理流水线

YouTube 播放列表（支持多个，自动去重）
    ↓
yt-dlp 下载（bestaudio 192k，限速 + 随机休眠，模拟正常用户）
    ↓
RNNoise 降噪（arnndn，sh.rnnn 模型）+ ffmpeg loudnorm（-16 LUFS，双声道 96k）
    ↓
whisper.cpp / openai-whisper 本地转录（描述文字不足 50 字时触发）
    ↓
Gemini 2.5 Flash 生成摘要（中文摘要 + 经文金句 + 西班牙语标题）
    ↓
上传 Cloudflare R2
    ↓
生成 RSS（sermon.xml，三重保护写入）
    ↓
git push → Cloudflare Pages 自动部署

这套流水线和最初的设想差别很大——最初的方案是纯云端架构，走了不少弯路才收敛成现在这个"零成本、自维护"的家用版本，详见下一节。

西班牙(瓦伦西亚)夫妻间转账 vs 赠与税(ISD) —— 查证总结

整理日期:2026年9月4日 依据:GPT两轮查证 + Claude 交叉核实(BOE、DGT约束性咨询原文、律所/税务咨询解读)

一、结论先行

不存在"夫妻间转账超过 €1,000 就构成赠与"这样的法定门槛。 这是本次查证要否定的核心谣言,GPT 和 Claude 交叉核实后一致确认:没有任何官方规定支持这个数字。

判断是否构成赠与(donación),看的是实质,不是金额或频率:

1. 赠与人财产是否实质减少(empobrecimiento del donante)
2. 受赠人财产是否实质增加(enriquecimiento del donatario)
3. 是否存在赠与意图(animus donandi / 无偿意图)
4. 受赠人是否接受
5. 是否满足对应的法律形式要件(现金赠与通常要求公证文书 + 资金来源可追溯)

五个要件同时成立,才构成 donación,才触发 ISD(继承与赠与税)。

二、⚠️ 需要修正 GPT 第一轮回复的一处错误

GPT 第一轮回复中,把"配偶享受99% bonificación(税额减免)“描述成 2026年6月1日起才适用的新规则,这个时间线是错的,容易造成误解。准确情况是:

结论:你妻子作为配偶,享受99%减免这件事从2023年就成立了,不是2026年才有的"福利”。 2026年6月的新规真正带来变化的是关系较远的兄弟姐妹/叔伯姨舅类,以及对所有赠与(含配偶间)强化了公证文书和资金可追溯性的手续要求。

三、第二轮 GPT 查证的 DGT 案例——已交叉核实,基本准确

Claude 逐一核实了 GPT 引用的 DGT(税务总局)约束性咨询(consulta vinculante),结果:

前两篇见 双机隔离与隐私保护（2026年6月3日）与8月复盘·手机号隔离实操篇（2026年8月24日）。本文不推翻前两篇的框架，而是指出一个前两篇都没有覆盖的威胁模型——2026年9月15日起施行的《国务院关于出境入境管理的规定》赋予了边检当场查验手机的权力，这是一种前两篇讨论的"账户/认证体系隔离"完全应付不了的场景，需要单独补一套方法论。

一、先说清楚：这是两种性质完全不同的威胁

前两篇文章的核心判断是对的，但都建立在一个隐含前提上：攻击者是远程的——黑客、平台大数据关联、SIM Swapping。应对远程威胁，靠的是账户体系隔离、认证器独立、单点故障消除，这套逻辑完全成立，不需要推翻。

但边检翻手机是物理接触 + 当场胁迫解锁的场景，前提完全不同：

也就是说，“平台知道A和B是同一个人 ≠ 平台获得了A的数据"这个判断在边检场景下依然成立，但已经不是重点——边检不需要靠数据关联去"发现"你是谁，他们直接拿着解锁后的手机看。这时候起作用的防线，不是身份隔离，而是**“这部手机上到底装了什么、留了什么”**。

二、共通部分：物理双机架构本身就是最好的边检防线

好消息是，前两篇建立的"物理双机 + 独立Apple ID"架构（第一梯队40分项），几乎原封不动地就是边检场景下最有效的防线——只是原因变了：

• 原文的理由：防止国内平台通过设备指纹/账户关联把海外身份和国内身份连起来
• 边检场景下的理由：如果国内机上原本就不装Gmail、Signal、券商App，边检翻遍这部手机也拿不到任何有价值的东西——不需要临时清理，因为架构上从一开始就是隔离的

这也是为什么本文的建议会反复强调：过关前的"清理”，本质上是对已经混用的设备做补救，如果双机架构从一开始就做到位，边检来临时你几乎不需要额外操作。这正好呼应第一篇里那句结论：

双机 + Apple ID分离：40分，账户与认证体系分离：40分

这80分在边检场景下依然是地基，只是补救成本从"平时不用管"变成了"过关前需要重新审计”。

三、边检场景特有、前两篇未覆盖的三个新维度

3.1 内容审计：不是"身份"而是"内容"本身构成风险

前两篇的三层模型（国内生态 / 海外生活 / 核心资产）划分的是账户归属，边检审计需要额外叠加一层内容敏感度的划分，这是前两篇完全没涉及的维度：

                    【 边检视角下的内容风险分层 】
                           │
      ┌────────────────────┼────────────────────┐
      ▼                    ▼                    ▼
  低风险内容              中风险内容              高风险内容
 （不需处理）           （需要审计清理）        （不应出现在随身设备上）
      │                    │                    │
  ├─ 日常聊天/照片        ├─ 群聊列表/群名       ├─ 讲道稿件/教会通讯录
  ├─ 银行/地图/天气App    ├─ 转账备注关键词      ├─ 境外资金往来细节
  └─ 普通网页浏览记录     └─ 公众号关注列表      └─ VPN/Telegram/Signal痕迹

这一层审计前两篇的框架里完全没有位置，因为它关心的不是"这个账户属于谁"，而是"这段内容一旦被人工翻看会造成什么后果"。

讲道录音：录制、播客制作、语音识别与传输综合方案

本文档在原始方案基础上，修正了 NotebookLM 单文件上传限制的问题，并加入了 Tascam DR-05X 录音参数的优化建议，整合出一套从录制到发布的完整工作流。

1. 使用场景

• 使用 Tascam DR-05X 录制教会讲道，每次约 1 小时
• 目标产出：
  1. 播客发布（后期处理、降噪、发布到 pabloye.es）
  2. 通过 WhatsApp 发送给他人
  3. 对方使用 Google NotebookLM 分析录音，提炼约 20 分钟内容
  4. 自己使用 whisper.cpp 做语音识别
  5. 保留原始录音，供未来剪辑、降噪、AI 音频处理等使用

2. 录音参数：可以且应该降低

当前设置 96kHz / 24bit / 立体声，1 小时讲道文件接近 2GB （96000 × 3字节 × 2声道 × 3600秒 ≈ 1.93GB，与实际观察吻合）。

2.1 采样率：96kHz → 48kHz（建议改）

人声频率范围集中在几百 Hz 到 8kHz，泛音很少超过 16–18kHz。48kHz（奈奎斯特上限 24kHz）对语音内容完全足够，是广播和播客制作的标准采样率。96kHz 的价值主要体现在古典乐录音、母带处理时的升采样余量或极端变速处理，人声讲道场景用不到。

这一步单独可将文件从 1.93GB 降到约 965MB（减半），且人耳无法察觉音质差异。

48kHz 还是 44.1kHz？

两者对人声都没有可闻差异，选择主要看下游用途而非音质：

迁移总方案：博客 + 播客脱离共享 CDN 代理 IP 依赖

背景与目标（2026-08-29 更新）

当前问题：博客（Cloudflare Pages）和播客音频（Cloudflare R2）都跑在 Cloudflare 的代理网络上，2026/27 赛季 LaLiga 反盗版封锁几乎天天有比赛日触发，导致这两块服务频繁被 O2 误伤。

如果你的目标是 “尽量利用现成互联网基础设施，少自己维护服务器，同时降低西班牙 LaLiga IP 封锁对博客和私人播客的影响”，我不建议把方案重心放到 Linode VPS + 自己维护 Caddy / UFW / DDNS 上。那属于“技术上可行，但运维成本偏高”的路线。

我重新按这个目标筛了一遍。核心问题是：不能简单地把 Cloudflare 换成 Vercel / Netlify / Bunny / AWS CDN，就认为安全了。 OONI 2026 年的实测显示，LaLiga 相关 IP 封锁已经波及至少 36 家基础设施/托管提供商、7441 个 IP，包括 Cloudflare、Amazon、Akamai、Meta、Microsoft 等；单个时间窗口封 4–20 个 IP，就可能影响几十万共享基础设施上的域名。OONI

重要更正：原方案曾建议博客迁往 Vercel，但经查证，Vercel、Netlify、GitHub Pages、BunnyCDN 等主流共享 IP CDN/托管平台，同样被 LaLiga 这轮封锁波及过——本质上都是"几十万个域名挤在同一批共享 IP 上"，只是被点名的频率和时间点不同，不是安全选项。因此博客的迁移目标改为自建到已有的 Linode VPS，用独立静态 IP 避开"共享大池子"这个结构性风险。