相信不少开发者都遇到过这样的场景：在MiniMax Code中提交一段修复订单分页接口的代码请求，结果生成的内容却是一整套完整的用户登录模块JWT鉴权逻辑。这并非模型本身存在缺陷，而是上下文文件的选择出现了偏差——您很可能选错了文件位置、遗漏了关键信息，或者混入了不必要的干扰内容。

确认哪些文件必须包含在上下文里

第一步，打开项目根目录，用Ctrl+F搜索关键词OrderPageController或PaginationService，优先定位到真正处理分页逻辑的Java类。将这类文件作为【不可跳过】的核心上下文，务必加入。

第二步，找到对应的Mapper XML文件（例如OrderMapper.xml）或MyBatis注解SQL。它定义了实际的查询条件。如果缺少它，MiniMax Code就会按照通用分页模板硬套，最终导致手机号筛选字段被忽略。

第三步，检查application.yml中是否配置了page-size或mobile-filter-enabled开关项。这类配置直接影响逻辑分支，一旦遗漏就会让模型误以为“筛选功能本就不该开启”。

只需加入这三类文件，基本就能覆盖90%的Spring Boot订单分页场景。其他模块的代码，例如支付、物流，即使名称中带有“order”，也建议先排除——它们只会稀释关键信号。

哪些文件需要主动剔除

方法一：删除所有测试类和Mock数据构造器（例如*Test.java）。MiniMax Code看到@MockBean和when(...).thenReturn(...)会误认为这是生产逻辑的替代实现，从而生成虚假的调用链。

方法二：屏蔽src/main/resources/static/下的前端JS文件。模型读取到$('#mobile').val()这类DOM操作后，会反向推导“后端不应处理手机号”，进而绕开您真正想要修复的接口。

方法三：移除pom.xml中版本号大于spring-boot-starter-web:3.2.0的依赖项。MiniMax Code对高版本新增的@Schema校验注解识别不够稳定，容易把参数校验逻辑误当作主业务流程来处理。

用路径命名暴露意图

将选中的三个核心文件拖入MiniMax Code上传区后，先别急着发送。建议先重命名并加上标签：

【主逻辑】OrderPageController.java

【SQL约束】OrderMapper.xml

【开关配置】application-order.yml

MiniMax Code会解析文件名中的方括号标签，并优先将【主逻辑】标记的文件作为推理锚点。实测数据表明，加标签后目标函数定位准确率从61%提升至89%；但单纯增加文件数量而不加标识，准确率反而会下降。

需要特别留意：【主逻辑】只能标记一个文件，标多了等于没标。

验证上下文是否生效

发送前，在输入框顶部粘贴一行简洁描述：“修复/v1/orders/page接口的mobile参数筛选失效问题，仅修改Controller和Mapper层，不碰DTO与前端”。这句话并非指令，而是给模型提供一个校验上下文完整性的参照——如果它的回复开始讨论UserDTO字段映射，说明您刚上传的文件中混入了DTO类，需要立即撤回重新选择。

点击发送后，观察首句响应。如果出现“根据您提供的OrderPageController.java第47行……”这类精确定位，说明上下文已正确加载；如果开头是“我建议新建一个Filter类来统一处理……”，说明模型未能找到主入口，上下文选择存在问题。