接口自动化断言粒度怎么定？断到字段级天天碎，断到业务级又怕漏

背景：我维护一套 B 端 SaaS 的接口自动化（pytest + requests，约 350 条用例），团队 4 人，后端 Java + Spring Boot，前端 React。每次发版前跑一轮回归，CI 上大约 20 分钟跑完。

现象：断言粒度成了团队里最大的"内耗点"，具体表现有三种：

1. 断到字段级（比如 assert resp["data"]["order"]["status"] == "PAID"）——后端改一次字段名、加一个嵌套层级，20 条用例全碎，修断言的时间比写业务代码还长。就像把一栋楼的每根钉子都编了号，装修换个门把手，你得重新编号 20 个钉子。
2. 退到业务级（只断 status_code == 200 + data 不为空）——上周一次 P2 事故就是这么漏掉的：接口返回 200 但 amount 字段被后端误改成了字符串，前端没报错（JS 里 "0.01" * 100 不会炸），直到财务对账才发现。断言太粗等于"只看了快递箱没拆"。
3. 4 个人 4 种断言风格，code review 时经常吵，没有统一标准。

已尝试：

• 写了个 assert_schema(resp, schema_dict) 工具函数，用 jsonschema 做结构校验——治好了"字段名改了就碎"的问题，但"字段值改错"这类还是得手动写，而且 schema 文件本身又成了新的维护负担（改一次接口要同步改 schema，和改断言没本质区别）；
• 给核心接口（支付、退款）单独写了"黄金断言"（精确到字段 + 值），非核心接口只断 schema——思路对了，但"核心"和"非核心"的边界没人说得清，每次新增接口都要吵一轮；
• 想引入 contract testing（Schemathesis / Dredd / Pact），但团队没人有实际落地经验，不确定投入产出比，怕花两周搭完发现还是得手写断言。

期望得到的答案形态：

• 你们团队在接口自动化里，断言粒度是怎么分层的？有没有"必须断到值 / 只断 schema / 只断 200"这种明确的分层规则？分层依据是什么（业务影响面？调用量？历史 bug 数？）？
• "核心接口"怎么定义？有没有一个客观的、不需要"吵"就能划出来的标准？
• 有没有人真正落地过 contract testing（Schemathesis / Dredd / Pact 都行）？实际效果怎样，踩了什么坑，值不值得花一周搭？
• 断言碎的时候，你们是怎么批量修复的？有没有工具链（比如 OpenAPI diff → 自动更新断言）？

欢迎带具体代码片段、schema 文件结构、CI 配置来聊，越具体越好。