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)游戏添加了一个突破性的新玩法机制——边玩边画的艺术创作系统。 这不再是简单的益智解谜,而是一场游戏过程与艺术创作的深度融合:玩家在游戏中收集彩色水,这些水会自动转化为颜料,在顶部的画布上浇灌,逐步显现出一幅完整的艺术作品。 新玩法机制详解🎨 颜料化收集系统当玩家成功完成关卡,收集到一瓶带有颜色的水后,这瓶水就不再仅仅是游戏道具,而是变成了真正的颜料。每种颜色对应画作中的一个区域,收集过程就是调色过程。 🖌️ 动态浇灌画布游戏界面顶部设置了专门的画布区域。每当收集到一种颜色的水,系统会自动将这瓶”颜料”浇灌到画布对应的区域,通过流畅的动画效果展现颜料流动和渗透的过程。 🌈 渐进式艺术显现画作不是一次性显示,而是随着玩家收集进度逐步显现。每收集一种颜色,画作就完成一部分;当所有颜色都收集完毕,整幅艺术作品才完整呈现。这种渐进式反馈极大地增强了玩家的成就感和沉浸感。 🎯 双重目标达成新玩法实现了双重目标体系: ...



