2026-04-29 13:00:00
上一篇文章里，我介绍了如何在 OpenClaw 中配置 Longbridge CLI 和 Skill，打通美股、港股、A 股的对话式查询与交易工作流。但是长桥并没有日本市场的行情，也不支持日股交易，所以今天我就再来介绍一下如何在 OpenClaw 中接入 moomoo 日本的 API 以及相应的 Skill 来帮我分析日本股市。
过去几年里，我都是使用其他网页信息来看高配当股、追跟踪日经225的 ETF、分析株主優待，数据来源七零八落，每次要对比几只股票的走势，得分别打开浏览器、moomoo App、再加上自己的笔记，来回切换很耗精力。恰好这段时间我也在用 [[OpenClaw]] 搭建投研工作台，看到 [[Moomoo]] 官方推出了一套专门为 AI 工具设计的 Skills 包，就把两边接到了一起。接上之后，直接在终端里问”帮我看一下丰田最近一个月的日 K 和成交量变化”，AI 就能调起 Moomoo API 把数据拉回来，整理成我看得懂的格式。这篇就把这套工作流的配置过程和实际体验记录下来。
先说说为什么我觉得 API 对日股研究特别有价值。日本股市有几个特点，让手动查询变得格外低效。一是标的数量多，东证（TSE）挂牌的上市公司超过 3900 家，光是做初步的行业筛选和财务比较，手动一家家看就很花时间；二是日本公司的财报、公告大量是日文，不顺手的人光是找关键数据就要花不少功夫；三是如果你同时持有日本股票和美股，两个市场时区不同，盯盘和整理数据的节奏很难统一。
通过 API 工具，这些问题大多可以用程序化的方式解决。我可以让 AI 一次性拉十几只候选股的 K 线，按波动率或换手率初步排序，把不符合条件的先过滤掉，再逐一深入研究。数据整理这个环节是最枯燥的，也是最适合交给 AI 的部分，把它解放出来之后，我的注意力才能真正放在判断和决策上。
[[Moomoo]] 的 OpenAPI 在这里是个合适的基础设施。它的行情数据覆盖美股、港股、A 股、日本、新加坡、澳大利亚等多个市场，架构上用本地运行的 [[OpenD]] 网关做中转，SDK 支持 Python、Java、C#、C++、JavaScript 五种语言。更重要的是，官方最近专门为 AI Agent 工具发布了一套 Skills 包，让 [[OpenClaw]] 这类工具可以直接调用，不需要自己写适配层。
在配置之前，先说清楚 Moomoo OpenAPI 的架构，因为理解这两层的分工对后面的调试很有帮助。
第一层是 moomoo OpenD，一个轻量的本地网关程序，需要运行在你的本地电脑或云服务器上。你的所有 API 请求，不管是查行情还是查持仓，都要先经过这个网关，再由它转发到 Moomoo 的后端服务器。OpenD 支持 Windows、macOS、Ubuntu 和 CentOS，启动之后需要用你的 Moomoo 账号登录一次完成授权，之后的 API 调用就在这个授权会话里进行。
第二层是各语言的 SDK，也就是 moomoo-api。以 Python 为例，pip install moomoo-api 之后就能用代码连接本地的 OpenD，发起行情订阅或者交易指令。SDK 和 OpenD 之间走的是自定义 TCP 协议，和语言无关。
这套架构对安全性和稳定性都有考量：账户凭证在 OpenD 里管理，你的脚本和 AI 工具只和本地 OpenD 交互，不直接接触账号密码；即便 AI 误操作，也只能在 OpenD 授权范围内行事。对于日常的行情查询和分析任务来说，这个结构已经足够顺手了。
[[OpenClaw]] 的 Skills 机制我在之前介绍 Longbridge 配置的文章里提到过。简单说，一个 Skill 就是一个目录，里面放了 SKILL.md 和若干脚本。SKILL.md 告诉 AI 这个 Skill 能干什么、什么场景下该用、底层命令怎么调用。OpenClaw 启动时扫描 skills 目录，把这些说明加载到上下文里，之后用户提问时它会判断要不要用某个 Skill 来响应。
Moomoo 官方提供的 AI Skills 包里包含两个模块：install-moomoo-opend（安装助手，负责检测操作系统并自动完成 OpenD 的下载、解压和启动）和 moomooapi（行情交易助手，内置 25 个脚本和 65 条 API 接口签名，覆盖行情查询、账户管理、交易操作等核心场景）。两个模块分工明确，前者解决”跑起来”的问题，后者解决”怎么用”的问题。
整个配置分三步：安装 OpenD、完成登录授权、把 Skills 接进 OpenClaw。
最省事的方式是直接在 OpenClaw 里用自然语言触发安装助手。向 OpenClaw 发送以下提示：
阅读文档中的一键安装步骤，安装 moomoo OpenD 和相关 skills
https://openapi.moomoo.com/moomoo-api-doc/intro/ai.html
OpenClaw 会自动读取文档，识别你的操作系统并下载对应版本的 OpenD，完成解压和启动。这条路径对大多数人最省事。
如果你倾向于手动控制，也可以直接去 Moomoo OpenAPI 页面 下载 OpenD，选择对应系统版本安装，然后启动并登录账号完成授权。还没有 Moomoo 日本账户的话，可以通过这个链接注册，日股交易佣金免费，美股 NISA 账户佣金也免费。
OpenD 启动后需要手动登录 [[Moomoo]] 账号——可以通过 OpenD 自带的 Web 管理界面完成，也可以通过客户端扫码授权。这一步是每次重启 OpenD 后都要做的，不提供免登录的持久会话。
Skills 的手动安装流程和 Futu API 类似：
# 下载 Skills 包
curl -L https://openapi.moomoo.com/skills/opend-skills.zip -o /tmp/moomoo-skills.zip
# 解压到临时目录
unzip /tmp/moomoo-skills.zip -d /tmp/moomoo-skills
# 复制到 OpenClaw 全局 skills 目录
cp -r /tmp/moomoo-skills/skills/* ~/.openclaw/skills/
# 清理临时文件
rm -rf /tmp/moomoo-skills /tmp/moomoo-skills.zip
如果你用的是 [[Claude Code]]，Skills 目录则是 ~/.claude/skills/，两边的 Skills 格式是通用的，同一套文件可以同时放进两个目录使用。安装完成后在 OpenClaw 的对话框里输入 /，能看到 moomooapi 和 install-moomoo-opend 出现在补全列表里，就说明安装成功了。
配置好之后，我先从最基础的日股行情查询开始测试。
日本股票在 Moomoo API 里的代码格式是 JP.XXXX，比如丰田汽车（7203）是 JP.7203，索尼集团（6758）是 JP.6758，日本银行股里常被讨论的三菱UFJ金融集团（8306）是 JP.8306。这个代码格式和 Moomoo App 里显示的一致，一般不会搞混。
我最常用的几种查询方式大概是这样的：
查单只股票的实时报价和今日涨跌，直接说”帮我看一下日本株 JP.7203 丰田的现价和今天的表现”，它就会去拉实时报价，给出当前价格、涨跌幅、成交量，附带一段简短的数字总结。
对比多只股票的时候，我会说”把丰田（JP.7203）、本田（JP.7267）、日产（JP.7201）三只汽车股今天的涨跌幅排一下”，AI 会批量拉报价、排好序、输出一个简洁的比较列表。这种多标的并行查询以前要自己切 App 来回看，现在一句话就出来了。
K 线数据是我研究技术形态时用得最多的。让它拉某只股票过去 30 天的日 K 或者过去 3 个月的周 K，它会返回 OHLCV 数据，同时顺手做个简单的走势描述，比如”过去 30 天整体呈上升趋势，最近一周有高位震荡”之类的初步判断。这种初筛是最省时间的，因为它把”先看一眼值不值得继续研究”这个步骤替我做掉了。
日经 225 相关的查询也很常见。我会问”日经 225 今天的整体走势和成分股里涨幅最大的是哪几只”，这种跨标的的信息整合在 App 里翻是比较麻烦的，用对话的方式反而顺手。
第一个要注意的是 OpenD 必须保持运行。和 Longbridge CLI 不同，moomoo API 的所有请求都依赖本地的 OpenD 网关，如果 OpenD 停了，所有 API 调用都会失败。我的建议是把 OpenD 作为后台服务配置，开机自启动，或者在云服务器上部署，避免本地关机导致工作流中断。
第二个坑是 OpenD 登录有效期。Moomoo 的 OpenD 登录状态不是永久的，有时候会因为长时间未使用或者账号安全策略而失效，需要重新登录授权。如果 AI 突然报错说”连接失败”或者”未授权”，第一步先去检查 OpenD 是不是需要重新登录。
第三个是股票代码格式。Moomoo API 的日本股票代码必须带 JP. 前缀，直接说”7203”是查不到的。在 Skill 的描述里加上这条规则，让 AI 在构建查询时自动补全代码格式，可以省掉很多来回纠错的时间。
第四个是行情订阅有配额。根据账户等级，实时行情订阅的并发数量从 100 到 2000 个不等。如果在脚本或自动化工作流里订阅了大量标的，记得定期释放不用的订阅，不然跑满之后新的订阅请求会失败。
第五个是关于日本账户的使用范围。目前通过 Moomoo 日本账户的 API 接口，交易功能仅支持美国股票和美国期权；如果你想通过 API 查询日本股票的行情数据，建议确认你的账户权限是否包含日股数据订阅，或者联系 Moomoo 客服了解具体的开通方式。查询数据和执行交易在权限上是分开的，数据查询通常比交易的开通门槛低。
基础流程跑通之后，我开始做一些更贴近日常研究的组合。
第一个是高配当股筛选辅助。我会让 AI 先批量拉一批候选标的的基本面数据，然后按股息率、PE、市净率做初步排序。光是这个环节，以前我要手动在多个数据源之间切换，现在可以用对话的方式驱动。
第二个是株主優待相关的分析。日本上市公司里有大量提供株主優待的公司，我在研究某只股票的時候，会让 AI 结合 K 线数据和配息时间点，看看権利確定日前后的价格走势有没有规律性的变化。这种分析以前是手工标注图表，现在可以让 AI 先做一遍初步整理，我再判断有没有值得深入的信号。
第三个是盘前晨报。我做了一个简单的工作流，每天开盘前让 AI 把我持仓的几只日本股票和关注的标的报价都拉一遍，顺手看看当天有没有重要的财报或者公告，再汇总成一份 Markdown 推送到我的 [[Obsidian]] 笔记里。这个工作流最值钱的不是有多先进，而是它真的每天在用，把原本分散在几个 App 里的晨报信息集中到了一个地方。
如果你对 AI 辅助量化有更深的兴趣，社区里已经有人基于 Moomoo API 开发了 MCP Server（moomoo-api-mcp），可以让 [[Claude]] 直接通过 MCP 协议调用 Moomoo 的行情和账户接口：
uvx --refresh moomoo-api-mcp
这条路对已经在用 Claude API 做定制开发的人比较实用，配合 Skills 的使用场景有所不同，具体选哪条路可以根据自己的工具链来判断。
把 Moomoo API Skills 接进 OpenClaw 之后，我对日股研究工作流的感受变化主要体现在两点。第一是查数据这件事变轻了，不是因为 AI 能帮我做决策，而是它把”拿数据、整理一遍”这两步顺手做掉了，让我可以更快地进入真正需要判断的部分。第二是研究密度提高了，以前觉得”顺手看一下这只股票”成本不低，现在直接说一句就有结果，我自然就更愿意多比、多看。
日本股市本身还有很多值得深挖的地方，高配当、株主優待、小型价值股，不少机会是被散户投资者低估的。[[Moomoo]] 的 OpenAPI 加上 [[OpenClaw]] 的 Skills 机制，算是给这块研究工作提供了一个顺手的基础设施。如果你本来就在用 OpenClaw，Skills 包装好之后五分钟内可以开始第一个查询。对于日股研究这件事来说，工具的顺手程度往往直接影响研究的深度，这一点我越来越有体会。
如果你对日本股市本身感兴趣，除了这个博客，我也在 EV 的日本生活记录 持续写在日本生活和投资的一些观察，涵盖高配当股、株主優待、ETF 等话题，欢迎关注。
2026-04-28 13:00:00
我最近在用 [[OpenClaw]] 处理一些需要浏览器自动化的任务时，发现平台提供了两种截然不同的方案：一个是官方内置的 browser 插件，另一个是 [[Vercel]] Labs 开源的 agent-browser 外部 Skill。刚开始我以为两者差不多，无非是换了个名字、换了个入口，但用了一段时间之后才意识到，这两套方案的设计哲学完全不同——一个面向”人机协作”，另一个专为”AI 批量执行”而生。搞清楚这个区别之后，我的 Agent 任务效率和 API 成本都有了明显改善。
浏览器自动化在 AI Agent 工作流中越来越常见，无论是抓取数据、填写表单，还是处理需要登录才能访问的网页，都需要一个可靠的浏览器控制方案。问题在于，传统的浏览器自动化工具（比如 [[Playwright]] MCP）虽然功能强大，但它们并不是专门为 AI Agent 设计的——每次操作都需要把大量的 DOM 结构塞进上下文窗口，Token 消耗惊人，很容易在复杂任务中撑爆上下文，导致任务中断或推理质量下降。
[[OpenClaw]] 为了解决这个问题，提供了两套并行的方案，分别针对不同的使用场景。内置 browser 插件是开箱即用的，能直接接管你正在运行的 Chrome；agent-browser 则是一个来自 Vercel Labs 的外部 Skill，需要单独安装，但在 Token 效率和执行速度上都更激进。了解两者之间的本质区别，能帮你在不同任务中做出更合理的选择，同时也能节省大量的 API 费用。
在深入技术细节之前，先从整体上理解两者的定位差异。内置 browser 插件由 OpenClaw 官方开发，核心设计目标是支持接管已打开的 Chrome，通过 Chrome DevTools Protocol（CDP）直接 Attach 到你正在运行的浏览器会话，天然保留登录状态和 Cookie。它更像是把你桌面上的 Chrome 浏览器权限开放给了 Agent，操作直观、可见，适合那些登录态敏感、需要可视化调试的场景。
agent-browser 则走了完全不同的路，它由 Vercel Labs 开发并开源，专门为 AI Agent 优化，默认以无头模式（Headless）运行，用 Rust 写的 CLI 和 Daemon 追求极致的执行效率。两者的功能侧重差异用一张表可以看得很直观：
| 维度 | 内置 browser 插件 | agent-browser |
|---|---|---|
| 开发方 | OpenClaw 官方 | Vercel Labs |
| 接入方式 | CDP Attach，支持有头模式 | 无头模式（Headless）为主 |
| Token 消耗 | 使用 DOM/HTML，上下文占用较高 | 比 Playwright MCP 减少 93% |
| 启动速度 | 每次启动新浏览器进程 | Rust daemon 热命令 <10ms |
| 已登录会话 | 原生支持，直接接管 | 需配置 Auth Vault 或 CDP 模式 |
agent-browser 的三层架构是理解它高效率的关键。最外层是 Rust 写的 CLI，负责解析命令并与 Daemon 通信，冷启动在 50ms 以内；中间层是持久运行的 Daemon，维持浏览器会话，热命令执行在 10ms 以内，彻底消除了传统方案每次都要重新启动浏览器的冷启动开销；底层由 [[Playwright]] 负责实际的浏览器操作，支持 Chromium、Firefox 和 WebKit，同时提供视频录制、网络拦截等高级功能。
内置 browser 插件则基于 Chrome DevTools Protocol，支持多种接入模式：可以通过 OpenClaw 的 Chrome 扩展 Attach 到你已有的标签页（Extension Relay Mode），也可以让 OpenClaw 启动独立的 Chromium 实例（OpenClaw-Managed Mode），还可以通过官方的 Chrome DevTools MCP Server 连接（需要 Chrome 144 以上版本）。不同模式对应不同的隔离程度和登录态保留能力，最常用的场景是直接接管你当前打开的 Chrome，这样 Agent 就能访问你已经登录的所有网站。
这是两者最关键的差异，理解这个问题需要知道两者在”描述页面”这件事上的不同做法。内置 browser 插件（以及传统的 Playwright MCP）描述页面的方式是提取 DOM 结构或 HTML，一个普通网页的 DOM 往往包含大量嵌套的 div 容器、样式标签、脚本代码，塞进上下文动辄需要 1万 到 5万 Token，十步操作的任务流程累计下来轻松突破 10万 Token。
agent-browser 的核心创新在于用无障碍树（Accessibility Tree）代替 DOM 来描述页面。无障碍树是浏览器为屏幕阅读器等辅助工具构建的一套平行结构，它只保留有语义的交互元素：按钮、链接、输入框、标题，把所有纯布局的容器和装饰性标记都过滤掉。agent-browser 从这棵树里提取有用的节点，给每个元素分配一个极短的引用标识（如 @e1、@e2、@e3），整张页面的快照只需要大约 200 到 300 Token。实际测试数据显示，一个十步操作的工作流，Playwright MCP 需要约 11.4万 Token，agent-browser 只需要约 7000 Token。
元素引用的稳定性是另一个重要优点。传统方式依赖 CSS 选择器或 XPath 定位，一旦页面样式或结构微调，定位就可能失效；而无障碍树里的元素语义（”登录按钮”就是登录按钮）基本不随页面改版而变化，Agent 操作的稳定性也更高。
这是两者使用体验差异最明显的地方。内置 browser 插件的 CDP Attach 模式天生就能复用你的 Chrome 登录状态，打开对应的标签页，Agent 接管即可访问，对于需要扫码的中国互联网平台、或者配置了双因素认证的账号，这几乎是唯一合理的方案，完全不需要把密码交给 Agent 处理。
agent-browser 应对登录的方式是 Auth Vault（认证保险库）。你预先用加密方式把账号密码存储在本地（AES-256-GCM 加密，密钥存在 ~/.agent-browser/.encryption-key），Agent 执行时调用 agent-browser auth login 命令完成登录流程，整个过程密码不会出现在 LLM 的上下文里，安全性有保障。对于不那么复杂的登录场景（用户名密码），这个方案完全够用。此外 agent-browser 也支持 CDP 模式，可以连接到已运行的 Chrome，在需要时同样能复用登录状态：
# 启动 Chrome 并开启远程调试
google-chrome --remote-debugging-port=9222
# agent-browser 连接到已运行的 Chrome
agent-browser --cdp 9222 open https://example.com
agent-browser --cdp 9222 snapshot -i
agent-browser --cdp 9222 click @e1
在真实任务里，我的选择逻辑大致如下：如果任务涉及已登录账号的操作，比如在社交平台发帖、操作公司内部后台、处理需要二维码登录的产品，就用内置 browser 插件直接 Attach 到 Chrome。这种方式几乎是零配置，打开对应标签页，让 Agent 接管即可；调试也很方便，因为整个过程是有头的，你能看到浏览器实时在做什么，出问题了直接盯着屏幕找原因。
如果任务是批量的、重复性的——大量数据采集、自动化填写表单、跨多个页面的流程操作——选 agent-browser 更合适。93% 的 Token 减少意味着同一个上下文窗口里可以完成更长、更复杂的任务，也意味着 API 账单会显著降低。Rust daemon 的持久化设计也意味着连续操作之间几乎没有启动延迟，在需要频繁与页面交互的场景里手感明显更流畅。
两者并不互斥，完全可以在同一个 OpenClaw 实例里同时启用，无头批处理任务用 agent-browser，需要登录态的操作用内置 browser 插件，根据任务性质灵活切换。
回顾整个对比，内置 browser 插件和 agent-browser 的区别，本质上是”人机协作”和”AI 批处理”两种思路的碰撞。内置 browser 插件把你桌面上的 Chrome 权限开放给 Agent，操作直接、可见，登录态天然保留；agent-browser 则把浏览器操作彻底抽象成 AI 友好的指令集，用无障碍树代替 DOM，用 Rust daemon 消除冷启动，在 Token 效率和执行速度上都做到了极致。
如果你刚开始接触 [[OpenClaw]] 的浏览器自动化，建议先从内置 browser 插件入手，几乎不需要额外配置，能让你快速验证 Agent 的浏览器操作能力；等到任务量上来了，或者发现 Token 费用开始令人心疼，再引入 agent-browser，会是一个非常值得的迁移。两个工具都用好了，才是把 [[OpenClaw]] 浏览器自动化能力发挥到极致的正确姿势。
2026-04-25 13:00:00
最近看到一条让我心里一沉的消息——[[FILCO]]（斐尔可）的母公司 [[Diatec]] 在 2026 年 4 月 22 日突然停业了。没有正式的新闻发布会，没有任何对外的告别声明，官网上只留下一段简短的停业通知，随后连网站内容都清空了。对于很多玩过机械键盘的人来说，FILCO 不只是一个品牌名，它代表着那个机械键盘从小众走向主流的时代。
如果你是在 2010 年前后接触机械键盘的人，你一定绕不开 FILCO 这个名字。Diatec 公司创立于 1982 年，总部位于东京，最初做的是半导体销售，后来逐步转型为 PC 外设领域。FILCO 品牌在 1990 年代确立，旗下最具代表性的产品线是 Majestouch（圣手）系列——这个名字在日本键盘玩家圈子里几乎是”高品质机械键盘”的代名词。
让 FILCO 真正在市场上站稳脚跟的，是它在 2004 年的一个决定：率先在日本将德国 [[Cherry MX]] 轴体引入消费级键盘。那个年代，薄膜键盘仍是市场主流，日本消费者对机械键盘几乎没有概念，FILCO 等于是一个人推开了那扇门。Majestouch 系列由此成为资深玩家口中的标杆，用它的人遍布程序员、写作者、翻译和各类文字工作者。国内玩家亲切地称其为”大F”，这个外号一叫就是十几年。
FILCO 的产品并不是靠华丽的外观打动人的，它走的是另一条路：在细节上做到让人挑不出毛病。Majestouch 系列最受推崇的几个点，至今仍被老玩家反复提起。
首先是 Costar 卫星轴设计。空格键和 Shift 键的稳定性一直是机械键盘的痛点，Costar 卫星轴相比平衡杆结构手感更直接、反馈更清脆，是一批追求纯粹打字手感的用户的最爱。其次是”忍者”款（Ninja）侧刻键帽。键帽正面素净无字，字符印在键帽侧面，桌面整洁美观同时又不影响实际使用。这种设计既低调又实用，让 FILCO 积累了一批审美品味相近的忠实用户。再加上厚实的外壳、严格的品质管控，以及 Cherry MX 各颜色轴体的多版本支持——红轴、青轴、茶轴、静音红轴——FILCO 面向不同使用场景，没有用花哨功能充数，全靠扎实的产品力说话。
近几年 FILCO 也尝试过一些新方向。2022 年推出的 Majestouch Convertible3 支持有线和蓝牙双模，可以自定义日英配列和数字键盘选项；2023 年的 Majestouch Xacro M10SP 更大胆地做了分体式设计，带有 10 个宏键，向工程师和专业用户靠拢。这些尝试说明 FILCO 并非没有在适应市场，只是时机和节奏都慢了半拍。
Diatec 在停业公告中没有提及任何具体原因，但结合行业背景来看，答案并不难猜。
机械键盘市场这几年发生了根本性的结构变化。以 [[Keychron]]、[[Akko]]、[[Nuphy]] 为代表的新兴品牌，凭借无线连接、热插拔轴座、铝合金外壳、客制化配件生态等一整套现代玩家语言，以更具性价比的定价快速占领市场。与此同时，中国厂商在磁轴（霍尔效应轴）、光轴、电感轴等新轴体技术上密集发力，驱动了一轮又一轮的产品革新，把整个行业的参考系重新拉高了一截。FILCO 长期依赖 Cherry MX 轴体、坚持传统有线固焊设计的产品路线，在这波浪潮中显得越来越保守。
Cherry MX 本身的处境也不乐观。这家德国轴体厂商近年同样面临来自中国制造商的激烈竞争，也在经历自己的市场份额缩水。赖以为基础的供应链合作伙伴都在收缩，对 FILCO 这类深度绑定 Cherry 的品牌来说是双重压力。
更深层的问题是定价空间。FILCO 的产品一直定位在中高端，在日本本土售价合理，但放到全球市场来看，同等价位的竞争对手可以提供更多功能。当消费者发现花同样的钱能买到无线、热插拔、RGB、更多轴体选择的键盘时，FILCO 曾经引以为傲的”稳定可靠”就变成了一种相对沉默的优势，很难在购买决策的瞬间胜出。
让行业观察者感到唏嘘的不只是倒闭本身，而是倒闭的方式。没有新闻稿，没有媒体采访，没有对老用户的公开致谢，只是在官网悄悄贴出停业通知，然后把所有内容清空。一家在日本键盘圈耕耘了几十年、基本上定义了那个时代”实用机械键盘”标准的公司，就这样悄无声息地离场了。在 Hacker News 的讨论帖子里，有用户写道：”FILCO 就这样安静地消失，真的是一个时代的落幕。”这句话，我觉得说得很准。
Diatec 在停业声明中唯一主动交代的事项，是确认已按照日本个人信息保护法规，在 2026 年 4 月 22 日之前将所有邮购和用户支持中收集到的个人信息全部妥善删除。这大概是这家公司最后的体面。
FILCO 的倒闭，让我想到很多年前第一次接触机械键盘时的情景。那时候周围的人还在用薄膜键盘，能聊机械键盘的圈子很小，FILCO 和 Cherry 几乎是入门必提的名字。那种每次按键都有确定感的体验，是很多人爱上机械键盘的起点，而 FILCO 就是那个时代最重要的引路人之一。
市场变了，玩家的需求也变了。今天的机械键盘世界比十年前丰富得多，也分裂得多——有人追求客制化的极致，有人热衷新轴体，有人要的是便携和无线，有人只想要一把结实耐用、能用十年的键盘。FILCO 恰恰是最后这类需求的代言人，只是这种需求在市场份额上越来越小，越来越不足以支撑一家公司的生存。
无论如何，FILCO 做过的产品会留在用户手里继续工作，那些圣手键盘的手感和段落，也会留在用过它的人的记忆里。一个品牌倒闭了，但它留下的影响不会立刻消失——这或许是最好的告别方式了。
2026-04-22 13:00:00
最近在研究[[期权]]交易的时候，我越来越频繁地看到一个词：0DTE。尤其是在 Reddit 的 r/wallstreetbets 和一些量化交易社区里，关于末日期权的讨论热度一直居高不下。有人靠它一天翻了几倍账户，也有人一单清零。这种极端的收益分布，吸引了大量散户和专业交易者的目光。
我自己花了不少时间研究末日期权的机制和策略，今天就把这些整理成文章，聊聊末日期权到底是什么、有哪些核心策略，以及如何在这个高风险游戏里尽可能提高自己的胜算。
末日期权，英文叫 0DTE（Zero Days to Expiration），指的是在当天到期、当天交易的[[期权]]合约。从字面意思理解，就是”距离到期日为零天”的期权。
在美股市场中，[[标普500指数]]（SPX）、SPY、QQQ 等主要指数 ETF 如今已经实现了每个交易日都有到期的期权合约，这使得末日期权交易成为可能。根据 CBOE 的数据，2023 年以来，0DTE 期权的成交量已经占到 SPX 全部期权成交量的 40% 以上，这个比例在短短几年内从几乎可以忽略不计跃升到接近半壁江山，增速令人咋舌。
理解末日期权，需要先搞清楚几个核心概念。
期权的价格由两部分组成：内在价值和时间价值。内在价值是期权如果立刻行权能获得的收益，时间价值则是市场对于未来价格可能继续向有利方向运动的预期所赋予的溢价。0DTE 期权因为马上就要到期，时间价值极低，价格几乎全部由内在价值决定——或者更准确地说，是由标的资产的当前价格和行权价的距离决定。
正因如此，0DTE 期权的权利金通常非常便宜，买入一份合约可能只需要几十到几百美元，但一旦方向踩对，价格可以在数小时内翻几倍甚至十几倍。这种”以小搏大”的特性，是它吸引散户的核心原因。
要真正理解末日期权，必须深入了解期权的希腊字母，尤其是 Gamma 和 Theta 这两个关键指标。
Theta（时间衰减）是期权价格随时间流逝而减少的速度。对于期权买家来说，Theta 是最大的敌人——每过一天，期权的时间价值就减少一点。而 0DTE 的特殊之处在于，它的 Theta 衰减速度在最后一天会呈指数级加速，尤其是在收盘前几个小时，时间价值的消耗极为剧烈。这意味着如果你买入了一份虚值的末日期权，即便标的资产价格稳定不动，你的期权也会快速贬值，最终归零。
Gamma（Delta 的变化速度）在 0DTE 场景下则是买方的最大武器。当期权接近到期且接近平值（ATM）时，Gamma 会变得极高。这意味着标的资产价格每移动一点，期权的 Delta（价格敏感度）就会大幅改变，期权价格的变化会被显著放大。举个例子，如果 SPX 在收盘前一小时突然快速上涨 10 点，一个接近平值的看涨末日期权可能在几分钟内价格翻倍，这就是高 Gamma 带来的”杠杆爆炸”效应。
此外，还有一个现象叫做 IV Crush（隐含波动率崩塌）。当重大事件（比如美联储议息会议、非农数据发布）过后，市场的不确定性消除，期权的隐含波动率会大幅下降，导致期权价格即便在标的方向走对的情况下也可能亏损。0DTE 期权因为时间极短，IV Crush 的影响相对有限，但在重大事件日前后交易仍需格外注意。
末日期权的策略大体上分为两类：买方策略（Long）和卖方策略（Short）。两者的风险收益特征完全不同，适合不同风格的交易者。
最直接的玩法是买入看涨期权（Call）或看跌期权（Put），押注当天市场的方向。这类策略风险有限（最多亏掉权利金），但胜率相对较低——市场需要在短时间内按照你预期的方向移动足够的幅度，才能覆盖权利金成本并产生利润。
在实际操作中，很多交易者会选择轻微虚值（OTM）的合约，因为权利金更低，一旦价格突破行权价，收益倍数更高。但这也意味着对市场走势的判断需要更精准。另一个思路是买入接近平值（ATM）的合约，Gamma 最高，对价格移动最敏感，但权利金相对更贵。
方向性交易的核心在于把握催化剂：比如在重要数据公布前押注方向（注意 IV Crush 风险），或者在盘中出现明显的技术突破信号时跟进。很多 0DTE 交易者会盯盘关键支撑阻力位，在价格突破关键点位时快速建仓。
相较于买入策略，卖出末日期权（收取权利金）拥有更高的胜率，因为时间站在你这一边。Theta 衰减对卖方有利——只要标的资产在到期前没有大幅波动超过行权价，卖出的期权就会到期归零，权利金全部落袋。
常见的做法是卖出虚值的看涨或看跌期权，也就是”裸卖”。但裸卖的风险是无限的（裸卖 Call 时如果标的暴涨，理论上亏损没有上限），所以大多数专业交易者会采用价差的形式来限制风险。
价差策略（Spread）是在卖出一个期权的同时买入更虚值的同类期权作为保护。比如卖出 SPX 5100 的看涨期权，同时买入 5110 的看涨期权，这样构成了一个看涨期权熊市价差（Bear Call Spread），最大亏损被限制在两个行权价之差减去收到的净权利金。这种方式牺牲了一部分收益，但大幅降低了尾部风险，更适合稳健型交易者。
如果你判断今天市场会在某个区间内震荡，不会大涨也不会大跌，那么中性策略是更好的选择。
铁鹰（Iron Condor）是同时卖出一个虚值看涨价差和一个虚值看跌价差，相当于在当前价格两侧都建立了”保险杠”。只要到期时标的资产价格留在两个空头行权价之间，四腿合约全部到期归零，所有收到的权利金都变成利润。这个策略胜率相对较高，但最大收益固定，且需要精准判断当天的波动区间。
蝴蝶（Butterfly Spread）则更加精准，是押注标的资产在到期时精确落在某个价格附近。通常用于重要数据公布后市场已经充分消化，预计价格会在某个水平附近停止波动的场景。蝴蝶的收益分布呈现出中间高、两侧低的形态，如果判断准确，收益率非常可观。
进阶的 0DTE 交易者不会死守一个方向，而是根据盘中市场结构动态调整仓位。比如早盘市场呈现震荡格局时先卖出铁鹰收取权利金，如果下午出现明显的方向性突破，则买入突破方向的期权进行对冲或追涨，同时平掉亏损方向的腿以控制回撤。这种动态管理需要较强的市场感知能力和快速执行力。
末日期权的高风险性是不可避免的，但通过科学的方法可以在一定程度上改善交易结果。
行权价的选择是最关键的决策之一。对于买方来说，选择太虚值的期权虽然权利金低，但需要标的资产大幅移动才能盈利，胜率极低；选择太接近平值的期权则权利金较贵，即便方向对了，如果移动幅度不够，也可能亏损。一般来说，买入 Delta 在 0.2 到 0.4 之间的期权在风险收益上相对平衡。
时机选择对末日期权尤为重要。0DTE 期权不适合全天候交易，市场开盘后 30 分钟和收盘前 1 小时通常是波动最剧烈的时段，也是末日期权价格变化最快的窗口。很多交易者会选择在上午 10 点到下午 2 点（美东时间）之间进行卖方策略，此时市场波动相对平稳，Theta 衰减稳定进行；而在收盘前一小时如果有方向性机会，则切换为买方策略快速博取短线收益。
仓位管理是决定能否在 0DTE 交易中长期存活的核心。由于末日期权可以快速归零，每笔交易的风险敞口必须严格控制。很多有经验的交易者建议，单笔 0DTE 交易的投入不超过总账户的 1% 到 2%，绝不能因为连续亏损后想要”扳回来”而加大仓位，这是最常见的致命错误。
技术面和市场结构的判断也很重要。末日期权的交易本质上是在极短时间框架内做方向判断，因此需要关注的是当天的关键价位：前一日高低点、昨日收盘价、开盘跳空缺口、整数关口等。这些价位往往是价格的磁力点或阻力位，市场在这些位置附近的反应会直接影响末日期权的价值走向。
此外，关注 VIX（恐慌指数）和期权市场的隐含波动率水平也很有帮助。在 VIX 处于高位时，期权权利金更贵，卖方策略的收益更高但风险也更大；VIX 低位时，期权便宜，买方策略的成本更低。理解当前市场的波动率环境，有助于选择更适合的策略方向。
止损纪律是末日期权交易中必须拥有的品质。无论是买方还是卖方，都需要预先设定好止损条件，并严格执行。买入 0DTE 期权后，如果价格短时间内下跌超过 50%，就应该考虑止损离场，而不是死扛等待翻身。一个归零的 0DTE 期权和一个亏损 50% 的期权，对账户的影响天差地别。
末日期权是一个高度专业化且充满争议的交易工具。它的魅力在于极致的杠杆效应和短时间内翻倍的可能，但背后是大量散户在不理解底层机制的情况下盲目跟风而遭受的惨重亏损。
我认为，末日期权适合有一定期权基础和市场经验的交易者，作为整体策略的一个补充，而不是主要的盈利方式。在尝试 0DTE 交易之前，至少应该对[[期权]]的希腊字母有清晰的认知，理解时间价值衰减的机制，并且用纸上交易（Paper Trading）积累足够的经验。
对于初学者，我更建议先从卖出价差的策略入手，因为卖方有时间优势，而价差结构限制了最大亏损，相对更适合建立初步的交易直觉。等到对市场节奏有了感觉之后，再逐步尝试方向性买入或者更复杂的动态调整策略。
末日期权的世界里，活得久比赚得快重要。
2026-04-20 13:00:00
最近在折腾 [[Rime]] 输入法，想配置一套日语输入方案，方便写笔记时随时切换输入日语词汇。配置过程中我发现了一个奇怪的现象：候选词列表里有时会出现一些看起来像简体中文的汉字，而不是标准日语汉字的写法。出于好奇，我翻开 japanese.jmdict.dict.yaml 字库文件仔细检查，才意识到背后其实涉及日语汉字的一段重要历史——新旧字体之争。
要理解这个问题，得先回到二战结束后的日本。1945 年战败后，日本政府推行了一系列文字改革，目的是降低汉字学习难度，推动文化普及。1946 年，日本内阁颁布了《当用漢字表》，列出了日常生活和出版物中应当使用的 1850 个汉字。紧接着在 1949 年，又发布了《当用漢字字体表》，规定了这些汉字的标准写法，对许多笔画繁复的旧字形进行了简化，这些经过简化的字形就是所谓的「新字体」，而原来的写法则被称为「旧字体」。
这次改革的思路与中国大陆后来推行简体字的改革有几分相似，但两者是独立进行的，具体的简化方案也存在相当多的差异。日语的新旧字体改革并非全面替换，而是在保留汉字体系的前提下，对特定字形进行局部调整，整体保守程度比中文简化字改革要高一些。
新旧字体的区别，有些非常明显，有些则极为细微。来看一些典型的例子：
| 旧字体 | 新字体 | 中文简体 | 含义 |
|---|---|---|---|
| 國 | 国 | 国 | 国家 |
| 學 | 学 | 学 | 学习 |
| 體 | 体 | 体 | 身体 |
| 廣 | 広 | 广 | 宽广 |
| 變 | 変 | 变 | 变化 |
| 邊 | 辺 | 边 | 边界 |
| 轉 | 転 | 转 | 转动 |
| 證 | 証 | 证 | 证明 |
| 藝 | 芸 | 艺 | 艺术 |
| 寶 | 宝 | 宝 | 宝贝 |
看这张表你会发现：某些新字体和中文简体字完全相同，比如「国」「学」「体」；但另一些则走了不同的简化路径，比如「広」对应繁体「廣」，中文简体却是「广」，三者各不相同；「証」对应繁体「證」，中文简体是「证」，日语新字体的写法又自成一格。
日语新旧字体和中文简繁体字之间的关系，大概可以分为以下几种情况：
第一种是完全一致。日语新字体与中文简体字写法相同，与繁体字相对。「国/國」「学/學」「体/體」这些字，在日语和普通话里写法一样，只是发音不同，容易让人误以为日语用的就是简体中文字。
第二种是日语独有简化。日语新字体进行了简化，但和中文简体字的方案不同。日语的「広」（旧字体「廣」），中文简体写作「广」；日语的「証」（旧字体「證」），中文简体写作「证」。这类字是真正意义上的「日语特有字形」，既不是繁体，也不是简体，容易在学习时造成混淆。
第三种是日语未简化。一些字在中文简体里被大幅简化，但日语新字体保留了较为接近原始字形的写法。例如「齢」（年龄）的中文简体是「龄」，日语写法接近繁体。「飲」「飯」这类字在日语里也保留了更多笔画。
正是因为这种复杂的三角关系，日语字库在编码和录入时就容易出现混用，某个字到底是用「日语新字体对应的码点」还是「恰好相同的中文字符码点」，在显示上完全一样，但在字体级别的渲染上可能有微妙差异。
回到最初触发我好奇心的那个问题。[[Rime]] 的日语输入方案通常基于 [[JMdict]] 词典构建，japanese.jmdict.dict.yaml 这个字库文件是从 JMdict 数据库转换而来的。JMdict 是由社区维护的日英双语词典，历史可以追溯到 1990 年代，数据条目来自不同时期和不同贡献者，字形标准难免不够统一。
在字库里，你可能会看到同一个单词同时存在新字体和旧字体两种写法，甚至混入了与日语新字体字形相同、但实际是中文简体字码点的字符。从渲染结果来看，这两者往往完全一样，但如果涉及到字体替换或者特定渲染环境，就可能出现奇怪的显示问题——候选词里的汉字突然变成了「中文字体风格」，笔画细节与日文字体略有出入。
更麻烦的是，Unicode 对很多日中共用汉字使用相同的码点，即所谓的 CJK 统一汉字。「国」这个字在 Unicode 里只有一个码点 U+56FD，无论是日语语境还是中文语境都是同一个字符。字形上的差异只能通过字体来体现——日文字体和中文字体对同一个汉字的渲染可能略有不同，比如横折的开口方向、笔画的连接方式等。所以在 Rime 候选词里看到「像简体中文的字」，很多时候并不是真的混入了中文字符，而是看到了字形上与简体字相同的日语新字体，只是字体渲染风格不同。
如果你也在用 [[Rime]] 配置日语输入，遇到类似问题，有几个思路可以参考：
检查字库来源是第一步。确认你使用的 japanese.jmdict.dict.yaml 版本和来源，优先使用维护活跃、经过校对的版本。目前比较常用的日语 Rime 方案有 rime-japanese 等，可以对比不同版本字库里的字形差异。
设置合适的显示字体也很重要。在系统或 Rime 的样式配置里，为日语输入候选项指定使用日文字体，比如 Noto Serif JP、Source Han Serif JP、游明朝等。这样即便码点相同，字形也会按照日文规范渲染，视觉上就能明显区分「这是日语汉字还是中文汉字」。
此外，在 Rime 里可以为不同的 schema（方案）设置不同的显示字体，切换到日语模式时自动使用日文字体，切回中文时换回中文字体，操作上比较优雅。
这次因为一个输入法配置的小问题，意外深入了解了日语汉字改革的历史。日语新旧字体的演变和中文简繁字的分化，本质上都是现代社会在汉字这套古老文字系统里求效率、求统一的尝试。两套改革走了不同的路，却有着共同的出发点——让更多人能更轻松地读写汉字。
对学习日语的人来说，理解新旧字体的区别，不仅能帮助正确识读老书、公文和人名（日本人名里旧字体用法相当普遍），也能更好地把握日语和中文在汉字使用上的异同。至于在 [[Rime]] 里折腾日语输入方案，倒意外成了一次文字学入门课，这大概就是技术折腾的附加价值所在。
2026-04-12 13:00:00
2026 年 3 月 7 日，[[Andrej Karpathy]] 在 X 上发了一条推文，宣布开源一个叫做 AutoResearch 的项目。帖子的热度出乎很多人的意料——发布几天内 GitHub 累积了 21,000 个星标，原始推文的浏览量达到了 860 万。两周后，《财富》杂志专门写了一篇文章，把这套方法命名为「The Karpathy Loop」，认为它代表了 AI 研究方式的一次范式转变。
我自己看完这个项目之后第一反应是：这个想法太简洁了，简洁到让人觉得「为什么之前没有人这么做」。它的核心思路用一句话就能说清楚：把一个 AI Agent 放进你的机器学习训练代码里，让它自己做实验，你去睡觉，早上看结果。
做机器学习实验有一个让所有人头疼的地方：大量时间花在了低价值的重复操作上。你想试试换一种学习率调度策略，需要改代码、跑训练、等结果、记录下来、再改、再跑。这个循环本身并不需要太多智识——更多是时间和精力的消耗。每次实验需要人守着，一天下来跑个五六次已经算高效了。
Karpathy 的观察是：AI Agent 做这件事比人更合适。Agent 不需要休息，不会因为等待而分心，能严格执行预设的评估标准，而且它提出的假设有时候会走一些人类不会主动去想的方向。如果给它一套规范的实验环境和明确的优化目标，它可以每小时跑 12 次实验，一夜下来跑 100 次，全部自动完成，你只需要第二天早上看 git 日志里留下了哪些改动。
AutoResearch 的整个设计非常克制，项目核心只有三个文件，各自有明确的职责边界。
prepare.py 是不可修改的地基。它负责数据准备（下载训练数据、训练 tokenizer）和运行时工具函数，同时也是最终的评估器，负责计算 val_bpb（验证集每字节比特数）这个核心指标。Agent 不能碰这个文件——这保证了评估标准始终一致，不同实验的结果可以直接比较。
train.py 是 Agent 唯一被允许修改的文件。它包含 GPT 模型定义、优化器逻辑和训练循环，以及所有可以被调整的超参数、架构选择、批大小等变量。Agent 在这里提出改动、测试，如果有改善就保留，否则回滚。
program.md 是人写给 Agent 的指令文档。它描述研究方向、哪些类型的改动值得尝试、哪些规则必须遵守（比如「不能修改模型的对外接口」、「不要尝试 X」）。这是人类唯一真正需要持续维护的文件——你通过改写 program.md 来引导 Agent 的探索方向。
这三个文件的分工直接体现了 Karpathy 的设计哲学：人定方向，Agent 执行。两者的边界通过文件权限来强制——不是靠约定，是靠结构。
每次实验的流程是固定的：Agent 读取当前的 train.py 和 program.md，形成一个改进假设，对 train.py 做出修改，启动训练，固定跑满 5 分钟。5 分钟到了，用 prepare.py 里的评估逻辑计算 val_bpb，和当前最优基线对比。
如果改善了，执行 git commit，这个改动成为新的基线。如果没有改善，执行 git reset，回到上一个状态，像什么都没发生过一样。然后进入下一轮循环。
固定 5 分钟的时间预算这个设定看似随意，实际上是深思熟虑的结果。它让每次实验的计算成本可控，在不同硬件上都能保证大致相同的实验频率，同时避免某个「看起来有潜力」的方向消耗过多资源。每小时约 12 次实验、一夜约 100 次——规模足够让有意义的改进浮现出来，成本又足够低到可以接受。
所有保留下来的改动都在 git 历史里，每一次 commit 都带着 val_bpb 数值。这意味着整个研究过程天然就是可复现的——你不需要额外的实验记录系统，git log 就是实验日志。
Karpathy 自己用 AutoResearch 跑了一个两天的实验，让 Agent 在一个 depth=12 的模型上自由探索。结果跑了大约 700 次实验，找到了 20 个真实有效的改进。他把这些改进叠加起来应用到 depth=24 的更大模型上，所有改动都是累加有效的，而且迁移性良好。
更值得一提的是，Agent 在这个过程中发现了原始 attention 实现里一个人类开发者漏掉了好几个月的 bug。一个自动化的实验循环找到了手动代码审查没有发现的问题——这是任何人都很难提前预期到的收获。
Shopify CEO Tobi Lütke 把这个思路应用到了他们自己的 Liquid 模板引擎（Shopify 每个店铺的页面都通过它渲染）上，一晚上跑了 93 个实验。结果是渲染速度提升了 53%，内存分配减少了 61%。其中最关键的一个改动是把 StringScanner 替换成 String#byteindex，单这一处改动就贡献了 40% 的速度提升——一个 Agent 靠穷举式实验发现的改动，远超他们工程师的预期。
Karpathy 在介绍这个项目时说了一句话，我觉得比项目本身更值得记下来：
“All LLM frontier labs will do this. It’s the final boss battle.”
他认为所有顶级 AI 实验室最终都会走到这一步——用 AI 来加速 AI 的研究本身。这不是比喻，是一个关于竞争优势来源的判断：谁能更快速地迭代实验，谁就能更快找到更好的模型架构和训练方法。
他对未来方向的预期也很清楚：「下一步是让 AutoResearch 能够异步大规模协作——像 SETI@home 那样，不是模拟一个博士生做实验，而是模拟一整个研究社区。」分布式的 Agent 群，在不同机器上同时探索不同方向，结果汇总到一个共享的知识库——这个愿景比「一夜跑 100 个实验」还要激进得多。
AutoResearch 的底层哲学和他稍后发布的 LLM Wiki 是同一套逻辑：人负责策展和方向，AI 负责执行和维护。LLM Wiki 里，人选择放进 /raw 的原始资料，AI 维护 /wiki 里的知识积累；AutoResearch 里，人写 program.md 定义研究规则，AI 修改 train.py 做实验迭代。两者都是对「人做什么、AI 做什么」这个问题的同一种回答。
Karpathy 在介绍时特别说了一句：「你不是’直接使用’它，它更像是一个配方和思路——把它交给你的 Agent，应用到你关心的问题上。」
这句话很重要。AutoResearch 不是一个开箱即用的产品，它是一套可以被移植的模式。如果你手上有任何可以用代码定义的优化问题——不一定是 LLM 训练，可以是数据库查询优化、算法参数调整、甚至是某种业务规则的 A/B 测试——都可以尝试用同样的三文件结构 + Agent 循环来处理。
具体到机器学习，项目已经适配了 Apple Silicon（MLX 版本），不需要 CUDA。单 GPU 可以跑，M 系列 Mac 也可以跑。仓库地址是 github.com/karpathy/autoresearch，630 行 Python，代码量小到可以完整读一遍。
目前社区里已经有了对各种方向的扩展：有人做了更通用的「任意代码优化」版本，有人把它用在科学计算上，还有人在用 Agent swarm（多 Agent 并行）来对同一个问题同时探索不同方向。[[Awesome AutoResearch]] 这个 GitHub 仓库收集了社区的各种应用案例和优化记录，可以作为参考。
AutoResearch 让我想起了编译器优化的发展历史。在很长一段时间里，手写汇编的程序员认为编译器生成的代码不可能比自己写的好。后来事实证明，在大多数情况下，编译器反而更好——不是因为编译器更聪明，而是因为它可以系统性地穷举人类不会有耐心尝试的每一种优化组合。
AutoResearch 做的事情，某种程度上是把这个逻辑延伸到了算法层面。不是说 Agent 比研究员更聪明，而是它可以不知疲倦地把研究员想到的每个方向都跑一遍，把研究员没想到的方向也顺便跑几遍。
在速度本身成为竞争优势的领域，能跑 100 次实验的人和只能跑 5 次实验的人，最终看到的世界会很不一样。
