最后定位到的根因也很“隐形”：宿主机目录的 Default ACL 影响了 containerd 为 Pod 生成并挂载的 resolv.conf，导致非 root 容器无法读取 /etc/resolv.conf，从而触发了 libc resolver 的兜底逻辑，盲目向 127.0.0.1/[::1]:53 发起查询。

背景

我本地用 Argo CD 管理和发布应用。这次想引入 argocd-diff-preview 做 CI 检查，把 diff 结果作为 GitHub 评论回写到 PR。

效果大概是这样：

为了跑这类任务，我需要一个轻量的 Kubernetes 集群。正好手头有飞牛 NAS，就在上面用 Docker 起了一个 K3s server（禁用 servicelb），docker-compose 如下：

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

version: "3.8"
services:
  argocd-k3s:
    image: k3s:v1.35.1-k3s1
    container_name: argocd-k3s
    privileged: true
    network_mode: bridge  # 防止本机的 Docker 网络的 DNS 干扰
    restart: unless-stopped
    ports:
      - "9444:6443"
    command:
      - "server"
      - "--prefer-bundled-bin"
      - "--disable=servicelb"
      - "--node-name=argocd-k3s"
      - "--kube-apiserver-arg=event-ttl=10m"
    volumes:
      - /vol1/1000/K3sData/argocd-k3s/data:/var/lib/rancher/k3s
      - /dev:/dev:ro

然后在 CI 里执行 argocd-diff-preview 时就开始报错：

1
2
3
4
5
6
7
8
9
10
11

argocd-diff-preview  \
    --create-cluster=False --keep-cluster-alive  \
    -d  \
    --argocd-chart-url ${chart_url} \
    --repo ${repo} \
    --target-branch ${env.CHANGE_BRANCH} \
    --argocd-chart-name argocd-apps

Tue, 31 Mar 2026 12:42:20 UTC DBG AppsetGenerateWithRetry attempt 1/5 to Argo CD...
Tue, 31 Mar 2026 12:42:21 UTC DBG Waiting 1s before next appset generate attempt (2/5)...
Tue, 31 Mar 2026 12:42:21 UTC WRN Appset generate attempt 1/5 failed. error="failed to run argocd appset generate: argocd command failed: {\"level\":\"fatal\",\"msg\":\"rpc error: code = Internal desc = unable to resolve git revision : failed to list refs: dial tcp: lookup argocd-redis on [::1]:53: read udp [::1]:59984-\\u003e[::1]:53: read: connection refused\",\"time\":\"2026-03-31T12:42:21Z\"}\n: exit status 20"

现象：Pod 里用 [::1]:53 查 DNS

Argo CD 无法正常同步应用。查看 argocd-server 日志，发现大量类似报错：

1

Failed to resync revoked tokens... dial tcp: lookup argocd-redis on [::1]:53: read udp [::1]:34952->[::1]:53: read: connection refused

第一眼看到这个日志，我的反应是：为什么 Pod 内部会用 IPv6 的本地环回地址（[::1]）去查 DNS？

按常规思路我先检查 CoreDNS，但 CoreDNS 运行完全正常。这就更怪了：dnsPolicy: ClusterFirst 的 Pod，理论上应该把查询发给 CoreDNS（例如 10.43.0.10），而不是对着本地 53 端口重试。

排查：从 /etc/resolv.conf 入手

既然外部看不出问题，就直接进入容器确认 DNS 配置：

1

kubectl -n argocd exec -ti argocd-server-fbbdf5d4d-c8z5q -- /bin/bash

然后查看 /etc/resolv.conf：

1
2

argocd@argocd-server:~$ cat /etc/resolv.conf
cat: /etc/resolv.conf: Permission denied (os error 13)

到这里基本就能解释日志了：应用进程读不到 /etc/resolv.conf，就拿不到 nameserver 配置。

在这种情况下，libc resolver 会走兜底逻辑，直接尝试向本地 localhost（127.0.0.1 和 [::1]）发 DNS 查询；如果本地没有 DNS 服务监听 53 端口，就会出现 connection refused。

所以这并不是 IPv6 本身的问题，而是容器“看不见”正确的 nameserver。

根因：文件权限末尾的 “+”（ACL）

继续用 ls -l 看权限：

1
2

argocd@argocd-server:~$ ls -alh /etc/resolv.conf 
-rw-r-----+ 1 root root 102 Mar 31 11:56 /etc/resolv.conf

我把这里的内容帖给 AI 之后, 它就提到了 ACL 问题：

注意权限末尾的 +：这表示该文件启用了 ACL（Access Control List）。即使基础权限看起来没问题，ACL 也可能额外收紧“其他用户（other）”的权限。由于 Argo CD 默认以非 root 用户（例如 UID 999）运行，它就会被挡在门外。

/etc/resolv.conf 不是镜像里的文件，而是运行时挂载进来的。为了确认它在宿主机上对应哪个文件，我回到宿主机用 crictl inspect 查了容器挂载信息：

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

~ # crictl ps  # 找到 argocd-server 容器的 ID
CONTAINER           IMAGE               CREATED             STATE               NAME                     ATTEMPT             POD ID              POD                                       NAMESPACE
c2722b3817277       86219ff1fefea       2 seconds ago       Running             argocd-server                      3                   d32169958ed68       argocd-server-fbbdf5d4d-tjsnf                       argocd

~ # crictl inspect <container_id>  # 查看 /etc/resolv.conf 的真实 source
# {
#   "destination": "/etc/resolv.conf",
#   "options": [
#     "rbind",
#     "rprivate",
#     "ro"
#   ],
#   "source": "/var/lib/rancher/k3s/agent/containerd/io.containerd.grpc.v1.cri/sandboxes/fd2373cfd801e2f95267286af155df3ca0cd912563bc9a668cc5e1b3a4956d3e/resolv.conf",
#   "type": "bind"
# }

~ # cat /var/lib/rancher/k3s/agent/containerd/io.containerd.grpc.v1.cri/sandboxes/fd2373cfd801e2f95267286af155df3ca0cd912563bc9a668cc5e1b3a4956d3e/resolv.conf
search argocd.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.43.0.10
options ndots:5

由于我的 K3s 数据目录在 /vol1/1000/K3sData（NAS 挂载盘）上，顺着这个路径找过去，再用 getfacl 查看 ACL：

1
2
3
4
5
6

root@Host:~# getfacl /vol1/.../sandboxes/.../resolv.conf
# owner: root
# group: root
user::rw-
group::--x
other::---  <--- 真凶在这里！

真相大白：/vol1 这类 NAS 挂载盘默认可能带有严格的 Default ACL。当 containerd 在这个目录下为 Pod 动态生成 resolv.conf 时，会继承父目录的 Default ACL，把 other 权限收紧为 ---。Pod 里的非 root 进程就无法读取 /etc/resolv.conf，从而触发“查 localhost DNS”的兜底行为。

解决方案：清理 Default ACL 继承规则

我最终没有改 K3s 配置，也没有去关闭整块盘的 ACL（这通常会影响 Samba 等服务）。更稳妥的做法是：只清理 K3s/containerd 工作目录上导致继承的 Default ACL 规则。

在宿主机执行：

1
2
3
4
5

# 1. 清除沙盒目录上导致问题的 Default ACL 遗传规则
sudo setfacl -k /vol1/1000/K3sData/

# 2. (可选) 给当前存在的目录批量重置基础权限
sudo setfacl -R -b /vol1/1000/K3sData/

做完后把 Argo CD 的 Pod 删掉让它重建。新的 Pod 启动后，containerd 生成的 resolv.conf 恢复为正常的可读权限；再进入容器执行 cat /etc/resolv.conf 也不再报 Permission denied。至此，Argo CD 立刻恢复正常，应用也能正常 Sync。

自动持久化：使用 tmpfiles.d (进阶方案)

如果你担心 NAS 系统在重启或通过 Web UI 操作后会重新“遗传”错误的 ACL 规则，可以使用 systemd 的 tmpfiles.d 机制。这是一种比 Crontab 脚本更优雅的“声明式”配置。

在宿主机创建配置文件 /etc/tmpfiles.d/k3s-nas-acl.conf：

1
2
3
4
5
6

# 确保目录及其子目录基础权限为 0755
# 类型  路径                   模式  用户  组    时间  参数
z     /vol1/1000/K3sData/     0755  root  root  -     -

# 递归强制应用规则：确保 others 可读，且新生成的子项也继承该权限
A+    /vol1/1000/K3sData/     -     -     -     -     other::r-x,default:other::r-x

配置完成后，可以执行以下命令立即生效（无需重启）：

1

sudo systemd-tmpfiles --create /etc/tmpfiles.d/k3s-nas-acl.conf

系统会扫描该路径，并按照配置自动纠正所有不符合要求的 ACL 项。

总结与避坑指南

• 别被 [::1]:53 误导：Pod 内查 localhost DNS，优先检查是否能读取 /etc/resolv.conf。
• 留意非 root 容器：越来越多组件默认非 root 运行，宿主机生成/挂载的文件必须保证“other 可读”或至少对应用用户可读。
• 小心 NAS 默认 ACL：在 NAS 挂载盘上跑 K3s/Docker 时，ls -l 权限末尾的 + 往往是权限问题的信号；遇到诡异现象优先用 getfacl 定位。
• AI 真的太强大了, 问对合适的问题, 能让调试更高效。

希望这次记录能给你一个更快的排查切入点。

本文是交易系统系列的第六篇，主要记录近期在期权策略和系统功能上的优化。我把一部分组合功能做了整合，重点是我常用的牛市价差；另外，也把出错订单单独记录下来，方便后续复盘和优化。

组合订单的实现

如前文《期权策略-变种比例价差》所述，我目前主要做科创50ETF期权的价差策略。单一标的的好处是，页面和流程都能做得更聚焦、更高效。在上一篇《半自动化交易系统(五)》里，我提到过按月份做持仓管理。每个月的仓位，基本都由单腿期权和比例价差这类组合构成。

我发现自己高频会用到价差组合的构建和释放。比如创建一个价差时，每次都要做这三步：

1. 买入低行权价看涨期权
2. 卖出高行权价看涨期权
3. 构建价差组合

实现细节

这个过程完全可以自动化，而且能尽量规避短时价格波动。流动性足够好的时候，滑点也能控制在可接受范围内。所以我把这三个步骤整合成了一个独立服务，做成了一个非常简单的组合订单，结构大概如下：

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
38
39
40

[
  {
    "method_name": "buy_open_with_executor",
    "params": {
      "code": "10011349.SHO",
      "count": 6,
      "price": 0.0,
      "wait": true,
      "timeout": 30.0
    },
    "status": "completed",
    "description": "买入权利仓: 10011349.SHO x 6",
  },
  {
    "method_name": "sell_open_with_executor",
    "params": {
      "code": "10011350.SHO",
      "count": 6,
      "price": 0.0,
      "wait": true,
      "timeout": 30.0
    },
    "status": "completed",
    "description": "卖出义务仓: 10011350.SHO x 6",
  },
  {
    "method_name": "make_option_combination",
    "params": {
      "combination_type": 50,
      "contracts": {
        "10011349.SHO": 48,
        "10011350.SHO": 49
      },
      "quantity": 6,
      "strategy_name": "认购牛市价差 1.4-1.45"
    },
    "status": "completed",
    "description": "创建组合: 认购牛市价差 1.4-1.45",
  }
]

这类指令会被放进消息队列，由单独服务消费，再直接和交易系统交互。我这里为了尽快成交，直接挂对手方一档。科创50ETF期权流动性本身也不错，通常几秒内就能完成交易，实际滑点非常小，执行效率和质量都比较高。

注意：这里用的是对手方一档，也就是优先保证立刻成交的价格。如果合约流动性不好，这样做风险会很高，利润空间也会被明显压缩。

组合订单的管理

现在 AI 写代码确实很好用。需求说清楚后，页面雏形很快就能出来；我自己再把前后端对接和细节收一收，基本就可以快速上线。下面是组合订单管理页面的截图：

我还加了出错订单的“分步骤重试”能力。卡在哪一步都没关系，人肉检查一下，确认没问题就从下一步继续执行。后面如果再接 AI 做检查，会更省事。甚至当开仓单子很多时，也能靠这种组合订单形式批量处理，operator 在开平仓上的手工工作量会小很多。

价差移仓

做完这套组合订单后，我开始更系统地思考一个问题：不同月份之间平移牛市价差，成本到底有多高，以及是否值得移仓。比如我持有的是由虚值看涨构成的牛市价差，如果当月机会已经不大，那把整个组合顺延一个月，盈利概率会不会更好？

因此我也做了一个图表，持续记录我关注的价差在不同月份的价格，用来评估“为了维持盈利机会，我需要支付多少移仓成本”。

只要合约时间价值没有被完全吃掉，移仓成本通常都比较低，大多数情况下在 100 元以内。也就是说，花不超过 100 元，通常就能把一个临近到期的价差组合平移到后一个月，或者换到更低行权价，从而明显提升盈利概率。如果再叠加后续可卖出的单腿期权，这项成本并不高，但对胜率和收益改善很明显。

订单记录

股票交易的订单记录相对简单，因为频率低。但期权不一样，一天几十单并不夸张。所以我想把订单“日历化”，方便后续分析交易习惯和月度盈亏。于是我也做了一个订单记录页面，直接落每一笔订单的细节。

其中绿色块表示交易日。点进某一天，就能看到当天全部订单及状态，这样交易习惯会非常直观。

总结与展望

我一直把期权看成一种“给市场打工”的工具。只要愿意做风险可控的套利，就有机会在这个市场里持续、稳定地赚钱。这和股票不太一样，股票很多时候要同时承受系统性风险和个股风险。

这篇文章里介绍的组合订单功能，本质上就是为了更高效地执行价差策略和移仓操作，让我能更稳定地“在市场里打工赚钱”。你也能看到，我的大多数期权操作并不依赖方向预测。市场按预期走会赚得更多；不按预期走，也不至于失控，我依然保留下一月份继续操作的权利。

另外，我做这些事情的目标也很明确：把操作流程标准化，最后交给其他人或 AI 去执行。

说起市场环境，春节和国庆这样的长假期间确实特殊。市场在假期前后往往会经历较大波动——一方面投资者在假期前主动调整仓位；另一方面，假期期间可能发生的突发事件会直接冲击开市后的行情。我看到很多人的策略是”持币过节”，用现金来规避不确定性。但这对我来说不太适合，因为我的持仓是一套非常长期构建的资产配置，不想简单地为了过个假期就破坏这个结构。于是我开始思考：有没有更精致的方式，在不破坏持仓的前提下，来对冲假期的风险？

我的投资组合核心是高分红的大市值股票，辅以一些成长股和小盘股。这个组合的风格与上证50相当接近，所以在本次分析中，我用上证50作为模型。这样做也是为了简化问题——我对冲的是整体市场风险（用指数来代表），而不是逐只考虑每只股票的波动。

问题定义

我想要在假期前构建一个”保险机制”：既能保护投资组合免受假期市场冲击（主要是下跌预期），又不用破坏现有的持仓结构。

我的股票持仓规模约60万元。虽然不是大资金，但这正好是一个很有代表性的规模——足够大到需要认真对待风险，又小到需要精打细算成本。

接下来，我会从期货 和 期权两个维度分别分析，看看哪种工具最适合这个特定的问题。

对冲选择

股指期货

原理

期货是一种标准化合约：规定在未来某个时间以约定的价格交割某资产。它本身是中立的工具——既可以对冲风险，也可以用来投机。

具体到对冲：如果我担心假期后市场下跌，我可以卖出期货合约来”锁定”当前价格。这样一来，即使股票跌了，期货的盈利就会抵消股票的亏损。听起来很完美，但问题在于——期货需要保证金，而且一旦市场大幅波动，会面临”追加保证金”的风险。

对我的现实约束

上证50期货合约的规格：

• 每点300元的乘数
• 最近的合约价格约3100点
• 一手能对冲约90万市值
• 需要约15万的保证金

这就立刻产生了一个现实问题：我有60万持仓，但账户里不可能闲置15万来”冻结”在保证金上（这15万相当于25%的账户被”冰冻”）。对于我这个量级的资金，期货的保证金成本太高了。

这个工具对于资产量在几千万以上的投资者是合适的，但对我目前的情况来说，不划算。

参考：CFFEX 上证50期货

股指期货期权

原理

期权是建立在期货基础之上的。如果说期货是”必须交割”的合约，那么期权就是”可以选择交割”的权利。期权赋予持有者在未来某个时间以约定价格买入（Call）或卖出（Put）某资产的权利，但没有义务。

这一点很关键：期权的非线性特征意味着它天然适合做对冲。我只需要为这份”权利”付出权利金，而不需要准备大额的保证金。

具体到上证50期货期权：

• 每点100元的乘数（比期货少）
• 最近价格约3100点
• 一张能对冲约30万市值
• 权利金成本约4000~6000元
• 买方不需要保证金

看起来理想多了，但我咨询了券商的客户经理后，遇到了一个隐藏的门槛：账户需要至少50万的闲置资金才能开通。而我的60万基本都在另一个期权账户持仓里，根本没有这笔”闲置资金”来满足开户要求。

这个方案对于资产在几百万级别的投资者很适合，但对我的现状来说，又卡在了准入条件上。

参考：CFFEX 上证50股指期货期权

ETF期权（最终方案）

原理

上证50ETF是一只标准化的ETF基金，它跟踪上证50指数。与期货期权的区别在于——它不是虚拟的指数合约，而是真实存在的可交易股票。

正因为这个特性，上证50ETF期权的准入门槛低得多。

规格对比

每个合约对应100手ETF（即1万股），权利金成本相对较低。重要的是——券商对这个品种没有设置额外的”闲置资金”要求，我可以直接用交易账户操作。

这意味着我可以灵活调整对冲力度。比如，我可以买10~20张看跌期权，既能覆盖大部分的对冲需求（10张 × 3万 = 30万；我只需要覆盖60万），又不用过度对冲浪费成本。

权利金成本估算：假设每张500元，对冲10张所需成本仅为5000元，相当于我总持仓的0.8%。这个成本对于对冲假期风险来说，是可以接受的。

参考：SSE 上证50ETF期权合约

结论：这是我最终的选择。它很好地平衡了对冲效果和成本效率，而且准入条件完全符合我的现状。

期权合约具体选择

既然选定了ETF期权作为对冲工具，接下来就是如何选择合约。主要需要决策的细节有三个：

合约到期日的选择

以2026年春节为例：

• 2月13日是假期前最后一个交易日
• 2月24日（假期后）才开市
• 2月份期权合约会在2月25日到期

这里有个陷阱：如果选2月到期的合约，它会在假期结束后马上到期。这样一来，你从假期风险中”活下来”，但合约却立刻清算了，可能面临比较大的价差问题（bid-ask spread）。

更好的选择是3月到期的合约。它能覆盖真正的风险窗口（2月13日到2月24日），而且离到期日还有足够的时间，不用担心流动性变差的问题。

买哪个行权价？

有三种极端选择：

1. 平值（ATM）：贴近当前股价的行权价，保险最充分，但保费最贵
2. 深度虚值：远离当前股价很远，保费很便宜，但保险效果形同虚设
3. 虚值一档（理想中点）：成本和效果的平衡点

我倾向于选虚值一档。这样既不会因为追求”完美对冲”而过度投入，也不会因为贪便宜而买不到真正的保障。再次提醒，这不是赌方向的投机——这里的目的就是”花合理的钱，买充分的保险”。

为什么不通过卖Call来对冲？

有小伙伴也问过我：与其买Put，不如卖Call（看涨期权）来赚权利金，用这笔钱来”自我保险”？

这在数学上省钱，但引入了额外的风险：如果行情大涨，我的股票虽然赚钱了，但被套的Call会限制我的上涨空间。对冲的核心目的是风险中立，而不是用一个风险来抵消另一个风险。所以卖Call不是我的主要策略。

执行记录

回到2026年春节的实际操作。从2月9日（周一）开始，我开始用限价单逐日建仓。最终的持仓是：

• 卖出2张看涨期权（Call）：小额的反向操作，用来微调
• 买入6张看跌期权（Put）：核心对冲头寸

这个配置覆盖了18万左右的名义市值（6 × 3万），相当于对我18万持仓做了保险覆盖。我其实想买10张Put，但是最后两天的合约太贵了，限价单没有成交。

结果怎样呢？好消息是期权对冲本身已经赚钱了。坏消息是最后两个交易日大盘下跌明显，虽然对冲帮我减少了损失，但账户总体仍然缩水了。

这就是现实：对冲的意义不在于”消除亏损”，而在于**”可控损失的规模”**。另外, 因为我的对冲只是针对长期不开盘的假期风险，所以对冲的效果也只能覆盖这个特定的风险窗口。假期结束后，我就会给期权平仓，这样一来一回的成本非常的低。

小结

这个案例实际上反映了一个很务实的问题：如何在有限的资本和约束条件下，做出最优的风险管理决策。

回顾整个推理过程：

1. 定义问题：不是”如何完全消除风险”（不现实），而是”如何成本有效地对冲假期风险”
2. 评估工具：期货和两种期权都各有优势，但都有现实约束
3. 匹配方案：根据我的资金规模和账户条件，ETF期权是最合适的选择
4. 精细化执行：选择合理的合约规格、到期日和行权价

对于不同量级的投资者，最优选择是不同的：

没有”完美”的对冲，都是权衡。核心是理解每个工具的本质、约束和成本，然后做出符合自己现状的选择。如这篇文章开头所说，这不仅涉及期权知识，更涉及如何在约束条件下做决策——这是做投资或经营生意的永恒主题。

这套体系的核心不在于追求市场的暴利，而在于承认一个朴素的事实：**财富积累往往伴随着枯燥的重复劳动。** 我试图理清从“出卖劳动力”到“拥有资产”之间，究竟存在怎样的转化机制。当然整篇文章的观点也仅仅是我个人的理解和实践经验，不构成任何投资建议。

对现金流的抽象定义

在构建这个模型的时候，我发现单纯盯着”收益率”这个数字其实意义不大。更重要的是先搞清楚”钱从哪里来”。我把现金流大致分为四类：

1. 劳动（工资）：本质是出卖时间或技能。
2. 借贷（利息）：让渡资金的使用权。
3. 权益（分红）：作为资产所有者分享收益。
4. 保险（补偿）：这是模型中比较特殊的一环。

把自己当成”保险公司”

我把期权卖方（Selling Options）理解成一种”保险生意” 。当我卖出期权的时候，本质上是在承担市场波动的风险（让买方能睡个好觉），然后收取”权利金”作为保费 。

既然是生意，那就意味着它是一种劳动 ，而不是躺着就能赚钱的被动收入。我需要持续投入时间和精力来维护这门生意 。目标也很明确：不去赌方向，而是像经营保险公司那样，通过提供流动性或对冲服务，稳健地赚取 10%-15% 的年化权利金 。

关于“保险机制”的理解

保险的本质是用小保费对冲小概率大损失, 关键在于资本充足以承受极端赔付.在金融市场中, 我把卖期权视为一套“保险机制”: 作为卖方承担波动风险, 用权利金作为对价.前提是保证金/底仓能够覆盖最坏情况, 否则就是用未来透支现在.它不是被动投资, 而是一门需要持续维护的生意; 目标是获取相对稳健的现金流, 而非追求暴利.对多数人而言, 与重资产创业相比, 这门“小保险业务”更轻、更可执行.

核心比喻：大楼与脚手架

如果把财务自由比作盖一座大楼，这个模型的逻辑是这样的 ：

• 高分红股票（大楼本体）：这是最终目标。能提供真正的被动分红现金流，是将来可以”住”的地方。
• 期权交易（脚手架）：这是加速工具。做卖方生意赚取额外现金流，用这些钱买更多股票（砖头），从而更快地把楼盖起来。
• 打工收入（地基）：在楼盖起来之前，打工收入提供最基础的生存保障。

这个顺序很重要：如果没有资产积累（没打地基）就直接去卖期权（搭架子），或者只搭架子不盖楼（纯投机），那就不是在做生意，而是在赌博 。

一条可执行的路线图

根据资金规模，我给自己规划了一条相对清晰的路径 [2]：

第一阶段：生存期（10万以内）

• 核心任务：保住饭碗，稳定工作收入。
• 阶段特点：这是最基础的原始积累阶段。在还没有资产护城河的时候，工资是唯一靠得住的正向现金流。

第二阶段：建仓期（10万 - 50万）

• 核心任务：建立根据地，积累底仓。
• 具体操作：**”不管股价涨跌，持续买入积累股份”** 。
• 底层逻辑：这个阶段是为了让你整体有个初步的框架, 也是为了验证你的水平.

我们经常听说某个老板炒股亏了就是这种现象, 如果没法在股市里保住本金, 那么无论你在其他地方赚多少钱, 最终都会被市场收割掉.我建议一开始就要去尝试, 看看这条路是不是能走的下去. 通过长期的判断认清自己的水平, 以及对市场的理解.

第三阶段：期权业务期（50万 - 500万）

• 核心任务：搭建脚手架，加速复利。
• 具体操作：开始做期权卖方（Selling Options）。从市场这个”盆”里收权利金，然后把所有权利金再投入买股票。
• 心理预期：即使只有 6% 的额外收益也算是加速。这会是一个漫长的过程，可能需要持续很多年。

这个业务会让你在承担部分风险的情况下, 赚取相对稳健的现金流. 注意, 这里的核心是”稳健”, 而不是”暴利”.你需要接受这种”有限收益, 有限风险”的特性 。如果这个时候疯狂加杠杆, 可能爆一次仓就会导致自己亏损几个月积蓄。这里一定要清楚一件事, 你没有在躺赚, 你是在做生意, 你需要付出时间和精力去维护这个业务.

第四阶段：拆除脚手架（500万+）

• 核心任务：**”不想一直卖保险了”**。
• 终局状态：当资产规模达到一定程度，分红已经能覆盖日常开销的时候，就可以停止那些消耗精力的期权操作，拆掉脚手架，回归单纯的资产持有状态 。这才是真正的自由——从”必须操作”中解放出来 。

到这里后, 最好将这项业务关闭或是外包出去, 可以尽量自动化, 或者雇人进行期权操作, 不要再去自己做这个重复的过程了.这个时候你可以有选择去做你想做的事, 甚至有一些现金流可以开始赌一下某个项目了, 因为你已经有足够的资产保护你不会归零了.

重点: 这里的第二阶段和第三阶段是不可以颠倒的, 你必须先有足够的市场认知, 稳定的盈利手段, 才能去承担期权卖方的风险.

隐藏的门槛：其实是一本”修心手册”

这套策略看起来挺简单的，但真要执行起来很难，因为它会不断挑战人性中的贪婪和恐惧。

期权投资是一项保险生意

是生意就会有赚有赔, 请一定记住这一点. 就算你算的胜率是99%, 也不能保证你每次都能赚到钱.

接受”慢”的节奏

经常会有这样的疑问：”单纯囤股加卖期权是不是太慢了？”

我的想法是：与其追求暴利搞得寝食难安，不如用稳健的方式安心睡觉，把精力留给生活中更重要的事情 。

试图绕过积累阶段直接追求”快”，通常意味着要牺牲心态的平稳。如果为了多赚点权利金就把风险拉得很高，那这些工具反而会变成绞肉机 。

接受平庸与机械重复

这个模型本身就锁死了收益上限（期权卖方的封顶收益特性）。在牛市疯狂的时候，大概率会踏空，收益跑输那些赌单边的人。需要提前做好这种”相对剥夺感”的心理准备 。

另外，作为”保险业务员”，需要忍受长期的机械重复操作。能不能控制住自己，其实比懂不懂技术更关键 。

写在最后

这套”期权脚手架”模型，本质上是一套防御性的财务体系 。

如果控制不住恐惧和贪婪，比如喜欢追涨杀跌、盲目满仓，或者为了多赚权利金就不顾风险，那这些工具其实帮不了什么忙。这种情况下，老老实实打工攒钱反而是最明智的选择，至少工资这个正向现金流不会让人亏到归零 。

但对于那些能够控制住自己心性的人来说，这确实是一条通往”睡后收入”的相对稳健的路径。

脚手架终将拆除，唯有大楼屹立不倒。

以前我只是把这句话当成一种“心态建设”，认为这只是在强调风险控制。但在深入研究了对数正态分布（Log-normal Distribution）模型后，我发现这句话其实有着极其冷酷且严密的数学底色。

为了方便直观理解，我编写了一个交互式的可视化工具，建议配合本文阅读：👉 复利真相：对数正态分布实验室

1. 从正态分布说起

在进入复杂的金融模型前，我们需要先理解自然界的基石——正态分布。

高尔顿板：加法的视觉化

想象一块布满交错钉子的板子，小球从顶端落下，每次碰到钉子都会随机向左或向右弹跳。这个物理过程本质上是随机步骤的累加。当小球足够多时，底部的堆积形状必然会呈现出完美的“钟形曲线”。

中心极限定理 (CLT)

这就是数学上的中心极限定理：大量相互独立、分布随机的变量，只要它们是相加（Summation）的关系，最终的加和一定会趋向于正态分布。

在加法的世界里，涨跌是对称的。如果你有 100 元，今天加 10 元，明天减 10 元，你还是 100 元。

2. 投资收益的模型：乘法的陷阱

然而，投资世界遵循的不是加法，而是乘法。

累加 vs 累乘

你的财富增长不是 $P_0 + r_1 + r_2$，而是：$$P_t = P_0 \times (1 + r_1) \times (1 + r_2) \times \dots \times (1 + r_t)$$

这种累乘随机过程导致了一个致命的不对称性：如果你亏损了 50%，你需要盈利 100% 才能回到原点。

对数变换：桥接两个世界

为了使用强大的中心极限定理，数学家对价格取了对数（$\ln$）：$$\ln(P_t) = \ln(P_0) + \ln(1+r_1) + \ln(1+r_2) + \dots$$

现在，等式右边变成了对数收益率的累加。根据中心极限定理，$\ln(P_t)$ 服从正态分布。推导结论：如果资产价格的对数是正态分布，那么资产价格本身就服从“对数正态分布”。

3. 对数正态分布的图像特质

当我们观察对数正态分布的概率密度曲线时，会发现它与正态分布完全不同：

1. 不对称性（右偏）：它有一条向右延伸的长尾巴（理论上无限的上涨空间），但左侧死死地卡在 0（你最多亏光）。
2. 重心左移：这是本文最核心的观察点。

在对数正态分布中，有三个“中心”：

• **期望值 (Mean)**：数学上的平均收益。
• **中位数 (Median)**：50% 的人能达到的结局。
• **众数 (Mode)**：概率最高、最可能发生的结局。

4. 深度性质：为什么“别亏钱”是第一法则

通过观察模型参数 $\mu$（预期收益）和 $\sigma$（波动率）的互动，我们可以得出以下实战启示：

4.1 波动率陷阱：亏损是复利的杀手

对数正态分布下，复合年化收益率 $g$ 的近似公式为：$$g \approx \mu - \frac{\sigma^2}{2}$$

看到那个 $\frac{\sigma^2}{2}$ 了吗？波动率会直接从你的收益中“扣钱”。即使平均收益 $\mu$ 很高，只要波动率 $\sigma$ 足够大，你的真实增长 $g$ 可能是负数。这就是为什么“稳健”比“爆发”更重要的数学原因。

4.2 不要加杠杆：中位数的坍缩

加杠杆会线性增加 $\mu$，但会以平方速度增加 $\sigma^2$。反映在图像上，虽然平均值（Mean）被极少数暴富的幸存者拉向了右侧，但曲线的峰值（Mode）和中点（Median）会迅速向左侧（亏损区）坍缩。结论：杠杆越高，你变成那个“被平均”的炮灰概率就越大。

4.3 追高的幻觉：高波动的代价

热门股（高 $\mu$, 极高 $\sigma$）往往呈现出极度的左偏。虽然它“看起来”涨得快，但其众数（最可能发生的结局）往往远低于 1.0。你追逐的是那条稀疏的、极难捕捉的“长右尾”，而你面对的却是大概率的亏损峰值。

4.4 本金要足够

在乘法模型中，所有的收益都基于 $P_0$。由于波动拖累的存在，小额本金通过高风险波动翻倍的概率，远低于大额本金通过低波动增长的确定性。本金不仅是资本，更是抗风险的“冗余度”。

4.5 永远有概率赢：时间的解药

只要你的复合收益率 $g > 0$，随着时间 $t$ 的增加：

• 增长项按 $t$ 线性增长。
• 随机波动项按 $\sqrt{t}$ 缓慢增长。只要你不因大亏或杠杆被清出场，时间最终会稀释掉短期的随机性，让财富分布的山峰缓慢爬过“盈亏平衡点”。

5. 总结

我可能做了一些不严谨的假设才构建了这个模型，但它揭示了一个深刻的真相：投资不是一个比谁跑得快的游戏，而是一个比谁活得久的游戏。

“别亏钱”不是为了追求保守，而是为了保护那个脆弱的复利引擎不被 $\sigma^2$ 这个恶魔强行熄火。在这个不对称的概率世界里，平庸的赢 + 极少的输 = 伟大的复利。

如果你对这些参数如何影响分布感兴趣，欢迎去我的可视化工具亲手调一调参数，你会对“风险”产生全新的敬畏。

本文作为交易系统系列的第五篇，主要介绍近期在期权策略和系统功能上的优化和改进。在券商平台开通QMT权限后，我实现了使用Python进行期权交易的自动化操作。本文将详细介绍系统架构、功能实现以及策略改进的相关内容。

券商集成

在期权自动化交易方面，我的主要账户在国金, 正好满足了要求, 所以就用国金的QMT接口作为底层交易通道。之前使用MiniQMT进行股票交易，但期权交易需要完整版QMT权限。

集成过程中使用的核心函数包括：

1. get_trade_detail_data 用于获取账户资金信息、委托记录等：
2. get_comb_option 取期权组合持仓
3. make_option_combination 用于创建期权组合, 我主要用来做价差
4. release_option_combination 用于释放期权组合
5. passorder 所有的下单操作, 包括开仓, 平仓
6. get_full_tick 获取期权逐笔数据

关于API的详细使用方法，券商提供的技术文档已经有较为完整的说明，这里不再赘述。如需要技术咨询服务，可通过私信联系讨论具体需求和费用。

需要注意的是，QMT启动后会独占交易通道，佣金宝和国金的其他客户端无法同时进行交易。如需在移动端进行操作，可以使用国金提供的汇点期权App作为替代方案。

页面功能设计

为了更有效地管理期权持仓，我开发了一个专门的持仓管理页面。该页面不仅展示持仓信息，还集成了调仓功能，可以便捷地进行期权组合的构建和调整。

如前文《期权策略-变种比例价差》所述，我目前专注于科创50ETF期权的价差策略。单一标的的策略使得页面设计可以更加专注和高效。

持仓概览

上图展示了持仓页面的整体布局。图中标注部分显示了当前标的物及其实时价格，这是监控持仓状态的核心指标。

分月持仓管理

考虑到不同到期月份的期权合约具有不同的时间价值特性，系统按照到期日对持仓进行分类展示，便于分析和管理。

页面从左到右依次显示：牛市价差组合数量、备兑组合数量、义务仓数量以及权利仓数量。这种布局方式能够快速呈现整体仓位结构。

此外，系统对不同行权价的时间价值进行了颜色编码，通过视觉化的方式突出显示各合约的时间价值水平，提高了信息的可读性。

调仓操作界面

调仓页面提供了简洁的操作界面。用户可以直接修改目标持仓数量，系统会自动计算需要执行的交易操作。

页面集成了实时行情数据，能够实时显示当前的买卖报价。科创50ETF期权具有较好的流动性，买卖价差相对较小。当前版本实现了对手价下单功能，限价单功能计划在后续版本中添加。

页面底部以JSON格式展示完整的持仓信息，包括各合约的数量和价格，便于在下单前进行最终确认。

组合策略管理

期权组合是策略实施的核心部分。页面提供了组合调整界面，支持便捷地构建和修改各类价差组合。

策略优化与实现

《期权策略-变种比例价差》一文中详细阐述了策略的理论框架。在实际落地过程中，为了更好地实现程序化交易，对策略进行了一些适配性调整和优化。

策略参数优化

在仓位管理方面，将之前的零散操作调整为标准化配置：在每个价位段，统一采用10张权利仓+12-15张义务仓的标准比例来构建组合，同时配合少量平值期权义务仓的裸卖操作。

这种标准化配置的优势在于：仓位控制更加精确，避免了为凑整数而产生的困扰，使得整体仓位管理更加规范和可控。

风控机制设计

衍生品交易中，风险控制是系统稳定运行的基础。系统实现了完整的风控和调仓逻辑。从我的角度来看, 风控长什么样不重要, 重要的是一定要有一个.它能够提醒你当前的风险暴露情况, 并且在必要时刻给出调仓建议. 我就想了一套最简单的让AI来生成.

围绕获取时间价值这一核心目标，针对义务仓设计了三层风控机制：

1. 高风险调仓机制：当持仓的风险评分超过预设阈值时，系统会自动识别并建议更保守的调仓方案，降低持仓风险暴露
2. 虚值平行移仓机制：当虚值合约时间价值快速衰减，且下月合约的时间价值达到当月的2倍以上时，系统会建议平行移仓，在获取更高时间价值的同时，可以适当降低持仓数量
3. 低价值清仓机制：对于时间价值低于50元的期权合约，系统会建议平仓，以提高保证金使用效率

系统还实现了风险评分机制记录，根据持仓情况和标的价格实时计算风险分数，并以图表形式记录风险变化趋势。

通过这套风控体系，能够及时识别和控制潜在风险。

总结与展望

本文介绍了期权自动化交易系统的主要功能模块和策略实现。从券商接口集成、页面功能设计，到策略优化和风控机制，系统已经具备了基本的自动化交易能力。

当前系统仍有较大的改进空间。限价单功能、更多样化的策略组合、更精细的风控算法等功能都在规划之中。系统的持续优化和完善将是后续工作的重点。

欢迎对期权交易自动化感兴趣的读者交流讨论。

这篇文章想和大家分享我一直在使用的期权策略，以及我对风险控制的一些体会。
这套策略是我在开始期权交易后不久就建立的，至今仍在使用。期间经过多次调整与优化，但核心逻辑始终未变。

👉 本文面向已经具备一定期权基础的投资者。
如果你刚入门，建议先了解期权的基本概念和原理。本文不会涉及复杂的希腊字母计算，也不探讨定价模型，更多是关于策略思路与风险控制的实践。（我自己也不太会算那些 😂）

⚠️ 风险提示：没有任何策略是永远有效的。市场在变，波动在变，人也会变。
以下内容仅为个人经验分享，不构成任何投资建议。

🧩 普通比例价差（Ratio Spread）

Ratio Spread（比率价差） 是一种常见的期权组合策略。
它的核心思想是通过 买入与卖出不同比例的期权，利用波动性与时间价值的差异，在风险可控的情况下获取收益。

以看涨期权为例 👇

1. 买入 较低执行价的看涨期权（Long Call）——获得上涨收益机会；
2. 卖出 较高执行价的看涨期权（Short Call）——收取权利金抵消部分成本。

举个最简单的例子：
买入 1 张执行价为 10 元的 Call，同时卖出 2 张执行价为 12 元的 Call。
你支付买入的权利金，同时获得卖出的权利金，形成一个「比例结构」。

🔗 延伸阅读

• moomoo 教程
• 雪球讨论

策略的到期盈亏图如下：

我个人并不太喜欢这种「山峰型」的损益曲线。
它虽然直观，却让人感到不够平衡与优雅。于是，我尝试使用下面我更偏好的变种。

🚀 我的变种策略

🎬 策略灵感

我最早在 PowerUpGammas 的视频 中看到这种思路。
视频讨论的是「如何用期权修复股票浮亏」，但我认为它不仅适用于亏损修复，也可在 趋势行情中放大收益。

后来, 他讲了另一篇 超级备兑期权, 就是本篇文章所讲的内容.

🧱 策略结构

1. 持有一份标的资产（用于备兑）；
2. 买入 1 张较低执行价的看涨期权；
3. 卖出 2 张较高执行价的看涨期权。

与普通比率价差相比，这里额外加入了标的资产本身，起到了风险缓冲的作用。

换个角度理解：

• 「买低 + 卖高」 = 牛市价差（Bull Call Spread）
• 「持股 + 卖高」 = 备兑看涨（Covered Call）

两者结合，就构成了这种混合型结构。

📈 到期盈亏图与分析

我用 OptionStrat 画了一张 SPY 的示意图：
👉 策略图链接

图中可以分为三个区间：

1. 左侧红区：股价低于 680，全体期权作废，盈亏与正股一致。
2. 中间绿区（680–700）：收益由股票上涨 + 看涨期权增值组成。
3. 右侧平顶区（>700）：卖出两张 Call 的收益抵消上涨空间，收益封顶。

💬 关键：
两张高行权价的 Call 收入必须能覆盖低行权价 Call 的成本，否则策略将需要额外资金投入（风险上升）。

我很喜欢这条盈亏曲线，它平滑、线性、干净。
数学上，它是一个分段线性函数；逻辑上，它在中段实现了无成本的杠杆提升。

✨ 优点总结：

• 风险可控，结构清晰
• 在区间内实现 2 倍收益
• 无额外资金占用

🧭 策略的进一步变种

既然原理是「用比率调整收益区间」，那我们就可以玩出更多组合。

🎯 变种 1：调整区间宽度

调整买卖期权的执行价，可改变收益区间。
例如：

• 买入 1 张 680 Call
• 卖出 2 张 710 Call

区间拉宽 → 收益范围更大，但权利金差距也变大，需要重新平衡成本。

⚙️ 变种 2：调整比例

可以买入 2 张、卖出 3 张，从而实现更高杠杆（例如 3 倍收益）。
只要卖出的权利金能覆盖买入成本，该结构依然成立。

🔄 变种 3：反向思维（看跌版）

同理，也可构建看跌版策略：
买入 1 张高行权价 Put，卖出 2 张低行权价 Put，同时准备现金用于”备兑”。

🔄 变种整合

如果我们将这几个变种策略结合起来, 那么最后的盈亏图可能长成这样, 在不同的区间内, 我们可以获得不同倍数的收益. 也可以理解为加了不同倍数的杠杆.

https://optionstrat.com/NpbByzGw1vll

我没有画看跌的比率价差, 因为这个工具并没有给我用现金做备兑的选项, 但其实它和看涨的比率价差类似, 只是方向相反.

⚖️ 风险与取舍

这种结构的优点在于：看错不亏，看对大赚。
但仍需注意以下风险 👇

1. 标的下跌风险：若价格跌破低行权价，亏损与持股一致。
2. 机会成本：资金被标的锁定，横盘时收益有限。
3. 踏空风险：若标的暴涨，收益被封顶，需提前规划。

🧮 市场分析与量化探索

既然结构清晰，我自然想看看，我平时交易的科创50ETF期权，能实现多大杠杆。

我写了一个小程序，基于科创50ETF期权数据，计算每个合约能实现的最大杠杆倍数（无额外投入）。

例如：

• 26年3月的科创50ETF期权合约中：

  1.55 Call 价格为 1213

  1.6 Call 价格为 1063

→ 理论上可开到 8 倍杠杆（卖8张，买7张）

1

8 * 1063 - 7 * 1213 = +13  # （未计手续费）

我自己编写了一个定时任务自动计算每个区间段内可以实现的杠杆倍数并打点, 下面是两张不同月份合约的杠杆计算结果图, 横轴为不同时间点, 纵轴为杠杆倍数。

📉 近月合约（2–3倍杠杆）：

📈 远月合约（6–8倍杠杆）：

读者可以自己算一下：杠杆倍数与价差成反比，与合约价格成正比。两张期权价差越小、价格越高，可开的杠杆就越大。

📊 我的持仓追踪与管理

我使用 Google 表格来管理持仓与杠杆情况👇

并标记了每个区间段、每个月份的杠杆倍数：

这些数据帮助我动态调整仓位，优化结构。

📍 开仓容易，管理更关键。很多期权合约不一定要持有到期的, 中途怎么调整, 可能是更重要的.

我做了几个月期权的一点思考就是: 只要你能在市场中活着, 你就有机会赚钱. 这个策略能让你在市场中活很久. 哪天失业了, 可以用这个策略给市场打工, 赚点小钱.

🧩 总结

这套比率价差变种，是我实战中最核心、最常用的策略之一。
它特别适合趋势明确的单边行情，或是大幅的震荡行情。

对于更大体量的投资者，这种结构更像是 微型做市（Market Making）：
提供市场流动性、赚取结构性溢价。
当然，这需要更成熟的风险矩阵与资金分层体系。

🤔 为什么我不担心策略公开会失效？

1. 市场需要流动性：更多人使用 → 价格更高效。
2. 机构更复杂：他们的模型理论上更加负责 我根本不需要担心他们。
3. 收益有限：Capped profit 不吸引极端投机者。

我虽然已经使用Bolt开发了期权相关的页面, 但是在实际交易中, 还是习惯使用Google表格来整理期权数据, 主要有以下几个原因:

1. 目前还没有把后端系统接入到QMT, 只能手动导入数据, 所以并没有什么自动化的优势.
2. 目前我做期权, 依然还是处于比较新手的阶段, 还在探索比较合适的工具, 这个时候去研究展示页面我认为收益不高
3. Google表格的界面非常友好, 可以很方便地进行数据的查看和编辑, 而且我能慢慢整理出自己想要的究竟是什么
4. 我也使用了一下飞书的文档, 它的自定义函数支持我是没看懂, 考虑到实用性和扩展性, 还是选了Google表格

我的Google表格的地址如下, 如果想修改, 读者可以直接复制一份到自己的Google账号下进行修改

https://docs.google.com/spreadsheets/d/1IiRv47a8lwmZt84KsiZnTKOTp4HDsqJUgsyUxbWHGlU/edit?gid=1506563050#gid=1506563050

期权持仓的获取

我用的是国金的金太阳来看我的持仓, 它是通达信的一个定制版本, 也提供了数据导出的功能

我就用它的导出功能, 导出成Excel, 然后再复制到Google表格中

持仓收益整理

我希望尽量记录自己的仓位变化情况, 正好也用Google表格以及图表进行记录和查看

Google表格的整理(内置函数)

这张图中. 有几个部分我用了Google表格的内置函数来实现

根据到期日进行过滤

比如, 整个tab中, 我首先进行过滤, Q2这个单元格对应的到期日, 这里是20251022, 而后基于合约名称进行排序

1

=sort(filter('持仓'!A2:N, '持仓'!N2:N = Q2), 2, true)

获取未平仓的CALL

而后, 我用这个公式来获取未平仓的CALL, 如下, 它的规则是:

1. 当我发现期权名称中包含购字 – 为看涨期权
2. 可用量大于0 – 说明还有未平仓的
3. 开仓价格为负数 – 说明当时是在卖出
4. 并且不是备兑的时候 – 非备兑

1

=FILTER(B2:O20, regexmatch(C2:C20,".*购.*"), F2:F20>0, G2:G20<0, NOT(D2:D20="备兑"))

未平仓的PUT也是类似的, 读者可以自己去表格中查看公式

调用自定义的函数

针对这些可能有行权风险的义务仓, 我还编写了一些自定义的函数, 来帮助我进行一些计算. 比如, 当前标的价格, 计算合约是实值还是虚值

函数代码编写

可以从这个位置打开来查看脚本

里面的代码我是求助Gemini来做的, 它比自己写快太多了, 还有注释, 好评!

表格中调用函数

我可以直接调用写好的函数来计算得到所有期权的状态, 方便我评估风险, 哪些属于实值的义务仓需要在到期前尽快平掉或是移仓

1

=ANALYZE_OPTION_STATUS(C:C, R2*1000)

总结

我说真的, 不管是用自己的程序还是用Google表格整理都不是特别方便. 但是我用了券商的软件包括通达信还是汇点, 他们的对于已持有的期权仓位的分析都非常有限,只能看到一些基本的信息. 甚至连按照月份来分类都没有, 只能看到一个大概的持仓. 当我做的期权越来越多的时候, 这些信息就显得非常不够用了.

如果是机构交易者应该也是要有自己的系统来管理这些数据的, 但是对于个人投资者来说, 我目前还没找到一个特别好的工具. 如果有推荐的期权工具也欢迎大家留言告诉我.

这篇文章是我的半自动化股票交易系统系列的第四篇，主要聚焦于期权相关的功能和策略改动。近期我的主要精力都放在期权自动化和策略优化上。本文不会详细介绍期权基础知识，更适合已有一定期权基础的读者。如果你对期权还不熟悉，建议先查阅相关入门资料，后续我也会专门写一篇期权基础与策略的介绍。

国内期权市场现状

很多朋友听到“期权”时，往往不相信国内也有类似的杠杆工具。实际上，国内不仅有商品期权，还有较为成熟的金融期权市场，尤其是股指期权。具体规则可以参考中信证券官网的交易规则。

我个人主要关注的是华夏科创50ETF（588000.SH）的期权。选择这个标的的原因很简单：价格计算方便，每张合约大约1万元，且科创板股票波动率较高，非常适合期权策略的实践。

目前国内主流的期权交易软件如汇点、通达信等，对自定义指标和策略的支持有限。如果想实现自动化交易，基本只能靠自己开发程序。与券商沟通后了解到，若想开通API权限，通常需要满足100万元资金量和500张期权交易的门槛，我还在为这个目标努力中。

T型报价与数据获取

T型报价表是期权交易的基础工具，也是我自动化程序的第一步。只有能实时获取期权报价和持仓数据，后续的分析和策略执行才有可能实现。

许多期权策略的分析和决策，都是基于当前的T型报价实时计算得出的。

持仓数据解析

由于目前还没有开放的API接口，我的期权持仓数据主要通过券商导出的持仓文件（CSV格式）获取。程序会自动解析这些文件，生成标准化的持仓数据，便于后续分析和策略管理。

在系统中，我可以根据实际持仓情况，自定义和选择对应的策略组合。

期权策略的维护与管理

基于当前持有的期权合约，我可以自定义常见的策略组合，比如牛市价差、熊市价差等基础策略，也可以灵活组合更复杂的策略。由于缺乏API，目前策略的维护主要依赖手动操作。好在我的资金规模尚未大到需要频繁调整仓位，现阶段这种方式尚可接受。

报价监听与策略通知

在维护好策略后，系统会根据当前持仓和策略，自动监听合约报价的变化，判断是否需要进行买卖操作。需要说明的是，目前实际下单仍需手动在券商软件中完成，系统会通过 Telegram 发送通知，提醒我及时操作。

对于十几万元规模的账户来说，这种半自动化已经极大减轻了盯盘和计算压力。只需等待程序通知，无需频繁关注行情和手动计算盈亏。

总结与展望

期权交易与股票有很大不同，需要学习和掌握的内容也更多。当前我主要利用期权获取稳定现金流，并对冲部分股票仓位的风险。期权策略丰富多样，自动化程度越高，效率和收益也会越好。受限于API门槛，目前我的系统还无法实现完全自动化，只能做价格提醒和部分策略维护。希望未来能达到券商API的要求，实现真正的自动化期权交易。

如果你对期权自动化、策略开发等话题感兴趣，欢迎留言交流！

整个过程其实很顺利，这里记录一下操作流程，方便大家参考。

为什么要做这件事

虽然我用 ArgoCD 自动发布服务，但密码等敏感信息都直接写在 Git 仓库里。这样做不仅不安全，而且维护起来很麻烦。

我希望能有一个自动同步 Secrets 的控制器，把密码从 Bitwarden 自动同步到 K8s 集群，提高安全性和管理效率。正好在 ArgoCD 文档 里看到官方推荐用独立的 Secrets 管理系统，比如 external-secrets。

架构设计

方案很简单：在集群里部署 Bitwarden 的转发服务和 external-secrets 控制器，Secrets 会自动创建到对应的 namespace。

详细流程可以参考：argocd bitwarden

实现步骤

我是用 ArgoCD 做 IaC 管理的，下面用 Application 的方式举例说明。

安装 external-secrets

用 Helm 安装 external-secrets，并开启 ClusterSecretStore 的 CRD 支持。

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

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: external-secrets
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://external-secrets.github.io/external-secrets/'
    chart: external-secrets
    targetRevision: 0.19.2
    helm:
      parameters:
        - name: bitwarden-sdk-server.enabled
          value: "false"
        - name: "crds.createClusterSecretStore"
          value: "true"
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: external-secrets
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

部署 Bitwarden 服务

部署 Bitwarden CLI 服务，确保能正常获取密码。可以在容器里执行 bw list items 验证。

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

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: bitwarden-cli
  namespace: external-secrets
type: Opaque
data:
  BW_HOST: $(echo -n "https://xxxxx" | base64 | tr -d '\n')
  BW_USERNAME: $(echo -n "" | base64 | tr -d '\n')
  BW_PASSWORD: $(echo -n "" | base64 | tr -d '\n')
EOF

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

# 参考文档：
# https://bitwarden.corvo.fun/#/vault?organizationId=unassigned&search=ext&itemId=502e2c9a-fefc-4d6d-93a9-0f66d7d4191a
# https://external-secrets.io/latest/examples/bitwarden/#deploy-bitwarden-credentials

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bitwarden-cli
spec:
  template:
    spec:
      containers:
        - name: bitwarden-cli
          image: ghcr.io/charlesthomas/bitwarden-cli:2025.6.1
      # ...
---
apiVersion: v1
kind: Service
metadata:
  name: bitwarden-cli
spec:
  # ...
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: external-secret-2-bw-cli
spec:
  # ...

配置 external-secrets 的密码获取方式

告诉 external-secrets 如何从 Bitwarden 获取密码。

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
38
39
40
41
42
43
44
45

---
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: bitwarden-login
spec:
  provider:
    webhook:
      url: "http://bitwarden-cli:8087/object/item/{{ .remoteRef.key }}"
      headers:
        Content-Type: application/json
      result:
        jsonPath: "$.data.login.{{ .remoteRef.property }}"
---
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: bitwarden-fields
spec:
  provider:
    webhook:
      url: "http://bitwarden-cli:8087/object/item/{{ .remoteRef.key }}"
      result:
        jsonPath: "$.data.fields[?@.name==\"{{ .remoteRef.property }}\"].value"
---
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: bitwarden-notes
spec:
  provider:
    webhook:
      url: "http://bitwarden-cli:8087/object/item/{{ .remoteRef.key }}"
      result:
        jsonPath: "$.data.notes"
---
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: bitwarden-attachments
spec:
  provider:
    webhook:
      url: "http://bitwarden-cli:8087/object/attachment/{{ .remoteRef.property }}?itemid={{ .remoteRef.key }}"
      result: {}

自动同步密码到集群

假如你已经在 Bitwarden 里保存了密码，只需创建 ExternalSecret，控制器会自动同步到 K8s 集群。

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

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: xx
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: bitwarden-secretsmanager
    kind: SecretStore
  data:
  - secretKey: AAA
    sourceRef:
      storeRef:
        name: bitwarden-notes
        kind: ClusterSecretStore
    remoteRef:
      key: AAA

最终会自动生成 K8s Secret，数据已经同步到集群，可以直接挂载和使用。

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

apiVersion: v1
type: Opaque
kind: Secret
metadata:
  name: xx
  namespace: default
  ownerReferences:
  - apiVersion: external-secrets.io/v1
    kind: ExternalSecret
    name: xx
data:
  AAA: QkJCQ0NDRERE

总结与建议

以前用 AWS SSM 管理密码，但因为成本没用起来。现在用 Bitwarden 管理 K8s 密码，既安全又方便。如果线上环境对安全性要求高，建议还是用专业的密码管理工具。

几点补充说明：

1. Bitwarden 是我自建的密码管理工具，已经做了自动备份和容灾，所以用它管理集群密码比较放心。
2. Bitwarden 支持权限控制。如果用它管理 K8s 密钥，建议单独建一个 organization 存储，并用专门的用户读取。这样即使集群被攻破，也能保证其他密码安全。

在 Telegram 中直接执行买卖操作

以往的半自动化模式是：程序检测到股票价格变化后，自动发送通知到 Telegram，我再根据提醒去券商软件下单。

最近我对这一流程进行了优化，现在可以直接在 Telegram 的通知消息上通过打标签来实现买卖操作，大大提升了效率和便捷性。

实现原理

核心逻辑如下：后端会检查消息的发送者是否为管理员，并判断标签（icon）是否符合要求，只有都满足条件才会继续执行买卖操作。下面是部分实现代码：

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

async def conv_command(update: Update, context: ContextTypes.DEFAULT_TYPE) -> None:
    app_logger.info(f"Update: {update}, Context: {context.__dict__}")

    if str(update.message_reaction.user.id) not in admin_user_ids:
        app_logger.warning(f"User {update.message_reaction.user.id} is not an admin")
        return

    act = update.message_reaction.new_reaction
    if not act or not act[0]:
        app_logger.warning("No reaction found in the update.")
        return

    emoji_data = act[0].to_dict()
    if emoji_data['emoji'] != '👏':
        app_logger.warning(f"Reaction {act} is not supported")
        return
    # ... buy or sell logic

if __name__ == "__main__":
    application = Application.builder().token(token).build()
    application.add_handler(MessageReactionHandler(conv_command))

通过这种方式，用户只需在 Telegram 消息上添加指定标签（如“👏”），系统就会自动完成买卖操作，无需手动切换到券商软件。

利用 LLM 工具分析持仓与仓位调整

我参考了 TauricResearch/TradingAgents 项目。虽然它主要支持 OpenAI 并且是终端交互，但我借鉴了其中的 prompt 设计，并在自己的系统中集成了 LLM 分析工具。现在，自动化代码生成和模型调用都非常高效，能够快速完成分析任务。

TradingAgents 的功能亮点

TradingAgents 利用 OpenAI 的函数调用能力（Function Calling），可以自动获取股票行情、检查新闻，并通过多轮交互生成分析报告。整个过程类似如下：

这种方式让模型能够主动调用后端函数，自动完成数据抓取和分析，极大提升了智能化水平。

我的实际应用

我没有 OpenAI 的 API，但之前充值了 DeepSeek 的，所以直接用它来做持仓分析。目前项目中的 LLM 交互流程比较简洁：系统会整理最近的持仓数据，上传给 DeepSeek 进行分析，模型会给出仓位变动建议和操作意见。

目前我每周查看一次模型生成的报告，已经能够满足日常的持仓管理和策略调整需求。

前端代码完全使用bolt来生成的, 因此我开源了一份放在GitHub corvofeng/trader-frontend-mirror,会不定期同步最新代码过去. 纯前端页面部署了一份在Cloudflare上, 可以直接预览这里:

https://trader-front-mirror.corvofeng.workers.dev/

新增的几个功能

展示自动操作记录

这个功能主要是确认我的程序是不是在正常运行, 所以我在关键位置打点了, 偶尔翻下记录就能知道有没有正常在跑.AI生成代码真的好用, 这个功能我自己写肯定要花不少时间.

Treemap展示股票持仓

Treemap 这里是用的 echarts 的组件.

https://echarts.apache.org/examples/en/index.html#chart-type-treemap

说真的, 这个组件我用了很多的 token, 每次不满意就要重新生成一整个组件代码, 而且需要不少手动微调.

目前可以根据资金量展示不同大小的卡片, 当日的盈亏情况展示不同颜色.

点开分组之后可以查看每个股票的持仓情况.

上传券商导出的持仓文件

因为我有一些券商没有开通QMT, 只能导出xls文件来查看仓位, 我想顺便集成到这个系统中,就增加了这个功能.

在用户上传持仓文件之后, 后台程序会解析持仓并返回预览, 而且会提供一个uuid来提供查看和分享

一些功能展望

以下功能是我准备逐步增加的:

• 多种券商持仓文件的支持

我自己只测试了两种券商, 中金财富和国泰君安, 如果用户有其他券商的持仓文件需要导入, 可能会考虑支持.

• 期权价格的监听

期权和保险的功能类似, 可以令你拥有稳定现金流的工具.我近期的很多时间也放在了期权交易上, 所以可能会在这方面投入一些时间

• AI分析持仓

用户在上传持仓文件后, 可以丢给AI, 针对持仓风格给出一些建议

我个人从去年开始就逐步买入日经相关的场外基金, 也同时在场内有看 日经ETF(SH:513520) 这只ETF基金:在当时我使用 Backtrader 做回测时, 这只基金是我回测最多的, 所以我也针对它做了一些技术面的统计.

其分析结果仅仅是一种技术面的观察, 不能预测未来趋势, 也不保证买了就可以赚钱,如果你认为只是技术面分析就能稳赚不赔, 我可能会认为你并不适合炒股, 也不适合做我的读者.

如果想要查看部分代码, 以及更加优雅的图形交互, 请打开 Google Colab地址.

亏损盈利分布

当日相比前一日的盈亏情况

计算基于盘中价格相对于前一日最高价和最低价的不同盈亏情景概率。比如横座标

• 0.05表明, 今日的最低价相比昨日的收盘价下跌超过5%
• -0.05表明, 今日的最高价相比昨日的收盘价上涨超过5%

我本来是想使用正态分布做拟合的, 但是当我把数据贴给ChatGPT的时候, 它帮我做了几种不同分布的拟合分析,发现下面这个分布更加适合 Lorentzian 分布

连续的盈利或亏损

横座标表示连续几天, 5表示连续五天盈利, -5表示连续5天亏损这张图的统计结果表明, 连续3天以上都盈利或是亏损的概率只有不到10%, 连续5天以上的盈利亏损概率仅1%

收益预期管理

股票降价后的收益率

这里计算得到的图表内容解释

• Expected Return 的数字表示预期盈利是 4%
• 以横座标为3为例, 它意味着当日的股票比前一天最高价低了3%以上
• 纵座标表示的是达到预期收益的, 如果以 14 天这条线为例, 它表示, 在未来14个交易日中, 能达到4%收益的概率接近60%

如果使用更加简单的例子

• 第0天, high: 1.0(最高价)
• 第1天: low: 0.97 (存在一个价格比前一天低了3%)
• 第2天: ….
• 第3天: ….
• 第14天: 存在一个价格大于 0.97 * 1.04 的概率接近是60%

可以看到, 随着我们的耐心等待, 从7天,14天,到21天,30天之后, 获利概率其实是逐步提升的.

降价后的收益率-3D

我尝试使用plotly也制作了 3D 的曲面, 可能没那么光滑, 不过只是查询看起来足够了.

平均套牢天数

我这里的评价套牢天数的定义是, 当你用某个价位买入时, 比如1元, 你想要以1.025d的价格卖出, 需要的时间分布.从图中的数据来看, 在1.41到1.48这段买入后, 平均时间是最短的, 大概是21个交易日内就可以获得2.5%的收益

数据的分析与讨论

以下的观点仅代表个人, 且只针对日经ETF, 我不对任何读者的选择负责. 赚钱赔钱与我无关.

符合直觉的结论

• 连续上涨, 连续下跌的概率会随着天数增加而快速减少
• 同一支股票的涨跌情况基本符合正态分布, 不过这里我拟合得到的是柯西分布(洛伦兹分布)
• 以一个合适的价位买入, 基本不太会被套, 但也不会赚大钱

可能的策略

假设每年的交易日大概240天

• 根据盈亏的分布

当日跌幅超4%时, 可以考虑买入并持有15-30个交易日, 在一年中买入的时机大概为 240天*2% 约为5个交易日

因为每次交易有7成以上的概率获得4%的收益, 所以一年的预期收益大概为 4% * 0.7 * 5 大约为 14%

• 根据平均套牢时间

日经的数据中, 从1.41到1.48这段的平均回本时间是最短的, 大概是21个交易日内就可以获得2.5%的收益. 平均的交易周期为21天.

假设你每次都能在1.41到1.48之间买到股票, 那么你每年能交易的次数为 240/21 = 10 次, 那么年化有可能达到 10 * 2.5% = 25% 的收益

命令行登录

SSH服务

确保系统中的SSH服务打开了:

1
2
3
4
5

➜  ~ ssh corvo@192.168.xxx.yyy
corvo@192.168.xxx.yyy's password:
Linux HomeFN 6.12.18-trim #5 SMP PREEMPT_DYNAMIC Thu Mar 27 10:30:00 CST 2025 x86_64
Last login: Sun May 18 11:06:10 2025 from 192.168.101.221
corvo@HomeFN:~$

在第一次登录之后, 我发现每次输入密码麻烦就加了公钥到机器上, 可以自行添加这个目录以及文件

1
2

corvo@HomeFN:~$ ls ~/.ssh/authorized_keys
/home/corvo/.ssh/authorized_keys

切换root用户

也可以切换到root用户, 正常输入密码就可以了

1
2
3

corvo@HomeFN:~$ sudo su - root
[sudo] password for corvo:
root@HomeFN:~#  # 已经切换到了root用户

系统组件

操作系统

这是一个Debian 12的系统, 我个人很喜欢他们的这个选择, 和我的其他NAS系统都能保持一致了.

1
2
3
4
5
6
7
8
9
10

corvo@HomeFN:~$ cat /etc/*-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

系统进程

查看系统进程我推荐systemctl:

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

root@HomeFN:/usr/trim/etc# systemctl status
● HomeFN
    State: degraded
    Units: 441 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 3 units
    Since: Mon 2025-05-12 21:02:26 CST; 5 days ago
  systemd: 252.30-1~deb12u2
   CGroup: /
           ├─init.scope
           │ └─1 /sbin/init
           ├─system.slice
           │ ├─ModemManager.service
           │ │ └─843 /usr/sbin/ModemManager
           │ ├─NetworkManager.service
           │ │ └─816 /usr/sbin/NetworkManager --no-daemon
           │ ├─accountsrv.service
           │ │ └─2409 /usr/trim/bin/accountsrv

磁盘挂载

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

corvo@HomeFN:~$ df -Th
Filesystem                                              Type         Size  Used Avail Use% Mounted on
udev                                                    devtmpfs     3.9G     0  3.9G   0% /dev
tmpfs                                                   tmpfs        796M   22M  775M   3% /run
/dev/sda2                                               ext4          63G  5.6G   54G  10% /
tmpfs                                                   tmpfs        3.9G  1.4M  3.9G   1% /dev/shm
tmpfs                                                   tmpfs        5.0M     0  5.0M   0% /run/lock
trimafs                                                 trimafs       52G  1.7G   50G   4% /fs
1000-1-c86c2633{SYtpW}:cloud-storage/v1/dav             fuse.rclone  1.0P     0  1.0P   0% /vol02/1000-1-c86c2633
//192.168.xxx.yyy/Data                                  cifs         1.6G  6.0M  1.6G   1% /vol02/1000-0-cb29116f
1000-1-4a74aa03{2_a9I}:cloud-storage/v1/dav             fuse.rclone  1.0P     0  1.0P   0% /vol02/1000-1-4a74aa03
tmpfs                                                   tmpfs        796M     0  796M   0% /run/user/1000
/dev/mapper/trim_fc35013f_f739_4592_942f_d054200d2a3a-0 btrfs        6.0G  5.9M  5.5G   1% /vol2
/dev/mapper/trim_5ab5694e_275a_417b_8f53_88510b630e5f-0 btrfs         52G  1.7G   50G   4% /vol1

其中, 这两个fuse.rclone的磁盘是百度云盘和阿里云盘, cifs挂载的目录是我自己的smb服务器,另外两个btrfs系统是我自己挂载的虚拟硬盘.

再看一下

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

root@HomeFN:/usr/trim/nginx# ps -aux | grep rclone
root        2944  0.0  0.3 730112 30572 ?        Sl   May12   3:41 /usr/bin/rclone --config /etc/mountmgr/rclone/1000.conf mount --daemon 1000-1-c86c2633:/cloud-storage/v1/dav /vol02/1000-1-c86c2633 --no-check-certificate --allow-other --uid 1000 --gid 1001 --umask 000 --default-permissions --dir-cache-time 10s --webdav-vendor baidu --vfs-cache-mode off --timeout 600s --contimeout 200s --daemon-timeout 3000s --daemon-wait 30s --poll-interval 10s --low-level-retries 2
root       93267  0.0  0.2 729344 23932 ?        Sl   May17   0:01 /usr/bin/rclone --config /etc/mountmgr/rclone/1000.conf mount --daemon 1000-1-4a74aa03:/cloud-storage/v1/dav /vol02/1000-1-4a74aa03 --no-check-certificate --allow-other --uid 1000 --gid 1001 --umask 000 --default-permissions --dir-cache-time 10s --webdav-vendor ali --vfs-cache-mode off --timeout 600s --contimeout 200s --daemon-timeout 3000s --daemon-wait 30s --poll-interval 10s --low-level-retries 2

# 再看看其中的rclone配置
root@HomeFN:/usr/trim/nginx# cat /etc/mountmgr/rclone/1000.conf
[1000-1-c86c2633]
type = webdav
user = 1000_qxSsjpVcKsVORqoA
pass = xxxxxxxxxxx
url = http://127.0.0.1:15244

[1000-1-4a74aa03]
type = webdav
url = http://127.0.0.1:15244
user = 1000_0XKC8OEuwEaVrUvn
pass = xxxxxxxxxxx

# 这里的15244是由 `cloud_storage_dav` 监听的, 提供了webdav接口之后, 由rclone挂载成为本地目录,
# 非常符合Linux的使用逻辑.

用户组

每个应用会有一个属于自己的用户, 看起来也是有权限控制的

1
2
3
4
5
6
7

root@HomeFN:/usr/trim/etc# cat /etc/passwd
# ...
trim-media:x:999:901::/home/trim-media:/usr/sbin/nologin
trim.photos:x:996:901::/home/trim.photos:/usr/sbin/nologin
baidu.netdisk:x:994:901::/home/baidu.netdisk:/usr/sbin/nologin
git:x:993:901::/home/git:/usr/sbin/nologin
trim.text-editor:x:992:901::/home/trim.text-editor:/usr/sbin/nologin

数据库

飞牛使用的是PostgreSQL做数据库的, 有兴趣可以自己研究下里面的数据库和表格, 看起来飞牛对AI相关的内容还是蛮重视的, 单独有一个AI相关的数据库.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

root@HomeFN:~# ps -aux | grep postgres
postgres    1399  0.0  1.0 239912 86084 ?        Ss   May12   0:58 /usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/15/main -c config_file=/etc/postgresql/15/main/postgresql.conf

root@HomeFN:/usr/trim/etc# su - postgres
postgres@HomeFN:~$ psql
psql (15.8 (Debian 15.8-0+deb12u1))
Type "help" for help.

postgres=# \list
                                                       List of databases
      Name      |     Owner      | Encoding |   Collate   |    Ctype    | ICU Locale | Locale Provider |   Access privileges
----------------+----------------+----------+-------------+-------------+------------+-----------------+-----------------------
 ai_manager     | postgres       | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
 appcenter      | postgres       | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
 dm             | postgres       | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
 #....

Docker

飞牛NAS里面也提供了Docker的集成, 普通用户是可以通过Docker来启动一部分组件了.

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

root@HomeFN:/usr/trim/etc# docker info
Client: Docker Engine - Community
 Version:    26.0.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.13.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

虚拟磁盘扩容

这个部分的是我写这篇文章的原动力, 因为我一开始就是使用Proxmox来启动这个系统的, 后续是有可能使用PVE自带的功能增加磁盘大小的,所以我就尝试研究了一下飞牛系统以及它的磁盘管理, 希望对那些同样使用PVE的用户一些帮助.

• 数据无价, 请务必在操作之前做好备份!!!
• 数据无价, 请务必在操作之前做好备份!!!
• 数据无价, 请务必在操作之前做好备份!!!

有部分内容参考: 关于飞牛在虚拟化下的存储硬盘扩容, 另外一部分我从ChatGPT学习来的,请注意, 这个步骤仅适合单磁盘的用户. 我自己本身仅仅了解RAID的功能, 但是没有任何RAID相关的实际操作.

这部分的内容不是给小白看的, 是我需要记录一下自己的操作方案, 方便以后进行磁盘管理做的.

查询当前磁盘信息

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

root@HomeFN:/usr/trim/etc# df -Th
/dev/mapper/trim_fc35013f_f739_4592_942f_d054200d2a3a-0 btrfs        6.0G  5.9M  5.5G   1% /vol2
/dev/mapper/trim_5ab5694e_275a_417b_8f53_88510b630e5f-0 btrfs         52G  1.7G   50G   4% /vol1

root@HomeFN:/usr/trim/etc# lsblk
NAME                                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sdb                                                 8:16   0   52G  0 disk
└─sdb1                                              8:17   0   52G  0 part
  └─md0                                             9:0    0   52G  0 raid1
    └─trim_5ab5694e_275a_417b_8f53_88510b630e5f-0 253:0    0   52G  0 lvm   /vol1
sdc                                                 8:32   0    6G  0 disk
└─sdc1                                              8:33   0    6G  0 part
  └─md1                                             9:1    0    6G  0 raid1
    └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1    0    6G  0 lvm   /vol2

确定好自己要扩容的磁盘, 我这里会以/vol2这个磁盘做演示, 从6G扩容到8G.

PVE中调整磁盘

选择磁盘进行扩容

增加2G的磁盘

确认磁盘已经增加

1
2
3
4
5
6

root@HomeFN:/usr/trim/etc# lsblk
NAME                                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sdc                                                 8:32   0    8G  0 disk  # 这里已经变成了8G
└─sdc1                                              8:33   0    6G  0 part
  └─md1                                             9:1    0    6G  0 raid1
    └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1    0    6G  0 lvm   /vol2

我们的目标其实是要扩容最后的lvm分区, 使其也到8G就完成了.

卸载磁盘

在系统设置中先卸载磁盘, 没用命令行是因为飞牛NAS有进程会占用, 不如直接从网页端卸载来的安全.

逐步调整分区大小

1
2

# 安装fdisk工具
apt update && apt install fdisk

调整分区

这里的核心逻辑是, 删除重建分区, 但是不更改分区表内容.

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
38
39
40
41
42
43
44
45
46
47
48
49

root@HomeFN:/usr/trim/etc# fdisk /dev/sdc

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (12582911 != 16777215) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.


Command (m for help): p

Disk /dev/sdc: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FA6EEB5E-CA1C-4B0D-A7B3-F5CE97C59BC7

Device     Start      End  Sectors Size Type
/dev/sdc1   2048 12580863 12578816   6G Linux RAID

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Command (m for help): n
Partition number (1-128, default 1):
First sector (34-16777182, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-16777182, default 16775167):

Created a new partition 1 of type 'Linux filesystem' and of size 8 GiB.
Partition #1 contains a linux_raid_member signature.

Do you want to remove the signature? [Y]es/[N]o: N  # 一定要保留当前签名

Command (m for help): t

Selected partition 1
Partition type or alias (type L to list all): 42
Changed type of partition 'Linux filesystem' to 'Linux RAID'.

Command (m for help): w
The partition table has been altered.
Syncing disks.

查看调整结果:

1
2
3
4
5
6

root@HomeFN:/usr/trim/etc# lsblk
NAME                                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sdc                                                 8:32   0    8G  0 disk
└─sdc1                                              8:33   0    8G  0 part  # 分区变为了8G
  └─md1                                             9:1    0    6G  0 raid1
    └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1    0    6G  0 lvm   /vol2

调整raid

1
2
3
4
5
6
7
8

root@HomeFN:/usr/trim/etc# mdadm --grow /dev/md1 --size=max
mdadm: component size of /dev/md1 has been set to 8381440K
root@HomeFN:/usr/trim/etc# lsblk
NAME                                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sdc                                                 8:32   0    8G  0 disk
└─sdc1                                              8:33   0    8G  0 part
  └─md1                                             9:1    0    8G  0 raid1  # raid变为了8G
    └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1    0    6G  0 lvm   /vol2

调整lvm卷

1
2
3
4
5
6
7
8
9
10
11

root@HomeFN:/usr/trim/etc#  pvresize /dev/md1
root@HomeFN:/usr/trim/etc# lvresize /dev/trim_fc35013f_f739_4592_942f_d054200d2a3a/0 -l +100%FREE
  Size of logical volume trim_fc35013f_f739_4592_942f_d054200d2a3a/0 changed from 5.99 GiB (1534 extents) to 7.99 GiB (2046 extents).
  Logical volume trim_fc35013f_f739_4592_942f_d054200d2a3a/0 successfully resized.


root@HomeFN:/usr/trim/etc# lsblk
sdc                                                 8:32   0    8G  0 disk
└─sdc1                                              8:33   0    8G  0 part
  └─md1                                             9:1    0    8G  0 raid1
    └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1    0    8G  0 lvm   /vol2  # lvm卷变为了8G

调整文件系统

1
2
3
4
5

root@HomeFN:/usr/trim/etc# btrfs filesystem resize max /vol2/
Resize device id 1 (/dev/mapper/trim_fc35013f_f739_4592_942f_d054200d2a3a-0) from 5.99GiB to max

root@HomeFN:/usr/trim/etc# df -Th
/dev/mapper/trim_fc35013f_f739_4592_942f_d054200d2a3a-0 btrfs        8.0G  5.9M  7.5G   1% /vol2  # 文件系统也变成了8G

我仅仅在单磁盘上做了这个操作, 其他RAID形式我没有操作过, 建议慎重.

系统更新

目前我只安装了一个版本, 这个系统的后期更新也是个问题, 包括系统本身, 内部组件, 希望开发团队已经有完整的方案了.

总结

我觉得飞牛NAS的低层系统以及其技术选型已经非常好了: Debian 12, PostgreSQL, Docker, Rclone, 组件大部分使用Golang编写,自由度拉满, 也方便和我之前的NAS系统做集成, 客户端也多端支持. 我想我没有什么可能拒绝继续使用这个NAS平台.

另外一点就是我担心他们的目标用户, 如果目标用户是像我一样的NAS使用者, 这个项目怕是要亏到底掉, 我既不想多花钱又不需要技术支持…

我挺好奇他们的增值服务到底要往什么方向发展, 如果是某个组件收费, 那一个组件的收益怎么负担所有组件的开发, 会不会存在团队间的不平衡?在我看来这个服务一定要走企业化方向的, 类似CentOS的咨询, PVE的授权, 或者是被小米这种厂商收购作为集成系统.

目前的阶段, 我会尝试使用一部分功能, 但是不会把所有服务都迁移过去. 除非项目组能够在钱烧完之前获得更加稳定的收入流.让用户相信盈利模式可持续比让用户体验一下难太多了, 希望你们能成功吧.

背景

有些朋友知道，我自己的 NAS 并没有安装定制化的 Linux 系统，而是购买了几块移动硬盘挂载到 Proxmox 中，然后安装 Debian 来使用。

之后手动启动里面的 Samba, Jellyfin 等服务。因为不止一台机器，也包括云厂商的，所以我使用 K3s 统一编排这些服务。

1
2
3
4
5

(⎈|default:default)➜  BlogSource git:(master) ✗ kubectl get pods
jellyfin-web-b5488b69b-cz69t                1/1     Running   0              15d
timemachine-dbc898585-j4ln8                 1/1     Running   0              42d
uptime-kuma-74b49dd555-qfnvz                1/1     Running   0              22h
samba-7c95544b86-qjj7q                      1/1     Running   0              16d

我自己额外的服务也有很多，所以只能使用这种形式来组织服务了。

安装

这次的飞牛NAS我其实是作为虚拟机安装在Proxmox中的，然后挂了虚拟的硬盘进去：

具体过程可以自己尝试下，最后页面大概长这样

我的一些用法

云盘挂载

我之前一直开着百度云盘和阿里云盘的会员，这次终于有官方的系统能直接挂载到Linux下面了。另外我还把原有的SMB服务也挂过来了，相当于飞牛NAS做了一个家用NAS的中心

影视照片

其实我想写篇博客就是因为它的影视功能太好了，我把原来在Jellyfin添加的路径以及网盘保存的电影、电视剧都加到这里了。

我顺便也给电视和iPad装了客户端，比Plex和Jellyfin使用体验好太多了。

Time Machine

之前我的Time Machine是用容器挂了磁盘来做的，类似这样进行创建的，估计我之后就会把这个功能也放到飞牛里面了。

1
2
3
4
5
6

name: timemachine
image: mbentley/timemachine:smb-20250328
hostPath:
- name: data
  hostPath: /run/mount/AppleBackup/timemachine
  podPath: /opt/timemachine

网盘备份

原来我的备份方案是先用rclone同步到Windows中，再通过Windows虚拟机中的阿里云盘客户端做文件备份的

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

name: rclone-backup
type: yaml
image: rclone/rclone:1.68
template: rclone
command:
- /bin/sh
- -c
- while true; do rclone sync /data win-smb:/K3sBackup/${NODE_NAME} -v; sleep 7200; done
hostPath:
- name: data-sync
  hostPath: /var/lib/K3sData/
  podPath:  /data

现在可以考虑直接将文件同步到飞牛NAS中，再配置它原生的备份方案来放到网盘了。

新加硬盘

我的另一台NAS上面的硬盘可能不会再动了，但是新买的硬盘估计会用用PVE的USB挂到飞牛这边来了。至于RAID目前我还没有这方面的需求。

总结

我挺喜欢它的很多功能的，基本上已经将我心目中的NAS实现了。我甚至想要将部分服务迁移到这里来了(Jellyfin, TimeMachine, alist)。它也增强了很多原来NextCloud的支持不好的功能，如果有一天我开工作室，估计会用它来做内部共享系统，比用很多云服务的SaaS功能提供的都好。

本文内容承接 InfluxDB 的使用与一些 A 股持仓分享。当时，我的交易系统已经有了后台任务，定时将部分数据同步到 InfluxDB 并展示出来。

去年 11 月，我发现了 bolt.new，可以使用 AI 快速生成前端代码。我借此机会为交易系统添加了前端页面，对页面效果非常满意。因此，我写下这篇博客，分享我的半自动化股票交易系统。为什么说是半自动化呢？因为我已经设置好了买入卖出的价格和数量，仅使用这个系统执行交易并发送提醒。

系统界面

作为游客，你可以直接访问这里：

https://stock.corvo.fun/

其中落地页和持仓页面是公开可见的。

落地页

这里的图表展示的是上证指数。我问 bolt 有没有更炫酷的落地页，它就生成了这个动态绘图。

持仓页面

这里的图表记录了我的仓位分布和操作情况。操作记录中仅显示成功的交易，并支持查看很久以前的交易。

我的交易计划

Trade Plan 标签页记录了我手动创建的一些条件单。

上半部分：股票走势

上半部分展示了选定股票的走势情况：

下半部分：预期计划

下半部分是我的预期计划：

这些条件单比同花顺或腾讯自选股的条件单更加个性化。我并不纠结程序是否会因故障而错过交易，因为股市从来不缺机会，不是吗？

一些交易策略

在上述系统页面中，我记录了一种确定价格和仓位的自动交易策略。此外，这个系统还支持几种其他策略，以下是具体分享。

1. 确定价格和仓位的自动交易

我的仓位图中大约有 20 多只股票。如果每天都要逐一查看这些股票，想想都觉得麻烦。通过程序的自动化，我节省了大量看盘时间。
我只需创建股票的交易预期，程序会自动监听并执行操作。例如，对于中远海控，我已经设置好了买卖点对应的价格和数量。

2. 动态止盈的自动交易

对于已经盈利的股票，我会设置一些止盈点来决定何时卖出。
以 2500 元为界限，当某只股票的阶段性收益超过 2500 元时，我会考虑卖出接近 2500 元的部分仓位。下一次卖出的点则会递增，比如 2500 × 1.1 = 2750 元。
我的数据库记录大致如下：

3. 成功买卖后自动创建未来交易

有些交易策略是以买入和卖出形成闭环的操作逻辑。我实现了一个功能：当每日交易成功后，程序会自动创建未来的交易记录。
例如，当我以 1.532 的价格卖出 5000 股某股票时，程序会自动生成一条未来买入记录，价格为卖出价的 0.9 倍（即 1.3788）。同样，买入成功后也会生成未来的卖出记录。

一些模型和回测的分享

我认为股票交易在长期来看是一个概率问题，因此会通过模型和回测来量化收益和风险。以下是一些分享：

盈利与亏损模型

查看 Colab Notebook

这个文档并不是告诉你能赚多少钱或亏多少钱，而是帮助你量化预期收益或损失。

使用 Backtrader 进行回测

查看 Colab Notebook

这个回测策略是基于某只股票当天价格相较于前一天最高点的跌幅进行买入，再逐步卖出的收益率分析。它可以回测过去几年的数据，标记买卖点并分析最终结果，非常实用。

如果你是 Backtrader 的新手，可以参考这个 Notebook，它详细介绍了如何使用 Backtrader 以及展示回测结果。

bolt 的一些使用技巧

1. 页面分离与项目结构化

在使用 bolt 时，我会要求它将不同的页面或组件进行分离。这不仅方便后续修改，也让项目逻辑更加清晰。

2. Mock 数据与生产数据分离

bolt 的后端功能无法完全满足我的需求，因此我要求它规范化接口并提供 Mock 数据功能。以下是实现示例：

在开发阶段，页面使用 Mock 数据；而在生产部署时，切换为我自己的接口。这种分离极大提升了开发效率。

3. 客户端集成的痛点

目前，bolt 生成的前端代码需要手动下载并导入到本地项目中。虽然前后端分离已经实现，但这个过程仍然不够高效。希望未来 bolt 能支持远程同步代码到本地的功能。

项目部署与自动化

作为我的老本行，CI/CD 流程是我非常熟悉的领域。未来有机会，我会专门写一篇文章分享我的自用 CI/CD 流程。

整理和总结

虽然我的账户一直是盈利的，但我并不在意这个交易系统能赚多少钱或亏多少钱。对我来说，这个系统的意义在于让交易更加结构化和可追溯化。
大多数时候，我们追求的不是赚钱，而是创建一个系统来解决问题。当你解决了足够多的问题，自然会获得一些收益。
我并不认为自己是投资者，而是一个拥有自动化工具的交易员。

在日本旅行时，我发现日本的井盖设计非常精美，每个城市都有其独特的设计风格。以下是我在不同城市拍摄的井盖照片集。

这里图片的布局相关都是使用cursor实现的, 强大啊!

项目时间线

• 22年09月: 我入职时 老板告诉我有一项工作是将我们的项目从Mesos集群迁移到Kubernetes集群
• 23年04月: 开始梳理所有的报警规则, 整理日志以及其他数据上报的链路
• 23年06月: 迁移前的计划与筹备, 并且尝试从零搭建服务
• 23年10月: 全球第一个区域迁移成功, 后续并行迁移多个区域
• 24年01月: 海外地区除美国外全部迁移成功, 我休了很久的年假, 直到春节假期结束, 非常开心
• 24年03月: 迁移工作由其他同事接手, 开始美国区域的迁移
• 24年07月: 美国部分完成迁移, 海外的所有环境均迁移至Kubernetes集群

前置工作

下面这些内容其实很虚, 但又十分必要.必要性在于, 你要告诉老板, 告诉同事, 告诉合作部门. 整个迁移的成功率在90%以上, 而且遇到了问题能够有拖底的解决方案.

梳理现有环境

要梳理的内容主要包括: 监控报警, 迁移范围

我们一般将报警按照是否有Player Impact进行区分, 为了整个迁移过程要保证用户无感.报警梳理这部分工作我做了挺久的, 主要是确认数据源, 数据上报链路, 有些时候直接去看后端代码, 确认下具体的报警逻辑.

Demo环境搭建以及验证

这部分直接决定着我们迁移方案的选择. 虽然合作方提供了Helm Chart, 但是在具体落地时, 需要事先将可能的坑踩一遍, 才能有把握去做好方案以及应对措施.

部门协调

这部分的工作不止是为了给老板做汇报, 也是为了让合作方伙伴更加信任我们, 要让对方也觉得这个工作是有把握的.

需要给出迁移的大致时间线, 并且做好风险评估以及回滚方案.

比如, 我们的系统有区分大版本和热更, 3个月一个大版本. 那么我们在规划时间线的时候, 就要考虑大版本的时间线, 最好在两个大版本之间完成, 避免在发大版本的时候出现事故.

问题与解决方案

这里记录一些我们曾经遇到的问题, 时间过去很久, 我就凭借记忆讲讲.

流水线改造

我们原有的流水线是基于BK GUI搭建的, 每次修改都需要在页面上点点点, 而且版本控制也不好用.基于此, 我们整套流水线改用Jenkins来实现了.

我之前写了一篇使用Groovy进行编程: 执行流程控制技巧与心得, 里面用到的并发以及重试技术基本就是整个流水线的核心了.

到目前为止, 流水线稳定运行了一年, 运行基本十分稳定且未出现重构功能这样的大改动.

我应该会再写一篇在Jenkins中如何做好流水线的单元测试以及项目规划的博客.

有状态的节点

虽然我们的业务在迁移前就已经使用了Mesos将其跑在了容器里, 但是在机器上还有几个目录是当前机器的容器都要共享的.为此, 我们使用了两个DaemonSet来同步机器上的这些目录文件, 但是依然存在着风险.

后来, 同事提出了一个解决方案, 新创建的Node会带有taint记号, 假如我们没有手动操作过这个Node,它就不会被投入使用. 这个问题我们至今也未完全解决, 带来的问题就是自动扩缩容迟迟没法落地.

给我带来了足够的教训, 业务一开始就不能有对有状态节点的依赖. 说人话就是, 自己把云硬盘或是volume挂进去,别用机器上的文件夹.

AWS CNI与多网卡问题

在美国的一些服务器, 会绑定一个单独的加速IP来降低玩家的游戏延迟, 本意是为了提升用户体验.但是同事发现在EKS集群中我们自己添加的网卡会被vpc-cni自动删掉. 他们当时没什么思路, 我说那我去读读看vpc-cni的代码吧,

被删掉的原因我找ChatGPT分析了一下代码

https://chatgpt.com/share/8e96aedc-b297-4f97-b765-267d108229f9

然后又看到了这个字段, 可以令vpc-cni忽略我们的网卡.

1
2
3

// eniNoManageTagKey is the tag that may be set on an ENI to indicate ipamd
// should not manage it in any form.
eniNoManageTagKey = "node.k8s.amazonaws.com/no_manage"

https://docs.aws.amazon.com/eks/latest/userguide/pod-multiple-network-interfaces.htmlhttps://docs.aws.amazon.com/whitepapers/latest/ec2-networking-for-telecom/multus-container-network-interface-cni.html

1
2

// https://github.com/aws/amazon-vpc-cni-k8s/blob/06828cee09446fd9e501984727ed807254385cb8/pkg/ipamd/ipamd.go#L1348
attachedENIs := c.filterUnmanagedENIs(allENIs)

当然可以说是我们文档读的还不够多, 不过, 能有机会简单看看基础组件的代码, 把问题解决掉, 还是很开心的.

混合云服务

我们使用的云服务业务中, 由于政策原因, 有一部分是非AWS以及腾讯云的, 我们仅仅租赁了几台物理机, 并通过专线进行组网.针对这部分机器, 也需要添加到腾讯云的TKE中, 才能完成整体K8S的升级. 这里借助了腾讯云的注册节点.只是网络方面稍稍不同, 我们直接用hostNetwork的方式规避了问题.

https://www.tencentcloud.com/zh/document/product/457/60282

一些思考

Terraform与IaC

我们使用Terraform是为了什么, 我觉得在使用它之前就要想清楚.

有个概念叫SSoT(Single Source of Truth), 对应在我们系统架构中, 它的含义是,我们们的当前的机器是什么功能, 他们分别有什么样的任务.在没有Terraform之前, 这部分数据可能会存储在CMDB中, 这也是一种SSoT, 但是CMDB的维护是需要人工的,也就是说, 从我们修改了一个机器的属性, 到它最后反映到CMDB中是有一个流程的.Terraform的存在简化了这一流程, 当我们对基建作出了改动的时候, Terraform的state就是一个SSoT,原有的CMDB就可以退变成仅仅是一个展示平台.

这里我推荐使用 Teragrunt+Atlantis 的方式, 真正的将基建的修改与审批流程相结合. 从技术人员的角度讲, 这个流程太美了.

https://medium.com/@unruly_mood/terragrunt-terraform-with-atlantis-to-automate-your-infrastructure-pull-requests-9832dd24e5bf

云原生问题的一些思考

Cloud Native 还是 Cloud Provider Native

在迁移结束之后, 我收到了一个任务是将原有的一部分逻辑迁移到Jenkins流水线中, 这个逻辑是到某台机器中执行一些脚本.不知道读者能想到有哪些方案, 我直接列出来这几种, 相信肯定有你想过的:

1. 使用ssh登录到机器, 执行对应的脚本, 最简单, 但是扩展性低, 而且我们机器上基本都取消ssh的服务了
2. 使用AWS或是腾讯云提供的SSM/TAT服务, 调用云厂商提供的脚本执行API
3. 我已经有了Kubernetes集群, 那么我可以新建一个pod, 在Jenkins执行kubectl exec -ti xxxx run.shexec中时, 会保留stdoud和stderr的日志, 相当于使用Jenkins来做执行日志的保留

最后我选择了第三种, 也说服了老板, 现在它也还在这么跑着. 这是我的考虑:

1. 需要区分好什么是云原生以及云厂商原生, 当我们使用了厂商提供的特有API的时候, 我们就应该问自己, 这是必要的吗?
2. 需要区分业务的需求, 比如, 什么需求是来自业务的, 什么需求是来自基建的, 我们值不值得为这个需求写一层多云厂商的兼容?

全球化协作

在一个全球化的团队里其实是很幸福的. 我能想到2点,

1. 你可以不太需要担心PageDuty(oncall)的问题, 美国的同事可以在我们凌晨的时候来处理问题.
2. 对于美东的同事, 我们和他们正好相差12小时, 相当于CN的白天我来处理, 工作结果留好言.CN的夜晚由他们继续来做, 工作效率非常高

凌晨喊人oncall是不人道的, 运维全球化一定是趋势.

整理和总结

其实7月份我就想写这个博客了, 近期终于有时间来整理下思路. 实际的问题解决起来还是很有成就感的, 但是一定要做好记录哈哈.不然就真的只能在写博客的时候苦苦搜寻记忆了.

Image by Freepik

创意来自之前同期做的小卡纸卡片，她做的太精美了。但她和我说有点遗憾是没有加NFC跳转音乐的功能。我就想花时间探索一下，现在已经可以成功写入并且正常唤醒网易云音乐和bilibili了。

AI生成图片的能力着实给不会画图的我提供了很多可能哈哈哈.

图片生成

准备提示词

我是用ChatGPT先准备好了提示词

生成素材

初始化图片

之前玩的时候自己建过Stable Diffusion, 我就直接用自己的尝试了下, 反正我是觉得够了

制作NFC贴图

我本身不会用PS, 所以简单的图片编辑是借助这个网站

https://fabritor.surge.sh/https://github.com/sleepy-zone/fabritor-web

简单的加下文字, 合成下图片真的很好用

传给店家

素材准备好之后, 直接传给店家就可以, 就是你心里要有底它大概长什么样子, 以下是我的经验

1. 图片是很亮的, 但是传给店家做出来的成品是有色差的
2. 边缘一定要有一点留白, 避免边缘的内容没有完全反映到图片中

你看这张, 是不是亮度完全不一样:

NFC写入

这个部分我先前分享在了小红书上, 详细可以看这里.

【动手制作自己的 NFC 冰箱贴 - 小米粥分你一半 | 小红书 - 你的生活指南】 😆 liPjLOZocun3BUZ 😆 https://www.xiaohongshu.com/discovery/item/66eeef7000000000260326a6?source=webshare&xhsshare=pc_web&xsec_token=AB5UGv9LJKqQ3S8DKtTLRyyl7RAylzkovtWDS34-7prU4=&xsec_source=pc_share

一些NFC URI 的分享

去年买了Meta Quest 3, 玩了几次之后就一直在吃灰. 每次录制五杀视频的时候,总想用VR第一人称的方式去观察峡谷中的战斗, 可惜没法hack到游戏客户端.

所以我想着直接写个VR版的游戏, 把召唤师峡谷放进去. 这次Thunderdome正好就有机会去实现了.我之前没做过任何游戏开发, 这次选Unity单纯是因为它的VR demo比较好. 在整个三天中,我实际做的工作有限, 基本是根据VR Demo来改改实现自己的逻辑, 这里抛砖引玉, 希望大佬们不要嘲笑哈哈.

最后的游玩视频我放在B站了, 可以直接查看:

Unity学习

我对Unity一点不认识的时候, 先去youtube上面找了一些视频来看, 确保自己有个还算是正常的认知,其实主要是学习一下C#以及模型的使用.

这是我看过的一些视频, 主要是

摄像头, 物体移动, 以及键盘鼠标交互

• https://www.youtube.com/watch?v=xCxSjgYTw9c
• https://www.youtube.com/watch?v=f473C43s8nE

刚体碰撞

• https://www.youtube.com/watch?v=mkErt53EEFY
• https://www.youtube.com/watch?v=GTvqhLJKzDo

我自己是在Thunderdome前, 动手做了一个3D版简易的打地鼠. 到正式开始时才开始用VR demo重写.类似这样:

模型与动作

我的模型都来源于这里

https://modelviewer.lol/model-viewer?id=142001

上次也用这些模型做了一个网页的Zoe

而且下载的glb格式其实是有动作的, 我在Unity中可以导入模型之后直接加动作效果

以剑魔为例, 直接将模型拖拽到场景之后, 添加Animator绑定到模型中就可以了.

碰撞与刚体

说来惭愧, 我现在只搞懂了刚体的概念, 以及碰撞的原理, 对于在Unity中怎么使用它还是完全懵逼,这把亚托克斯的剑, 我是将它固定在demo中原有的一个枪上面, 而后增加了Mesh collider使其能够与其他模型发生交互.

VR调试与双项目编译

VR调试

VR项目的开发中, 我不可能每改一点代码就烧到机器中去调试.所以, 开发过程中, 大部分的调试操作发生在开发过程中, 我使用XR Device Simulator来实现.虽然不那么好用, 但是已经能够省很多时间了, 其实我觉得最优的方案是可以直接使用真的控制器.

在编译生成apk的时候, 手动去掉这个类的勾选即可, 或者我使用了另一种方案git pull --autostash能够直接将这个类关闭.

双项目编译

Unity中编译项目会block掉整个项目的开发, 我原本打算用命令行来做, 后来想了想没心情再去研究.所以我就开了另一个项目, 这个项目只进行代码pull.

在pull之后, 我手动触发编译按钮, 最后我得到了这么多的apk包, 其中能稳定运行的我打了stable.

C# 学习

我之前从没写过C#代码, 不过有ChatGPT的加持, 我能像编写Python代码一样让它帮我生成一部分内容.自己组织的部分其实只有场景概念这些内容.

总结

不管是Thunderdome还是黑客马拉松, 我觉得都非常好玩.但是参加的时候要考虑下, 规定时间之内能做哪些内容, 需要做什么样的提前准备.我觉得前提是保证自己在有限时间内可以做点东西出来, 如果我一开始没做那个简单的3D项目甚至没有对Unity有了个初步的认识, 可能TD的这两天完全都在入门, 根本不可能做的出来.