通用开发工作台“创造模式”实践指南：从插件创建到模式复用

在智能开发工具逐渐深入工程流程的背景下，越来越多的工作台开始提供“创造模式”。这一模式的核心价值在于：让开发者以自然语言描述目标能力，由智能代理完成插件生成、运行时校验与验收反馈，从而降低扩展开发的门槛。本文将以“项目笔记”插件为例，围绕一个通用开发工作台的创造模式，完整走通从环境准备到模式复用的五个关键步骤。

一、理解创造模式的基本边界

创造模式并非一个独立安装的软件，而是运行在主工作台内部的一种任务形态。它聚合了任务规划、插件生成、运行时检查与验收反馈等能力。与普通对话模式相比，创造模式更强调“可执行结果”而非“信息问答”。

使用创造模式前，建议先明确以下三个要素：

1. 要增加什么能力：例如在侧栏增加一个入口，列出当前工作区的文档文件。
2. 使用入口在哪里：是侧栏、命令面板、右键菜单还是编辑器内嵌区域。
3. 如何验收：例如点击入口后能否正确读取文件、预览内容是否正常。

这三个要素决定了后续创建任务的描述质量，也直接影响代理生成结果的可验证性。

首次尝试时，建议单独建立一个示例目录，避免与现有工程文件混用。这既可以降低误操作风险，也便于在验收阶段进行对照检查。

二、环境准备与工作区初始化

在开始插件开发之前，需要先完成基础运行环境的准备。当前主流方案依赖 Node.js 运行时。安装完成后，在终端中创建示例目录并启动工作台：

mkdir -p harness-creator-demo
cd harness-creator-demo
npx @deepseek-ai/dsh web

上述命令仅作为流程示意。实际执行时，应以目标工作台官方文档提供的启动参数为准。启动成功后，终端通常会输出本地访问地址，例如 http://127.0.0.1:3080。保持终端进程持续运行，浏览器会自动打开工作台界面。

在示例目录中放置几份 Markdown 格式的笔记文档，后续将用于插件的读取与预览验收。建议准备不同类型的内容，例如：

• 一份包含标题层级的文档；
• 一份包含列表和代码块的文档；
• 一份内容较长的多段落文档。

这样可以更全面地检验文件读取与渲染能力。

三、配置模型与选中工作区

全新启动的工作台界面通常不会自动选中工作区。在未选中工作区之前，会话输入框可能处于不可用状态。因此，需要先完成模型配置与工作区选择，再进入插件开发流程。

1. 添加模型提供商

以某云厂商提供的模型 API 为例，一般配置步骤如下：

1. 打开“设置 → 模型 → 添加模型提供商”。
2. 选择“自定义模型 API”。
3. 填写以下关键信息：

配置项	说明
Provider ID	自定义小写标识，用于内部识别
基础 URL	由模型服务方提供的 API 接入地址
API 协议	通常为 OpenAI Chat Completions 兼容协议
API 密钥	从模型服务方控制台获取
模型 ID	从模型广场复制，注意区分模型 ID 与展示名称

配置完成后保存，并在模型选择器中选中刚刚添加的模型。不同服务商的接入地址和参数名称可能存在差异，应以实际控制台提供的信息为准。

2. 选中工作区并验证

点击“选择工作区”，添加并选中前面创建的示例目录。随后发送一条简单的验证指令：

“列出当前工作区中的 Markdown 文件”

如果模型能够正确返回文件列表，说明模型配置与工作区读取链路均已打通。这一步骤是后续插件开发的基础，如果此处失败，插件验证也将无法正常进行。

四、创建第一个插件：项目笔记

在创造模式中，任务描述的质量直接影响生成结果的可用性。一个完整的任务描述应包含能力目标、入口位置与验收标准三个部分。

1. 任务描述模板

以下是一个可直接参考的描述模板：

帮我写一个工作台插件，在侧栏增加“项目笔记”入口。点击后列出当前工作区的 Markdown 文件，并支持点击预览内容。请先检查当前运行时与已有插件环境，说明具体实施方案。

这个描述的特点在于：

• 明确入口：侧栏增加“项目笔记”；
• 明确行为：列出 Markdown 文件、点击预览；
• 明确前置动作：先检查运行时与已有插件，再说明方案；
• 隐含验收标准：入口可见、列表正确、预览可用。

实际使用时，可以进一步补充文件范围限制（如仅扫描工作区根目录两层以内）和预览方式要求（如使用只读视图展示）。

2. 创建任务并观察执行过程

在新建任务时选择“创造模式”，将上述描述填入。代理通常会先进行环境检查，包括：

• 当前运行时是否支持插件加载；
• 是否已存在同名插件或冲突入口；
• 工作区的文件结构是否符合预期。

随后代理会给出实施方案说明，并开始生成插件代码。有经验的开发者可以关注方案中的文件组织方式、入口注册逻辑与文件读取实现，这些决定了插件的可维护性。

五、验证插件生效与验收要点

插件生成完成后，验证环节不可省略。验证应覆盖以下层面：

1. 入口可见性验证

检查侧栏是否出现“项目笔记”入口。如果入口未出现，需要确认插件是否正确注册、是否触发加载失败等。

2. 功能行为验证

点击入口，检查是否列出当前工作区中的 Markdown 文件。重点关注：

• 文件列表是否完整；
• 文件名是否可读；
• 是否混入了非 Markdown 文件。

3. 内容预览验证

点击某个文件，检查内容能否正确渲染。注意观察代码块、列表、标题等元素的呈现效果。

4. 异常场景验证

尝试在空目录、无 Markdown 文件、文件名包含特殊字符等场景下运行，观察插件是否提供合理的空状态提示或错误处理。

六、保存专属模式：三种生效方式的区别

验证通过后，将当前创造模式任务保存为可复用模式，是提升效率的关键步骤。这里需要区分三种不同的生效方式。

1. 插件保存

插件代码保存后，成为工作台可加载的扩展单元。保存位置通常位于工作区的插件目录或全局插件目录中。

2. 即时加载

在开发调试阶段，工作台可能支持热加载或即时重载。修改插件代码后无需重启即可生效。这种方式适合快速迭代，但需要注意运行时状态可能残留。

3. 重启生效

部分插件或运行时环境需要重启后才能加载新代码。重启生效更加稳定，适合在正式使用前进行最终确认。

三者之间的差异可以总结如下：

方式	生效速度	适用场景
即时加载	最快	开发、调试、快速验证
重启生效	较慢	正式加载、规避状态残留
模式保存	持久化	跨会话复用、团队共享

将验证完成的插件与模式一并保存，即可在后续会话中直接调用，无需重复描述任务需求。

七、实践建议与注意事项

基于上述流程，以下几点值得特别关注：

1. 描述越具体，生成结果越可控。模糊的需求容易产出不可验证的结果。
2. 先验证基础设施，再开展插件开发。模型和工作区链路不通时，插件验证无从谈起。
3. 示例环境与真实环境分离。避免插件调试影响已有工程。
4. 验收标准前置。在任务描述中明确“怎样算成功”，可以减少返工。
5. 理解加载机制差异。根据场景选择即时加载或重启生效，避免因状态残留造成误判。

创造模式的价值不仅在于自动生成插件，更在于它提供了一种“描述—生成—验证—沉淀”的闭环。开发者从一次性任务中提炼出可复用的工作模式，逐步形成自己的自动化资产。在智能开发工具持续迭代的背景下，这种能力的积累将比单个插件的实现更具长期意义。