这类问题我又碰上了一次。本地用 DSPy 2.4 编译好的指令产物存成 json，升级到 3.0 预发布版后加载报 Signature field 'question' not found in signature，编译时的 demo 一起失效。把文件里的字段名手工改成 question 仍然报错，试过重新编译一次，跑到第 40 分钟被中断。
第一反应是「demo 里的输入键名被重命名，加载时校验不通过」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。新版把 Signature 的字段描述改成了 pydantic 模型，旧 json 结构不兼容；编译产物里带着旧版的类路径，反序列化时找不到类；缓存目录里留着一份更旧的指令，优先被读到了。
动手时先看产物 json 里的字段与版本标记
python -c "import json;d=json.load(open('compiled.json'));print(list(d)[:8], d.get('version'))"随后清掉 DSPy 的本地缓存再加载
python -c "import shutil,os;shutil.rmtree(os.path.expanduser('~/.dspy_cache'),ignore_errors=True)"接着确认当前安装的版本号
python -c "import dspy;print(dspy.__version__)"末了用新版重新编译一个小样本后比对字段
python -c "import json;d=json.load(open('compiled.json'));print(sorted(d.get('demos',[{}])[0]))"恢复的判定其实很直接。新版本能直接加载重新编译的产物，同一批 50 条问题的准确率与旧版编译结果相差在 1 个百分点内，不再报字段缺失。
补一句。编译产物是带版本的结构体不是纯文本，跨大版本升级必须重新编译，手改字段只会把错误推到运行时。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。