这阵子不少开发者已经不只是“开一个编辑器然后跑一个终端”了。

  • 一个项目里要同时启动前端、后端、数据库代理和 worker；
  • 本地还要开 Codex、Claude Code 之类的 AI 编码代理；
  • 有时想并行做两个功能分支，又不想把同一个工作目录搅乱；
  • 切去另一个项目时，还希望前一个项目的长任务能继续活着。

问题是，大多数本地开发工具只解决其中一小块。

  • 终端只负责跑命令；
  • GUI 启动器只负责点一下打开项目；
  • tmux 或 session manager 偏终端老手；
  • Docker 类工具又不一定适合本地原生开发流程；
  • AI 编码代理通常只是被塞进某个已有终端，并没有真正进入项目工作台。

今天想记下的 gug007/lpm，就在试着把这些事情重新收口。

按 GitHub 仓库页、README 和 releases 页在 2026-06-26 的公开信息，这个仓库当前约有 225 stars、17 forks，仓库创建于 2026-03-29，仓库页显示最近公开更新发生在 2026-06-26。仓库主要由 TypeScript 和 Rust 组成，最新 release 是 v0.4.52，发布时间为 2026-06-25。

项目概览

属性详情
仓库gug007/lpm
定位面向本地开发项目的桌面工作台
Stars225
Forks17
主要技术栈TypeScript、Rust
创建时间2026-03-29
最近公开更新2026-06-26
最新版本v0.4.52
版本日期2026-06-25
当前平台macOS（Apple Silicon / Intel）

它抓住的核心，不是“再造一个终端”，而是“把项目运行态集中起来”

README 开头写得很直接：lpm 想让你一键启动、停止、复制开发项目，并把 AI coding agents 跟项目服务放进同一个 workspace 里。

这个定位比看起来更重要。

因为本地开发的真正摩擦，往往不是“命令不会敲”，而是运行态太分散：

  • 哪个终端在跑 web 服务；
  • 哪个终端挂着 worker；
  • 哪个 AI 代理正在读这个仓库；
  • 哪个目录是功能 A 的并行副本；
  • 哪个项目现在可以安全切走，哪个还在跑长任务。

lpm 的想法，是把这些信息和操作都收拢进一个本地桌面控制面，而不是继续让它们散落在 Finder、Terminal、iTerm、tmux、IDE 和一堆 shell 标签页之间。

最有意思的一点，是它把“项目复制”当成一等能力

README 里最打动我的不是“一键启动”，而是 duplicate your project instantly。

这件事对现在的 AI 编码工作流特别有意思。

因为很多人都已经遇到过这个问题：

  • 一个代理在改接口；
  • 另一个代理想同时试验 UI；
  • 自己还想保留一个稳定工作区做 review；
  • 如果全塞进同一个目录，就很容易相互污染。

lpm 明显是把这种并行开发场景当成默认需求来设计的。它不是只说“你可以多开几个窗口”，而是更进一步，把 复制项目副本并平行运行代理 变成产品能力。

这让它和传统项目启动器的差别很大。

传统启动器更像“帮你开门”，lpm 更像“帮你布置一整个工作现场”。

它关心的不是容器编排，而是本地原生开发者日常

README 里还有一句很关键：No Docker required。

这不是说它反对容器，而是它优先服务的是另一类工作流：

  • 项目本来就是在本机原生跑；
  • 服务之间的启动顺序和命令已经很清楚；
  • 需要的是统一入口，而不是再套一层基础设施；
  • 想快速进出不同项目，不想每次都考虑 compose、镜像和容器生命周期。

这点让我觉得它的边界非常清楚。

lpm 不是去跟 Docker Desktop、Dev Containers、Kubernetes 本地编排工具抢同一个问题定义。它更像在回答：

“如果我的项目本来就是本机优先、终端优先、但现在又多了 AI 代理和并行工作区，我该怎么把这些东西管起来？”

这个切口挺准。

自动识别项目形态，让它不像一个只会保存命令的 launcher

README 里还列了一个很实际的能力：自动识别项目 setup，包括：

  • Rails；
  • Next.js；
  • Go；
  • Django；
  • Flask；
  • Docker Compose。

这意味着 lpm 不是单纯保存一串 shell 命令，然后下次帮你重新执行。

它更接近一个懂项目结构的本地工作台，会尝试先理解项目的运行方式，再给你一个可以持续管理的配置。

再加上它支持：

  • profiles：只启动一部分服务；
  • actions：把测试、迁移、部署之类的一次性命令挂进界面；
  • live terminal：直接看服务输出；
  • notes 和 config editor：把项目说明和配置留在同一个地方；

这就让它从“桌面快捷方式集合”变成了真正的项目操作面板。

它对 AI 编码代理不是顺手兼容，而是明确纳入主场景

lpm README 里几次直接点名了 Claude Code 和 Codex。

这很重要，因为不少工具虽然口头上支持 AI agent，但真实状态只是“反正你也可以在我的终端里运行它”。

lpm 则明显把代理协作视为第一类场景：

  • 终端布局就是为了让服务和代理并排工作；
  • 项目复制能力天然适合多代理并行；
  • 工作区切换强调“不要丢上下文，也不要丢运行中的任务”；
  • README 还提供了一个 AI Agent Skill，让代理自己为项目生成 lpm 配置。

最后这一点很妙。

也就是说，lpm 不只是给人类点按钮，它还试图让代理参与到工作台配置本身。README 给出的安装方式是：

npx skills add gug007/lpm

然后让代理去分析代码库、发现服务并写出配置。

这说明作者考虑的已经不是“AI 代理运行在 lpm 里”，而是“AI 代理也可以帮你把 lpm 设起来”。

它更像本地项目控制台，而不是通用 IDE 替代品

看完 README，我觉得 lpm 最合理的理解不是“新 IDE”，也不是“终端美化工具”，而是一个 local project operations console。

它关心的是这些事情：

  • 这个项目怎么启动；
  • 现在有哪些服务在跑；
  • 能不能一键切到另一个项目；
  • 能不能保住长任务；
  • 能不能为并行开发快速复制工作区；
  • 能不能把 AI 代理和服务放进同一个现场里。

这和 IDE 关注点不一样，也和传统 terminal multiplexer 不太一样。

它不是替代所有开发工具，而是替代“为了把项目跑起来和切来切去而反复做的那一层机械操作”。

适合谁

我觉得 lpm 比较适合这些人：

  • 本地同时维护多个项目的人；
  • 常驻跑前后端、worker、代理脚本的人；
  • 已经把 Codex、Claude Code 之类工具纳入日常开发的人；
  • 需要并行复制工作区做多线程开发的人；
  • 更喜欢本机原生运行，而不是所有东西都进容器的人。

尤其是当你发现自己每天都在重复做这些动作时：

  • 打开同几个目录；
  • 启动同几组服务；
  • 给不同任务复制工作区；
  • 找回昨天没关掉的长任务；
  • 把 AI 代理塞到正确的项目上下文里；

那 lpm 这种工具就会显得很有价值。

也要看清它的边界

当然，lpm 也不是：

  • 跨平台开发环境统一层；
  • 面向团队的远程编排平台；
  • 云端托管的代理控制中心；
  • 替你处理生产部署的 DevOps 平台。

至少按当前 README 和下载说明来看，它现在主要面向 macOS 本地桌面。

所以它更像一把很聚焦的刀：

  • 做本地项目切换；
  • 管本地服务和终端；
  • 服务 AI 代理并行协作；
  • 减少多工作区开发时的混乱。

如果你的需求刚好落在这个交叉点上，它会很顺手。反过来，如果你要的是跨平台团队编排或远程基础设施控制，它就不是那个方向。

小结

gug007/lpm 值得看的地方，不只是“一键启动项目”这件事，而是它对当下本地开发现实的判断很准确：

  • 一个项目往往不止一个服务；
  • 开发者手上不止一个工作区；
  • AI 编码代理已经进入日常流程；
  • 长任务、上下文和切换成本正在变成新的摩擦点。

lpm 的做法，是把这些摩擦集中进一个本地工作台里处理。

它未必适合所有人，但如果你最近已经开始把多个服务、多个终端和多个 AI 代理塞进同一台开发机，那这个项目很值得认真翻一遍。