感觉提问的是思路, 不是技术, 那就从思路方面给一些参考意见哈, 希望能抛砖引玉 :

一般接口会有独立的 code 响应,
比如成功是 200 / OK / Success 啥的,
失败就是 501(502,500 等) / DATA_CHECK_FAIL / FAILURE 啥的,
所有接口肯定都需要进行基础断言, 比如你们公司的接口, 数据处理成功, code 给你响应一个 OK, 你就每个接口都断言这个 code 为 OK ( PS : 这个并不绝对, 大多数项目会在相应状态码基础上, 在响应体的 Json 中给出更加详细的 code 区分 )

甚至可以将这个断言直接写入 requests 的封装中, 毕竟每个接口都需要, 这样你最起码能保证每个通过的用例, 内部的接口都调用通过了

然后就是帖子中提到的各种断言方式, 看你接口需要哪一种, 这里就结合业务和实际流程
数据敏感, 下游接口需要使用某数据, 那你就可以考虑详细断言, 毕竟业务相关就需要结合实际项目来考量
可以是从基础到详细, 考虑细化
或者从详细到基础, 考虑简化
最终找到适合自己项目的断言标准

一定要用 ai 吗, 开源的 Paddle OCR 了解一下, 直接 flask 启一个客户端开放 web 接口就可以了. 甚至你可以写一个 web 页面来自定义位置 输出

相比于作者的 ao 模式
更为普遍的还是 :
Excel/yaml 维护接口信息
Pytest 直接定义用例方法
上下游依赖的数据存储与内存或者 yaml 文件中
这样的作法

个人感觉后者除了扩展性外均优于前者
原因是我们可以直接通过 curl 命令来提取需要的数据
同时生成参数化数据
又生成 Python / Pytest 脚本

这个功能我也实现并部署了 : ( ps:云服务不久就会过期哈 )
http://121.36.110.11:5555
这个项目是在应付常规业务测试之余编写实现的
仅仅是基于我们公司内部框架的实现, 其实也可以写通用一些
不过当前是硬编码的, 大家可以简单看看, 交流交流想法

回到正题 :
这样编写一个接口测试脚本的成本就变得很低了:

1. 公共数据的提取和写入 ( 这点其实没什么成本, 因为方法肯定会提前封装好, 而替换哪些, 存储哪些, 在任何框架下都需要思考 )
2. 用例的组织 ( 这个其实也没什么成本, 一个流程下来, 按照执行顺序来组织用例即可 )

以上是我的拙见, 欢迎并且十分期待大佬指正哈
我也在思考接口自动化测试项目, 如何在编码的情况下
既要有要还要
既要便于实现, 让全员参与, 哪怕是代码小白
又要项目规范, 不至于混乱, 代码格式得统一
还要扩展性强, 比如性能侧, 或便于生成数据

以为是测试相关副业, 点进来原来是五花八门.