CodeCompanion 内置 LSP 诊断解释 Promptlsp.md实战指南从选区到 AI 调试【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim在 Neovim 中面对一屏编译错误、lint 告警时CodeCompanion 的 prompt library 内置了一个专门针对 LSP 诊断的 Prompt——lsp.md。它会在 Visual 模式下将当前选区的诊断消息连同语言类型一并交给 AI让它扮演调试助手逐条解释并给出带语法高亮的修复代码。本文以该内置 Prompt 为骨架结合仓库源码拆解它的 YAML frontmatter、模板占位符、底层诊断采集逻辑并给出从调用方式到自定义扩展的完整实战方案读完你将能直接对选区跑 LSP 诊断解释也能照着它写出属于自己的诊断类 Prompt。内置 Prompt 全貌lsp.md在仓库中的位置与作用CodeCompanion 的 prompt library 分两类来源一类是用户通过配置项prompt_library.markdown.dirs指定的自定义 Markdown Prompt见 config.lua另一类就是插件自带的 builtin 集合。本篇文章的主角位于模板文件lua/codecompanion/prompt_library/builtins/lsp.md配套占位符实现lua/codecompanion/prompt_library/builtins/lsp.lua与同目录下的fix.md修复选中代码、explain.md解释选中代码共同构成一套选中即用的代码辅助 Prompt。lsp.md的特殊之处在于它不把选中代码本身发给模型而是只发送该选区内的 LSP 诊断消息列表——模型的输入是诊断问题清单而非代码原文从而把 AI 的注意力直接聚焦在报错上。frontmatter 逐项拆解lsp.md的 YAML 元数据语义lsp.md开头是一段 YAML frontmatter它是整个 Prompt 的元数据卡prompt library 的解析器通过 markdown.lua 的 parse_frontmatter依赖yamltreesitter parser读取。逐字段说明如下字段取值语义nameExplain LSP diagnosticsPrompt 显示名称会出现在 Action Palette 等入口interactionchat交互类型标记为聊天式交互descriptionExplain the LSP diagnostics for the selected code用途描述供 picker 检索展示opts.aliaslspPrompt 别名可用于 keymap 与 slash command 引用opts.is_slash_cmdfalse是否作为内置斜杠命令暴露opts.modes[v]仅在 Visual 模式下可用opts.stop_context_insertiontrue阻止当前 buffer 上下文自动插入保证发送给模型的只有诊断信息值得注意stop_context_insertion: true的作用CodeCompanion 默认会在聊天中附加编辑器上下文代码、文件树等而本 Prompt 希望模型只看诊断列表因此主动关闭上下文插入避免诊断之外的无关代码干扰模型判断。对照同目录的 fix.md 与 explain.md它们也都声明了modes: [v]与stop_context_insertion: true但fix.md额外设置了auto_submit: true自动提交与explain.md的is_slash_cmd: true——可见同类 Prompt 之间在调度行为上的差异完全由 frontmatter 控制。模板占位符解析${context.filetype}与${lsp.diagnostics}的填充机制lsp.md的正文只有两段## system与## user这与 prompt library 的解析约定一致——## system段被识别为 SYSTEM_ROLE、## user段被识别为 USER_ROLE见 markdown.lua 与 parse_prompt 的 role 捕获逻辑。user 段正文The programming language is ${context.filetype}. This is a list of the diagnostic messages: ${lsp.diagnostics}两个占位符的解析链路如下${context.filetype}来自调用时的 BufferContext 上下文对象由 prompt library 的resolve_placeholdersmarkdown.lua通过点号记法解析先按占位符第一段context、lsp尝试从 Prompt 同目录加载同名 Lua 文件再把该表挂到args上后解析嵌套值。context.filetype直接命中上下文自带的文件类型。${lsp.diagnostics}点号第一段lsp会触发加载同目录下的 lsp.lua该文件返回{ diagnostics function(args) ... end }然后以args携带context调用该函数其返回值即诊断文本。这就是Markdown 模板 同目录 Lua 函数的组合模式模板负责定义措辞Lua 文件负责运行时数据采集二者通过${name.func}占位符衔接。源码级原理get_diagnostics如何采集选区诊断lsp.lua的核心只有一段diagnostics函数它调用require(codecompanion.helpers.code).get_diagnostics( args.context.start_line, args.context.end_line, args.context.bufnr )真正的采集逻辑在 lua/codecompanion/helpers/code.lua 的 get_diagnostics该实现参考自piersolenski/wtf.nvim。其工作流程为缺省处理end_line缺省时退化为start_linebufnr缺省时使用当前 buffer。遍历从start_line到end_line的每一行调用vim.diagnostic.get(bufnr, { lnum line_num - 1, severity { min vim.diagnostic.severity.HINT } })——注意这里把 severity 下限设为 HINT即 ERROR / WARNING / INFORMATION / HINT 四级诊断全部纳入采集。对每一行命中的诊断收集三项信息line_number1-based 行号、message诊断消息文本、severity通过vim.diagnostic.severity[diagnostic.severity]转成可读字符串。采集完成后lsp.lua按Issue N / Location / Buffer / Severity / Message的固定格式逐条拼接成编号清单返回最终替换掉模板中的${lsp.diagnostics}。与编辑器诊断上下文Editor Context的对照CodeCompanion 在聊天中还内置了一套诊断编辑器上下文实现位于 lua/codecompanion/interactions/shared/editor_context/diagnostics.lua。对照阅读可以更好理解本 Prompt 的定位Editor Context 的chat_render同样调用vim.diagnostic.get并设定severity.min HINT但它采集的是整个 buffer的诊断且每条附带对应源码行内容插入聊天消息打上DIAGNOSTICS标签。而lsp.md的get_diagnostics只针对当前选区范围的行做采集且不附带代码原文只给行号 严重级别 消息。因此可以把两者视为互补方案需要全文件诊断 代码上下文用 diagnostics 编辑器上下文需要精准选区诊断、避免无关代码干扰则用本 Prompt。调用方式在 Neovim 中触发lsp内置 Promptlsp.md声明了opts.alias: lsp因此有三种标准触发方式与 usage/prompt-library.md 描述一致方式一Slash commandchat buffer 内在聊天缓冲区输入/lsp回车即可。注意它依赖 Visual 模式的选区需先在源文件选中代码再发起。方式二命令行:CodeCompanion /lsp效果同上。方式三Keymap 绑定用require(codecompanion).prompt(lsp)将 Prompt 绑定到按键vim.keymap.set(v, LocalLeaderd, function() require(codecompanion).prompt(lsp) end, { noremap true, silent true })其中lsp即 frontmatter 中定义的alias。此外它也会出现在 Action Palette 的 prompt library 列表中可通过:CodeCompanion打开挑选可用config.display.action_palette.opts.show_prompt_library_builtins控制 builtin Prompt 是否展示见 prompt_library/init.lua 的resolve逻辑。自定义与扩展仿照lsp.md编写你自己的诊断 Promptlsp.md是 prompt library 自定义能力的绝佳范本。若想做一个只关注 ERROR、或输出 JSON 格式的诊断 Prompt只需在prompt_library.markdown.dirs配置的自定义目录下新建.md文件例如my_diagnostics.md仿照 frontmatter 结构声明name/interaction/opts.alias等字段在正文中使用## system/## user段落书写提示词在同目录放一个同名.lua文件如my_diagnostics.lua返回以占位符名称为键、以function(args)为值的表即可像lsp.lua一样注入运行时数据解析与占位符替换全部由 markdown.lua 的 resolve_placeholders 自动完成。结合 helpers/code.lua 的 get_diagnostics 的实现你甚至可以自定义 severity 过滤或行号格式让 AI 拿到更贴合自己工作流的诊断信息。这种Markdown 模板 同目录 Lua 提供数据的双文件模式是 prompt library 内置 Prompt 的通用套路也是扩展 CodeCompanion 最轻量的切入点。小结lsp.md是 CodeCompanion 内置的选区 LSP 诊断解释 Prompt模板位于 lua/codecompanion/prompt_library/builtins/lsp.md数据采集函数位于同目录 lsp.lua。它只发送选区内诊断行号 严重级别 消息不发送代码原文并通过stop_context_insertion关闭上下文插入聚焦模型注意力。底层诊断采集由 helpers/code.lua 的 get_diagnostics 完成通过vim.diagnostic.get以 HINT 为 severity 下限逐行抓取。触发方式支持 chat buffer 内/lsp、:CodeCompanion /lsp、keymap 绑定与 Action Palette。它的Markdown 模板 同目录 Lua双文件模式可直接复用到自定义诊断类 Prompt 的开发中。【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CodeCompanion 内置 LSP 诊断解释 Prompt（lsp.md）实战指南：从选区到 AI 调试
CodeCompanion 内置 LSP 诊断解释 Promptlsp.md实战指南从选区到 AI 调试【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim在 Neovim 中面对一屏编译错误、lint 告警时CodeCompanion 的 prompt library 内置了一个专门针对 LSP 诊断的 Prompt——lsp.md。它会在 Visual 模式下将当前选区的诊断消息连同语言类型一并交给 AI让它扮演调试助手逐条解释并给出带语法高亮的修复代码。本文以该内置 Prompt 为骨架结合仓库源码拆解它的 YAML frontmatter、模板占位符、底层诊断采集逻辑并给出从调用方式到自定义扩展的完整实战方案读完你将能直接对选区跑 LSP 诊断解释也能照着它写出属于自己的诊断类 Prompt。内置 Prompt 全貌lsp.md在仓库中的位置与作用CodeCompanion 的 prompt library 分两类来源一类是用户通过配置项prompt_library.markdown.dirs指定的自定义 Markdown Prompt见 config.lua另一类就是插件自带的 builtin 集合。本篇文章的主角位于模板文件lua/codecompanion/prompt_library/builtins/lsp.md配套占位符实现lua/codecompanion/prompt_library/builtins/lsp.lua与同目录下的fix.md修复选中代码、explain.md解释选中代码共同构成一套选中即用的代码辅助 Prompt。lsp.md的特殊之处在于它不把选中代码本身发给模型而是只发送该选区内的 LSP 诊断消息列表——模型的输入是诊断问题清单而非代码原文从而把 AI 的注意力直接聚焦在报错上。frontmatter 逐项拆解lsp.md的 YAML 元数据语义lsp.md开头是一段 YAML frontmatter它是整个 Prompt 的元数据卡prompt library 的解析器通过 markdown.lua 的 parse_frontmatter依赖yamltreesitter parser读取。逐字段说明如下字段取值语义nameExplain LSP diagnosticsPrompt 显示名称会出现在 Action Palette 等入口interactionchat交互类型标记为聊天式交互descriptionExplain the LSP diagnostics for the selected code用途描述供 picker 检索展示opts.aliaslspPrompt 别名可用于 keymap 与 slash command 引用opts.is_slash_cmdfalse是否作为内置斜杠命令暴露opts.modes[v]仅在 Visual 模式下可用opts.stop_context_insertiontrue阻止当前 buffer 上下文自动插入保证发送给模型的只有诊断信息值得注意stop_context_insertion: true的作用CodeCompanion 默认会在聊天中附加编辑器上下文代码、文件树等而本 Prompt 希望模型只看诊断列表因此主动关闭上下文插入避免诊断之外的无关代码干扰模型判断。对照同目录的 fix.md 与 explain.md它们也都声明了modes: [v]与stop_context_insertion: true但fix.md额外设置了auto_submit: true自动提交与explain.md的is_slash_cmd: true——可见同类 Prompt 之间在调度行为上的差异完全由 frontmatter 控制。模板占位符解析${context.filetype}与${lsp.diagnostics}的填充机制lsp.md的正文只有两段## system与## user这与 prompt library 的解析约定一致——## system段被识别为 SYSTEM_ROLE、## user段被识别为 USER_ROLE见 markdown.lua 与 parse_prompt 的 role 捕获逻辑。user 段正文The programming language is ${context.filetype}. This is a list of the diagnostic messages: ${lsp.diagnostics}两个占位符的解析链路如下${context.filetype}来自调用时的 BufferContext 上下文对象由 prompt library 的resolve_placeholdersmarkdown.lua通过点号记法解析先按占位符第一段context、lsp尝试从 Prompt 同目录加载同名 Lua 文件再把该表挂到args上后解析嵌套值。context.filetype直接命中上下文自带的文件类型。${lsp.diagnostics}点号第一段lsp会触发加载同目录下的 lsp.lua该文件返回{ diagnostics function(args) ... end }然后以args携带context调用该函数其返回值即诊断文本。这就是Markdown 模板 同目录 Lua 函数的组合模式模板负责定义措辞Lua 文件负责运行时数据采集二者通过${name.func}占位符衔接。源码级原理get_diagnostics如何采集选区诊断lsp.lua的核心只有一段diagnostics函数它调用require(codecompanion.helpers.code).get_diagnostics( args.context.start_line, args.context.end_line, args.context.bufnr )真正的采集逻辑在 lua/codecompanion/helpers/code.lua 的 get_diagnostics该实现参考自piersolenski/wtf.nvim。其工作流程为缺省处理end_line缺省时退化为start_linebufnr缺省时使用当前 buffer。遍历从start_line到end_line的每一行调用vim.diagnostic.get(bufnr, { lnum line_num - 1, severity { min vim.diagnostic.severity.HINT } })——注意这里把 severity 下限设为 HINT即 ERROR / WARNING / INFORMATION / HINT 四级诊断全部纳入采集。对每一行命中的诊断收集三项信息line_number1-based 行号、message诊断消息文本、severity通过vim.diagnostic.severity[diagnostic.severity]转成可读字符串。采集完成后lsp.lua按Issue N / Location / Buffer / Severity / Message的固定格式逐条拼接成编号清单返回最终替换掉模板中的${lsp.diagnostics}。与编辑器诊断上下文Editor Context的对照CodeCompanion 在聊天中还内置了一套诊断编辑器上下文实现位于 lua/codecompanion/interactions/shared/editor_context/diagnostics.lua。对照阅读可以更好理解本 Prompt 的定位Editor Context 的chat_render同样调用vim.diagnostic.get并设定severity.min HINT但它采集的是整个 buffer的诊断且每条附带对应源码行内容插入聊天消息打上DIAGNOSTICS标签。而lsp.md的get_diagnostics只针对当前选区范围的行做采集且不附带代码原文只给行号 严重级别 消息。因此可以把两者视为互补方案需要全文件诊断 代码上下文用 diagnostics 编辑器上下文需要精准选区诊断、避免无关代码干扰则用本 Prompt。调用方式在 Neovim 中触发lsp内置 Promptlsp.md声明了opts.alias: lsp因此有三种标准触发方式与 usage/prompt-library.md 描述一致方式一Slash commandchat buffer 内在聊天缓冲区输入/lsp回车即可。注意它依赖 Visual 模式的选区需先在源文件选中代码再发起。方式二命令行:CodeCompanion /lsp效果同上。方式三Keymap 绑定用require(codecompanion).prompt(lsp)将 Prompt 绑定到按键vim.keymap.set(v, LocalLeaderd, function() require(codecompanion).prompt(lsp) end, { noremap true, silent true })其中lsp即 frontmatter 中定义的alias。此外它也会出现在 Action Palette 的 prompt library 列表中可通过:CodeCompanion打开挑选可用config.display.action_palette.opts.show_prompt_library_builtins控制 builtin Prompt 是否展示见 prompt_library/init.lua 的resolve逻辑。自定义与扩展仿照lsp.md编写你自己的诊断 Promptlsp.md是 prompt library 自定义能力的绝佳范本。若想做一个只关注 ERROR、或输出 JSON 格式的诊断 Prompt只需在prompt_library.markdown.dirs配置的自定义目录下新建.md文件例如my_diagnostics.md仿照 frontmatter 结构声明name/interaction/opts.alias等字段在正文中使用## system/## user段落书写提示词在同目录放一个同名.lua文件如my_diagnostics.lua返回以占位符名称为键、以function(args)为值的表即可像lsp.lua一样注入运行时数据解析与占位符替换全部由 markdown.lua 的 resolve_placeholders 自动完成。结合 helpers/code.lua 的 get_diagnostics 的实现你甚至可以自定义 severity 过滤或行号格式让 AI 拿到更贴合自己工作流的诊断信息。这种Markdown 模板 同目录 Lua 提供数据的双文件模式是 prompt library 内置 Prompt 的通用套路也是扩展 CodeCompanion 最轻量的切入点。小结lsp.md是 CodeCompanion 内置的选区 LSP 诊断解释 Prompt模板位于 lua/codecompanion/prompt_library/builtins/lsp.md数据采集函数位于同目录 lsp.lua。它只发送选区内诊断行号 严重级别 消息不发送代码原文并通过stop_context_insertion关闭上下文插入聚焦模型注意力。底层诊断采集由 helpers/code.lua 的 get_diagnostics 完成通过vim.diagnostic.get以 HINT 为 severity 下限逐行抓取。触发方式支持 chat buffer 内/lsp、:CodeCompanion /lsp、keymap 绑定与 Action Palette。它的Markdown 模板 同目录 Lua双文件模式可直接复用到自定义诊断类 Prompt 的开发中。【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
