插件发布3天，下载破千：我把公众号创作接进了DSH

一个插件，怎样才算真正“做完”？

对我来说，不是面板能打开、包能安装就结束。它还得能把任务交给 Agent，安全地调用本机工作台；服务出错时能说清下一步；更新后也不把用户留在版本不兼容的状态里。

最近，npm 页面给了我一个小惊喜：用户提供的截图显示，见字插件包 jianzi-content-workbench 的近 7 天下载量达到 1,357。截图时版本列表从首个预发布版算起只有3天。下载数字会变化，它说明有人在尝试这个插件，却不能单独说明留存或实际使用效果。我更想借这个节点，复盘它是怎么做出来的。

面板只是入口，任务链才是产品

见字是本机运行的内容工作台，负责保存采集、选题、文章和交付产物。我们想让 DSH 用户在当前会话里调度这些能力，不必在不同窗口间来回切换。

第一版很快遇到一个设计问题：点击按钮后，是直接开干，还是先让人检查任务？

我们选了后者。插件面板把阶段和对象整理成一条 DSH 原生会话草稿；用户检查并发送后，Agent 才通过 MCP 调用见字。这样做多了一步，但选题、写文章和交付内容时，用户知道 Agent 将处理什么，也能在关键节点停下来。

面板只读取展示所需的状态；执行业务的 MCP 工具复用见字现有实现，数据仍由本机工作台保存。流程规则放在项目技能里，界面不再维护另一套容易过期的流程说明。

把关键门槛写进流程

接通工具之后，工作才刚开始。我们把常用任务串成几个阶段：检查环境、发现选题、文章生产、排版交付、图文制作和内容复盘。

每个阶段都有边界。选题结果先交给用户挑选；写作先保存为草稿；排版只接受用户确认过的终稿。内容复盘需要本轮上传的数据表，匹配并关联到本地文章后再生成调整草案。没有必要的输入，就停下来说明缺什么。

本地服务和版本问题也要有答案

插件要连接用户电脑上的见字服务。服务没启动时，DSH Agent 可以调用启动工具，等待健康检查，并核对项目指纹，避免连到另一个目录里的项目。插件版本高于本地项目时，业务调用会停止，并提示更新、重建和重启。

这部分没有发布海报那么显眼，却决定了用户第一次遇到问题时，是能继续处理，还是只能对着报错猜。

从能安装到能持续交付

第一版插件于 2026 年 11 月 6 日合入仓库。后续提交继续完善安装说明、统一项目和插件的版本发布，并补上版本兼容检查。现在普通用户可以在 DSH 插件管理器里输入 jianzi-content-workbench 安装；发布流程通过 npm Trusted Publisher 完成，不需要长期保存 npm 发布令牌。统一版本标签也减少了项目与插件各自改版本造成的错位。

我还把版本占用检查放进发布流程：如果 npm 上已经存在同一版本，发布任务会失败，而不是悄悄覆盖或留下难以判断的发布结果。发布动作由版本标签触发，日常提交不会误发 npm 包。

从这次开发里，我们记住一件很实际的事：集成工具时，先定清楚谁负责展示、谁执行、数据落在哪里，以及哪些动作需要用户确认。再把启动、升级和故障恢复纳入设计。这样面板上的每个按钮才有明确的去处。

如果你在用 DeepSeek Harness，可以试试搜索 jianzi-content-workbench。打开见字项目作为当前工作空间，启用插件后，就能从面板选择要推进的内容阶段。

数据说明：1,357 次近 7 天下载来自作者提供的 npm 页面截图，是截图时的动态值。项目说明见 npm 包页面；首个插件提交见 GitHub 提交记录。