我有好多想干的事，但是……

Laurence-042

- 2 minutes read - 248 words

完全没时间干完！

所以我想先把它们记下来，没准哪天智械危机后人类都被装罐扔到虚拟世界了呢，那时候我就有时间去干这些事了

已完成

这里是我已经干完的事，基本都是我在学习某些特定技术的时候为了学以致用做的。大部分是玩具——我大学和大学毕业后的第一份工作都没有给我留下很多自由时间，不太足够搞一些大项目

Color Change Image（2020）

  • 学习Vue
  • 图像处理
  • 尝试为真实需求设计算法

这个项目的灵感来源是当时QQ群里刷屏的几张图，其特点是图片中的元素（比如丝袜，衣服之类的）的颜色会随着聊天气泡的颜色（也就是背景色）变化。比如说那张丝袜图，如果聊天气泡是黑色的，丝袜就是黑色的；聊天气泡是白色的，丝袜就是白色的。

关键是，变色部分的阴影是被完美地保留了的，这不是简单的抠图所能做出来的。我猜想可能是画师在画图时预先设定了一个背景色，然后将阴影之类的上完色之后去除背景色，并以png格式导出的方式做出来的。

但我觉得我可以自己动手试着做一个工具出来，使其可以自动将正常的jpg加工成那种变色图，而我也能练习正在学习的Vue。就这样，这个纯属娱乐的项目就开工了。

silly butt helper（2021）

就是一个简单的带动画的网页。会从query里拿参数，然后播放一段搜索这个关键词的动画，并自动跳转到query里指定的搜索引擎搜索这个关键词的页面。就是当年我学js的时候尝试把传参、网页加载流程、第三方库引用之类的东西都用一遍得到的小玩具

言阅姬（2024）

  • JavaScript+Webpack
  • 尝试AI辅助编程

Steam好评率98%，全球首款「寻找对话中敏感词」的游戏《ウーマンコミュニケーション/ 女性交流》通关后做的小玩具，既可以直接标红页面上的敏感词来找乐子，也可以人工寻找敏感词并点击以标红以模仿游戏中的玩法

Rimworld计算仪典（2025）

  • TypeScript+Vue
  • 尝试AI辅助编程
  • 尝试demo迭代的开发模式

Rimworld的护甲系统属实不太直观，做这个工具的直接原因就是，我无法区分米莉拉派系扩展：米莉拉帝国这个 Mod 里面的磁轨杠杆步枪和电磁突击步枪哪个比较好。前者有高达 85% 的穿甲但单发且有较长的前后摇，后者穿甲只有 15% 还不如突击步枪但6连发前后摇也更短，而两者制造成本没啥本质差别。我猜测可能有个特定点护甲值，高于这个值磁轨 DPS 更高，低于这个值电突 DPS 更高。但我不知道具体值，所以我写了这个工具，然后发现电突几乎永远稳压磁轨，因为即使在较高护甲下，其多发也能有效弥补穿甲的不足

oral-oiiaioiiiai（2026）

  • 自行进行数据处理+模型训练+结果分析+调优
  • 低延迟计算
  • 程序生成音乐

一个基于实时元音识别的浏览器音游。玩家对着麦克风连续发出 O / I / A 元音，驱动猫咪旋转并触发五阶段视觉进化。

最初我是玩了一个叫《Flick It! ClitoRhythm》的神奇音游，然后因其传统四向跳舞机+十分神奇的反馈模式想到了《Friday Night Funkin》的传统四向下落式+角色的魔性BBox。然后我就在想，能不能把《FNF》里的魔性逻辑反过来，即让玩家发出BBox来玩音游。

考虑到BBox识别难度大，我决定从元音 A/I/U/E/O 入手，分析操作的技术可行性，随后意识到这作为音游有不少不兼容，但都有应对方案：

挑战问题描述解决方案
延迟音游对节奏要求极高（通常在 10ms 级）。处理音频、进行 FFT 变换再到判断元音，往往会有几十毫秒的延迟，“不跟手"感明显放弃反应式音游，改为执行特定序列的操作式音游
方言与口音不同地区的"a"发音共振峰有差异，针对标准日语优化的模型可能识别不出其他口音选择全球通用的 oiiaioiiiai 发音，简化为 O/I/A 三个元音，然后让UO可互相替代，IE可互相替代
社交尴尬对着设备大喊限制了游玩场景反向利用：足够魔性反而有利于社交媒体传播

并在开发过程中把这段时间学的机器学习知识学以致用了一下，还额外接触了程序生成音乐这么个有趣的东西

Anora’s Not Only Recording API（前端）

  • 学习Rust
  • 学习Tauri

这最初是我在第一份工作中，为了应对“必须使用某个十分奇葩的、不会编程的人用不明白、会编程的人只会被限制的API测试平台”的要求而开发的辅助工具Automatic Auto-test Wingman，以录制API调用为核心，提供各种辅助数据关联分析工具，将脚本编写转化为构建有向图。通过这种方式，只需要跑一遍界面，API流程就能被录制下来。然后按几个按钮，选几个数据，整个数据流动图就出来了。

当然，这个工具不在工作计划里，我只能在业余时间或“自愿”加班的间隙写。

但后来由于某些项目管理和官僚主义的问题，这个工具不得不在未完备的状态下进行了穿刺测试，然后就因为“对接API测试平台麻烦”（那个破平台连个projectID数据都得用三四个字段、绕七八个request才能查到，让用户直接填ID已经是最简单的方案了，结果还因为这个平台的ID必须开devtool才能看见而被嫌对接麻烦）、“需要自行配置黑名单”（TMD被测产品前端代码跟屎一样，开发改个版本号都得同时改三四个地方，进个主页都能加载10+的json，这不配黑名单就只能自学习了，而我初版的自学习方案又被嫌冷启动得录制至少两次，属实是既要又要了）之类的原因被毙了，然后需要干的活越来越多，有价值的活却越来越少，这也成了我离职的一大原因。

当我学习Tauri（Electron的技术有点老了，后面我准备切到Tauri上）时，我开始重写这个项目来学以致用巩固知识。这一次，我会叫它ANORA（Anora’s Not Only Recording API）

其仍会继承AAW的各种主要功能，同时进行一些演化，但不再作为那个垃圾API测试平台的挂件，而是一个直观、通用、可拓展的图形化编程工具。它不仅仅是API测试，而是一个通过配置不同插件可以适应包括但不限于API测试、CI/CD、AI工作流等各种场景的通用框架

  • 录制API调用

  • 将API调用整理为有向图

    • 每个节点是一个函数调用
      • 有多个入参（入handle）和单个出参（出handle）
      • handle如果是复杂对象，可以通过点击handle旁的开关展开，显示代表其属性的子handle
      • 连接出入handle表示传参
    • 执行时分多次迭代，每次迭代都会找没有“未满足的入边（即前置节点未执行完）”的节点执行

  • 推测API数据结构并保存为OpenAPI 3.0定义

  • 数据关联分析

  • 中途暂停，修改后续节点后继续执行

  • 导出与导入有向图

目前其前端部分已经基本完成，且集成进了ProxyOS项目，以作为教学演示的一部分

正在进行

这些是我想干且正在干的事

ProxyOS

  • Godot
  • 游戏设计
  • Python与其他项目混合

一个操作系统模拟+编程教程工具融合的项目

目的只是验证自己这些年的知识，作为技术人员应聘进了公司结果因为客服没干好扣绩效后，我觉得我需要做点真正想干且符合我能力的事歇俩月，然后再继续当牛马，不然我会忘记自己也算个人

你可以在ProxyOS开发半周报里查看最新进展

学点深度学习

  • 深度学习
  • 模型微调

上次碰这个还是在大学，然后在工作的几年里这项技术飞速发展。但在公司里属实接触不到相关内容：要设备没设备，要时间没时间，连查个资料都被各种提示没权限访问外网。在公司里干的最接近深度学习的事只有俩，一个是“硬编码Agent的各种前后置处理”，另一个是“当客服推广一个完全不用LLM只用RAG的所谓‘AI’应用，并因为这玩意从设计上就不可能有用推广不开而被扣绩效”

在进行ProxyOS施工的同时，我得恶补相关知识，以免自己当牛马后被驯化成牛马，最后因为只能干牛马活而饿死

我正在Practical Deep Learning for Coders - The book上面学习，这属实是个不错的教程——不是学术化地介绍背景、数学证明，而是讲工程应用，这显然很适合我这种没法在学术上有什么作为、时间不够却还想具备相关能力的牛马化的人

规划中

这里是一些我以后准备做的

ANORA后端

目前前端因为ProxyOS项目能用到所以提前开发了，后端到时候再说

OCR翻译器

WindowTranslator是不错，但是其提供的翻译选项过于不自由了，而且其调翻译服务的方式也过于离散，以至于翻译效果不佳。我在考虑做一个结合本地OCR和可插拔翻译后端的工具

OCR分两层：

  • Windows OCR：免费、速度快，负责全屏扫描并返回 bounding box，用于定位文字和判断文字范围，本身识别质量不作要求
  • manga-ocr：专门针对漫画/游戏场景微调的日文 OCR 模型，本地运行，负责对裁出的实际文字区域进行高质量识别

它的工作流程大致是

  • 等待鼠标位置大幅移动后悬停触发
  • 获取屏幕画面
  • 获取指针位置
  • 用 Windows OCR 对鼠标附近小范围做快速检测，判断指针位置是否存在文本
    • 是
      • 用当前屏幕截图的感知哈希（phash）检查是否有缓存
        • 是
          • 将缓存作为翻译结果
        • 否
          • 用 Windows OCR 进行全屏扫描，获取所有文字的 bounding box
          • 根据 bounding box 的空间分布确定翻译范围
            • 默认只翻译鼠标最近的单个 bounding box
            • 如果满足表格行特征（行高一致，同横轴存在另外2-3个底边基本对齐的 bounding box），自动扩展到整行
            • 如果满足段落特征（行宽一致、行高一致、紧密间距），自动扩展到整个段落
          • 用 manga-ocr 对裁出的文字区域进行识别，得到文本
          • 根据设置选择翻译插件，如有必要，翻译插件可以自行集成工具提供的缓存Agent
            • Cloud Translation API（按字符计费，费用低，适合 UI/菜单等短文本）
            • OpenAI接入点（缓存翻译结果，用户可以在界面上配置总prompt，而翻译过程中会连带之前的摘要一起发送，来避免对话中多次翻译缺乏上下文导致理解偏差；适合对话场景）
          • 以 phash 为 key 缓存翻译结果
      • 将结果作为遮罩显示在触发位置
    • 否
      • 结束，开始工作循环

你问我为啥不用MTool或RenpyThief？TMD那个神人作者TMD拿Light.VN做了个TMD超棒的TMD黄油，但套了壳，也根本没考虑国际化，然后俩工具都搞不定，而WindowTranslator翻译没个上下文，翻译结果看上去是根据本地OCR结果翻译得到的，质量很糟糕。Google 有拍照翻译功能，但那个没有公开 API，Cloud Translation 只接受文本。所以更务实的方案是本地用 manga-ocr 做高质量日文识别，再把文本发给翻译服务——OCR 和翻译分开，各用最合适的工具

俺寻思可行，但俺够呛能行

这里主要是一些我的能力看起来足以应对，但肯定有组织比我快，所以没条件以个人开发者身份投入的项目