Vibe coding 不是不用写测试，是换个人写：先定测试用例再写代码，还得有个独立评审员

Vibe coding 最容易被误解的一句话是“不用写代码了”。小博主 nguyen nang huy（@nanghuy001）在 11 月 5 日的 Medium 文章里把这句话纠正了一半：代码可以少写，测试不能少写——而且测试这件事，在 AI 写代码的时代比以前更重要。他的理由很直接：以前是你写代码、你写测试；现在是 agent 写代码、agent 写测试，同一双手既当运动员又当裁判，绿灯亮了也不代表代码是对的。

他的方法分六步，核心在第二步和第五步。第一步，理解需求：agent 先读需求和完成标准，不清楚的先问，不许猜。第二步，先定测试用例再写代码：列出正常路径、边界情况、报错情况和每种情况的预期行为——这是他本人审得最仔细的一步，因为这一步便宜，且决定了后面所有产出。第三步，写代码并写出对应的自动化测试。第四步，跑验证：测试、lint、静态分析、类型检查，全绿才往下走。第五步，独立评审：另一个 Reviewer Agent 单独检查实现和测试本身的质量，不只看 CI 是不是绿的。第六步，过门禁才能合并。

评审员要审两件事。实现评审：正确性、代码质量、安全性、范围（只做了该做的事，没多做）。测试评审：需求覆盖全不全、正常和边界与报错场景齐不齐、断言写得到不到位、测试本身稳不稳定。作者还给了一个分类表，写进 CLAUDE.md 让 agent 自己判断：普通功能走测试金字塔，RAG、LLM、Agent 这类 AI 功能加一层自动化评估加回归测试。比如电商聊天机器人，优先回归测试那些能量化的事：商品查询返回正确的 SKU、订单查询返回正确的状态、路由分到正确的处理函数、检索拉到正确的文档、工具调用传了正确的参数。

这套方法真正有价值的洞见不在六步流程，在“谁来审测试”这个问题。同一份测试由写代码的 agent 自己写出来，天然会顺着实现写断言，测的只是“代码按我以为的方式跑了”，不是“代码做对了需求”。独立评审员的意义，是把测试质量本身当成被审对象——这也是 gstack 那 64 个角色里专门留评审角色的原因，思路是通的。

怎么用起来：别照抄六步，先抄两条。第一，把“先定测试用例”写进你的 CLAUDE.md 或工作流文件，强制 agent 在写代码前先列出用例清单，等你点头再动手。第二，给你的项目加一个独立评审步骤，哪怕是用同一个 Claude Code 另开一个 fresh context 的 subagent 来审，也比让实现者自己说“测过了”强。剩下的分类表和门禁，等你跑顺了再补。

边界必须写清：这是作者个人的工作流实践，不是跑分验证过的方法，没有数据说明它能把 bug 率降多少；六步里的“完成标准”和分类表需要你自己的项目信息才能落地，照抄跑不起来。以及，本文作者的方法我没有亲自跑过，照着用之前先在小项目上试一轮——这是独立判断，不是实测结论。

可信度：六步流程、评审分工、分类表为作者 11 月 5 日 Medium 原文（单方实践分享）；Claude Code 团队同类做法（多 agent 并行评审、投票定稿）为 11 月 4 日团队博客经第三方整理，可作旁证；效果数据作者未提供，尚未证实。