关于，大概如此。

我叫 Frank，是软件工程师。主要写 Rust，做的多是开发者工具，以及这些工具和它们所依赖的底层系统之间的接缝。

最近主要在做四件事。

第一件是 gm-crypto-rs，一套纯 Rust 的国密 SM2 / SM3 / SM4 SDK。我特别在意时序侧信道这类容易被忽略的安全风险：代码处理密钥时，执行时间不能跟密钥内容有关，否则别人可能靠测耗时反推出密钥。所以涉密路径按常量时间设计，CI 里挂着一套 dudect 泄漏回归 harness，每次提交都重测——核心那一组一旦越过公开门槛，构建就会失败，而不是只相信设计评审。

第二件是 RepoLens，给 AI 编程 Agent 用的仓库记忆层——一张类型化、会衰减的记忆图，经 MCP 暴露出来，让新开的会话不必每次都冷启动重新摸清项目。

第三件是 ghrunners，macOS 上的一个观测小工具：把一台机器上 GitHub Actions self-hosted runner 的 launchd 状态、进程、日志和 GitHub API 信息收成可核对的状态。它存在的理由很简单：查这件事不该耗掉一个小时。

第四件是 Explainer Engine，一条把 storyboard 渲染成概念讲解视频的确定性流水线——讲解里的每个说法，画出来之前都得先按源码核对，核对不过就不渲染。

我做的工具，正确性、当前状态和失败模式都得保持可查。几个项目方向不一样，但惦记的是同一件事：软件应该讲得清楚自己知道什么、改动了什么、以及哪些事它做不到。

落到手上，就是那些不那么光鲜的部分：一个说得清楚的名字；一道能在发布前拦住泄漏回归的门禁；以及一行终于解释了「为什么」、而不只是重复「做了什么」的注释。都是有主张的那部分。

想看每个项目做到哪一步，这里的项目页是诚实的快照——发到哪了、凭什么这么说、哪些做不到，都写在页面上；没公开的项目也一样。已经公开的部分，源码在 GitHub。