尧图网页设计 
数据库客户端桌面应用MCP 服务【免费下载链接】GoNaviHigh-performance multi-data-source database client — ~30MB, AI MCP ready, zero Electron bloat. | 高性能多数据源数据库客户端约 30MBAI 与 MCP 就绪告别 Electron 膨胀。项目地址https://gitcode.com/gh_mirrors/go/GoNavi点击查看免费下载本文基于 GoNavi 仓库中的 AI_EXTENSIONS_ROADMAP.md 展开解析 GoNavi 当前 AI 链路的组成与职责边界并沿着“提示词 / 工具 / 技能”三层拆分的路线梳理用户级自定义提示词、MCP 能力开放与 Skills 设计的落地方式、数据模型与源码佐证。读完本文你将掌握 GoNavi 的 AI 配置结构ai_config.json、四个提示词作用域、MCP 工具注册与桥接的架构分层以及 Skill 从 manifest 到运行时注入 system message 的完整实现路径。1. 现状GoNavi 当前的 AI 链路路线文档首先明确了当前 GoNavi 的 AI 调用链共三个环节前端AIChatPanel组装 system messages前端声明本地固定工具LOCAL_TOOLS后端aiservice.Service只负责 Provider 配置、安全级别与模型转发。从源码可以印证这条链路的真实存在前端的会话组装逻辑集中在 frontend/src/components/AIChatPanel.tsx 及其子模块 frontend/src/components/ai/AIChatPanelModeContent.tsx而系统消息的构造在 frontend/src/components/ai/aiSystemContextMessages.ts 中实现——该文件定义了AISystemContextMessagerole: systemcontent结构并把用户提示词、Skills 逐条追加进 system 消息数组。后端方面internal/ai/service/service.go 中的Service持有 provider 配置、安全级别与模型转发能力具体配置读写由 internal/ai/service/config_store.go 承担。这套结构已经足够承接“用户级提示词”但要继续承接 MCP 和 Skills需要先把“提示词 / 工具 / 技能”三层职责拆开——这正是路线文档的核心论点。2. 第一层用户级自定义提示词已落地2.1 配置存储与编辑入口用户级提示词是三层中唯一已落地的方向三个关键事实如下配置存储存放在ai_config.json的userPromptSettings字段。对应后端结构见 internal/ai/service/config_store.go 中的aiConfig其中UserPromptSettings ai.UserPromptSettings以json:userPromptSettings,omitempty持久化该文件顶部还定义了配置文件的 schema 版本常量aiConfigSchemaVersion 6加载时若版本不一致会触发自动重写shouldRewrite。编辑入口由AISettingsModal提供前端实现见 frontend/src/components/AISettingsModal.tsx提示词编辑子面板位于 frontend/src/components/ai/AISettingsPromptsSection.tsx。运行时注入由AIChatPanel在运行时把用户提示词追加为 system message。前端组装逻辑见 frontend/src/components/ai/aiSystemContextMessages.ts其中appendCustomPromptGroup按作用域把userPromptSettings.global / database / jvm / jvmDiagnostic分别注入到对应场景的 system 消息中。2.2 四个提示词层级路线文档建议长期保持 4 个层级前端与后端的实现已经完全对齐层级适用场景说明global所有 AI 会话统一追加承载“个人习惯”类定制database数据库 / SQL 场景面向查询编辑与 SQL 分析会话jvmJVM 资源浏览与分析场景面向 JVM 内存、线程等浏览分析jvmDiagnosticJVM 诊断命令规划场景面向诊断命令规划类会话后端数据结构与这四个层级一一对应见 internal/ai/types.go// UserPromptSettings 表示用户级自定义提示词配置 type UserPromptSettings struct { Global string json:global Database string json:database JVM string json:jvm JVMDiagnostic string json:jvmDiagnostic }保存与读取通过两个后端方法暴露给前端见 internal/ai/service/service.goAIGetUserPromptSettings()返回当前用户级提示词配置AISaveUserPromptSettings(settings)先经过normalizeUserPromptSettings归一化再写入配置。对应的持久化行为在 internal/ai/service/config_store_test.go 的TestProviderConfigStoreSaveAndLoadUserPromptSettings中覆盖了“保存后再加载应完全一致”的往返校验。前端 system 消息注入的对应实现与测试位于 frontend/src/components/ai/aiSystemContextMessages.ts 与 frontend/src/components/ai/aiSystemContextMessages.test.ts。保持 4 层而不是“一条超长总提示词”的好处既满足个人习惯定制又不会把所有场景揉成一条过长提示词避免上下文预算被无关指令占用。3. 第二层MCP 能力开放路线文档明确了一个关键定位目标不是把 MCP 做成新的聊天面板而是把它变成“外部工具源”。围绕这个定位建议拆成三层3.1 三层架构建议tool registry工具注册表统一收口内置工具、本地扩展工具、MCP 工具对模型只暴露统一的tools[]屏蔽工具来源差异。mcp server config服务配置保存 server 名称、transport、启动命令或 URL、超时、启用状态由后端维护生命周期与连通性。mcp runtime bridge运行时桥接负责list tools / call tool / errors / timeout / auth等运行时交互。3.2 仓库中已具备的实现基础虽然路线文档属于“后续规划”但当前仓库已经落地了一部分基础设施可以作为规划的现实锚点配置层ai_config.json的aiConfig已包含MCPServers []ai.MCPServerConfig与MCPHTTPServer ai.MCPHTTPServerConfig两个字段internal/ai/service/config_store.go。MCPServerConfig的结构与路线文档建议的配置项高度吻合见 internal/ai/types.go// MCPServerConfig 表示一个可配置的 MCP 服务 type MCPServerConfig struct { ID string json:id Name string json:name Transport MCPTransport json:transport Command string json:command Args []string json:args,omitempty Env map[string]string json:env,omitempty Enabled bool json:enabled TimeoutSeconds int json:timeoutSeconds }注意其中Transport的类型MCPTransport目前只定义了stdio一种常量见 internal/ai/types.go这与路线文档“后端先支持最小 transportstdio、http/sse如果后续确认需要”的规划顺序一致——stdio已就绪HTTP 类 transport 属于待确认项。运行时层internal/mcpserver包已经实现了工具目录与执行桥接例如 internal/mcpserver/agent_catalog.go 中的AgentToolCatalog.List / Resolve / Execute以及 internal/mcpserver/composite_catalog.go 用于组合多个工具来源internal/mcpserver/dynamic_mcp_source.go 承载动态 MCP 工具源。这可以推断为“tool registry”与“mcp runtime bridge”的雏形。HTTP 方向MCPHTTPServerConfiginternal/ai/types.go保存内置 HTTP MCP 服务的偏好enabled / addr / path / schemaOnly其中 Token 明确“仅保存在 secret store不会序列化到 ai_config.json”。服务端形态见 cmd/gonavi-mcp-server/README.md本机客户端默认走stdio云端 Agent 可通过显式开启的 Streamable HTTP 模式接入。工具面cmd/gonavi-mcp-server当前提供的 MCP tools 包括get_connections、get_databases、get_tables、get_views、get_objects、get_columns、get_table_ddl、execute_sql其中execute_sql与内置 AI 助手共用“安全控制”分级只读仅查询 / 读写可 DML / 完全可 DDL且可用--schema-only启动纯元数据模式不注册execute_sql。这直接体现了“把数据库能力通过 MCP 暴露给外部客户端”的产品方向。3.3 MCP 是否需要单独 GitHub 仓库路线文档给出的结论非常明确不需要把“GoNavi 对 MCP 的支持”单独拆仓库。更合理的边界是GoNavi 主仓库维护 MCP client、配置、UI、工具注册和运行时桥接单独仓库可选只有当你需要发布一个可复用的独立 MCP Server时才值得例如gonavi-mcp-sql-tools、gonavi-mcp-jvm-agent这类独立 server。一句话总结“客户端支持 MCP”不需要新仓库“某个独立 MCP Server”是否拆仓库取决于它要不要单独发布、复用或部署。4. 第三层Skills 设计4.1 Skills 不等于“另一种提示词”路线文档反复强调Skills 不建议直接等同于“另一种提示词”其本质是“提示词 工具依赖 使用入口”的组合而不是单独一段文案。建议的四要素如下skill manifest技能清单名称、说明、适用场景、是否默认启用skill prompt技能提示词该技能追加的 system prompt / few-shot / 输出约束skill tool requirements工具依赖该技能依赖哪些内置工具或 MCP 工具skill shortcuts快捷入口可选给欢迎卡片、斜杠命令或快速动作提供入口。4.2 仓库中的 Skill 数据模型SkillConfig已经按 manifest 思路落地见 internal/ai/types.go// SkillConfig 表示一个可配置的 Skill type SkillConfig struct { ID string json:id Name string json:name Description string json:description,omitempty SystemPrompt string json:systemPrompt Enabled bool json:enabled Scopes []string json:scopes,omitempty RequiredTools []string json:requiredTools,omitempty }与路线文档“Skill 以 manifest 形式声明id / name / description / systemPrompt / requiredTools / scopes”的清单完全一致。同时 Skill 的作用域枚举也复用了提示词的四个层级见 internal/ai/types.goconst ( SkillScopeGlobal SkillScope global SkillScopeDatabase SkillScope database SkillScopeJVM SkillScope jvm SkillScopeJVMDiagnostic SkillScope jvmDiagnostic )配置持久化方面aiConfig与ProviderConfigStoreSnapshot均包含Skills []ai.SkillConfiginternal/ai/service/config_store.go对应测试见 internal/ai/service/config_store_test.go构造了Scopes: []string{string(ai.SkillScopeDatabase)}的 Skill 场景。4.3 Skill 的运行时注入逻辑前端在组装 system messages 时会按作用域与工具依赖过滤并注入 Skill核心实现在 frontend/src/components/ai/aiSystemContextMessages.ts 的appendSkillPromptGroup启用过滤skill?.enabled为 false 直接跳过作用域匹配skill.scopes必须与当前会话场景global / database / jvm / jvmDiagnostic有交集才注入工具依赖校验若声明了requiredTools要求每个工具名都出现在当前可用工具集合availableToolNameSet中否则不注入注入格式以 “The active Skill {{skillName}} applies to this response. Follow its constraints and workflow” 的形式把description、requiredTools与systemPrompt拼入 system message。这一实现把路线文档的“skill prompt”与“skill tool requirements”落到了运行时Skill 只有在场景匹配且工具齐全时才会真正生效避免给模型挂上无工具支撑的约束。编辑侧 UI 见 frontend/src/components/ai/AISettingsSkillsSection.tsx测试见 frontend/src/components/ai/AISettingsSkillsSection.test.tsx其中明确校验了“Skill 不是另一条大提示词”“选择这个 Skill 要作用到哪些场景”“可选声明这个 Skill 依赖哪些工具”等表单语义。4.4 Skills 是否需要单独 GitHub 仓库路线文档给出的建议顺序第一阶段不需要独立仓库——先在 GoNavi 主仓库内把 Skills manifest/runtime 跑通等格式稳定后再考虑增加“本地目录导入”或“Git 仓库导入”只有当你明确要做下面两件事时独立仓库才值得把 Skills 当作社区共享资产分发让不同团队独立维护自己的 skill pack。5. 建议的下一步实现顺序路线文档给出的推进次序如下可作为后续开发与扩展的参考路线抽出统一ToolRegistry让LOCAL_TOOLS不再硬编码在聊天面板内部——对应“tool registry”收口内置工具、本地扩展工具与 MCP 工具的目标对模型只暴露统一的tools[]在 AI 设置中新增MCP Servers配置页——对应mcp server config层保存 server 名称、transport、启动命令或 URL、超时、启用状态后端先支持最小 transportstdiohttp/sse如果后续确认需要注当前仓库MCPTransport枚举已含stdiointernal/ai/types.goHTTP 侧已存在内置 Streamable HTTP server 的配置结构MCPHTTPServerConfig可以作为扩展基础在 AI 设置中新增Skills配置页——SkillConfig数据模型与前端AISettingsSkillsSection已具备雏形让 Skill 以 manifest 形式声明id、name、description、systemPrompt、requiredTools、scopes——与当前SkillConfig字段一一对应再决定是否增加“从 Git 仓库同步 MCP/Skills 包”的分发能力——只有明确要做社区共享资产分发或多团队独立维护 skill pack 时才值得引入独立仓库。6. 小结三层职责与仓库边界的判断标准GoNavi 的 AI 扩展路线可以概括为一张三层职责表层职责承载位置现状/规划提示词Prompt用户级四场景定制运行时追加 system message已落地userPromptSettingsglobal/database/jvm/jvmDiagnostic编辑入口AISettingsModal工具Tools内置工具 本地扩展工具 MCP 工具统一注册暴露统一tools[]规划统一ToolRegistry现状internal/mcpserver的 catalog 与动态工具源技能Skillsmanifest提示词 工具依赖 使用入口按场景注入数据模型已落地SkillConfigid/name/description/systemPrompt/enabled/scopes/requiredTools运行时注入已实现仓库边界方面判断标准始终是“是否要单独发布、复用或部署”MCP 客户端支持与 Skills runtime 留在主仓库只有独立的 MCP Server如gonavi-mcp-sql-tools或作为社区资产分发的 skill pack 才值得拆出独立仓库。这条路线既保持了客户端 AI 能力的单一收口又为未来开放生态保留了清晰的分发边界。赞分享数据库客户端桌面应用MCP 服务【免费下载链接】GoNaviHigh-performance multi-data-source database client — ~30MB, AI MCP ready, zero Electron bloat. | 高性能多数据源数据库客户端约 30MBAI 与 MCP 就绪告别 Electron 膨胀。项目地址https://gitcode.com/gh_mirrors/go/GoNavi点击查看免费下载相关推荐ai-guide 项目 Vibe Coding 资源大全一站式 AI 工具、提示词、MCP/Skills 与学习资源导航指南ai guide 项目 Vibe Coding 资源大全一站式 AI 工具、提示词、MCP/Skills 与学习资源导航指南 本指南以 ai guide 仓库文档教程知识库人工智能深入 Gemini CLI 的 MCP Server 扩展模板从 mcp-server 示例读懂扩展如何向 CLI 暴露工具与提示词深入 Gemini CLI 的 MCP Server 扩展模板从 mcp server 示例读懂扩展如何向 CLI 暴露工具与提示词 本文以 Gemini C人工智能AI Agent交互助手CLIMCP ClientsSSD-1B-openmind与AUTOMATIC1111兼容性详解无缝AI绘图体验指南SSD 1B openmind与AUTOMATIC1111兼容性详解无缝AI绘图体验指南 SSD 1B openmind是一款高效的AI绘图模型而AUTOM上一篇如何用开源工具实现40平台直播自动录制告别错过直播的终极指南下一篇免费开源的AMD Ryzen调试工具SMUDebugTool终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GoNavi AI 扩展能力路线：用户级提示词、MCP 工具源与 Skills 三层架构实践
数据库客户端桌面应用MCP 服务【免费下载链接】GoNaviHigh-performance multi-data-source database client — ~30MB, AI MCP ready, zero Electron bloat. | 高性能多数据源数据库客户端约 30MBAI 与 MCP 就绪告别 Electron 膨胀。项目地址https://gitcode.com/gh_mirrors/go/GoNavi点击查看免费下载本文基于 GoNavi 仓库中的 AI_EXTENSIONS_ROADMAP.md 展开解析 GoNavi 当前 AI 链路的组成与职责边界并沿着“提示词 / 工具 / 技能”三层拆分的路线梳理用户级自定义提示词、MCP 能力开放与 Skills 设计的落地方式、数据模型与源码佐证。读完本文你将掌握 GoNavi 的 AI 配置结构ai_config.json、四个提示词作用域、MCP 工具注册与桥接的架构分层以及 Skill 从 manifest 到运行时注入 system message 的完整实现路径。1. 现状GoNavi 当前的 AI 链路路线文档首先明确了当前 GoNavi 的 AI 调用链共三个环节前端AIChatPanel组装 system messages前端声明本地固定工具LOCAL_TOOLS后端aiservice.Service只负责 Provider 配置、安全级别与模型转发。从源码可以印证这条链路的真实存在前端的会话组装逻辑集中在 frontend/src/components/AIChatPanel.tsx 及其子模块 frontend/src/components/ai/AIChatPanelModeContent.tsx而系统消息的构造在 frontend/src/components/ai/aiSystemContextMessages.ts 中实现——该文件定义了AISystemContextMessagerole: systemcontent结构并把用户提示词、Skills 逐条追加进 system 消息数组。后端方面internal/ai/service/service.go 中的Service持有 provider 配置、安全级别与模型转发能力具体配置读写由 internal/ai/service/config_store.go 承担。这套结构已经足够承接“用户级提示词”但要继续承接 MCP 和 Skills需要先把“提示词 / 工具 / 技能”三层职责拆开——这正是路线文档的核心论点。2. 第一层用户级自定义提示词已落地2.1 配置存储与编辑入口用户级提示词是三层中唯一已落地的方向三个关键事实如下配置存储存放在ai_config.json的userPromptSettings字段。对应后端结构见 internal/ai/service/config_store.go 中的aiConfig其中UserPromptSettings ai.UserPromptSettings以json:userPromptSettings,omitempty持久化该文件顶部还定义了配置文件的 schema 版本常量aiConfigSchemaVersion 6加载时若版本不一致会触发自动重写shouldRewrite。编辑入口由AISettingsModal提供前端实现见 frontend/src/components/AISettingsModal.tsx提示词编辑子面板位于 frontend/src/components/ai/AISettingsPromptsSection.tsx。运行时注入由AIChatPanel在运行时把用户提示词追加为 system message。前端组装逻辑见 frontend/src/components/ai/aiSystemContextMessages.ts其中appendCustomPromptGroup按作用域把userPromptSettings.global / database / jvm / jvmDiagnostic分别注入到对应场景的 system 消息中。2.2 四个提示词层级路线文档建议长期保持 4 个层级前端与后端的实现已经完全对齐层级适用场景说明global所有 AI 会话统一追加承载“个人习惯”类定制database数据库 / SQL 场景面向查询编辑与 SQL 分析会话jvmJVM 资源浏览与分析场景面向 JVM 内存、线程等浏览分析jvmDiagnosticJVM 诊断命令规划场景面向诊断命令规划类会话后端数据结构与这四个层级一一对应见 internal/ai/types.go// UserPromptSettings 表示用户级自定义提示词配置 type UserPromptSettings struct { Global string json:global Database string json:database JVM string json:jvm JVMDiagnostic string json:jvmDiagnostic }保存与读取通过两个后端方法暴露给前端见 internal/ai/service/service.goAIGetUserPromptSettings()返回当前用户级提示词配置AISaveUserPromptSettings(settings)先经过normalizeUserPromptSettings归一化再写入配置。对应的持久化行为在 internal/ai/service/config_store_test.go 的TestProviderConfigStoreSaveAndLoadUserPromptSettings中覆盖了“保存后再加载应完全一致”的往返校验。前端 system 消息注入的对应实现与测试位于 frontend/src/components/ai/aiSystemContextMessages.ts 与 frontend/src/components/ai/aiSystemContextMessages.test.ts。保持 4 层而不是“一条超长总提示词”的好处既满足个人习惯定制又不会把所有场景揉成一条过长提示词避免上下文预算被无关指令占用。3. 第二层MCP 能力开放路线文档明确了一个关键定位目标不是把 MCP 做成新的聊天面板而是把它变成“外部工具源”。围绕这个定位建议拆成三层3.1 三层架构建议tool registry工具注册表统一收口内置工具、本地扩展工具、MCP 工具对模型只暴露统一的tools[]屏蔽工具来源差异。mcp server config服务配置保存 server 名称、transport、启动命令或 URL、超时、启用状态由后端维护生命周期与连通性。mcp runtime bridge运行时桥接负责list tools / call tool / errors / timeout / auth等运行时交互。3.2 仓库中已具备的实现基础虽然路线文档属于“后续规划”但当前仓库已经落地了一部分基础设施可以作为规划的现实锚点配置层ai_config.json的aiConfig已包含MCPServers []ai.MCPServerConfig与MCPHTTPServer ai.MCPHTTPServerConfig两个字段internal/ai/service/config_store.go。MCPServerConfig的结构与路线文档建议的配置项高度吻合见 internal/ai/types.go// MCPServerConfig 表示一个可配置的 MCP 服务 type MCPServerConfig struct { ID string json:id Name string json:name Transport MCPTransport json:transport Command string json:command Args []string json:args,omitempty Env map[string]string json:env,omitempty Enabled bool json:enabled TimeoutSeconds int json:timeoutSeconds }注意其中Transport的类型MCPTransport目前只定义了stdio一种常量见 internal/ai/types.go这与路线文档“后端先支持最小 transportstdio、http/sse如果后续确认需要”的规划顺序一致——stdio已就绪HTTP 类 transport 属于待确认项。运行时层internal/mcpserver包已经实现了工具目录与执行桥接例如 internal/mcpserver/agent_catalog.go 中的AgentToolCatalog.List / Resolve / Execute以及 internal/mcpserver/composite_catalog.go 用于组合多个工具来源internal/mcpserver/dynamic_mcp_source.go 承载动态 MCP 工具源。这可以推断为“tool registry”与“mcp runtime bridge”的雏形。HTTP 方向MCPHTTPServerConfiginternal/ai/types.go保存内置 HTTP MCP 服务的偏好enabled / addr / path / schemaOnly其中 Token 明确“仅保存在 secret store不会序列化到 ai_config.json”。服务端形态见 cmd/gonavi-mcp-server/README.md本机客户端默认走stdio云端 Agent 可通过显式开启的 Streamable HTTP 模式接入。工具面cmd/gonavi-mcp-server当前提供的 MCP tools 包括get_connections、get_databases、get_tables、get_views、get_objects、get_columns、get_table_ddl、execute_sql其中execute_sql与内置 AI 助手共用“安全控制”分级只读仅查询 / 读写可 DML / 完全可 DDL且可用--schema-only启动纯元数据模式不注册execute_sql。这直接体现了“把数据库能力通过 MCP 暴露给外部客户端”的产品方向。3.3 MCP 是否需要单独 GitHub 仓库路线文档给出的结论非常明确不需要把“GoNavi 对 MCP 的支持”单独拆仓库。更合理的边界是GoNavi 主仓库维护 MCP client、配置、UI、工具注册和运行时桥接单独仓库可选只有当你需要发布一个可复用的独立 MCP Server时才值得例如gonavi-mcp-sql-tools、gonavi-mcp-jvm-agent这类独立 server。一句话总结“客户端支持 MCP”不需要新仓库“某个独立 MCP Server”是否拆仓库取决于它要不要单独发布、复用或部署。4. 第三层Skills 设计4.1 Skills 不等于“另一种提示词”路线文档反复强调Skills 不建议直接等同于“另一种提示词”其本质是“提示词 工具依赖 使用入口”的组合而不是单独一段文案。建议的四要素如下skill manifest技能清单名称、说明、适用场景、是否默认启用skill prompt技能提示词该技能追加的 system prompt / few-shot / 输出约束skill tool requirements工具依赖该技能依赖哪些内置工具或 MCP 工具skill shortcuts快捷入口可选给欢迎卡片、斜杠命令或快速动作提供入口。4.2 仓库中的 Skill 数据模型SkillConfig已经按 manifest 思路落地见 internal/ai/types.go// SkillConfig 表示一个可配置的 Skill type SkillConfig struct { ID string json:id Name string json:name Description string json:description,omitempty SystemPrompt string json:systemPrompt Enabled bool json:enabled Scopes []string json:scopes,omitempty RequiredTools []string json:requiredTools,omitempty }与路线文档“Skill 以 manifest 形式声明id / name / description / systemPrompt / requiredTools / scopes”的清单完全一致。同时 Skill 的作用域枚举也复用了提示词的四个层级见 internal/ai/types.goconst ( SkillScopeGlobal SkillScope global SkillScopeDatabase SkillScope database SkillScopeJVM SkillScope jvm SkillScopeJVMDiagnostic SkillScope jvmDiagnostic )配置持久化方面aiConfig与ProviderConfigStoreSnapshot均包含Skills []ai.SkillConfiginternal/ai/service/config_store.go对应测试见 internal/ai/service/config_store_test.go构造了Scopes: []string{string(ai.SkillScopeDatabase)}的 Skill 场景。4.3 Skill 的运行时注入逻辑前端在组装 system messages 时会按作用域与工具依赖过滤并注入 Skill核心实现在 frontend/src/components/ai/aiSystemContextMessages.ts 的appendSkillPromptGroup启用过滤skill?.enabled为 false 直接跳过作用域匹配skill.scopes必须与当前会话场景global / database / jvm / jvmDiagnostic有交集才注入工具依赖校验若声明了requiredTools要求每个工具名都出现在当前可用工具集合availableToolNameSet中否则不注入注入格式以 “The active Skill {{skillName}} applies to this response. Follow its constraints and workflow” 的形式把description、requiredTools与systemPrompt拼入 system message。这一实现把路线文档的“skill prompt”与“skill tool requirements”落到了运行时Skill 只有在场景匹配且工具齐全时才会真正生效避免给模型挂上无工具支撑的约束。编辑侧 UI 见 frontend/src/components/ai/AISettingsSkillsSection.tsx测试见 frontend/src/components/ai/AISettingsSkillsSection.test.tsx其中明确校验了“Skill 不是另一条大提示词”“选择这个 Skill 要作用到哪些场景”“可选声明这个 Skill 依赖哪些工具”等表单语义。4.4 Skills 是否需要单独 GitHub 仓库路线文档给出的建议顺序第一阶段不需要独立仓库——先在 GoNavi 主仓库内把 Skills manifest/runtime 跑通等格式稳定后再考虑增加“本地目录导入”或“Git 仓库导入”只有当你明确要做下面两件事时独立仓库才值得把 Skills 当作社区共享资产分发让不同团队独立维护自己的 skill pack。5. 建议的下一步实现顺序路线文档给出的推进次序如下可作为后续开发与扩展的参考路线抽出统一ToolRegistry让LOCAL_TOOLS不再硬编码在聊天面板内部——对应“tool registry”收口内置工具、本地扩展工具与 MCP 工具的目标对模型只暴露统一的tools[]在 AI 设置中新增MCP Servers配置页——对应mcp server config层保存 server 名称、transport、启动命令或 URL、超时、启用状态后端先支持最小 transportstdiohttp/sse如果后续确认需要注当前仓库MCPTransport枚举已含stdiointernal/ai/types.goHTTP 侧已存在内置 Streamable HTTP server 的配置结构MCPHTTPServerConfig可以作为扩展基础在 AI 设置中新增Skills配置页——SkillConfig数据模型与前端AISettingsSkillsSection已具备雏形让 Skill 以 manifest 形式声明id、name、description、systemPrompt、requiredTools、scopes——与当前SkillConfig字段一一对应再决定是否增加“从 Git 仓库同步 MCP/Skills 包”的分发能力——只有明确要做社区共享资产分发或多团队独立维护 skill pack 时才值得引入独立仓库。6. 小结三层职责与仓库边界的判断标准GoNavi 的 AI 扩展路线可以概括为一张三层职责表层职责承载位置现状/规划提示词Prompt用户级四场景定制运行时追加 system message已落地userPromptSettingsglobal/database/jvm/jvmDiagnostic编辑入口AISettingsModal工具Tools内置工具 本地扩展工具 MCP 工具统一注册暴露统一tools[]规划统一ToolRegistry现状internal/mcpserver的 catalog 与动态工具源技能Skillsmanifest提示词 工具依赖 使用入口按场景注入数据模型已落地SkillConfigid/name/description/systemPrompt/enabled/scopes/requiredTools运行时注入已实现仓库边界方面判断标准始终是“是否要单独发布、复用或部署”MCP 客户端支持与 Skills runtime 留在主仓库只有独立的 MCP Server如gonavi-mcp-sql-tools或作为社区资产分发的 skill pack 才值得拆出独立仓库。这条路线既保持了客户端 AI 能力的单一收口又为未来开放生态保留了清晰的分发边界。赞分享数据库客户端桌面应用MCP 服务【免费下载链接】GoNaviHigh-performance multi-data-source database client — ~30MB, AI MCP ready, zero Electron bloat. | 高性能多数据源数据库客户端约 30MBAI 与 MCP 就绪告别 Electron 膨胀。项目地址https://gitcode.com/gh_mirrors/go/GoNavi点击查看免费下载相关推荐ai-guide 项目 Vibe Coding 资源大全一站式 AI 工具、提示词、MCP/Skills 与学习资源导航指南ai guide 项目 Vibe Coding 资源大全一站式 AI 工具、提示词、MCP/Skills 与学习资源导航指南 本指南以 ai guide 仓库文档教程知识库人工智能深入 Gemini CLI 的 MCP Server 扩展模板从 mcp-server 示例读懂扩展如何向 CLI 暴露工具与提示词深入 Gemini CLI 的 MCP Server 扩展模板从 mcp server 示例读懂扩展如何向 CLI 暴露工具与提示词 本文以 Gemini C人工智能AI Agent交互助手CLIMCP ClientsSSD-1B-openmind与AUTOMATIC1111兼容性详解无缝AI绘图体验指南SSD 1B openmind与AUTOMATIC1111兼容性详解无缝AI绘图体验指南 SSD 1B openmind是一款高效的AI绘图模型而AUTOM上一篇如何用开源工具实现40平台直播自动录制告别错过直播的终极指南下一篇免费开源的AMD Ryzen调试工具SMUDebugTool终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考