关于 AI 写代码，工程团队最常见的抱怨是：生成得快，但验证得慢。代码看起来对，逻辑大概能跑，可要真正上生产，你还是得自己读一遍、自己写测试、自己盯着 CI。结果 AI 省下的时间，有相当一部分又被「审查 AI 的产出」吃掉了。
Perplexity 联合创始人兼首席战略官 Johnny Ho 给出的路径有点不一样：不只是让模型写代码，而是让模型负责构建证明代码可用的那套东西。他在 OpenAI 的一则客户案例里，描述了这套做法在生产环境里的样子，以及一个更值得玩味的后果——他对模型的检查频率比使用上一代模型时低得多。
速览卡：这位大佬和他说了什么
 | 大佬 | Johnny Ho（何嘉豪） |
| 身份 | Perplexity 联合创始人兼首席战略官（CSO）；负责产品工程、排序算法与延迟优化；前 Tower Research 高频量化交易员、Quora 工程师；2012 年国际信息学奥赛（IOI）全球第一、满分金牌 | |
| 出处 | OpenAI 客户案例《Perplexity trusts GPT-6 Astra with end-to-end systems》及配套视频（2026-09-14） | |
| 时间 | 2026 年 9 月 14 日 | |
| 核心观点 | 让模型自己搭建测试程序、顶替外部服务生成响应，从而端到端验证工作流；已把沟通撰写、修改真实系统、监控生产软件交给模型，且检查频率远低于前几代模型 |
先说清楚一件事：这是一则供应商客户案例，天然带有宣传属性。但这则案例值得读的原因不在于结论有多惊人，而在于 Ho 说出的几个具体的工程动作——它们可以脱离厂商语境被单独评估。本文把原文引述逐句保留英文，方便读者核对措辞。
他说了什么：逐句还原
整则案例里真正以直接引语形式出现、且信息量最大的只有两句。第一句覆盖了三件事：
“We can have the model craft communications, edit real-world systems, and monitor our production software in a way that previous generations were not able to.”
（译文）我们可以让模型撰写沟通文案、修改真实世界的系统，并监控我们的生产软件——这是前几代模型做不到的。
这句话里三个动作的「胆子」是递增的。写文案是最低风险的——错了重写就行。监控生产软件是中等风险——它是只读的，但看错了会误导判断。而修改真实系统是最高风险的：dev 环境改错可以回滚，线上改错是事故。
第二句才是真正的重点，也是这则案例里最有价值的一句：
“We’re actually able to trust it with full end-to-end systems and check in on it much less frequently than previous generations of models.”
（译文）我们实际上能够把完整的端到端系统交给它，并且检查和介入的频率比前几代模型低得多。
注意这句话的两个要素：「端到端系统」划定了信任范围，「检查频率低得多」描述了人的角色变化。前者是能力声明，后者是流程变更——后者对团队的意义更大，因为监督成本才是真正的瓶颈。
还有一个被转述、但同样关键的观点，关于编码能力和搜索质量的关系：
“Every time the model gets better at writing code, Perplexity’s search engine improves too. It becomes able to write better programs that search the web and internal information and summarize it very concisely.”
（译文）每当模型写代码的能力变强，Perplexity 的搜索引擎也会随之提升。它能够写出更好的程序去检索网页和内部信息，并把结果非常精炼地总结出来。
这段话在 OpenAI 的页面里是以转述形式出现、由 Johnny Ho 提出的观察。它其实揭示了一个很少被讨论的杠杆：对一个「答案引擎」来说，编程能力不是旁枝，而是决定检索质量的上游能力。搜索的本质是「写查询、取结果、合并、总结」这一串动作，而这串动作在智能体形态下就是代码——模型写代码的能力提升，直接转化为它对信息的调度能力提升。
核心动作：让模型顶替「不存在的那个服务」
这则案例里最具体、也最值得工程团队直接借鉴的，是 Ho 对测试的描述。原文的表述是：
“For Johnny, one of the most useful applications of AI is testing code. With limited time to test manually, he asks GPT-6 Astra to build a small testing program around an application.”
（译文）对 Johnny 而言，AI 最有用的应用之一就是测试代码。由于手动测试的时间有限，他让 GPT-6 Astra 围绕一个应用搭建一个小型测试程序。
接下来是这个方法真正的关键机制：
“The model generates realistic responses like those another service would send, for example, a language model API or a connector. By standing in for those services, the model can check how the application responds and test the workflow from start to finish.”
（译文）模型会生成逼真的响应，就像另一个服务会发回的那样——例如语言模型 API 或某个连接器。通过顶替这些服务的位置，模型可以检查应用如何响应，并从头到尾测试整个工作流。
这段话描述了三个层次的工作，价值依次递增。
第一层：写测试代码
这是最容易被理解和模仿的部分。模型围绕应用生成测试程序，这不是新能力——大部分 AI 编程工具都能做。但注意它的边界：模型写的不是「单元测试」这种局部验证，而是围绕应用的端到端测试。区别在于，单元测试验证「这个函数算对了吗」，端到端测试验证「整条流程跑通了吗」。后者需要理解系统各部分怎么衔接，难度高得多。
第二层：制造测试替身（mock / stub）
这是最有实操价值的一点，也是很多团队真正卡住的地方。原文里用的词是 “standing in for those services”——顶替那些服务的位置。
做过端到端测试的人都知道，最烦人的不是写断言，而是准备依赖：要测一个调用外部 LLM API 的流程，你得有个 API 能调；要测支付流程，你得有个沙箱能返回各种支付状态；要测连接器，你得先有那个连接器。这些依赖要么不存在（接口还没开发完），要么很难构造（真实服务不会按你需要的方式返回错误），要么有成本（每次调用都要花钱）。
结果就是：测试被无限期推迟。这在工程上是个非常普遍的死结——人人都知道该测，但准备成本太高，于是先「上线再说」。Ho 的做法是把这道坎直接填平：让模型生成那些服务的逼真响应，替代真实服务的位置。这样一来，流程的上下游都能被接上，端到端测试才真正可跑。
这个思路其实暗合了一个更本质的观察：模型最擅长的事情之一，就是生成「看起来像真的」的东西。过去我们用这个能力做内容创作，现在用它来做测试基础设施，本质上是在把「生成逼真数据」这个能力用在工程验证上。而且这里有一个自我强化的循环——模型对某个 API 的返回格式理解得越好，它生成的替身就越逼真，测试的有效性就越高。
第三层：判断结果对不对
最容易被忽略但最难的一层。端到端测试跑通了，但「跑通」不等于「正确」。模型不仅要能生成响应，还要能判断应用的响应是否合理。原文的表述是 “check how the application responds”——检查应用如何响应。
从「生成测试」到「执行测试」到「判断结果」，这三步合起来才构成一个完整的验证闭环。缺了最后一步，模型就只是帮你写了个脚本，判断权还在人手里，监督成本并没有真正下降。这也解释了为什么 Ho 敢说「检查频率低得多」——前提是判断动作也被部分交出去了。
背景：为什么「验证」成了新瓶颈
要理解这则案例为什么重要，需要先看清 2026 年 AI 软件工程的一个结构性变化：瓶颈从「写代码」转移到了「验证代码」。
这个转移的逻辑很直白。当模型的编码能力达到某个水平后，生成代码的成本急剧下降——一个功能点可以从「工程师写两天」变成「模型写五分钟加人改半小时」。但验证的成本并没有同步下降，因为验证的核心是「人得相信它是对的」，而信任的建立依赖于证据：测试通过、类型检查通过、集成测试通过、灰度观察无异常。
于是出现了一个反直觉的现象：代码产出增加，但团队并没有感觉更快，因为审查和验证的队列变长了。这跟工业革命早期的情形有点类似——纺纱机让纱线产量暴涨，结果瓶颈转移到了织布环节。
业界的应对方向很统一：让模型也参与验证。2026 年 9 月，Cognition 披露他们在 Devin 里用 GPT-6 Astra 测试软件，并产出「证据」——包括应用在模拟器里运行的录屏，以及哪些检查通过、哪些还没测的报告；客户发来 bug 截图后，团队把它交给 Devin，Devin 修好并返回一张显示修复效果的截图。Perplexity 的做法是同一方向上的另一个版本。Perplexity 的 CSO 在案例里把这个逻辑说得很清楚：他们做的是「验证工作是否被完成」，而不只是「生成代码」。
把这两家放在一起看，会发现一个共同的转变：从「模型生成代码」到「模型证明代码可用」。前者的交付物是代码，后者的交付物是证据。这个转变看起来只是产品话术的调整，但它决定了人的角色——如果交付物是代码，人必须读代码；如果交付物是证据，人可以看证据。而看证据比读代码快得多。
更深一层：让模型监控生产，意味着什么
Ho 的那句引语里，「monitor our production software」是比测试更容易被低估的一环。测试发生在部署前，监控发生在部署后——而部署后的世界，是输入分布漂移、依赖服务行为变化、真实流量触发边缘路径的世界。传统上，这个阶段靠的是可观测性体系：日志、指标、追踪、告警规则。
问题在于，告警规则是人写的。人能想到的异常形态，才会被写成告警；人想不到的，就静默通过。而模型在这方面有一个天然优势：它不需要预先枚举异常形态，只需理解「正常应该是什么样」，然后对偏离做出反应。这是一种基于语义的监控，而非基于阈值的监控。
但它同时带来了一个新问题：当模型负责监控，谁来监控模型？如果模型漏报了一个异常，或者误报了大量噪声，人怎么知道？这就是为什么 Ho 的表述里，人的角色变化是「检查频率下降」而不是「检查消失」。降低监督频率不等于取消监督——这个区别在工程上是生死线。
行业内的讨论与不同声音
质疑一：客户案例的可信度折扣
这则案例来自 OpenAI 的官方页面，是供应商讲述客户如何使用自家产品。这类材料的固有偏差是：容易成功、失败不提、指标模糊。Ho 说「检查频率低得多」，但没给数字——是降低 10% 还是 90%？在什么类型的任务上？哪些类型的变更仍然需要人工复核？这些细节决定了这个做法能不能被复制。
审慎的读法是：把这则案例当作方向性信号，而不是成熟方法论。它证明了「让模型负责验证」这条路径是有人跑通的，但没有证明它已经稳定可复制。
质疑二：「验证」本身能不能被信任
更技术性的反驳指向一个循环依赖：如果用模型来验证模型的产出，那么验证的有效性取决于验证者的能力，而验证者本身也是模型。同源错误（correlated failure）怎么办？如果验证模型和生成模型共享同一个盲点——比如都对某类边界条件不敏感——那么验证环节就形同虚设，但它会给人「已经验证过了」的安全感，这比没有验证更危险。
业界的常见缓解手段是异构验证：用不同厂商的模型交叉验证、用确定性工具（类型系统、静态分析、形式化验证）做互补、用真实流量做最终检验。但这则案例里没有提到 Perplexity 采用哪种策略——这是它作为方法论文档的明显缺口。
质疑三：人的判断力会不会退化
一个更长期的问题：如果监督频率持续下降，工程师对系统的直觉会不会钝化？等到真正需要人介入的复杂故障发生时，人还具备定位能力吗？这个问题在自动驾驶、航空自动化领域都有先例——自动化程度越高，人类操作员的「情境意识」越容易退化，而关键时刻恰恰依赖这种意识。
支持 Ho 这种做法的人会说：这是分工演进的正常结果，就像现代程序员不需要懂汇编也能写高质量软件。反对者则指出，AI 系统的失效模式比编译器复杂得多，且缺乏形式化保证，此时放弃人的直觉监督为时过早。这个争论没有定论，但值得每个采用这类流程的团队认真对待。
横向扩展：相关的工程概念与背景知识
测试替身的类型与选择
Ho 描述的做法，在软件工程里有成熟的术语体系，理解这些概念有助于把「让模型生成替身」这件事放回正确的位置：
- Stub（桩）：返回固定预设值，用于让代码能跑起来。最简单，也最不真实。
- Mock（模拟对象）：不仅能返回值，还能记录「被调用了没有、调用了几次、参数是什么」，用于验证交互行为。
- Fake（伪实现）：一个有简化逻辑但能工作的真实实现，例如内存数据库替代真实数据库。
- Service Virtualization（服务虚拟化）：模拟整个外部服务的完整行为，包括各种状态码、延迟、错误响应，是最接近 Ho 描述的那一层。
模型生成替身的价值，在于它可以把「服务虚拟化」这项原本需要专门工具和人工配置的工作自动化，而且能按自然语言描述的自定义场景生成响应——这在构造罕见错误路径时特别有用。
端到端测试与测试金字塔
经典的测试金字塔主张：底层单元测试多、中层集成测试适量、顶层端到端测试少。理由是端到端测试慢、脆、维护成本高。模型生成端到端测试的能力，可能会松动这个结构——当编写和维护成本大幅下降时，「少写端到端测试」这条经验的前提就变了。
不过要注意，端到端测试的另一个问题是不确定性：涉及多个服务和异步流程时，失败原因往往难以定位。让模型生成测试，并不会自动解决这个问题；它甚至可能放大问题——如果模型生成了大量不稳定的端到端测试，团队的 CI 会变得吵闹而无用。所以在实践中，「生成多少测试」和「生成什么粒度的测试」同样重要。
从「人在回路」到「人在回路之上」
自动化领域有个经典区分：human-in-the-loop（人在流程中）意味着每个关键决策都需要人确认；human-on-the-loop（人在流程之上）意味着人负责设定目标、监督整体、处理异常，但不介入每一步。Ho 描述的转变，正是从前者向后者的迁移。
这个迁移的可行性取决于三个条件：可观测性（人能随时看到系统在做什么）、可干预性（发现问题能立刻接管）、可回滚性（出错的后果可以被撤销）。三者缺一，降低监督频率就是鲁莽而非进步。这也是评估任何「AI 自动化」方案时最实用的检查清单——不要只问「模型做得对吗」，要问「做错了我能不能发现、能不能叫停、能不能撤回」。
为什么这件事对「答案引擎」特别重要
回到 Ho 关于编码能力与搜索质量的那段话。对 Perplexity 这类产品，模型写代码的能力是一条上游杠杆：检索需要构造查询、调用工具、合并多源结果、生成摘要，这些环节在智能体架构下都可以表达为程序。模型写程序的能力越强，它能构造的检索策略就越复杂、越贴合问题。
这解释了一个看似反直觉的现象：一家做搜索的公司，会如此重视 AI 的编码能力。在传统的搜索架构里，检索质量由索引和排序算法决定；在智能体化的架构里，检索质量还取决于「模型能不能写出恰当的程序去取回信息」。前者是系统工程问题，后者是模型能力问题——而后者的改进速度，目前远快于前者。
总结：可以从这则案例带走什么
抛开厂商宣传的成分，Ho 这套做法里有几个可以直接借鉴的工程判断：
第一，验证成本是被低估的真正瓶颈。如果你的团队已经能快速生成代码，但交付速度没有同比提升，瓶颈大概率在审查和验证环节，不在生成环节。
第二，测试基础设施的「准备成本」值得被优先解决。依赖不存在、难以构造、有调用成本——这三点是端到端测试最常见的死因。让模型生成逼真替身，是目前成本最低的解法之一。
第三，「检查频率下降」必须配套「可观测 / 可干预 / 可回滚」。这三个条件是降低监督的前提，不是降低监督的结果。顺序搞反了，省下的时间会用事故来偿还。
第四，把模型的编码能力当作上游杠杆来看。如果你的产品的核心链路里包含「构造查询、组合工具、合并结果」这类动作，那么模型写代码的能力提升会直接转化为产品能力提升——这条杠杆比单纯换更强的模型更值得投入。
至于「把端到端系统完全交给模型、大幅降低检查频率」这条路，能不能从个别团队的实践变成行业标准做法，还需要更多独立数据来判断。但方向已经足够清楚：在这个阶段，谁先解决验证问题，谁就能真正拿到 AI 编码的生产力。
参考来源
- OpenAI, “Perplexity trusts GPT-6 Astra with end-to-end systems”, 2026-09-14 — openai.com
- OpenAI Developers (@OpenAIDevs) 视频：Perplexity 用 GPT-6 Astra 端到端测试代码，2026-09-14
- METAL, “OpenAI Posts Video of Perplexity Testing Code With Astra” — metallab.ai
- OpenAI, “Cognition helps Devin test its own work with GPT-6 Astra”, 2026-09-11 — openai.com
- Fabio Pacifici, “AI Developer Digest — September 12, 2026” — fabiopacifici.com
