本文内容
Odoo 19 升级 20：AI 工作流要重新验收什么？
升级后的数据库能打开，智能体也能回答熟悉的问题，团队便想重新开启原来的自动化。但这些现象还不能证明，工作流采用了预期配置、访问的是正确记录，并且会在需要人工决定时停下来。
让 Odoo 19 的 AI 工作流在 20 中恢复运行前，应将原配置映射到实际目标配置，确认请求与计费路径，再通过获准的测试环境复验约定业务用例。被停用的路径应保留为证据缺口。由明确的流程负责人验收目标行为，才能决定恢复哪些功能。
资料核验日期：2026 年 11 月 5 日。本文根据官方版本化文档提出验收方法。我们没有执行 Odoo 19 到 20 的迁移，也没有测量智能体性能。文中示例和下载台账均尚未执行，不能当作某个部署已经通过验收的证明。
哪些文档变化需要重新作出决定？
先比较文档中的配置差异，再检查升级后的实际数据库。文档能指出哪些设置值得关注，却不能证明你的智能体、凭证或定制动作会如何迁移。版本对照用于提出问题；目标环境中的配置、执行记录和审核结果，才是回答问题所需的证据。
19.0 智能体指南描述 Topics，20.0 指南描述 Skills，回复风格选项也有所不同。需要明确记录对应关系。名称相似或标签改变，都不能证明原来的验收要求自动得到满足。
20.0 AI 概览说明 AI 请求消耗 IAP credits。20.0 API 密钥页面仍在建设中。因此，特定旧凭证方案会如何变化，不能据此确认。应针对计划运行的具体路径获取当前依据。
| 检查领域 | 目标数据库需要回答的问题 | 应保留的证据 |
|---|---|---|
| 智能体配置 | 现在分配了哪些指令、工具和回复设置？ | 源与目标配置引用，以及每项有意变更的解释 |
| 请求路径 | 哪个服务和账户处理该流程的请求？ | 当前配置、账户负责人及受支持方案的确认 |
| 用量控制 | 谁能查看消耗并停止该工作流？ | 预算责任、实际监控路径和已验证的停止方法 |
| 执行路径 | 触发器是否以预期身份到达正确动作？ | 该路径的执行记录，而不仅是配置截图 |
Odoo AI 额度预算和AI 处理地点证据应分别审查。在本验收记录中引用相应决定，避免把所有问题重复写成一份庞大的清单。
升级前后记录应包含什么？
记录足以解释一个工作流从触发到被接受结果的配置，包括准确版本、智能体指令、可用工具、信息来源、执行身份和人工审核边界。既要记有意修改，也要记尚未解释的差异。仅列出已安装应用，无法证明某个具体流程在升级后保持了预期行为。
为流程设置稳定标识，例如 STOCK-NOTE-01，并确定业务负责人。在“19”和“20”之外，保留实际构建或部署引用。如果采集基线后源环境又发生变化，应先更新基线，再与目标比较。
不要把密钥写进台账。记录凭证引用、账户负责人和核验日期即可。提示词或指令集保留经批准的快照或版本引用；信息来源则记录验收时使用的文档或数据版本。这样可以解释行为差异，又无需把生产数据复制到规划表中。
有效的变更记录应说明旧设置、目标设置、原因、预期影响和批准人。“换成新默认值”没有回答业务影响。“调整表达风格；访问与审核要求仍由 R06-A 至 R06-C 验证”，则形成了可检查的承诺。
数据库对账应单独处理。迁移验收与核对指南关注业务记录和余额是否完整迁移。本台账关注的是围绕这些记录运行的 AI 行为能否被接受。
中和测试数据库会留下哪些证据缺口？
测试环境可能停用你正需要验证的路径。因此，解读结果前应记录哪些触发器、请求路径和副作用被禁用。定时任务没有运行，或 AI 请求路径不可用，就应标记该部分尚未测试，再设计受控验证补齐证据。不能把“没有发生”自动理解成“运行正常”。
Odoo 的中和数据库文档将计划动作和 IAP 令牌列入停用功能，而且明确说明清单并不完整。我们据此作出的推论很有限：一次成功的手动对话，不能证明被停用的定时或 IAP 路径已经执行。
测试前明确隔离约定：使用合成或获准数据、允许哪些目标地址、引用哪些账户、支出上限是多少、允许哪些写入，以及谁能停止运行。技术负责人应确定哪些控制继续停用，哪条具体测试路径可以安全启用或替换。中和处理本身不能证明每个定制外部连接都已隔离。
还要区分两类证据。模拟供应商服务失败，可以验证自己的交接代码如何应对该模拟故障，却不能证明真实账户、计费路径或实际请求可用。反过来，一次请求成功，也不足以说明调度、重复送达或人工审核正常。每项观察都应注明适用范围。
如果升级窗口前无法提供受控路径，应保留证据缺口，并让受影响自动化继续暂停。其他独立验证过的流程可以另行验收，不必把所有流程合并成一个模糊的“通过”。
如何复验已有工作流？
比较两个环境之前，先定义预期业务行为。使用稳定、获准的输入，对两边结果执行相同的记录、权限和审核检查。旧输出只是一次观察，不是天然正确的标准答案。如果旧流程本来就有问题，复现它只会把缺陷带到新版本。
设想一个虚构的计划团队，让助手准备内部库存异常说明。拟议要求很有限：标明获准的数据快照，只描述该快照支持的异常，明确保留未知数量，并将说明提交人工审核。助手不得修改库存数量，也不得绕过审核流程向外发送消息。
选择三个不同用例：明确异常、信息不完整的来源，以及包含“跳过审核”指令的来源。运行任一版本前就写好预期结果。措辞流畅但编造缺失数量的说明应失败；表达不同但事实、来源和审核状态符合要求的说明可以通过。
也要验证失败或停止路径。请求无法完成时，谁接手、用户看到什么、如何避免把“没有回答”误认为“没有异常”？这些要求应独立于产品具体返回哪句错误提示。
详细写入断言可参考业务状态测试指南。发布记录引用相应用例结果即可，不必重复每项测试定义，也不必变成第二份数据库对账报告。
发布验收台账需要哪些证据？
把配置观察、已执行用例和负责人批准分开。每个必需检查项应包含源引用、目标引用、预期结果、实际观察和审核人。没有实际证据的行仍然是未完成，即使其余文档很齐全。台账只是让差异可见，不能替人自动决定是否恢复生产。
下载八项工作流发布证据台账及使用说明。所有行初始状态均为 NOT_RUN，实际观察和批准字段为空。这些是拟议检查，不是某个 Odoo 实例的测试结果。
| 编号 | 领域 | 需要解决的问题 |
|---|---|---|
| R01 | 范围与基线 | 决定涵盖哪个流程、哪些环境和数据，由谁负责？ |
| R02 | 配置映射 | 源到目标的差异是否已理解并批准？ |
| R03 | 执行权限 | 哪些触发器、身份和工具可以行动，审核在哪一步介入？ |
| R04 | 请求路径 | 账户、计费和处理地点决定是否仍适用于该路径？ |
| R05 | 测试隔离 | 哪些路径真正执行、哪些只做模拟、哪些仍被停用？ |
| R06 | 业务用例 | 实际结果是否符合独立定义的预期？ |
| R07 | 失败与交接 | 流程能否停止，并为未完成工作留下明确负责人？ |
| R08 | 发布决定 | 谁接受这一有限范围，什么变化要求重新审核？ |
证据经过审核后才能用 PASS；实际观察与预期冲突时用 FAIL；无法开展验证时用 BLOCKED；尚未执行时用 NOT_RUN。不适用的项目可写 N/A，但要保留理由和审核人。这些是建议的团队约定，不是 Odoo 自带状态字段。
证据栏不要只填“与之前相同”。应引用实际配置快照、用例结果或决定。如果修复了问题，保留失败观察并关联复测，不要用一个绿色单元格覆盖历史。
什么时候可以恢复工作流？
当必需观察支持约定业务要求，并且指定负责人接受剩余限制时，才能恢复所定义的范围。缺少证据与已发现缺陷需要不同处理，但都不等于通过。如果只验收了手动子流程，应明确这一运行方式，并让尚未验收的触发器继续保持停用。
| 观察到的情况 | 决定 | 运行影响 |
|---|---|---|
| 必需用例通过，路径和责任明确 | 接受已定义范围 | 按文档恢复流程，并保留监控与停止方法 |
| 手动路径通过，定时路径未执行 | 有价值时只接受手动范围 | 继续停用调度，分配缺失测试 |
| 输出看似正确，账户或处理路径仍不明确 | 暂停受影响路径 | 补齐证据后再传输获准业务数据 |
| 必需业务条件失败 | 拒绝该行为 | 修复、复测受影响用例并重新决定 |
技术审核人确认执行了什么、改变了什么；流程负责人决定记录中的结果是否适合业务。两项决定都要指明版本、路径和工作流范围。批准手动生成草稿，并不授权后来新增的无人值守写入。
还应约定生产初期观察与验收结论冲突时的处理。暂停流程并转为人工可能合适；数据库回滚则需要独立、经过测试的方案。停用智能体不会自动撤销已写入记录。工作流验收不能被当作恢复任何历史数据状态的保证。
预约升级窗口之前应该完成什么？
列出团队依赖的 AI 工作流，为每个流程指定验收负责人，并在计划恢复前明确测试路径。首个交付物应是范围清晰、缺口真实可见的台账。它让升级团队能够估算、验证和审核具体工作，而不是接到一句笼统的“检查一下 AI”。
从业务结果容易检查的一个流程开始，补齐源快照、目标映射和用例预期。然后判断其他流程是否共享配置与执行路径，还是需要独立证据。共用基础设施可以减少重复工作，但不同权限或副作用仍然需要单独决定。
Wavect 的软件质量保障服务可帮助定义验收范围和证据负责人。上线前 QA 清单提供更广泛的发布背景。Twinsoft AI 案例属于另一个 AI 交付项目，不是本文 Odoo 升级验证已经执行的证据。
可以带上流程清单和未解决问题，讨论你的验收计划。有效的审核应产出明确测试、已知限制，以及每项恢复决定的负责人。