AI 生成的 Odoo 模块：先审业务规则，再谈上线

返回

Kevin Riedl

12 分钟 阅读 · 2026年11月5日
最近审核 2026年11月5日

下一篇

折扣审批看起来很小：设置标记，再记录批准人。但下文故意写错的示例会批准已取消报价，相信调用者编造的批准身份，并在注入故障后留下部分修改。普通演示却仍能成功。

应依据获批业务规则和准确的已安装 Odoo 版本，审计 AI 生成的模块。 复现有业务后果的失败，检查最终记录，并独立验证修正。通过本地模型有助于定义检查；真正决定能否上线的，仍是原生安装、授权、事务和升级证据。

资料核查日期：2026年11月5日。 我们审阅 Odoo 20 官方资料，并执行了 13 个虚构审批用例。两份 Python 实现均为本文编写，不是客户代码样本，也不是 AI 工具基准。没有安装 Odoo 插件或执行原生升级，所有建议原生检查仍为 NOT_RUN。

模块审计应该作出什么决定？

审计应判断一项明确的定制是否有足够证据发布、需要有限修复，或应由获批的更简单实现替代。先确定业务命令允许改变什么。代码质量分数不能补上缺失的审批规则，也不能决定谁有权批准该规则。

扩大自定义代码前，让负责人在当前配置中演示需求。如果受支持的现有流程已经满足要求，应把它与持续维护覆盖逻辑的成本比较。这需要在已安装版本上验证，并不是预先认定所有定制审批都没有必要。

随后固定审查范围：模块提交、Odoo 版本与版本类型、依赖修订、受影响记录和执行身份。包括会改变行为的设置。只看 Git 分支、不看必要配置，可能漏掉业务实际使用的路径。

AI 生成代码 QA 指南负责更广泛的生产就绪检查。本文审查单元是一项确定性的 Odoo 定制。代理业务状态指南则覆盖代理的完整任务与工具选择。

审批示例应该实现什么规则？

示例只在执行者有权为该公司审批、折扣处于虚构授权上限内时，批准当前版本的报价草稿，并记录一次可信身份。过期或被禁止的决定必须被拒绝，不留下部分审批，即使失败发生在批次较后的记录上也一样。

虚构报价 Q-17 属于公司 A，版本为 3，初始折扣 5.00%。用户 7 可批准从 0% 到 10.00% 的折扣，含上限。10.01% 需要其他决定。这些是示例业务规则，不是 Odoo 默认值。字段 approval 和 approved_revision 属于 Python 示例。

这里的审批只修改审核字段，不确认报价、不创建交付，也不产生会计过账。这条边界决定“成功”指什么。如果真实模块还执行后续业务动作，应增加该动作的授权及最终状态约定。

先解决规则分歧，再生成预期结果。业务规则冲突指南解释如何分配这项决定。审核人不能仅凭函数已经接受 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 的公共方法安全指南将传入记录与参数视为不可信，CRUD 访问检查不能证明所有业务前提成立。应审查接收调用的方法，而不只是可见按钮。

修正版 Python 先验证选择项，在暂存副本上修改，再替换模型状态。这只模拟所需结果，并没有实现 Odoo 事务。官方开发规范解释框架的事务所有权，以及为何需要审查无明确理由的手动提交。例外情况下自行明确管理的游标，需要另行论证。

下载带注释的发现记录，查看缺陷与复现用例的对应关系。Odoo 20 公司访问迁移测试负责版本相关的权限变化。旧的通用 ACL 清单不足以解释该迁移。

13 个业务规则测试修正前后有何变化？

缺陷版本违反 13 项固定预期中的 11 项；修正版满足全部 13 项。两者都能完成普通审批和恰好达到上限的审批，所以一次成功演示可能隐藏其他缺陷。这些数字仅描述刻意构造的示例，不是 AI 生成 Odoo 代码的缺陷率。

下载可运行审批审查示例及完整预期与观察状态。保存 Python 文件后运行：

python3 approval-review-model.py

脚本使用 Python 标准库，并用十进制比较检查虚构百分比规则。它不导入 Odoo，也不访问网络。预期状态由业务约定独立定义，不依赖任一审批函数。输出包括错误和最终审批字段，仅抛出异常，不能让部分写入看起来正确。

模型没有测试原生并发请求。两个调用者并行批准同一版本时，真实方法可能还需其他保护。n8n 恢复文章讨论外部订单创建的独立边界；本示例的重复审计效果，不能证明连接器具备幂等性。

真实 Odoo 模块还必须验证什么？

将模型结论应用于 Odoo 前，应在实际构建中验证真实入口和受影响记录。审查覆盖逻辑及依赖，再通过接收方法执行获批业务用例。确认每次修改的身份。孤立函数即使满足约定，也可能与应用集成错误。

建议的原生验收包包含这些关卡及业务规则用例，初始状态为 NOT_RUN，政策批准仍待完成。将示例预期替换为获批规则，记录准确身份与版本，并附上实际证据后才能认定通过。

审查每项覆盖逻辑时，应把标准行为放在旁边比较。没有解释的替换意味着还要查明移除了什么。如果只需要增加一个决策检查，应考虑是否能采用更窄的扩展，而非替换完整流程，再用受影响标准用例验证该判断。

安装和升级证据应该怎样检查？

将安装、升级和运行行为视为独立关卡。空库安装可发现依赖缺失；既有数据演练覆盖变化前的记录与配置。两者都不能证明正确业务测试已运行。报告必须绑定准确模块提交、目标环境和所选用例。

Odoo 的测试文档要求导入测试模块，并说明启用和选择如何决定执行。应索取标明预期测试的运行输出。命令显示绿色，但相关用例未执行，其行为仍未验证。

定制数据库升级指南区分空库安装、升级数据上的安装及运行演练。本文 Python 执行没有提供其中任何原生结果。

针对该审批定制，应纳入尚未填写新审批字段的旧报价、业务内容已变的已批准报价，以及升级开始时仍待审的记录。演练前先决定目标状态。默认值让旧记录看起来已批准，是业务决定，不应只是消除报错的捷径。

为演练保留受控恢复方案。仅回退代码，不能证明数据修改也已撤销。迁移对账指南覆盖更广范围的预期与观察比较。

审计交付应包含哪些内容？

每项发布决定都应能追溯到获批规则和可复现证据。对每个阻断项，记录受影响版本、复现步骤和业务后果，再附上修正及独立复测。未执行检查必须保持可见。文字风格建议清单，无法回答报价是否可能被越权批准。

示例发现记录将已确认的本地规则失败，与仍需执行的原生问题分开。真实审计也应保持这一区别。“模型拒绝旧审批”和“部署的 Odoo 方法在这些身份下拒绝旧审批”，是不同证据陈述。

修复实现与批准政策也应分开。审核人可以证明函数执行了 10.00% 上限；业务负责人决定这是否是预期授权。若审查期间规则改变，应修订预期结果，并按新约定重跑受影响用例。

发布前 QA 清单提供整体上线背景。AI 构建软件的通用审计指南介绍更大范围的审计；本模块审查应保持较窄、可测试的边界。

什么时候应发布、修复或移除定制？

只发布获批原生证据支持的范围。修复已证明的规则违例，并复测受影响流程。如果获批的受支持替代方案满足需求，可考虑移除不必要定制，但必须安排既有数据。漂亮演示不能决定这三种选择。

建议从一个有实际后果的命令、它的真实入口，以及一对允许／拒绝用例开始，再加入可能留下错误业务记录的失败情形。这样，审计在扩展到仓库所有文件前，就有一项具体决定可作。

讨论 Wavect 的软件质量保障服务时，请准备模块提交、安装版本信息，以及负责人能批准的一条业务规则。有效交付应包含可复现发现、明确原生发布关卡，以及商定修正确实奏效的证据。