Study-HYK

这次整理博客的起点有点狼狈：网站还能打开，GitHub 仓库也在，但原来的 Hexo 本地工程找不到了。 仓库里留下的不是 Markdown，而是一堆已经生成好的 HTML、CSS 和 JavaScript。换句话说，房子还在，图纸没了。文章在网页上都能看，可我没法正常修改，也没法继续用 Hexo 写新文章。 好在静态网页并不是完全没用。只要文章发布过，正文、标题、日期、标签、分类这些信息大多还藏在 HTML 里。这次折腾下来，我把原来的文章重新整理成了一个能安装、能生成、能本地预览，也能继续发布的 Hexo 工程。 先别动远端刚开始最应该做的事不是重装 Hexo，而是把还活着的静态站点完整留一份。 我把项目拆成了两个目录： 123BLOG/├── hexo-old-web/ # 从 GitHub 拉下来的旧网页└── hexo-source/ # 重新恢复的 Hexo 工程 hexo-old-web 就当现场备份，不在里面直接改东西。后面的解析和转换全部输出到 hexo-source。这样即使恢复脚本写坏了，也不会把仅剩的一份网页覆盖掉。 当时如果直接在原仓库里...

CAD_Converter 是我参与设计和构建的一套 CAD 图纸处理工具。仓库目前是私有的，这里只记录可以公开的技术方案，不涉及内部图纸、模型配置和接口信息。 这个仓库要解决什么问题项目面对的不是单纯的格式转换，而是一批来源、版本和绘图习惯都不统一的工程图纸。使用者需要先把 DWG 转成可处理的 DXF，再按规则清理图层、文字和颜色，最后导出 PNG、PDF 或 SVG。部分图纸还要继续交给视觉模型分析，从中提取设备与连接关系，并把识别结果标回图中。 如果这些步骤各自做成零散脚本，每换一张图就要手动搬文件、改参数，也很难知道失败发生在哪一步。因此我想把它做成一套有界面、能批量运行、能记录进度，也可以直接打包交付的完整工具。 我采用的整体方案我把仓库分成入口、核心能力、界面页面和交付脚本几层。 src/main.py 负责启动 Qt 应用和处理运行期消息；src/gui/main_window.py 组织主窗口，并把功能拆成“格式转换”“图纸清理”“AI 分析”三个页面。页面只负责收集参数、展示预览和反馈任务状态，真正的处理逻辑放在 src/core。 核心层继续分工：dwg_c...

AI_Psyc_Project 是一个私有 Fork 项目。上游提供了初始基础，我参与了当前仓库整套应用的构建设计，并在后续 7 次提交中完成本地模式、模型服务衔接、认证、进度与前后端合并。这里不展开业务数据、提示词和私有模型配置。 这个仓库要解决什么问题项目要把 AI 对话、语音输入、语音输出、过程评估和报告生成放进同一个应用，同时允许使用在线模型与本地模型。除了普通用户的访谈流程，还需要登录、数据保存和管理界面。 难点在于这些能力来自不同运行环境。浏览器负责录音和交互，Next.js 负责页面与服务调用，PocketBase 负责认证和数据，本地 Python 后端还要运行 STT、LLM、TTS 与视觉服务。只把每个接口分别接通，整个访谈仍然可能在模式切换、连接中断或页面刷新时失去状态。 我采用的整体方案我参与把仓库组织为本地 AI 后端、Next.js 前端和 PocketBase 三部分。 FastAPI 后端在启动时初始化 VisionService、STTService、ToneService、BrainService 和 MouthService，分别处理视觉、语...

obs-zoom-to-mouse-zh Fork 自 BlankSourceCode/obs-zoom-to-mouse。我基于上游的核心思路参与了当前中文版本整套脚本的整理与构建，并参考 fixajteknik 的方案处理新版本 OBS 兼容问题。 这个仓库要解决什么问题录制软件操作或代码讲解时，完整桌面里的文字往往太小。这个脚本需要在 OBS 中根据鼠标位置放大显示器捕获画面，并平滑跟随光标；鼠标停下来后还要留出一个安全区域，避免画面一直晃动。 旧版本已经有基础能力，但中文用户面对的是英文设置和英文文档，而且脚本在 OBS 32.0.2 上出现兼容问题。我的目标因此不是只翻译几行文字，而是交付一份在当前 OBS 中能加载、能配置、能缩放，也能按文档排错的中文版本。 我采用的整体方案这个仓库最终保持得很小：一个约 1299 行的 Lua 主脚本、一份中英双语 README 和一个 GIF 演示。代码全部运行在 OBS Script API 中，不额外引入安装器或后台服务。 脚本内部按运行职责组织：平台层从 Windows、Linux 或 macOS 获取鼠标和显示器...

MaixPy-UI-Lib 是我基于 aristorechina/MaixPy-UI-Lib 参与继续构建的轻量级 UI 库。我的工作覆盖组件组织、分辨率适配、页面系统、包结构、示例和文档，其中多项修改通过 PR #2、PR #4 和 PR #7 合并到上游。 这个仓库要解决什么问题MaixPy 设备可以直接在图像上绘制界面，但项目一复杂，按钮命中、滑块状态、页面切换和不同分辨率会反复出现。如果每个应用都在主循环里手写坐标判断，UI 代码很快会和视觉算法、相机处理混在一起。 这个仓库要提供一套适合嵌入式环境的基础 UI：组件足够轻，能够直接绘制到图像；输入事件由管理器统一分发；多页面应用有清楚的进入、退出和返回规则；在不同屏幕尺寸上还能复用同一套设计坐标。 我采用的整体方案我参与把代码整理成标准 src/maixpy_ui 包。components 下分别放按钮、滑块、开关、复选框和单选框，每类组件都有对应管理器；core/resolution_adapter.py 负责设计分辨率到设备分辨率的换算；core/ui_manager.py 定义 Page 与 UIMana...

MaixCam_Tic_Tac_Toe_2024 是我为 2024 年电赛 E 题参与设计和构建的井字棋机器人。仓库里的相机视觉、棋盘状态、博弈决策、交互界面和串口控制共同组成一套完整系统，不是只训练了一个棋子检测模型。 这个仓库要解决什么问题机器人要在真实棋盘上与人对弈。它必须找到棋盘和棋子，判断对手本轮新增或移动了哪颗棋子，计算自己的落点，再控制 XYZ 三轴滑台完成取棋和落子。不同游戏模式还需要在屏幕上选择、显示和复位。 这里任何一层出错，最后都会表现成“机器人下错了”。视觉识别正确但坐标映射偏了，机械臂仍会落错；Minimax 计算正确但棋盘状态读错，决策也没有意义。因此我从一开始就按感知、状态、决策、控制和交互五部分组织方案。 我采用的整体方案相机感知使用传统计算机视觉与 YOLOv5 组合。OpenCV 负责规则明确的棋盘轮廓、透视校正和九宫格定位，YOLO 处理背景变化更大的棋子。模型文件和 MUD 配置随仓库保存，MaixCam 可以直接加载推理。 感知结果不会直接变成串口命令，而是先转换成统一棋盘数组。BoardChangeDetector 比较前后两次稳定状态...

Scoliosis-AI-Analysis 是我参与设计和构建的脊柱侧弯辅助分析原型。我的工作覆盖数据转换、模型训练、关键点推理、Cobb 角算法、结果可视化、报告接口和 Gradio 应用，目标是验证一条从 X 光图像到可复核测量结果的完整路径。 这个仓库要解决什么问题脊柱侧弯评估需要在 X 光图像中确定椎体方向并测量 Cobb 角。人工测量依赖专业经验，重复操作也会产生差异。这个项目尝试自动定位椎体关键点，再用明确的几何方法计算角度，并把测量依据画回图像。 我没有把目标设成“上传图片后直接给出诊断”。模型输出必须能被检查，角度计算要能追溯，生成式报告也只能整理测量结果。仓库因此更适合作为辅助分析原型和研究验证。 我采用的整体方案整套代码按数据、模型、测量、报告和界面组织。 数据层把原始 .mat 标注转换为 YOLO Pose 格式，将 17 个椎体表示为 68 个关键点，并生成训练、验证、测试拆分和数据集 YAML。train_model.py 负责 YOLOv11-Pose 训练，训练结果、曲线和权重保存在仓库中；yolo_detector.py 封装推理与关键点输出。 ...

KanResNet-Modulation-Recognition 是我参与设计和构建的一套无线信号调制识别实验。项目参考 isaaccorley/pytorch-modulation-recognition 的训练流程，并使用 IvanDrokin/torch-conv-kan 的 KAN 卷积实现。在这些基础上，我把数据、ResNet/KanResNet、训练、评估、预测和交互界面组织成可比较的完整仓库。 这个仓库要解决什么问题调制识别需要根据 I/Q 信号判断调制方式。RadioML2016.10a 同时包含多种调制类别和不同信噪比，低 SNR 下有效特征容易被噪声淹没。 我想验证引入 KAN 卷积后的 KanResNet 在这项任务中会有什么表现，但只训练一个新模型无法说明问题。必须保留一个稳定 ResNet 基线，让两者使用相同数据与训练条件，再按信噪比查看结果。 因此这个仓库解决的不只是“实现 KanResNet”，还要建立一套公平、可复现并能回到具体样本的对比流程。 我采用的整体方案torch_modulation_recogn...

PowerBox 是我参与设计并完成整体构建的一款效率工具。它使用 Python 和 Flet，把 Todo、番茄钟、倒数日、主题设置和坚果云 WebDAV 同步放进同一个应用。 这个仓库要解决什么问题我平时需要记录待办、专注时间和重要日期，但不想在几个小工具之间切换。我希望做一个统一入口：打开后可以进入不同功能，数据退出后仍然保留，有需要时还能通过坚果云在不同设备间同步。 这也是我第一次尝试把一个应用从界面做到本地存储和网络同步。三个功能需要共享主页、设置、生命周期和数据目录，作为同一个应用运行。 我采用的整体方案应用以 Flet 为 UI 框架。main.py 和 web.py 提供启动入口与应用外壳，HomepageButton 组成主页导航，AnimatedSwitcher 在主页、Todo、番茄钟和倒数日之间切换。设置对话框管理主题、坚果云账号与同步操作。 三个业务模块各自独立：todo.py 定义任务与任务列表，pomo.py 负责计时、暂停、继续和统计，countdown.py 管理日期任务，datePicker.py 提供日期选择。各模块实现自己的 load() ...

最早整理这篇笔记时，我存了很多别人的书评和摘录，后来越堆越长，反而看不出自己读完留下了什么。重新整理后，我只想回答一个问题：保罗·肯尼迪怎样解释大国的兴起与衰落，这套解释今天还有多少参考价值？ 《大国的兴衰》讨论的是 1500 年以后各主要国家之间的力量变化。它不是把历史写成几位统治者的胜负故事，而是反复比较生产、财政、技术和军事之间的关系。国家可以在一场战争中获胜，也可能因为长期支付战争成本而变弱。书里最让我记住的不是某个结论，而是这种看问题的尺度。 军事力量背后是一张账单军队和舰队不会凭空出现。造船、火炮、补给、交通和士兵薪饷，最后都要落到税收、信贷和生产能力上。一个国家短期内可以借债扩军，甚至连续赢得战争；时间拉长以后，财政是否撑得住，往往比某次战役更重要。 西班牙和哈布斯堡王朝就是书里反复出现的例子。美洲白银、辽阔领地和王朝关系让它看起来资源雄厚，但需要防守的方向也太多。地中海、低地国家、德意志地区以及同法国的竞争，把军费和债务不断推高。财富流入并没有自动变成更稳定的税制和生产能力，庞大的战略目标反而越来越难以维持。 荷兰与英国走的是另一条路。它们同样打仗，却更善于把商业...