OpenAI 这篇客户案例把 Greptile 的变化说得很干脆：缺陷检测不再停在代码审查。Greptile 用 GPT-6 Astra 测试用户工作流，用 Daybreak 加强安全，用 Codex 减少返工。公开信息只到这一层组合，没有模型规格、评测分数、误报率或接入方式。对开发者，有用的是意图，而不是把宣传稿读成评测报告。审查仍在，但被写成入口；后面要接住的是用户路径能不能走完、安全有没有漏、合并之后还要不要来回改。
从看 diff 到测用户工作流
标题的关键不在「又一个 AI 审查」，而在 beyond code review。代码审查处理的是变更本身：可读性、明显缺陷、接口是否被破坏。用户工作流测试处理的是另一件事：这些变更叠进产品后，用户常用路径是否还能闭环。材料把 GPT-6 Astra 的用途写成 test user workflows，因此它被放在审查之后的验证层，而不是只生成 PR 评论。Astra 究竟是写测试、跑路径、做探索性点击，还是只根据仓库与文档做静态推断，摘要没有说，不能补写。能说的只有职责划分：模型被指定去碰「用户怎么用」，而不是去当更健谈的 reviewer。材料没证明 Greptile 已经把工作流测试做实，只表明他们把这个方向写进了产品叙事。缺了可命名的路径和可判定的失败，审查意见再长也接不住上线后的使用问题。
安全与返工被拆成两条线
同一句摘要里，Daybreak 对应加强安全，Codex 对应减少返工，和 Astra 并列。这说明「找 bug」在他们的说法里不是一次模型调用。安全问题的漏检和误报都很贵，通常要独立门槛；返工则是审查过了仍要改代码、补测试、处理冲突的时间税。Daybreak 是产品名、扫描层还是内部项目，Codex 是补全、改 diff 还是自动消化评论，材料都没解释。能读出的结构只是检测、安全、收口被分开讲，而不是一个通用模型包办。对正在接 AI 编码工具的团队，这更像研发系统设计：谁负责发现路径失败，谁负责拦住安全风险，谁负责把修改做完并减少来回。三者是否真的降低了线上缺陷，案例没给证据。
我的判断
价值主要在方向：代码智能体从「看 diff」扩到「测工作流」和「消化返工」，比继续加长审查意见更接近真实交付。适用边界很窄。这是 OpenAI 的客户故事，信息停留在摘要级，不能当选型依据，也不能外推到中小团队或私有化部署的收益。局限同样硬——没有基准、没有失败样本、没有成本和集成说明。当成组合三种能力的宣传稿来读即可：有分工意识，无配方。若要进生产，得自己规定工作流覆盖哪些路径、安全误报预算是多少、返工下降如何度量。缺这三项，换模型名没有意义。