OpenWork 社区支持指南从 SUPPORT.md 到 Settings → Debug 的调试信息采集与高质量 Issue 上报【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openworkOpenWork基于 opencode 构建的 Claude Cowork 开源替代品在仓库根目录维护了一份 SUPPORT.md规定了求助渠道、Issue 提交规范、调试信息采集与维护者分流机制。本文以该文档为主体骨架结合仓库内实际的 Issue 模板bug.yml、feature.yml、安全策略SECURITY.md以及 Settings → Debug 页面的源码实现讲解如何在遇到问题时快速、准确、可复现地获得官方支持。读完本文你将掌握OpenWork 各类问题的正确求助渠道与模板选择、提交 Issue 前必须准备的上下文版本、OS、复现步骤、调试产物以及如何从桌面端 Debug 面板导出运行时 debug 报告 开发者日志这两份排查利器。选择合适的求助渠道SUPPORT.md 的核心建议是使用正确的渠道以获得更快的帮助Use the right channel to get faster help。不同性质的问题走不同的通道避免把安全漏洞、功能建议混入普通问答问题类型正确渠道说明使用问题 / 用法求助提交 GitHub Issue并标记为 question常规求助用于如何配置某功能怎么用类问题Bug 报告使用 Bug issue 模板模板位于 .github/ISSUE_TEMPLATE/bug.yml功能请求使用 Feature issue 模板模板位于 .github/ISSUE_TEMPLATE/feature.yml安全漏洞报告遵循 SECURITY.md 私下报告严禁在公开 Issue 中披露安全漏洞从 SECURITY.md 可以看到安全报告的完整约定请将漏洞细节通过邮件发送至benopenworklabs.com邮件主题使用[OpenWork security] 简短摘要前缀并附带问题描述、复现步骤或 PoC、影响评估以及如已知的修复建议。官方承诺 3 个工作日内确认收到、7 个工作日内给出初步分流triage状态并尽快分享修复或缓解指引在修复或缓解方案可用且维护者确认公开时机之前请保持细节私密。提交 Issue 前自查清单SUPPORT.md 要求开 Issue 前完成以下准备这也是维护者能高效处理你问题的前提搜索已有 Issue避免重复Search existing issues to avoid duplicates。包含精确的 OpenWork / OpenCode 版本、操作系统与复现步骤Include exact OpenWork/OpenCode versions, OS, and reproduction steps。针对桌面端、worker 或会话类 Bug打开Settings - Debug同时附带两类产物——运行时 debug 报告runtime debug report与开发者日志导出developer log export。截图当截图有助于说明流程或失败状态时附上截图Add screenshots when they help explain the flow or failure state。其中版本 OS字段在 Bug 模板中有明确占位示例OpenWork version: [e.g. 0.1.166]、OS: [e.g. macOS Tahoe 26.2]并提示可从Settings General查看版本号复现步骤要求用最小化步骤Minimal Steps to reproduce逐条列出1. Go to ... → 2. Click on .... → ... → See error。Bug 模板字段速览bug.yml 定义的必填与选填字段如下Summary必填什么问题 / 哪里不对。To Reproduce必填最小复现步骤。Expected behavior必填期望发生什么。Actual behavior必填实际发生了什么。Screenshots选填有助于解释问题的截图或视频。OW version Desktop info选填OS 与 OpenWork 版本。Additional context选填其他背景信息。Feature 模板的独特要求feature.yml 与常规功能请求模板不同额外要求贡献者思考OpenCode primitive alignment是否存在已覆盖该能力的 OpenCode 原语或 API如session.*、permission.*、skills/plugins、mcp若没有为什么仍需要一层薄薄的 OpenWork 层Alignment with VISION/PRINCIPLES/PRODUCT该功能如何与VISION.md、PRINCIPLES.md、PRODUCT.md对齐。Testability如何测试手动步骤、工具、截图示例为pnpm dev chrome mcp screenshots。Ready to build it yourself是否愿意自行实现Yes/No。Primary user(s)目标用户BobIT/高级用户Susan非技术用户其他团队角色。Settings → Debug运行时调试信息的采集实现SUPPORT.md 反复强调的Settings - Debug并非纸面建议它对应桌面端真实的开发者调试页面。该页面在 debug-view.tsx 中渲染状态与命令逻辑集中在 debug-view-model.ts仅在**开发者模式developerMode**开启时可见if (!props.developerMode) return null;。页面上与你上报 Bug 直接相关的核心能力如下。运行时 debug 报告Runtime debug report页面顶部是 Runtime debug report 区块提供一键复制Copy JSON与导出Export。从 debug-view-model.ts 的runtimeDebugReport构建逻辑可见导出的 JSON 快照包含collectedAt采集时间ISO 8601。app桌面应用构建信息版本、git commit SHA。engineopencode 引擎的baseUrl、runtime、pid、hostname、port、opencodeBinPath及来源、最近 stdout/stderr。openworkServerhostInfo、diagnostics版本、uptime、readOnly、approval 模式与超时、工作区数量、config 路径、token 来源、capabilitiesskills/plugins/mcp/commands/config 的读写能力、浏览器与文件工具提供方、sandbox 后端、settings、status、url。runtimeWorkspaceId、selectedWorkspaceRoot、bootstrap.preparedagent-first 安装的 org 与首个 skill 摘要。导出的文件名形如openwork-runtime-timestamp.json见onExportRuntimeDebugReport。这些字段覆盖了 SUPPORT.md 要求的精确版本信息——应用版本、OpenCode 版本、OpenWork server 版本在同一份报告中一次集齐。服务状态卡片与日志Debug 页面以两张 ServiceCard 展示两个核心服务的运行状态见 debug-view.tsx 中的 Services 区块OpenWork serverBase URL、托管 opencode 二进制路径与来源、服务端日志文件路径、Connect URL、LAN URL、mDNS URL、PID、远程访问开关。OpenCode engine sidecarBase URL、runtime、opencode 二进制路径与来源、PID、hostname、port。每张卡片都提供Restart重启服务、Copy logs、Export logs按钮并内置可展开的last stdout / last stderr原始输出。导出文件分别命名为openwork-server-timestamp.log与openwork-opencode-timestamp.log。对于会话异常、worker 掉线等场景这两份服务日志与运行时报告组合基本可以还原故障现场的完整链路。开发者日志流Developer log streamDebug 页面底部的 Developer log stream 区块标题文案见 en.ts 中settings.developer_log_titleApp, workspace, session, and perf events captured while Developer Mode is on对应的是 debug-logger.ts 实现的开发期可观测性客户端。该模块会拦截浏览器console.log/info/warn/error/debug并记录uncaught全局错误与unhandledrejection未处理 Promise 拒绝包装window.fetch记录每次网络请求的方法、URL、状态码与耗时便于定位卡死前的挂起请求以 1 秒间隔的心跳检测主线程卡顿心跳间隔超过3 秒记录hang真实 JS 线程停滞事件超过10 秒则降级记录为meta级webview 被后台节流/恢复事件用于区分 macOS App Nap 导致的假卡死将事件批量 POST 到 openwork-server 的/dev/logsink带 500ms 批量合并与 200 条队列上限并同步保留一份到window.__openwork.events()供操作者本地查阅生产构建中默认全部为 no-op除非显式设置localStorage.openwork.debug.enableLoggerInProd 1。开发者日志的复制与导出对应openwork-developer-timestamp.log且页面保留最近500 条记录pushDeveloperLog中的截断逻辑。上报会话类 Bug 时这段日志可以精确还原卡死 / 异常前最后发生了什么。维护者分流Maintainer triageSUPPORT.md 声明维护者会依据TRIAGE.md中的评分细则rubric对 Issue 打标签并路由处理。需要说明的是当前仓库根目录下并未发现TRIAGE.md实体文件仅在 SUPPORT.md 与 translated_readmes/README_JA.md 中被引用因此从仓库证据看该文件可能作为维护者内部文档或暂未随仓库公开普通用户无需直接接触它——你只需保证 Issue 信息完整、属于正确类别分流自然会更快。小结一份高通过率Issue 的构成结合 SUPPORT.md 与仓库实现一份能被高效处理的 OpenWork Bug 报告应包含在 .github/ISSUE_TEMPLATE/bug.yml 模板中逐字段填写Summary、最小复现步骤、Expected / Actual、截图明确 OpenWork / OpenCode 版本与 OS可从Settings General查看桌面端、worker、会话类问题务必先进入Settings - Debug导出 runtime debug 报告 JSON并导出开发者日志.log随 Issue 一并附上若涉及安全漏洞改走 SECURITY.md 的私密邮件通道绝不在公开 Issue 中披露。这套先自查、再取证、后提交的流程既能避免重复 Issue 与无效往返也能让维护者基于运行时报告与开发者日志快速定位问题根因——这正是 SUPPORT.md 想要传达的支持效率哲学。【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考