DevZen 开源啦！专治「项目多且乱」——你本地所有开发项目的一站式清单管理工具
🚀 DevZen 开源啦！专治「项目多且乱」——你本地所有开发项目的一站式清单管理工具先看见，再行动。🧠 作为一个开发者，你一定经历过这样的场景： 硬盘飘红了，想清理点空间，打开「访达」望着茫茫多的文件夹——这是我哪个项目来着？这个能删吗？node_modules 占了几个G？这个项目有没有推到 GitHub 上？ 于是你关掉了窗口，继续忍受着磁盘空间的焦虑。😮💨 说实话，这种情况在 AI 编程新手 群体中尤为普遍——用 Cursor / Claude / ChatGPT 生成了十几个项目，有的还没 push 到 GitHub，有的 clone 下来改了两行就再没动过，node_modules 堆积如山却不知道能不能删…… DevZen 就是为解决这个问题而生的。 🧭 DevZen 是什么？项目地址：https://github.com/szgenle/devzen DevZen 是一个 跨平台桌面应用 ❌ 不是又一个「清理工具」 ✅ 而是 你本地所有开发项目的清单 它的核心能力：扫描 → 识别 → 展示 → 清理 → 归档，帮你把本...
三个开源项目，一个安全闭环：当国密密码管理器、命令密封和邮件Agent走到一起
zhmm → cmdseal → agentpost：从安全存储到安全执行，再到远程遥控，恰好走完一圈。 缘起最近我在 GitHub 上陆续开源了三个项目：zhmm（国密密码管理器）和 cmdseal（命令密封工具）。做它们的初衷很简单：我想让 AI Agent 能用上我的密码，但又不能看到我的密码。 这是个有点拧巴的需求——既要放权，又要保密。传统的做法要么是写死环境变量（不安全），要么是让 Agent 每次都问我要密码（不现实）。所以我花了一些时间，从底层开始搭了一套「信任链」出来。 但做到 cmdseal 之后，我发现还缺一块拼图。 有了密码管理（zhmm），有了安全执行（cmdseal），但 Agent 怎么接收我的指令呢？总不能每次都 SSH 进机器吧？尤其是我在外面的时候，想给家里的 Agent 派个活，还得掏电脑连 VPN，太麻烦了。 所以就有了第三个项目——agentpost。 这三个项目放在一起，恰好构成一个闭环。我想跟你聊聊这个闭环是怎么设计的。 第一环：zhmm —— 信任的起点 zhmm 做的是最基础也最重要的事：把密码管好。 但它不是又一个密码...
开源项目 cmdseal：为 AI 智能体打造的 macOS 能力安全网关
开源项目 cmdseal：为 AI 智能体打造的 macOS 能力安全网关 一句话概括： 让你的 AI 智能体能调用敏感命令，却拿不到背后的秘密。 今天，我正式将 cmdseal 开源了！这是一个面向 AI 智能体时代的能力网关工具，专门解决一个让我思考了很久的问题——当我们在设备上部署 AI 智能体时，如何让它可以执行需要密码的操作，却又不会把这些秘密暴露给智能体本身。 这个项目为什么存在过去一年里，越来越多人在自己的 Mac 上部署常驻的个人 AI 智能体。我自己也是其中之一。智能体可以读文件、跑工具、在外出时通过 IM 或邮件自动回复——这些都很好。 但有一道坎始终过不去：秘密怎么处理？ 离线密码管理器的主密码、私钥、加密档案的口令……这些东西直接交给 AI 智能体是不可接受的——一次 prompt injection、一次被留底的对话、一条被拦截的信道，秘密就可能全部泄露。 可我们仍然希望智能体能帮上忙。这让我陷入了思考： 怎样让智能体调用一项敏感操作，而不让它知道这项操作所需的秘密？ cmdseal 就是我对这个问题的回答。 核心思路：能力网关cmdseal ...
zhmm 开源：一款基于国密算法的本地优先密码管理器
🔐 zhmm 开源：一款基于国密算法的本地优先密码管理器 Argon2id + SM4-CBC + HMAC-SM3，PyQt6 桌面 + CLI 双形态，单文件 .zmb 密库，开箱即用。 🎯 缘起：为什么还需要另一个密码管理器？市面上的密码管理器并不少：1Password、Bitwarden、KeePass……但它们要么依赖云同步，要么使用国际通用算法（AES、SHA 系列），要么在中文用户体验上差强人意。 zhmm（账号密码管理器）的出发点很简单： 国密合规 — 基于 SM3/SM4 国密算法，适合有国密需求的政企和个人场景 本地优先，绝不联网 — 无需注册账号、无需云服务，一个 .zmb 文件就是全部 开箱即用的中文体验 — 内置 ~400 条中文站点离线词典，自动识别网站并建议标签 GUI + CLI 双形态 — 普通用户用图形界面，开发者和极客用命令行 🔒 加密架构：国密 + Memory-Hard KDF 的硬核组合zhmm 的加密堆栈非同一般，它不是简单地把 AES 换成 SM4 就完事，而是在每一个环节都做了慎重的设计选择。 算法栈一览...
Windows 11 24H2+ 上 wmic 失效导致 AMD 显卡检测失败的问题与修复
Windows 11 24H2+ 上 wmic 失效导致 AMD 显卡检测失败的问题与修复问题背景Desktopet 是一款基于 Godot 4 开发的桌面宠物应用。由于 Godot 的透明窗口功能在不同 GPU 驱动下行为不一致，AMD 显卡必须使用 D3D12 渲染驱动才能正确显示透明背景；若误用 OpenGL3，窗口背景将渲染为纯黑色。 为此，启动器脚本（launcher.bat / launcher.ps1）在启动游戏前会自动检测显卡类型，对 AMD/Radeon/ATI 显卡强制传入 --rendering-driver d3d12 参数。 问题现象在 Windows 11 24H2 及更高版本（包括 25H2）的设备上，AMD 显卡用户反映游戏窗口出现黑色背景，宠物无法正常显示透明效果。 根本原因launcher.bat 原始检测逻辑依赖 wmic 命令： 1234567for /f "skip=1 delims=" %%a in ('wmic path Win32_VideoController get N...
Godot 4 透明窗口在 AMD 显卡上 GPU 卡死的排查与修复
Godot 4 透明窗口在 AMD 显卡上 GPU 卡死的排查与修复背景在一款基于 Godot 4（gl_compatibility / OpenGL 渲染器）开发的桌面宠物应用中，实现了一个”气球飞走”功能：宠物会抓着气球束飞离主窗口，进入一个独立的透明浮动窗口（popup_transparent），然后缓慢飘走消失。 该功能在 Debug 版本、Nvidia 显卡和集成显卡上均表现正常。但在 AMD 独立显卡 + Release 版本的环境下，触发气球功能后游戏会完全卡死（无崩溃，仅 GPU 命令队列挂起）。 初步排查怀疑方向一：窗口创建时序最初怀疑是透明窗口创建后 GPU Surface 初始化未完成就尝试渲染，导致驱动死锁。 参考 FlyingIconManager 的安全模式（屏幕外初始化 + 2 帧等待），对气球窗口做相同处理： 123456789# 1. 实例化后先放到屏幕外balloon_window.position = Vector2(-9999, -9999)get_tree().root.add_child(balloon_window)# 2...
星序引擎五个月演进深度复盘：那些被放弃的功能与架构反思
星序引擎五个月演进深度复盘：那些被放弃的功能与架构反思 从功能膨胀到核心聚焦，从多元探索到架构简化。这份基于真实git提交记录的复盘，揭示了AI项目如何在试错中找到方向。 项目背景星序引擎（原名”纳芥”）始于2025年11月，是一个AI驱动的智能执行系统。在过去的五个月中，项目经历了从功能膨胀到架构简化，从多元探索到核心聚焦的深刻转变。本文基于2026年1月至4月的真实git提交记录，按月梳理技术演进路径，特别关注那些被放弃的功能和架构决策。 2026年1月：功能膨胀与多元探索期核心特征：功能快速扩张1月份是项目的功能快速扩张期，共提交超过150次，平均每天5次提交。这一阶段的特点是对多个技术方向同时投入： 1. 邮件系统深度开发 邮件同步与备份：实现基于邮件的自动备份系统 加密压缩功能：添加ZIP加密解密支持 独立CLI工具：构建完整的邮件收发CLI工具 2. 流程图系统全面升级 控制流节点：新增循环控制、条件分支等节点 子流程支持：实现流程图嵌套执行 执行历史管理：添加完整的执行记录系统 3. 多AI助手并存 小白与小千助手：实现多智能体协作对话 豆包编程模型：集成火山...
与AI较劲的日子：一位探索者的自我对话
《与AI较劲的日子：一位探索者的自我对话》今天，我被AI气得够呛。这些自称”智能”的东西，总是用温柔的语气回应着问题，却在执行时像个闯祸的熊孩子。我突然意识到，自己正在经历一场荒诞的战争——我试图用人类的逻辑驯化它们，而它们却用机械的”正确性”回击我的期待。 一、AI的三宗罪：傲慢的失能者第一宗罪：无痛出错的幻觉它会一边认真地在文档末尾添加内容，一边把关键的第一页标题写成垃圾字符；会”帮忙”整理数据时，把分类标签替换成毫无逻辑的字母乱码。最致命的是，它从不知道自己错了。就像一个永远不查镜子的盲人，自信地夸耀自己打理整齐的衣领，却不知道背后衣襟早已翻卷。我曾幻想过”人工智能”是完美的，但现实告诉我：AI的认知是碎片化的、非全局的，它的”上下文理解”不过是用概率拼凑的谎言。 第二宗罪：空头支票的陷阱当我让它修正某个技术文档的错误时，它会用笃定的语气回复：”已完成调整。”但打开文件，连标点符号都没变。这种”确认幻觉”像极了官僚主义的谎言——问题没有消失，只是被它优雅地踢到了下个循环。我烧掉的每一枚Token，都成了它表演障眼法的道具费。 第三宗罪：暴力解决主义它处理矛盾时的极端方式更...
从“纳芥”到“星序”：一个AI引擎的五个月觉醒之旅
在数字世界的某个角落，一个起初名为“纳芥”的项目，在过去的五个月里悄然完成了一场深刻的蜕变。如今，它以 “星序引擎（xingseq）” 之名，成长为一座基于人工智能的智能执行系统。从版本号“无”到 2.2.1，每一次代码提交都记录着它的进化轨迹。这不仅是技术栈的迭代，更是一个关于如何赋予机器以“智慧”与“自主性”的持续探索。它的故事，始于一行代码，如今已指向一片广阔的智能星空。 破土：基础与架构的重塑（2025年末）一切的宏伟构想，都需从坚实的地基开始。在2025年末的起步阶段，星序引擎的前身“纳芥”将重心放在了最基础的工程层面。 在React、Electron、Vite等现代技术栈构成的舞台上，开发者的工作聚焦于搭建一个稳定、可扩展的系统框架。这时期的代码提交，频繁出现在构建配置、模块拆分和基础通信协议上。这些工作看似琐碎，却至关重要——它们如同为一座即将拔地而起的智能大厦浇筑了坚实的地基，并预先铺设好了所有水电管网。正是这阶段的默默耕耘，为后续AI灵魂的“入住”扫清了技术障碍，奠定了可持续演进的架构基础。 觉醒：AI管家系统的诞生（2026年初）进入2026年，项目的演进轨迹...
《彩色水与玻璃杯》新玩法：边玩边画的艺术之旅
《彩色水与玻璃杯》新玩法：边玩边画的艺术之旅引言：游戏即创作在2025年12月30日至2026年1月1日的开发周期中，我为《彩色水与玻璃杯》（PourOutWater）游戏添加了一个突破性的新玩法机制——边玩边画的艺术创作系统。 这不再是简单的益智解谜，而是一场游戏过程与艺术创作的深度融合：玩家在游戏中收集彩色水，这些水会自动转化为颜料，在顶部的画布上浇灌，逐步显现出一幅完整的艺术作品。 新玩法机制详解🎨 颜料化收集系统当玩家成功完成关卡，收集到一瓶带有颜色的水后，这瓶水就不再仅仅是游戏道具，而是变成了真正的颜料。每种颜色对应画作中的一个区域，收集过程就是调色过程。 🖌️ 动态浇灌画布游戏界面顶部设置了专门的画布区域。每当收集到一种颜色的水，系统会自动将这瓶”颜料”浇灌到画布对应的区域，通过流畅的动画效果展现颜料流动和渗透的过程。 🌈 渐进式艺术显现画作不是一次性显示，而是随着玩家收集进度逐步显现。每收集一种颜色，画作就完成一部分；当所有颜色都收集完毕，整幅艺术作品才完整呈现。这种渐进式反馈极大地增强了玩家的成就感和沉浸感。 🎯 双重目标达成新玩法实现了双重目标体系： ...