从快手生成式推荐到测试范式变革：推荐系统的终局，是测试系统的起点？

推荐系统花了近十年，从人工规则走到协同过滤，再走到深度学习，如今在快手等公司手里，正迈向「生成式统一模型」。

测试领域看起来完全是另一套东西：需求文档、测试用例、自动化脚本、缺陷报告。但如果我们退一步看，推荐系统和测试系统解决的其实是同一个元问题——

在有限资源下，如何把最合适的「内容」，在最合适的时机，送到最合适的「对象」面前。

推荐系统的对象是用户，内容是商品、视频或广告；测试系统的对象是被测软件，内容是验证行为、测试用例和策略。

这个同构关系意味着：推荐系统已经走过的路，很可能是测试系统接下来要走的路。

一、快手为什么要做生成式推荐

快手是国内最大的短视频平台之一，日活超过 4 亿。用户每刷一次视频，系统都要判断：下一条该推什么？搞笑、情感、美食、三农、直播、电商，还是本地内容？推荐系统是快手的命脉。

长期以来，快手和行业主流一样，采用多阶段级联链路：

这套架构成熟，但天花板很明显：

• 链路长：每一层目标不一致，各自训练和调参
• 模块割裂：召回觉得好的候选，精排可能全否掉；精排的结果，重排又打乱
• 反馈断裂：用户在重排阶段的行为，很难回传到召回阶段优化
• 算力浪费：每一级都跑完整推理，但大部分结果被丢弃
• AI 大模型能力难融入：没有一个环节能「看到全貌」

快手推荐大模型资深算法专家王诗瑶在 2025 年的一次技术分享中指出：大模型的兴起，让推荐系统从传统的判别式范式迈向生成式范式，为突破传统推荐的智能天花板提供了可能。

核心变化在于——不再从候选池中筛选，而是直接生成推荐结果。

二、OneRec 改变了什么

OneRec 不是论文概念，而是快手在短视频主推荐场景里实际部署的工业级系统。

传统推荐是：给一堆候选视频，逐个打分，排出顺序，选出前几个。OneRec 是：根据用户历史行为，直接生成「下一组应该看什么」。

对测试人员来说，不需要理解 OneRec 的内部细节，关键是抓住它的核心思想：把多个割裂的环节，统一成一个可反馈、可优化、可生成的系统。

它的线上数据也很真实：部署在快手和快手极速版，处理约 25% 的总 QPS；App Stay Time 提升分别达到 +0.54% 和 +1.24%；运行成本约为传统推荐流水线的 10.6%。

OneRec-V2 又进一步把成本压了下来。这恰好对应测试领域的一个现实挑战：生成式测试要能嵌入 CI/CD 流水线，成本必须可控。

在 OneRec 之后，快手把同一套思路扩展到了更多场景：

• OneLive：直播场景的动态统一生成式推荐框架，解决直播内容生命周期短、实时性要求高的挑战
• GR4AD：广告场景的生成式推荐系统，在表示层、学习层、服务层联合优化，实现广告收入提升 4.2%，服务 4 亿+用户
• Align3GR：LLM 驱动的多级对齐框架，构建「懂→会→契合」的对齐体系，发表于 AAAI 2026

三、推荐与测试的范式对照

传统测试系统的困境，和快手 OneRec 要解决的传统推荐困境，高度同构。

四、六个可以迁移到测试领域的理念

理念 1：统一生成式架构

推荐侧：用一个模型替代召回→粗排→精排→重排的多级漏斗。

测试侧映射：传统测试流水线中，需求分析、用例编写、环境准备、执行、结果分析、缺陷报告，每个环节由不同角色和工具完成，信息在传递中大量损耗。生成式测试的愿景是：需求输入一个统一模型，直接输出测试策略、用例、执行结果和分析报告。

测试领域长期存在「工具碎片化」问题——需求管理用 Jira，用例管理用 TestRail，自动化用 Selenium 或 Playwright，CI 用 Jenkins，报告用 Allure。生成式推荐的经验是：当一个系统被拆成太多独立模块时，统一端到端模型才是突破口。

理念 2：Token 化一切

推荐侧：将用户、广告、上下文统一编码为 token 序列，在同一语义空间中建模。

测试侧映射：测试世界的一切都可以 token 化。

• 用户行为序列 → 用户真实操作路径（注册→浏览→加购→下单→支付→退款）
• 广告素材特征 → 被测功能的接口、页面、状态
• 上下文信息 → 测试环境、配置、数据快照
• 历史交互记录 → 历史缺陷、测试结果

如果测试用例、缺陷、代码变更、用户行为都能被编码到同一个向量空间，就能实现：新需求和历史上哪个缺陷最相似？哪类用户操作路径最容易出 bug？这段代码变更最该回归哪些用例？

理念 3：懂→会→契合的多级对齐

推荐侧：理解用户偏好 → 掌握推荐策略 → 对齐商业目标。

测试侧映射：

• 懂：理解需求文档的业务意图、代码变更的影响范围、用户实际使用模式
• 会：掌握测试设计方法论、自动化框架、不同质量维度的覆盖策略
• 契合：测试资源跟着风险走。每个需求都覆盖，但覆盖深度由风险决定，而不是均匀撒网；测试节奏跟发布节奏对齐，测试结果跟用户感知对齐

当前测试领域最大的问题之一是「测了很多但没测到点上」。Align3GR 的启发是：光懂测试技术不够，还要契合业务目标。

理念 4：生成而非筛选

推荐侧：传统推荐从候选池中选，生成式推荐直接创造。

测试侧映射：

这不仅仅是「AI 辅助写测试用例」。真正的生成式测试是：给定当前的需求、代码变更、用户行为数据和历史缺陷，系统能生成一整套测试策略，而不只是填充用例模板。

理念 5：实时动态适应

推荐侧：直播内容动态演化，推荐系统需要实时感知变化并调整。

测试侧映射：

• 代码变了 → 自动生成或更新受影响的回归用例，而非跑全量回归
• 用户行为模式变了 → 自动调整测试场景优先级
• 线上缺陷暴露了新风险 → 自动将该场景加入测试覆盖
• 环境变了 → 自动适配测试配置

当前测试系统大多是「静态」的——用例写好就不怎么变。OneLive 的启示是，测试系统应该像推荐系统一样，持续感知上下文变化，动态调整「推」什么测试。

理念 6：大规模落地的工程思维

推荐侧：学术界讨论生成式推荐很多，但快手是第一个在 4 亿用户规模全量落地的。关键是在表示层、学习层、服务层三个维度联合优化。

测试侧映射：生成式测试要真正落地，也必须在三个层面同时突破。

• 表示层：需求、代码、用例的统一编码
• 学习层：从历史测试数据中学习质量模式
• 服务层：保证生成速度跟上 CI/CD 节奏

很多人尝试用 LLM 生成测试用例，但停留在「玩具阶段」。GR4AD 的教训是：生成式技术的价值不在 Demo，在于能否嵌入生产流水线。

五、一条核心链路：需求感知 → 策略生成 → 场景演进 → 测试推荐

以上六个理念可以提炼为一条完整的生成式测试链路：

• 需求感知：理解需求文档、代码变更、用户行为和历史缺陷的业务意图，而非停留在关键词匹配
• 策略生成：基于感知到的语义和模式，生成之前不存在的测试策略、用例、数据和脚本
• 场景演进：随着需求变更、代码迭代、线上反馈持续演化测试覆盖，而非写好就不变
• 测试推荐：在所有可用测试点中，根据当前上下文决定本次执行哪些、先跑哪些、每个花多少精力

这条链路的本质，是把推荐系统「理解用户→生成内容→实时调整→精准分发」的逻辑，完整迁移到测试领域。

六、架构设想：测试领域的系统族

借鉴快手的系统族思路，测试领域可以这样构建：

统一理解层（类似 Align3GR）：将需求文档、代码变更、用户行为、历史缺陷统一编码，进行风险评估和优先级排序。

生成式测试引擎（类似 OneRec）：端到端生成测试策略、用例、数据、脚本和预期结果，替代传统的人工设计→人工编写→人工评审流程。

场景化子系统：

• OneTest：功能和接口测试，类似内容推荐
• OneLive：线上实时巡检和混沌测试，类似直播推荐的动态适应
• GR4Test：专项性能和安全测试，类似广告推荐
• Align3Test：测试资源与业务风险的对齐，测试投入 ROI 优化

七、三个最根本的思维转变

快手生成式推荐给测试领域最根本的启发，不是「用 AI 写测试」，而是三个思维转变：

从筛选到生成——不要再问「现有用例够不够」，要问「能不能根据当前上下文直接生成最合适的测试」。

从级联到统一——不要再优化单个环节，要思考端到端的统一模型。

从静态到动态——测试系统不应该写好就不变，应该像推荐系统一样持续感知、持续适应、持续进化。

八、落地中的关键问题与解法

问题 1：反馈闭环怎么建？

推荐系统有明确的反馈信号——完播率、点赞、划走、停留时长。测试领域的等价物是什么？

注意：回归用例持续通过本身是有价值的，不能用「没发现缺陷」来衡量回归用例的好坏。上述指标只适用于生成式系统新生成的用例。

问题 2：新项目没有历史数据怎么办？

推荐系统有冷启动问题，测试领域也有。解法和推荐系统一样——用内容特征替代行为特征。

• 语义迁移：新项目的需求文档、接口定义、业务流程本身就是特征
• 跨项目迁移：把相似模块的缺陷模式迁移过来
• 快速积累：前几轮执行结果就是第一批反馈数据，系统可以在 2-3 个迭代内从「语义驱动」切换到「语义+数据混合驱动」

问题 3：生成的测试不对怎么办？

推荐错了，用户划走就行，代价很低。测试用例生成错了，可能漏掉严重缺陷，代价很高。

需要三层防护：

• 生成层约束：生成的每条用例必须关联到具体需求条目、接口、页面元素
• 验证层校验：执行前先做静态校验——接口是否存在、页面元素是否匹配、测试数据是否合法
• 执行层兜底：用例执行结果是最终验证。如果一条生成的用例在多次迭代中从未发现缺陷，而不是作为回归用例持续通过，系统应降低同类策略的推荐权重

问题 4：人在这个系统里扮演什么角色？

推荐系统是全自动的，模型生成推荐，用户直接看。测试领域现阶段做不到完全自动。

合理分工是：机器负责规模化生成，人负责方向把控和例外处理。

问题 5：一个具体场景长什么样？

以「用户登录功能」为例：

需求感知阶段：输入需求文档「用户通过手机号+验证码登录，支持密码登录作为备选，连续输错 5 次锁定 30 分钟」。系统解析出核心实体、业务规则、关联模块。

策略生成阶段：系统自动生成测试策略——

• 正向场景：正确手机号+正确验证码登录成功
• 反向场景：错误验证码、过期验证码、已锁定账号尝试登录
• 边界场景：第 4 次输错 vs 第 5 次输错、锁定 29 分钟 vs 30 分钟
• 安全场景：验证码暴力枚举、SQL 注入、会话劫持
• 性能场景：高并发登录、短信接口超时

场景演进阶段：发现「锁定 30 分钟后重新计数没有重置」的缺陷，系统将「锁定机制的状态重置」标记为高风险模式，后续类似功能自动关联。

测试推荐阶段：下一个迭代新增微信登录，系统推荐：微信登录的正反向用例 + 上次发现的锁定机制相关用例 + 回归核心登录流程，不推荐与本次改动无关的安全场景，节省资源。

问题 6：现在能做什么？

不需要等一个完美的生成式测试系统出现，现在就可以起步：

• 建立缺陷知识库：把历史缺陷按模块、类型、根因分类存储
• 用 LLM 辅助生成用例初稿：把需求文档喂给大模型，人工评审修改，积累映射数据
• 做测试数据的结构化：记录用例、缺陷、代码变更的关联关系
• 从一个模块试点：跑通「需求→生成→执行→反馈→优化」的完整闭环

写在最后

推荐系统花了十年，从人工规则走到协同过滤，从深度学习走到生成式统一模型。每一次范式跃迁，都带来了数量级的效率提升。

测试领域正站在类似的时间节点上。当前的测试系统，本质上还停留在「人工规则+工具辅助」的阶段，和十年前的推荐系统类似。生成式推荐已经验证的范式突破——统一架构、token 化表示、语义理解、动态适应——大概率可以在测试领域复现。

但也要坦诚：这条路目前没有人真正走通。快手有 4 亿用户每天产生海量行为数据作为训练燃料，测试领域没有这样的数据规模。一个项目积累的缺陷数据可能只有几千条，和推荐系统的百亿级交互记录完全不在一个量级。这是最大的挑战。

不过推荐系统也是从少量数据起步的。测试领域可以分两步走：第一步，用 LLM 的语义理解能力解决冷启动问题；第二步，从每次执行结果中积累反馈数据，逐步建立「需求→用例→缺陷」的关联图谱，让系统从「语义驱动」进化到「数据+语义混合驱动」。

关键不是等条件成熟，而是现在就开始积累。每一次需求分析、每一条缺陷记录、每一次用例执行的结果，都是未来生成式测试系统的训练数据。今天不开始，明天就没有数据可用。

问题不是「会不会发生」，而是「谁先开始积累」。

本文是"肖恩的博客"系列文章之一，首发于 seanwalter.top。作者是一名从软件测试转型AI领域的开发者，记录在转型过程中的真实思考。