pr-genius 怎么安装？

在已安装 dsh CLI 引擎的环境中，进入插件页复制安装命令一键执行即可；自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node ^22.19.0 || >=24）；该结论来自程序自动检查，未经人工实机验证。

pr-genius 兼容性怎么样？

自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node ^22.19.0 || >=24）；该结论来自程序自动检查，未经人工实机验证。

pr-genius 有中文文档吗？

已提供中文翻译 README（由 DeepSeek 最新模型翻译生成），本站可切换中英文对照阅读。

pr-genius 还在维护吗？

GitHub 3 星。最近一次上游提交在 2026/11/2。

PR 提交顾问 zsxh1990/pr-genius

DeepSeek Harnessv2.2.5

zsxh19904 天前有提交已提供中文文档扫描：含敏感能力

在 GitHub 查看 ↗

PR Genius — 提交前改进顾问 + 大型开源项目 PR 知识库

38.8/100

综合分

GitHub 星标

372

npm 周下载

—/5

用户评分

数据截至 2026/11/3 · 周下载取自 npm 全网（含 CI / 镜像），非本站安装数；综合分由星标、活跃度与兼容性检查合成。

安装命令 · 需先装 dsh CLI 引擎

dsh plugin --profile web add pr-genius

npm 源 · pr-genius 的发布者账号已校验与本仓库一致

状态速览

判定依据：实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态

信任档位：待复验

是什么[目录]—

dsh 原生插件 · platform

暂无时间戳·判据 →

装得上吗[实装验证]—

曾在 dsh 0.2.1-rc.2 下真实安装成功，但当前 dsh 已更新至 0.2.2-rc.1，本站尚未在新版下复验

L4 · 真实安装等级说明 →

数据截至 2026/10/23·判据 →

安全吗[自动扫描]—

本站尚未对该插件做风险分级

暂未覆盖，不等同于无风险

数据截至 2026/11/05·判据 →

还在维护吗[仓库]✓

活跃：最近一次提交在 4 天前

暂无时间戳·判据 →

图例：✓ 通过! 需注意— 未判定 / 无数据· 「未判定」= 本站尚无数据，不代表插件有问题

档位由哪些信号合成

本站实装验证（真实安装 L4 覆盖全站；L5 为运行时冒烟或实机截图，覆盖范围小于 L4） · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。

验证判据与等级说明 →

可信度证据

安全扫描自动 · 静态分析源码

v2.7.0

🔵 扫描：含敏感能力尚无人工评估

展开查看扫描说明与证据 ↓

静态扫描发现插件具备触达本地系统的能力：执行外部命令、读写/删除本地文件、读取剪贴板或密钥类环境变量（至少其一）。这是能力清单，不是危险判定——具体能力项与证据见下方，安装前请自行判断是否需要。

可执行外部命令读写/删除本地文件发起外部网络请求

查看扫描证据（共 12 处，展示前 12 条）

读取本地文件
dist/kb.mjs:30
const missing = Object.entries(layout).filter(([key]) => key !== "root").filter(([, dir]) => !existsSync(dir)).map(([key, dir]) => `${key} (${dir})`);
读取本地文件
dist/kb.mjs:31
if (!existsSync(root) || missing.length > 0) throw new PrGeniusConfigError("kbRoot", `knowledge base layout not found under ${root}; missing: ${missin
读取本地文件
dist/kb.mjs:37
const raw = readFileSync(file, "utf8");
发起网络请求
dist/mcp-client.mjs:154
return unwrapResult(name, await this.request({
执行外部命令来自配置/变量
dist/mcp-client.mjs:176
const child = spawn(this.options.command, this.options.args, {
发起网络请求
dist/mcp-client.mjs:209
await this.request({
读取本地文件
src/kb.ts:42
.filter(([, dir]) => !existsSync(dir))
读取本地文件
src/kb.ts:44
if (!existsSync(root) || missing.length > 0) {
读取本地文件
src/kb.ts:61
const raw = readFileSync(file, 'utf8')
发起网络请求
src/mcp-client.ts:249
const message = await this.request(
执行外部命令来自配置/变量
src/mcp-client.ts:273
const child = spawn(this.options.command, this.options.args, {
发起网络请求
src/mcp-client.ts:303
await this.request(

扫描于 2026/11/5（1 天前） · 范围入口闭包 + 全包扫描 · 来源 npm 发布包

静态扫描只反映源码中出现的调用，不构成安全背书；人工评估与自动扫描相互独立、互不覆盖。

依赖的 DSH / Cordis 模块

@deepseek-ai/cordis@deepseek-ai/dsh@deepseek-ai/dsh-client-connection@deepseek-ai/dsh-client-ui-cordis@deepseek-ai/dsh-client-ui-slots@deepseek-ai/dsh-cordis-client-runner@deepseek-ai/dsh-session-projection@deepseek-ai/schemastery

给这个插件打分还没有人投票↓

用户评分

还没有人投票，来当第一个

广告阿里云

阿里云新客首购 8 折 · 把 dsh 跑起来

云服务器 ECS、数据库 RDS、对象存储 OSS、CDN 等常用产品，新用户首购立减 20%。插件装好之后想放到公网，这是最省事的一条路。

·新用户首购立减 20%
·覆盖 ECS / RDS / OSS / CDN
·国内节点，访问与备案都顺

领取 8 折资格→

功能亮点

提交前改进建议
大型开源项目PR知识库

最近更新

在 GitHub 查看全部 →

v2.1.42026-10-03

· [2.1.4] - 2026-10-03

只为了一件事才发这个版本：让「运行时门禁签过字」这句话在 CI 里成真。2.1.3 就带着这句话，但它只对了一半。门禁在本地和 prepublishOnly 里都过了，可 CI 那条腿从来没跑起来——actions/setup-node 配 cache: pnpm 排在 pnpm/action-setup 前面，于是它在门禁启动前就挂了，报「Unable to locate executable file: pnpm」。这个顺序已在 main 上修好（ac8ab6a），这个 tag 就是用来验证它的。

· 修复
· release-smoke.yml 现在先装 pnpm，再走 setup-node 的 pnpm 缓存。setup-node 要调用 pnpm 解析 lockfile；pnpm 还不在 PATH 上时，工作流在 setup 阶段就失败，门禁根本没机会跑。门禁从来不是问题所在——工作流压根没走到它。

· 行为无变化

插件代码和 2.1.3 完全一致。发这个版本，是为了让下一次「门禁签过字」的说法能在 Actions 标签页里查证，而不只是在我机器上成立。

· 仍然成立

门禁证明的是 apply() 发出的调用落在 SDK 声明的座位上、且组件非空。它不证明任何东西能渲染出来——这里没有 DEEPSEEK_API_KEY，pr-genius 也从没在真实的 DSH web 宿主里挂载过。

v2.1.32026-10-03

· [2.1.3] - 2026-10-03

首个通过运行时门禁签核的版本。此前所有版本都靠编译或 grep 验证，其中三个版本发布的声明并不成立。

· 新增
· 发布运行时冒烟门禁（npm run smoke:release，已接入 prepublishOnly 和 .github/workflows/release-smoke.yml）。打包真实 tarball，解包，导入产物入口，调用 apply()，再把发出的调用与 DSH SDK 自带的 CLIENT_SLOT_API 比对。退出码 0 = 发布声明成立，1 = 不成立，2 = 无法验证。（issue #96）
· 运行时槽位探测。面板座位带一份候选列表，apply() 逐个尝试每个键，保留宿主接受的那个。若都不接受，就不注册该界面——宁缺勿假。注册路径里不再有静态槽位名。（issue #97）
· 界面渲染真实数据。知识库计数来自语料库，顾问界面显示真实教练输出，偏好设置显示 12 个 Config 字段的当前值。数据经 MCP 桥接到达 UI，TypeScript 里没有重写任何逻辑。（issue #98）

· 修复
· 列表槽位的 register options 带 id，不是 kind——门禁把两处都抓到了。

· 门禁发现了什么，意味着什么

两份目录对不上，而且这种分歧不是学术问题：

| 来源 | 键数 | details | sidebar.right.pane.tab |
|---|---|---|---|
| 锁定的 npm 包（用户实际安装的） | 42 | 有 | 无 |
| 上游 deepseek-harness@master | 92 | 无 | 有 |

用户装的是锁定包。插件不去选边，而是探测。改动后门禁输出：

 ✓ sidebar.footer.action list root required=[id]
 ✓ conversation.view list session required=[id]
 ✓ details single session required=[] ← 探测选了锁定包的键
 ✓ settings.section list root required=[id]
 VERDICT: PASS_WITH_WARNINGS exit 0 FAIL=0

2 条警告分别是 50 个键的目录漂移（只报告，从不合并成一份列表——合并等于拿一份没有宿主拥有的目录去验证）和门禁同样跑到的降级路径。

· 诚实的边界

门禁证明 apply() 发出的调用落在 SDK 声明的座位上，且组件非空。它不证明任何东西能渲染。这台机器上没有 DEEPSEEK_API_KEY，pr-genius 也从未在真实 DSH web 宿主里加载过。宿主挂载行为仍需真实运行时验证。

v2.1.22026-10-03

· [2.1.2] - 2026-10-03

砍掉 2.1.1，因为它重犯了 2.1.0 一模一样的错。2.1.1 的 slot-key 修复落在一个 apply() 从不读取的模块里，所以发布的包仍然注入了编造的 slot 名。这次对着模拟的 DSH 宿主验证过，不是靠 grep。

· 修复
· apply() 现在注册进真正存在的 slot。2.1.1 改的是 src/client/slots.ts 里的键，却让 src/index.ts 继续导入 src/ui/surfaces.ts，而 apply() 读的是后者里的 SURFACE_PLAN 表。那张表还写着 ui-sidebar / ui-settings-plugins——我从教程文字里猜出来的名字，发布的目录里根本没有。包里两套名字都带着，运行时用错了那套；client/slots.ts 是死代码。（issue #95）

· 变更
· src/ui/surfaces.ts 里的 SETTINGS_SURFACES 现在是所有挂载点的唯一来源——sidebar.footer.action（根列表）、conversation.view（会话）、sidebar.right.pane.tab（会话）。client/slots.ts 从它派生，不再自己声明副本；同一件事两张表，正是它们跑偏的原因。
· 编造的名字也从注释里删了，所以 grep 什么都搜不到，而不是搜到我解释它们错在哪的那段话。

· 验证

模拟一个只接受真实目录里键的 DSH 宿主，调用 apply()，看落下了什么：

sidebar.footer.action -> pr-genius.dashboard component=REAL
conversation.view -> pr-genius.advisor-tab component=REAL
sidebar.right.pane.tab -> pr-genius.advisor-panel component=REAL
sidebar.footer.action -> pr-genius.preferences component=REAL
SKIPPED（不在 DSH 目录里）：无

dist 里的过期键：0。tsc 0，vitest 34 通过，validate --strict 0。

· 这个模式，记下来免得再犯

三个版本，一个形状：

| | 改了什么 | 怎么验证的 | 用户撞上什么 |
|---|---|---|---|
| #89 | parse_frontmatter | 调用了 parse_frontmatter | load_anti_patterns → _parse_simple_frontmatter |
| #90 | src/client/* | tsc + grep dist | 入口从没导入它 |
| #95 | src/client/slots.ts | grep dist 找到了键 | apply() 读的是另一张表 |

「产物里存在」不等于「用户走的路径上修好了」。上面那次运行时模拟，才是能抓住这三次的检查。

数据来自仓库的 GitHub Release，可能与插件实际版本不一致。

README

由 DeepSeek 最新模型翻译生成

type: Knowledge Bundle title: PR Genius — 你发出去的那些 PR 的看板 description: 面向 OSS 贡献者的外发贡献项目管理，不是代码审查工具。知道今天该动哪个 PR，以及具体怎么做。 version: 2.2.3 created: 2026-07-01 updated: 2026-10-17 author: zsxh1990 PR Genius 你的 GitHub 里，有一些 PR 你已经不再点开了。有一个需要 rebase，你一直说等会儿弄。有一个红了四天，没人告诉你。有三个摆了三周没人看。还有一个你干脆绕着走——因为点开它，就意味着确认它死了。 PR Genius 是这些活儿的看板。你往别人的仓库发出去的贡献——没有看板、没有站会、没人在替你记着。它不是代码审查工具。它从不读你的 diff，也不会告诉你「代码没问题」。那是另一类工具的活儿，而且有做得很好的。它回答的是一个真的在干活的人，周二早上会问的问题：我发出去的这些东西，今天该动哪个——具体怎么做？为什么会有这个东西 GitHub 记得住那条 PR。它记不住你为什么关掉了在某个仓库的第三次尝试。什么有效、什么无效。哪个 reviewer 真的会回，哪个评论过一次就消失了。上次把你弹回来的到底是体量、缺 issue 链接，还是语气。

展开完整文档（README 剩余 1 节）

type: Knowledge Bundle
title: PR Genius — 你发出去的那些 PR 的看板 description: 面向 OSS 贡献者的外发贡献项目管理，不是代码审查工具。知道今天该动哪个 PR，以及具体怎么做。
version: 2.2.3
created: 2026-07-01
updated: 2026-10-17
author: zsxh1990

PR Genius

你的 GitHub 里，有一些 PR 你已经不再点开了。

有一个需要 rebase，你一直说等会儿弄。有一个红了四天，没人告诉你。
有三个摆了三周没人看。还有一个你干脆绕着走——因为点开它，就意味着确认它死了。

PR Genius 是这些活儿的看板。 你往别人的仓库发出去的贡献——没有看板、没有站会、没人在替你记着。

它不是代码审查工具。它从不读你的 diff，也不会告诉你「代码没问题」。那是另一类工具的活儿，而且有做得很好的。

它回答的是一个真的在干活的人，周二早上会问的问题：我发出去的这些东西，今天该动哪个——具体怎么做？

为什么会有这个东西

GitHub 记得住那条 PR。

它记不住你为什么关掉了在某个仓库的第三次尝试。什么有效、什么无效。哪个 reviewer 真的会回，哪个评论过一次就消失了。上次把你弹回来的到底是体量、缺 issue 链接，还是语气。

那些东西在你脑子里。会话一结束就没了。

PR Genius 是它们该去的地方。

仓库画像记下这个项目要什么。
案例记下一次贡献怎么落地或怎么死的。
你自己的状态历史记下后来怎样——等了多久、什么变了、有没有回来。

第三样，代码审查工具和大模型都不可能有。它们只在别人的仓库里看见你的 PR 一次。这个看见的是你几个月的组合。

它知道什么

| 它知道 | 对你意味着 |
| 67 个大项目的实际做派 —— merge 率、review 节奏、什么会被关 | 你不用再猜 encode/httpx 想要什么 |
| 真实 PR 为什么被拒 —— 写下来了，带证据 | 你不用再重蹈别人已经赔进去三周的覆辙 |
| 你自己的 PR 后来怎样 —— 每个状态停了多久 | 你在它正在死的时候就知道，而不是三周后 |
| 你瞄准的那个仓库的政策 | 正文里一个 Fixes #N，仍然是第一条 PR 被弹回来的头号原因 |

给怀疑者看的数字：753 条模式、190 条失败 PR 观察、68 个仓库画像、302 个审过的案例。这些是上面那几句话的收据，不是重点——每次发布都会由 scripts/verify_claims.py 对着真实目录核一遍。

其中一个语料要说清楚：success-patterns/ 只作检索/参考，不参与评分。它是可以翻的背景，不是正反馈系统，从来没有改变过任何一次结论。真正推动风险档位的是那 61 条 anti-patterns。

九个状态，是九个决定

看板上的数字告诉你「有事」。状态告诉你「怎么办」。

| 状态 | 今天对你意味着 |
| NEEDS_REBASE | 花二十分钟，这条 PR 就还活着。 |
| CI_FAILING | 红了好几天，本来不会有人告诉你。 |
| STALE_REVIEW | 有人看过，然后停住了。现在动，或者它就凉了。 |
| STALE_NO_REVIEW | 没人看过。等、催、还是体面地撤——但要决定。 |
| CLEAN | 别管它。这同样是一句值得被告知的话。 |
| WAITING | 还在正常响应窗口内。去做别的。 |

看板一半的价值，在于告诉你今天不该把时间花在什么上。

它出现的两个时刻

在你提之前。 这个 ready 了吗，还是我准备浪费维护者的注意力？

python3 -m prgenius coach "fix: timeout in connection pool" \
--repo encode/httpx --body "Fixes #4821"

五个答案，每个都带下一步——READY_TO_SUBMIT、FIX_BEFORE_SUBMIT、NEEDS_DISCUSSION、IMPROVE_CHANCE、ASK_MAINTAINER。只读、只建议：不评论、不打标签、不关闭、不合并。

在它已经出去之后。 这些里面哪个需要我？

python3 -m prgenius status --author your-handle

九个状态、陈旧检测、每条给一个建议——修 CI、rebase、催、等、或者放弃。挂到 cron 上，它就变成你真的会看的那一行。

而且它会记住：STALE_NO_REVIEW for 5d, was NEEDS_REBASE。不是「有事」，是怎么走到这一步的。

安装

pip install "prgenius-core[mcp]" # 引擎 + MCP server

装完就能用——决策相关的语料（anti-patterns / profiles / pr-observations / policies）在 wheel 里，不用 clone。

prgenius-core doctor # 它找到了什么、缺什么，照实说
python3 -m prgenius status --author your-handle
python3 -m prgenius profile get owner/name # 这个项目到底要什么？

一条诚实的边界：success-patterns/（约 2.7 MB，只作检索参考、不参与评分）不进 wheel。
doctor 会说 success-patterns: not installed，而不是含混地报 0。想要它，clone 本仓并
export PRGENIUS_REPO_ROOT=<clone>。

它永远不会做的事

明说，因为这一页的其余部分如果这些含糊，就一文不值：

- 它不会告诉你代码是对的。 它不读 diff。
- 它不会替你发任何东西，除非你显式加 --confirm。所有会改动状态的命令默认 dry-run。
- 它不外联。 分析是本地的：无 LLM、无 API key、无网络调用。碰 GitHub 的那几个命令用的是你自己的 token，而且只读 PR 元数据。没有遥测——见 docs/ADOPTION_DATA.md。
- 它不装。 没验证过的事实就写没验证。这一页错过，更正在 CHANGELOG.md 里。

中文文档与延伸

- README.md —— 英文主文档
- docs/BLOG.md —— 上面那段故事的长文版
- README.zh.md —— 知识库中文导航

Contributing

仓库画像、案例、anti-patterns 都欢迎——见 CONTRIBUTING.md。瓶颈是每个上游的整理工时，不是基建：一个仓库画像大约 30 分钟调研，再加上在上游落地一个支撑性 PR 的功夫。

引用

@software{pr_genius,
title = {PR Genius — the board for your outbound open-source contributions},
author = {zsxh1990},
year = {2026},
url = {https://github.com/zsxh1990/pr-genius}
}