刚把一个仓库克隆到本地，导入行全是红色报错？Magic Install 会自动识别每个文件对应哪个包管理器，执行正确的命令，将红色错误变回绿色——一键完成，无需思考。
克隆仓库后立即安装依赖，是开发者最日常的摩擦之一。这件事本身毫无难度——每个包管理器都有默认的安装命令，执行起来都没问题。麻烦在于记忆：Node 项目用 npm install，有 requirements 文件的 Python 项目用 pip install -r requirements.txt，有 pyproject.toml 的用 poetry install，Rust 用 cargo build，有 Podfile 的用 pod install，Ruby 用 bundle install，Elixir 用 mix deps.get……这张清单没有尽头，每个仓库都要求你在项目开始之前，先把正确的命令加载到工作记忆里。
LingCode 把这件事看作一个查找问题，而非记忆问题。仓库里的文件是公开信息——package.json 要么存在，要么不存在；Cargo.toml 就摆在那里。扫一眼文件树，就能知道该用哪个包管理器、执行哪条命令。智能体替你做这个扫描，运行命令，并告诉你结果。整个过程简化为一句话："是，安装。"
听起来很微小，每次节省的时间确实有限。但它的价值在于消除了接手陌生仓库时的启动阻力。那个"搞什么，这个项目的安装命令是什么"的停顿消失了。你打开仓库，直接开始。
打开一个尚未安装依赖的项目。也许你刚刚克隆了它；也许队友新增了一个依赖，你本地的 node_modules 已经过期；也许 Python 虚拟环境莫名消失了。
LingCode 的编辑器会捕捉到这个症状：未解析的导入、缺失的类型、查找失败。一旦你打开含有未解析导入的文件，就会出现一个小提示（通常以横幅形式显示在文件顶部，或作为角落里的通知），询问是否安装缺失的包。
提示会标注即将使用的包管理器名称，例如"使用 npm 安装依赖"或"使用 poetry 安装"——总之是这个仓库正确的那个。点击后，终端面板会显示正在运行的命令；命令成功退出后，文件中的红色波浪线随即消失。
对大多数仓库来说，这就是全部操作。Magic Install 读取项目的清单文件（package.json、Cargo.toml、requirements.txt、Podfile 等），选出项目明确使用的包管理器，运行该管理器的默认安装命令。这个过程在大多数情况下完全透明，正是它该有的样子。
检测结果几乎总是正确的。以下两种情况可能出现偏差：
package.json 和 requirements.txt 的仓库需要同时运行两个包管理器。Magic Install 会提示依次执行——两个提示都接受即可。如果只提示了其中一个，手动运行另一个。pnpm-lock.yaml 对应 pnpm，poetry.lock 对应 poetry）——通常是正确的。如果项目作者有强烈偏好但没有通过锁文件记录下来，可以拒绝提示，手动运行正确的命令。Magic Install 对常见场景很高效，但以下情况它无能为力：
apt-get、项目假设已安装的系统框架。Magic Install 处理的是仓库内的包依赖，不会审计你机器上的其他内容。npm login 的私有 npm 注册表、需要 token 的 Cargo 注册表、私有 CocoaPod 等。Magic Install 会运行安装命令；如果因为缺少认证而失败，你需要先完成认证再重新运行。Makefile 封装安装步骤的项目，或有自定义 shell 脚本做预拉取处理的项目。请按照项目文档中的安装方式操作。Magic Install 是最省事的默认选项。当智能体的默认行为明显不够用时，退回到手动执行才是正确的选择。
安装命令完成后，编辑器的语言服务器会重新建立索引。红色波浪线消失，导入解析成功，自动补全恢复正常。你已经可以在一个十秒前从未见过的仓库里写代码了。
如果波浪线没有消失，很可能是安装悄悄失败了——检查终端面板的错误输出。常见的失败原因：缺少系统依赖、Node 版本不匹配、Python 虚拟环境没有激活。
package.json 里漏掉了哪些实际使用的依赖"。如果需要排查这类问题，可以询问智能体："这个项目中有哪些导入没有出现在 package.json 里？"它可以同时读取两份文件并告诉你答案。