sunnysab

同意楼上 #59 。

在做一套系统，关键是辅助自己验证想法、提高自己对市场的认知，可能这比量化策略更重要。

@Ccf 您好，请问是 cloudlflare tunnel （那套 zero trust ）吗？还是 ddns 哇？

我现在临时打了个 ssh 隧道用，反向、动态端口转发，很稳，我来尝试一下新方案。

昨晚折腾了好久也没有解决。对端是千兆对等教育网，本地是安徽电信（下行 500Mbps 上行 40Mbps ），跨省。

1. tailscale 这种基于 udp 的协议，隧道内 ping,丢包率可达 20%。说明 udp 丢包率高。
2. 两侧通过 ipv6 直连，ping 大概丢包 2%。
3. 两侧通过 ipv6 直连，iper3 跑 tcp 忘了，反正也不好
4. 两侧通过 GRE6 隧道，上行 4Mbps ，下行 100Mbps 。重传和丢包约 5%，但负载不高的话，ping 无丢包。
5. 两侧通过 ipv6-in-ipv4 隧道，丢包都有点高（ udp 6%-30%）

此外还测试了 Easytier （无中转），主要是 tcp6 和 quic6 模式。均出现过隧道本身几十秒自动重连一次的情况，不知道为什么。codex 的总结：TCP 隧道下行约 14.5 Mbps ，上行约 2.73 Mbps 。quic6 ，下行 UDP 10M 可跑满且 0% 丢包；但 QUIC 承载本身仍约每 40 秒重连一次，且上行 TCP 只能约 0.4 Mbps.

之前还发现在 tailscale 隧道上传文件，单连接约 400kB/s 。

现在我推测这个丢包对所有 ip 协议均生效？下一步方向：

1. 尝试更小众的如 VoIP 协议等协议。
2. 建立多条隧道同时收发，以提高吞吐量。
3. 用一些前向纠错的手段抗丢包。

有个想法，这俩都是开源的，让 AI 写个新的并到一起… 制约因素：token 不够…

其实之前搞过一点，后来烂尾了

真心怕中转站投毒/低价模型替换…

您好！用目前最强的 Gemini3.1Pro 和 GPT-5.4 测试了一下，仓库见 https://github.com/sunnysab/BaziQA

结果如下：
OpenAI GPT-5.4 Multi-turn 30.83%
OpenAI GPT-5.4 Structured 31.33%
Gemini-3.1-Pro-Preview Multi-turn 38.33%
Gemini-3.1-Pro-Preview Structured 33.33%

本以为新模型会好一些，但似乎 GPT5.4 并没有什么提升，而 Gemini3.1Pro 多轮测试的效果是更好的。API 使用的是 OpenRouter 官方 API 。有可能是排盘的差异（我不知道我用的库准不准，来源： https://github.com/china-testing/bazi ）

很有意思的、针对 LLM 的测试角度。从我个人经验看，在使用 AI 做推理前，可以让它回答自己过去的事，这也是测试准确性的方法。

@Mzs 成功了，感谢！

我之前缓存过一些微信公众号文章，用 cloudflare workers 做的，效果还不错，没有遇到反爬。
最近用自己的真实 ip 跑，几十几百篇都没啥问题？

---
当前是自用，抓取一百多个公众号。如果开放，可能遇到的问题会比较多。

似乎有点像 AI 去写博客？