AI 编程最危险的用法，是只说一句“帮我修复这个 Bug”，然后直接接受修改结果。
可靠的修复流程应该包含复现、定位、最小修改、测试和结果汇报。MainBody 可以围绕本地项目完成这些步骤，但开发者仍要提供清楚现象和验收方式。
第一步：选择正确项目目录
在 MainBody 中为代码仓库创建项目会话，不要选择包含多个无关仓库的上级目录。
确认项目中是否存在 AGENTS.md、CONTRIBUTING.md、README 或测试说明。让 Agent 在修改前先阅读这些约束。
第二步：写出可观察的 Bug
下面两种描述差别很大：
模糊：登录页面有问题，帮我优化。清楚：在 390px 宽度下打开登录页，
错误提示超过卡片右侧边界；桌面宽度正常。
保持接口、文案和桌面布局不变。
问题现象、触发条件和不能改变的内容越明确，Agent 越容易缩小范围。
第三步：要求先定位，不立即修改
先阅读项目约束，找到登录页面、相关样式和测试。
说明问题原因与计划修改的文件，暂时不要编辑。
如果无法复现，列出缺少的条件。
检查它是否找对组件，是否把公共样式误认为页面专用样式。
第四步：执行最小修改
确认方案后继续：
按刚才方案做最小范围修复。
不要升级依赖，不要重构无关组件，不要改变接口和现有文案。
为窄屏问题补充或更新相关测试。
最小修改更容易审查，也能降低意外影响其他页面的概率。
第五步：运行验证
运行登录页面相关测试和生产构建。
如果项目支持本地页面预览，在 390px 与桌面宽度分别检查。
不要把“命令已执行”当成成功，报告退出状态和实际页面结果。
测试失败时，先分析失败是否由本次修改引起，不要为了通过测试随意删除断言。
第六步：检查差异和运行记录
最终至少查看：
- 修改了哪些文件；
- 代码差异是否只围绕问题；
- 新增测试是否真的覆盖触发条件；
- 构建与测试结果；
- 没有覆盖的浏览器或真实登录场景；
- Runs 中是否出现反复失败的命令。
可直接复制的完整指令
修复登录页在 390px 宽度下错误提示溢出卡片的问题。
先阅读仓库规则并定位原因，再做最小修改。
保持接口、文案、桌面布局和依赖不变。
完成后运行相关测试与生产构建，并检查移动端和桌面端页面。
汇报改动文件、验证结果和未覆盖风险。
哪些改动必须格外谨慎？
身份认证、权限、支付、数据迁移和删除逻辑，即使测试通过也应经过人工代码审查。生产部署不应因为本地 Agent 完成修改而自动发生。
总结
开发者使用 MainBody 修 Bug 的关键流程是：给出现象、先定位、确认范围、最小修改、运行测试、检查差异。
Agent 能减少搜索和重复操作，但“修复是否正确”仍要由代码、测试和人工审查共同证明。
了解 MainBody：https://mainbody.cn