QoderWork 拓展发布指南（Skill / Plugin / Connector）

1.1 Skill — 原子能力

Skill 是 QoderWork 中最基础的能力单元，一份 Skill 即一项可被 AI 复用的"做事方法"。当用户提出与之匹配的任务时，AI 会自动调用对应 Skill，按其内置的步骤、规范与示例完成工作，从而显著提升单一场景下的表现质量。

典型场景：生成 PDF 报告、撰写专业合同、解读用户反馈数据、整理周报等。

特点：粒度小、即装即用、可被多个专家套件共同复用，是构建上层能力的基石。

1.2 Plugin（专家套件）— 虚拟岗位专家

Plugin 是围绕一个真实岗位或专业角色组织的能力集合，由多个 Skill、若干 Connector 依赖与岗位指令文档共同构成。安装后即可在 QoderWork 中获得一位"虚拟同事"，可独立承担该岗位的完整工作链路。

典型场景：超级 HR（招聘全案）、超级法务（合同审查）、超级财务（对账与异常分析）、超级产品经理（需求规划）等。

特点：以岗位为中心、能力相互联动、具备完整的工作流，适合需要"一人成军"的复合任务场景。

1.3 Connector — 外部系统连接器

Connector 是 QoderWork 与第三方系统之间的标准化连接通道，本质是一台支持 OAuth 授权的 MCP Server。安装并授权后，AI 即可在用户许可的权限范围内读写对应系统的数据，将外部业务系统纳入工作流之中。

典型场景：连接钉钉、Notion、Slack、Jira、企业 CRM 或自建业务系统等。

特点：以服务为单位、用户授权可控、可被任意 Skill 或专家套件调用，是 AI 触达真实业务数据的关键入口。

1.4 工作台 — 垂直场景的独立工作界面

工作台是 QoderWork 中一类形态较重的拓展，为特定专业场景提供独立的工作界面与状态管理，将相关的 Skill、Connector 与自定义 UI 编排在同一画布之内。相较于通用对话界面，工作台更适合高频、重状态、多任务并行的专业作业场景。

典型场景：估值复核工作台、合同审阅工作台、销售线索看板等。

特点：拥有独立界面与状态、面向单一垂直场景、可深度定制交互流程，是面向专业岗位的"专属工厂"。

2.1 Skill 上架要求

Skill 的核心价值在于"被 AI 准确理解并稳定复用"，因此审核重点在内容质量本身：

• 内容清晰：描述须以第三人称说明 Skill 的职责与触发场景，并包含用户在自然语言中可能使用的关键词，便于 AI 在合适的时机调用；

• 结构合理：正文应包含明确的使用步骤、注意事项与验证方式，避免出现占位符（如 TODO、<your-token>）或无法直接执行的伪代码；

• 安全无害：不得包含恶意脚本、可疑的外部请求或越权指令，亦不得在示例中泄漏真实凭证。

Skill 采用机审为主、人工抽检为辅的审核机制，通常数分钟内即可获得结果。

2.2 Plugin（专家套件）上架要求

Plugin 体现的是"一位专家"的完整能力，因此审核更关注套件作为整体的合理性与专业度：

• 符合套件结构：须按规范组织目录，提供完整的元数据（plugin.json）、内嵌的 Skill 与必要的角色指令文档，且每个内嵌 Skill 自身均须合规；

• 围绕岗位组织：套件名称建议直接采用真实存在的岗位名称（2–6 字），所含 Skill 与 Connector 之间应存在明确的协作关系，避免将无关能力简单堆砌；

• 依赖可解析：套件中引用的 Connector 必须为市场中已上架的有效条目。

Plugin 在提交前由客户端进行结构预检，预检通过后进入与 Skill 类似的机审流程。

2.3 Connector 上架要求

Connector 涉及外部数据访问与用户授权，是审核要求最高的拓展类型。原则上，每家公司均可为自家服务提交一个官方 Connector：

• 支持 OAuth 的 MCP Server：必须为公开可达的 HTTPS MCP Server，并实现完整的 OAuth 授权流程，确保用户的访问权限可控、可撤销；

• 公司身份核验：上架者须为对应服务的公司可信人员，提交时须配合官方完成实名或企业认证，官方将通过电话方式确认上传人身份；

• 法务与隐私合规：须提供公开可访问的隐私政策、服务条款，并明确说明采集的数据范围与使用目的；

• 自测报告完整：须提交涵盖连通性、典型工具调用、权限范围、异常处理与服务可用性的自测说明。

Connector 在机审通过后，将统一进入人工终审环节，不会被自动放行。

2.4 工作台上架要求

工作台属于较为复杂的一类拓展，承载完整的界面与业务流程，因此对工程化交付有更高的要求：

• 遵循 SDK 规范：须基于 QoderWork 官方提供的工作台 SDK 进行开发，包含合规的清单文件、UI 资源与 MCP Server 实现；

• 垂直场景明确：每一个工作台应聚焦一个清晰的专业场景，具备完整的输入、处理与输出链路；

• 资源边界清晰：工作台所依赖的 Skill、Connector 须在套件内明确声明，并通过 SDK 提供的接口完成集成与权限确认。

由于工作台对界面与状态有深度定制，建议在提交前完成端到端走查，确保在 QoderWork 中可稳定加载与运行。

3.1 Skill 规范

每个 Skill 以一个独立文件夹为单位，核心为 SKILL.md，其余为可选的参考资料。

目录结构

<skill-name>/
├── SKILL.md          # 技能定义文件（必需）
└── references/       # 参考文件目录（可选，存放模板、示例、数据等辅助材料）
    ├── template.md
    └── example.json

SKILL.md 格式

文件顶部为 YAML Frontmatter，正文为 Markdown：

---
name: contract-review           # 技能标识（必需）
description: 审查合同条款并标注风险点。适用于用户上传合同文件并要求审查时。  # 功能描述（必需）
version: 1.0.0                  # 版本号（可选）
---

命名规则

• 仅允许小写字母、数字与连字符（-），不得以连字符开头或结尾

• 最长 64 个字符

• 名称即为技能的唯一标识，发布后不可修改

版本号

采用语义化版本（Semantic Versioning），格式为 主版本.次版本.修订号，如 1.2.0。每次发布新版本时须递增。

参考文件

references/ 目录用于存放 Skill 执行过程中可能引用的辅助材料，如文档模板、格式示例、字典数据等。该目录中的文件将在 AI 调用 Skill 时作为上下文提供，无需额外配置即可生效。

3.2 Plugin（专家套件）规范

Plugin 以文件夹为单位，将多个 Skill、角色指令与 MCP 依赖组织为一个完整的岗位专家。

目录结构

<plugin-name>/
├── .qoder-plugin/           # 插件元数据目录（必需）
│   └── plugin.json          # 元数据清单（必需）
├── skills/                  # 技能目录（核心）
│   ├── 技能A/SKILL.md
│   └── 技能B/SKILL.md
├── agents/                  # subagent 角色配置（可选）
│   ├── agentA.md
│   └── agentB.md
├── .mcp.json                # MCP Connector 声明（可选）
├── qoder.md                 # 项目指令文件（可选，兼容 cursor.md / claude.md）
├── CONNECTORS.md            # Connector 依赖说明（可选）
└── README.md                # 插件说明文档（可选）

plugin.json 要点

plugin.json 声明了套件的名称、版本、所含技能清单及角色信息。命名建议为真实岗位名称，2–6 个汉字。

声明式 MCP Connector 配置（可选）

若套件内的 Skill 需要调用外部系统，可通过 .mcp.json 文件声明所需的 MCP Server 连接。用户安装套件时，QoderWork 将引导其完成对应的授权配置。

{
  "mcpServers": {
    "钉钉日志": {
      "type": "streamable-http",
      "url": "{{USER_CONFIG}}",
      "_setup": {
        "configUrl": "https://aihub.dingtalk.com/#/detail?mcpId=9639",
        "guide": "请访问上方链接登录钉钉，获取您的个人 MCP Server URL",
        "required": true
      }
    }
  }
}

各字段说明：

• type：传输协议，支持 streamable-http 与 stdio

• url：填写 {{USER_CONFIG}} 作为占位符，用户安装时由实际地址替换

• _setup.configUrl：引导用户获取凭证或地址的页面链接

• _setup.guide：向用户展示的配置说明文字

• _setup.required：是否为必填项；设为 true 时，用户未完成配置则无法使用该连接

该文件为可选项。若套件不依赖任何外部系统，可不提供。

3.3 Connector 规范与指南

Connector 本质为一台面向公网的 MCP Server，须满足以下技术与合规要求方可上架。

技术要求

• 服务地址须为 HTTPS，且为公开可达的稳定域名（不接受内网 IP 或临时隧道）

• 须实现完整的 OAuth 2.0 授权流程，确保用户授权可控且可撤销

• 工具（Tool）定义须具备清晰的名称与描述，参数应使用 JSON Schema 声明类型与约束

• 建议提供健康检查端点，以便平台监测服务可用性

提交指南

1. 完成 MCP Server 开发与部署后，在 QoderWork 中进入"我的发布 → 提交新拓展"，选择 Connector 类型

2. 填写公开信息（名称、简介、图标、分类），并提供 OAuth 授权入口地址

3. 上传自测报告，覆盖以下方面：连通性验证、至少三个典型工具调用的示例与结果、权限范围说明、异常处理策略、近 7 天的服务可用性数据

4. 配合完成公司身份核验（官方将通过电话确认上传人身份）

5. 提交后进入机审 + 人工终审流程，审核周期通常为 3–5 个工作日

注意事项

• 同一服务仅允许对应公司提交官方 Connector，第三方封装不予上架

• 已上架 Connector 的 OAuth scope 变更须重新提交审核

• 若服务长期不可用（连续 7 天以上），平台保留暂时下架的权利