AI 代码审查：先定设计，再用证据验收

AI 写代码越来越快，人工审查却容易卡在两头：逐行看，时间吃不消；只看测试通过，又担心代码和测试一起理解错了需求。这篇文章给出的办法，是把设计决策提前，把自动验证放到人工审查之前，再按变更风险分配人的注意力。

它串起了 Hacker News 的工程师讨论、Claude Code 团队的审查流程，以及一段 Tokely 接入介绍。最值得带走的是前两部分：如何让人仍然掌握设计和上线责任，同时减少重复检查。文中的效果数字来自团队自报，不能直接当成所有团队的收益预期。

人可以不盯每一行，但必须掌握设计

2026 年 10 月 19 日，Hacker News 用户 rzk 发帖询问：如何面对自己并不理解、却正在交付的 AI 代码？截至 10 月 23 日，帖子获得 614 分、748 条评论。问题背后是一个现实矛盾：Agent 承担大部分实现后，人工逐行理解的速度，很难追上代码产出。

在包含 183 条回复的最大子讨论里，bitwizeshift 给出的做法是：自己负责设计，让 LLM 实现。即使不知道每个单元的全部细节，也要清楚它们分别负责什么、怎样协作。

放到前端和全栈开发里，就是先确定组件边界、接口契约、状态归属、异常处理，再让 Agent 填充实现。审查因此有了依据：这段代码有没有越过职责边界，有没有违反约定，有没有遗漏失败路径。

设计越含糊，审查就越容易退化成凭感觉判断代码是否合理。

执行验证同样重要。讨论中的工程师强调大量测试，但也指出一个盲点：如果实现和测试都由 AI 编写，两者可能共享同一个错误假设。测试通过，只证明代码符合这些测试，不能证明测试覆盖了真实需求。

因此，减少逐行检查不等于放弃理解。原文保留了一条责任底线：公司里至少要有人能解释上线代码。不同层次也可以采用不同力度，有人让 AI 大量生成 UI，SQL schema 则继续手写。这是个人取舍，并不是 UI 天然低风险的证明。

Claude Code 把人工审查放在七层防线中间

原文称，Claude 编写了 Claude Code 自身约 90% 的代码。Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 于 2026 年 10 月 15 日发布的团队流程，把审查拆成七层：

1. 提交前，Claude 运行测试、构建和 linter，展示输出，再由一个使用全新上下文的 Agent 审查 diff。
2. 每个 PR 接受自动 AI 审查，结合整个仓库和 PR 声明的意图检查；发现由其他 Agent 复核，并标成 Important、Nit 或 Pre-existing。
3. 独立安全审查拥有阻断权，bug 审查或安全审查仍有未关闭发现时，PR 不能合并。
4. lint、类型检查、各平台测试和构建作为阻断检查执行。
5. 人工批准数量由变更风险决定。
6. 代码进入合并队列，通过 feature flags 渐进发布，先向 Anthropic 员工开放。
7. 上线后依靠快速检测、无需重新部署即可关闭的开关，以及每周轮换的值班机制处理问题。

这里的关键是验证分工。构建和类型检查负责确定性约束，Agent 寻找逻辑问题，人处理风险判断，渐进发布与回滚控制漏检后的影响。

「全新上下文」也有具体目的：让另一个 Agent 从需求和 diff 重新检查，减少它沿用实现者既有思路的机会。但它仍可能共享模型层面的盲点，不能视为独立正确性的保证。

人工批准遵循三条规则：风险由变更决定；Agent 批准不算人的批准；每次批准只覆盖一个具体 commit。

低风险变更在自动审查和安全检查通过后，可以不需要人工批准，包括文档、文案、内部功能，以及被 feature flag 隔离的增量变更。中风险需要 1 人批准，覆盖普通产品改动，以及缓存逻辑、自动更新器、system prompts 等敏感区域。高风险需要 2 人批准，覆盖最高风险代码和少量敏感仓库路径。

效果有数据，产品接入要分开理解

团队报告，一轮审查和修复后通过的 PR 占比从 65% 提升到 78%；需要 5 轮及以上的占比从 8.9% 降到 1.5%；平均审查轮数从 2.08 降到 1.32。6 月至 9 月，合并 PR 总量超过翻倍，需要回滚的 PR 占比下降超过 40%。

他们还把曾导致事故或回滚的历史 PR 做成评测集，每天运行。审查器的 prompts、工具或模型更新，都要经过这套事故库评分。它回答的问题很实际：换了审查器以后，过去踩过的坑还能不能被识别？

原文另称，Code Review for Claude Code 于 2026 年 10 月 15 日面向 Claude Team 和 Enterprise 组织正式开放。管理员可按仓库选择 Quick、Standard 或 Deep，默认 Standard；多数审查耗时从研究预览期约 20 分钟降到 6 至 10 分钟。

文章后半段转向 Tokely。下面这条原始命令解决的是：让本地 Claude Code 通过兼容 Anthropic 的网关启动。

ANTHROPIC_BASE_URL=https://api.tokely.me ANTHROPIC_AUTH_TOKEN='<YOUR_TOKELY_API_KEY>' ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5 ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5 ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-5-5 claude

要看清这一行里的 ANTHROPIC_BASE_URL：请求被指向 Tokely，经由其兼容的 /v1/messages 接口发送。按原文说明，本地 /code-review 和 /security-review 消耗现有 Tokely 余额，按 token 计费。

同一 API key 还可通过兼容 OpenAI 的 Chat Completions 接口访问 GPT-6.1 Sol、Gemini 4 Argon 等模型，用另一家模型复审 diff。但 Tokely 是 API 网关，不运行 Anthropic 托管的 Code Review GitHub App。这几种使用方式不能混为一谈。

我的判断

我认同把设计提前、把确定性检查自动化、把人工注意力集中在高风险改动上。相比要求人完整重读所有生成代码，这套流程更容易形成明确的责任边界；相比只盯 CI 绿灯，它也保留了需求理解和上线后的控制手段。

但收益数字有边界。原文没有交代样本量、变更规模是否一致，也没有给出对照组或人工审查工时。审查轮数下降，不能直接推导出总成本下降；回滚占比下降，也不能替代生产事故率。它提供的是团队自报的前后变化，尚不足以证明每一层措施各自贡献了多少。

低风险零人工批准尤其依赖前提：风险分类可靠，自动检查有效，开关确实能隔离影响，事故发生后有人接手。普通团队不宜直接照搬分类结果。例如 UI 中的权限判断和支付确认，就不能只凭文件位置判为低风险。

先学习它怎样划分责任，再决定能省掉多少人工审查。

跨模型复审可以尝试，但作者也承认它不是解决共同盲点的已验证方案。独立编写验收条件、补充失败场景、由熟悉业务的人核对关键行为，同样重要。文章原发于 Tokely，网关接入带有产品介绍目的；审查方法是否成立，不应依赖是否使用这家服务。

能拿来做什么

• 让 Agent 写功能前，先写清职责、输入输出和失败行为。前端重点说明状态归属与交互边界，Node 接口重点说明权限、错误返回和数据一致性，再据此审查实现。
• 把 Agent 能执行的检查写进简短的 CLAUDE.md，用 hooks 自动运行 formatter 和 linter；开 PR 前执行 /code-review、/security-review，或安排全新上下文复审，并保留执行输出。
• 用 REVIEW.md 沉淀重复反馈，在 PR 模板加入 Testing、Risk、How to revert。结合 CODEOWNERS 和分支保护，让 auth、billing、CI workflows、release workflows、installers 必须经过人工批准。
• 同时记录人工审查时间、回滚率和生产事故率。限制自动复审轮数，前几轮之后只检查新修改的 diff；若回滚率上升，就收紧风险分级，或把漏掉的问题加入评测集。