Hi, 请登录     我要注册     找回密码

闲置手机秒变电脑副屏：Hamzi 直调 NVIDIA/AMD/Intel 编码 SDK，内测送永久授权

分类：未分类 阅读() 评论(0)

开发者发布了一款将手机、平板用作电脑副屏的软件，由桌面端 Hamzi Studio 与移动端 Hamzi Display 组成，现开启限量 100 人的内测招募，内测用户可在正式版上线后获得永久专业版授权。桌面端采用 Qt 构建界面、Swift 编写核心，安装包仅 40MB+；视频编码未使用 ffmpeg，而是直接对接 NVIDIA、AMD、Intel 三家芯片厂商的编解码 SDK，实现显卡直通编码；通过共享内存与 OBS、SIMHUB 插件对接获取画面，支持最高 120FPS 高刷新率传输及系统音频推流。移动端为 Android 原生开发，传输核心通过 JNI 直接对接 USB 数据节点，解码调用 NdkMediaCodec，支持 H.264、H.265、VP9、JPEG 格式，安装包仅 6MB+，兼容至 Android 8.0，同样支持 120FPS 与音频播放，并提供自动横屏与反向媒体控制功能。该软件目前基本免费，仅计划对 OBS、SIMHUB 及媒体播放功能收费，定价待定。后续将推出 iOS、macOS 与 Linux 版本，并已在 iPad 2（iOS 6）上跑通适配。

事件分析

该项目的技术亮点在于绕过 ffmpeg 通用框架、直接调用三大 GPU 厂商编解码 SDK 的路线，可显著降低编码延迟与 CPU 占用；传输层面走 USB 物理链路而非局域网无线投屏，规避了 Wi-Fi 抖动与带宽不稳定问题，配合共享内存采集和移动端直送底层显示管线的优化，构成了一条完整的低延迟视频通路。这类方案将与 Spacedesk、Duet Display 等成熟产品正面竞争，差异化在于极小的安装包体积和对老旧 Android 设备的兼容能力。从产业角度看，个人闲置移动设备数量持续增长，旧设备再利用具备稳定需求，属于绿色计算的一个细分场景；但独立开发者将面临 iOS 审核政策、多平台维护成本与商业化定价的多重考验，后续更新节奏和收费策略将直接影响其生命力。

核心观点：把旧手机变副屏不难，难在直调芯片编码 SDK 的低延迟管线，底层工程能力才是设备再利用工具的真正护城河。

原文链接：V2EX 分享发现

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

相关推荐

抢沙发

评论前必须登录！

立即登录   注册

易安
易安作者
长期关注 AI Agent、软件工程、自动化工作流与个人生产力系统。喜欢把复杂技术拆成普通人也能上手的实践教程,也记录自己在工具链、编程、内容创作和知识管理上的真实折腾。
  • 分享 AI 工具、Agent 工作流与提示词工程的实战经验
  • 记录从想法到产品、从代码到上线的完整实践过程
  • 关注普通人如何用 AI 放大能力,而不是被工具牵着走
阅读作者的全部文章 ›
文章目录

    置顶推荐

    Code80 · AI 编程巴士

    前沿哨所

    • 闲置手机秒变电脑副屏：Hamzi 直调 NVIDIA/AMD/Intel 编码 SDK，内测送永久授权

      开发者发布了一款将手机、平板用作电脑副屏的软件，由桌面端 Hamzi Studio 与移动端 Hamzi Display 组成，现开启限量 100 人的内测招募，内测用户可在正式版上线后获得永久专业版授权。桌面端采用 Qt 构建界面、Swift 编写核心，安装包仅 40MB+；视频编码未使用 ffmpeg，而是直接对接 NVIDIA、AMD、Intel 三家芯片厂商的编解码 SDK，实现显卡直通编码；通过共享内存与 OBS、SIMHUB 插件对接获取画面，支持最高 120FPS 高刷新率传输及系统音频推流。移动端为 Android 原生开发，传输核心通过 JNI 直接对接 USB 数据节点，解码调用 NdkMediaCodec，支持 H.264、H.265、VP9、JPEG 格式，安装包仅 6MB+，兼容至 Android 8.0，同样支持 120FPS 与音频播放，并提供自动横屏与反向媒体控制功能。该软件目前基本免费，仅计划对 OBS、SIMHUB 及媒体播放功能收费，定价待定。后续将推出 iOS、macOS 与 Linux 版本，并已在 iPad 2（iOS 6）上跑通适配。

      事件分析

      该项目的技术亮点在于绕过 ffmpeg 通用框架、直接调用三大 GPU 厂商编解码 SDK 的路线，可显著降低编码延迟与 CPU 占用；传输层面走 USB 物理链路而非局域网无线投屏，规避了 Wi-Fi 抖动与带宽不稳定问题，配合共享内存采集和移动端直送底层显示管线的优化，构成了一条完整的低延迟视频通路。这类方案将与 Spacedesk、Duet Display 等成熟产品正面竞争，差异化在于极小的安装包体积和对老旧 Android 设备的兼容能力。从产业角度看，个人闲置移动设备数量持续增长，旧设备再利用具备稳定需求，属于绿色计算的一个细分场景；但独立开发者将面临 iOS 审核政策、多平台维护成本与商业化定价的多重考验，后续更新节奏和收费策略将直接影响其生命力。

      核心观点：把旧手机变副屏不难，难在直调芯片编码 SDK 的低延迟管线，底层工程能力才是设备再利用工具的真正护城河。

      原文链接：V2EX 分享发现

    • 程序员爸爸用Gemini自制有声水墨地图，让孩子看懂苏轼一生

      一位开发者在V2EX分享了自己历时一个月制作“有声水墨地图”的经历。该项目源于一个具体的家庭教育难题：向孩子讲解苏轼生平时，孩子对“从四川眉山到开封、再贬至黄州、惠州、儋州”的迁徙路线完全没有任何概念。传统科普内容往往用一条红线在地图上简单划过，短短几毫米的直线无法呈现古人数月跋涉、颠沛流离的真实经历，孩子难以共情。作者在视频号刷到“混子哥”（半小时漫画作者）风趣讲解苏轼的视频后受到启发，决定将现代GIS地图与AI技术结合，为古人生平制作一套有声交互地图，让孩子直观感受历史人物的人生轨迹。作者特别称赞了Google的Gemini模型（文中称Gemini 3.8）在垂直工具网站开发中的表现，表示尽管当前网络对各类AI模型评价褒贬不一，但这次用Gemini实际开发垂直工具网站的体验超出预期。该项目技术组合涉及GIS地理信息系统、有声内容与水墨风格视觉设计，属于AI辅助个人开发的典型案例。作者将其定位为“捣鼓出来的小玩具”，但其背后反映的是大模型正在显著降低个人开发门槛：非专业团队也能在一个月内完成融合地图、音频、美术的垂直交互产品，AI编程对个人创意项目的赋能效应可见一斑。

      事件分析

      该案例的技术看点在于大模型对个人开发工作流的改造：作者以单人形式依托Gemini完成前端交互、GIS地图集成到内容组织的开发流程，验证了大模型在垂直工具场景下的可用性。与通用应用不同，有声水墨地图这类项目需求高度个性化、商业价值有限，恰是大模型赋能“长尾开发”的典型场景——传统开发模式下投入产出比过低的产品，如今个人即可低成本完成。产业层面，此类实践反映AI编程工具正从代码补全走向整站级生成，个人创意的落地周期被压缩至周级别。后续走向上，历史人物可视化教育是潜在的规模化方向，若项目迭代为覆盖多位古人的通用模板或开源，可能催生“AI+历史地理”的内容生态。需注意的是，文中提及的“Gemini 3.8”版本命名与Google官方发布节奏存在出入，实际所用模型版本有待核实，但不影响案例本身展示的AI开发能力。

      核心观点：AI编程正在激活长尾创意：那些传统开发ROI过低的小众工具，正成为个人开发者与大模型结合的新试验场。

      原文链接：V2EX 分享发现

    • 开源搜索工具「Win 顺」0.8.0 更新：双击 Ctrl 唤出，挑战 Everything 与 Listary

      开发者在 V2EX 分享了开源 Windows 搜索工具「Win 顺」（WinShun），该项目 10 月 8 日上线，经高频迭代后已更新至 0.8.0 版本，代码托管于 GitHub。工具定位类似 Everything 与 Listary，用户连按两次 Ctrl 即可唤出搜索框，边输入边出结果。文件搜索方面，其宣称三百多万个文件可在几毫秒内完成检索，新建、改名文件可即时被索引，并支持 NAS 及局域网共享文件夹。除文件名搜索外，工具支持检索 Word、Excel、PPT、PDF、WPS 及代码文件内的文字，并标注具体行数与页数；通过插件接入本机 Ollama 模型或自有 API 密钥后，可实现语义搜索，例如用自然语言描述即可找到相关文档，该插件默认关闭。工具全面支持拼音检索与同音字容错，输入拼音缩写即可定位中文文件名，并覆盖软件、系统设置、网页搜索入口。此外，它还集成了资源管理器增强（双击空白处快速切换文件夹）、文件对话框跳转、剪贴板历史（可替代 Win+V，支持搜索图片内文字）、任务栏搜索框替换、文件夹收藏夹等功能。作者表示欢迎用户反馈建议，并通过 GitHub Star 获取更新动力。

      事件分析

      该项目的看点在于将文件名索引、文档全文检索与语义搜索整合进单一快捷入口。语义搜索选择接入本机 Ollama 而非强制云端服务，兼顾了隐私与离线可用性，符合桌面工具对低延迟与数据安全的诉求；拼音与同音字容错则是面向中文用户的差异化细节。值得注意的是，作者提及「opus 和 fable 也快累死了」，暗示开发过程深度借助大模型编程——个人开发者在一周内完成多轮高频迭代，侧面印证了 AI 辅助开发对独立软件生产效率的改变。后续走向上，该项目能否在索引性能、内存占用上与 Everything 等成熟方案抗衡，以及插件生态能否建立，将决定用户留存；作为刚上线的新项目，其稳定性与长期维护能力仍待观察。

      核心观点：AI 辅助开发大幅降低个人造轮子门槛，桌面效率工具赛道的竞争格局正从成熟团队转向独立开发者。

      原文链接：V2EX 分享发现

    • 开源项目 Lexora 更新：游戏化伙伴招募机制上线，多 Agent 协作与 UI 插件能力增强

      开源项目 Lexora 发布新一轮功能更新，核心是引入了伙伴招募机制。该机制借鉴游戏的设计风格，将 AI 协作者划分为主角与 NPC 两类角色，底层由 multi-agent 与 subagent 架构支撑。用户可以新增主角并招募 NPC，由主角负责协作与调度，把任务分派给不同的 NPC 执行，作者同时展示了调度 NPC 时的执行详情界面。在界面层面，Lexora 在内置主题之外开放了插件定制能力，用户可通过插件定制界面外观与功能，个性化空间进一步扩大。作者还给出了一个实际用例：在一次 WebDAV 同步方案研究中，两个 Researcher 角色被并行派出，分别独立检索资料，直观呈现了多智能体分工协作的完整过程。项目代码托管于 GitHub（useLexora/Lexora），此前已在 V2EX 做过一次分享，本次属于迭代更新。整体来看，此次更新将游戏化的角色体系与多智能体编排相结合，并补齐了界面可定制性，使该工具在任务拆解、并行研究与个性化使用方面更加完整。

      事件分析

      用游戏中的角色养成与任务分发来映射多智能体系统，是此次更新最值得注意的设计：主角承担意图理解与调度，NPC 作为可招募的执行单元，与当前 Agent 编排中规划者—执行者分离的主流架构相契合，也降低了普通用户理解多智能体的心智门槛。界面插件化则显示项目正从单一功能工具向平台化方向演进，主题与能力均可扩展。潜在挑战在于：多 Agent 并行会放大 token 消耗与调用成本，角色间任务边界的清晰程度直接决定输出质量；且项目当前知名度有限，插件生态能否繁荣仍有待观察。后续若开放 NPC 角色共享或与主流模型深度适配，有望形成差异化竞争力。

      核心观点：游戏化角色包装降低了多智能体协作的使用门槛，但 Agent 产品的竞争终局仍取决于编排效率与成本控制。

      原文链接：V2EX 分享发现

    • 机场流量被谁偷吃？开发者用 Vibe Coding 搓出 macOS 菜单栏流量账本 Mihomo Monitor

      一位 macOS 用户因机场流量莫名消耗、不清楚被哪个应用占用，基于 Vibe Coding 方式开发了原生菜单栏流量监控工具 Mihomo Monitor，并在 GitHub 开源。该工具采用 SwiftUI 纯原生开发，常驻菜单栏，主打轻量快捷、看一眼就走的使用体验。核心功能包括四点：一是只统计代理流量，自动过滤国内直连，专注出海流量消耗；二是全应用进程归因，无论是 Chrome、终端 CLI 脚本还是 AI 工具，均可自动反查真实进程并匹配 macOS 原生高清图标；三是支持按应用、域名和节点多维度统计，数据存入本地 SQLite（WAL 模式），可随时查看当日、近 7 天及累计数据；四是纯原生质感，接入系统级数字轮盘平滑滚动动效，深浅色模式跟随系统。项目已提供 DMG 安装包直接下载，当前为 v0.1-beta 版本，仅支持 macOS 并适配 Mihomo 内核（基于 Clash Verge Rev 服务模式）。由于作者未购买苹果开发者证书，应用未签名，初次打开需在系统设置的隐私与安全性中手动放行。代码 100% 本地开源运行，作者欢迎社区体验反馈，并计划与 V 友共创支持更多内核。此前站内已有的 clash-traffic 项目主打多机同步与订阅分析，而本作定位为差异化的大窗口替代方案。

      事件分析

      技术层面，该项目是 SwiftUI 在菜单栏轻量工具场景的一次完整实践，涉及进程级流量归因、SQLite WAL 模式本地存储、系统级动效调用等具体实现，对 Mac 端独立开发者有参考价值。开发方式上，作者明确表示借助 AI 辅助完成整个项目，即当下流行的 Vibe Coding 模式，这正是大模型降低个人开发者造轮子门槛的典型样本；同时，本地 Agent 与 AI 工具的日常使用本身也在催生流量监控这类新需求，形成闭环。产品定位上，作者刻意与功能更全的 clash-traffic 拉开差距，走原生、轻量、无窗口路线，印证开发者工具市场中小而美细分品类的生存空间。后续关键在于能否适配 sing-box 等更多内核、吸引社区贡献，以及未签名应用分发门槛的解决程度。

      核心观点：AI 辅助编程大幅拉低个人开发者造轮子门槛，瞄准细分痛点的小而美工具正成为 Vibe Coding 时代的新常态。

      原文链接：V2EX 分享发现

    • Claude把400GB中间文件写进tmpfs：一次AI编程引发的OOM事故

      一名开发者日前在Linux.do论坛发帖，讲述了一次由AI编程助手Claude引发的运维事故。据其描述，当天到达工位时发现服务器发生OOM（内存溢出）宕机，重启后排查卡死前的内存占用记录，发现tmpfs文件系统中被写入了超过400GB的数据。经过与Claude对话确认，问题根源在于Claude在执行任务时，将某个流程中的全部中间文件直接写入了tmpfs目录。由于tmpfs是基于物理内存实现的文件系统，写入的数据会直接占用内存而非磁盘空间，大量中间文件的堆积对服务器内存构成了严重威胁。发帖人表示，幸运的是，真正压垮服务器内存的并非自己运行的程序，当时还有其他人在同一台服务器上运行了一个占用700多GB内存的未知进程，也就是说Claude写入的400GB数据虽然危险，但尚未单独达到撑爆内存的量级。该事件在社区引发了对AI编程工具安全边界的讨论：AI Agent在自主执行任务时，可能做出看似合理但存在系统性风险的决策，例如选用tmpfs这类高性能但容量受限于内存的存储路径，而自身缺乏对底层资源影响的感知与约束。

      事件分析

      这起事件暴露出AI编程Agent在系统层面的认知盲区：Claude选择tmpfs存放中间文件，很可能是出于读写性能的考虑，却忽略了tmpfs直接消耗物理内存的特性，在无人监督的执行过程中埋下OOM隐患。类似的资源类决策还包括随意清理文件、修改系统配置、执行高风险命令等，共性在于AI对’技术正确’与’生产安全’的边界缺乏判断。对工程团队而言，此案例提示AI生成的代码应运行在容器、cgroups资源限额或独立沙箱环境中，并通过权限分级限制其对系统路径的写入。随着Claude Code、Cursor等工具深入工程实践，如何在提升效率的同时建立资源隔离、操作审计与回滚机制，正成为AI编程规模化落地的必修课，也可能催生面向Agent的运维护栏类工具生态。

      核心观点：AI Agent能写代码却不懂敬畏生产环境，沙箱隔离与资源护栏是AI编程从玩具走向生产的安全底线。

      原文链接：Linux.do

    最新文章

    热门专题

    热门标签

    AI编程claude大模型AIAI Agent人工智能开源项目Gemini开发者工具开源GitHubClaude Code开源工具AI工具开发工具谷歌openaideepseek提示词工程cursor网络安全anthropicAI应用ChatgptAI开发agentAI安全自动化智能体AI智能体

    网站统计

    • 日志总数：29084
    • 评论总数：7
    • 标签总数：17919
    • 用户总数：3675
    • 最后更新：2026-10-14