OpenSWE147 万美元打造最大开源 SWE 训练环境45k Docker 环境助力代码 Agent 登顶 SWE-bench一句话总结GAIR-NLP 团队斥资 147 万美元构建了 OpenSWE——迄今最大的开源软件工程智能体训练框架包含 45,320 个可执行 Docker 环境、覆盖 1.28 万个代码仓库全部基础设施完全开源。基于此训练的 OpenSWE-72B 在 SWE-bench Verified 上达到 66.0%刷新了 Qwen2.5 系列的 SOTA 记录。 论文信息标题daVinci-Env: Open SWE Environment Synthesis at Scale作者Dayuan Fu, Shenyu Wu, Yunze Wu, Zerui Peng, Yaxing Huang, Jie Sun, Ji Zeng, Mohan Jiang, Lin Zhang, Yukun Li, Jiarui Hu, Liming Liu, Jinlong Hou, Pengfei Liu共 14 人机构GAIR-NLP发布日期2026年3月13日v12026年3月16日v2开源资源 项目主页GitHub - GAIR-NLP/OpenSWE 147 万美元的疯狂为什么要花这么多钱造数据在代码智能体领域有一个残酷的现实数据是最贵的资产。想象一下训练一个能修 Bug 的 AI Agent。它不仅要能读懂代码还要能理解 issue 描述定位问题代码编写修复补丁确保测试通过这意味着训练数据不能是静态的输入-输出对而必须是可执行、可验证的完整环境——Agent 写完代码后能真正跑一遍测试知道自己改对了没有。问题是这种环境从哪来看看现有的开源数据集数据集任务数仓库数问题SWE-bench2,29412仓库太少容易过拟合SWE-rebench~19k~1k规模有限OpenSWE45,32012,800✅ 最大规模工业界当然有更多数据比如 OpenAI、Anthropic 内部肯定有海量代码修复轨迹但他们不会公开。结果就是学术界想训练一个像样的代码 Agent连数据都找不到。OpenSWE 的目标很简单用钱砸出一个学术界能用的大规模 SWE 训练环境然后全部开源。图1OpenSWE 的完整流水线——从 GitHub PR 收集到环境构建、质量过滤、轨迹采样最终产出高质量训练数据 SWE-bench 是什么为什么它这么重要在聊 OpenSWE 之前得先说说它的考场——SWE-bench。2024 年 8 月OpenAI 发布了 SWE-bench Verified这是软件工程智能体领域最权威的基准测试。它的任务设定是输入一个代码仓库 一个 issue 描述比如某个函数在处理空列表时会报错输出一个能修复这个 issue 的代码补丁验证运行仓库的测试套件看补丁是否真的修复了问题这个任务难在哪仓库很大动辄几十万行代码Agent 要在茫茫代码海中定位问题上下文很长理解一个 Bug 可能需要读懂多个文件、多个类的交互验证很严格不是看起来对就行必须通过真实的测试用例到了 2026 年前沿模型在 SWE-bench Verified 上的分数已经突破 60%。OpenSWE 训练的模型拿到了66.0%这是什么概念每 3 个真实世界的 BugAI 能独立修好 2 个。 核心挑战为什么造 SWE 环境这么难表面上看造 SWE 训练数据不就是找一堆 GitHub PR然后把它们包装成 Docker 环境吗实际上这里面坑多到你怀疑人生。坑1依赖地狱每个 Python 项目都有自己的依赖环境。你可能遇到这个库需要 Python 3.7那个库需要 3.10某个依赖的某个版本已经从 PyPI 下架了两个依赖互相冲突让 AI 自动写 Dockerfile 来配置这些环境99% 的情况会失败。坑2测试不靠谱GitHub PR 里自带的测试可能太脆弱换个环境就挂测试覆盖不全修补丁通过了但实际上没改对依赖外部服务比如数据库、API在 Docker 里跑不起来坑3Issue-PR 不对齐很多 PR 的 issue 描述写得很模糊比如修复了一些问题。这种数据拿来训练 Agent它学到的是什么学到了如何胡说八道。坑4难度不可控有些 Bug 一眼就能看出来怎么改太简单没学习价值有些 Bug 即使给人类专家也改不出来太难Agent 根本学不会。OpenSWE 的贡献就是系统性地解决了这些问题并把整个流水线开源出来。 方法详解多智能体合成流水线OpenSWE 的核心是一套部署在 64 节点集群上的多智能体合成流水线。每一步都有专门的 Agent 负责Step 1PR 收集与过滤从 GitHub 收集 Python 仓库的 Pull Request然后四阶段过滤阶段过滤条件目的仓库可行性Stars ≥ 5过滤掉低质量玩具项目语言过滤主语言为 Python聚焦 Python 生态Issue 要求PR 必须关联有具体描述的 issue确保有清晰的任务定义实质性更改排除仅改测试的 PR确保测试的是真实能力Step 2仓库探索 Agent在写 Dockerfile 之前需要先了解仓库的结构。探索 Agent 会浏览 README 和配置文件搜索与环境配置相关的文档总结安装和测试命令这就像让 Agent 先预习一遍仓库知道它大概长什么样。Step 3Dockerfile 构建 Agent这是最难的一步。为了提高成功率OpenSWE 做了几个工程优化基础镜像预构建提前构建了覆盖 Python 2.7 到 3.14 的openswe-python基础镜像避免每次都从头装 Python。本地仓库缓存用COPY命令注入代码而不是git clone绕过 GitHub API 限制。分层感知提示指导 Agent 把稳定的底层比如系统依赖放前面变化频繁的层比如项目代码放后面利用 Docker 层缓存加速重建。一个典型的 Dockerfile 生成过程Agent 输入仓库结构 README requirements.txt setup.py Agent 输出完整的 Dockerfile Agent 思考过程 1. 这个项目需要 Python 3.9用 openswe-python:3.9 基础镜像 2. 发现 requirements.txt 里有 torch需要安装 CUDA 依赖 3. setup.py 里有 C 扩展需要装 gcc 4. 生成 Dockerfile...Step 4评估脚本构建 Agent有了 Docker 环境还需要知道怎么跑测试。评估脚本 Agent 负责定位与 issue 相关的测试文件生成运行测试的 bash 脚本如果原 PR 没有测试还要合成新的测试用例Step 5环境验证用一个简单但有效的规则验证环境是否可用1. 应用仅测试补丁只包含测试代码的改动→ 测试应该失败 2. 应用完整补丁包含修复代码→ 测试应该通过 只有两个条件都满足才接受这个环境这个验证逻辑确保了环境确实能复现 Bug且修复确实能解决 Bug。Step 6测试分析 Agent对于验证失败的环境分析 Agent 会诊断原因Dockerfile 配置错误→ 反馈给 Dockerfile Agent 重试评估脚本有 Bug→ 反馈给脚本 Agent 修改环境本身不可解→ 标记并丢弃这个闭环迭代让成功率从第一轮的不到 10% 提升到了最终的 ~20%。图2多智能体协作的环境构建流水线——仓库探索、Dockerfile 构建、评估脚本生成、测试分析形成闭环迭代 质量控制难度感知的过滤流水线有了 45k 个可执行环境还不够还要确保这些环境的训练价值。OpenSWE 用一个简单但有效的方法来评估难度让模型尝试解决看成功率。用 GLM-4.7 模型在每个环境上跑 4 次4 次全失败太难了Agent 学不会 → 丢弃4 次全成功太简单了没学习价值 → 丢弃1-3 次成功难度适中保留最终从 ~45k 环境中筛选出约 9,000 个高质量环境生成约 13,000 条训练轨迹。 实验结果登顶 SWE-bench主要结果模型参数量SWE-bench VerifiedQwen2.5-Coder-Instruct32B41.2%SWE-Master32B57.8%daVinci-Dev32B55.3%OpenSWE32B62.4%daVinci-Dev72B58.5%OpenSWE72B66.0%OpenSWE-32B 比同规模的 SWE-Master 高出 4.6%OpenSWE-72B 比 daVinci-Dev-72B 高出 7.5%。数据扩展分析一个有趣的发现是训练数据越多效果越好而且还没有饱和。论文画出了 Pass1 随训练步数的变化曲线发现是近似对数线性的增长y a ⋅ log ( x ) b y a \cdot \log(x) bya⋅log(x)b相关系数高达 0.99。这意味着什么如果继续扩展 OpenSWE 的规模模型效果还会继续提升。图3Pass1 随训练步数呈对数线性增长且未观察到饱和迹象——继续扩展数据集将带来额外收益跨域迁移能力最让我惊讶的是在 SWE 数据上训练数学能力也提升了。基准Qwen2.5-72B-BaseOpenSWE-72B提升GSM8K86.394.58.2MATH-50073.485.612.2HumanEval51.882.931.1这说明什么代码调试能力和推理能力是相通的。训练 Agent 修 Bug 的过程实际上也在训练它的逻辑推理、多步规划、错误诊断等通用能力。 成本分析钱都花在哪了OpenSWE 项目总投资约 147 万美元具体分布阶段成本说明环境构建$891,000LLM API 调用探索、Dockerfile、脚本生成轨迹采样$376,000让模型尝试解决每个环境难度过滤$200,000多次采样评估难度总计~$1,470,000平均每个可执行环境的构建成本约 $19.66。这个成本高吗从学术界的角度看确实不低。但从工业界的角度看这是在打基础——有了这套开源的基础设施后续扩展的边际成本会大幅下降。 我的观点与启发1. 数据工程的胜利这篇论文再次证明了在 Agent 训练中数据工程的重要性不亚于算法创新。OpenSWE 没有提出什么花哨的新算法它做的就是把 PR 收集流程标准化把 Dockerfile 生成自动化把质量过滤系统化然后用钱和算力把规模堆上去。结果呢直接登顶。2. 多智能体协作的范式OpenSWE 的流水线是一个很好的多智能体协作案例探索 Agent 负责侦察Dockerfile Agent 负责搭环境脚本 Agent 负责写测试分析 Agent 负责诊断问题每个 Agent 只做一件事但组合起来能完成复杂任务。这种分工协作的模式在其他领域也可以借鉴。3. 开源的价值最让我感动的是OpenSWE 把所有东西都开源了。不只是模型权重而是45k 个 Docker 环境所有 Dockerfile评估脚本分布式构建基础设施这意味着其他团队不需要再花 147 万美元从头造一遍。学术界真正能在这个基础上继续往前走。4. 一些疑问Q1训练数据和测试数据有重叠吗OpenSWE 用的是 GitHub PRSWE-bench Verified 也是从 GitHub 来的。虽然论文说做了去重但具体怎么去的如果训练数据里有和测试集高度相似的样本模型可能只是在背答案。Q2147 万美元的可复现性虽然代码开源了但如果我想复现整个流程还是要花 147 万美元吗有没有更经济的方案Q3仓库分布的偏差12.8k 仓库看起来很多但热门仓库比如 Django、Flask的样本肯定比冷门仓库多。这种分布偏差会不会导致模型在冷门项目上效果变差图4OpenSWE 与其他数据集的规模对比——在任务数和仓库覆盖率上都远超现有开源数据集 与其他工作的对比项目任务数仓库数开源程度SWE-bench VerifiedSWE-bench2.3k12数据开源-SWE-rebench~19k~1k数据开源~55%daVinci-Dev??仅模型58.5%72BOpenSWE45.3k12.8k全开源66.0%72BOpenSWE 在规模、开源程度、模型效果三个维度上都是最强的。 总结OpenSWE 这篇论文的贡献可以总结为三点规模突破构建了迄今最大的开源 SWE 训练环境45k 任务、12.8k 仓库比现有数据集大一个数量级全栈开源不只是模型权重而是把整个构建流水线、Docker 环境、评估脚本全部开源真正做到可复现效果验证OpenSWE-72B 在 SWE-bench Verified 上达到 66.0%刷新了 Qwen2.5 系列的 SOTA且展现出强劲的跨域迁移能力对于想做代码 Agent 的团队OpenSWE 提供了一个非常好的起点。对于关心 AI 发展的读者这篇论文揭示了一个重要趋势在 Agent 训练中可执行、可验证的环境数据比静态的 QA 对有价值得多。至于 147 万美元的投资值不值我觉得值。因为这不是一次性消费而是为整个开源社区建设基础设施。 参考文献OpenSWE GitHub: https://github.com/GAIR-NLP/OpenSWESWE-bench: https://swebench.comSWE-bench Verified: https://openai.com/research/swe-bench-verified觉得有启发的话欢迎点赞、在看、转发。跟进最新AI前沿关注我的微信公众号机器懂语言 OpenSWE：147 万美元打造最大开源 SWE 训练环境，45k Docker 环境助力代码 Agent 登顶 SWE-bench
OpenSWE147 万美元打造最大开源 SWE 训练环境45k Docker 环境助力代码 Agent 登顶 SWE-bench一句话总结GAIR-NLP 团队斥资 147 万美元构建了 OpenSWE——迄今最大的开源软件工程智能体训练框架包含 45,320 个可执行 Docker 环境、覆盖 1.28 万个代码仓库全部基础设施完全开源。基于此训练的 OpenSWE-72B 在 SWE-bench Verified 上达到 66.0%刷新了 Qwen2.5 系列的 SOTA 记录。 论文信息标题daVinci-Env: Open SWE Environment Synthesis at Scale作者Dayuan Fu, Shenyu Wu, Yunze Wu, Zerui Peng, Yaxing Huang, Jie Sun, Ji Zeng, Mohan Jiang, Lin Zhang, Yukun Li, Jiarui Hu, Liming Liu, Jinlong Hou, Pengfei Liu共 14 人机构GAIR-NLP发布日期2026年3月13日v12026年3月16日v2开源资源 项目主页GitHub - GAIR-NLP/OpenSWE 147 万美元的疯狂为什么要花这么多钱造数据在代码智能体领域有一个残酷的现实数据是最贵的资产。想象一下训练一个能修 Bug 的 AI Agent。它不仅要能读懂代码还要能理解 issue 描述定位问题代码编写修复补丁确保测试通过这意味着训练数据不能是静态的输入-输出对而必须是可执行、可验证的完整环境——Agent 写完代码后能真正跑一遍测试知道自己改对了没有。问题是这种环境从哪来看看现有的开源数据集数据集任务数仓库数问题SWE-bench2,29412仓库太少容易过拟合SWE-rebench~19k~1k规模有限OpenSWE45,32012,800✅ 最大规模工业界当然有更多数据比如 OpenAI、Anthropic 内部肯定有海量代码修复轨迹但他们不会公开。结果就是学术界想训练一个像样的代码 Agent连数据都找不到。OpenSWE 的目标很简单用钱砸出一个学术界能用的大规模 SWE 训练环境然后全部开源。图1OpenSWE 的完整流水线——从 GitHub PR 收集到环境构建、质量过滤、轨迹采样最终产出高质量训练数据 SWE-bench 是什么为什么它这么重要在聊 OpenSWE 之前得先说说它的考场——SWE-bench。2024 年 8 月OpenAI 发布了 SWE-bench Verified这是软件工程智能体领域最权威的基准测试。它的任务设定是输入一个代码仓库 一个 issue 描述比如某个函数在处理空列表时会报错输出一个能修复这个 issue 的代码补丁验证运行仓库的测试套件看补丁是否真的修复了问题这个任务难在哪仓库很大动辄几十万行代码Agent 要在茫茫代码海中定位问题上下文很长理解一个 Bug 可能需要读懂多个文件、多个类的交互验证很严格不是看起来对就行必须通过真实的测试用例到了 2026 年前沿模型在 SWE-bench Verified 上的分数已经突破 60%。OpenSWE 训练的模型拿到了66.0%这是什么概念每 3 个真实世界的 BugAI 能独立修好 2 个。 核心挑战为什么造 SWE 环境这么难表面上看造 SWE 训练数据不就是找一堆 GitHub PR然后把它们包装成 Docker 环境吗实际上这里面坑多到你怀疑人生。坑1依赖地狱每个 Python 项目都有自己的依赖环境。你可能遇到这个库需要 Python 3.7那个库需要 3.10某个依赖的某个版本已经从 PyPI 下架了两个依赖互相冲突让 AI 自动写 Dockerfile 来配置这些环境99% 的情况会失败。坑2测试不靠谱GitHub PR 里自带的测试可能太脆弱换个环境就挂测试覆盖不全修补丁通过了但实际上没改对依赖外部服务比如数据库、API在 Docker 里跑不起来坑3Issue-PR 不对齐很多 PR 的 issue 描述写得很模糊比如修复了一些问题。这种数据拿来训练 Agent它学到的是什么学到了如何胡说八道。坑4难度不可控有些 Bug 一眼就能看出来怎么改太简单没学习价值有些 Bug 即使给人类专家也改不出来太难Agent 根本学不会。OpenSWE 的贡献就是系统性地解决了这些问题并把整个流水线开源出来。 方法详解多智能体合成流水线OpenSWE 的核心是一套部署在 64 节点集群上的多智能体合成流水线。每一步都有专门的 Agent 负责Step 1PR 收集与过滤从 GitHub 收集 Python 仓库的 Pull Request然后四阶段过滤阶段过滤条件目的仓库可行性Stars ≥ 5过滤掉低质量玩具项目语言过滤主语言为 Python聚焦 Python 生态Issue 要求PR 必须关联有具体描述的 issue确保有清晰的任务定义实质性更改排除仅改测试的 PR确保测试的是真实能力Step 2仓库探索 Agent在写 Dockerfile 之前需要先了解仓库的结构。探索 Agent 会浏览 README 和配置文件搜索与环境配置相关的文档总结安装和测试命令这就像让 Agent 先预习一遍仓库知道它大概长什么样。Step 3Dockerfile 构建 Agent这是最难的一步。为了提高成功率OpenSWE 做了几个工程优化基础镜像预构建提前构建了覆盖 Python 2.7 到 3.14 的openswe-python基础镜像避免每次都从头装 Python。本地仓库缓存用COPY命令注入代码而不是git clone绕过 GitHub API 限制。分层感知提示指导 Agent 把稳定的底层比如系统依赖放前面变化频繁的层比如项目代码放后面利用 Docker 层缓存加速重建。一个典型的 Dockerfile 生成过程Agent 输入仓库结构 README requirements.txt setup.py Agent 输出完整的 Dockerfile Agent 思考过程 1. 这个项目需要 Python 3.9用 openswe-python:3.9 基础镜像 2. 发现 requirements.txt 里有 torch需要安装 CUDA 依赖 3. setup.py 里有 C 扩展需要装 gcc 4. 生成 Dockerfile...Step 4评估脚本构建 Agent有了 Docker 环境还需要知道怎么跑测试。评估脚本 Agent 负责定位与 issue 相关的测试文件生成运行测试的 bash 脚本如果原 PR 没有测试还要合成新的测试用例Step 5环境验证用一个简单但有效的规则验证环境是否可用1. 应用仅测试补丁只包含测试代码的改动→ 测试应该失败 2. 应用完整补丁包含修复代码→ 测试应该通过 只有两个条件都满足才接受这个环境这个验证逻辑确保了环境确实能复现 Bug且修复确实能解决 Bug。Step 6测试分析 Agent对于验证失败的环境分析 Agent 会诊断原因Dockerfile 配置错误→ 反馈给 Dockerfile Agent 重试评估脚本有 Bug→ 反馈给脚本 Agent 修改环境本身不可解→ 标记并丢弃这个闭环迭代让成功率从第一轮的不到 10% 提升到了最终的 ~20%。图2多智能体协作的环境构建流水线——仓库探索、Dockerfile 构建、评估脚本生成、测试分析形成闭环迭代 质量控制难度感知的过滤流水线有了 45k 个可执行环境还不够还要确保这些环境的训练价值。OpenSWE 用一个简单但有效的方法来评估难度让模型尝试解决看成功率。用 GLM-4.7 模型在每个环境上跑 4 次4 次全失败太难了Agent 学不会 → 丢弃4 次全成功太简单了没学习价值 → 丢弃1-3 次成功难度适中保留最终从 ~45k 环境中筛选出约 9,000 个高质量环境生成约 13,000 条训练轨迹。 实验结果登顶 SWE-bench主要结果模型参数量SWE-bench VerifiedQwen2.5-Coder-Instruct32B41.2%SWE-Master32B57.8%daVinci-Dev32B55.3%OpenSWE32B62.4%daVinci-Dev72B58.5%OpenSWE72B66.0%OpenSWE-32B 比同规模的 SWE-Master 高出 4.6%OpenSWE-72B 比 daVinci-Dev-72B 高出 7.5%。数据扩展分析一个有趣的发现是训练数据越多效果越好而且还没有饱和。论文画出了 Pass1 随训练步数的变化曲线发现是近似对数线性的增长y a ⋅ log ( x ) b y a \cdot \log(x) bya⋅log(x)b相关系数高达 0.99。这意味着什么如果继续扩展 OpenSWE 的规模模型效果还会继续提升。图3Pass1 随训练步数呈对数线性增长且未观察到饱和迹象——继续扩展数据集将带来额外收益跨域迁移能力最让我惊讶的是在 SWE 数据上训练数学能力也提升了。基准Qwen2.5-72B-BaseOpenSWE-72B提升GSM8K86.394.58.2MATH-50073.485.612.2HumanEval51.882.931.1这说明什么代码调试能力和推理能力是相通的。训练 Agent 修 Bug 的过程实际上也在训练它的逻辑推理、多步规划、错误诊断等通用能力。 成本分析钱都花在哪了OpenSWE 项目总投资约 147 万美元具体分布阶段成本说明环境构建$891,000LLM API 调用探索、Dockerfile、脚本生成轨迹采样$376,000让模型尝试解决每个环境难度过滤$200,000多次采样评估难度总计~$1,470,000平均每个可执行环境的构建成本约 $19.66。这个成本高吗从学术界的角度看确实不低。但从工业界的角度看这是在打基础——有了这套开源的基础设施后续扩展的边际成本会大幅下降。 我的观点与启发1. 数据工程的胜利这篇论文再次证明了在 Agent 训练中数据工程的重要性不亚于算法创新。OpenSWE 没有提出什么花哨的新算法它做的就是把 PR 收集流程标准化把 Dockerfile 生成自动化把质量过滤系统化然后用钱和算力把规模堆上去。结果呢直接登顶。2. 多智能体协作的范式OpenSWE 的流水线是一个很好的多智能体协作案例探索 Agent 负责侦察Dockerfile Agent 负责搭环境脚本 Agent 负责写测试分析 Agent 负责诊断问题每个 Agent 只做一件事但组合起来能完成复杂任务。这种分工协作的模式在其他领域也可以借鉴。3. 开源的价值最让我感动的是OpenSWE 把所有东西都开源了。不只是模型权重而是45k 个 Docker 环境所有 Dockerfile评估脚本分布式构建基础设施这意味着其他团队不需要再花 147 万美元从头造一遍。学术界真正能在这个基础上继续往前走。4. 一些疑问Q1训练数据和测试数据有重叠吗OpenSWE 用的是 GitHub PRSWE-bench Verified 也是从 GitHub 来的。虽然论文说做了去重但具体怎么去的如果训练数据里有和测试集高度相似的样本模型可能只是在背答案。Q2147 万美元的可复现性虽然代码开源了但如果我想复现整个流程还是要花 147 万美元吗有没有更经济的方案Q3仓库分布的偏差12.8k 仓库看起来很多但热门仓库比如 Django、Flask的样本肯定比冷门仓库多。这种分布偏差会不会导致模型在冷门项目上效果变差图4OpenSWE 与其他数据集的规模对比——在任务数和仓库覆盖率上都远超现有开源数据集 与其他工作的对比项目任务数仓库数开源程度SWE-bench VerifiedSWE-bench2.3k12数据开源-SWE-rebench~19k~1k数据开源~55%daVinci-Dev??仅模型58.5%72BOpenSWE45.3k12.8k全开源66.0%72BOpenSWE 在规模、开源程度、模型效果三个维度上都是最强的。 总结OpenSWE 这篇论文的贡献可以总结为三点规模突破构建了迄今最大的开源 SWE 训练环境45k 任务、12.8k 仓库比现有数据集大一个数量级全栈开源不只是模型权重而是把整个构建流水线、Docker 环境、评估脚本全部开源真正做到可复现效果验证OpenSWE-72B 在 SWE-bench Verified 上达到 66.0%刷新了 Qwen2.5 系列的 SOTA且展现出强劲的跨域迁移能力对于想做代码 Agent 的团队OpenSWE 提供了一个非常好的起点。对于关心 AI 发展的读者这篇论文揭示了一个重要趋势在 Agent 训练中可执行、可验证的环境数据比静态的 QA 对有价值得多。至于 147 万美元的投资值不值我觉得值。因为这不是一次性消费而是为整个开源社区建设基础设施。 参考文献OpenSWE GitHub: https://github.com/GAIR-NLP/OpenSWESWE-bench: https://swebench.comSWE-bench Verified: https://openai.com/research/swe-bench-verified觉得有启发的话欢迎点赞、在看、转发。跟进最新AI前沿关注我的微信公众号机器懂语言