代码评审能抓出逻辑 bug，但有一种缺陷它天生看不见：按钮在某个尺寸的屏幕上消失了、某个交互流程在真实浏览器里点了会崩。Greptile 这家做代码审查 Agent 的公司，最近用 GPT-6 的 Astra（Codex Astra）把这层补上了——让模型直接操作浏览器，模拟真实用户去测代码改动。这篇把它的三件套分工拆开讲。
从审代码到模拟用户
Greptile 的定位是「在完整代码库上下文的层面审查和测试代码变更」，联合创始人 Daksh Gupta 把公司的使命说得很直白：减少 bug，让世界上的软件更可靠。以前审一个 PR，模型只能读 diff；现在 Astra 的 computer use 能力让整件事变了——针对某个 pull request，它可以启动对应的开发服务器、把浏览器视口缩到 iPhone 尺寸、模拟用户在应用里的实际操作，再靠视觉理解直接「看」屏幕检查状态。
一个具体例子能说清这层价值：某个按钮在 iPhone 上看网站时会消失。纯读代码很难发现这个问题，但 Astra 会启动那个 PR 的开发服务器，把浏览器调成 iPhone 视口，模拟用户浏览，然后靠视觉理解发现这个隐藏的按钮。这正是「代码评审之外」的缺陷——它不在 diff 里，在渲染出来的页面和真实的用户路径里。
三件套的分工
Greptile 现在靠三个模型分工，各管一段：
| 模型 | 干什么 | 解决什么 |
|---|---|---|
| GPT-6 Astra | 计算机使用，模拟用户操作、视觉检查 | 大规模自动化测试，替代「人工 QA 每个改动」 |
| Daybreak | 安全加固 | 让资源有限的初创也能把系统防御做起来 |
| Codex | 接知识库按既有模式写代码 | 减少返工和回滚 |
Daksh 对这套组合的判断是：computer use 第一次达到了可以自动化「让用户试着弄坏你的应用」这个体验的水平，让大公司发布时更有信心。传统 QA 公司测所有变更慢得不可行，而 Agent 可以规模化地跑这件事。安全侧他提到了一个容易被忽视的点——模型越强，攻击者利用漏洞也越容易，所以防御要比对手的进攻手段更先进，Daybreak 就是朝这个方向去的。
数字与信号
原文里唯一的量化数据是：数千名客户已经把 Codex 接到了 Greptile 的知识库上。它的工作方式是先把代码库索引成一个知识库，记录项目的工作方式，再通过 MCP 服务器把这些文档提供给 Codex，Codex 就按客户代码库里已有的编码模式来写代码。团队跟踪了 AI 生成代码被回滚的频率，发现给 Agent 喂了上下文之后，回滚次数减少——「更少的回滚，客户省时间和推理成本」。这也解释了为什么「上下文」比「模型更强」更值钱：让 Agent 按你仓库的既有模式写，返工自然少。
这个信号比单一功能更有意思：缺陷检测正在从「评审阶段看代码」往前移到「改动一进来就自动化跑真实用户路径」。测试不再只是断言函数返回值对不对，而是把「人怎么用这个产品」也纳入了自动化。往后，一个 PR 合进去之前，可能先被 Agent 在 iPhone 视口里点过一遍、被安全模型扫过一遍，再交给人类评审看逻辑——评审这个环节本身也会被重新定义。
待观察
两件事值得盯。一是 Astra 的 computer use 到底能覆盖多大的测试面——起服务、缩视口、模拟点击只是演示出来的路径，真实产品的状态流转和边界情况远比这复杂，能不能规模化还待验证。二是 Daybreak 提到的「防御领先于进攻」目前还是定性说法，没有给出可量化的安全指标。对开发者来说，这波趋势更直接的启示是：当 Agent 能自己测自己写的代码时，「写」和「测」的边界在模糊，人真正该管的是定义「什么叫对」——这恰恰是代码评审之外，更早、也更难的那一步，也是接下来最值得花时间的地方。