夜雨聆风
如果你用过或见过 WorkBuddy，你大概知道这类 AI 工作助手长什么样。按官方页面和产品文档的描述，你交代目标，它拆步骤、动文件，最后交回产物。openwork 又把代码、桌面入口和接入方式放进了公开仓库。第一反应很诱人：原来自己也能做一个类似的。可画风一转，界面只是交付的起点。公开路线能检查、能修改、能继续开发；任务敢不敢交出去，还得往后看。
WorkBuddy 在这里是产品形态参照，openwork 是 different-ai 名下的公开项目，两者没有官方承接关系。公开代码把“能不能做”变成了可核对的工程问题。
如果你见过 WorkBuddy，就知道它卖的不是聊天框
聊天框等你一问一答，工作助手接到的是一个目标，最后还要交回结果。
腾讯产品页说，WorkBuddy 接受自然语言任务，会思考、拆解、规划并交付结果。官方任务文档列出了阶段卡片、实时过程、继续追问、中断和重新生成。
官方 App 文档接着讲产物。文件可在对话里展示，预览 PDF、DOCX 和 Markdown；用户可继续修改并重新生成。App 端还列出了导出、腾讯文档和分享链接。
这些都是官方披露，不是本文实测，也不证明任务成功率。它们画出的轮廓很具体：人交目标，过程能改，文件回到人手里。
openwork 把门推开了：路线现在可以自己检查
openwork 的 README 自述：它是分享 AI 工作流的免费开源桌面应用，面向 macOS、Windows 和 Linux。桌面端不是唯一入口，README 也给了安装、远程接入和本地开发说明。
OpenWork MCP 可以理解成一种连接方式，让兼容的 AI 工具调用外部能力。README 说，能力可跨工具、同事和机器复用，并给出了查找能力的 search_capabilities 和执行能力的 execute_capability。
README 还把 OpenWork Den 描述成团队控制面，可管理成员与访问、桌面策略、本地模型、应用版本，以及 skills 和 plugins 的分配范围。
公开仓库里还能看到 issue 模板、测试和发布工作流相关文件。它们只证明工程入口存在。openwork 让“自己做一个”有了可检查、可修改的路线，但 README 不是一张照着走就必然完工的说明书。
画风一转：入口做出来，任务还没交完
一个界面能收指令，一次调用能返回结果，离可反复使用的工作体验还有一段路。
我把后面的环节叫“交付链”。这不是厂商术语或行业标准，只是本文的检查尺：任务控制、产物接收、权限确认、异常维护，以及团队或跨设备交付。
openwork 让“自己做一个”变得可信。公开材料目前能确认的是入口和工程路线，后面的交付链还要逐层检查。
下面只对照公开页面明确披露的内容。页面空白处留问号，不把“没按同一口径写”偷换成“产品没有”，也不给两款产品排座次。
从一句指令到一个能交的文件，先过任务和产物两层
第一层是任务过程。WorkBuddy 官方文档列出了自动拆解、阶段卡片、实时展示、追问、中断和重新生成。
openwork 的 README 提供了能力查找与执行两个工具，也说明兼容的 Agent 可以调用。它没有按同样的粒度展开上述交互。两份页面披露的对象不同，所以无法据此判断 openwork 是否具备任务拆解或中断，也不能判断 WorkBuddy 的成功率。
第二层是产物接收。WorkBuddy 官方 App 文档串起了查看、预览、修改、重新生成、分享和导出。格式以页面列出的 PDF、DOCX、Markdown 为准，部分动作限定在 App 端。
openwork 的 README 讲了桌面工作空间、已连接服务和能力执行，但没有按上述口径给出整段说明。公开页面不足以判断同类产物如何走到预览、修改、导出与分享。
调用成功只说明能力跑了一次。文件到了人能接手的状态，这段交付才算闭合。
演示结束后，权限和故障才开始显出重量
第三层是权限。WorkBuddy 官方文档区分默认权限和完全访问。默认权限围绕工作空间运行，并会对敏感路径、重要删除、脚本或外部程序、网络等操作要求确认。文档也把风险写在了明面上：默认权限不能替代备份；完全访问会关闭二次确认。文件备份当前只支持 Windows。
openwork 的 README 在 Den 部分公开了成员访问、模型供应方范围、桌面策略、本地模型限制和应用版本。它偏向团队控制面，和 WorkBuddy 端侧风险确认并非同一口径，不能直接折算成安全排名。
第四层是异常与维护。WorkBuddy 官方 FAQ 列出登录、工作空间文件、Bot 连接、文件读取、生成文件打不开、运行慢、卡住、乱码或无响应等情况，也给出停止任务、切换模型、拆分任务、看日志和提交反馈等建议。FAQ 还写明 Windows 11 ARM64 暂不支持，服务器端能力仍在完善。
FAQ 条目不代表故障率，处理建议也不保证奏效。openwork 仓库里有 issue 模板、测试和发布工作流、本地开发说明；这些入口不能换算成稳定运行。README 未按 WorkBuddy FAQ 的形式列出终端用户故障矩阵，只能记作“缺少同口径材料”。
正常演示往往只走最顺的一次。权限弹窗、坏文件、卡住的任务和版本升级，才会把后续投入一项项摊开。
最后一层要看别人能不能接得住
个人电脑上跑通，还要面对第五层：任务能不能交到另一个入口、另一台设备或另一个成员手里。
WorkBuddy 官方 App 文档写到，产物可生成链接并通过系统渠道分享。FAQ 还列出 QQ、企业微信、微信、飞书、钉钉等入口，也披露了部分连接、移动端上传和远程场景的限制。这里不能顺手推导团队使用效果。
openwork 的 README 写明，能力可跨工具、同事和机器复用。Den 可管理成员与访问，把 skills 和 plugins 分配到不同范围，并设置共享或个人连接。
两边材料都触及多人、多入口，但披露对象和粒度不同。公开页面没有共同的任务接续成功率、权限效果、支持成本或团队采用数据。这一层无法评分，只能标清证据边界和未知项。
拿这五层回看“手搓 AI 工作助手”，进度就不该只报“界面做好了”或“能力调用通了”。任务过程、产物接收、权限确认、异常维护、团队交付，每往后闭合一段，别人接手时才少一个问号。
下一次再看到“自己做一个 AI 工作助手”，可以把问题换得具体些：它已经把任务送到了交付链哪一步？答案不必漂亮，但要和公开证据对得上。
资料来源
• 腾讯云：《Tencent WorkBuddy 产品页》 • WorkBuddy 官方文档：《产品介绍》 • WorkBuddy 官方文档：《任务执行与对话》 • WorkBuddy 官方文档：《产物查看与分享》 • WorkBuddy 官方文档：《默认权限与安全沙箱》 • WorkBuddy 官方文档：《常见问题 FAQ》 • different-ai：《OpenWork — GitHub README 与公开仓库》