前面写了不少理论和对比这篇来点实际的用 MonkeyCode 修复一个真实的 GitHub Issue记录完整的从发现问题到提交 PR 的过程。这个 Issue 来自 MonkeyCode 自己的仓库github.com/chaitin/MonkeyCode是一个已经被修复的真实案例。我用它来演示 AI 编码平台处理真实 bug 的工作流程。一、问题背景GitHub Issue #824在任务输出的 Markdown 中点击以 /workspace/ 开头的链接会跳回应用首页而不是打开对应的文件。这个问题的影响场景MonkeyCode 在任务执行过程中会输出 Markdown 格式的日志和说明其中包含指向工作空间内文件的 /workspace/ 路径链接。开发者点击这些链接想要查看文件内容结果被跳回了应用首页体验很差。二、问题分析为什么 /workspace/ 开头的链接会跳回首页MonkeyCode 的前端路由处理逻辑中/workspace/ 路径被当成了应用路由的一部分而不是文件路径。点击链接时前端路由尝试匹配 /workspace/... 到一个应用页面匹配失败后就 fallback 到了首页。这个问题的修复方案PR #859是区分三种交互行为1、普通点击打开 task file preview在编辑器内预览文件内容。2、新标签页打开保留 file-manager deep link让用户在新标签中查看文件。3、复制链接保留 deep link 格式方便分享给其他开发者。三、用 MonkeyCode 处理这个问题的流程如果我是一个贡献者用 MonkeyCode 来修复这个 Issue流程如下第一步提交需求在 MonkeyCode 控制台提交开发需求描述内容是修复 Issue #824任务输出 Markdown 中 /workspace/ 开头的链接点击后返回首页的问题。需要区分普通点击、新标签页打开、复制链接三种交互行为。相关代码在 frontend/src/components/console/task/ 目录下。第二步AI 执行MonkeyCode 在服务器端创建工作空间拉取仓库代码调用模型分析问题并生成修复代码。模型会1、定位到前端路由处理 /workspace/ 路径的代码。2、分析当前的点击事件处理逻辑。3、修改代码为三种交互行为分别添加处理逻辑。4、生成修复后的代码 patch。第三步人工审查任务完成后审查生成的代码 patch1、检查点击事件是否正确区分了三种行为。2、确认普通点击打开预览而不是跳转首页。3、确认新标签页打开保留了 deep link 格式。4、确认复制链接功能正常。5、检查是否引入了新的 bug。第四步验证在本地或 CI 中验证修复1、运行 lint 检查代码规范。2、运行在线 build 确认编译通过。3、手动测试 Markdown 链接的三种交互行为。PR #859 的报告中正是包含了这些验证项lint 通过、online build 通过、手动 Markdown-link 检查通过。第五步提交 PR审查通过后提交 Pull Request关联 Issue #824在 PR 描述中说明修复方案和验证结果。四、从这个案例看 AI 编码平台的价值这个案例虽然是个小 bug但它体现了 AI 编码平台相比 IDE 插件的几个优势1、任务可追溯从 Issue 到需求描述到代码 patch 到 PR整条链路有完整记录。用 IDE 插件的话修了什么、基于什么上下文修的全靠 commit message 记录。2、隔离环境AI 在独立工作空间中分析代码和生成修复不会影响开发者本地的其他工作。如果修复不满意直接驳回重新执行不产生本地垃圾文件。3、附带验证MonkeyCode 的任务产物包含 build 和 test 结果审查时可以确认代码至少能编译通过。IDE 插件生成的代码需要开发者自己跑测试。4、适合批量处理如果你有多个类似的 Issue 需要修可以在 MonkeyCode 上批量提交任务并行执行。IDE 插件只能一个一个手动操作。五、任务描述的好坏决定修复质量用 AI 编码平台修 bug最关键的是任务描述要写清楚。对比两种描述差的描述修复 #824 链接跳转问题好的描述修复 Issue #824任务输出 Markdown 中 /workspace/ 开头的链接点击后返回首页的问题。需要区分三种交互行为普通点击打开 task file preview、新标签页打开保留 file-manager deep link、复制链接保留 deep link 格式。相关代码在 frontend/src/components/console/task/ 目录下。验证方式lint 检查、online build、手动 Markdown-link 检查。好的描述包含三个要素问题是什么、怎么修约束条件、怎么验证。描述越具体AI 生成代码的质量越高审查的工作量越小。六、另一个案例键盘快捷键同一个仓库还有另一个 Issue #862slash-command 确认对话框缺少键盘快捷键用户只能用鼠标点击确认或取消。PR #863 的修复方案是添加 ArrowLeft 键将焦点移到 Cancel 按钮ArrowRight 键将焦点移到 Confirm 按钮。实现路径在 frontend/src/components/console/task/chat-inputbox.tsx 中通过 button refs 控制焦点移动。这两个案例的共同特点是问题边界清晰、修复方案明确、验证方式可描述。这类 bug 非常适合用 AI 编码平台来处理。七、什么类型的 Issue 适合交给 AI根据实际使用经验以下类型的 Issue 适合交给 MonkeyCode 处理1、UI 交互修复边界清晰效果可验证。比如上面的链接跳转和键盘快捷键。2、工具函数实现功能明确容易写测试。比如写一个验证邮箱格式的函数。3、bug 修复有明确复现步骤问题描述清楚修复范围有限。4、单元测试编写给现有代码补测试AI 擅长这类任务。5、文档完善给代码加注释、更新 README。不适合交给 AI 的1、架构级重构涉及大量文件和依赖关系AI 容易遗漏上下文。2、性能优化需要 profiling 数据和实际测试AI 只靠代码分析容易误判。3、安全漏洞修复需要安全专业知识和威胁建模不宜完全依赖 AI。4、业务逻辑密集型修改涉及大量领域知识AI 可能理解偏差。八、总结用 MonkeyCode 修真实 GitHub Issue 是一个很好的上手方式。找一个边界清晰的 Issue写好任务描述让 AI 生成修复代码然后人工审查和验证。这个过程能帮你快速理解平台的工作流程也能评估 AI 在你的项目上的实际表现。建议从自己熟悉的项目仓库里找 2-3 个小 Issue 开始练手积累任务描述的技巧和审查经验后再扩大使用范围。相关链接MonkeyCode GitHubgithub.com/chaitin/MonkeyCode在线体验monkeycode-ai.net社区 Discorddiscord.gg/2pPmuyr4pP作者注我是 MonkeyCode 的实际使用者非项目官方成员。本文引用的 Issue 和 PR 均来自公开的 GitHub 仓库修复方案描述基于 PR #859 和 PR #863 的公开信息。