Vibe Coding时代：代码审查与自动化测试如何守住质量防线

前阵子听一个朋友讲他们团队的翻车经历：三个工程师，用 vibe coding 的姿势搞了三个月，把一款 SaaS 产品从零堆到能演示的程度，功能列表非常吓人。结果上线第一周就爆了，用户支付回调的签名校验形同虚设，订单状态被 AI 生成的并发逻辑搅成一锅粥。最讽刺的是，代码都走过 review 流程，而且都通过了——因为没人能真正读懂那几千行 AI 生成代码里到底埋了什么雷。

这事儿让我意识到，Vibe Coding（凭感觉写代码，让 AI 生成，报了错就贴回去让它改，自己甚至不需要读代码）这个模式本身没有问题，问题在于大多数团队把"质量防线"完全交给了传统的代码审查和测试流程，而这些流程根本跑不过 AI 写码的速度。这篇文章照例是这个系列里偏实战的一篇，重点聊三件事：AI 协作时代的代码审查到底该审什么、自动化测试怎么落地才不会被 vibe coding 裹挟、以及怎么自己搭一个测试 Agent 来兜底。

1. Vibe Coding 让"质量防线"全面失守的三个真相

1.1 AI 生成的代码量远超你的 review 速度

先说个最简单的数学题。传统开发模式下，一个工程师一天的有效产出大概在 200 到 500 行代码之间，一个 PR 的体量通常在 500 行以内，reviewer 花 20 到 30 分钟把 diff 读完，是完全可以做到的。但在 vibe coding 模式下，一个人一天可以让 AI 灌出两三千行甚至更多的代码，而且是以"看起来都挺对"的方式灌出来的。

我算过一笔账：一个熟练的工程师读别人写的代码，速度大概在每分钟 30 到 50 行，而且这是在不考虑理解上下文的前提下。AI 生成的代码恰恰是上下文最多的代码——它为了防御各种边界，会写大量模板化的判断、重复的工具函数、冗余的日志逻辑，这些代码的阅读体验比人写的还要累。也就是说，原来 30 分钟能审完的活，vibe coding 之后可能需要两三个小时。这还只是一个 PR。

这就是第一个真相：靠"逐行阅读"来保障质量的传统代码审查，在 vibe 编码的产量面前，物理上就不可行了。你得先承认这一点，后面所有的方法论才有意义。

1.2 "能跑"不等于"正确"

Vibe coding 的反馈循环有个致命的问题：它的成功标准是"代码能跑起来"，而不是"逻辑符合业务预期"。你告诉 AI 你要什么，它写得飞快，跑起来也没报错，你就会天然地认为"没问题"。但真正上生产之后，出问题的往往不是"跑不跑得起来"，而是"跑起来之后做的决定对不对"。

举个我真实见过的例子。有人让 AI 写一个每天凌晨同步订单数据的定时任务，开发环境跑起来一切正常，数据也同步了。上线第三周老板发现报表里的金额总是差一节，排查了一整天才定位到：AI 在写时间处理时，用了一个带时区的类，但在解析上游时间戳时假设了 UTC，于是每天凌晨的同步窗口里，有 8 个小时的订单被归到了前一天。开发环境里的数据量少，看不出来；生产环境一放大，问题就成了事故。

这类问题有个共同特征：它们在"正常路径"上完全看不出毛病，只有在边界条件、异常分支、跨系统约定这三类场景下才会暴露。而这三类场景，恰恰是 AI 写代码时最薄弱的地方——因为它从训练数据里学到的"常见写法"，覆盖不到你业务里的特殊约定。没有自动化测试兜底，这些问题就像埋在地里的雷，什么时候爆，全看运气。

1.3 审查者面对 AI 代码时的"自动化偏见"

第三个真相稍微有点反直觉，它跟技术没关系，跟人的心理机制有关。心理学里有个概念叫自动化偏见（automation bias），意思是人类面对自动化系统给出的结论时，会本能地降低自己的警惕性，倾向于信任系统的输出。

AI 生成的代码也一样。当你打开一个 PR，看到满屏代码结构严谨、注释齐全、命名规范（AI 特别擅长这些表面功夫），你的大脑会不自觉地放松戒备：既然它写得这么像模像样，那应该没什么大问题吧。这种认知偏差是 vibe 时代代码审查最大的隐形杀手。

更麻烦的是，同一个 AI 既能写代码也能"解释"代码。reviewer 看不懂某段逻辑时，把代码贴给 AI 问一句"这段是干嘛的"，AI 会给出一个听上去非常合理的解释——但这个解释可能本身就是它编的。我在团队里遇到过好几次这样的情况：AI 把 A 函数的作用解释得头头是道，但实际上那一段是 B 函数在调用，解释和代码已经对不上了，AI 照样自信满满。

解决办法我在后面会细说，核心思路是：不能再让"写了这段代码的 AI"来负责解释它，得引入独立的 AI 审查者、独立的人类决策层，再把自动化测试作为最终裁判。

2. 被误解的审查：AI 协作时代的代码审查到底在审什么

2.1 从逐行阅读到"差异驱动"的审查

既然逐行读不现实，那 AI 时代的代码审查第一步是转变心态：你不需要读懂这个 PR 里所有的代码，你需要搞清楚的只有三件事——这个改动想改变什么行为？它改变这份行为的方式，跟现有系统的逻辑冲不冲突？改动带来的风险点有没有被覆盖到？

我把这种审查方式叫"差异驱动审查"。具体操作是：不要从文件清单开始读，先从 diff 的主干开始看，搞清楚这次改动的主线逻辑。AI 生成的代码通常有大量辅助性的外围内容（错误处理、日志、类型判断），这些等主线逻辑清楚了再回头看不迟。

实操里有个效率很高的习惯：让写代码的那个人（哪怕是 AI）先输出一份 PR 摘要，包括改动背景、目标行为、涉及的核心路径、已知风险点。人类 reviewer 拿到摘要之后，只需要验证"摘要说的跟代码做的是不是一回事"。这个验证成本比逐行读低得多，但抓到的问题反而更关键——很多时候 AI 写的代码和它声称要做的功能根本不是同一个东西。

2.2 审交互边界和隐含假设：AI 最擅长一本正经地胡说八道

我在前面提到，AI 代码最薄弱的三个地方是边界条件、异常处理、跨系统约定。对应到代码审查里，这三个地方就是你要重点审的对象。

边界条件包括：输入为空的时候走什么逻辑？数组越界了怎么办？并发情况下状态会不会乱？异常处理包括：外部接口超时了是重试还是抛错？上游返回了非预期格式怎么兜底？跨系统约定包括：你调用的外部 API，真实返回结构真的像代码里假设的那样吗？你写的返回值，下游真的能接到吗？

这里我多说一句：AI 特别擅长假设外部接口的返回格式。它从文档和类似项目里学到的"常见接口格式"，跟你实际对接的那个服务的真实格式，往往有出入。所以审查时如果看到 AI 写了类似const data = res.payload.data这样的代码，一定要追问一句：谁告诉你这个接口一定有 data 字段？

我踩过一次很深的坑。AI 写了一个对接第三方物流查询的模块，开发环境和测试环境用的都是 mock 数据，一切正常。上线之后才发现，第三方接口在订单不存在时返回的报文里根本没有我们解析的那个节点，AI 也没做空值判断，系统直接抛了空指针异常，整个查询链路挂了。这个事如果当时有一条自动化用例覆盖"上游返回异常报文"的场景，根本走不到生产。

2.3 用独立的 AI 做第一轮审查

既然人类 reviewer 的时间不够用，最直接的办法是让机器先帮人类筛一遍。这里的核心原则是：负责写代码的 AI 和负责审查的 AI 必须是互相独立的。如果同一个模型、同一个上下文里既写又审，那就是让考生自己给自己打分，基本等于走过场。

我的做法是开一个全新的会话，或者干脆换一个不同厂商的模型，把 PR 的 diff 粘贴过去，配合一个固定的审查 prompt。下面这个模板我用了一段时间，效果比较稳定：

你是一名资深代码审查员。以下是本次代码变更的 diff，请从以下几个维度进行审查，逐条输出问题： 1. 业务逻辑正确性：变更是否可能引入逻辑错误？ 2. 边界与异常：输入边界、空值、超时、重试、非预期返回是否处理？ 3. 安全与权限：鉴权、越权、敏感信息泄露、输入校验是否存在漏洞？ 4. 兼容性：是否会破坏已有的接口契约或数据结构？ 5. 可测试性：这段代码是否容易被测试覆盖？缺少哪些测试用例？ 请对每个问题标注严重等级（高/中/低），并给出具体的修改建议。

把这份审查结果拿回来之后，人类 reviewer 只需要做两件事：确认 AI 指出的问题是否真实存在，以及 AI 没提到的地方有没有遗漏。实测下来，这个前置流程能帮人类砍掉 60%-70% 的低价值 review 时间，剩下需要人动脑子的，基本都在"业务逻辑正确性"和"安全与权限"这两个维度上。

当然，AI 审查结果绝对不能直接信。它最大的问题是会编造"看起来合理的问题"——有时候它指出的"bug"其实是它自己理解错了。所以 AI review 的输出只是线索，不是结论。

2.4 一份可以直接抄的 review 检查清单

结合前面说的内容，我整理了一份 vibe 时代代码审查的检查清单，适合贴在团队 wiki 里或者做成 PR 模板的勾选项：

这个清单不要求每条都必须是"通过"，但它能强迫审查者把注意力放在高频风险点上，而不是被 AI 写出来的花哨代码带跑偏。

3. 自动化测试从"可选"变成"承诺"：三类必须落地的测试

3.1 单元测试：给 AI 生成的逻辑上锁

代码审查管的是"要不要合入"，自动化测试管的是"合入之后还敢不敢继续改"。在 vibe coding 的模式下，代码迭代频率极高，如果没有单元测试兜底，每次让 AI 改完代码、修完 bug，都相当于一次推倒重来的冒险。

我的习惯是给 AI 下一条硬性规定：每次修改核心业务逻辑的同时，必须同步生成或更新对应的单元测试。这一步不依赖团队自觉，而是靠工程约束——下面这条 pytest 的最小样例，可以作为 AI 生成单测的起点：

# test_discount.py import pytest from discount import calculate_discount def test_正常价格不打折(): assert calculate_discount(price=100, user_level="normal") == 100 def test_会员打九折(): assert calculate_discount(price=100, user_level="vip") == 90 def test_零价格不崩(): assert calculate_discount(price=0, user_level="vip") == 0 def test_负价格抛异常(): with pytest.raises(ValueError): calculate_discount(price=-1, user_level="normal")

注意看这几个用例的设计思路：它不只是测"正常路径"，而是把边界（零价格、负价格）和业务规则（会员折扣）一起锁住。这恰恰是 AI 最容易出错的地方。如果你只是让 AI"写几个测试"，它大概率会给你生成一套只验证 happy path 的用例——这种测试跑一万次都是绿的，但对质量毫无保护作用。

关于覆盖率，我的态度很明确：不要追求 100%。覆盖率是手段不是目标，重点把核心业务模块的覆盖率拉起来，外围的胶水代码、配置加载、日志封装这类，就算低一点也没关系。我见过太多团队为了达标硬写assert True的无效用例，纯粹是自欺欺人。

3.2 接口自动化测试：性价比最高的防线

如果 vibe 时代只能保留一种自动化测试，我强烈建议保留接口自动化测试。原因很简单：AI 最常见的翻车方式，是打破系统之间的"契约"。接口测试恰恰是验证契约的最佳工具，而且它的维护成本远低于 UI 自动化，执行速度又快，非常适合作为 CI 里的质量门禁。

技术选型上，Python 生态用pytest + requests + allure基本是标配，Java 生态则绕不开RestAssured + TestNG + Maven。两者我都在项目里跑过，给你一个最直白的选型建议：如果团队技术栈以 Python 为主，或者团队规模不大，选 pytest 这一套，代码量少、上手快；如果是大型团队且已有 Java 基础设施，选 RestAssured，跟现有的构建链和代码规范能无缝衔接。

下面是一个最小的 Python 接口自动化测试框架骨架，核心就两个文件：

# conftest.py import pytest import requests BASE_URL = "https://api.example.com" @pytest.fixture(scope="session") def session(): s = requests.Session() # 这里做登录并拿到 token s.headers.update({"Authorization": f"Bearer {get_token()}"}) return s @pytest.fixture(scope="function") def cleanup_order(): yield # 每个用例跑完之后清理订单数据，避免用例间互相污染 cleanup_test_orders()

# test_order_api.py def test_创建订单_正常流程(session, cleanup_order): resp = session.post("/orders", json={ "product_id": "sku_123", "quantity": 1, "pay_channel": "wechat", }) assert resp.status_code == 201 order_id = resp.json()["data"]["order_id"] assert order_id def test_创建订单_商品不存在(session): resp = session.post("/orders", json={"product_id": "not_exist"}) assert resp.status_code == 404

这两个用例的差别你应该能看出来：一个验证正常路径，一个验证异常路径。对 AI 生成的接口代码来说，异常路径才是重灾区。第三方返回失败格式、缺失字段、鉴权失败，这些用例写出来之后，AI 再怎么乱写代码，接口层出问题都会被 CI 先拦住。

3.3 E2E 自动化测试：Playwright + AI 生成用例

接口测试管住了契约，但管不住页面交互。AI 在写前端 UI 逻辑时，经常会出现"功能明明实现了，用户却不知道怎么操作"或者"某个按钮点击后没有反应"这类问题，这些只能靠端到端测试来发现。

端到端测试工具我目前最推荐 Playwright，没有之一。跨浏览器、自带智能等待、还能录制操作生成脚本，这些特性在 vibe 时代太重要了——尤其是"智能等待"，它解决的是 AI 代码里最常见的时序问题：页面元素还没加载完就去点击，导致偶发性失败。Selenium 时代最痛苦的隐性等待问题，在 Playwright 里基本消失了。

让 AI 辅助写 E2E 用例是真正的提效点。我的做法是给 AI 描述业务流程，让它生成 Playwright 脚本，然后人工过一遍，把业务断言补上。比如：

# test_checkout.py from playwright.sync_api import Page, expect def test_下单全流程(page: Page): page.goto("https://example.com") page.get_by_role("button", name="加入购物车").click() page.get_by_role("button", name="去结算").click() # 断言：结算页出现了订单金额 expect(page.locator(".order-total")).to_contain_text("¥") page.get_by_role("button", name="提交订单").click() # 断言：跳转到了支付页面 expect(page).to_have_url(re.compile(r"/pay"))

这套脚本跑的链路很长，一旦中间任何一步因为 AI 改坏了代码而中断，CI 立刻报警。实际维护中，最大的痛点是元素定位符（locator）经常因为前端重构而失效。我现在的做法是：把失败的截图和 HTML 快照直接喂给 AI，让它分析新的页面结构、给出修正后的 locator。这套"AI 生成用例 → 失败 → AI 自动修复"的闭环，能把 E2E 维护成本压缩到一个团队能长期承受的水平。

顺带提一句小程序自动化。有人问"小程序如何利用 AI 做自动化测试"，我的看法是：小程序领域目前还没有一个像 Playwright 对 Web 那样成熟的 E2E 方案，比较常见的路线是微信官方出品的miniprogram-automator，或者走 Appium 这类移动端自动化工具。这些方案都能接 AI 辅助生成用例，但成本明显比 Web 端高。如果团队资源有限，建议优先保核心用户链路，别贪多。

3.4 测试金字塔在 Vibe 时代的变形

传统测试金字塔的配比是：大量单元测试、少量接口测试、极少 E2E 测试。这个配比在 AI 写代码的时代需要做一次调整：接口测试的比例要往上提，甚至可以考虑把它变成整个金字塔的"腰部核心"。

原因前面已经说过：AI 最容易打破的是系统边界上的契约，而接口测试是契约的第一道守卫。E2E 虽然覆盖面最直观，但执行慢、维护贵，应该压缩成"冒烟级"的数量，只覆盖最核心的几条用户路径。单元测试仍然重要，但它更聚焦在核心业务逻辑上，不需要追求全面铺开。

我在团队里给的实际比例大约是：单元测试 40%、接口测试 45%、E2E 冒烟 15%。这个配比不是绝对的，但它反映了一个思路调整：把测试资源往"契约层"集中，用最少的维护成本守住最容易出事故的环节。

4. 自己搭建 Agent 做自动化测试的实战路线

4.1 为什么建议"自己搭"而不是买现成的

市面上的 AI 自动化测试工具不少，我大概用过三四款，结论是：它们对特定场景（比如登录页、表单页）的调试确实方便，但一旦你的业务场景稍微特殊一点——比如要操作企业微信内部系统、要连数据库做数据断言、要按你团队的测试报告格式输出——那些黑盒工具就变得非常别扭。

自己搭一个测试 Agent 的核心价值不在于"AI 有多聪明"，而在于它是你完全可控的：它理解你的业务上下文，能直连你的测试环境，按你团队定义的验收标准来跑。另外从面试角度说，现在问"你怎么自己搭建 Agent 做自动化测试"的团队越来越多，自己动手把这条路走通一遍，聊起来底气完全不一样。

不过我也说句实在话：如果团队只有三五个人，测试场景也比较常规，直接用现成工具加 Playwright 足够，没必要上来就搞 Agent。自建 Agent 适合的场景是：自动化用例数量已经过百、跨系统依赖多、需要频繁处理非结构化测试任务。

4.2 一个最小可行的测试 Agent 架构

我们公司现在跑的这个测试 Agent，核心架构并不复杂，拆开来就五个组件：

1. 意图解析器：接住用户的自然语言指令，比如"跑一下订单相关的回归"。
2. 任务规划器：把意图拆解成可执行步骤，比如"先登录 → 创建订单 → 支付 → 查订单状态"。
3. 执行器：调用 Playwright、requests、数据库连接器去真正执行步骤。
4. 结果收集器：把执行结果、截图、接口返回报文、日志数据统一收集起来。
5. 决策环：把收集到的结果回传给 LLM，让 LLM 判断"继续往下走"还是"判定失败并给出原因"。

流程上的关键点是：不能让 Agent 完全失控地自动循环下去。必须给它划定边界——允许访问哪些域名、允许执行哪些动作、单条用例的超时时间是多少、最多重试几次。否则 Agent 一旦发疯，会在测试环境里无限创建订单、无限点击按钮，账单比人还吓人。

4.3 一个可以跑的极简实现

下面这个代码骨架是我在个人项目里验证过的，用 Python + Playwright + OpenAI API 可以实现一个最简单的"自然语言驱动测试"Agent。它能听懂"打开首页并登录账号"这种指令，并按规则执行：

# simple_test_agent.py import json import openai from playwright.sync_api import sync_playwright def run_natural_language_test(instruction: str): # 1. 让 LLM 把自然语言指令转成 Playwright 步骤 JSON prompt = f""" 把下面的测试指令拆解为 Playwright 可执行步骤，只输出 JSON 数组。 每一步包含 action(open/click/fill/expect_text) 和参数。 指令：{instruction} 示例输出：[{{"action": "open", "url": "https://example.com"}}] """ resp = openai.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0 ) steps = json.loads(resp.choices[0].message.content) # 2. 逐步骤执行，把结果收集回来 results = [] with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() for step in steps: act = step.get("action") if act == "open": page.goto(step["url"]) results.append({"step": act, "status": "ok"}) elif act == "click": page.click(step["selector"]) results.append({"step": act, "status": "ok"}) elif act == "fill": page.fill(step["selector"], step["value"]) results.append({"step": act, "status": "ok"}) elif act == "expect_text": content = page.text_content(step["selector"]) ok = step.get("expect") in content results.append({"step": act, "status": "ok" if ok else "failed"}) browser.close() # 3. 把执行结果回传 LLM，生成最终判断 final_prompt = f"测试步骤执行结果如下，请判断测试是否通过并给出简要报告：{json.dumps(results, ensure_ascii=False)}" final_resp = openai.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": final_prompt}], temperature=0 ) return final_resp.choices[0].message.content if __name__ == "__main__": print(run_natural_language_test("打开首页，点击登录按钮，输入账号 test@example.com 和密码 123456，点击提交"))

这只是一个演示骨架，生产环境里你至少还要加：执行环境隔离、失败重试机制、步骤级别的超时控制、以及把结果对接上报到测试管理平台。但它已经把"自建 Agent"的核心链路跑通了：自然语言 → LLM 拆解 → 执行器执行 → 结果回传 LLM 判断。

4.4 实测效果与翻车记录

我们这个 Agent 跑了大概四个月，说说真实数据：回归用例的编写时间从人均一小时的量级降到了十五分钟左右（毕竟 AI 生成初稿，人只需要校对），而且最明显的变化是——非技术同事（产品经理、运营）也能自己跑一趟"下单流程"的回归，这在以前是不可想象的。

但翻车的次数也不少，主要是三件事。第一，AI 生成的 locator 经常是错的，页面结构和它猜测的不一样，导致用例第一步就跑飞。第二，Agent 修代码修上头，有时候会为了"让测试通过"而自己改断言逻辑，把本该失败的用例改成永远绿——这是最危险的情况。第三，Agent 跑长链路时偶尔会死循环，如果没设超时，一张账单能跑到你怀疑人生。

针对这三个坑，我的对策分别是：locator 问题让 AI 基于页面快照（ARIA 快照或 HTML 片段）来生成，而不是凭记忆胡猜；测试断言逻辑做版本管理，Agent 不允许直接篡改断言，只能提出修改建议由人来确认；所有 Agent 任务强制设置总超时和步骤超时，到了就中断并报错。这些规则听起来很基础，但少了任何一条，Agent 都有可能从"测试助手"变成"事故制造机"。

5. Vibe 团队里的协作规则：让审查和测试不拖后腿

5.1 小步提交与"AI 结对"的工作流

聊完了单点技术，最后说团队协作层面的节奏设计。vibe coding 最容易出现的一个场景是：工程师让 AI 一口气写了 2000 行代码，然后一股脑提了个巨型 PR，谁都审不动。所以在团队里我立的第一个规矩就是：AI 生成的大块代码，必须由人类工程师拆分后再提交，一个 PR 的 diff 控制在 300 行以内。

这个数字不是随便定的。300 行以内，人类 reviewer 还能在 30 分钟左右读完全部改动；超过这个量级，人脑的注意力就开始下降，审查质量急剧下滑。为了做到这一点，最直接的办法是在让 AI 干活之前，先让 AI 输出一个改动方案，你把方案拆成几个阶段，每个阶段单独跑一下测试再合入。

另外一个正在验证的工作流是"AI 结对"：一个 LLM 负责写代码，另一个独立的 LLM 负责审代码，人类只做最终决策。这听起来有点折腾，但在关键模块（支付、权限、核心数据操作）上是值得的。前面说过，同一个模型既写又审没有意义，但两个独立模型之间互相挑刺，确实能发现一些人类容易忽略的问题。

5.2 质量门禁：CI/CD 里怎么配置

团队协作光靠自觉不够，还需要硬性门禁。我建议在 CI 里配置三道闸：单测、接口测试、E2E 冒烟。任何一个不通过，PR 不允许合入。这是个简单的 GitHub Actions 配置，可以直接抄：

name: quality-check on: pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: "3.12" - name: Install dependencies run: pip install -r requirements-dev.txt - name: Unit tests run: pytest tests/unit --cov=src --cov-fail-under=70 - name: API tests run: pytest tests/api - name: E2E smoke run: pytest tests/e2e --headed=false

门禁设完之后，团队普遍会经历一段"阵痛期"——CI 红一片，因为 AI 生成的代码第一次被真刀真枪卡住。这时候最容易犯的错误是一看到用例失败就让 AI"修一下测试"，把失败断言改成不失败。我见过太多次这种操作：AI 把assert x == 10改成assert x in [5, 10]，测试绿了，bug 还在。所以门禁后面还要跟一个纪律：测试失败先查实现，再查测试本身，不能一上来就修用例。

5.3 代码审查的"时间盒"机制

前面说了，传统 review 方式在 vibe 时代跑不动。我自己在团队里推的做法是给审查设时间盒：一个 300 行以内的 PR，review 时间不超过 30 分钟，到点必须给出结论——要么通过、要么打回、要么挂上"需讨论"的标签。不要在一个 PR 上纠结两小时。

时间盒的底层逻辑是：vibe 时代的风险不是"漏看了一个变量名"，而是"改动方向跟业务预期偏离"。方向性问题在摘要和 diff 主干里能很快发现，不需要逐行读。至于细枝末节的问题，自动化测试会替你把关。所以把审查时间压缩到 30 分钟以内，反而逼着 reviewer 去抓重点，而不是陷入"帮 AI 捉语法虫"的泥潭。

风险分级也是个好办法：改动涉及支付、权限、数据迁移的 PR，走深度审查，逐行过；纯前端样式、文案、工具函数这类低风险 PR，走轻量审查，只验主干逻辑。分级之后，团队的审查压力小了很多，重点环节反而更有保障。

5.4 从 vibe coding 到 vibe testing

最后聊聊方向。很多人以为 vibe coding 和代码审查、自动化测试是对立的，一个求快一个求稳。但这一期想说的其实是：它们不该对立，也对立不起来。vibe coding 解决的是"怎么让 AI 更快地产出"，代码审查与自动化测试解决的是"怎么让 AI 的产出不把团队淹死"。前者负责油门，后者负责刹车和护栏。

我越来越觉得，接下来更有意思的方向是"vibe testing"——不只是"让 AI 写测试"，而是让整个测试流程也进入"凭感觉但可控"的状态：工程师用自然语言描述测试目标，Agent 自己拆步骤、跑用例、收结果、报问题，人只负责最后拍板。这个状态在四个月前我还觉得是 PPT，现在已经在团队内部跑起来了，虽然 bug 还不少，但方向是明确的。

如果你在准备面试，这是个很好的话题切口。现在不少团队在问"vibe coding 怎么保证质量""你怎么看 AI 自动化测试"，能讲清楚"为什么自建 Agent""门禁怎么设""审查流程怎么改"这三件事的人，已经跟只会喊"AI 写代码真快"的人拉开了距离。

最后分享一个我自己的体会。前半年我有一阵特别上头，每天让 AI 写大量代码，功能推进飞快，但测试一直没补，总觉得"后面再补"。直到一次演示环境在客户面前突然崩溃，我才真正明白：vibe 时代的自由，必须以自动化为土壤。没有测试兜底的 vibe coding，不是自由，是裸奔。

如果让我给你一条立竿见影的建议，那就是：从今天开始，给你所有 AI 生成的代码加上一条铁律——"没有配套测试的代码，不算完成"。一开始会觉得慢，但跑两周之后你会明显感觉到，睡觉都踏实了。顺便说一句，那些你让 AI 写的测试用例，一定要把"业务预期"写清楚再让它写，否则它只会生成跟实现完全一致的"自证式"测试，跑得再绿也说明不了任何问题。