我有好多想干的事,但是……
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 缓存翻译结果
- 是
- 将结果作为遮罩显示在触发位置
- 用当前屏幕截图的感知哈希(phash)检查是否有缓存
- 否
- 结束,开始工作循环
- 是
你问我为啥不用MTool或RenpyThief?TMD那个神人作者TMD拿Light.VN做了个TMD超棒的TMD黄油,但套了壳,也根本没考虑国际化,然后俩工具都搞不定,而WindowTranslator翻译没个上下文,翻译结果看上去是根据本地OCR结果翻译得到的,质量很糟糕。Google 有拍照翻译功能,但那个没有公开 API,Cloud Translation 只接受文本。所以更务实的方案是本地用 manga-ocr 做高质量日文识别,再把文本发给翻译服务——OCR 和翻译分开,各用最合适的工具
俺寻思可行,但俺够呛能行
这里主要是一些我的能力看起来足以应对,但肯定有组织比我快,所以没条件以个人开发者身份投入的项目
- 娱乐形人造天使
- 通过外接LLM+本地部署知识图谱+浏览器插件(及其他信息源)+MCP,形成一个可以看用户所看、想用户所想、和千禧年人们幻想中一样的的智能助理~~(电脑老婆)~~
- 相关备忘