--- title: "Odoo 19 升级 20：AI 工作流复验清单" canonical: https://wavect.io/zh/blog/odoo-19-20-ai-upgrade-readiness/ language: zh description: "升级到 Odoo 20 后，如何重新验收原有 AI 工作流？对照配置、确认请求路径、记录被停用的测试，并用八项证据台账决定哪些功能可以恢复。" image: "https://wavect.io/img/blog/headers/header_odoo-19-20-ai-upgrade-readiness.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo 19 升级 20：AI 工作流要重新验收什么？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-helpdesk-ai-classify-draft-escalate/) 要点速览 映射实际源与目标配置，确认请求路径，按独立业务预期复验。中和测试可能停用定时和 IAP 路径，应保留相应证据缺口。手动路径通过，不代表定时任务已经验证。让指定负责人只批准有证据支持的运行范围。 升级后的数据库能打开，智能体也能回答熟悉的问题，团队便想重新开启原来的自动化。但这些现象还不能证明，工作流采用了预期配置、访问的是正确记录，并且会在需要人工决定时停下来。 **让 Odoo 19 的 AI 工作流在 20 中恢复运行前，应将原配置映射到实际目标配置，确认请求与计费路径，再通过获准的测试环境复验约定业务用例。**被停用的路径应保留为证据缺口。由明确的流程负责人验收目标行为，才能决定恢复哪些功能。 **资料核验日期：2026 年 11 月 5 日。**本文根据官方版本化文档提出验收方法。我们没有执行 Odoo 19 到 20 的迁移，也没有测量智能体性能。文中示例和下载台账均尚未执行，不能当作某个部署已经通过验收的证明。 ## 哪些文档变化需要重新作出决定？ 先比较文档中的配置差异，再检查升级后的实际数据库。文档能指出哪些设置值得关注，却不能证明你的智能体、凭证或定制动作会如何迁移。版本对照用于提出问题；目标环境中的配置、执行记录和审核结果，才是回答问题所需的证据。 [19.0 智能体指南](https://github.com/odoo/documentation/blob/19.0/content/applications/productivity/ai/agents.rst) 描述 Topics， [20.0 指南](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai/agents.rst) 描述 Skills，回复风格选项也有所不同。需要明确记录对应关系。名称相似或标签改变，都不能证明原来的验收要求自动得到满足。 [20.0 AI 概览](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai.rst) 说明 AI 请求消耗 IAP credits。 [20.0 API 密钥页面](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai/apikeys.rst) 仍在建设中。因此，特定旧凭证方案会如何变化，不能据此确认。应针对计划运行的具体路径获取当前依据。 | 检查领域 | 目标数据库需要回答的问题 | 应保留的证据 | | --- | --- | --- | | 智能体配置 | 现在分配了哪些指令、工具和回复设置？ | 源与目标配置引用，以及每项有意变更的解释 | | 请求路径 | 哪个服务和账户处理该流程的请求？ | 当前配置、账户负责人及受支持方案的确认 | | 用量控制 | 谁能查看消耗并停止该工作流？ | 预算责任、实际监控路径和已验证的停止方法 | | 执行路径 | 触发器是否以预期身份到达正确动作？ | 该路径的执行记录，而不仅是配置截图 | [Odoo AI 额度预算](/zh/blog/odoo-ai-cost-per-accepted-workflow/) 和 [AI 处理地点证据](/zh/blog/odoo-ai-data-residency-eu-hosting/) 应分别审查。在本验收记录中引用相应决定，避免把所有问题重复写成一份庞大的清单。 ## 升级前后记录应包含什么？ 记录足以解释一个工作流从触发到被接受结果的配置，包括准确版本、智能体指令、可用工具、信息来源、执行身份和人工审核边界。既要记有意修改，也要记尚未解释的差异。仅列出已安装应用，无法证明某个具体流程在升级后保持了预期行为。 为流程设置稳定标识，例如 `STOCK-NOTE-01`，并确定业务负责人。在“19”和“20”之外，保留实际构建或部署引用。如果采集基线后源环境又发生变化，应先更新基线，再与目标比较。 不要把密钥写进台账。记录凭证引用、账户负责人和核验日期即可。提示词或指令集保留经批准的快照或版本引用；信息来源则记录验收时使用的文档或数据版本。这样可以解释行为差异，又无需把生产数据复制到规划表中。 有效的变更记录应说明旧设置、目标设置、原因、预期影响和批准人。“换成新默认值”没有回答业务影响。“调整表达风格；访问与审核要求仍由 R06-A 至 R06-C 验证”，则形成了可检查的承诺。 数据库对账应单独处理。 [迁移验收与核对指南](/zh/blog/odoo-migration-acceptance-reconciliation/) 关注业务记录和余额是否完整迁移。本台账关注的是围绕这些记录运行的 AI 行为能否被接受。 ## 中和测试数据库会留下哪些证据缺口？ 测试环境可能停用你正需要验证的路径。因此，解读结果前应记录哪些触发器、请求路径和副作用被禁用。定时任务没有运行，或 AI 请求路径不可用，就应标记该部分尚未测试，再设计受控验证补齐证据。不能把“没有发生”自动理解成“运行正常”。 Odoo 的 [中和数据库文档](https://github.com/odoo/documentation/blob/20.0/content/administration/neutralized_database.rst) 将计划动作和 IAP 令牌列入停用功能，而且明确说明清单并不完整。我们据此作出的推论很有限：一次成功的手动对话，不能证明被停用的定时或 IAP 路径已经执行。 测试前明确隔离约定：使用合成或获准数据、允许哪些目标地址、引用哪些账户、支出上限是多少、允许哪些写入，以及谁能停止运行。技术负责人应确定哪些控制继续停用，哪条具体测试路径可以安全启用或替换。中和处理本身不能证明每个定制外部连接都已隔离。 还要区分两类证据。模拟供应商服务失败，可以验证自己的交接代码如何应对该模拟故障，却不能证明真实账户、计费路径或实际请求可用。反过来，一次请求成功，也不足以说明调度、重复送达或人工审核正常。每项观察都应注明适用范围。 如果升级窗口前无法提供受控路径，应保留证据缺口，并让受影响自动化继续暂停。其他独立验证过的流程可以另行验收，不必把所有流程合并成一个模糊的“通过”。 ## 如何复验已有工作流？ 比较两个环境之前，先定义预期业务行为。使用稳定、获准的输入，对两边结果执行相同的记录、权限和审核检查。旧输出只是一次观察，不是天然正确的标准答案。如果旧流程本来就有问题，复现它只会把缺陷带到新版本。 设想一个虚构的计划团队，让助手准备内部库存异常说明。拟议要求很有限：标明获准的数据快照，只描述该快照支持的异常，明确保留未知数量，并将说明提交人工审核。助手不得修改库存数量，也不得绕过审核流程向外发送消息。 选择三个不同用例：明确异常、信息不完整的来源，以及包含“跳过审核”指令的来源。运行任一版本前就写好预期结果。措辞流畅但编造缺失数量的说明应失败；表达不同但事实、来源和审核状态符合要求的说明可以通过。 也要验证失败或停止路径。请求无法完成时，谁接手、用户看到什么、如何避免把“没有回答”误认为“没有异常”？这些要求应独立于产品具体返回哪句错误提示。 详细写入断言可参考 [业务状态测试指南](/zh/blog/odoo-ai-agent-business-state-tests/) 。发布记录引用相应用例结果即可，不必重复每项测试定义，也不必变成第二份数据库对账报告。 ## 发布验收台账需要哪些证据？ 把配置观察、已执行用例和负责人批准分开。每个必需检查项应包含源引用、目标引用、预期结果、实际观察和审核人。没有实际证据的行仍然是未完成，即使其余文档很齐全。台账只是让差异可见，不能替人自动决定是否恢复生产。 下载 [八项工作流发布证据台账](/downloads/odoo-19-20-ai-upgrade-readiness/workflow-release-evidence.csv) 及 [使用说明](/downloads/odoo-19-20-ai-upgrade-readiness/README.md) 。所有行初始状态均为 `NOT_RUN`，实际观察和批准字段为空。这些是拟议检查，不是某个 Odoo 实例的测试结果。 | 编号 | 领域 | 需要解决的问题 | | --- | --- | --- | | R01 | 范围与基线 | 决定涵盖哪个流程、哪些环境和数据，由谁负责？ | | R02 | 配置映射 | 源到目标的差异是否已理解并批准？ | | R03 | 执行权限 | 哪些触发器、身份和工具可以行动，审核在哪一步介入？ | | R04 | 请求路径 | 账户、计费和处理地点决定是否仍适用于该路径？ | | R05 | 测试隔离 | 哪些路径真正执行、哪些只做模拟、哪些仍被停用？ | | R06 | 业务用例 | 实际结果是否符合独立定义的预期？ | | R07 | 失败与交接 | 流程能否停止，并为未完成工作留下明确负责人？ | | R08 | 发布决定 | 谁接受这一有限范围，什么变化要求重新审核？ | 证据经过审核后才能用 `PASS`；实际观察与预期冲突时用 `FAIL`；无法开展验证时用 `BLOCKED`；尚未执行时用 `NOT_RUN`。不适用的项目可写 `N/A`，但要保留理由和审核人。这些是建议的团队约定，不是 Odoo 自带状态字段。 证据栏不要只填“与之前相同”。应引用实际配置快照、用例结果或决定。如果修复了问题，保留失败观察并关联复测，不要用一个绿色单元格覆盖历史。 ## 什么时候可以恢复工作流？ 当必需观察支持约定业务要求，并且指定负责人接受剩余限制时，才能恢复所定义的范围。缺少证据与已发现缺陷需要不同处理，但都不等于通过。如果只验收了手动子流程，应明确这一运行方式，并让尚未验收的触发器继续保持停用。 | 观察到的情况 | 决定 | 运行影响 | | --- | --- | --- | | 必需用例通过，路径和责任明确 | 接受已定义范围 | 按文档恢复流程，并保留监控与停止方法 | | 手动路径通过，定时路径未执行 | 有价值时只接受手动范围 | 继续停用调度，分配缺失测试 | | 输出看似正确，账户或处理路径仍不明确 | 暂停受影响路径 | 补齐证据后再传输获准业务数据 | | 必需业务条件失败 | 拒绝该行为 | 修复、复测受影响用例并重新决定 | 技术审核人确认执行了什么、改变了什么；流程负责人决定记录中的结果是否适合业务。两项决定都要指明版本、路径和工作流范围。批准手动生成草稿，并不授权后来新增的无人值守写入。 还应约定生产初期观察与验收结论冲突时的处理。暂停流程并转为人工可能合适；数据库回滚则需要独立、经过测试的方案。停用智能体不会自动撤销已写入记录。工作流验收不能被当作恢复任何历史数据状态的保证。 ## 预约升级窗口之前应该完成什么？ 列出团队依赖的 AI 工作流，为每个流程指定验收负责人，并在计划恢复前明确测试路径。首个交付物应是范围清晰、缺口真实可见的台账。它让升级团队能够估算、验证和审核具体工作，而不是接到一句笼统的“检查一下 AI”。 从业务结果容易检查的一个流程开始，补齐源快照、目标映射和用例预期。然后判断其他流程是否共享配置与执行路径，还是需要独立证据。共用基础设施可以减少重复工作，但不同权限或副作用仍然需要单独决定。 Wavect 的 [软件质量保障服务](/zh/services/software-quality-assurance/) 可帮助定义验收范围和证据负责人。 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 提供更广泛的发布背景。 [Twinsoft AI 案例](/zh/case-studies/twinsoft-ai/) 属于另一个 AI 交付项目，不是本文 Odoo 升级验证已经执行的证据。 可以带上流程清单和未解决问题， [讨论你的验收计划](/zh/contact/?intent=qa) 。有效的审核应产出明确测试、已知限制，以及每项恢复决定的负责人。 ## Odoo 升级 AI 验收常见问题 ### 旧模型答案可以直接当标准答案吗？ 不能。它只能证明旧流程曾经输出什么。业务事实、权限范围和审核要求应独立定义。如果旧答案编造数量或执行了未授权操作，在目标版本重现同样行为仍然失败。保留两边观察，才能区分修复、改进与回归问题。 ### 截图和回答必须完全一致吗？ 通常业务要求比措辞或界面完全一致更重要。应明确哪些字段、来源引用、状态和审批边界必须正确。如果合同或下游集成要求精确格式，就将它列为验收条件。其他情况下，回复风格不同不应掩盖任务是否正确完成。 ### Odoo 19 使用自有供应商密钥时怎么办？ 记录当前方案，但不要把密钥本身写进台账。针对具体工作流确认目标配置支持情况、账户负责人、请求路径和计费证据。20.0 密钥文档不完整，既不能证明原方案会保留，也不能证明它被禁止。在取得当前依据前，应将该路径标为待确认。 ### 能否跳过已经不用的工作流？ 可以决定退役，但要记录决定并停用可能的入口。被遗忘的定时任务、按钮或集成调用可能重新启动无人验收的工作。如果将来可能恢复，应明确它不在本次批准范围内，并要求启用前重新提供证据。 ### 手动点击按钮通过，是否覆盖定时任务？ 它只覆盖真正执行过的路径。定时运行可能采用不同时间、身份、记录筛选或重复处理方式。记录共享组件与未测部分。被停用的定时路径需要单独受控验证，或者明确保持手动运行；一次成功点击不能补齐这项证据。 ### 验收证据可以有效多久？ 应将批准绑定到记录中的配置与范围，而不是默认永久有效。请求路径、指令、工具、来源、权限或触发器变化时，应重新评估影响。仍适用的证据可以复用，受影响用例需要复测，并记录更新决定。验收只覆盖被审查过的行为。 QA 与生产就绪 ## 接下来读什么 可靠生产软件所需的测试、审计、维护与加固。 [从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [README ZIP 恶意软件：审查 AI 工具的实际安装内容](/zh/blog/readme-zip-malware-install-review/) - [AI 生成的 Odoo 模块：先审业务规则，再谈上线](/zh/blog/ai-generated-odoo-module-audit/) - [Odoo 迁移验收：逐条核对业务记录与余额](/zh/blog/odoo-migration-acceptance-reconciliation/) - [Odoo AI 智能体测试：验收实际保存的活动记录](/zh/blog/odoo-ai-agent-business-state-tests/) - [Odoo 20 权限迁移：如何验收多公司隔离？](/zh/blog/odoo-20-company-access-migration-tests/) [上一篇文章**Odoo 20 权限迁移：如何验收多公司隔离？**](/zh/blog/odoo-20-company-access-migration-tests/) [下一篇文章**Odoo AI 导入映射：核验供应商价格**](/zh/blog/odoo-ai-data-mapping-validation/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-helpdesk-ai-classify-draft-escalate/)