數據庫客戶端桌面應用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 調用鏈共三個環(huán)節(jié)前端AIChatPanel組裝 system messages前端聲明本地固定工具LOCAL_TOOLS后端aiservice.Service只負責 Provider 配置、安全級別與模型轉發(fā)。從源碼可以印證這條鏈路的真實存在前端的會話組裝邏輯集中在 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 配置、安全級別與模型轉發(fā)能力具體配置讀寫由 internal/ai/service/config_store.go 承擔。這套結構已經足夠承接“用戶級提示詞”但要繼續(xù)承接 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加載時若版本不一致會觸發(fā)自動重寫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 診斷命令規(guī)劃場景面向診斷命令規(guī)劃類會話后端數據結構與這四個層級一一對應見 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、超時、啟用狀態(tài)由后端維護生命周期與連通性。mcp runtime bridge運行時橋接負責list tools / call tool / errors / timeout / auth等運行時交互。3.2 倉庫中已具備的實現基礎雖然路線文檔屬于“后續(xù)規(guī)劃”但當前倉庫已經落地了一部分基礎設施可以作為規(guī)劃的現實錨點配置層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如果后續(xù)確認需要”的規(guī)劃順序一致——stdio已就緒HTTP 類 transport 屬于待確認項。運行時層internal/mcpserver包已經實現了工具目錄與執(zhí)行橋接例如 internal/mcpserver/agent_catalog.go 中的AgentToolCatalog.List / Resolve / Execute以及 internal/mcpserver/composite_catalog.go 用于組合多個工具來源internal/mcpserver/dynamic_mcp_source.go 承載動態(tài) MCP 工具源。這可以推斷為“tool registry”與“mcp runtime bridge”的雛形。HTTP 方向MCPHTTPServerConfiginternal/ai/types.go保存內置 HTTP MCP 服務的偏好enabled / addr / path / schemaOnly其中 Token 明確“僅保存在 secret store不會序列化到 ai_config.json”。服務端形態(tài)見 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、工具注冊和運行時橋接單獨倉庫可選只有當你需要發(fā)布一個可復用的獨立 MCP Server時才值得例如gonavi-mcp-sql-tools、gonavi-mcp-jvm-agent這類獨立 server。一句話總結“客戶端支持 MCP”不需要新倉庫“某個獨立 MCP Server”是否拆倉庫取決于它要不要單獨發(fā)布、復用或部署。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 跑通等格式穩(wěn)定后再考慮增加“本地目錄導入”或“Git 倉庫導入”只有當你明確要做下面兩件事時獨立倉庫才值得把 Skills 當作社區(qū)共享資產分發(fā)讓不同團隊獨立維護自己的 skill pack。5. 建議的下一步實現順序路線文檔給出的推進次序如下可作為后續(xù)開發(fā)與擴展的參考路線抽出統一ToolRegistry讓LOCAL_TOOLS不再硬編碼在聊天面板內部——對應“tool registry”收口內置工具、本地擴展工具與 MCP 工具的目標對模型只暴露統一的tools[]在 AI 設置中新增MCP Servers配置頁——對應mcp server config層保存 server 名稱、transport、啟動命令或 URL、超時、啟用狀態(tài)后端先支持最小 transportstdiohttp/sse如果后續(xù)確認需要注當前倉庫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 包”的分發(fā)能力——只有明確要做社區(qū)共享資產分發(fā)或多團隊獨立維護 skill pack 時才值得引入獨立倉庫。6. 小結三層職責與倉庫邊界的判斷標準GoNavi 的 AI 擴展路線可以概括為一張三層職責表層職責承載位置現狀/規(guī)劃提示詞Prompt用戶級四場景定制運行時追加 system message已落地userPromptSettingsglobal/database/jvm/jvmDiagnostic編輯入口AISettingsModal工具Tools內置工具 本地擴展工具 MCP 工具統一注冊暴露統一tools[]規(guī)劃統一ToolRegistry現狀internal/mcpserver的 catalog 與動態(tài)工具源技能Skillsmanifest提示詞 工具依賴 使用入口按場景注入數據模型已落地SkillConfigid/name/description/systemPrompt/enabled/scopes/requiredTools運行時注入已實現倉庫邊界方面判斷標準始終是“是否要單獨發(fā)布、復用或部署”MCP 客戶端支持與 Skills runtime 留在主倉庫只有獨立的 MCP Server如gonavi-mcp-sql-tools或作為社區(qū)資產分發(fā)的 skill pack 才值得拆出獨立倉庫。這條路線既保持了客戶端 AI 能力的單一收口又為未來開放生態(tài)保留了清晰的分發(fā)邊界。贊分享數據庫客戶端桌面應用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終極指南創(chuàng)作聲明：本文部分內容由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 調用鏈共三個環(huán)節(jié)前端AIChatPanel組裝 system messages前端聲明本地固定工具LOCAL_TOOLS后端aiservice.Service只負責 Provider 配置、安全級別與模型轉發(fā)。從源碼可以印證這條鏈路的真實存在前端的會話組裝邏輯集中在 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 配置、安全級別與模型轉發(fā)能力具體配置讀寫由 internal/ai/service/config_store.go 承擔。這套結構已經足夠承接“用戶級提示詞”但要繼續(xù)承接 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加載時若版本不一致會觸發(fā)自動重寫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 診斷命令規(guī)劃場景面向診斷命令規(guī)劃類會話后端數據結構與這四個層級一一對應見 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、超時、啟用狀態(tài)由后端維護生命周期與連通性。mcp runtime bridge運行時橋接負責list tools / call tool / errors / timeout / auth等運行時交互。3.2 倉庫中已具備的實現基礎雖然路線文檔屬于“后續(xù)規(guī)劃”但當前倉庫已經落地了一部分基礎設施可以作為規(guī)劃的現實錨點配置層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如果后續(xù)確認需要”的規(guī)劃順序一致——stdio已就緒HTTP 類 transport 屬于待確認項。運行時層internal/mcpserver包已經實現了工具目錄與執(zhí)行橋接例如 internal/mcpserver/agent_catalog.go 中的AgentToolCatalog.List / Resolve / Execute以及 internal/mcpserver/composite_catalog.go 用于組合多個工具來源internal/mcpserver/dynamic_mcp_source.go 承載動態(tài) MCP 工具源。這可以推斷為“tool registry”與“mcp runtime bridge”的雛形。HTTP 方向MCPHTTPServerConfiginternal/ai/types.go保存內置 HTTP MCP 服務的偏好enabled / addr / path / schemaOnly其中 Token 明確“僅保存在 secret store不會序列化到 ai_config.json”。服務端形態(tài)見 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、工具注冊和運行時橋接單獨倉庫可選只有當你需要發(fā)布一個可復用的獨立 MCP Server時才值得例如gonavi-mcp-sql-tools、gonavi-mcp-jvm-agent這類獨立 server。一句話總結“客戶端支持 MCP”不需要新倉庫“某個獨立 MCP Server”是否拆倉庫取決于它要不要單獨發(fā)布、復用或部署。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 跑通等格式穩(wěn)定后再考慮增加“本地目錄導入”或“Git 倉庫導入”只有當你明確要做下面兩件事時獨立倉庫才值得把 Skills 當作社區(qū)共享資產分發(fā)讓不同團隊獨立維護自己的 skill pack。5. 建議的下一步實現順序路線文檔給出的推進次序如下可作為后續(xù)開發(fā)與擴展的參考路線抽出統一ToolRegistry讓LOCAL_TOOLS不再硬編碼在聊天面板內部——對應“tool registry”收口內置工具、本地擴展工具與 MCP 工具的目標對模型只暴露統一的tools[]在 AI 設置中新增MCP Servers配置頁——對應mcp server config層保存 server 名稱、transport、啟動命令或 URL、超時、啟用狀態(tài)后端先支持最小 transportstdiohttp/sse如果后續(xù)確認需要注當前倉庫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 包”的分發(fā)能力——只有明確要做社區(qū)共享資產分發(fā)或多團隊獨立維護 skill pack 時才值得引入獨立倉庫。6. 小結三層職責與倉庫邊界的判斷標準GoNavi 的 AI 擴展路線可以概括為一張三層職責表層職責承載位置現狀/規(guī)劃提示詞Prompt用戶級四場景定制運行時追加 system message已落地userPromptSettingsglobal/database/jvm/jvmDiagnostic編輯入口AISettingsModal工具Tools內置工具 本地擴展工具 MCP 工具統一注冊暴露統一tools[]規(guī)劃統一ToolRegistry現狀internal/mcpserver的 catalog 與動態(tài)工具源技能Skillsmanifest提示詞 工具依賴 使用入口按場景注入數據模型已落地SkillConfigid/name/description/systemPrompt/enabled/scopes/requiredTools運行時注入已實現倉庫邊界方面判斷標準始終是“是否要單獨發(fā)布、復用或部署”MCP 客戶端支持與 Skills runtime 留在主倉庫只有獨立的 MCP Server如gonavi-mcp-sql-tools或作為社區(qū)資產分發(fā)的 skill pack 才值得拆出獨立倉庫。這條路線既保持了客戶端 AI 能力的單一收口又為未來開放生態(tài)保留了清晰的分發(fā)邊界。贊分享數據庫客戶端桌面應用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終極指南創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考