OpenCowork 实测:支持本地文件、飞书机器人的 Windows AI 助手(只需配置 Token)

目的

找一款window 本地ai助手,但有如下要求 1)windows一键安装,带gui界面,操作简单 2)直接操作本地文件,能生成和写入本地文件内容 3)配置token 即可,无需绑定账号登陆 

测试效果

OpenCowork 可直接操作本地电脑文件,并支持接入飞书机器人应用,实现类似 OpenClaw 的电脑操作能力;
但整体更适合本地文档生成、资料整理、代码或文本批量处理等场景。相比云端 AI,在生成速度、工具能力和复杂任务支持方面仍有差距,尤其在长文档生成和多工具协作时效率与稳定性较弱,因此更适合作为本地文件处理的辅助工具,而非替代云端 AI。

OpenCowork 很多自动化能力依赖python,你可以自己升级一下python,然后让OpenCowork 检测环境是不是最新的,并升级一下;

1 安装 OpenCowork 客户端

下载地址
https://github.com/AIDotNet/OpenCowork
找右侧侧 releases ,我这里是x64 所以下载amd

在这里插入图片描述


默认安装,换成磁盘路径,安装后客户端如下图

在这里插入图片描述

2 配置 token

点击左上角用户头像,点击头像下的设置,弹窗如下图,一直脱到最下面
输入打开完整版设置

在这里插入图片描述


选择模型,输入模型的api Key;联通性选择选择你使用的模型,点击检测即可
到这里配置完成,点击左侧工具栏的对话框,开始实际操作

在这里插入图片描述

3 测试

3.1 选择工具要操作的路径

最好选择一个只跟工作内容相关的干净的文件夹,并把需要的资料移入进文件夹内
这里历史测试:用桌面

在这里插入图片描述

3.2 测试功能

1)联网框的联网搜索,可根据实际情况选择启用和关闭

在这里插入图片描述


2) 输入后开始工作

在这里插入图片描述


3)测试效果
生成3页 word 5分钟,但也能接受(毕竟含网页搜索);豆包测试室1分钟(立马输出,1分钟生成完);
效果还算可以,毕竟花钱用token了;这种工具严重依赖于本地的skill,且本地生成速速远低于云厂商;毕竟你的能力是ai 工具能力 是低于云端AI服务。

在这里插入图片描述

4 添加skill

如下图:点击获取skill,会跳转至下拉地址https://skills.open-cowork.shop/dashboard,把获取的 skill 粘贴如下位置,点击发送请求

目前不推荐安装其它skill 日用满足,因为现在有skill 投毒问题

在这里插入图片描述

下面为再次申请skill的地址

在这里插入图片描述

5 app 聊天接入

这里试了企业微信,因为需要:WS 中继地址,就没做深入的研究;飞书测试成功了;

聊天频有 Feishu Bot 、DingTalk Bot 、WeCom Bot、QQ Bot、Telegram Bot、 Discord Bot 、WhatsApp Bot , 目前不确定哪个不需要内网穿透 or 公网ip就能用; 

5.1 接入飞书

5.1 创建应用

在这里插入图片描述
在这里插入图片描述

5.2 应用添加机器人能力并导入权限

如下图:添加机器人能力,然后点击菜单的权限管理: 导入权限如下

{ "scopes": { "tenant": [ "aily:file:read", "aily:file:write", "application:application.app_message_stats.overview:readonly", "application:application:self_manage", "application:bot.menu:write", "contact:user.employee_id:readonly", "corehr:file:download", "event:ip_list", "im:chat.access_event.bot_p2p_chat:read", "im:chat.members:bot_access", "im:message", "im:message.group_at_msg:readonly", "im:message.p2p_msg:readonly", "im:message:readonly", "im:message:send_as_bot", "im:resource", "cardkit:card:write" ], "user": ["aily:file:read", "aily:file:write", "im:chat.access_event.bot_p2p_chat:read"] } } 
在这里插入图片描述

5.3 查看APP ID和秘钥

如下图:点击appId 和秘钥

在这里插入图片描述

5.4 发布应用

点击菜单的版本管理和发布,填写信息,发布应用

在这里插入图片描述

5.5 配置事件与回调改成长连接

在这里插入图片描述


然后点击下方的添加时间按钮:输入 im.message.receive_v1
切记:重新部署应用,这里发布了新版本 1.0.1

在这里插入图片描述

5.6 配置openCowork

点击左侧的 Feishu Bot,然后粘贴应用 appId 和秘钥
然后滚动到最下方:允许读取的路径可选配,然后启用

在这里插入图片描述

5.7 测试

1)应用商店下载飞书并登陆: 在下方更多菜单 的工作台,添加常用应用,搜索oepnCoWork;
2)然后电脑OpenCowork对话框的加号,勾选聊天频道飞书;
3)点击机器人输入现在几点了,桌面上有什么等内容,就能自动回复和操作电脑上了;

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

总结

整体体验下来,OpenCowork 更适合用于 本地文档生成、资料整理、代码或文本批量处理 等需要直接操作本地文件的场景。

不过相比云端 AI 平台,它在 生成速度、工具能力和任务复杂度支持 上仍有差距;尤其在长文档生成、多工具协作等场景下,效率和稳定性不如云端服务。因此更适合作为 本地文件处理的辅助工具,而不是完全替代云端 AI。

Read more

一键拯救大模型的前端审美能力 - 使用Frontend-Design Skill提升AI设计水平

# 一键拯救大模型的前端审美能力 ## 前言 目前,在不额外给风格规范/设计系统/示例参考的情况下,拥有前端审美能力的编程模型只有4款: - Gemini 3 Pro - Gemini 3 Flash   - Claude Opus 4.5 - Claude Sonnet 4.5 当我们看到GPT-5.2-Codex等明明其他方面都很厉害,但是唯独前端审美不行的模型时,常常感叹"哀其不幸、怒其不争"。那么,是否有快速提升他们前端审美能力的方法呢? 答案是:**使用 Anthropic 官方提供的 frontend-design skill** ## 什么是 Frontend-Design Skill? Frontend-Design Skill 是 Anthropic 官方提供的一款技能包,可以为所有主流编程大模型(

前端老鸟血泪史:本地存储爆雷怎么办?5招搞定缓存顽疾还能让页面秒开

前端老鸟血泪史:本地存储爆雷怎么办?5招搞定缓存顽疾还能让页面秒开

前端老鸟血泪史:本地存储爆雷怎么办?5招搞定缓存顽疾还能让页面秒开 * 前端老鸟血泪史:本地存储爆雷怎么办?5招搞定缓存顽疾还能让页面秒开 * 别整那些虚的,聊聊咱们天天都要面对的"存数据"这点破事 * 扒一扒浏览器给咱们留的那些"储物柜"底细 * 深究那些让你又爱又恨的存储黑科技 * 这几种方案各有各的坑,踩平了才是真本事 * 真实项目里大家都是怎么"缝缝补补"过日子的 * 遇到诡异的缓存问题别慌,按这个路子查准没错 * 几个让代码更健壮、性能更起飞的老司机经验 * 要是看完你还觉得缓存简单,那一定是你遇到的坑还不够多 前端老鸟血泪史:本地存储爆雷怎么办?5招搞定缓存顽疾还能让页面秒开 说实话,写这篇文章之前我抽了三根烟。不是因为别的,就是想起这些年被本地存储坑过的那些夜晚,血压有点上来了。你们懂那种感受吗?凌晨两点,用户群里突然炸锅,说数据丢了、页面白了、刷新一下东西全没了。你一边陪着笑说"马上修复",一边疯狂翻代码,

前端八股文面经大全:字节跳动前端一面(2025-10-09)·面经深度解析

前端八股文面经大全:字节跳动前端一面(2025-10-09)·面经深度解析

前言 大家好,我是木斯佳。 在这个春节假期,当大家都在谈论返乡、团圆与休息时,作为一名技术人,我的思考却不由自主地转向了行业的「冬」与「春」。 相信很多人都感受到了,在AI浪潮的席卷之下,前端领域的门槛在变高,纯粹的“增删改查”岗位正在肉眼可见地减少。曾经热闹非凡的面经分享,如今也沉寂了许多。但我们都知道,市场的潮水退去,留下的才是真正在踏实准备、努力沉淀的人。学习的需求,从未消失,只是变得更加务实和深入。 正值春节,也是复盘与规划的好时机。结合ZEEKLOG这次「春节代码贺新年」活动所提倡的“用技术视角记录春节、复盘成长”,我决定在这个假期持续更新专栏,帮助年后参加春招的同学。 这个专栏的初衷很简单:拒绝过时的、流水线式的PDF引流贴,专注于收集和整理当下最新、最真实的前端面试资料。我会在每一份面经和八股文的基础上,尝试从面试官的角度去拆解问题背后的逻辑,而不仅仅是提供一份静态的背诵答案。无论你是校招还是社招,目标是中大厂还是新兴团队,只要是真实发生、有价值的面试经历,我都会在这个专栏里为你沉淀下来。 温馨提示:市面上的面经鱼龙混杂,

大模型选型“炼狱”与终结:一份来自普通开发者的AI Ping深度评测报告

大模型选型“炼狱”与终结:一份来自普通开发者的AI Ping深度评测报告

在人工智能应用开发的浪潮中,每一位开发者或许都经历过相似的“启蒙时刻”:初次调用大模型API,看到屏幕上流畅涌现出精准答案时的兴奋。然而,当兴奋褪去,真正将大模型集成到生产环境时,一场更为严峻的考验才刚刚开始。这不再是关于模型能否回答“地球为什么是圆的”,而是关乎你的应用能否在真实的用户压力下,稳定、快速且经济地持续运转。 这片看似繁荣的“百模大战”景象,对一线开发者而言,更像是一片充满未知与迷雾的沼泽。我们正在面临一个前所未有的“选择炼狱”。 第一部分:AI开发者的真实困境——MaaS时代的“性能盲区” 大模型即服务(MaaS)的兴起,极大地降低了开发者使用尖端AI能力的门槛。阿里云、腾讯云、百度智能云等巨头,以及智谱AI、月之暗面、百川智能等新兴力量,共同构建了一个庞大的模型超市。货架上琳琅满目,从千亿参数的庞然大物到针对特定场景的轻量级模型,应有尽有。但问题也随之而来:当产品经理带着需求走来,当运营部门设定了严格的成本红线,当用户在应用商店里因为“反应太慢”而打下一星差评时,我们该如何做出最优选择? 长久以来,行业内评估一个大模型优劣的核心标准,似乎都聚焦于“精度”