当客户的业务规则发生变化，我们会同步调整语义建模，并确认两件事：
1. 新的业务规则是否已经生效；
2. 原有关键问题是否仍符合当前业务口径。
最近我们进一步优化了测试集这个基础功能，把这一过程沉淀为一套可重复运行的验证方法。以下示例我们用三条测试用例快速展示背后的工作原理。
01 真实问题，定义验证边界
项目初期，为保障核心测试有效性，应优先将高频业务问题、核心经营指标及易混淆业务口径，直接通过调试入口一键归集至测试集，夯实基础测试体系。
同时，支持团队手动创建用于验证的问题，自主配置验证类型与预期内容，归档用于后续系统版本迭代、业务规则变化或建模配置调整。
聊着天就能够把真实使用过程中的测试用例进行补入，测试覆盖范围统一管理，测试结果也一目了然，及时发现“未通过”原因，进行逻辑修正。
02 三种验证，对应三个判断层级
一个问题能否得到符合预期的回答，可以从查询执行、语义理解和最终结果三个层面检查：
1. 没报错即通过：查询链路能否完整运行？
2. Logicform （系统核心逻辑层）一致：业务对象、时间范围、指标和筛选条件是否符合预期？
3. 结果一致：最终查询结果是否符合预期？
即便查询结果碰巧一致，Logicform 仍能揭示业务对象或筛选条件的变化。Logicform 保持一致，而结果变化时，又能反向排查SQL逻辑和数据源，定位结果变更原因。
说明：LF 转 SQL 由算法生成，版本升级可能优化 SQL 写法，但只要 LF 不变，业务逻辑就一致，结果异常基本指向数据本身问题
03 一次运行，形成一条可复查记录
项目团队可以指定实际用于该业务场景的 AI 员工，批量运行相关测试用例。这样，团队看到的就是该 AI 员工在当前建模配置下的测试结果。
测试运行器会展示执行进度、整体通过率和每条用例的状态。点开未通过项，可以查看实际 Logicform、预期 Logicform、实际结果和预期结果，并据此安排修正与复测。
每次运行都会留下历史记录。一条完整记录至少回答四个问题：测了什么、由谁运行、按什么标准判断、发生在什么时候。再结合建模版本、数据环境和变更记录，项目团队可以复查调整前后的变化，并据此安排验收、复测和发布。
04 随建模配置迁移
测试用例可以随建模包迁移。建模内容进入目标环境时，配套问题和预期也会同步迁移。团队可以直接运行同一批问题，检查迁移后的建模配置是否仍按既定口径工作。
业务口径和数据状态保持一致时，原有预期可以继续使用。业务规则或数据已经变化时，项目团队需要先确认新的预期，再启动测试。
语义建模、数据质量、指标口径和权限配置共同构成数据问答准确性的基础。测试集记录这些条件变化后，哪些已覆盖问题仍符合预期。
客户项目中的验收、回归和迁移复查可共用同一套判断依据。业务团队确认当前口径，实施与数据团队维护建模、用例和预期，项目负责人依据运行记录安排修正、复测和发布。
团队由此可以说清楚：当前配置在哪些问题上、由哪个 AI 员工、按什么标准通过了验证，并据此判断是否进入日常使用。