上一篇，我直接从 WideWorldImporters 业务库的发票和发票明细出发。用同一个 QueryModel 交付了表格、查询 API 和 AI 问数。

但那只能证明第一版能跑。

真实业务不会停在一张固定列表上。说起来，使用者痛点：不断 的筛选需求——按日期、发票、客户、客户类别、地区、商品、税率和金额筛选。还要分页、排序和汇总，

这次我把所有条件全部加到了同一张发票明细表上。

结果概览

我没有新增专用 Controller、Form / DTO、Mapper、Repository 查询方法或 Vue 页面也没有修改上一篇的 TM / QM。

八个条件同时使用时只返回一条明细：

="" r="" td=""。="">

="" r="" th="">

="" r="" th="">

="" r="" th="">

="" r="" th="">

手写 SQL 返回的也是这一条。

传统列表接口真正麻烦的不是 WHERE 而是层层改动的痛点：

• Controller 接收新参数: 使用者常说“这个字段太多，改接口太麻烦。”
• Form / DTO 补字段与校验: 开发者频繁遇到“类型错误”提示。
• Service 判断哪些条件存在: 因为过滤器增多，判断逻辑堆积成“if-else”山。
• Mapper/Repository 或 SQL 模板追加过滤逻辑: 每一次更改都可能引入 N+1 问题。
• 分页查询和 count 查询不能漏掉任何一个条件: “页面显示的数据数量与后台返回的不一致”。​ <\/li>
• 汇总 SQL 再复制一次相同范围​ <\/li>
• 前端表单项、操作符、默认值和序列化规则同步更新。​ <\/li>
• AI 如果走另一套接口，还要重新理解这组参数。​ <\/li> - **新增的是8个筛选条件**。不一定是8个 HTTP endpoint，但通常会变成多个层次里的 **4–6** 组改动。​ <\/ul>