用API Key将你的Odoo连接到Claude，无需编写Python即可创建自己的视图

Facebook上「Odoo México」小组里的一个帖子提醒了我们一件令人不适的事：在顾问上门报价数千美元之前，开源社区早就解决了这个问题。这里是具体做法，适用于任何版本、任何版次的Odoo，也是几乎没人告诉你的那些缺点。

起因：一个合理的问题和八个昂贵的回答

在Facebook的Odoo México小组里，有人问了一个我们许多人都曾想过的问题：

「谁有一个能为Odoo Community用AI查询报表的模块？」

回答都在意料之中：「我很乐意为你开发」「我们有一个已经在用了」「你好，我们很乐意帮你」「可以给你个好价钱」。一个社区在做它最擅长的事：报价。

而在帖子中间，出现了那句很少有人愿意大声说出来的回答：

「你为什么不直接生成API Key，把它交给任意一个AI代理，让它帮你建立与MCP的连接并做出自定义视图呢？」

任何版本的Odoo。任何版次。无需安装第三方模块。无需报价。无需编写哪怕一行Python。

这篇文章就是那个回答的完整而诚实的长版本。有的，是分步操作指南，但也有大多数帖子跳过的那些小字：你引入的技术债、你制造的依赖、你可能在不知不觉中触发的Odoo收费，以及为什么这并不取代一位好顾问，而是赋能于他。

Odoo原本自带、却几乎没人用的东西

在教程之前先说一句：Odoo多年来一直在「技术」菜单里附带一套工具箱，而大多数用户并不知道它的存在：

• 自定义视图：列表、看板、表单、透视表、图表、日历。
• 字段：向现有模型添加计算字段或关联字段。
• 模型：检查数据的真实结构。
• 菜单项：把你的视图挂到一个可见的位置。
• 用户过滤器：保存你每个周一都在用的那个过滤条件。

这些都不需要Python。它们由XML和QWeb组成，而QWeb就是拥有超能力的HTML。如果你让一个语言模型帮你编写那个视图，它会毫无问题地写出来，因为十多年来Odoo的公开语料库里到处都是这类内容。

那个会被报价数千美元的「AI报表模块」，在大多数情况下，恰恰就是把这些东西包进一个manifest里而已。

图表源码（Mermaid）

mindmap
  root(("Odoo的
技术菜单"))
    用户界面
      自定义视图
      菜单项
      用户过滤器
    数据结构
      模型
      字段
      字段选择
    全部无需Python
      XML和QWeb

图表源码（Mermaid）

flowchart LR
    U(["用户"]) -->|"1. 生成"| K["Odoo中的API Key\n个人资料，偏好设置，安全"]
    K -->|"2. 配置"| M["AI代理 + MCP服务器"]
    M -->|"3. 读取真实结构"| S[("模型与字段\nfields_get / list_models")]
    S --> M
    M -->|"4. 编写"| V["自定义视图\nXML / QWeb，无需Python"]
    V -->|"5. 在浏览器中验证"| U

教程：如何自己一步步连接起来

图表源码（Mermaid）

flowchart LR
    P1["步骤1\n生成API Key\n个人资料，偏好设置，\n安全"] --> P2["步骤2\n将Odoo的MCP\n连接到代理"] --> P3["步骤3\n用中文\n描述视图"] --> P4["步骤4\n在浏览器中\n验证"] --> P5["步骤5\n保存变更的\n记录"]
    style P4 fill:#E14228,stroke:#E14228,color:#FFFFFF

步骤1：在Odoo中生成你的API Key

在Odoo里，用你的账户：个人资料，偏好设置，账户或安全标签页，新建API Key。

给它起一个有描述性的名字（例如，claude-mcp-septiembre2026）。Odoo只会向你显示一次这个key，请立刻把它复制到密码管理器里。如果丢了，你可以再生成一个；它是不可恢复的。

它在Community、Enterprise、Odoo Online和Odoo.sh上都能用。它在v14、v15、v16、v17、v18和v19上都能用。这是一个原生机制，不是什么取巧的手段。

步骤2：在你的AI代理中登记一个Odoo的MCP

MCP的意思是Model Context Protocol，这是把AI代理与真实系统连接起来的开放标准。

选择你的技术栈所支持的连接器：

• 一个运行在Docker中并暴露常见操作（odoo_search_read、odoo_fields_get、odoo_list_models、odoo_create、odoo_write、odoo_execute）的Odoo MCP服务器。这是我们在Transgenia内部采用的方式。
• 面向Claude Desktop、Cursor或VS Code的更轻量的XML-RPC封装器。

你的MCP需要四项数据：

ODOO_URL=https://tu-instancia.odoo.com
ODOO_DB=nombre-de-tu-base
ODOO_USER=usuario-que-genero-la-key
ODOO_API_KEY=la-key-del-paso-1

步骤3：用中文向AI描述你想要什么

一个真实有效的指令示例：

「在销售模块里，创建一个报价单的列表视图（处于「已发送」状态的sale.order），筛选出创建至今超过7天的，按销售员和按行业标签分组。列：编号、客户、销售员、总金额、自发送以来的天数。把它挂到菜单：销售、报表、停滞的报价单。」

代理会做三件事：

1. 查询真实的结构（对sale.order执行fields_get），以免编造出不存在的字段。
2. 生成视图的XML、窗口动作和菜单项。
3. 直接通过API写入，或者交给你，让你手动粘贴到「自定义视图」里。

步骤4：在相信之前先验证

这是一半的教程都省略的一步。在认定视图没问题之前：

• 打开菜单，在浏览器里浏览这个视图。
• 确认各列显示的是真实数据（不是空值，也不是报错）。
• 应用筛选和分组；确认它们是按你要求的字段分组，而不是按某个看起来相似的其他字段。

如果有什么看起来不对劲，就让代理回读它刚创建的那个视图。是的，AI会出错。区别在于，现在你用两条消息就能纠正它，而不用等一个咨询工单等上两周。

步骤5：保存变更的记录

在某个地方（一个文档、一份内部笔记）记下：你创建了哪个视图，用的是什么指令，在什么日期，以及哪个用户持有这个API Key。这一步看起来是可选的。它不是。缺点那一节会向你解释原因。

令人不适的思考：传统顾问的食利

这里是文章变得沉重的地方，所以我直说了。

一位在Odoo领域有十年经验的资深顾问读到这里，可能会同时感受到两件事：

1. 「他们在砸我的饭碗。」为一个报表模块开出五千、八千、一万五千美元的账单，而一个高级用户用一个AI代理和一个API Key，在一个下午就能把它复制出来。
2. 「我终于可以不用再卖这个了。」因为在内心深处，为一个自定义视图收取几十个小时的费用，从来不是一个人当初学习系统架构时所设想的工作。

开源社区多年来一直在推荐这条路。自定义视图、Enterprise里的Studio、JSON-RPC API、无需Python的XML开发：这一切早在十多年前就写在Odoo的官方文档里了。在2024年和2025年改变的，是出现了一种工具，即带MCP的AI代理，它把编写那段XML的成本从「一位有多年经验的顾问」降到了「一位有耐心、会提好问题的高级用户」。

这个变化并没有消灭严肃的咨询。严肃的咨询是数据架构、流程决策、安全、访问权限控制、迁移、与SAT和CFDI的集成、财税纪律、ERP治理。所有这些依然需要一个有判断力的人。

它确实消灭的，而且是好事，是那种食利型的咨询：为今天只需一次点击、一条指令和一个原生菜单就能完成的事按小时收费。那些抱着这个模式不放的顾问、开发者和技术项目经理，将要面对越来越自主的终端用户的竞争。而那些进化到治理、架构和判断层面的人，会比以往任何时候都赚得更多，因为市场终于要能分辨出这两者的区别了。

图表源码（Mermaid）

flowchart TD
    C["Odoo顾问的工作"] --> R{"哪一类工作？"}
    R -->|"食利型"| X["按小时收费做一个视图\n或临时报表"]
    R -->|"专业型"| K["架构，安全，\n迁移，ERP治理"]
    X --> XD["由拥有AI的\n高级用户吸收"]
    K --> KP["仍然需要\n人类判断"]
    style XD fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style KP fill:#14532d,stroke:#3ba55d,color:#FFFFFF

优点，简而言之

• 速度：以分钟计，而非以周计。
• 无供应商锁定：你不依赖一个封闭模块，它也许熬不过下一次升级。
• 对话式迭代：你提要求，你看结果，你做调整，没有工单那套繁文缛节。
• 一切都在核心之内：你不会把第三方的Python代码塞进你的实例。
• 可移植性：视图和其他任何原生视图一样，存放在ir.ui.view里。

缺点：几乎没人告诉你的那些小字

这一节才是这篇文章真正存在的理由。优点到处都有人推销给你；缺点，则很少。

图表源码（Mermaid）

mindmap
  root(("Odoo中的
API Key + AI"))
    优点
      速度
      无供应商锁定
      对话式迭代
      在核心之内
    缺点
      技术债
      依赖个人电脑
      可计费的LoC
      访问权限控制

图表源码（Mermaid）

flowchart TD
    A["你向AI请求一项更改"] --> B{"需要Python吗？"}
    B -->|"否：XML / QWeb / 视图"| C["安全\n不计为LoC"]
    B -->|"带简单safe_eval的Studio"| C
    B -->|"是：server action中的\ndef / class / import"| D["Odoo将其\n计为代码行"]
    D --> E{"你在Odoo Online\n或Odoo.sh上吗？"}
    E -->|"是"| F["可能被Odoo SA\n计费"]
    E -->|"否：Community自托管"| G["不计费，\n但属于技术债"]

1. 看不见的技术债

一个通过与AI对话创建的视图，并不存放在git仓库里。没有diff，没有同行评审，除了那条记录的write_uid和write_date之外，没有「谁在什么时候、为什么改了什么」的历史。

在实践中这意味着：

• 在做版本迁移时，这些个性化可能会悄无声息地损坏，而没人知道该去哪里找。
• 当实例增长到几十个甚至几百个这样创建的视图时，就没有一种健康的方式去审计它们了。
• 自动化测试覆盖不到它们，因为在你的持续集成里它们并不作为代码存在。

这就等同于在一栋没有图纸的房子上加盖：能用，直到需要改造的那一天。

图表源码（Mermaid）

flowchart LR
    subgraph IA["通过对话创建的视图"]
      I1["无git仓库"] --> I2["无diff无审查"] --> I3["迁移：\n悄然损坏"]
    end
    subgraph GIT["受版本控制的模块"]
      G1["存在于git中"] --> G2["Diff，PR，测试"] --> G3["迁移：\n可复现"]
    end
    style I3 fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style G3 fill:#14532d,stroke:#3ba55d,color:#FFFFFF

2. 依赖机主的电脑

这是最被低估的一点。API Key存放在你的机器上：在你本地MCP的配置文件里，在Claude Desktop的配置里，在你编辑器的mcp.json里。存放在一台具体的、实体的笔记本电脑上，而它是会坏的。

后果：

• 如果做修改的AI代理运行在实例机主的笔记本上，那就没有高可用性，没有对话上下文的备份，一旦那台机器坏了，「当初是怎么做的」就丢了。
• 它不是一个带服务水平协议的服务。它是一台个人机器上的本地配置。
• 如果那个人带着他的笔记本离开了公司，组织对已经做过的那些个性化就完全失明了。

这不同于一个第三方模块，后者至少和它的manifest一起存放在addons里，也不同于一位外部顾问所做的改动，后者至少留下一个关闭的工单和一张发票作为痕迹。

3. 对Odoo的责任：那出了名的代码行

这是在原帖里出现的那一点，值得单独一段。

在Odoo Online（SaaS）和Odoo.sh里，根据Odoo SA的商业模式，修改会被计入，并且可能作为个性化被计费。实用的操作规则：

• 自定义视图（纯XML，背后没有带Python的server action）：安全，不计为代码行。
• 带简单可视化逻辑的Studio（过滤、用safe_eval做的计算）：一般来说，安全。
• 带Python的server action（def、class、import、复杂函数）：这些Odoo会把它们计为代码行，并且有可能被计费。
• 带代码的自动化：同理。

如果你让AI通过给你写一个三十行的Python server action来「解决」一个复杂的计算，恭喜你：你刚刚制造了技术债，还额外产生了一笔对Odoo SA的可变成本。

一个来自原帖本身的建议：如果Odoo试图为个性化向你收取代码行费用，就向他们索要不含HTML行数的审计报表，因为HTML、XML和QWeb不应该被算作Python代码，而那份报表能让你看清最原始的账单。

4. 访问权限控制：影响范围的问题

Odoo的API Key会继承生成它的那个用户的全部权限。这就是它的设计。在标准的Odoo里，没有按操作细分的权限。

后果：

• 如果这个API Key是由管理员生成的，而你把这个key交给一个运行在连接互联网的MCP服务器上的AI代理，那么一旦泄露，影响范围就是整个ERP：发票、客户、员工、会计，全部。
• 一个拥有管理员权限的代理，可能因为意外或因为一次指令注入，对关键模型执行删除操作。

不可商量的最佳实践：

1. 创建一个专用用户，例如[email protected]。
2. 给它分配最小的用户组：能只读的地方就只读，只在它需要的模型上给写权限。
3. 从那个用户生成API Key。
4. 永远不要使用管理员用户的API Key。
5. 每60到90天轮换一次这个key。
6. 记录是哪个代理、哪台机器在使用它。

图表源码（Mermaid）

flowchart TD
    subgraph MAL["有风险"]
      A1["管理员的API Key"] --> A2["代理继承\n全部权限"] --> A3["影响范围：\n整个ERP"]
    end
    subgraph BIEN["推荐做法"]
      B1["专用用户ai-bot"] --> B2["最小权限，\n仅需所需"] --> B3["影响范围：\n受限"]
    end
    style A3 fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style B3 fill:#14532d,stroke:#3ba55d,color:#FFFFFF

5. 可复现性与环境

对于一个通过对话创建的视图，没有从staging到生产的通路。如果你的实例损坏了，你恢复了两周前的备份，那么在那个日期之后创建的所有视图都会消失，除非你手动导出了它们，或者记录了它们的原始指令以便重新生成。

在一个受git管理的传统模块里，一次checkout就能复现出那个状态。这里不行。

6. 知识的连续性

如果那个与代理对话创建视图的用户离开了公司，谁也不知道他用了什么指令，存在哪些计算字段，什么依赖于什么。没有刻意的文档，每一个这样创建出来的个性化都是一个小小的黑箱。

7. 结构幻觉

一个无法访问真实结构的代理，可能会编造出不存在的字段。视图要么编译失败，要么编译成功却对所有内容都显示为空。最佳实践：让代理在编写之前始终对照真实模型做校验。成熟的连接器暴露了这个能力；请用它。

什么时候该用、什么时候不该用这个模式

图表源码（Mermaid）

flowchart TD
    Q{"你要构建什么？"} -->|"临时报表，\n试点，原型"| SI["自己动手"]
    Q -->|"关键流程，CFDI，\n安全，正式上线"| NO["由专业人员\n陪同"]
    SI --> SI2["有判断力的\n超级用户"]
    NO --> NO2["顾问 + ERP\n治理"]
    style SI fill:#14532d,stroke:#3ba55d,color:#FFFFFF
    style NO fill:#7a2018,stroke:#E14228,color:#FFFFFF

什么时候该用：

• 快速试点、原型、在购买咨询之前的价值验证。
• 超级用户（分析师、controller、部门主管）的临时报表。
• 不适用Odoo SA收费的Community自托管实例。
• 团队内部的探索和培训。

什么时候不该用，若没有专业陪同：

• 有多个用户在生产环境中的关键流程。
• 触及安全、CFDI、会计或财税义务的更改。
• 任何需要正式上线、用户培训和回滚方案的更改。
• 尚未阅读个性化条款的Odoo Online实例。
• 任何高级用户并不真正理解AI刚刚写了什么的情况。

顾问、开发者和技术项目经理的真正角色

我以此收尾，这也是Transgenia为什么把这篇文章发布出来、而不是藏着掖着的原因。

这项技术不取代严肃的顾问。它赋能于他，让他不必再为今天只需一次带监督的点击就能完成的事收取咨询费。

而且它把技术项目经理和资深开发者解放出来，去做那些确实需要判断力和经验的工作：

• 数据架构和流程架构。
• ERP治理：谁可以做什么。
• 版本之间的迁移，且不丢失个性化。
• 与SAT、银行、marketplace、产品目录的集成。
• 财税审计和CFDI审计。
• 运营纪律的设计：变更如何记录、如何测试、如何部署、如何回滚。

在Transgenia，我们采用的正是这个模式：一个通往Odoo的MCP连接器，一个拥有最小权限的专用用户，以及一位人类顾问来治理代理所写的一切。不是为了给我们自己省下计费的工时，而是为了把它们释放到那些确实能长期创造价值的工作上。

如果你要自己试试，欢迎入伙：你已经知道该怎么开始了。而如果哪天视图搞坏了生产环境、Odoo开始向你收取代码行费用、或者API Key泄露了，那时候，确实值得打一通电话。而那，恰恰就是那份不会消失的工作。

常见问题

关于作者与 Transgenia

Efraín Carreón Ortiz 是 Centrum Transgenia（一家墨西哥技术精品公司）的总经理（Director General）。他持有由 Anthropic 颁发的官方 Claude Code 徽章（Claude Partner Badge），可在 Credly 上验证。

Transgenia 是 OpenAI Partner Network 中的 OpenAI Select Partner，也是 Anthropic Claude Partner Network 的注册合作伙伴。我们在自有生产环境中运营着十二个受治理的 AI 代理，并在医疗和 B2B 领域支持可验证的落地实施。

联系我们：LinkedIn、预约 15 分钟，或访问联系页面。

继续阅读

• Transgenia 如何用受治理的 AI 代理运营：这一模式背后的治理体系（draft-first、人工签核、MCP）。
• 在企业中分阶段部署 Claude：实战指南：来自 Anthropic 注册合作伙伴的完整落地方法。
• 我们的 AI 解决方案 与 Transgenia 作为 OpenAI Select Partner。