测评场景： 基于现有两段复杂 SQL，生成一段全新的"按村统计"查询，涉及多表关联、条件筛选、存栏量统计等业务逻辑。
使用过程：
我直接把两段原始 SQL 贴给 Solo，并描述了新需求：按村维度统计乡镇、村名、姓名、身份证、联系电话、牛/羊存栏数、是否更新、备注等字段。Solo 没有立刻动手写代码，而是主动提了三个关键问题：
-
牛和羊各自的
classify_code_second是什么？（现有 SQL 只出现了羊的编码 C0102） -
存栏量的统计截止日期是当前日期还是固定日期？
-
"是否更新"的判断标准是否与现有逻辑一致？
这三个问题恰好是我描述中没有说清楚但直接影响结果正确性的地方。回答完毕后，Solo 生成了完整的 SQL，我检查后确认：存栏统计口径（p_cultivation + pa_archives_register 两表 UNION ALL、is_such='0' 过滤未出栏）、用户筛选条件（auth_status、family_user_type、user_type）、更新判断逻辑（三张表任一有记录）均与原始 SQL 完全保持一致。
核心评价：
最让我惊喜的是业务理解能力。这两段原始 SQL 加起来几百行，涉及养殖、屠宰、档案登记等多张业务表，统计逻辑并不直观。Solo 不仅读懂了现有 SQL 的统计口径，还在新 SQL 中严格复用了一致逻辑，没有出现"看似合理但实际偏差"的情况。对于这种强业务场景的代码生成，这种准确性比"写得快"重要得多。
总结： Solo 在理解复杂业务 SQL 方面表现可靠，适合有明确参考逻辑的代码生成场景。推荐给需要频繁编写数据统计查询的同学。