大模型的“推理能力”能让机器具备与人类相似的认知和行为能力，能像人一样理解、思考、学习并解决复杂问题。而在众多推理能力评测场景中，数学推理任务是当前衡量和追踪模型推理能力进展的 “黄金标尺”。与此同时，主流数学推理评测体系正面临关键瓶颈：部分顶尖模型在常用的数学推理评测任务中，如 AIME24/25 的正确率已突破 90%，评测区分度大幅下降，难以再有效牵引模型向更高阶推理能力进化；此外，现有基准大多源于公开竞赛题库，存在数据穿越风险。

在此背景下，美团 LongCat 团队发布数学推理评测基准—— AMO-Bench 。该评测集共包含 50 道竞赛专家原创试题， 所有题目均对标甚至超越 IMO 竞赛难度。目前，头部大模型在 AMO-Bench 上的最好表现也尚未及格，SOTA 性能仅为 52.4%，绝大多数模型正确率低于 40%。AMO-Bench 既揭示出当前大语言模型在处理复杂推理任务上的局限性，同时也为模型推理能力的进一步提升树立了新的的标杆。

AMO-Bench 的评测榜单将保持更新，欢迎持续关注：

• 项目主页：http://amo-bench.github.io/
• Github 地址：https://github.com/meituan-longcat/AMO-Bench
• Hugging Face 地址：https://huggingface.co/datasets/meituan-longcat/AMO-Bench

一、评测现状：老题库 “失效”，行业亟需高难度原创基准

现有数学评测 benchmark 因出现严重的性能饱和问题，已无法有效指引头部大语言模型推理能力的进一步提升。一方面，随着 AIME、HMMT 等竞赛题库的公开，模型有可能通过训练数据 “背诵答案”，成绩可信度存疑；另一方面，随着模型的快速迭代升级，现有评测榜单上头部模型的得分趋同，因此逐渐失去鉴别模型能力差异的价值。为进一步提升评测集的难度，已有工作考虑直接使用 IMO 等等有挑战性的竞赛原题对模型进行评测。然而，现有 IMO 题目仍以证明题为主，极度依赖人工批改模型的复杂证明过程，单题批改需 30 分钟以上，评测效率低下且易受主观因素影响。

当前行业迫切需要一套 “高难度 + 原创 + 可自动化” 的评测方案。在这一背景下，AMO-Bench 的推出直击行业痛点—— 50 道竞赛专家原创题目、对标甚至超越 IMO 的试题难度、配套高效高准确率的自动化打分算法，为大模型推理能力评测提供了可落地的新标杆。

二、AMO-Bench：高难度数学推理评测的 “行业新标杆”

AMO-Bench 拥有一套系统化的数据构建逻辑、清晰的数据难度特征与针对性的模型打分算法，为行业提供了一套可信赖且置信的评测方案。

2.1 AMO-Bench 的构建

为打造兼具高质量、强原创性与高挑战性的数据集，LongCat 团队构建了一套 “数据创建 - 质量审查 - 原创性审查 - 难度审查” 全链路流程。

数据创建：专家原创，自带 “解题说明书”

• 题目由具备数学奥林匹克竞赛获奖经历或相关竞赛出题经验的顶尖专家独立设计，每道试题不仅提供最终答案，还详细撰写了 step-by-step 解题路径 —— 从关键定理应用到逻辑推导节点，每一步都清晰标注，既为后续审查提供依据，也为模型错误分析预留 “参考坐标”。

质量审查：三重盲审，杜绝 “题不对标”

• 每道题需经 3 位以上专家 “盲审”质检，重点核查两大核心：一是题目表述与解题逻辑是否无歧义，避免因题干模糊导致的模型误判；二是所需数学知识是否严格匹配数学奥赛考察的知识范围（如代数、几何、数论等核心领域），确保不超纲、不偏题，真正考验模型的推理能力。

原创性审查：题库匹配 + 人工核验，切断 “数据穿越”

• 采用 “技术核验 + 专家经验” 双重保障：通过 n-gram 文本匹配与互联网检索等方式，与 AIME24/25 等主流竞赛数据集和在线数据库进行比对，排除与现有数据资源中高度相似的题目；同时依靠专家经验进行人工核验，确保与过往竞赛题无高度重合，杜绝模型 “背答案” 的可能。

难度审查：双标筛选，确保 “够硬核”

• 采用双重难度筛选标准来保证每一道题目都具备足够挑战性：首先使用国内外最顶尖模型进行筛选，要求至少 2 款模型在 3 次独立测试中无法全部答对；其次候选题目需要经过第三方专家进行二次审核题目难度，确保题目难度不低于 IMO 标准。

2.2 数据集：覆盖核心领域，推理复杂度显著升级

AMO-Bench 的 50 道题目覆盖数学奥赛核心领域，且从解题复杂度上实现对现有基准的全面超越。

题目分类：覆盖五大核心领域

参照国际数学竞赛官方竞赛大纲，题目被划分为五大类：代数方程与不等式（11 题，占比 22%）、函数与数列（13 题，占比 26%）、几何（5 题，占比 10%）、数论（9 题，占比 18%）、组合数学（12 题，占比 24%），覆盖数学奥赛核心知识点，考察模型在不同领域是否存在能力短板。

解题复杂度：答案长度远超传统基准

通过对比大模型在 AMO-Bench 和现有数学评测集上的输出长度，可以看到，随着数据集难度的提升，模型表现在逐渐走低的同时，其输出 token 数量也会大幅增加。

大模型在 AMO-Bench 上的解题步骤长度显著长于现有 AIME/HMMT 等评测集，这意味着 AMO-Bench 的题目需要模型构建更长、更复杂的逻辑链才能解答，本质上更具挑战性，能更精准地检验大模型的深度数学推理能力。

2.3 评分方法：兼顾 “自动化” 与 “准确性”

AMO-Bench 的问题答案类型可以概括为四种类型，为兼顾打分准确率和打分效率，我们针对不同的答案类型匹配相应的评分方式：

1. 数值 / 集合 / 变量表达式类（39 题）：采用 “parser-based 自动评分”，要求模型将答案按指定格式（答案）输出，使用 Math-Verify 工具核验模型结果与标准答案的等价性；

2. 描述性答案（11 题）：采用 “LLM 评分 + Majority Voting”，在实验中使用了 o4-mini（Low）为评分模型，对同一答案进行 5 次独立评分采样，取多数结果作为最终得分，以减小打分模型采样的波动性。

为了验证打分方案的准确率，我们随机抽取了 10 款不同模型生成的 1000 组答案打分结果进行人工检查，结果显示 AMO-Bench 的评分方案准确率高达 99.2%，为大规模自动化评测提供了坚实保障。

三、实验与分析：AMO-Bench 揭示大模型数学推理的能力边界

为全面揭示当前大模型数学推理的能力边界，LongCat 团队分别从 “开源 / 闭源”和“推理 / 非推理” 两方面共筛选了 26 个头部大语言模型，真实的反应了当前主流模型在数学推理能力上的实际表现。

3.1 整体能力格局：顶尖模型仍 “不及格”，能力梯度差异显著

从核心指标来看，当前大部分大模型在 AMO-Bench 上的表现远未达及格水平，且不同类型模型间呈现明显能力分层：

• 闭源推理模型领跑，仍有巨大提升空间：表现最优的 GPT-5-Thinking（High）正确率仅 52.4%，且大部分模型表现低于 40%，即便头部闭源模型，也未突破 “及格线”，凸显 IMO 级难度的原创题对当前 AI 的挑战性；
• 开源模型仍有差距，但已在全力追赶：开源模型中 Qwen3-235B-A22B-Thinking-2507 正确率为 47.8%，DeepSeek-V3.1-Thinking 为 47.6%，距离最好表现的 GPT-5 仍有一定差距，但已明显超越 o4-mini 和 Gemini-2.5-Pro，展示出开源模型奋起直追的势头。

3.2 推理效率关联：Test-Time Scaling 效果显著

通过分析模型在 AMO-Bench 上输出长度与模型表现的关系，LongCat 团队指出，当前 test-time scaling 仍然是提升模型推理表现的有效手段。

• 高得分模型依赖更多 token 输出：AVG@32 超 40% 的模型（如 GPT-5-Thinking、DeepSeek-V3.1-Thinking），平均输出 token 量均超 35K，意味着当前的头部推理模型能通过构建显著更长的逻辑链来达到更好的解题表现。
• 同系列模型迭代体现效率提升：以 o 系列模型为例，o4-mini（High）在相近 token 量下，正确率（40.2%）显著高于 o3-mini（High）（32.3%）；DeepSeek-V3.1-Thinking 较前代 DeepSeek-R1-0528，则进一步用更少 token（32K vs 38K）实现了更高正确率（47.6% vs 34.3%），证明新一代模型可以用更高的效率获取更强的推理性能。

• 推理投入与得分呈对数线性增长：同一模型正确率与输出长度对数呈近线性正相关，且这一趋势与现有工作在 MATH500、AIME24 等基准上的实验观察一致，证明增加推理计算投入仍是提升模型解决复杂任务能力的有效路径。

3.3 潜在能力挖掘：模型多次尝试下的探索潜力

通过进一步分析模型的 “Pass@k” 表现（k 次尝试至少答对 1 次），LongCat 团队指出，前沿推理模型如 GPT-5-Thinking（High）、DeepSeek-V3.1-Thinking 等在 AMO-Bench 上能达到 Pass@32 超 70%，表明当前大模型暗含解决难题的潜力，其性能仍有巨大提升空间。

四、总结与展望

综上，AMO-Bench 相比 AIME24/25 等主流数学评测集具备了更好的区分度和模型提升空间，同时通过 IMO 级别的原创题解决了因数据泄露的潜在风险造成的评估失真问题，以及凭借 99.2% 的高打分准确率保证了自动化评测的准确性。未来，美团 LongCat 团队将持续更新 AMO-Bench 评测集，扩大题目覆盖类型与优化评测方案，同时会进一步探索包括通用和学科推理在内的高难度评测集建设，助力业界大模型在推理能力上的持续提升。

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

随着 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 解锁图片创作的无限可能～