从编码 AI 用平台
开发同事电脑上的编码 AI（Claude Code、Cursor、Codex 这类）可以直接连上一个项目，用 MCP 工具走完整个流程：接入、写测试、审核、预跑、正式测试、看报告，改了再测。不用人在网页和编码 AI 之间来回复制。它能做到哪一步，由你在网页上给这个连接勾的权限决定。
平台里把这样连上的编码 AI 叫「开发机 AI」。它用的是你们自己的编码工具和它自己的模型账户，平台不在你们的代码上运行编码 AI。
建一个连接
- 打开项目的「设置 → 开发机 AI」。
- 在「它可以：」下面勾这个连接能做的事（见下表）。
- 勾了「发起正式测试」的，在旁边填「每天最多花 $」，或者勾「不限」（见每天的费用上限）。在本地测试机上跑的项目默认每天 $5；连 GitHub 仓库或自带镜像的项目（在云端沙盒里跑）默认不限。
- 在「AI 怎么连：」里选「用开发机上的 reviewctl」或「MCP over HTTP（不用装 reviewctl）」。
- 在「AI 用什么语言：」里选「中文」或「English」（见语言）。
- 点「生成连接命令」。
只有人在浏览器里能建连接、改权限。连接以建它的人的身份做事，30 天有效；建它的人离开组织，连接就失效。
权限
| 权限 | 默认 | 勾上后它能做什么 |
|---|---|---|
| 写测试草稿和上传文件 | 勾 | 交测试草稿，上传草稿缺的测试文件，让平台的 AI 再审草稿 |
| 改测试接入文件（.reviewctl） | 勾 | 存平台上的测试接入文件，和人在「目标」里保存一样核对 |
| 预跑 | 勾 | 让平台在测试机或沙盒里预跑一次 |
| 发起正式测试 | 勾：本地测试机上每天最多 $5，云端沙盒里不限 | 发起正式测试，受每天的费用上限约束 |
| 确认测试 | 不勾 | 确认草稿，和人在网页上确认一样核对。不勾时平台的 AI 照样审草稿，其余的等人在网页上确认 |
| 让平台的 AI 补全接入 | 勾 | 发起「让 AI 补全并检查」 |
| 改通过标准 | 不勾 | 存项目的通过标准 |
看东西不要权限：测试、任务、报告、诊断和测试接入文件，连接都能读。取消只能取消这个连接自己发起的正式测试或预跑。
没勾的步骤，平台不做，并告诉编码 AI：「这个连接没有「…」的权限，没有做：请开发同事在网页「设置 → 开发机 AI」里，在这个连接上点「改权限」勾上它」。被拒的这一次也记在连接那一行。
每个连接在「设置 → 开发机 AI」里占一行：用 reviewctl 连的写机器名，用 MCP over HTTP 连的写「远程 MCP」；下面是它能做什么、今天用了多少、最近做了什么。点「改权限」打开同样的框，改完从它的下一次调用起生效，改动记进审计日志。连续 5 次交测试没交成，或者连续 5 次预跑没通过，连接会暂停，点「让它继续」才能接着做。暂停时编码 AI 的 get_status 会列出最后一次没交成的问题（或者最后一次预跑没通过的原因），并给出这一页的链接。点「断开」作废这个连接（先问你一句）。
这次更新之前建的连接只能写草稿、传文件和预跑。要它做更多，在它那一行点「改权限」。
语言
每个连接有自己的语言，中文或英文：建连接时在「AI 用什么语言：」里选，不选就是你网页的语言。连接那一行写着是哪种（「AI 用中文」），点「改权限」能改，从它的下一次调用起生效，和改权限一样记进审计日志。有语言之前建的连接用中文。
按连接的语言说的，是平台对它的 AI 说的所有话：MCP 服务的说明和每个工具的标题、说明和参数；每个工具的返回和下一步；拒绝和报错；get_prompt 的提示词（英文的会要求测试里的文字也用英文写）；预跑、任务和运行的结果；get_report、get_diagnosis、get_fixes；以及页面上给你发给它的那句话。测试、人或被测 Agent 写的内容（测试的标题、Agent 的回复）照原样。平台 AI 诊断写的每条修改意见都有中英两种，英文连接（和英文的网页）读英文的，条件也是英文（"under normal conditions"）；平台自己的规则改修改意见时（前面加「只改你们自己的代码」、换成平台自己的修改意见、把文件名改对），英文的也一起改。在这之前做的诊断，和 AI 追问后仍没写英文的，仍是中文。get_job、wait_job 里预跑的结果也按连接的语言。草稿等人确认的理由（「平台 AI 诊断的改法去掉或放宽了…」，里面 AI 自己的理由是全的）和报告里通过标准的原因，也按连接的语言，这样的草稿也列成要人确认的（list_tests 的 needs_person）。get_diagnosis 里安全检查的名字对英文连接是英文的（"System prompt extraction"），和 get_fixes 一样。用英文写的测试，它的规则原文里平台自己的话也是英文：上面的说明、AI 自动审批确认时写的是谁确认的（"AI auto-approval (on by default)"；网页上按看的人的语言显示），以及按目标生成的给评审模型的说明。之前存的测试，给评审模型的说明在它改动之前不变。用英文写的默认安全测试，里面平台自己的话也是英文：上面的说明、各项检查的名字、给评审模型看的 Agent 做什么和谁是登录用户，以及给评审模型的说明里的例子；之前写的照原样，英文连接读到的攻击类别名照样是英文（get_report 里的 "question r17 (System prompt extraction)"）。connect --ai 给英文 Agent 写的起步测试，它加的备注（"Assumptions made while drafting"）也是英文，英文测试上平台自己核对时记下的备注（还缺的测试文件、规则用到的参数测试机没有报）也是英文。submit_answer 说每个测试跑什么、核对什么（tests），get_experiment_rows 说一项为什么没判定，也按连接的语言。reviewctl 在你终端里打印的话照旧按 REVIEWCTL_LANG 或系统的语言。
编码 AI 那边怎么知道：MCP over HTTP 每次调用按令牌的连接。reviewctl dev mcp 的，reviewctl dev connect 把语言存进 ~/.reviewctl/dev-links/ 下这个连接的文件；平台每次返回都带着这个连接现在的语言，reviewctl dev mcp 那次返回里自己的话就按它说，并写回这个文件（reviewctl dev status 也会写回），所以网页上改了之后，下一次返回就全是新的语言。工具的说明从下一次列工具起跟着改；MCP 服务的说明在它启动时读，要换成新的语言，重启 MCP 服务（或编码 AI 的会话）。
用 reviewctl 连（stdio）
开发机上要先装好 reviewctl，见命令行：安装。
页面给出一句话，复制发给编码 AI。它会在仓库里运行：
reviewctl dev connect <配对码> --api https://<平台地址> --register <claude|cursor|codex> --yes配对码 10 分钟内有效，只能用一次。点「换一个配对码」后，页面上原来那个马上作废：它那一行不再显示，再用它连会被拒，并说它已经作废了。这条命令连上平台，把连接按仓库存在本机的 ~/.reviewctl/dev-links/ 下（每个仓库一份：一台机器可以同时连几个项目，在哪个仓库里运行就用哪个仓库的连接），再把 MCP 服务 reviewctl-dev（就是 reviewctl dev mcp）注册到编码工具里：
--register | 怎么注册 |
|---|---|
claude | 机器上有 claude 命令时用 claude mcp add；没有时写进仓库的 .mcp.json |
cursor | 写进仓库的 .cursor/mcp.json |
codex | 机器上有 codex 命令时用 codex mcp add；没有时只给出要加进 ~/.codex/config.toml 的几行，不替你改用户目录里的配置 |
none | 不注册 |
已经有一样的 reviewctl-dev 就不动。有一个不一样的，只在终端里问你，回答 y 才换；不是终端（或者带了 --yes）就留着它，并说怎么换。读不懂的配置文件不碰。不写 --register 时，在终端里会问注册到哪个；不是终端就只给出手动注册的命令。
注册好后，在这个仓库里重新打开编码工具，就能用这些工具。这次会话里还调不到的，编码 AI 可以先用同样的 reviewctl dev 命令（见命令行）。
--register 没成功时，手动注册：
claude mcp add reviewctl-dev -- reviewctl dev mcp # Claude Code
codex mcp add reviewctl-dev -- reviewctl dev mcp # CodexCursor：在仓库的 .cursor/mcp.json 里写
{ "mcpServers": { "reviewctl-dev": { "command": "reviewctl", "args": ["dev", "mcp"] } } }断开：在仓库里运行 reviewctl dev disconnect。平台上这个仓库的连接作废，本机为这个仓库存的连接删掉；别的仓库的连接不动。旧版本 reviewctl 存的 ~/.reviewctl/dev-link.json 照样能用：没有自己连接的仓库用它，在这样的仓库里断开就断它。注册过的 MCP 服务要自己删：claude mcp remove reviewctl-dev（Codex 是 codex mcp remove reviewctl-dev），或者从 .mcp.json、.cursor/mcp.json 里删掉 reviewctl-dev。
在本地测试机上顺带启动测试机
接本地测试机的项目，预跑和正式测试都在测试机上跑，测试机要在线（get_status 会说它在不在线、不在线怎么办）。在测试机就是这台开发机时，用 --runner：
reviewctl dev connect <配对码> --api https://<平台地址> --register claude --runner这样注册的是 reviewctl dev mcp --runner。MCP 服务起来后，它在后台用 reviewctl runner start 启动这个项目的测试机，服务退出时一起停掉。日志在 ~/.reviewctl/logs/runner-<项目编号>.log。要启动，这台机器得已经注册成这个项目的测试机（见本地测试机），review.yaml 里的项目对得上，平台上也还没有在线的测试机；它用当前目录的 review.yaml，没有就用 .reviewctl/review.yaml，也可以用 --config 指定。启动了没有、为什么，get_status 会说。
接本地测试机的项目，页面给的那句话和手动注册的命令里已经带了 --runner；没带时，reviewctl dev connect 会提醒。
用 MCP over HTTP 连
不想在开发机上装 reviewctl，就选「MCP over HTTP（不用装 reviewctl）」。点「生成连接命令」后连接马上建好，不用配对码。在编码工具里按页面给它的那几行注册。Claude Code（在仓库里运行）：
claude mcp add --transport http preworld https://<平台地址>/v1/dev/mcp --header "Authorization: Bearer <令牌>"Cursor 和其他读 mcp.json 的工具：
{ "mcpServers": { "preworld": { "url": "https://<平台地址>/v1/dev/mcp", "headers": { "Authorization": "Bearer <令牌>" } } } }Codex 见下面的 Codex。别的编码工具按它自己注册远程 MCP 服务的方式，填同一个地址和请求头。
令牌以 dl_ 开头，只显示这一次：离开或刷新页面后就看不到了，丢了就断开这个连接再建一个。不要把它提交进仓库。没带令牌、或者带的是已经断开或过期的连接的令牌时，每次调用都回 401，说是哪一种，以及要做的是在编码工具里换上新连接的令牌（PREWORLD_TOKEN，或 Authorization 头），不是运行 reviewctl dev connect。401 按这个连接的语言说（断开或过期的连接也还记着它的语言）；平台没发过的令牌，按请求的 Accept-Language 说，两种都没要时中英文都说。注册好后，对编码 AI 说页面上的那句话：「用 preworld 的 MCP 工具连上测试平台，从 get_status 开始，按每一步返回的「下一步」做，最后告诉我结果。」
在编码 AI 第一次用这个令牌调用平台之前，连接那一行写「等它连上」，调用过以后才是「已连上」。
MCP over HTTP 的工具和 reviewctl dev mcp 一样，只少了 upload_file：平台读不到你们机器上的文件。草稿缺的测试文件，到网页上传，或者用 reviewctl；HTTP 连接拿到的提示词和下一步也这么说，不会叫它用 upload_file。
本地测试机的项目要注意：「不用装 reviewctl」说的是开发机 AI 自己。这种项目的预跑和正式测试都在测试机上跑，测试机还是要装 reviewctl、运行 reviewctl runner start（见本地测试机）；测试机不在线，编码 AI 连上以后第一步就会停在「先启动测试机」。MCP over HTTP 的连接平台不知道编码 AI 在哪台机器上，所以 get_status 说的是请管你们测试机的人在那台机器上启动它，要接新的测试机就在「目标」→「本地测试机」里点「生成配对码」。
接入只看回复的项目（review.yaml 的 attach.mode 是 endpoint_only），测试机报不出工具。这时场景的 tools 照样写一个：Agent 回复用户的那个函数或入口的名字，平台不拿它核对调用；这种场景不写 must_call、never、fault、attack、data_checks，用 goal_text 和 reply_must_say 说回复里要有什么。
Codex
Codex 的命令行、IDE 扩展和 ChatGPT 桌面应用都读 ~/.codex/config.toml。页面给出要加进去的几行，令牌从环境变量 PREWORLD_TOKEN 读，文件里不放令牌：
[mcp_servers.preworld]
url = "https://<平台地址>/v1/dev/mcp"
bearer_token_env_var = "PREWORLD_TOKEN"codex mcp add preworld --url https://<平台地址>/v1/dev/mcp --bearer-token-env-var PREWORLD_TOKEN 写进去的是同样几行。然后在启动 Codex 的环境里设好令牌，重新打开 Codex：
export PREWORLD_TOKEN=<令牌>要一直用，把这一行写进 shell 的配置文件（~/.zshrc、~/.bashrc），不要写进仓库里的任何文件。
ChatGPT 桌面应用不读 shell 的配置文件。在 macOS 上二选一：运行 launchctl setenv PREWORLD_TOKEN <令牌>，再退出、重新打开桌面应用（到注销为止有效）；或者把令牌存进钥匙串，用 http_headers_helper 让 Codex 每次去读，它是一条把请求头按 JSON 对象打印出来的命令：
security add-generic-password -s preworld-review -a "$USER" -w # 会提示输入令牌#!/bin/sh
# ~/.codex/preworld-headers.sh（chmod +x）
token=$(security find-generic-password -s preworld-review -w) || exit 1
printf '{"Authorization":"Bearer %s"}\n' "$token"[mcp_servers.preworld]
url = "https://<平台地址>/v1/dev/mcp"
http_headers_helper = "/Users/<你>/.codex/preworld-headers.sh"Codex 的 Preworld Review 插件带着连 https://review.nice2.io 的这个 MCP 服务（同样从 PREWORLD_TOKEN 读令牌），和一份带 Codex 走整个流程的技能：先查什么，怎么对照代码读报告、诊断和修改意见，哪些事绝对不做（放宽通过标准、没有权限时确认测试、提交令牌、在你们机器上运行被测 Agent 的任何代码、登录测试机），最后要告诉你什么。插件和技能都是英文的。它还没上公开的插件目录；有它所在仓库的一份副本（是一个名为 preworld 的 Codex 插件市场）时：
codex plugin marketplace add <副本的路径>
codex plugin add preworld-review@preworld装好后对 Codex 说「Test this agent with Preworld Review」。config.toml 里的 [mcp_servers.preworld] 会代替插件里的服务：要让插件连别的平台地址，或者用钥匙串那条命令，就这样写。
没人在旁边点同意的 Codex（codex exec），比如在 CI 里：它默认的审批策略是 never，preworld 里不是只读的工具全都会被拒（「MCP tool call requires approval, but approval policy is never」）。--approve-for-me 让审批走 Codex 的自动审核，但不能和 -s（--sandbox）一起用。要自己定沙盒模式，就改设审批策略和审核方：
codex exec -s workspace-write -c approval_policy="on-request" -c approvals_reviewer="auto_review" "Test this agent with Preworld Review" < /dev/null在后台启动的 codex exec 会一直等标准输入（「Reading additional input from stdin...」），要加 < /dev/null。
每次改完都测（AGENTS.md）
Codex 和其他读 AGENTS.md 的编码工具，会照仓库里 AGENTS.md 写的做。要编码 AI 改完 Agent 先测过再说改好了，把下面这段贴进仓库的 AGENTS.md：
## 测试 Agent
这个仓库的 AI Agent 用 Preworld Review 测试，通过 `preworld` 的 MCP 工具。
- 改了 Agent（代码、提示词、工具或模型设置）之后，先跑一遍 Preworld Review 的流程，再说改好了：从 `get_status` 开始，用 `try_run` 预跑，用 `run_tests` 发起正式测试、`wait_job` 等它跑完，再看 `get_report`、`get_diagnosis` 和 `get_fixes`。
- 每条发现先对照代码核实再改。绝不为了通过而放宽通过标准，或者改测试的期望。
- 发起正式测试前先说要花多少；连接暂停了、今天的额度用完了、或者没有某一步的权限时，停下来告诉我。
- 最后告诉我结论、报告链接，以及改了什么。流程和工具
一共 40 个工具（MCP over HTTP 少了 upload_file，是 39 个）。每个工具的返回都写了下一步；连接没有权限的步骤，返回会说要谁在哪里打开。
每个工具都有标题和 MCP 的标注（annotations），编码工具据此判断哪些要你点头：只读的（get_status、list_tests、get_report、wait_job 这类，以及已经去掉、只会说明这一点的计划工具）标 readOnlyHint（get_tasks 不算：它会把派来的活领走）；可能改掉或结束已有东西的（submit_answer、finish_task、put_wiring_file、start_connect_assist、review_drafts、confirm_test、cancel_job、set_gate）标 destructiveHint；try_run、run_tests、start_connect_assist 会运行被测 Agent，标 openWorldHint。
跑的是哪版代码。 try_run、get_setup、get_job、wait_job 和 get_report 都写明每次预跑和正式测试跑的是哪版代码，文字里有，结构化内容里也有（code）。在本地测试机上：提交、有没有未提交的改动，以及每个改过的或新加的文件和它内容 sha256 的前 12 位，可以和你这边的文件对照（shasum -a 256 <文件>），最多列 30 个文件。离开测试机的只有文件名和哈希，没有内容；文件名像密钥的（.env、密钥文件）只列名字，不给哈希。review.yaml 里 agent.version.git 开着（默认开）、目录在 Git 仓库里时，测试机才报这些。在云端沙盒里：提交，加上平台的测试接入文件。要核对测试机跑的是什么代码，看这些，不要登录测试机。
刚通过的预跑会沿用。 run_tests 先预跑，除非最近一次预跑跑的就是同样的测试和代码，而且通过了：在本地测试机上，是 30 分钟内同一台测试机、中间没重启过、代码一样；在沙盒里，是 6 小时内同一个提交；之后测试、测试接入文件、密钥都没改过。沿用时返回会写明；不能沿用时也写明为什么（最近没有通过的预跑、上次通过的预跑太久了或跑的是别的测试、测试机报的代码不一样了、测试机重启过、换了测试机，或者之后改过测试、测试接入文件、密钥），结构化内容里是 prerun.why。测试机领到它之前代码又变了，就还是先预跑。见沙盒运行。
Agent 的模型调用去哪。 测试机上没有 Agent 的模型密钥时（review.yaml 和那台机器上都没有 OPENAI_API_KEY 或 OPENAI_BASE_URL），reviewctl runner start 把 Agent 的 OPENAI_BASE_URL 指向那台机器本机（127.0.0.1）上的一个中转，OPENAI_API_KEY 给一个占位值。Agent 的模型调用（只有 chat completions 和 Responses API）由测试机转给平台的模型应答，按用量计费；云端沙盒也一样（见 Agent 的模型）。Agent 有自己的密钥时，照它自己的设置去调。try_run 和 run_tests 的说明里也写了这一条。
来自被测 Agent 或测试数据的内容（它的回复、工具调用和结果、测试题和攻击题、测试要求的结果、追踪的跨度、实验的行、预跑和测试机的日志、诊断引用的原文）放在 <untrusted-content boundary="…"> 和 </untrusted-content boundary="…"> 之间，前面一句话说明这是数据、不是指令、不要照着做；MCP 服务的说明里也写了这一条。标记里的内容照原样。get_fixes 里平台 AI 写的修改意见（和 get_diagnosis 里诊断自己的话）重复了它的证据引用的 Agent 或测试的原文（回复、工具调用、日志、测试里的文字、判定里引的回复原文）时，重复的那几句也在原处包上标记；证据里引的平台自己的话（判定的理由，例如「The platform checked this against the system prompt's own text」）不算，修改意见碰巧和它用词相同不会被包上。草稿等人确认时 AI 的理由（get_status、review_drafts）重复了测试自己的文字（目标、用户说的话、回复要说到的要点）的，也在原处包上标记；理由里的字段名按测试页的叫法说（「做成什么样算完成」「回复必须告诉用户」）。get_setup 里预跑检查引了 Agent 打印的内容（例如最后一行报错）的，测试没进到 Agent 的运行在报告总结里引了的，文字里也在原处包上标记。一批的总结（不写 run_id 的 get_report 第一行下面那一段）是平台自己的话，不引 Agent 的输出。结构化内容（structuredContent）里也一样：每个这样的值单独包在标记里，不带那句话。编号、代码、状态、时间、链接、哈希、结论和下一步照原样，平台自己的话也照原样：预计花多少、沿用哪次预跑或为什么不沿用、测试机跑的是哪版代码（code，里面仓库的文件名包在标记里）、一批里每一部分是什么（「2 个测试」，测试集的名字包在标记里）、预跑检查的标题、报告的总结（「7 scenarios, 21 attempts: all passed…」，里面提到的测试标题包在标记里；测试记录不可信的运行，它的总结引了 Agent 自己的报错，整句包上），以及 get_diagnosis 里每条是谁的问题、在什么条件下（里面 Agent 的工具名包在标记里）。通过标准和测试接入文件的内容也照原样（set_gate、put_wiring_file 要原样交回）。顺序是：
- 看到哪一步了：
get_status。 - 接入：
get_wiring看平台上的测试接入文件，put_wiring_file改；或者start_connect_assist让平台的 AI 补全，get_connect_assist看进度。本地测试机的项目，测试机只读你们仓库里的测试接入文件：直接改仓库里的.reviewctl/，改好用try_run预跑；平台上存的只是一份副本，不用put_wiring_file存回平台。这些文件的写法见 review.yaml 参考，数据检查读的数据查询（state_queries.yaml）见其中的数据查询。 - 写测试：
get_prompt取提示词，submit_answer交，upload_file补测试文件。项目有以前批准过的测试计划时，提示词里带着它（get_plan看全文；做计划的那几步已经去掉，见测试计划的工具）。有人经 API（POST /v1/projects/<编号>/dev-tasks）派给它的活，用get_tasks取、finish_task交回；网页上不再派活。 - 审核：
review_drafts让平台的 AI 审，get_test对照代码看规则，confirm_test确认（要有「确认测试」的权限）。规则按住、只能人确认的草稿（例如平台 AI 诊断的改法去掉或放宽了一项检查），AI 不会读：review_drafts和get_status列出它的理由，说要人在网页上确认，不算在「平台的 AI 正在审」的草稿里，也不算在review_drafts第一行「请平台的 AI 再审一遍草稿（N 个）」的 N 里。它返回的started只在有草稿送给平台的 AI 审时为 true；auto_approve说项目的 AI 审批开没开。 - 预跑：
try_run，没通过用get_setup看问题。预跑还在跑时，get_setup和try_run的第一行和下一步都说它在哪里跑（测试机或云端沙盒），并说已经跑了多久，以及这个项目最近几次在同一处的预跑一般要多久；沙盒里还没有跑过的，按平台的估算（沙盒开机，再把每个测试跑一次）。 - 正式测试：
run_tests发起，wait_job等它跑完。 - 看结果：
get_report、get_diagnosis、get_fixes。不写run_id时，三个工具说的都是最近一次正式测试：一起发起的几次运行（功能测试和各个测试集）一起说。预跑的run_id只有get_report能读：预跑没有 AI 诊断，也没有修改意见，get_diagnosis、get_fixes会说这是一次预跑，它的问题和修改意见在get_setup里。还在跑或还在评审的正式测试，会说用wait_job等哪个任务。诊断的修改意见说的是怎么在平台上验证改法，不会叫你在自己的机器上运行被测 Agent：开发机 AI 用try_run预跑、再用run_tests发起正式测试；人在网页上先预跑、再发起正式测试。诊断的模型写成别的验证办法时，平台会退回给它重写一次。 - 对照代码核实后改，回到第 5 步再跑。
| 工具 | 做什么 | 要的权限 | 对应的命令 |
|---|---|---|---|
get_status | 草稿、还缺的测试文件、测试机在不在线、这个连接能做什么、下一步，以及平台自己域名上这份文档的链接（MCP 服务的说明里也有） | reviewctl dev status | |
get_prompt | 平台给这个仓库的提示词：写哪些测试、文件和 todo，按什么格式 | reviewctl dev prompt | |
submit_answer | 交写好的 JSON；没通过列出问题，连续 5 次没通过连接暂停 | 写测试草稿和上传文件 | reviewctl dev submit <文件> |
upload_file | 上传草稿还缺的测试文件（只有 reviewctl dev mcp 有） | 写测试草稿和上传文件 | reviewctl dev upload <路径> |
get_tasks、finish_task | 经 API 派给它的活；做完或做不了交回 | reviewctl dev tasks、reviewctl dev done <编号> | |
get_wiring | 平台上的测试接入文件：内容、哈希、最后是谁存的 | reviewctl dev wiring | |
put_wiring_file | 存一个 .reviewctl/ 下的文件，按网页保存的规则核对 | 改测试接入文件 | reviewctl dev push <文件> |
start_connect_assist、get_connect_assist | 让平台的 AI 补全接入并检查；看它做到哪了 | 让平台的 AI 补全接入（只发起时要） | reviewctl dev assist、reviewctl dev assist --status |
list_tests | 测试和草稿：id、情况、AI 审批结果、上次的结果，以及通过标准。同时有正常和攻击情况的场景只列一次（groups 里是功能和安全），个数和 get_status 的一样 | reviewctl dev tests | |
get_test | 一个测试的完整规则（YAML） | reviewctl dev test <id> | |
review_drafts | 让平台的 AI 再审草稿，说哪些在等人、在哪确认 | 写测试草稿和上传文件 | reviewctl dev review |
confirm_test | 确认一个草稿 | 确认测试 | reviewctl dev confirm <id> |
try_run | 预跑一次（只跑 1 次，不出报告）并等结果；连续 5 次没通过连接暂停 | 预跑 | reviewctl dev retry |
get_setup | 最近一次预跑：测试能不能进到 Agent、测试机跑的是哪版代码，没通过时的问题和修改意见 | reviewctl dev setup | |
run_tests | 发起正式测试（和「开始测试」一样，先预跑，通过后开始；刚通过的预跑跑的就是同样的代码和测试时沿用它）。场景和每个测试集各是一个任务，一起排队：返回每个任务的编号、预计花多少和最多花多少。conditions 只选故障情况（没有正常情况，也没有攻击）时，要有点名它们的通过标准：没有人设过通过标准时，默认标准只判每个测试的正常情况和攻击，这样的测试会被拒，回复里说为什么，以及不写 conditions 就跑全部情况 | 发起正式测试 | reviewctl dev run |
get_job、wait_job | 任务现在怎样；等它跑完（它跑完就返回，一起发起的还没跑完的会列出任务编号）。不写 job_id 时是这个连接最近发起的正式测试；还没有发起过时会说明，并说出这个连接自己的预跑，它的结果在 get_setup 里（要等它就带上它的 job_id）；在那次正式测试之后发起、还在跑的预跑，会在旁边说一句；和它一起发起的某部分到了费用上限停下时，也会点名那一部分（开始前就停下的说它没有开始，不说跑完了）。每次执行的状态用话说（「通过」「判断不了」「没执行」），结构化内容里仍是代码 | reviewctl dev job、reviewctl dev job --wait | |
cancel_job | 取消这个连接发起的任务 | reviewctl dev cancel <编号> | |
list_runs | 最近的正式测试：结论、问题数、报告链接 | reviewctl dev runs | |
get_report | 一次正式测试的结论：第一屏的话、跑的是哪版代码、模型有没有被平台换掉、没通过和判断不了的及原因（测试集逐题说）。第一行按测试数，一个测试在几种情况下都没测成也只算一个，后面写共几种情况（「9 个测试（共 15 种情况）没测成」）；判断不了的原因用平台的话说，不带内部代码 | reviewctl dev report | |
get_diagnosis | 平台 AI 的诊断：原因在 Agent、测试接入还是测试本身 | reviewctl dev diagnosis | |
get_fixes | 一次运行的修复说明（和实验行上「导出修复说明」导出的一样） | reviewctl dev fixes | |
set_gate | 存项目的通过标准 | 改通过标准 | reviewctl dev gate <文件> |
测试计划的工具
测试计划这一步已经去掉了（见测试计划）：平台不再做计划，网页上也没有批准计划的页面。这几个工具只有 MCP 里有，没有对应的 reviewctl dev 命令。
| 工具 | 做什么 | 要的权限 |
|---|---|---|
get_plan | 项目以前批准过的测试计划：第几版、全文，以及下一步（用 get_prompt 取带着这份计划的提示词）。没有批准过的计划时，说明这一步已经去掉、写测试改怎么做 | |
start_plan、answer_plan、next_plan_round、write_plan、edit_plan | 已去掉：什么都不开始、不改，只返回错误 plan_removed，说明这一步已经去掉，写测试改用 get_prompt 取提示词、submit_answer 交 |
实验、日志和发布门槛的工具
编码 AI 也能读项目的实验、线上日志（追踪）和发布门槛，对照代码找原因；还能往数据集里起草行、起草评分器。这些只在这个连接自己的项目上：同一个组织别的项目的实验、追踪、数据集都看不到。读不要权限；起草要「写测试草稿和上传文件」，起草的东西都要人在网页上核对；不能改发布门槛，也不能跑实验、打分（不花钱）。这几个工具只有 MCP 里有。
| 工具 | 做什么 | 要的权限 |
|---|---|---|
list_experiments | 项目的实验（最新的在前）：来源、状态、发布门槛过没过、每个评分器的平均分、成本 | |
get_experiment | 一个实验和它的发布门槛：每条规则过没过、实际是多少、让它没过的行 | |
get_experiment_rows | 一个实验的行：输入、期望、输出、每个评分器的分数和理由；和基线比时带上变化。可以用筛选语言挑出没过的行，例如 score.builtin:task_done < 0.5 | |
list_traces | 项目的追踪（最新的在前）：输入输出的开头、状态、在线评分、模型；筛选例如 status = error、issue = <问题编号> | |
get_trace | 一条追踪的所有跨度（按调用顺序和层级）：工具调用、模型调用的输入输出、出错的地方、在线评分和理由 | |
list_datasets | 项目的数据集：自建的，和代表项目测试（场景、测试集）的 | |
add_rows | 往自建的数据集里加行，标成「还没人看过」，由人核对后留下或删掉 | 写测试草稿和上传文件 |
create_scorer_draft | 新建一个项目评分器（标为开发机 AI 起草）；只建新的，建好不会自动用上，由人在「评分器」里试跑后再加 | 写测试草稿和上传文件 |
get_gate | 项目的发布门槛（每条规则）和最近一个跑完的实验在这些规则上的结果；只能读，改要人在网页「设置 → 发布门槛」里改 |
接本地测试机的项目，try_run 和 run_tests 都要测试机在线；不在线时平台不发起，并说在这台机器上运行 reviewctl runner start，或者用 --runner。
每天的费用上限
勾了「发起正式测试」的连接，每天（按 UTC）最多花「每天最多花 $」填的钱：在本地测试机上跑的项目默认 $5，最多 $1000。
不限
建连接时、或者在连接那一行点「改权限」时，在「每天最多花 $」旁边勾「不限」，这个连接就没有自己的每日上限。连 GitHub 仓库或自带镜像的项目（在云端沙盒里跑）新建的连接默认就是不限。以前建的连接保持原来的上限。
- 这时只受组织自己的限制，和在网页上发起的测试一样：本期额度和余额、花费上限、先充值的余额，以及组织策略。
run_tests按下面同一个算法，拿这次的花费和组织剩下的额度比：在沙盒里，沙盒按组织的单次运行最长时间算，模型按预计算。放不下就不发起，并说要多少、组织还剩多少，以及要组织的所有者在账单页充值或调高花费上限。- 跑的时候，组织的额度用完，平台的模型就停下，和网页上发起的一样；没测成的不收费。组织完全没有花费上限的，只按每次运行自己的上限算。
get_status写「正式测试：这个连接不限每天的花费」，run_tests的返回在今天已用多少旁边也这样说，连接那一行写「今天已用约 $X / 不限」。- 审计日志和连接的其他权限一起记下这次改动。测试跑的时候有人设了上限、测试停在那里的，页面会说这次测试开始时不限每天的花费。
这一节下面说的是有每日上限的连接。
- 每次
run_tests先按开始测试页的同一个算法算这次花多少，发起时先占这个连接今天的额度，放不下就不发起，并说预计、上限、今天已经用了多少、还剩多少，以及可以怎么办（少测一些、明天再测，或者请人调高每日上限）。 - 接本地测试机的项目没有沙盒费用，算的是平台的评审模型，和平台替 Agent 应答时 Agent 的模型。发起时按预计占额度：「预计约 $X（一般 $低–$高，按这个项目最近几次测试的花费算）」，和开始测试页说的一样，含预跑。跑的时候，平台的模型花到这个连接今天剩下的额度就停下，和到了每次运行的上限一样：评审模型不再评，后面的回复判断不了（没测成）；替 Agent 应答的平台模型不再应答，这次运行在当时那次执行结束后停下，出部分报告。所以每日上限照样是实际花费的上限。回复里照样写「最多约 $…」：每次运行的评审模型和 Agent 的模型上限，没有为了放进每日上限调低。
- 安全测试在这个项目里还没跑过时，Agent 的花费按这个项目的功能测试算，评审模型的花费按组织最近的安全测试算（安全测试一道题的评审比功能测试贵）。
- 还没有可参考的花费记录时（这个项目和组织里还没有在测试机上跑完过的测试），估不出预计，发起时先占住今天剩下的额度，跑的时候同样花到这里就停下。
- Agent 的模型什么时候算：测试机上的 reviewctl 只在那台机器没有自己的
OPENAI_API_KEY（也没设OPENAI_BASE_URL）时替 Agent 转给平台的模型，并告诉平台。项目的测试机都不转时，上限里不算 Agent 的模型；不调模型的 Agent（比如脚本），以往的运行里 Agent 的模型没花钱，预计里也就不算。 - 在云端沙盒里跑的项目，评审模型和替 Agent 应答的平台模型也按预计占、花到今天剩下的额度就停下，和测试机上一样。只有沙盒按秒计费、跑的时候停不在每日上限上，所以每个沙盒（每次运行一个，要预跑时再加一个）另按组织的单次运行最长时间先占住。例如两个测试各测 1 遍、预计约 $0.08，再加最多两个标准沙盒、各按 2 小时算，默认的每天 $5 放得下（以前按「最多约 $…」占，要 $13 多，一律被拒）。跑的时候，模型花到「每天的上限 − 别的测试占的 − 这些沙盒按最长时间算的钱」就停下，所以沙盒跑满最长时间也不会超过每日上限。放不下时，回复里写要先占多少，以及每日上限至少要调到多少。
- 网页上连接那一行列出它发起的每次正式测试：测试机上写预计和最多多少；沙盒里另写发起时先占了多少（「预计约 $0.08，先占 $0.43（最多约 $13.35）」）。跑的时候到了每日上限停下的正式测试，结束时单独记一行，写这样没测成几次（只有评审停下的，写几次没判），上限是跑的时候被人调低的也写出来。那一行里被拒的原因按看网页的人的语言显示，不管连接用哪种语言。
- 今天已用的，按这个连接今天发起的正式测试算：还在跑、可能还会花钱的，按发起时占的和已经计费的取大的（在沙盒里，每个沙盒按最长时间算，直到它关掉、按实际计费）；跑完的按实际计费（连同它们的预跑）。
get_status也写今天已用多少和它算了什么。有正式测试还在跑时，get_status（running_today）和连接那一行另写其中多少是这次测试、它发起时先占的和到现在已计费的：每日上限没动过（或者调高了）时，还在跑的测试不按先占的停，按它已计费的（每个沙盒按最长运行时间算）和今天别的正式测试加起来碰到上限才停，所以测试还在跑时，今天已用的可能比上限高；它开始以后有人把每日上限设得或调得比今天已用的还低，它下一次调用平台模型时就停下（见下一条），running_today这时带stopping，两处都写它正在停下。list_experiments给的是每个实验的全部花费，含平台 AI 对它的运行的诊断（diagnosis_usd），诊断不算进这个上限。 - 跑的时候有人在「改权限」里设了每日上限或调低了它，平台的模型下一次调用就按新的上限核：评审模型和替 Agent 应答的平台模型都一样，原来不限的连接也一样（2026 年 11 月 5 日以前，原来不限的要晚最多 30 秒）。新的上限比这次测试先占的加上今天别的正式测试还低时（2026 年 11 月 5 日起），不管它已经计费多少，下一次 Agent 的模型调用或评审调用就被拒，测试在当时那次执行结束后停下，记为到了这个连接的每日上限（连接那一行的「到了每日上限」一行、报告和各个工具都写明开始时是多少，或者开始时不限）；以前它要跑到已计费的（沙盒按最长运行时间算）碰到新的上限才停。新的上限不比这些低时（在沙盒里，先减去已经计费的和各个沙盒按最长运行时间算的钱），测试接着跑到余地用完，再在当时那次执行结束后停下；超出上限的最多是正在进行的那几次调用。只调高上限的，测试照常跑。和它一起发起、还没开始的部分（例如排在场景后面的测试集），开沙盒之前也这样核：已经没有余地，就不开沙盒，这一部分就此停下，记为到了上限，
get_job、wait_job、get_report都这样说。 - 单独的预跑（
try_run）和「让平台的 AI 补全接入」照平时计费，不算进这个上限：预跑按沙盒时长和模型用量，补全接入的模型调用算进助手的每日用量。 - 到了每日上限被拒时，回复里带着调高它的设置页链接（「设置 → 开发机 AI」）。正式测试跑到一半用完了每日上限时，
wait_job、get_report、get_fixes、get_status也带这个链接；跑的时候有人调低了上限，会写明开始时是多少。get_report里没测成的按网页第一屏的数法分开数测试和攻击，被上限停下的那几次只算到上限上，不再同时算成「平台的模型没应答」：这次运行的「平台的模型有没有正常应答」检查和一批的总结都说到了费用上限（平台的刹车），不引那时 Agent 交回的内容。 - 是哪个上限停下了一次正式测试（这个连接的每日上限、组织的余额，还是这次运行自己的），在它结束时按当时的上限定下来，记在任务上；之后照着提示调高（或调低）每日上限，网页上的本轮报告、报告页、进度页和
get_report、wait_job、get_fixes、get_status说的都不变。以前结束的，按连接那一行的记录或结束时的上限算。被上限停下、没判的执行也不算进「平台看不到 Agent 调用工具」的检查，这样的运行第一句说的是上限，不会叫你去修接入。 - 组织本身的额度、余额和组织策略里的上限照样管着它。因为组织的额度和余额、花费上限或预付余额用完了而被拒时，回复会说要组织的所有者来处理，并附账单页的链接（
/org?tab=billing）。