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

记录一次从"随手问问"到"跑起来的树莓派服务"的完整过程：期权数据源怎么选、 期权价格构成和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），换源不用动上层业务逻辑。

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

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

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

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

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 自动部署

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

前两篇见 双机隔离与隐私保护（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 避开"共享大池子"这个结构性风险。

隔离测试 Agent 环境部署指南 v2（完整版，从零到部署一份文档搞定）

巴黎机票监控 + 巴萨车票监控 + 假日感知 AI 行程规划

这是一份自包含文档，不需要再回看 v1。相对最初版本的核心变化：把"数值判断"从 LLM prompt 里挪到 Python 代码里，权限模型从裸 ask 改成精确规则，密钥彻底和 OpenCode 进程隔离，Playwright 浏览器进程容器化加固；新增一个每周跑一次的"假日规划器"结合巴伦西亚本地假期找出值得关注的出行窗口，并在规划器最后一步加了一个唯一允许 AI 做主观判断的"参谋"环节——AI 只负责在已核实数据基础上排序和给理由，不碰任何数字，且有校验兜底。

0. 这一版改了什么（对照上一轮审查）

1. 隔离环境搭建（一次性）

1.1 创建独立的本地 macOS 账户

系统设置 → 用户与群组 → 添加账户，选择「标准」账户，账户名建议 agentlab。

双机隔离与隐私保护——2026年8月复盘

原文见 双机隔离与隐私保护(2026年6月3日)。本文不推翻原文的核心框架,而是用本人最近两周实测调研海外"保号卡"生态的结果,补上原文里比较薄弱的一块——手机号隔离到底该怎么落地。结论是:原文的方法论完全正确,但"手机号隔离"这个具体战术在2026年下半年已经基本走不通了,需要换一套实操方案。

一、原文核心框架依然成立,重新确认一遍

原文最有价值的判断,现在看依然站得住,值得再强调一次:

平台知道 A 和 B 属于同一个人 ≠ 平台获得了 A 的数据。 Identity Correlation(身份关联)≠ Data Access(数据访问)。

以及那张 100 分权重表:

以及那句最终结论:

最划算的目标不是"完全匿名",而是即使国内手机丢失、被盗、被恶意软件控制,海外邮箱、银行、券商、税务账户仍然保持独立且可恢复。

这套判断这两周被反复验证——越想追求"运营商也不知道是我"这种强匿名性,越会发现现实中根本走不通,而且这种投入本质上是在第三梯队(5分项)里内卷。下面详细说说为什么。

二、2026年下半年的新现实:全球免实名SIM卡生态正在系统性收紧

这两周为了给"注册微信小号"找一张免实名保号卡,逐个验证了市面上最热门的几个选项,结果是全军覆没,而且不是偶然踩坑,是结构性问题:

为什么会这样——不是运气不好,是全球趋势

背后的驱动因素是一致的:

（待测试）跨境数字化完全指南：西班牙 ↔ 中国大陆

适用场景： 旅居西班牙的华人回国期间，需要访问西班牙政府系统、维持远程办公，以及无人值守地运维留守在家的树莓派节点。 版本： v5.9 | 覆盖：Cloudflare Tunnel 穿透（--protocol 参数修正为 http2 + 初始部署即加 --network host 及 --log-opt max-size/max-file 日志限制 + 出口节点验证 + 三层封锁对策）· Zero Trust 访客隔离 · 树莓派自愈监控（Xray Reality 健康检查解除硬编码限制，修复 send_email() From 头编码 bug，alert_relay.py 收紧为 127.0.0.1 绑定 + hmac 恒定时间比较，报警架构改为国内节点优先直连、失败降级中继，5.6 节日志管理，ddns_update.sh 修复静默失败问题：查询和更新两个阶段均补充 success 字段校验，不再无条件打印"已更新"）· CF Workers 轻量转发（cfst 安装指南 + 按需手动优选）· Xray Reality IP 保证方案（住宅 IP + DDNS + Fallback 默认关闭 + 系统加固 + 客户端三层防线架构 + ufw CGNAT/Docker 网段自锁修复 + 伪装目标域名修正 + 第七节泛化双向部署 + sudoers 免密白名单分级设计）· 第 2.7 节：SSH 隧道首选 + gost 备选 + 完整清理步骤，2.7.1 节客户端方案，gost 开机自愈精确等待方案，全文 Cloudflare 后台路径系统性核实：确认 Team & Resources → Devices（原 My Team/Settings→WARP Client）、Access controls → Applications/Service credentials（原推测标注已转正）、Workers & Pages 分类名未变，Custom Domains 标签页可能已改名 Domains & Routes（加谨慎提示）

[Read More]