oh-my-pr：你的 GitHub PR 全职保姆

凌晨两点，PR 还在打转

你有过这样的经历吗？辛辛苦苦写完代码，推了一个 PR，等 review 的时候切换到其他任务。等你想起来看，CI 已经红了三条——只是因为某个依赖版本的小冲突。评论区的反馈积压了五条，reviewer 问的问题还没来得及回答，merge 冲突又冒出来了。

这就是 oh-my-pr 试图消灭的场景。这个由独立开发者 yungookim 构建的工具，本质上是一个本地优先的 GitHub PR 自动管家：它持续监控你关心的 PR，自动分类 review 反馈，在隔离的 git worktree 中调用本地 Codex 或 Claude CLI 自动修复代码，并把补丁推送回 PR 分支。整个过程不需要云端，不上传代码，一切在你自己电脑上跑。

背景故事：开发者的时间去哪儿了

Pull Request 的生命周期里，藏着大量重复性劳动：review 评论来了，你需要重新加载上下文；CI 失败了，你需要 local debug；修复后 push 了，又要等下一轮 review。这些"保姆级"操作占据的时间，本质上是开发流程中的摩擦损耗。

yungookim 在项目 README 中直言不讳：这个工具专为"Token 消耗最大化"设计——它会大量使用 AI 模型的 token，换取开发者精力的解放。这是一种明确的工程权衡：用云端算力换本地时间。

技术架构：四层结构，本地为王

oh-my-pr 的架构设计非常清晰，分为四层：

客户端层

基于 React 18 + Vite + TanStack React Query 构建，UI 组件库使用 Radix UI 配合 Tailwind CSS，数据状态通过 React Query 管理。这套技术栈保证了 dashboard 的响应速度和现代感。

服务端层

Node.js Express 服务器，监听本地端口（默认 5001），提供 RESTful API 接口。核心逻辑分布在多个专门模块中：

• babysitter.ts：PR 监控主控制器
• ciHealingAgent.ts / ciHealingManager.ts：CI 失败自动修复
• deploymentHealingAgent.ts：部署问题自动诊断
• feedbackLifecycle.ts：review 反馈生命周期管理
• repoWorkspace.ts：隔离的 git worktree 管理
• github.ts：通过 @octokit/rest 与 GitHub API 通信
• mcp.ts：MCP（Model Context Protocol）服务器暴露
• sqliteStorage.ts：本地 SQLite 持久化（Drizzle ORM）

Agent 层

通过 @modelcontextprotocol/sdk 连接外部 AI Agent，支持 Codex CLI 和 Claude CLI 两种后端。Agent 在隔离的 worktree 中执行代码修复任务，遵守 AGENTS.md 中定义的严格行为准则（最小代码改动、目标驱动执行）。

暴露接口

工具提供四种接入方式，满足不同使用习惯：

接口	说明	端口
Web Dashboard	浏览器可视化面板	localhost:5001
Local API	RESTful API 二次开发	localhost:5001/api
MCP Server	Model Context Protocol 协议	mcp.ts 进程
Tauri Desktop App	macOS 原生桌面应用	.dmg 安装包

核心功能：六个自动化场景

1. PR 持续监控

无需轮询 GitHub Web 界面，oh-my-pr 自动追踪已注册仓库中你关心 PR 的评论、check 状态、merge 冲突。一旦有新动态，立即触发后续处理流程。

2. Review 反馈分类

工具将 reviewer 的评论自动归类为"需要代码改动"、"问题确认"、"表扬/批准"等类型，让开发者快速区分优先级。

3. CI 失败自动修复

CI 红了一条，它会读取失败的日志，诊断失败原因，然后在隔离的 worktree 中启动 AI Agent 自动修复并 push 补丁。针对 GitHub Actions、Travis CI、CircleCI 等主流 CI 平台都有对应适配器。

4. 自动回复 GitHub 评论

当修复完成后，工具可以自动在 PR 下回复评论，告知 reviewer 已处理，并自动 resolve conversation，保持 PR 线程整洁。

5. 自动发布 Release

当一个 merged PR 包含足够重要的版本升级时，工具可以自动调用 GitHub Releases API 创建 release，并附上 changelog（从 CHANGELOG.md 读取）。

6. 使用数据本地收集

Dashboard 包含匿名的使用统计（打开次数、追踪 PR 数、合并数、修复次数），所有数据存在本地 state.sqlite，不上传到任何云端。

本地优先：数据主权的设计哲学

oh-my-pr 的所有数据都在本地：

• ~/.oh-my-pr/repos/ — 仓库缓存
• ~/.oh-my-pr/worktrees/ — 隔离的 worktree
• ~/.oh-my-pr/log/ — 运行日志
• ~/.oh-my-pr/state.sqlite — 应用状态

可自定义 OH_MY_PR_HOME 改变存储路径。Token 认证支持 gh auth login、GITHUB_TOKEN 环境变量、Dashboard 配置等多种方式。

争议与局限

Token 消耗巨大：作者在 README 中明确警告，这个工具会大量消费 AI API token。在重度使用场景下，月账单可能相当可观。这是一把双刃剑——省了开发时间，但可能花了更多钱。

代码改动风险：AI Agent 自动修复代码的能力受限于模型水平，有时可能引入新的问题，特别是复杂的业务逻辑或边界条件。工具设计了"bounded code-owner fallback"兜底机制，但依然需要开发者在最终 merge 前认真 review。

平台依赖：依赖 GitHub，不支持 GitLab/Bitbucket。桌面版目前只有 macOS（Apple Silicon），Windows/Linux 用户只能使用 CLI + Web Dashboard 模式。

无容器化部署：没有 Dockerfile 或 docker-compose，无法在服务器上以容器方式运行。但这符合项目"本地优先"的定位——它的设计初衷就不是服务器工具。

行业意义：PR 流程自动化的探索者

在 AI Agent 落地工程实践这条路上，oh-my-pr 代表了一个有趣的垂直场景：不是通用的代码生成，而是专注在 PR 全生命周期管理这个细分领域。它将开发者从"等反馈→切上下文→小改动→push→再等"的循环中解放出来。

从架构设计来看，项目展现了很高的工程水准：完整的测试套件（.test.ts 文件遍布 server/ 和 client/src/lib/）、TypeScript 严格模式、模块化的 agent 架构、多接口暴露（API + MCP + Web + Desktop）。这种"认真做一个工具"的态度，在独立开发者项目中相对少见。

快速上手

# 安装
npm install -g oh-my-pr

# 启动 dashboard
oh-my-pr

# 打开使用统计
open http://localhost:5001/usage

# 查看日志
open http://localhost:5001/logs

# 以 MCP Server 模式运行（供 AI IDE 集成）
npm run mcp

需要 Node.js 22+、git、gh auth login（或 GITHUB_TOKEN），以及 Codex/Claude CLI 之一。

总结

oh-my-pr 是一个将 AI Agent 深度嵌入 GitHub PR 协作流程的工具，定位清晰——做开发者 PR 的"全职保姆"。本地优先的架构保障了数据安全，多接口暴露提供了灵活性，完整的测试覆盖体现了工程可靠性。主要风险在于 Token 消耗和 AI 修复的质量边界。它代表了 2026 年 AI Coding Agent 垂直化落地的一个真实案例，适合对 PR 流程自动化有强需求的团队或个人开发者试用。