先给结论：我判断一个变更能否合入，看的是意图是否明确、关键不变量（Invariant）是否成立、验证覆盖到哪里，以及剩余风险由谁接受。代码评审（Code Review）应把这些判断变成能复核的记录。AI 智能体（AI Agent）可以接手实现、补测和初筛，但生成代码、运行测试、批准合入与承担上线风险，仍然是不同的权限和责任。

对在线分析处理（Online Analytical Processing，OLAP）数据库内核，我会保留 SQL 语义、对象生命周期、恢复边界和跨版本兼容的人工判断。智能体驱动研发（Agentic Engineering）的价值，需要从需求规格（Specification）一直算到部署：局部编码更快，如果换来更多排队、误报和返工，并不自动降低交付成本。

产品与价格沿用 2026-10-24 核验记录，未重新实测；资料未记载的金额留空。商业判断与流程建议属于推演，个人经历用【模板】补齐。

一、评审原则：先确定凭什么阻塞，再讨论速度

代码健康度需要落实为契约和证据

Google 的 The Standard of Code Review 要求：变更确定改善整体代码健康度时，即使不完美也应批准；技术事实和数据优先于个人偏好，风格争议遵循既有规范，可有可无的建议用 Nit: 标注。

我会把这个标准拆成两个问题：变更有没有违反必须维持的契约，剩余问题能不能独立偿还。命名偏好可以延期，合法 SQL 返回错误结果不能用“结构更整洁”抵消。持久格式不兼容、无界资源增长或有条件可复现的严重性能退化，也可能使合入条件不成立。

一条阻塞评论至少应说明触发条件、违反的约束、后果和验证方法。只写“这里不安全”会把证明负担全部推给作者；只写“我以前一直这样做”则把经验变成权威。作者应能用调用方保证、反例失败或测量数据反驳，reviewer 也应能据此撤回意见。

Apache Voting 规定，代码修改上的 −1 否决必须附技术理由，无理由的否决无效。LLVM Code Review Policy 区分提交前和提交后评审，并将认可限定在 reviewer 评审的部分。PostgreSQL Reviewing a Patch 则覆盖补丁可应用性、需求、性能、规范与文档。

社区流程不能互相套用，StarRocks 以 CONTRIBUTING 为入口；该移动分支链接不充当固定提交的源码证据。

研究说明评审的产出，但不给单个补丁背书

Bacchelli 与 Bird 的 ICSE 2013 论文 Expectations, Outcomes, and Challenges of Modern Code Review 研究了 Microsoft 的现代代码评审（Modern Code Review）。找缺陷是开发者的重要动机，但评论还产生知识传递、团队意识和替代方案；理解变更本身也是评审需求。

Sadowski 等人的 Modern Code Review: A Case Study at Google 报告了 Google 环境中变更通常很小、多数只有一名 reviewer、中位响应时延在小时级等观察，并讨论教育和维护规范的价值。这是特定组织的研究，不能直接推成所有团队的目标值。

Google Small CLs 将约 100 行作为合理规模的经验参考，认为 1000 行通常过大；Speed of Code Reviews 要求最迟一个工作日内响应。这些是规范和经验指引，不是正确性的统计阈值。

拆分应沿可验证的契约推进：先建立接口和兼容读取，再接入新路径，最后切换默认行为与清理。每一步都要说明能否编译、测试和部署。新格式已经写出而旧节点不能读取时，代码上的“小改动”仍然可能是部署上的不可逆变化。

先处理设计分歧，避免在行级评论里重做架构

Malte Ubl 的 Design Docs at Google 把设计文档的价值放在实现前暴露分歧、记录取舍与被否决方案，并指出小改动不必都写设计文档。

我会让持久格式、协议和公开 SQL 行为先经过设计讨论。代码评审随后核对实现是否满足那些假设。设计通过不等于实现正确；实现测试通过，也不等于最初的兼容与回退假设成立。

评审顺序可以是描述和测试、接口和状态边界、关键实现、局部细节。发现方向性问题就先同步讨论，结论写回 PR。机制是否有效，要结合首次响应、等待、返工原因和漏出缺陷看；评论数量与通过速度都不能单独代表质量。

二、内核清单：沿状态变化检查 P0–Nit

Google What to look for 将设计、功能和复杂度列为评审重点。因此这张表不是固定分类法：严重复杂度、已证实的性能退化或无法诊断的关键失败可以阻塞；妨碍理解所有权的命名问题，也不能仅因涉及命名就降为 Nit。

P0：证明正确性、存活与恢复边界

SQL 正确性先检查空输入、NULL 三值逻辑（Three-Valued Logic）、溢出、decimal 精度、时区，以及 nullable 与 const 列的特化分支。优化器规则要先证明等价，再判断成本；执行器（Executor）的快速路径也必须满足同一语义契约。

以谓词下推（Predicate Pushdown）为例，下面的 SQL 可以检验一种错误改写：把右侧条件移入扫描，同时删除连接后的过滤。

1SELECT l.k
2FROM l LEFT JOIN r ON l.k = r.k
3WHERE r.v = 1;

左外连接（Left Outer Join）在右侧不匹配时产生补 NULL 行，原查询的 WHERE 会过滤这些行；错误改写却可能保留它们。这个反例只否定该改写，不否定保留上层过滤或满足条件时转换连接类型的其他方案。重复行还要按多重集语义（Bag Semantics）检查，规则交互则另查触发条件与终止性。

并发审查要写出锁序、发布与读取的同步关系，以及回调跨越的生命周期。release 和 acquire 同时出现，不足以证明所需的先行发生关系（Happens-Before）；必须检查读取是否观察到对应的发布。合法的 relaxed 计数器不能仅凭关键字判错。

异步回调捕获 this 时，我会沿注册、运行、取消、完成、析构推演。取消请求不等于任务退出；若析构后仍解引用对象，就有释放后使用（Use-After-Free）风险。改成 shared_ptr 可能延长存活，也可能引入引用环或延迟资源释放；等待退出还要排除调度依赖导致的无法推进。

资源获取即初始化（Resource Acquisition Is Initialization，RAII）可以约束析构时的释放，但还要证明析构最终发生。提前返回、异常、取消和重复完成都要核对资源清理与内存记账是否对称；对象仍被异步任务持有时，局部作用域结束不能证明查询资源已经归还。

存储审查先找恢复后决定可见文件集合的元数据，再沿新文件生成、持久化、元数据发布和旧文件回收推进。合并压缩（Compaction）中的校验和（Checksum）只能帮助检测损坏，不能证明发布顺序正确；旧文件回收还受读者引用和快照约束。

每个崩溃切点都要回答恢复读哪一代文件、如何识别孤儿文件、何时允许回收。具体原子性和持久性取决于文件系统或对象存储接口，不能用一次 rename 概括。格式升级还要分别验证读兼容和写兼容，关开关不能自动撤销已落盘格式。

远程过程调用（Remote Procedure Call，RPC）超时只说明调用方没有及时收到确认，服务端可能已经提交。安全重试需要稳定操作标识、重复执行保护，以及结果与去重状态在恢复后的对应关系；内存去重不能自动覆盖重启，取消也不能自动撤销提交。

P1：性能收益必须带条件，验证必须带断言

性能审查关注热路径分配和拷贝、虚函数、分支，以及列式批处理是否退化成逐行处理。单指令多数据（Single Instruction, Multiple Data，SIMD）没有脱离负载的固定加速倍数；伪共享（False Sharing）通常也是性能问题，应与数据竞争的正确性风险区分。

向量化执行（Vectorized Execution）的微基准只能证明局部路径。查询级收益需要保留硬件、编译选项、数据规模和分布、NULL 比例、并发、缓存状态及重复运行条件，再结合性能剖析（Profiling）解释瓶颈。局部计算减少，在内存带宽或其他算子主导时未必改善总时延。

测试至少要覆盖与改动相关的边界、并发交错和故障注入（Fault Injection）；执行算子变化应有 SQL 级结果断言。ASan、TSan、UBSan 等检测器只观察实际执行路径，未报告问题不能替代所有权、同步关系或恢复协议的推导。

可观测性要能支持失败定位：错误上下文包含适用的 query_id、fragment/instance 标识和状态码，新执行路径有对应计数器。若失败后无法判断最终状态或安全重试，缺失诊断能力可能直接影响上线条件。

纯命名偏好、可选函数拆分、注释表达等用 Nit: 标注。注释优先解释为什么存在约束，待办项关联 issue。这里的非阻塞前提是问题不妨碍正确性与维护；不能为了让清单整齐，把关键错误处理降为风格问题。

评论可以压缩成“级别 → 触发条件 → 后果 → 验证或修改建议”。例如：“[P0] 取消后回调仍可能访问该状态，若最后引用先释放会发生悬空访问；请说明持有者与退出确认，并补可控制交错的测试。”这是一条通用示例，不对应真实 PR 或已确认事故。

三、Agent 进入研发链：自动执行与批准执行要分开

从规格到部署，每一步都有不同的证明义务

1spec → code → test → CI → review → merge → deploy
2规格    实现    测试    集成    评审      合入     部署
3人定契约；Agent 可提出方案、产出补丁、运行验证、整理证据
4人确认意图与风险；平台控制凭据、分支保护和发布权限

规格阶段应写清输入输出、非目标、兼容性、验收条件和禁止改变的行为。Agent 可以帮助寻找歧义，但若需求只写“让查询更快”，后续代码和测试都可能围绕错误目标自洽。规格负责人需要先确认优化允许改变什么、必须保留什么。

实现阶段适合让 Agent 形成可审查补丁，测试阶段则需要可区分正确与错误实现的断言。让同一个 Agent 同时写代码与测试并非天然无效，但两者可能共享同一错误假设；需要由规格、独立反例或另一条验证路径打破这种相关性。

持续集成（Continuous Integration，CI）负责执行确定的检查，包括编译、静态分析、回归和按风险选择的运行时检测。Agent 可以诊断失败并修订补丁，但不应通过删除失败断言、放宽阈值或跳过任务，把“检查通过”替换成“问题解决”。这些修改本身也应进入评审范围。

review 阶段确认意图、实现和证据一致；merge 阶段检查目标版本上的审批与保护条件；deploy 阶段确认运行环境、兼容方向、观测和退出条件。代码审批不能自动代替生产发布授权，尤其是回滚二进制无法恢复旧数据格式的变更。

我会明确三个角色，可以由同一个人兼任，但不能因此省掉相应判断。规格负责人（Spec Owner）确认问题与验收条件；意图审阅者（Reviewer of Intent）确认实现没有偏离需求，并审查关键机制；风险负责人（Owner of Risk）决定残余风险是否满足发布条件。

DORA 2025 将 AI 描述为组织已有强项和弱项的放大器。我据此采用的实践边界是：先检查测试、交付批量和平台权限是否可靠，再扩大 Agent 自主执行范围；这不是该报告对数据库内核自动合入的直接实验结论。

Agentic CI：先约束运行环境，再让 Agent 修复失败

GitHub 在 Copilot coding agent 发布文章 中描述：将 issue 分配给 Agent 后，它在 GitHub Actions 环境中工作，向草稿拉取请求（Pull Request，PR）推送提交并提供会话日志；分支保护仍有效，Agent PR 的持续集成与持续交付（CI/CD）工作流运行前需要人工批准。文章将良好测试基础上的低至中等复杂度任务列为适用方向。

Devin 的发布介绍 描述了带 shell、编辑器和浏览器的沙箱（Sandbox），以及独立完成任务后交由人审阅的工作方式。Claude Code GitHub Actions 则提供在自有 CI 中运行 Claude 的接入形式。

我理解的 Agentic CI，是 Agent 在受控环境中读取失败、提出修复、重新验证，而 CI 平台继续执行权限隔离与准入检查。沙箱应限制凭据、网络和写入范围；执行测试、修改工作流、读取生产密钥和发布服务，不能因为同属一个任务就共享权限。

人工批准工作流也应有具体对象：将运行哪个提交、使用哪些工作流、接触哪些凭据、允许哪些副作用。Agent 能改 .github/workflows 时，批准前需要看这些差异；批准旧版本不能覆盖后续新增的高权限操作。这是我的流程建议，不是对所有产品默认行为的描述。

瓶颈可能从写代码转向理解、验证和等待

Cursor 在 Graphite 加入公告 中明确提出：编码更快后，审查变更、安全合入和协作越来越成为瓶颈；写代码与协作之间的边界也越来越人为。这是公司的产品判断，不是所有团队瓶颈变化的独立测量。

如果 Agent 提高进入评审队列的速度，而人工理解能力和验证环境不变，等待就会增加。若补丁还更长、更分散，作者省下的时间可能转成 reviewer 的上下文成本。因此我会同时观察进入队列的变更类型、首次响应、返工、误报处理与上线缺陷，不能只算生成行数或 PR 数。

质量低下但外观完整的生成内容（Slop）会把成本推给下游：多余抽象、重复测试和长摘要都可能增加阅读量，却不增加证明力。控制方法是限制任务范围，要求关键分支解释，并把评论与真实后果对应；不能把“内容很详细”当作可靠性。

评审疲劳（Review Fatigue）来自有限注意力被低价值告警持续占用。AI reviewer 应帮助聚焦可验证问题，重复提醒和无条件建议应能被规则收敛。采用率、评论数量与缺陷发现率是不同指标，工具自称低误报不能代替目标仓库上的复核。

提示词注入（Prompt Injection）的风险在于，Agent 读取的 issue、代码注释、日志或网页可能包含诱导越权的指令。把这些内容当作任务数据，限制工具权限，并对凭据与发布保持独立授权，可以降低攻击影响；再加一个审查 Agent，不能自动消除共同信任错误。

四、商业模式：收费单位不能代替交付责任

以下比较公开产品形态与收费边界，不能据此排名准确率或客户总成本；表中最后一列是接入时需要核对的责任。

Cognition 的 Devin提供 shell、编辑器和浏览器沙箱，收购 Windsurf将 IDE 纳入布局。定价记录：Free $0、Pro $20/月、Max $200/月，Pro 含 Devin Cloud，额外用量按 API 价；Teams 为 $80/月加每个完整开发者席位 $40/月，最多 200 人，企业另报。订阅、席位和用量混合收费，并未证明按验收结果收费。

Cursor 的产品愿景、Bugbot、后台 Agent与 Graphite 公告把编辑器延伸至评审协作；SpaceX 公告加入算力叙事。价格矩阵和这些公告不提供本次比较所需的独立准确率或成本数据，不能推出收购提高了评审质量。

GitHub coding agent把 issue、Actions、草稿 PR 与日志连起来。Copilot code review默认留下 Comment，概览附批准评估，新提交会撤销批准。产出补丁、发表评论及计入必需审批，应分别配置。

Codex提供云端与 CLI，支持 ChatGPT 套餐登录；PR 评审会参考 AGENTS.md。套餐包含不等于无限额度。Claude Code及其 Actions 接入允许团队沿用自有 CI；执行权限与配置维护成本仍归团队。本次材料未记录两者可比较的价格和额度。

CodeRabbit年付 Essentials／Team／Advanced 为每用户每月 $24／$48／$72，覆盖 PR、CLI、IDE 与 Agent 循环；文档含摘要、逐行评论和路径规则。Greptile Pro 为 $1/credit、无席位费，不限开发者与 Agent，企业可自托管；未记录单次评审的 credit 消耗，无法换算单 PR 成本。Factory覆盖 plan、build、review、ship，强调模型独立，未记录公开价格及可比较的交付效果。

席位定价（Seat-Based Pricing）便于按人数预算；用量定价（Usage-Based Pricing）容纳一人驱动多个 Agent，也要求控制重跑与消费波动。一个人生成更多补丁以后，席位数与评审工作量可能脱钩，两类收费也可以混合。

结果定价（Outcome-Based Pricing）先要定义结果：按合并 PR 收费可能鼓励低价值拆分，按功能验收又要承担需求变化、长期缺陷和环境差异。上述资料没有证明厂商已采用这种模式。

评审入口和上下文可以归编辑器、仓库平台或独立 reviewer，最终认可权仍需组织授权。内核团队应在自己的任务上比较有效发现、误报处理、返工、等待与漏出风险，并保留分支、反例、测试和审批版本的跨工具证据。

五、面试：把原则压缩成能继续追问的回答

常规问题：标准、节奏与团队机制

Q1：你 review 时先看什么？CI 全绿能合吗？ 强答：先确认意图、版本和测试，再看接口、契约与关键实现。CI 只证明实际执行并断言的路径；正确性、生命周期、兼容性与严重资源风险仍需核对。 追问：只有可疑分支，没有反例？说明未证明的条件并构造输入；不可逆风险关键疑点未清时阻塞，可隔离实验则说明开关和退出条件。 差答：“测试绿就合”“正确性以外都不阻塞”。

Q2：大 PR 怎么拆？ 强答：按可验证契约拆成兼容接口、新路径、默认切换与清理，说明每步能否编译、测试和部署；不能独立成立的迁移步骤需要共同审查。 追问：为什么不按文件拆？模块边界不一定是语义边界；中间版本必须有明确行为和兼容条件。 差答：“统一限制行数”。

Q3：作者更资深，意见又冲突，怎么办？ 强答：把争议写成触发条件、后果和证据，区分阻塞与建议；异步讨论不能收敛时同步沟通，把结论写回 PR。 追问：对方说线上一直没事？没有事故不能否定可触发反例；也应检查自己是否遗漏调用方保证。 差答：“听负责人决定”或“坚持到对方接受”。

Q4：review 拖慢交付，怎么证明改进有效？ 强答：先分清排队、理解和返工成本，再看响应、等待、风险类型与漏出缺陷；小批量、分流和机械检查前移需要对应具体瓶颈。 追问：时延下降但事故增多，能归因吗？先核对变更量、类型和发布节奏，相关性不足以证明因果。 差答：“评论更多就更认真”“降低标准换速度”。

Q5：如何通过 review 带新人？ 强答：解释触发条件和机制，让新人也审阅资深成员的补丁；重复且稳定的问题沉淀成规则，复杂判断保留讨论。 追问：怎么知道学会了？让对方独立解释反例、所有权和验证边界，不能只看是否照着修改。 差答：“多给修改意见”。

Q6：事故复盘发现 review 漏了，怎么办？ 强答：核对原规格、补丁、测试与审阅范围，判断缺口能否用检测器、回归或流程捕获，并明确维护责任。 追问：如果 checklist 已有这一条？检查是否过于抽象、告警过多或任务范围失控，不能只再加一次提醒。 差答：“以后更仔细”。

内核问题：从一个局部条件推到系统结果

Q7：优化器新规则结果测试通过，为什么还可能不批准？ 强答：检查 NULL、外连接、重复行、相关子查询的适用条件，再查规则交互、终止性与计划成本；已有测试不能穷尽输入。 追问：给反例？用前文左外连接说明删除上层过滤为什么改变结果，再分别讨论保留过滤与连接类型转换。 差答：“多跑回归”“计划更短所以更快”。

Q8：C++ 取消路径用了 RAII，为什么仍有风险？ 强答：异步引用和引用环可能阻止析构，取消也不等于回调退出；需证明最后引用、完成确认和清理线程。 追问：换 shared_ptr 或原子完成标记够吗？分别检查存活、同步和调度依赖，不能混成一个问题。 差答：“智能指针自动管理”“TSan 没报”。

Q9：新存储格式出问题，关开关或回滚二进制够吗？ 强答：先确认格式是否已持久化、旧版本能否读取，再说明恢复、迁移与回收方案；停止新写入不等于恢复旧格式。 追问：发布前后分别崩溃？列出可见文件集合、孤儿清理和旧读者约束，补故障切点断言。 差答：“有校验和就安全”“写成功就删旧文件”。

Q10：RPC 超时能否直接报事务失败？ 强答：确认可能丢失而提交已经完成，需要按协议查询状态或安全重试，并核对结果与去重信息的恢复边界。 追问：换 leader、重启、去重记录清理后呢？说明旧请求是否仍可能到达，取消与提交竞态返回什么。 差答：“失败重试”“用 query_id 去重”。

Q11：AI 改了向量化循环，微基准更快，能合吗？ 强答：先验证 nullable、const、空批次、溢出和尾部处理，再在明确资源与负载条件下测查询级收益，关注内存峰值、吞吐和尾延迟。 追问：只在均匀数据上受益？补与改动相关的倾斜、NULL 和资源压力维度，未测负载列为限制。 差答：“用了 SIMD 必然更快”“AI 测试也过了”。

Agent 问题：审什么、准许什么、谁来负责

Q12：实现和测试由同一个 Agent 生成，怎样 review？ 强答：回到原始规格，检查断言能否拒绝错误实现；选择独立反例、参考结果或受控失败路径，复核关键逻辑与未测范围。 追问：再叫一个 Agent 就独立了吗？若共用错误规格或只读前一个摘要，仍可能重复相同假设。 差答：“两个 Agent 同意就合”。

Q13：Agent PR 修了 CI，能否让它自动重跑并合入？ 强答：区分运行授权、检查通过和合入审批；检查目标提交、工作流差异、凭据与分支保护，按风险决定自动化范围。 追问：补丁同时改了工作流怎么办？先审执行权限与副作用，再批准对应版本运行，确认没有通过削弱检查制造绿色结果。 差答：“CI 绿就自动合”。

Q14：Agent 让 PR 数增加，reviewer 已经看不过来，怎么办？ 强答：限制进入队列的任务范围和批量，治理重复告警，观察等待、返工与缺陷分布；同时明确规格、意图与风险负责人。 追问：工具说低误报，还需要测吗？需要在实际仓库复核有效发现、漏报和处理成本，产品宣称不能代替本地证据。 差答：“再加一个 reviewer Agent”。

经历叙事：保留角色与证据的真实边界

Q15：说一次你通过 review 改变方案的经历。 强答：选真实可披露案例，说明版本、原目标和自己的范围，用一个反例或失败时序解释修订，再报告实际验证与残余风险。 追问：哪条评论是你写的，谁补测，最终谁批准？逐项对应记录；阅读、评论、批准和主导设计是不同贡献。 差答：“我避免了一次重大事故”。

• 素材入口：外连接下的 dynamic filter 与 StarRocks optimizer 可以帮助复习机制；结论需回到各自版本与条件，文章存在不证明我参与过相关评审，下面的 review 情节是【模板】。
• 【模板】S：社区 PR 把 runtime filter 推过 left outer join。T：作为 committer 判断能否合入。A：（填实际过滤方向、保留侧、过滤器用途与 NULL 行为），构造反例并记录安全条件。R：（填实际修订、是否合入及验证结果）。不能仅凭“推向补 NULL 侧”判断丢行；只有确有记录才填后续问题数。
• 【模板】性能回归：PR 声称提升 X%，要求附 TPC-H/SSB 前后对比和 profile；（填实际负载、发现及证据）；（填合入、延期或拒绝原因）。默认关闭只是可选处置，不能写成已发生结果。（填真实数据）
• 【模板】机制化：团队 PR 首次响应时延中位数从（填）降到（填），措施包括 CODEOWNERS、PR 模板、CI 前置 sanitizer；补实际实施范围、时间窗口和其他影响因素，没有测量就不填改善幅度。

【模板】证据卡：背景与版本（填）→ 本人角色与审阅范围（填）→ 原实现及预期不变量（填）→ 评论中的触发条件与反例（填）→ 作者回应和修订（填）→ 验证环境、断言或测量（填）→ 未验证部分与残余风险（填）。无可核验记录的格子保留“未确认”。

反问团队时，我会问 PR 规模与首次响应分布、设计评审与合入权的关系、Agent 可以运行哪些检查、谁批准高权限 CI，以及工具误报由谁治理。这些答案比“是否用了 AI”更能说明实际工作方式。

实际落地可以先选可隔离、可验证的任务，让 Agent 交付补丁与执行记录，保留人工意图确认和风险审批，再根据返工与漏出问题调整范围。SQL 语义、异步存活、持久格式和混合版本恢复等变更，在证据不足时仍应停下来补证明；工具覆盖更广，不会降低这些证明义务。