一个字段终于抽对了，其他字段却开始乱填。对合同、发票和业务PDF，提示词修改并不是只影响一个格子的局部手术。Databricks在10月27日公开的一份工程复盘中，把问题从“再改一句提示”推进到固定样本评测、提示与结构共同留版，以及人工批准上线的完整闭环。

快速看点：字段规则不应全塞进全局提示；提示词与输出结构需要一起管理版本；准确率之外还要看漏答覆盖率与多次运行波动。Genie Code可以协助提出修改并重新评测，但是否进入生产，仍由负责的人员决定。

先分清错误，再决定改哪里

这份材料是已有产品的工程方法复盘，不是文档抽取功能当天首次上线。它处理的链路包括文件解析、结构化字段抽取和人工复核。关键改进是将审核确认的结果沉淀为可重复使用的标准答案，而不是每次改提示后，凭几份看起来正常的输出判断是否成功。

错误还要先分类。原始页面上的字没有被正确解析，与字已经识别出来但字段含义理解错误，是不同问题。带位置引用的结果可以帮助复核人员回到页面找证据；模型给出高置信度，也不代表该答案一定正确，不能直接替代人工标签或业务规则。

复盘把修改分成几层：字段类型、枚举和描述表达单个字段的约束；全局提示负责跨字段关系、文档层面的推理与优先级；确定性的格式整理则放到SQL等处理环节。这种拆分并不保证每次都更准，但能让团队知道，究竟改了业务定义、模型判断还是后处理规则。

例如，同样叫“版本”的字段，业务可能只接受明确写出的修订值，而不是允许模型根据日期猜一个。这里需要先说明什么算正确、什么时候应返回空值。换更强的抽取模式未必能解决定义混乱，反而可能让错误答案看上去更完整。

提示与结构要一起留版本

只给提示词留历史，仍可能漏掉一半抽取逻辑。字段描述也会影响模型行为，因此复盘建议将提示和结构定义都纳入MLflow Prompt Registry管理，并把评测结果对应到实际使用的两组版本。这样才能解释一次回归是从哪里开始的。

生产别名可以指向当前批准的版本，候选别名指向待评测版本。管道在新的初始化或运行时读取别名，而不是把配置永久写死在任务代码中。回退时，需要恢复提示与结构两个对应版本；这不是正在执行的所有任务瞬间切换，也不是两个独立别名天然拥有原子提交保证。

这里还有产品状态边界：当前Databricks文档把Prompt Registry标为Beta，并要求相应Unity Catalog权限。文档处理也依赖受支持区域、计算资源及数据访问条件。可复用的版本管理方法，不等于任何账户今天都能无条件使用全部能力。

准确率上升，还要看漏了多少

评测首先固定文档、标准答案与计分规则。否则，前后分数变化可能来自样本变简单，而不是配置变好。除了整体和逐字段结果，还应按文档类型拆开看，避免某类常见版式掩盖另一类材料的明显退步。

覆盖率尤其容易被忽略。如果只在“模型和人工都填了值”的位置算准确率，模型放弃难题、留下空白，反而可能获得更漂亮的分数。反过来，正确答案本来就应该为空，也必须纳入错误分析。因此，团队需要明确哪些空值算正确，哪些属于漏答，再对比准确率与有效覆盖是否同时保持。

语言模型重复运行会出现波动，单次高分不能直接证明改善。复盘建议对同一生产配置多次评测，估计正常波动，再为候选配置制定门槛。文中提供的运行次数和统计阈值属于工程策略示例，不是适用于所有业务的统计保证，更不能替代严重字段错误的一票否决规则。

Genie Code的相关文档描述了一个可检查的过程：对标注表逐字段评分，展示建议修改的差异，用户接受后再跑同一评测集。最终提升生产别名前，仍要有人审阅退步字段、记录理由和配置版本。对于总体变化不明显但符合重要业务约定的修改，也应留下明确的人工决策记录。

本文没有采用匿名项目的错误下降比例作为普遍收益。样本构成、标注口径和业务难度无法在本轮独立复现，官方复盘中的改善不能直接换算为任何企业的准确率、节省人力或投资回报。本轮也未执行该项目代码或进行客户生产测试。

小编判断

文档AI的交付标准，不应只是“这张表看起来对了”，而应能回答：用了哪组配置、在哪些文档上变好、哪些字段退步、谁批准上线，以及如何退回上一版。这套闭环的价值，是让提示词修改成为能追踪的工程变更，而不是靠印象决定投产。