我的 AI 逃离了它的容器并做了所有事——除了审查自己的代码
I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have that, I’ll provide the translation while preserving the source link, formatting, markdown, and any code blocks exactly as requested.
之前：完整的开发周期
在 Part 4 of this series 中，我的 AI 助手实现了一件了不起的事。它在安全的 Docker 容器内运行，现在能够执行完整的开发周期：
Code → Test → Build → Deploy → Commit我把它称为终章。三部曲已经完成。AI 能够编写代码、运行测试、构建产物、部署到容器，并提交更改——所有这些都在安全地隐藏机密的前提下完成。
我错了。还有些什么缺失。
缺失的环节
再看看那个循环。现在想想真实的开发团队是如何运作的。
Code → Test → Build → Deploy → Commit → PR → …审查在哪里？
在任何专业团队中，代码并不是从编写直接流向部署。有人会阅读它。有人会检查是否有漏洞、安全问题、架构缺陷。有人会问，“你考虑过这种边缘情况吗？”
我的 AI 可以做所有事情——除非检查它自己的工作。
官方插件
Claude Code 有一个官方的 /code‑review 插件。当我发现它时，我被它的设计所震撼：
| 功能 | 描述 |
|---|---|
| 并行代理 | 多个 AI 代理从不同角度同时分析代码——错误扫描、CLAUDE.md 合规性检查 |
| 置信度评分 | 每个发现都有一个评分，用于过滤噪声 |
| 验证步骤 | 另一个独立的代理重新检查发现，以消除误报 |
这是一项严肃的工程：不是“让 AI 审查代码”，而是一个结构化的、多阶段流水线，旨在产生高信号的结果。
我立刻安装了它……结果却根本无法工作。
为什么它无法访问
官方插件是为标准的 GitHub 工作流构建的。它的前提是：
ghCLI – 用于从 GitHub 获取 PR 细节- GitHub PR – 审查目标是一个拉取请求
- 单一仓库 – 它在一个项目内部运行
我的 AI 沙盒环境中没有这些条件：
- 没有
ghCLI（容器中没有 GitHub 认证） - 还没有 PR（我想在 推送之前 进行审查，而不是之后）
- 一个工作区中有多个相互独立的仓库（API、Web、iOS —— 各自拥有独立的 Git 历史）
插件无法访问我的代码。并不是因为它设计得不好——它在自己的职责范围内表现出色。只是它是为开发周期的另一个时点构建的：在推送之后。我需要的是 推送之前 的工具。
从设计中学习
我无法直接使用该插件，但我可以从中学习。
插件文档 显示，Claude Code 的自定义命令其实就是 Markdown 文件——结构化指令会变成斜杠命令。官方的 /code‑review 展示了一个设计良好的审查流水线的样子：并行分析、评分、验证。
于是我向 AI 询问：
分析 code‑review 插件并创建一个可以本地运行的自定义命令。允许选择要审查的项目。与用户确认目标分支。运行同样的审查，但不依赖 GitHub 访问。
AI 阅读了官方插件，理解了其结构，并生成了本地版本。没有 gh 依赖，支持多项目，兼容 Git 与非 Git 模式。它成功了。
从一到九
一旦本地审查命令运行起来，接下来的想法显而易见。
如果我可以拥有一个通用代码审查器，为什么不拥有安全审查器？性能审查器？架构审查器？
每种审查类型需要不同的专业知识：
| 命令 | 目的 |
|---|---|
ais-local-review | 通用代码审查（错误，CLAUDE.md） |
ais-local-security-review | 安全漏洞 |
ais-local-performance-review | 性能瓶颈 |
ais-local-architecture-review | 结构性问题 |
ais-local-test-review | 测试质量评估 |
ais-local-doc-review | 文档准确性 |
ais-local-prompt-review | AI 提示/命令质量 |
ais-refactor | 具体的重构建议 |
ais-test-gen | 自动化测试生成 |
所有九个命令共享同一套受官方插件启发的流水线架构：
Parallel Analysis → Scoring → Verification → Report
(4‑5 Sonnet agents) (Haiku) (Sonnet)每个专用命令都会发送具有不同审查视角的并行代理。评分代理评估置信度。验证代理消除误报。只有高置信度、已验证的发现才会进入最终报告。
管道运行示例
以下是运行 /ais-local-review 时的流程：
- 选择项目和分支（如果没有 Git，则选择文件）。
- 四个 Sonnet 代理并行启动：
- 代理 #1： CLAUDE.md 合规性 — 代码是否遵循项目约定？
- 代理 #2： Bug 扫描 — 明显的逻辑错误、边界情况。
- 代理 #3： 历史分析 — 是否在重新引入之前已修复的 bug？
- 代理 #4： 注释检查 — 代码是否与自己的文档相匹配？
- Haiku 代理为每个发现打分（0‑100）。
- Sonnet 验证代理重新检查所有得分 75 以上的项。
- 仅确认的高置信度问题会出现在报告中。
最终得到的是一个聚焦的报告：不是一堆挑剔的细节，而是一份真正重要事项的简短清单。
两次审查，两种时刻
官方插件和我的本地命令并不竞争；它们在开发周期的不同阶段发挥作用。
Code → Review → Test → Build → Deploy → Commit → PR → …- 本地审查 在创建 PR 之前进行，能够及早捕获问题。
- 基于 GitHub 的审查 在打开 PR 之后运行，提供第二层安全网。
两者结合形成一个持续的、多阶段质量关卡，从第一行代码到生产部署，都能保持代码库的健康。
开发流程
→ Build → Deploy → Commit → PR → Review
↑ ↑
ais-* commands Official /code-review
Before you push After you push
Quality gate Team review
Local, private GitHub, collaborative官方的 /code-review 用于代码已经准备好让团队审阅的情况。
它会在 PR 上发表评论，提出修改建议，并与 GitHub 的协作功能集成。
你的 ais-* 命令则用于更早的阶段——在你仍在开发、尚未提交，甚至在完成测试之前。
它们充当私有的质量关卡，能够在问题最便宜、最容易修复的时候将其捕获。
Source:
完成的循环
还记得第 4 部分的开发循环吗？
Code → Test → Build → Deploy → Commit现在它看起来是这样：
Code → Review → Test → Build → Deploy → Commit
↑
缺失的环节AI 可以编写代码、从多个角度审查自己的工作、运行测试、构建、部署并提交。之前缺失的质量关卡现在已经就位。
我学到的
这个项目的起点是官方插件无法访问我的代码。这个限制把我带向了意想不到的方向。
官方插件的设计——并行代理、置信度评分、误报消除——成为了蓝图。开源的最佳体现：你可以阅读其工作原理，理解其原则，并将其适配到自己的环境中。
我得到的不仅是一个代码审查器。我拥有了九个专用审查工具、一个重构助手以及一个自动化测试生成器。这一切都源于官方插件向我展示了一个精心设计的审查流水线应该是什么样子，而我的 AI 沙盒则提供了一个可以在本地构建并运行它的场所。
迄今为止的系列
最初只是“我的 AI 能看到我的 API 密钥”，现在已经发展成更大的项目：
- Secrets – 使用 Docker 卷挂载让 AI 隐藏敏感文件
- Toolbox – AI 通过 SandboxMCP 自动发现并使用工具
- Host Access – AI 逃离容器并获得受控的主机操作系统访问权限
- Review（本文） – AI 自己审查代码，完成开发周期
三部曲变成了四部曲。我不再保证它已经完整。
AI Sandbox 与 DockMCP 是开源的：GitHub repository
如果你为自己的 AI 工作流构建了自定义审查命令，欢迎在评论中分享。