no_human

你可以信任的 AI 编码工厂：

• 先制定计划，再编写任何代码，依据工单和它在你的代码仓库中发现的内容。 计划制定失败时，会告知编码器它正在无计划的情况下工作；如果判断更改很简单，则会按设计跳过计划而不告知编码器——跳过这一事实仍会记录在运行事件流中。
• 对抗式审核。 由另一个模型在从未看过编码器对话记录的会话中进行，并被要求反驳“已完成”的说法。你会得到一份通过／未通过清单，其中引用文件和行号——绝不会给出数字自评分。
• 防篡改保护。 删除测试、新增跳过项、把断言改成恒真式——审核关卡运行前会通过机械方式统计这些情况，然后根据你的验收标准说明理由，否则就停止尝试。
• 修复确实解决了 Bug 的证明。 作为证据提交的测试必须在合并基点上失败，并在新代码树上通过——复现关卡会在两者上都运行测试。开箱即用时，这会约束 Python Bug 修复；repro_gate.mode: required 则会约束所有类型和所有更改。
• 运行你的测试，在本地运行，也可选择通过你的 CI 运行——如果 PR 没有找到测试命令，就会明确标示为 NOT RUN。
• 如实停止。 无法完成时，它会停止并说明原因——如果你的回答能让它继续，就提出具体问题；如果只是预算耗尽，就给出结构化记录——绝不会编造一个看似合理的差异。

关卡拦截了什么

no_human 用 no_human 构建 no_human。在它自己的看板上运行 65 天以上，以下情况无一进入拉取请求：

• 编码器称已完成的 1,709 次尝试中，有 505 次 被第二个模型退回，每次都附有引用文件和行号的通过／失败检查清单。
• 有 44 次尝试 在审查开始前就被拦截，因为它们删除或削弱了测试。
• 有 46 份错误修复证明 被拒绝，因为作为证据提供的测试在旧代码上也能通过。

这些数据的统计方式

安装

一行命令（CLI + 看板）

uv tool install no-human   # or: pipx install no-human — the wheel ships the board
nh init && nh doctor       # token, config, first repo; then prove the install is real

桌面应用

每个版本都会随附与构建产物一同发布的 SHA-256 校验值。平台说明和 首次运行指南：docs/quickstart.md。

从源码构建

git clone https://github.com/no-human-ai/no_human.git && cd no_human
uv sync                 # installs the `nh` entry point into .venv
(cd web && npm install && npm run build)   # builds the board (cold first install can take minutes)
uv run nh init          # token, config, first repo (about 2 minutes)
uv run nh doctor        # verify the install is real before relying on it

如果需要看板，web 构建并非可选项：源码检出版本不包含 web/dist，因此不执行该构建时，nh start 只会提供 API，不会渲染 UI。 需要 Python 3.12+、uv、git，以及用于构建看板的 Node 和 npm。

产品亮点

编写代码前先制定计划 根据任务单和你的代码仓库撰写可检查的验收标准。
独立审查者 另一个模型从未见过编码者的会话，并被要求反驳“已完成”的结论。给出通过或失败结果；每条阻塞性问题都会注明文件和行号。
测试结果直接显示在 PR 上 可在本地运行，也可通过 CI 运行。找不到测试命令时会显示 NOT RUN，绝不会留空。
防篡改保护 审查前会统计被删除的测试、新增的跳过项和同义反复断言。若没有正当理由，尝试就会停止。
证明修复确实修好了缺陷 作为证据提交的测试必须在旧代码上失败、在新代码上通过。门禁会分别运行两者，事件日志会显示结论。
坦诚地暂停 需要你提供信息时，它会停下来并提出一个具体问题，而不是猜测。
跟踪工具中的任务单，显示在你的看板上 从待办列表中选择 Jira 或 Linear 任务单（会轮询 monday.com 看板）。每项任务都会先与你一起明确范围，再开始执行。

_{截图：演示工作负载中的真实看板。}

运行一个任务

不带参数运行 nh 即可打开 shell：查看你的任务列、实时事件流，以及一个可用通俗语言描述任务的输入区。以下每条命令仍然有效。

nh                                   # the shell
nh start                             # board + worker on 127.0.0.1:8420
nh task add https://github.com/org/repo/issues/42 --repo ~/git/repo
nh status                            # needs-you / working / waiting / done
nh review <id>                       # the reviewer's evidence checklist
nh diff <id>                         # the diff it wants to ship
nh approve <id>                      # your approval squash-lands the PR (git.approve_identity)
nh reject <id> --reason "..."        # send it back with feedback

集成

将 no_human 指向你已在使用的跟踪器，它就会将工单拉取到你的看板 — 跟踪器的筛选条件保存在你的配置中，绝不会写在任务自身的文本里；传输错误会被记录，并在下一次轮询时重试，而不是导致任务池崩溃。

跟踪器	工单的获取方式	你配置的筛选条件
Jira Cloud	通过 REST search/jql 轮询（HTTP Basic email:token）	integrations.jira.jql
Linear	通过 GraphQL API 轮询	integrations.linear.team_key + state_types + label
monday.com	通过 GraphQL v2 轮询	integrations.monday.board_id + status_column + todo_labels

启用写回（write_back，默认关闭）后，工单会随任务一同流转 — 根据状态类别、类型或你指定的标签匹配，绝不使用硬编码的 transition id — 并附上 PR 链接；需要人工处理的任务会收到评论，绝不会被流转。GitHub 和 GitLab 的 issue 会按 URL 导入为任务，PR 或 MR 会在你自己的主机上创建；任务需要你处理时，Slack 和 Teams 会收到消息；Jenkins 和 CircleCI 可以运行你的测试层并为工作流设置门禁。各项配置说明： docs/adapters.md。

查看 Jira 工作流的完整过程 — 从 Jira 看板同步工单、确定范围、完成实现，到交付通过评审的拉取请求（点击观看包含每个步骤的完整视频）：

▶️  播放完整演示 — 1:33，从 Jira 看板到通过评审的 PR

GitHub Action

将同一套对抗式审查器和篡改防护作为拉取请求检查运行 — 单次运行，无守护进程，无 ~/.no_human 数据库，也不走会将任务排入队列的 nh review CLI 路径。它只评估差异：与本地运行不同，它不会收集 lint、接线或类型证据，也不会探索代码仓库。它会发布一条包含 file:line 引用的通过/失败清单评论；评论通过自身标记查找，并在每次运行时原位更新，而不是每次都新建一条。该评论会用 @ 提及拉取请求的作者（作者信息来自事件载荷，绝不从差异或 PR 自身的标题/正文中获取）— GitHub 会在首次运行创建评论时发送通知，但在后续原位编辑评论时不会发送；评论会明确说明本次运行属于哪种情况。

# .github/workflows/review-gate.yml
name: no_human review gate
on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}
      - uses: no-human-ai/[email protected] # a release tag; a reviewed SHA is stronger — see below
        with:
          credential: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ github.token }}

permissions.contents: read 允许 actions/checkout 读取此代码仓库；pull-requests: write 则用于允许 Action 发布/更新自己的评论。两者都不会授予更广泛的权限。检出步骤中显式设置 ref: ${{ github.event.pull_request.head.sha }} 也很重要：对于 pull_request 事件，actions/checkout 默认检出的是临时合并提交，而不是 PR 的实际头部提交；Action 会根据磁盘上的代码树审查并引用行号 — 如果检出的不是正确代码树，它会拒绝运行，而不是审查错误的版本。因此，省略此处的 ref: 会导致红色且可采取行动的退出码 2，而不是悄无声息地错误审查。

此 Action 目前还没有 v1 标签。v0.2.4 是首个包含 action.yml 的发布标签，因此 no-human-ai/[email protected] 可以解析，也是上方示例固定使用的版本 — 但发布标签不是会自动更新的主版本，而 @main 指向最近合入的内容。你已审查过的提交 SHA（no-human-ai/no_human@<sha>）则更加可靠：分支按定义会移动，标签也可以被移动，因此只有 SHA 能确保此代码仓库之后的更改不会改变你的工作流实际运行的内容 — 而此 Action 运行时会使用你的凭据。 credential 接受两种形式的 Anthropic 凭据：ANTHROPIC_API_KEY（sk-ant-api...）或通过 claude setup-token 生成的 Claude 订阅 OAuth 令牌（sk-ant-oat...）。Action 会根据前缀自动检测，也可以通过 credential_mode: oauth / credential_mode: api_key 显式指定。无论传入哪种形式，审核器运行前，另一条凭据路径都会从作业环境中清除；凭据值一经读取，便会立即在日志中屏蔽。

必须提供凭据，不会静默回退。 如果 secrets.ANTHROPIC_API_KEY（或你接入 credential 的其他密钥）为空、未设置，或即使在 auto 模式下也无法识别其形式，运行会以退出代码 2 明确失败，并指出 credential 输入项和所需密钥；此时审核器和任何 GitHub API 调用都尚未运行。审核器本身出错或模型调用遭拒时，同样会采用失败关闭规则，退出代码也为 2。凭据或审核器出错时，Action 绝不会发布 PASS，也绝不会以 0 退出——但绿色勾选并不总是表示该门禁审核了代码：来自 fork 的拉取请求会以退出代码 0 跳过，且不会调用审核器（见下文）；没有差异（无内容可审查）的拉取请求则会发布模拟 PASS，且不会调用审核器或防篡改检查。如果将此项设为必需检查，必须将这两种情况都视为“未审核”，而不是批准。差异超过审核器单轮处理上限时，会以退出代码 2 拒绝，而不会只审核被截断的前缀；因此这种情况绝不会显示绿色勾选：请降低 max_files 或拆分拉取请求。

来自 fork 的拉取请求会被跳过，而非审核。 如果拉取请求的 head 不属于此仓库——包括已删除 fork 发起的拉取请求——就不会交给审核器或模型处理；Action 会以退出代码 0 结束，并说明跳过原因且不发表评论，而不会在能够访问密钥的作业中针对未经审查的 head 运行审核代码。pull_request_target 会被直接拒绝（退出代码 2），即使凭据有效也不例外，因为这种触发器可能将 fork 的 head 带入可访问密钥的作业。

workflow_run 也是受支持的触发器。它会通过 GitHub REST API 还原拉取请求编号、head 提交和变更文件，而不是从 pull_request 载荷中读取。由于此模式下没有已检出的仓库工作树，因此不会运行防篡改检查；发布的评论会明确说明这一点，而不会让人误以为已通过防篡改检查。

Dependabot 发起的拉取请求会以退出代码 2 失败关闭，这是 GitHub 的限制，而非此 Action 的限制。 Dependabot 发起的拉取请求与其 head 属于同一仓库——它不是 fork，因此不会被上述检查跳过——但 GitHub 本身会在 pull_request 事件触发的工作流运行中屏蔽仓库密钥（并将 GITHUB_TOKEN 降级为只读），这是平台层面的一项防护措施，用于防止锁文件更新将恶意安装脚本带入可访问密钥的作业。因此，这些运行中的 credential 会为空；此 Action 自身的失败关闭规则（见上文）会使其以可采取措施的退出代码 2 标红，并指出缺少哪个密钥，而不会静默跳过或错误地显示 PASS。如果你要求此项检查通过，并希望 Dependabot 的拉取请求显示绿色勾选，可以在分支保护规则中将其豁免，或者接受它们需要维护者像处理其他需要密钥、但 GitHub 不会提供给机器人触发作业的检查一样，手动重新运行或批准。 成本取决于文件数，而非令牌数或时间。 max_files（默认值为 15）限制发送给审查器的变更文件数量，按路径排序后取前 N 个；评论会报告实际审查的文件数占总数的多少。审查器以 single_turn 运行，因此通过时只需一次模型调用来处理数量受限的差异；未通过时可能再进行一次有界的反驳审查。粗略来说，根据差异大小，这会消耗你自己的 Anthropic 用量，费用从几美分到几十美分不等，与运行一次本地 nh review 的成本相近。这与运行器每次构建 Docker 镜像的一次性成本是分开的；除非你的工作流缓存了镜像，否则每次运行都会花费几十秒的 GitHub 托管运行器计算时间，而非模型费用。降低 max_files（或拆分大型拉取请求）可以减少花费。

该 Action 除了发布一条自己的评论外，绝不会合并、推送、批准或编辑拉取请求中的任何内容——这由代码强制执行，而非仅凭约定：每次 GitHub API 调用发出前，都会检查它是否属于仅包含两个端点的允许列表（列出/创建/更新那一条评论）。将 fail_on_findings: false 设为不因检查失败而保留评论，或将 dry_run: true 设为仅在作业日志/摘要中输出结论，完全不调用 GitHub API。

已知限制：防篡改保护关于“完整测试树”的说法仅适用于 ASCII 测试文件名，不适用于非 ASCII 文件名。 防篡改检查会通过未加引号的 git ls-tree 遍历仓库中的每个测试文件（而不只是发送给审查器的、受 max_files 限制的子集），因此，名称包含非 ASCII 字节的测试文件会以 Git 的 C 引号字符串形式列出（例如 "r\303\251gression_test.py"），而非其真实路径，因而会被静默排除在前后对比之外——目前无法检测此类文件是否被删除或弱化。该 Action 自身的差异/审查文件列表不受同类问题影响（它会明确地重新引用并重新验证交给审查器的每个路径），但底层防篡改检查模块不在此 Action 的修改范围内。如果你的测试套件包含非 ASCII 测试文件名，在上游修复此问题前，请将防篡改保护对这些特定文件视为尽力而为。

已知限制：两个运行同时进行，或拉取请求已有 1,000 条以上其他评论时，可能会产生重复评论。 该 Action 会列出拉取请求的评论（最多 10 页，每页 100 条），并选取带有其标记的最低 ID 评论，以查找自己先前发布的评论；如果两个运行几乎同时启动，都可能在任一运行创建评论之前完成列表操作，随后各自创建一条评论。之后任一运行都会恢复一致——再次列出评论，找到最低 ID 的带标记评论并更新它——但不会删除多出的评论。“先列出，再操作”的间隙还意味着，如果带标记的评论只会出现在第 11 页或更后（即拉取请求已有 1,000 条以上其他评论），它会被视为不存在，于是会新建评论而非更新已有评论。这两种情况都是已接受并记录在案的限制，而非静默失败：如果你的工作流可能针对同一次提交触发两次运行，请添加一个以拉取请求为键的 concurrency: 分组，将两次运行串行化。

MCP 服务 — 将工作交给你当前 Agent 中的助手

no_human 提供 MCP（Model Context Protocol）服务：这是一个基于官方 Python MCP SDK 构建的 stdio 桥接程序，可让 Claude Code、Cursor 或任何 MCP 客户端向本地 no_human 提交工作并查看进度。

nh mcp-serve        # the MCP server, over stdio

只有两个工具，不多不少：

工具	功能
task_add(title, description, repo_path)	提交一项任务。随后，no_human 会规划任务、编写更改、运行测试、让第二个模型进行审核，并创建拉取请求。
task_status(task_id_or_external_id)	返回该任务的当前状态——状态、尝试次数，以及创建拉取请求后的链接。

它只与您自己的 no_human 通信，地址为 http://127.0.0.1:8420：无需身份验证，因为该地址是 localhost，且中间没有我们的任何服务。对于 Claude Code，同一服务也以插件形式提供——此仓库本身就是它的插件市场，因此完成以下操作后，这两个工具就会出现在您的会话中：

/plugin marketplace add no-human-ai/no_human
/plugin install no-human@no-human-ai

其他 MCP 客户端使用常见的 stdio 入口：

// .mcp.json
{ "mcpServers": { "no_human": { "command": "nh", "args": ["mcp-serve"] } } }

该插件还提供 review-this-branch 技能，无需 MCP 服务或 ~/.no_human：它会运行 nh gate 这个一次性 CLI 命令，使用您自己的 Claude 凭据，直接在当前分支或 GitHub 拉取请求上启动新会话对抗式审查器和防篡改守卫，然后退出并输出通过/失败的 Markdown 检查清单；除了 nh CLI 本身，不会安装或运行任何其他内容。

nh gate                        # current branch vs. its merge base with origin's default branch
nh gate --pr <github-pr-url>   # a GitHub pull request's head vs. its merge base

文档

quickstart.md	各平台从零开始到提交第一个任务
configuration.md	所有设置和默认值
verification.md	关卡、有限循环及其限制
security.md	身份验证边界、绝不合并规则及守卫
blockers.md	升级处理、唤醒监视器、nh reply
adapters.md	接收、上下文、VCS 和 CI 后端
eval.md	黄金集、回放评分、影子模式
CHANGELOG.md	各版本的变更内容

开发

uv sync
uv run pytest -q
uv run nh --help

欢迎提交问题和拉取请求；提交前请运行 uv run pytest -q。

如果 no_human 帮您省下了一轮审核，点个星标可以帮助更多人发现它：

社区

如有问题、Bug 报告或值得展示的运行记录，请加入 Discord， 在 r/no_human 发帖，或提交 GitHub 问题。

许可证

MIT — 请参阅 LICENSE。该许可适用于代码，不适用于名称： TRADEMARK.md 说明了使用“no_human”和徽标的政策。 打包二进制文件需承担源代码树无需承担的义务，详见 THIRD-PARTY-NOTICES.md。