企业官网建设流程全解析

前面写了不少理论和对比，这篇来点实际的：用 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。

第三步：人工审查

任务完成后，审查生成的代码 patch：

1、检查点击事件是否正确区分了三种行为。

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 #862：slash-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 GitHub：github.com/chaitin/MonkeyCode

在线体验：monkeycode-ai.net

社区 Discord：discord.gg/2pPmuyr4pP

（作者注：我是 MonkeyCode 的实际使用者，非项目官方成员。本文引用的 Issue 和 PR 均来自公开的 GitHub 仓库，修复方案描述基于 PR #859 和 PR #863 的公开信息。）