AI Agent自动化修复GitHub Issue：从问题定位到PR提交全流程解析

1. 项目概述一个能自动修复GitHub Issue并提交PR的AI技能最近在折腾AI编程助手的时候发现了一个挺有意思的东西叫issue-to-pr。简单来说这玩意儿是一个AI Agent的“技能包”你把它装在你的AI编程工具比如Cursor、Claude Code这些里然后只需要丢给它一个GitHub Issue的链接它就能自己把整个活儿给干了分析代码库、定位问题、写修复代码、跑测试最后生成一个完整的Pull Request等着你点头确认。整个过程你只需要在最后点一下“同意”PR就自动发出去了。听起来是不是有点科幻我第一次看到的时候也觉得挺玄乎的。但仔细研究了一下它的实现思路和背后的逻辑发现这其实是一个把现有工具链Git、GitHub CLI、AI代码生成和一套非常清晰的自动化流程结合起来的产物。它解决的痛点非常明确作为一个开发者每天可能会看到很多需要修复的Issue但手动去克隆仓库、定位代码、写修复、提PR这个过程非常耗时且重复。这个技能就是把中间所有机械化的步骤给自动化了让AI和开发者各自做自己最擅长的事——AI负责执行既定流程和生成代码开发者负责最后的决策和审核。这个技能包本身是开源的基于MIT协议这意味着你可以自己研究、修改甚至集成到自己的工具链里。它目前支持主流的AI编程环境包括Qoder、Cursor、Claude Code、Windsurf和GitHub Copilot。接下来我就结合自己的理解和一些实验来详细拆解一下这个东西到底是怎么工作的以及如果你想深度使用或者自己实现类似功能需要注意哪些坑。2. 核心工作流与设计哲学解析2.1 八阶段自动化流水线不只是“写代码”这个技能最核心的价值在于它定义了一个完整的、端到端的自动化工作流。很多AI代码工具只能做到“根据描述生成代码片段”但issue-to-pr把范围扩大到了整个GitHub协作生命周期。它的工作流被清晰地划分为八个阶段我们一个一个来看第一阶段链接解析与信息抓取当你输入一个类似https://github.com/owner/repo/issues/123的链接时技能首先要做的是解析。它需要准确提取出三个关键元素仓库所有者owner、仓库名repo和Issue编号number。这里看似简单但其实有坑。GitHub的URL有时候会有额外参数或者用户可能输入的是短链接。一个健壮的解析器必须能处理各种边缘情况确保核心信息被正确提取。之后它会利用GitHub CLI (gh) 去获取这个Issue的详细信息包括标题、正文描述、标签、评论历史。这些信息是后续所有分析的“原材料”。实操心得为什么优先用ghCLI而不是直接调用GitHub API因为gh命令行工具已经帮你处理了认证使用你本地配置的GitHub token并且有更好的速率限制处理和错误反馈。对于公开仓库它也会有一个降级策略即如果gh不可用或失败会回退到通过HTTP抓取公开页面内容。这种设计保证了工具在大多数环境下的可用性。第二阶段代码库定位与准备拿到Issue信息后它需要在一个有代码的环境里工作。这里有一个智能判断它会先检查你当前的工作目录是否已经是目标仓库。如果是就直接使用当前目录避免重复克隆节省时间和磁盘空间。如果不是它才会执行git clone操作把仓库拉到本地。这个细节对体验提升很大特别是当你已经在项目目录中只是想快速修复另一个相关Issue时。第三与第四阶段代码分析与根因定位这是最体现“智能”的部分也是整个流程的难点。AI需要理解用自然语言描述的Issue比如“点击按钮后表单验证不生效”然后去代码库中寻找相关的代码文件。它并不是盲目地全局搜索而是会结合Issue中的关键词、错误信息、堆栈跟踪如果有的话、以及代码的文件结构和命名约定进行有目的的“追踪”。例如如果Issue提到了一个具体的函数名或文件名AI会优先查看那些文件。它需要理解代码的调用链路、数据流从而定位到真正需要修改的那几行代码。这个过程非常依赖AI模型对代码语义的理解能力。第五阶段实施最小化修复找到问题根因后AI会生成修复代码。这里有一个关键原则最小化变更。它不会重写整个文件或模块而是力求用最少的代码改动来解决问题。同时它会尽力模仿项目原有的代码风格缩进、命名约定、注释风格等让生成的补丁看起来就像是项目维护者自己写的一样提高被合并的几率。第六阶段内置验证代码写完了不能直接就算完事。AI会尝试运行项目已有的测试套件比如npm test,pytest,go test等并运行代码格式化工具或linter如prettier,eslint,black。这一步是为了确保修复没有引入回归错误并且符合项目的代码质量标准。如果测试或检查失败AI可能会尝试调整修复方案或者将错误信息反馈给用户。第七阶段交互式确认这是将控制权交还给开发者的关键一步。AI会生成一个清晰的总结说明它发现了什么问题、修改了哪些文件、以及具体的代码差异diff。它会等待用户的明确确认。只有用户说“可以”它才会进入最后一步。这个设计至关重要保证了人始终在循环中对代码变更拥有最终决定权。第八阶段自动提交PR获得确认后AI会执行一系列Git命令git add,git commit并生成语义化的提交信息git push。这里还有一个高级功能自动分叉支持。如果你对目标仓库没有写入权限它会自动帮你fork这个仓库将更改推送到你的fork中然后从你的fork向原仓库发起Pull Request。最后它会使用gh pr create来创建PR并自动填充标题和描述通常来源于Issue内容和AI的修改总结。2.2 设计哲学增强而非替代理解这个技能的设计哲学很重要。它不是一个要取代开发者的“自动程序员”而是一个力放大器。它把开发者从繁琐、重复的上下文切换和机械操作中解放出来克隆、找文件、运行命令、提交推送让开发者可以更专注于高层次的思考问题定位是否准确修复方案是否最优代码变更是否安全它的整个流程设计都体现了“有约束的自动化”输入有约束输入必须是具体的GitHub Issue链接这提供了极其丰富的上下文问题描述、讨论历史、标签比一句模糊的“帮我修个bug”要强得多。操作有约束它严格遵循项目的现有工具链项目的测试、项目的linter确保变更符合项目规范。输出有约束最终输出是一个标准的Git提交和GitHub PR完美嵌入现有的开源协作流程。权限有约束任何向远程仓库的推送和PR创建都必须经过用户手动确认。这种设计使得它既强大又可控非常适合处理那些模式固定、上下文清晰、但执行起来繁琐的任务。3. 环境准备与安装部署详解3.1 核心依赖工具剖析要让issue-to-pr技能跑起来你的机器上需要准备好两个基础工具它们各自扮演着不可替代的角色。Git版本控制的基石这个没什么好说的是任何代码相关操作的前提。你需要安装并配置好Git确保git命令在终端可用并且已经配置了你的用户名和邮箱git config --global user.name和git config --global user.email。因为后续的所有代码变更、提交、分支操作都依赖于Git。GitHub CLI (gh)与GitHub交互的瑞士军刀这是强烈推荐的组件也是技能体验流畅的关键。gh是GitHub官方出的命令行工具它比直接使用Git或原始API方便太多了。安装去 cli.github.com 根据你的操作系统下载安装。macOS用户用Homebrew (brew install gh) 是最方便的。认证安装后第一次使用需要运行gh auth login。这个过程会引导你在浏览器中完成GitHub账号的OAuth授权之后gh就会安全地使用你的token来执行操作。这个token被存储在本地系统密钥链中issue-to-pr技能通过调用gh命令间接使用它避免了技能本身处理敏感凭证的安全风险。核心作用gh在这里主要负责两件大事高效获取Issue数据gh issue view number --repo owner/repo --json title,body,comments这样的命令可以以结构化的JSON格式快速获取Issue的所有细节比爬取网页HTML要可靠和高效得多。便捷创建PRgh pr create --title ... --body ... --base main一行命令就能完成PR创建的所有步骤包括自动检测当前分支、设置目标分支、打开浏览器或直接创建。注意事项虽然技能有fetch_content作为降级方案当gh不可用时通过HTTP请求抓取公开的Issue页面但这种方式解析HTML不稳定容易因为GitHub前端页面改版而失效而且无法获取私有仓库的Issue信息。因此为了获得完整、稳定的功能尤其是处理私有仓库安装并登录gh是必须的。3.2 多种安装方式实操项目提供了几种安装方式适用于不同的使用场景和AI编辑器。方式一通过ClawHub安装推荐如果你使用的AI编辑器环境集成了ClawHub一个AI技能的管理平台那么这是最简洁的方式。clawhub install issue-to-pr这条命令会从技能仓库拉取最新的SKILL.md文件这个文件定义了技能的元信息、触发指令和工作流并安装到你的AI编辑器技能目录下。安装后通常在编辑器中输入/就能看到这个技能选项了。方式二使用一键安装脚本对于没有集成ClawHub或者喜欢手动控制的用户项目提供了一个安装脚本。# 先克隆仓库 git clone https://github.com/ClawHub/issue-to-pr.git cd issue-to-pr # 运行安装脚本 bash scripts/install.sh你可以打开scripts/install.sh看看它做了什么。本质上它就是把SKILL.md文件复制到了AI编辑器特定的技能目录中比如~/.qoder/skills/issue-to-pr/。不同的编辑器技能路径可能不同这个脚本通常会尝试检测或让你指定编辑器类型。方式三完全手动安装如果你对路径很明确或者想自定义安装位置可以直接手动操作。# 假设你的AI编辑器如Qoder技能目录在 ~/.qoder/skills/ mkdir -p ~/.qoder/skills/issue-to-pr # 将技能描述文件复制过去 cp /path/to/issue-to-pr/SKILL.md ~/.qoder/skills/issue-to-pr/手动安装的关键在于找到正确的目标路径。你需要查阅你所用的AI编辑器的文档弄清楚它从哪里加载自定义技能。3.3 安装后的验证与配置安装完成后如何验证技能是否生效重启你的AI编辑器。大多数编辑器会在启动时加载技能目录。在编辑器的聊天框或命令面板中尝试输入技能的关键词比如/fix-issue或者直接描述“fix GitHub issue”。如果技能被正确加载编辑器应该会识别出这个命令并提示你输入Issue URL。你也可以在编辑器的设置或技能管理界面中查看已安装的技能列表确认issue-to-pr在列。一个重要的配置点工作目录技能在执行时需要一个本地目录来克隆代码和进行操作。你需要确保你当前在AI编辑器中打开或所在的工作区Workspace是一个合适的目录比如你的项目开发目录。或者技能可能会在你指定的一个临时目录中操作。理解这一点有助于你管理克隆下来的众多仓库避免弄乱你的主项目目录。4. 实战演练从Issue到PR的全过程拆解光说不练假把式我们用一个模拟的场景来走一遍完整的流程看看每个环节在实际操作中是什么样子可能会遇到什么问题。4.1 场景设定与技能触发假设我们在浏览GitHub时看到一个开源工具example-cli的Issue#456标题是“--helpcommand output is misaligned on terminals wider than 120 chars”。描述里说当终端宽度超过120字符时帮助信息的对齐格式会乱掉。我们想修复它。传统做法是克隆仓库、找到负责打印帮助信息的代码文件、理解格式逻辑、修复、本地测试、提交PR。现在我们试试用issue-to-pr。在已经安装该技能的Cursor编辑器里我直接在聊天框中输入/fix-issue https://github.com/someuser/example-cli/issues/456或者用更自然的说法请帮我修复这个GitHub issuehttps://github.com/someuser/example-cli/issues/456AI助手比如Claude会识别出这个指令并开始调用issue-to-pr技能。4.2 阶段实录AI如何一步步工作阶段1 2解析与克隆AI的回复开始了“我将开始处理这个Issue。首先解析URL... 识别到仓库someuser/example-cliIssue编号456。” “正在通过GitHub CLI获取Issue详情... 获取成功。标题--helpcommand output is misaligned on terminals wider than 120 chars。” “检查当前目录... 不在目标仓库内。正在克隆https://github.com/someuser/example-cli.git到临时目录/tmp/issue_to_pr_xxx。”此时你会看到终端活动起来执行git clone命令。克隆完成后AI的工作环境就准备好了。阶段3 4分析与定位“开始分析代码库定位与--help输出和终端格式对齐相关的代码。” “搜索关键词help,printf,format,terminal,width,columns...” “发现主要相关文件src/cli/help_formatter.c和src/utils/terminal.c。” “正在分析help_formatter.c中的print_help_table()函数。发现它使用硬编码的列宽值80来计算对齐。当终端实际宽度大于此值时计算出的偏移量错误导致对齐混乱。” “根因定位help_formatter.c第127行const int TERMINAL_WIDTH 80;这是一个硬编码的假设值。需要改为动态获取终端宽度。”这个过程是黑盒的但我们从AI的“思考过程”描述中可以看到它在进行关键词搜索、文件定位、代码阅读和逻辑推理。它准确地找到了问题所在一个硬编码的终端宽度常量。阶段5实施修复“将实施最小化修复。方案将硬编码的TERMINAL_WIDTH替换为从get_terminal_width()函数位于terminal.c中获取的动态值。” “修改src/cli/help_formatter.c在文件顶部添加对get_terminal_width函数的声明或头文件引用如果需要。修改第127行将const int TERMINAL_WIDTH 80;替换为int TERMINAL_WIDTH get_terminal_width();。考虑到get_terminal_width()可能失败或返回0添加一个回退值int TERMINAL_WIDTH get_terminal_width(); if (TERMINAL_WIDTH 0) { TERMINAL_WIDTH 80; }。”然后AI会直接展示它生成的代码差异diff// src/cli/help_formatter.c #include ../utils/terminal.h // 添加头文件引用 void print_help_table() { - const int TERMINAL_WIDTH 80; int TERMINAL_WIDTH get_terminal_width(); if (TERMINAL_WIDTH 0) { TERMINAL_WIDTH 80; // 失败时使用默认值 } // ... 其余计算逻辑保持不变 }这个修复非常精准只改了必要的地方保持了代码风格并且考虑了边缘情况函数调用失败。阶段6运行验证“现在运行项目测试以验证修复。” 你会看到AI在终端执行make test或npm test或项目特定的测试命令。 “测试通过。正在运行代码格式检查 (make lint)... 检查通过。” “编译测试 (make build)... 成功。”阶段7呈现变更并等待确认“✅ 分析与修复完成。问题根因硬编码的终端宽度导致宽终端下对齐计算错误。修改文件src/cli/help_formatter.c具体变更将静态宽度常量替换为动态获取终端宽度的函数并添加错误回退。代码差异已生成见上文。 是否确认以上变更并自动提交Pull Request(Yes/No)”这时你需要仔细审查AI给出的diff。确认修改是否正确、是否引入了其他问题。如果没问题输入Yes。阶段8提交PR“收到确认。开始提交代码。” “执行git add src/cli/help_formatter.c” “执行git commit -m \fix: dynamically fetch terminal width for help output alignment\n\nCloses #456\n\n- Replace hardcoded TERMINAL_WIDTH with get_terminal_width() call\n- Add fallback to default width if detection fails\” “检测到我对someuser/example-cli仓库没有直接写入权限。正在自动创建Fork... Fork创建成功yourname/example-cli。” “推送更改到Fork仓库git push origin HEAD” “正在创建Pull Request... 使用命令gh pr create --base main --head yourname:fix/help-output-alignment --title \fix: help output misalignment on wide terminals\ --body \This PR fixes #456 by replacing the hardcoded terminal width with a dynamic lookup via \get_terminal_width(). A fallback to the original default (80) is included.\n\nChanges:\n- Modified src/cli/help_formatter.c to call get_terminal_width().\n- Added fallback logic.\n\nTesting:\n- All existing tests pass.\n- Manually verified help output aligns correctly on terminals of varying widths.” “✅ Pull Request 已成功创建链接https://github.com/someuser/example-cli/pull/789”至此整个流程结束。你从一个Issue链接开始没有执行任何Git命令没有手动写代码就得到了一个等待合并的PR。4.3 实操中的关键技巧与心得提供高质量的Issue这个技能的成效很大程度上取决于输入Issue的质量。一个描述清晰、有重现步骤、甚至有错误日志的Issue能让AI更准确地定位问题。模糊的Issue如“这个功能不好用”很可能导致AI跑偏。审查Diff是必须的永远不要跳过第7步的确认。AI可能会误解需求或者修复方案有副作用。你必须像审查任何人类同事的代码一样仔细审查它生成的变更。利用好“自动Fork”对于你没有写入权限的仓库这个功能是无价的。它省去了你手动去GitHub页面点击Fork、设置上游远程仓库、切换分支等一系列操作。关注测试结果如果AI报告测试失败不要急着确认。仔细看失败信息可能是AI的修复引入了新bug也可能是测试本身依赖了某些环境。你可以根据错误信息进一步指导AI调整修复方案。临时目录管理技能克隆的仓库通常在临时目录。如果你需要基于这个修复做更多工作记得在流程结束后将代码复制到你的常规开发目录或者记下临时目录的位置。5. 深度技术解析技能如何与AI编辑器协同工作issue-to-pr本身不是一个独立的应用程序而是一个“技能”或“插件”。它的本质是一个高度结构化的提示词Prompt模板加上一些预定义的逻辑步骤。它需要在一个具备代码执行能力和大语言模型LLM的AI编辑器环境中运行。5.1 技能描述文件SKILL.md 的奥秘技能的核心是那个SKILL.md文件。它并不是可执行代码而是一个用特定格式编写的“说明书”告诉AI编辑器“当用户触发某个指令时你应该按照以下步骤去思考和工作”。这个文件通常包含元信息技能名称、描述、作者、版本。触发指令比如/fix-issue或者自然语言模式“fix GitHub issue”。输入规范期望用户输入什么一个GitHub URL。工作流步骤用自然语言或结构化格式描述的一系列步骤就是我们前面讲的8个阶段。这些步骤是给AI看的“剧本”。工具调用指令告诉AI在特定步骤应该使用什么工具例如“使用gh issue view命令获取Issue详情。”“使用git clone命令克隆仓库。”“使用find或grep命令在代码库中搜索相关文件。”“运行npm test来执行测试。”输出格式规定AI在每个阶段应该以什么格式向用户汇报以及最终PR提交信息的模板。当你在AI编辑器中输入指令时编辑器会将SKILL.md的内容作为系统提示词的一部分与你的输入Issue URL一起发送给背后的LLM如Claude、GPT-4。LLM根据这个“剧本”一步步推理并在需要执行实际操作运行命令时通过编辑器提供的“代码解释器”或“工具调用”功能来执行。5.2 与不同AI编辑器的集成差异虽然技能逻辑相同但在不同编辑器中的集成度和体验可能有差异Qoder / Cursor这类深度集成AI的编辑器通常有完善的技能管理系统和后台命令执行能力。技能可以无缝调用系统终端、访问文件系统体验最接近“自动化助手”。Claude Code / GitHub Copilot它们可能更侧重于代码补全和聊天。运行issue-to-pr这类需要多步执行外部命令的技能时可能需要用户更多地在聊天中确认每一步的操作例如“我现在要运行git clone了可以吗”自动化程度可能稍低。通用性SKILL.md的格式如果遵循某种开放标准如OpenAI的Function Calling描述、或Claude的Tool Use描述那么它就有可能在不同平台间移植。这也是开源这个技能的意义之一——推动AI Agent技能生态的标准化。5.3 安全边界与隐私考量这是一个非常值得讨论的点。很多人担心AI自动执行命令会不会有风险。代码执行在本地整个流程中代码分析、修改、测试都是在你的本地机器上完成的。AI没有权限直接访问你的服务器或云环境。它只能操作你允许它访问的目录通常是临时目录或当前工作区。Git操作使用你的凭证git push和gh pr create使用的是你本地配置的Git和GitHub CLI凭证。技能本身不存储、也不接触你的密码或token。这和你手动在终端执行这些命令的安全级别是一样的。最终确认权推送代码和创建PR这两个最关键、最具“副作用”的操作完全由你手动输入“Yes”来触发。AI不能绕过这步。无数据上报根据其文档声明该技能不收集任何遥测数据或使用数据。你的代码和Issue信息不会发送到技能作者的服务器。尽管如此一个重要的安全建议是在初期试用时可以找一个无关紧要的公开仓库的简单Issue来测试观察AI的所有操作理解其行为模式后再用于更重要的项目。6. 常见问题、局限性与进阶玩法6.1 你会遇到的问题与解决方案在实际使用中你肯定会遇到一些报错或不如预期的情况。下面是一个快速排查指南问题现象可能原因解决方案AI无法识别指令或技能1. 技能未正确安装到编辑器技能目录。2. 编辑器不支持该技能格式。1. 检查SKILL.md文件是否在正确的路径下如~/.qoder/skills/issue-to-pr/。2. 重启编辑器。3. 查阅编辑器文档确认其支持的技能扩展方式。克隆仓库失败1. 网络问题。2. 仓库地址不存在或为私有仓库且无权限。1. 检查网络连接。2. 确认GitHub链接有效。3. 对于私有仓库确保你的SSH密钥或gh认证有访问权限。gh命令执行失败1.ghCLI未安装。2.gh未登录认证。1. 运行gh --version检查是否安装。2. 运行gh auth status检查登录状态未登录则运行gh auth login。AI找不到问题相关代码1. Issue描述过于模糊。2. 代码库结构复杂AI推理路径错误。3. 问题根因不在代码层面如配置、数据问题。1. 尝试提供更详细的指令例如在Issue URL后补充“重点关注src/app/目录下的文件”。2. 手动分析Issue如果已有线索如错误日志行号直接告诉AI“查看文件X的第Y行附近”。3. 对于非代码问题此技能可能不适用。测试运行失败1. 项目测试环境依赖未安装。2. AI的修复引入了编译错误或逻辑错误。3. 测试本身是脆弱的Flaky Tests。1. 查看AI输出的错误信息指导它安装依赖如npm install,pip install -r requirements.txt。2. 仔细审查AI生成的diff看是否有语法错误或逻辑漏洞。3. 如果确认是AI修复的问题可以命令它“根据测试失败信息xxx重新调整修复方案。”创建PR时权限错误1. 对原仓库无写入权限且自动Fork功能未触发或失败。2. GitHub token权限不足。1. 检查AI的日志看是否尝试了Fork。可以手动Fork仓库然后指导AI“请将更改推送到我已Fork的仓库yourname/repo。”2. 运行gh auth refresh更新token确保token有repo和workflow等必要权限。生成的提交信息或PR描述不佳AI生成的描述过于模板化或未抓住重点。在确认提交前你可以直接要求AI“请将提交信息修改为fix: [更具体的描述]”或者“在PR描述中加入测试细节和屏幕截图说明”。6.2 当前能力的局限性认识到工具的边界才能更好地使用它。对复杂问题的无力对于需要深度架构思考、涉及多个模块联动、或者问题描述极其模糊的BugAI目前很难给出正确修复。它擅长的是模式固定、上下文清晰的“小修小补”。依赖项目本身的质量如果项目没有良好的测试覆盖AI的“验证”阶段就形同虚设。如果代码风格混乱AI模仿起来也会困难可能生成风格不一致的补丁。无法处理主观决策比如“这个API设计得不好需要重构”这种涉及设计和品味的决策AI无法独立完成。外部依赖问题如果修复需要引入新的第三方库AI通常不会自动修改package.json或go.mod文件除非你明确指示它。对话上下文限制整个流程在一个较长的对话中完成可能会受限于AI模型的上下文长度。对于非常大的代码库或复杂的Issue讨论AI可能无法记住所有细节。6.3 进阶玩法与自定义如果你不满足于开箱即用的功能这个开源技能为你提供了自定义的可能性。修改技能逻辑你可以直接克隆issue-to-pr的仓库修改SKILL.md文件。比如你觉得默认的测试命令npm test不通用可以改成让AI先检测项目类型通过package.json,pom.xml,Cargo.toml等再执行对应的测试命令。集成到CI/CD你可以设想一个更激进的场景在CI流水线中当一个Issue被标记为good-first-issue或bug时自动触发一个AI Agent去尝试修复并将修复作为草稿PR创建等待维护者审查。这需要将技能与GitHub Actions等工具结合。创建领域特定技能模仿issue-to-pr的结构你可以为自己团队的项目创建定制技能。例如一个/update-dependency技能输入一个库名和版本号AI自动更新package.json运行测试提交PR。或者一个/write-unit-test技能针对某个函数自动生成单元测试。结合更强大的模型技能的效果很大程度上取决于底层AI模型的能力。你可以尝试在支持切换模型的编辑器如Cursor中将其与更强大的代码模型如Claude 3.5 Sonnet, GPT-4 Turbo结合可能会获得更好的代码分析和生成效果。这个技能展示了一条清晰的路径如何将大语言模型的能力通过精心设计的流程和约束转化为解决实际开发工作流痛点的生产力工具。它可能不会每次都完美解决问题但它将修复一个简单Issue的平均时间从“小时”级降低到了“分钟”级并且让开发者能够并行处理更多这样的任务。