用途
该技能用于在需要检查、验证、校验或理解文件（通常是代码相关文件或 Markdown）的代码或结构时，系统化地使用语言服务器和 linter 完成工作。核心原则是：让对应语言的合适工具执行验证工作，而不是手动检查；自动完成工具发现与选择。
何时使用
- 检查代码文件的语法错误、类型问题或风格问题
- 验证配置文件（YAML、TOML、JSON、KDL 等）
- 理解陌生文件的结构或代码质量
- 验证 Markdown 文件的格式/链接问题
- 需要快速了解文件中存在哪些问题
何时不使用
- 仅阅读文件以了解其内容（无需验证）
- 运行完整测试套件（那属于测试，而非验证）
- 分析代码行为（那属于调试，而非验证）
工作流程
第 1 步：检测文件类型
根据文件扩展名确定语言/类型：
- .lua → lua
- .ts/.tsx → typescript
- .py → python
- .go → go
- .rs → rust
- .md → markdown
- .json → json
- .yaml → yaml
- .toml → toml
- .kdl → kdl
如果扩展名不明确或缺失，检查文件 shebang 或内容模式。
第 2 步：在 Mise 中搜索 LSP/Linter
运行：mise search <filetype>
这会返回该语言所有可用的语言服务器、linter 和格式化工具。
示例输出：
mise search lua
- lua-language-server（最流行）
- stylua（格式化工具）
mise search python
- pyright
- pylance
- python-language-server
- black
- ruff
第 3 步：智能选择
按工具类型优先排序：语言服务器（LSP）> Linter > 格式化工具。
LSP 提供最全面的验证。Linter 捕获风格/质量问题。格式化工具在验证用途中属于次要。
如果只有一个明显选择：
- 自动选择它（例如 Lua 只有 lua-language-server）
- 验证安装：
mise list | grep <tool>（如果未列出，则安装） - 安装：
mise install lua-language-server - 对文件运行它
如果有多个选择：
- 按优先级过滤：先显示 LSP，其次 linter，跳过格式化工具
- 按流行度排序：最常用的工具优先（以 GitHub stars 衡量，npm/PyPI 下载量作为平局决胜）
- 向用户显示排序后的列表（含工具类型和简要描述）
- 让用户按编号/字母选择
- 验证并安装所选工具
- 对文件运行它
如果未找到工具：
- 明确告知用户：“mise 中没有适用于 [filetype] 的 LSP/linter”
- 按顺序建议替代方案：
- 检查在线包管理器（npm、PyPI、cargo 等），如果 mise 中没有
- 寻找通用验证器（JSON 用 jq，YAML 用 yamllint 等）
- 基本语法检查（语言内置检查器）
- 使用结构化指导进行手动验证
- 询问：“需要我帮你从其他来源安装吗？”
第 4 步：运行验证
对文件执行所选工具并返回结果：错误、警告、风格问题和建议。
快速参考
| 任务 | 操作 |
|---|---|
| 检测文件类型 | 以文件扩展名作为主要信号 |
| 查找工具 | mise search <filetype> |
| 安装明显选择 | mise install <tool>（自动选择） |
| 显示选项 | 呈现排序列表供用户选择 |
| 运行验证 | 使用文件路径执行工具 |
常见错误
- 错误：跳过文件类型检测。 错误做法：“这是代码文件，任何语言服务器都行”。正确做法：文件类型决定适用哪个 LSP。错误的 LSP = 错误的错误。
- 错误：存在多个时随机选一个 LSP。 错误做法：“我就试第一个”或“它们都一样”。正确做法：不同 LSP 检查不同方面。使用排序：最流行 > 较不常见。按类型过滤：LSP > Linter > 格式化工具。没有例外：存在多个时必须向用户呈现选项，不能猜测。
- 错误：假设 LSP 已安装。 错误做法：“让我直接运行 lua-language-server...”。正确做法：始终先用 mise search 验证。安装前检查 mise list。需要时安装。
- 错误：不检查系统要求。 错误做法：“安装 LSP 就能用”。正确做法：某些 LSP 需要运行时依赖（Python、Node 等）。报告结果前测试 LSP 能运行。
- 错误：LSP 不可用时放弃。 错误做法：“这个语言没有工具，无法验证”。正确做法：按顺序探索替代方案：在线包管理器 → 通用验证器 → 语法检查 → 手动指导。
- 错误：混合工具类别。 错误做法：验证时同等展示格式化工具和 linter。正确做法：优先 LSP > Linter > 格式化工具。以工具类型作为第一过滤器。
回退验证选项
当 mise 中没有 LSP/linter 时：
- 检查在线包管理器（npm、PyPI、cargo 等），如果 mise 中没有
- 寻找通用验证器——JSON 验证器、YAML 检查器可跨项目使用
- 基本语法检查——某些语言有内置语法检查器
- 手动验证——提供结构化审查指导
- 建议安装——“需要我帮你从其他来源安装吗？”
实施步骤
帮助用户检查文件时：
- 询问或确定：“我们在检查哪个文件？”
- 从扩展名检测文件类型
- 运行：
mise search <filetype> - 决定：明显选择还是显示排序选项？
- 验证安装：
mise list | grep <tool>（检查是否已安装） - 如需要则安装：
mise install <selected-tool> - 测试工具运行：验证 LSP/linter 执行无错误
- 运行：使用适当标志对文件执行工具
- 报告：向用户显示验证结果
- 提供后续步骤：“修复这些问题？”或“再次运行检查？”
故障排除
工具安装但无法运行：
- 某些 LSP 需要运行时依赖（某些工具需要 Python，其他需要 Node）
- 检查 LSP 文档了解运行时要求
- 示例：python-language-server 需要安装 Python
- 验证：
mise exec <tool> -- <tool> --version
Mise search 无结果：
- 该语言可能不在 mise 数据库中
- 尝试替代包管理器：npm（JavaScript）、PyPI（Python）、cargo（Rust）
- 或使用通用验证器：jq（JSON）、yamllint（YAML）
LSP 发现错误但工具不适合该任务：
- 选错了工具（选了格式化工具而非 LSP）
- 回到第 3 步，按类型优先级过滤（LSP > Linter）
- 请用户从列表中选择其他选项
文件扩展名不常见：
- 使用文件内容检查（shebang、头部）作为回退
- 示例：可执行 shell 脚本通常没有 .sh 扩展名
- 在搜索 mise 前检查内容以确认类型
实际影响
- 快速验证：无需手动代码审查即可发现常见问题
- 一致检查：每次使用相同工具、相同标准
- 发现：找到手动检查会遗漏的问题
- 自动化：可集成到工作流、CI/CD、pre-commit 钩子中
- 语言无关：只要有可用 LSP，同一模式适用于任何语言