--- title: "AI 生成 Odoo 模块审计：业务规则与发布证据" canonical: https://wavect.io/zh/blog/ai-generated-odoo-module-audit/ language: zh description: "按业务规则审计 AI 生成的 Odoo 模块。对比 13 个本地审批测试，检查越权、旧版本与部分写入，再定义原生安装、事务和升级证据，区分模型通过与真实上线验收。" image: "https://wavect.io/img/blog/headers/header_ai-generated-odoo-module-audit.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # AI 生成的 Odoo 模块：先审业务规则，再谈上线 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-migration-acceptance-reconciliation/) 要点速览 按获批业务规则和准确目标版本审计模块，复现重要失败并检查最终记录。13 个本地 Python 用例揭示缺陷示例的 11 项违例，修正版满足全部预期。这不是 AI 质量基准；原生安装、授权、事务和升级检查仍为 NOT_RUN，继续决定真实发布。 折扣审批看起来很小：设置标记，再记录批准人。但下文故意写错的示例会批准已取消报价，相信调用者编造的批准身份，并在注入故障后留下部分修改。普通演示却仍能成功。 **应依据获批业务规则和准确的已安装 Odoo 版本，审计 AI 生成的模块。** 复现有业务后果的失败，检查最终记录，并独立验证修正。通过本地模型有助于定义检查；真正决定能否上线的，仍是原生安装、授权、事务和升级证据。 **资料核查日期：2026年11月5日。** 我们审阅 Odoo 20 官方资料，并执行了 13 个虚构审批用例。两份 Python 实现均为本文编写，不是客户代码样本，也不是 AI 工具基准。没有安装 Odoo 插件或执行原生升级，所有建议原生检查仍为 `NOT_RUN`。 ## 模块审计应该作出什么决定？ 审计应判断一项明确的定制是否有足够证据发布、需要有限修复，或应由获批的更简单实现替代。先确定业务命令允许改变什么。代码质量分数不能补上缺失的审批规则，也不能决定谁有权批准该规则。 扩大自定义代码前，让负责人在当前配置中演示需求。如果受支持的现有流程已经满足要求，应把它与持续维护覆盖逻辑的成本比较。这需要在已安装版本上验证，并不是预先认定所有定制审批都没有必要。 随后固定审查范围：模块提交、Odoo 版本与版本类型、依赖修订、受影响记录和执行身份。包括会改变行为的设置。只看 Git 分支、不看必要配置，可能漏掉业务实际使用的路径。 [AI 生成代码 QA 指南](/zh/blog/qa-for-ai-generated-code/) 负责更广泛的生产就绪检查。本文审查单元是一项确定性的 Odoo 定制。 [代理业务状态指南](/zh/blog/odoo-ai-agent-business-state-tests/) 则覆盖代理的完整任务与工具选择。 ## 审批示例应该实现什么规则？ 示例只在执行者有权为该公司审批、折扣处于虚构授权上限内时，批准当前版本的报价草稿，并记录一次可信身份。过期或被禁止的决定必须被拒绝，不留下部分审批，即使失败发生在批次较后的记录上也一样。 虚构报价 `Q-17` 属于公司 A，版本为 3，初始折扣 5.00%。用户 7 可批准从 0% 到 10.00% 的折扣，含上限。10.01% 需要其他决定。这些是示例业务规则，不是 Odoo 默认值。字段 `approval` 和 `approved_revision` 属于 Python 示例。 | 规则 | 允许结果 | 要求的失败行为 | | --- | --- | --- | | 权限与公司 | 当前获授权身份在公司 A 范围内操作。 | 缺少角色或公司未授权时，记录不变。 | | 版本与生命周期 | 已审核版本仍为当前版本，报价仍是草稿。 | 拒绝旧版本或已取消报价。 | | 授权上限 | 示例允许 10.00%。 | 10.01% 不能得到该项批准。 | | 身份依据 | 审批记录可信用户 7。 | 调用者提供的标签不能替换为用户 99。 | | 重复选择 | 每个报价版本只有一次批准和一条审计记录。 | 重放或重复选中不增加审批效果。 | | 批次失败 | 约定批次连同审计证据一并完成。 | 某项被拒绝或注入审计故障时，不留下部分批次修改。 | 这里的审批只修改审核字段，不确认报价、不创建交付，也不产生会计过账。这条边界决定“成功”指什么。如果真实模块还执行后续业务动作，应增加该动作的授权及最终状态约定。 先解决规则分歧，再生成预期结果。 [业务规则冲突指南](/zh/blog/enterprise-business-rule-conflicts/) 解释如何分配这项决定。审核人不能仅凭函数已经接受 10.00%，就判断业务应该允许它。 ## 逐项代码审查暴露了哪些缺陷？ 注释审查揭示缺少业务前提、批准身份不可信，以及未完成操作后仍保留修改等问题。重复调用还增加审计效果。每个发现都关联具体语句和失败用例，比把整个模块标为“AI 生成”再给出泛化风险分数，更能支持发布决定。 缺陷版本包含以下顺序，节选保留了执行次序： ``` quote["approval"] = "approved" quote["approved_revision"] = expected_revisions[key] quote["approved_by"] = claimed_approver or actor["uid"] if key == fail_audit_for: raise InjectedAuditFailure(key) store["audits"].append({ "quote": key, "revision": expected_revisions[key], "actor": quote["approved_by"], }) ``` 这段逻辑没有检查执行者是否有权批准当前记录。Odoo 的 [公共方法安全指南](https://github.com/odoo/documentation/blob/20.0/content/developer/reference/backend/security.rst) 将传入记录与参数视为不可信，CRUD 访问检查不能证明所有业务前提成立。应审查接收调用的方法，而不只是可见按钮。 | 发现 | 示例中的业务后果 | 需要验证的修正 | | --- | --- | --- | | 未检查当前权限和目标记录 | 未经授权的执行者或公司得到批准。 | 修改前验证可信身份及目标记录。 | | 缺少版本、状态与上限前提 | 过期、取消或超限请求被标为已批准。 | 将获批规则与当前记录值比较。 | | 调用者选择记录中的批准人 | 审计归因于用户 99，而非 7。 | 从可信执行身份取得归属。 | | 每次选择都追加效果 | 重复调用或重复项目产生两条审计记录。 | 识别同一版本已完成的审批。 | | 失败前先修改，却没有原子边界 | 审计写入失败，仍留下批准记录或半完成批次。 | 在真实实现证明约定的全成或全不成结果。 | 修正版 Python 先验证选择项，在暂存副本上修改，再替换模型状态。这只模拟所需结果，并没有实现 Odoo 事务。官方 [开发规范](https://github.com/odoo/documentation/blob/20.0/content/contributing/development/coding_guidelines.rst) 解释框架的事务所有权，以及为何需要审查无明确理由的手动提交。例外情况下自行明确管理的游标，需要另行论证。 下载 [带注释的发现记录](/downloads/ai-generated-odoo-module-audit/annotated-review.md) ，查看缺陷与复现用例的对应关系。 [Odoo 20 公司访问迁移测试](/zh/blog/odoo-20-company-access-migration-tests/) 负责版本相关的权限变化。旧的通用 ACL 清单不足以解释该迁移。 ## 13 个业务规则测试修正前后有何变化？ 缺陷版本违反 13 项固定预期中的 11 项；修正版满足全部 13 项。两者都能完成普通审批和恰好达到上限的审批，所以一次成功演示可能隐藏其他缺陷。这些数字仅描述刻意构造的示例，不是 AI 生成 Odoo 代码的缺陷率。 | 用例 | 缺陷版本 | 修正版本 | | --- | --- | --- | | 普通 5.00% 审批 | 批准；一条审计记录 | 批准；一条审计记录 | | 恰好 10.00% 上限 | 批准；一条审计记录 | 批准；一条审计记录 | | 10.01% 请求 | 错误批准 | 拒绝；不变 | | 执行者缺少审批权限 | 错误批准 | 拒绝；不变 | | 记录属于未授权公司 B | 错误批准 | 拒绝；不变 | | 审核引用版本 3，记录已为版本 4 | 错误地按版本 3 批准 | 拒绝；不变 | | 报价已取消 | 仍设置批准标记 | 拒绝；不变 | | 一次请求选中同一报价两次 | 两条审计记录 | 一条审计记录 | | 同一审批调用两次 | 两条审计记录 | 一条审计记录 | | 调用者提供批准人 99 | 归因于用户 99 | 归因于可信用户 7 | | 批准赋值后审计失败 | 批准标记保留；无审计记录 | 无修改 | | 批次第二条记录属于未授权 B | 两条都批准 | 两条都未修改 | | 批次第二次审计写入失败 | 两条都批准；只有一条审计记录 | 两条都未修改 | 下载 [可运行审批审查示例](/downloads/ai-generated-odoo-module-audit/approval-review-model.py) 及 [完整预期与观察状态](/downloads/ai-generated-odoo-module-audit/model-results.json) 。保存 Python 文件后运行： ``` python3 approval-review-model.py ``` 脚本使用 Python 标准库，并用十进制比较检查虚构百分比规则。它不导入 Odoo，也不访问网络。预期状态由业务约定独立定义，不依赖任一审批函数。输出包括错误和最终审批字段，仅抛出异常，不能让部分写入看起来正确。 模型没有测试原生并发请求。两个调用者并行批准同一版本时，真实方法可能还需其他保护。 [n8n 恢复文章](/zh/blog/odoo-n8n-idempotency-recovery/) 讨论外部订单创建的独立边界；本示例的重复审计效果，不能证明连接器具备幂等性。 ## 真实 Odoo 模块还必须验证什么？ 将模型结论应用于 Odoo 前，应在实际构建中验证真实入口和受影响记录。审查覆盖逻辑及依赖，再通过接收方法执行获批业务用例。确认每次修改的身份。孤立函数即使满足约定，也可能与应用集成错误。 | 领域 | 审查问题 | 所需证据 | | --- | --- | --- | | 入口 | 按钮、API 调用和自动化是否到达同一行为？ | 每条相关路径的获批身份及最终状态检查。 | | 依赖 | 清单是否声明定制使用的模块？ | 从声明依赖集可复现安装。 | | 覆盖逻辑 | 为什么替换或扩展每项基础行为？ | 证明必要标准流程仍正常的回归用例。 | | 公司与字段 | 命令是否使用预期记录、公司和值？ | 原生角色／上下文证据及代表性字段检查。 | | 失败与并发 | 中断或并行审批后留下什么？ | 受控故障时序下的记录及审计效果。 | | 既有数据 | 此模块版本之前创建的报价如何处理？ | 获批升级预期及演练后观察记录。 | [建议的原生验收包](/downloads/ai-generated-odoo-module-audit/native-acceptance.json) 包含这些关卡及业务规则用例，初始状态为 `NOT_RUN`，政策批准仍待完成。将示例预期替换为获批规则，记录准确身份与版本，并附上实际证据后才能认定通过。 审查每项覆盖逻辑时，应把标准行为放在旁边比较。没有解释的替换意味着还要查明移除了什么。如果只需要增加一个决策检查，应考虑是否能采用更窄的扩展，而非替换完整流程，再用受影响标准用例验证该判断。 ## 安装和升级证据应该怎样检查？ 将安装、升级和运行行为视为独立关卡。空库安装可发现依赖缺失；既有数据演练覆盖变化前的记录与配置。两者都不能证明正确业务测试已运行。报告必须绑定准确模块提交、目标环境和所选用例。 Odoo 的 [测试文档](https://github.com/odoo/documentation/blob/20.0/content/developer/reference/backend/testing.rst) 要求导入测试模块，并说明启用和选择如何决定执行。应索取标明预期测试的运行输出。命令显示绿色，但相关用例未执行，其行为仍未验证。 [定制数据库升级指南](https://github.com/odoo/documentation/blob/20.0/content/developer/howtos/upgrade_custom_db.rst) 区分空库安装、升级数据上的安装及运行演练。本文 Python 执行没有提供其中任何原生结果。 针对该审批定制，应纳入尚未填写新审批字段的旧报价、业务内容已变的已批准报价，以及升级开始时仍待审的记录。演练前先决定目标状态。默认值让旧记录看起来已批准，是业务决定，不应只是消除报错的捷径。 为演练保留受控恢复方案。仅回退代码，不能证明数据修改也已撤销。 [迁移对账指南](/zh/blog/odoo-migration-acceptance-reconciliation/) 覆盖更广范围的预期与观察比较。 ## 审计交付应包含哪些内容？ 每项发布决定都应能追溯到获批规则和可复现证据。对每个阻断项，记录受影响版本、复现步骤和业务后果，再附上修正及独立复测。未执行检查必须保持可见。文字风格建议清单，无法回答报价是否可能被越权批准。 示例发现记录将已确认的本地规则失败，与仍需执行的原生问题分开。真实审计也应保持这一区别。“模型拒绝旧审批”和“部署的 Odoo 方法在这些身份下拒绝旧审批”，是不同证据陈述。 修复实现与批准政策也应分开。审核人可以证明函数执行了 10.00% 上限；业务负责人决定这是否是预期授权。若审查期间规则改变，应修订预期结果，并按新约定重跑受影响用例。 [发布前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 提供整体上线背景。 [AI 构建软件的通用审计指南](/zh/blog/vibe-coded-software-audit/) 介绍更大范围的审计；本模块审查应保持较窄、可测试的边界。 ## 什么时候应发布、修复或移除定制？ 只发布获批原生证据支持的范围。修复已证明的规则违例，并复测受影响流程。如果获批的受支持替代方案满足需求，可考虑移除不必要定制，但必须安排既有数据。漂亮演示不能决定这三种选择。 建议从一个有实际后果的命令、它的真实入口，以及一对允许／拒绝用例开始，再加入可能留下错误业务记录的失败情形。这样，审计在扩展到仓库所有文件前，就有一项具体决定可作。 讨论 Wavect 的 [软件质量保障服务](/zh/services/software-quality-assurance/) 时，请准备模块提交、安装版本信息，以及负责人能批准的一条业务规则。有效交付应包含可复现发现、明确原生发布关卡，以及商定修正确实奏效的证据。 ## AI 生成 Odoo 模块审计常见问题 ### 下载示例是 Odoo 插件吗？ 不是。它是使用标准库的 Python 模型，包含故意写错及修正的审批函数，并有固定预期状态，无法安装到 Odoo。可用它检查审查逻辑和失败用例，再针对真实模块、依赖和业务政策实现并执行独立原生检查。 ### 13 个用例通过，就证明 AI 代码可靠吗？ 只能证明这个修正版满足这 13 项预期。两份实现都是为本文编写，没有测量 AI 输出样本。这个数量既不是模型比较，也不是生产缺陷估计。真实模块仍需自己的获批范围和原生证据。 ### 10.00% 是 Odoo 默认审批上限吗？ 不是。这是为显示边界测试而虚构的授权规则。普通示例是 5.00%，允许上限为 10.00%，10.01% 需要其他决定。业务负责人必须先批准真实规则及其适用数值和版本，再由审核人定义预期结果。 ### 能让同一个 AI 生成预期结果吗？ 它可以建议用例，但获批预期行为必须独立依据业务规则。如果实现和预期输出共享同一个错误假设，两者可以一致却都错误。先由负责人确定规则，再据此审查测试数据和最终记录断言。 ### 折扣获批是否意味着报价已经确认？ 本示例不是。批准只更新自定义审核字段，报价仍是草稿。确认及其他后续动作需要自己的明确约定与授权。应写清真实命令允许产生的准确状态并检查它，不能从一次成功审批回复推断报价已确认。 ### 所有 sudo 或显式提交都应自动删除吗？ 先审查用途与边界。高权限操作需要合理授权模型和拒绝路径证据；自行管理的事务需要故障与恢复论证。官方指南解释为何应重点检查这些选择。不了解调用者就删一行，可能引入另一缺陷，应验证替代行为。 ### 空库安装成功能替代既有数据测试吗？ 不能。新数据库没有模块升级后将遇到的历史记录或配置。应批准这些记录的预期处理，并在受保护副本上演练。安装证据与业务状态证据要分开，包括尚待处理及以前已批准的工作将如何变化。 QA 与生产就绪 ## 接下来读什么 可靠生产软件所需的测试、审计、维护与加固。 [从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [README ZIP 恶意软件：审查 AI 工具的实际安装内容](/zh/blog/readme-zip-malware-install-review/) - [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 19 升级 20：AI 工作流要重新验收什么？](/zh/blog/odoo-19-20-ai-upgrade-readiness/) [上一篇文章**README ZIP 恶意软件：审查 AI 工具的实际安装内容**](/zh/blog/readme-zip-malware-install-review/) [下一篇文章**Odoo 迁移验收：逐条核对业务记录与余额**](/zh/blog/odoo-migration-acceptance-reconciliation/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-migration-acceptance-reconciliation/)