开源huashu-mac-use：AI Agent轻松搞定Mac办公与3D建模
近期在社交平台上看到不少关于新一代AI模型在电脑操控领域的演示案例，其中借助Blender生成高精度3D模型的内容让人眼前一亮，但我也意识到，这类纯视觉点击交互的方式在实际办公场景中仍存在不少局限。对于多数白领来说，日常工作大多依赖电脑和浏览器完成，而不少软件和网站的开放性不足，因此让智能代理能够自主操控电脑来获取更全面的上下文信息，完成任务的最后一环，其实是打通智能办公闭环的关键一步。
笔者在过去半个月里，一直在优化智能代理的电脑操控能力，以下是用Claude Code借助相关工具完成的两个实际案例，能直观体现这套方案的效果。
第一个案例是10万吨级邮轮模型的制作。笔者给Claude Code的指令只有一句话：调用生成高清的10万吨级邮轮参考照片，再通过工具操控Blender生成与照片高度一致的渲染模型。整个流程从接收任务到交付对比图仅用了33分钟：首先生成正侧视图作为基础参考，再依次生成右前45°、左后45°和航拍俯视三张视角一致的照片；随后根据照片尺寸参数，在Blender中编写了约400行的参数化建模脚本，用超椭圆截面放样船体，将10层上层建筑按像素换算为实际尺寸逐层搭建，还原了阳台凹槽、救生艇、烟囱、穹顶、桅杆和驾驶台翼等细节；最后按照四张照片的机位和太阳方位完成四视角渲染。
整个过程共迭代了8轮，每轮预览仅需3到30秒。最终的渲染效果和参考照片仍有细微差距：驾驶台前端的流线型外壳、船艉阶梯露台的栏杆、顶层泳池区没有还原，航迹仅为薄片没有浪花，海面纹理也相对平整。这些不足都是智能代理在收尾汇报中主动列出的。
另一个案例是高精度甜甜圈模型的制作。智能代理不仅还原了面团气孔、油炸时留下的浅色腰线、半截淋面和滴落的巧克力酱，还添加了三百颗随机颜色的糖针、盘子上的碎屑，甚至虚化了背景中的第二个甜甜圈。渲染完成后，笔者还让它设置了120帧的相机关键帧，完成了一镜到底的动态展示。
这套工具目前已经正式开源，项目名为huashu-mac-use，仓库地址为：https://github.com/alchaincyf/huashu-mac-use。任何支持skill格式的智能代理都可以安装，包括Claude Code、Codex、Kimi Code、Cursor、OpenClaw以及国内多款办公客户端，安装方式也非常简单，只需将仓库链接发送给智能代理，告知“帮我安装这个skill”即可。
设计核心原则
和新一代AI模型直接通过屏幕点击操控Blender的方式不同，这套工具采用了更高效的路径：借助Blender自带的Python接口和无头命令行完成建模、材质、灯光和渲染，全程不需要手动点击坐标，仅在最后打开GUI截取窗口作为取证时才涉及界面操作。这并非投机取巧，而是这套工具的第一条核心原则：能不依赖视觉截图就不依赖，能不用鼠标点击就不用。
虽然新一代AI模型的能力已经大幅提升，但仍有三个基础问题需要提前解决：如何确定一个应用的最佳操控路径、如何避免干扰用户的正常操作、如何为每一步操作留下可复现的证据。这套工具正是围绕这三个问题展开设计的。
核心工作流程
这套工具的工作逻辑可以概括为三件核心事：
第一步：先探测，再确定操控路径。Mac上的应用可以分为四层可操控维度：自带命令行或脚本接口、支持视障辅助功能树、可通过坐标点击交互、最后才依赖视觉截图。层级越高的操控方式越稳定高效，越低则越接近手动点击的低效模式。因此工具在运行前会先执行30秒的探测脚本，快速摸清应用的可用接口。以Blender为例，探测后发现其辅助功能树为空，但自带完整的Python接口，因此全程无需手动点击，直接通过脚本完成所有操作。笔者最初没有做探测直接尝试，浪费了20分钟的时间，这个步骤也是从多次踩坑中总结出来的。
不同内核的应用，操控方式差异极大：国内多款AI办公客户端都是基于Chromium套壳开发的，这类应用可以通过调试端口直接操控，不需要抢焦点、切换桌面，甚至可以同时运行多个代理而互不干扰。笔者最初误将豆包工作判断为原生应用，通过坐标点击尝试后才发现它的Chromium内核藏在深层目录中，顶层接口为空；千问办公的辅助功能树看似支持输入，但实际发送键无法激活，输入内容不会被编辑器识别。另外，后台截图的成功率和应用内核无关，比如剪映的主窗口可以正常后台截图，但版本更新的弹窗却无法捕获，这一点也需要通过探测来确认。
第二步：优先读取而非写入，避免抢占用户焦点。截图、列出窗口、读取界面状态都属于读取操作，工具在执行这类操作时不会激活窗口、切换桌面或移动鼠标，即使窗口被遮挡也能正常截取。比如邮轮案例中的Blender窗口截图，就是通过在其他桌面启动Blender实例，后台截取完成的，期间笔者在另一个窗口打字完全没有受到干扰。工具还会自动调整应用的初始状态：比如Blender默认打开时无法直接看到船体，工具不会手动调整视角，而是修改配置文件让每个视口默认显示相机视角和材质预览，再保存使用。
写入操作则相对复杂，后台窗口无法直接接收键鼠输入，因此工具会先尝试直接向应用进程发送事件，通过截图对比确认是否生效，若失败才会尝试抢占焦点。抢占焦点前会经过四道验证：当前前台是否为目标应用、点击落点是否被其他窗口遮挡、如果用户在2秒内有键鼠操作则最多等待15秒后再执行、全局同时只允许一个进程抢占焦点。这套规则参考了行业的最佳实践，核心是避免干扰用户的正常工作，当用户正在打字时，工具会自动暂停等待。当真正抢占焦点时，屏幕四角会显示取景框提示，但这个框不会出现在取证截图中，避免影响效果。另外，工具会拒绝跨桌面的点击操作，避免出现点击误触到当前使用的终端窗口的问题。
第三步：工具反馈成功不算数，必须验证实际状态。曾有一次写入操作连续四次返回成功，但截图后发现前三次输入框都是空的。因此工具要求每一步操作都必须回读实际状态，比如确认发送键是否亮起、任务是否进入列表、文件是否成功保存，仅看到界面文字是不够的。比如关闭系统蓝牙的测试中，同一个坐标点了三次却得到三种结果：第一次坐标错误点到角落、第二次坐标正确但后台窗口无法接收事件、第三次激活窗口后才成功关闭，三次的系统反馈却完全一致。现在工具会在每次操作后自动对比前后状态，无法判断时会标记“返回重查”，既不算成功也不算失败。即使是生成文件的操作，工具也不会只相信脚本反馈，而是会直接检查生成目录中的新增文件来确认结果。
迭代进化逻辑
这套工具的价值不在于单一的命令，而在于将踩过的坑转化为可自动执行的工具逻辑。最初的版本仅用三天完成，正文近两万字，全部是踩坑记录。第二天笔者让Claude Code以产品负责人和架构师的视角评审，得到的结论是：核心思路正确，但形态更像一本日记而非可用接口，所有的经验都写在提示词里而非工具代码中，操作时需要智能代理手动计算坐标、遍历DOM、判断截图失败的原因，有一次为了截取9张图片发送了76条指令，效率极低。
评审后确定了四个核心优化指标：将每张有效截图的模型交互次数从8次压缩到2次以内；将三款旗舰应用的首次截图成功率从1/3提升到3/3；确保读取操作不会占用用户焦点；将正文从19.8k字符压缩到6k以内。当天就完成了重构：内核自动换算坐标，智能代理无需再做乘法计算；自动诊断截图失败的原因并切换截取兄弟窗口；辅助功能树检查增加两次验证；拒绝跨桌面写入操作；支持通过中文名称启动应用。重构后的正文压缩到4.8k字符，所有踩坑记录都被迁移到参考文档中，没有丢失任何细节。
之后的迭代遵循一个核心规则：每次收尾时先判断“这条踩坑经验能否转化为工具行为”。如果可以，就修改工具代码而非文档；如果不能，则加入参考文档，且单个应用的观察仅保存在对应应用的档案中，至少在两个不同应用上复现的经验才能升级到通用文档。坐标、端口、窗口ID、界面文案这类易随产品版本失效的信息，永远不能作为通用结论写入文档。证伪旧结论的优先级高于新增内容，错误的记录会导致后续操作走错路径，比没有记录更糟糕。
以邮轮案例的收尾汇报为例，四条踩坑经验被当场写入Blender的应用档案：后台模式新建材质时需要显式创建默认节点，否则会出错；海面变白的原因是Ocean修改器的foam属性而非反射参数，此前两轮调整都方向错误；天空模型的太阳方位角约定需要通过小批量测试确认，最终通过4张480×270的小图在30秒内完成验证，确认0度对应+Y轴、90度对应-X轴；还有一条推翻了原有结论：通过`open -g`启动的Blender窗口在其他桌面也能后台截图，此前文档认为未渲染的窗口无法截取。这类实验比查阅文档更高效，30秒的测试就能得到准确结果。8轮迭代每次仅修复一个根因，而根因往往不是表面看到的问题：第一次渲染全黑是曝光参数错误而非灯光问题，第二次海面像镜面是因为Ocean修改器上叠加了6000倍的物体缩放而非材质问题。每轮3到30秒的预览让试错成本极低，这也是通过脚本接口操控相比GUI点击的最大隐性优势：可以像开发代码一样快速迭代。
这和笔者此前在培训中分享的思路一致：笔者并不打算开发新的智能代理框架，目前主流厂商的框架已经足够完善，我们需要做的是优化代理运行的环境、传入的规则和专属技能。这套工具属于两个核心技能之一：huashu-chrome可以让智能代理使用用户的Chrome浏览器并保留登录态，huashu-mac-use则用于操控没有公开API的原生Mac应用。
收尾与展望
回到最开始看到的那些演示案例，比如关于新一代AI模型在Blender和三维推理领域的高赞内容，以及用专业图纸让模型重建出大量可编辑物件的案例，这些成果确实令人振奋。这套工具终有一天会被新一代AI模型的原生能力完全覆盖，可能就在几个月之后，但笔者认为在那之前，先为大家提供一个实用的工具是有价值的。而且根据相关论文的测试，纯视觉点击的操控方式在Mac系统上的成功率仅为四成多，仅为Ubuntu系统的一半，因此“按应用内核选择最优操控路径”“不干扰用户操作”“保留可复现证据”这三个核心逻辑，在模型层完全解决之前，仍需要通过工具层来补充落地。
欢迎大家通过国内的办公类应用测试这套工具，包括WorkBuddy、豆包工作、千问办公、ZCode、Kimi Work等支持skill格式的客户端，相信都能得到不错的效果。如果在使用中遇到问题，可以直接到仓库提交issue，毕竟笔者一个人无法覆盖所有应用的测试场景。
