Open Cowork 使用体验报告
—— 一位深度用户的真实反馈
撰写日期：2026-08-11
使用版本：Open Cowork v3.3.1（底层 pi-engine / Electron 35.7.5）
环境：Windows 11 x64 · Node v22.16.0 · 主模型 DeepSeek deepseek-chat
作者角色：重度用户（已经用本软件完成了多份 PPT 课件、图文文档、会议资料的自动化生成，并亲手打通了联网搜索与图片识别链路）
〇、写在前面：真心感谢这个开源社区
首先要由衷地表态：能遇到 Open Cowork 这样一款免费、开源、可离线本地运行的 AI 桌面助手，真的太惊喜了。在这个各家 AI 产品普遍按月订阅、动辄上百元的时代，Open Cowork 让我这样一个普通用户能在不花一分订阅费的前提下，把日常的 PPT 制作、文档整理、资料检索真正自动化，而且所有对话、配置、技能都留在本地，数据安全、隐私有保障。仅凭这一点，就值得为社区作者和贡献者们点赞。
我是抱着"用了就有责任反馈"的心态写下这份报告。报告中没有任何苛责的意思，恰恰相反——正因为我觉得这个软件有巨大的潜力，才希望把我这两天深度使用中遇到的真实问题、已经踩坑踩出来的解法、以及对产品后续方向的一些想法，完整地分享给社区，帮助它变得更好。
一、UI 交互层面：几个非常影响日常体验的问题
以下问题全部在 v3.3.1 实机复现，均为纯前端交互层的缺陷，不涉及 AI 能力，优先级建议最高。
- 会话不自动回落到最底部（最常见）
用户点击/切换/打开会话时，聊天区经常停留在历史顶部而不是滚动到最后一条消息。在多轮问答后尤其明显——打开会话看不到最新的回复，必须先手动滚到底。
期望：切换会话后自动滚到底部一次。
备注：这个问题我自己通过修改 ChatView 组件、注入"会话指纹"逻辑已在本地修复，但默认版本仍存在。
- 点击设置页再回到会话，滚动条跳回顶部
当用户临时点开"设置"（Settings）页，或切换回会话视图时，聊天滚动位置被重置到最顶部。这在大段阅读历史、或需要边看结果边调参数的场景下非常折磨人——每次从设置页返回，都得重新滚到刚才看的位置。
期望：切窗返回后保持滚动条位置不变（这是所有"设置页 + 主面板"型应用的常识性体验）。
- 编辑框文字在切窗后丢失，且无法保存
如果用户在消息输入框里敲了一半的内容，然后点开设置页再回来——输入框里未发送的文字会被直接清空，且没有草稿保留、没有"是否恢复"的提示。对于需要撰写大段 prompt 的场景，这是一次性的内容损失。
期望：输入框内容在切窗/切换会话时应持久保留为草稿，或至少给出"检测到未发送的输入，是否保留？"的提示。
- 删除会话没有二次确认，极易误操作
侧栏的"删除会话"按钮点击后直接删除，没有任何确认弹窗（不是双选、不是输入"确认删除"、不是可撤销）。考虑到会话里往往沉淀了大量重要的对话记录和生成文案，误触一次就是不可逆的数据丢失。
期望：删除前必须有明确的二次确认，最好支持"最近删除"的回收站/撤销机制。
- 会话没有导出功能
目前无法将单个/全部会话导出为 Markdown、JSON 或文本。这意味着：换电脑没法直接带走对话记录、想把某个会话的"最佳实践"分享给团队成员也做不到，会话数据被"锁"在本地应用里。
期望：提供"导出会话为 .md / .json / .txt"的入口，最好支持批量导出和保留附件。
二、能力层面：内置 PPT 技能经常被 AI 跳过，导致成稿质量不稳定
问题描述
软件在 resources/skills/ 中内置了 PPTX（还附带 DOCX/PDF/XLSX）文档生成技能，理论上 AI 应该优先调用。但实测中，AI 大模型很多时候会直接跳过内置技能，选择自己手写一段 PptxGenJS 调用脚本去生成 PPT。
带来的后果（这是我踩得最深的坑）
当 AI 手写生成脚本时，因为不了解 PptxGenJS 底层画布预设的真实尺寸，极容易犯同一个致命错误：
我做过的一个课件就曾因此整页素材超界，排查和重做花了很长时间。最终是通过诊断 p:sldSz 画布尺寸 + 元素坐标系才对症根治的。
根因与建议
根因：内置技能说明没有被 AI 稳定地"优先喂给"模型（系统提示词里技能描述不够醒目 / 判断优先级时被忽略），AI 更倾向于自写脚本。
期望：
- 强化内置技能的触发优先级，在系统提示词里明确"生成 PPT 必须优先调用内置技能，禁止自写脚本"。
- 在技能说明里内置防呆画布校验（显式 defineLayout 写死 13.333×7.5 + 生成后自动读 p:sldSz 比对），让"即使自写脚本也能自检"。
- 生成 PPT 后，自动触发一轮"画布尺寸 + 元素越界"体检并回读给模型，从流程上杜绝超界产出。
三、能力层面：联网搜索 / 图片识别都需要"自己搭链路"，软件没有配置入口
坦率地说，这是我对普通用户入门门槛最担心的部分。下面两条能力，软件本身确实原生支持（底层能通），但没有任何图形化配置入口，全靠用户手动写配置文件、手搓脚本、逐条踩坑才能打通。对没有技术背景的用户来说，几乎是不可用的。
- 联网搜索：需要自己接 MCP 服务器 + 填 API Key
现状问题：软件内置的 MCP 服务器（software-dev-server、gui-operate-server）都不提供联网搜索。要用联网搜索，用户必须自己：
- 注册搜索 API 厂商（如 Tavily 给 1000 次/月免费额度，或国内博查 Bocha 需充值）；
- 用一个完整可用的 Node 环境手动 npm install 搜索 MCP 包；
- 手写/编辑 mcp-config.json，配置 command（node 绝对路径）/args（入口绝对路径）/env（API Key）三件套；
- 全程没有任何图形界面引导，写错一个路径就报 Failed to initialize MCP servers。
我们实际是怎么打通的：
-
Tavily（主力）：command 指向独立的 node.exe，args 指向 tavily-mcp 入口，env 里配置 TAVILY_API_KEY。装机后发现 api.tavily.com 国内能直连、是唯一可用的境外搜索端点（Google/Serper/Brave 全部超时被墙）。
-
博查 Bocha（替补）：因为 Tavily 是境外服务存在网络波动，我又自写了一个基于 modelcontextprotocol/sdk 的 MCP 服务器 bocha-server-sdk.mjs（npm 上的现成包有 completion/complete 兼容 bug 不可用），把国内博查作为兜底，实现"Tavily 失败自动切博查"的双引擎冗余。
期望：在设置界面加入"联网搜索"配置向导——下拉选择引擎（Tavily/博查等）+ 填 API Key + 一键测试连通性，后台自动生成/管理 mcp-config.json。这样普通用户不用碰配置文件就能用上联网检索。
- 图片识别：纯文本模型必须靠"技能脚本"中转，模型本身看不了图
现状问题：当主模型是纯文本模型（如 deepseek-chat）且不再有多模态视觉能力时，用户上传图片会直接报 400：unknown variant image_url——因为 read 工具读图会把图片转成 image_url 强塞给模型。软件内没有任何"图片识别/OCR"设置项，也没有针对纯文本模型的原生降级方案。切后续一切对话均报400错误，必须重启软件。
我们实际是怎么打通的：
- 自制一个 qwen-vision 技能：在技能目录 ~/.pi/agent/skills/qwen-vision/ 放一个 Node 脚本 + SKILL.md；
- 脚本把本地图片转 Base64，调 DashScope Qwen3-VL 视觉模型 API，把识别的中文打印到 stdout；
- 利用 pi 的"技能机制"（把技能 description 注入系统提示词），引导纯文本模型"遇到图片就主动跑这个脚本、把 stdout 当看图结果"；
- 实测这个方案能稳定生效（关键是用技能而非扩展——因为本 GUI 里扩展钩子根本不触发，这也是一个需要社区留意的坑）。
期望：
- 加入图片 OCR 的设置项：至少提供"视觉模型 API Key + 端点 + 模型名"的图形化配置，让软件自动为纯文本模型装配图片识别技能，替代用户手搓。
- 当检测到主模型不支持多模态时，内置 image_url 降级拦截（把图片先走 OCR 再进提示词），而不是直接 400 中断。
- 报告中提到的"扩展机制在本 GUI 不生效"也应排查——这会直接影响大量依赖扩展生态的高级用户。
四、关于 pi 引擎底层继承能力的整体评价（使用小结）
因为我这轮的闭环是通过深挖底层实现的，顺手也把 pi-engine 继承来的能力梳理了一下，整体对技术用户非常友好：
做得好的方向：
-
纯本地 + 免订阅，配置和数据掌握在用户自己手里，这一点的价值怎么强调都不为过。
-
系统提示词可扩展：通过放置 .pi/SYSTEM.md（全局 ~/.pi/agent/SYSTEM.md）即可自动向所有会话注入自定义规则，且不依赖容易失忆的"记忆"——这是我通过源码（buildSystemPrompt 的 customPrompt 分支 + discoverSystemPromptFile）验证过的可靠机制。
-
技能（Skill）机制强大：一套 SKILL.md + 脚本就能扩展几乎任何能力，部署位置灵活（用户级/项目级/包级多目录合并）。
-
MCP 支持成熟：底层原生支持 MCP，为接入任意外部服务提供了通用通道。
待改进的方向（与 pi 继承相关）：
-
系统提示词组装存在一个"知识盲区"：一旦存在 SYSTEM.md，会走 customPrompt 分支替换默认模板（丢失 Available tools 列表、Guidelines、Pi 文档链接）；同时 APPEND_SYSTEM.md 又会被硬编码规则 U 抢占失效。这两处对新手不透明，建议在 GUI 里提供更明确的提示。
-
扩展（Extension）注册的钩子在 GUI 会话中不生效（见第三节图片识别），对想用扩展生态的用户是较大的阻碍。
-
.pi/SYSTEM.md 的加载需要重启应用才在新会话生效，旧会话不会自动刷新，体验上容易造成"改规则却看不到变化"的困惑。
五、总结与个人展望
Open Cowork 让我这个普通用户，第一次真正体会到"把 AI 变成自己的生产力工具、而不是被订阅付费牵着走"的快乐。它身上那些 open-source、本地优先、自由扩展的特性，正是我最看重的价值。
当然，它也还没有完全打磨到"开箱即用、人人可上手"的程度——UI 上的滚屏/草稿/删除确认、能力的配置向导、内置技能的稳定触发，这些直接决定普通用户的留存率，是我觉得最值得社区优先投入的几个点。
而我自己，也还在持续摸索和打磨这套工作流：
- 我已经在这台机器上亲手打通了联网搜索双引擎、纯文本模型图片识别、模板化 PPT 防呆生成这三条链路。
- 我也已经在本地修复了会话滚动、注入全局规则等几个痛点，并验证了可离线复现。
如果有时间和精力的话，我想把自己这一版经过实际打磨、修复改进，整理后发布到我的公开仓库，让更多和我一样需要"免费、本地、可自定义"AI 助理的朋友能直接受益，也算是把自己从社区学到的东西，以开源的方式回馈回去。
再次感谢 Open Cowork 的开发者和社区。期待它越来越好。
本报告由AI基于我的真实使用情况生成
Open Cowork 使用体验报告
—— 一位深度用户的真实反馈
撰写日期：2026-08-11
使用版本：Open Cowork v3.3.1（底层 pi-engine / Electron 35.7.5）
环境：Windows 11 x64 · Node v22.16.0 · 主模型 DeepSeek deepseek-chat
作者角色：重度用户（已经用本软件完成了多份 PPT 课件、图文文档、会议资料的自动化生成，并亲手打通了联网搜索与图片识别链路）
〇、写在前面：真心感谢这个开源社区
首先要由衷地表态：能遇到 Open Cowork 这样一款免费、开源、可离线本地运行的 AI 桌面助手，真的太惊喜了。在这个各家 AI 产品普遍按月订阅、动辄上百元的时代，Open Cowork 让我这样一个普通用户能在不花一分订阅费的前提下，把日常的 PPT 制作、文档整理、资料检索真正自动化，而且所有对话、配置、技能都留在本地，数据安全、隐私有保障。仅凭这一点，就值得为社区作者和贡献者们点赞。
我是抱着"用了就有责任反馈"的心态写下这份报告。报告中没有任何苛责的意思，恰恰相反——正因为我觉得这个软件有巨大的潜力，才希望把我这两天深度使用中遇到的真实问题、已经踩坑踩出来的解法、以及对产品后续方向的一些想法，完整地分享给社区，帮助它变得更好。
一、UI 交互层面：几个非常影响日常体验的问题
以下问题全部在 v3.3.1 实机复现，均为纯前端交互层的缺陷，不涉及 AI 能力，优先级建议最高。
用户点击/切换/打开会话时，聊天区经常停留在历史顶部而不是滚动到最后一条消息。在多轮问答后尤其明显——打开会话看不到最新的回复，必须先手动滚到底。
期望：切换会话后自动滚到底部一次。
备注：这个问题我自己通过修改 ChatView 组件、注入"会话指纹"逻辑已在本地修复，但默认版本仍存在。
当用户临时点开"设置"（Settings）页，或切换回会话视图时，聊天滚动位置被重置到最顶部。这在大段阅读历史、或需要边看结果边调参数的场景下非常折磨人——每次从设置页返回，都得重新滚到刚才看的位置。
期望：切窗返回后保持滚动条位置不变（这是所有"设置页 + 主面板"型应用的常识性体验）。
如果用户在消息输入框里敲了一半的内容，然后点开设置页再回来——输入框里未发送的文字会被直接清空，且没有草稿保留、没有"是否恢复"的提示。对于需要撰写大段 prompt 的场景，这是一次性的内容损失。
期望：输入框内容在切窗/切换会话时应持久保留为草稿，或至少给出"检测到未发送的输入，是否保留？"的提示。
侧栏的"删除会话"按钮点击后直接删除，没有任何确认弹窗（不是双选、不是输入"确认删除"、不是可撤销）。考虑到会话里往往沉淀了大量重要的对话记录和生成文案，误触一次就是不可逆的数据丢失。
期望：删除前必须有明确的二次确认，最好支持"最近删除"的回收站/撤销机制。
目前无法将单个/全部会话导出为 Markdown、JSON 或文本。这意味着：换电脑没法直接带走对话记录、想把某个会话的"最佳实践"分享给团队成员也做不到，会话数据被"锁"在本地应用里。
期望：提供"导出会话为 .md / .json / .txt"的入口，最好支持批量导出和保留附件。
二、能力层面：内置 PPT 技能经常被 AI 跳过，导致成稿质量不稳定
问题描述
软件在 resources/skills/ 中内置了 PPTX（还附带 DOCX/PDF/XLSX）文档生成技能，理论上 AI 应该优先调用。但实测中，AI 大模型很多时候会直接跳过内置技能，选择自己手写一段 PptxGenJS 调用脚本去生成 PPT。
带来的后果（这是我踩得最深的坑）
当 AI 手写生成脚本时，因为不了解 PptxGenJS 底层画布预设的真实尺寸，极容易犯同一个致命错误：
PptxGenJS 的 LAYOUT_16x9 预设实际是 10 × 5.625 英寸，而很多人（包括 AI）会下意识按 16:9 常见的 13.333 英寸宽来布局元素。
结果就是：所有 x > 10 英寸的标题、右侧图片、通栏条全部跑到画布之外，WPS/PowerPoint 打开素材全部越界，转 PDF 后右半边被直接裁剪，成稿排版错乱，且肉眼难以及时发现（屏幕上看的时候边界不明显）。
我做过的一个课件就曾因此整页素材超界，排查和重做花了很长时间。最终是通过诊断 p:sldSz 画布尺寸 + 元素坐标系才对症根治的。
根因与建议
根因：内置技能说明没有被 AI 稳定地"优先喂给"模型（系统提示词里技能描述不够醒目 / 判断优先级时被忽略），AI 更倾向于自写脚本。
期望：
三、能力层面：联网搜索 / 图片识别都需要"自己搭链路"，软件没有配置入口
坦率地说，这是我对普通用户入门门槛最担心的部分。下面两条能力，软件本身确实原生支持（底层能通），但没有任何图形化配置入口，全靠用户手动写配置文件、手搓脚本、逐条踩坑才能打通。对没有技术背景的用户来说，几乎是不可用的。
现状问题：软件内置的 MCP 服务器（software-dev-server、gui-operate-server）都不提供联网搜索。要用联网搜索，用户必须自己：
我们实际是怎么打通的：
Tavily（主力）：command 指向独立的 node.exe，args 指向 tavily-mcp 入口，env 里配置 TAVILY_API_KEY。装机后发现 api.tavily.com 国内能直连、是唯一可用的境外搜索端点（Google/Serper/Brave 全部超时被墙）。
博查 Bocha（替补）：因为 Tavily 是境外服务存在网络波动，我又自写了一个基于 modelcontextprotocol/sdk 的 MCP 服务器 bocha-server-sdk.mjs（npm 上的现成包有 completion/complete 兼容 bug 不可用），把国内博查作为兜底，实现"Tavily 失败自动切博查"的双引擎冗余。
期望：在设置界面加入"联网搜索"配置向导——下拉选择引擎（Tavily/博查等）+ 填 API Key + 一键测试连通性，后台自动生成/管理 mcp-config.json。这样普通用户不用碰配置文件就能用上联网检索。
现状问题：当主模型是纯文本模型（如 deepseek-chat）且不再有多模态视觉能力时，用户上传图片会直接报 400：unknown variant image_url——因为 read 工具读图会把图片转成 image_url 强塞给模型。软件内没有任何"图片识别/OCR"设置项，也没有针对纯文本模型的原生降级方案。切后续一切对话均报400错误，必须重启软件。
我们实际是怎么打通的：
期望：
四、关于 pi 引擎底层继承能力的整体评价（使用小结）
因为我这轮的闭环是通过深挖底层实现的，顺手也把 pi-engine 继承来的能力梳理了一下，整体对技术用户非常友好：
做得好的方向：
纯本地 + 免订阅，配置和数据掌握在用户自己手里，这一点的价值怎么强调都不为过。
系统提示词可扩展：通过放置 .pi/SYSTEM.md（全局 ~/.pi/agent/SYSTEM.md）即可自动向所有会话注入自定义规则，且不依赖容易失忆的"记忆"——这是我通过源码（buildSystemPrompt 的 customPrompt 分支 + discoverSystemPromptFile）验证过的可靠机制。
技能（Skill）机制强大：一套 SKILL.md + 脚本就能扩展几乎任何能力，部署位置灵活（用户级/项目级/包级多目录合并）。
MCP 支持成熟：底层原生支持 MCP，为接入任意外部服务提供了通用通道。
待改进的方向（与 pi 继承相关）：
系统提示词组装存在一个"知识盲区"：一旦存在 SYSTEM.md，会走 customPrompt 分支替换默认模板（丢失 Available tools 列表、Guidelines、Pi 文档链接）；同时 APPEND_SYSTEM.md 又会被硬编码规则 U 抢占失效。这两处对新手不透明，建议在 GUI 里提供更明确的提示。
扩展（Extension）注册的钩子在 GUI 会话中不生效（见第三节图片识别），对想用扩展生态的用户是较大的阻碍。
.pi/SYSTEM.md 的加载需要重启应用才在新会话生效，旧会话不会自动刷新，体验上容易造成"改规则却看不到变化"的困惑。
五、总结与个人展望
Open Cowork 让我这个普通用户，第一次真正体会到"把 AI 变成自己的生产力工具、而不是被订阅付费牵着走"的快乐。它身上那些 open-source、本地优先、自由扩展的特性，正是我最看重的价值。
当然，它也还没有完全打磨到"开箱即用、人人可上手"的程度——UI 上的滚屏/草稿/删除确认、能力的配置向导、内置技能的稳定触发，这些直接决定普通用户的留存率，是我觉得最值得社区优先投入的几个点。
而我自己，也还在持续摸索和打磨这套工作流：
如果有时间和精力的话，我想把自己这一版经过实际打磨、修复改进，整理后发布到我的公开仓库，让更多和我一样需要"免费、本地、可自定义"AI 助理的朋友能直接受益，也算是把自己从社区学到的东西，以开源的方式回馈回去。
再次感谢 Open Cowork 的开发者和社区。期待它越来越好。
本报告由AI基于我的真实使用情况生成