你將學到

• 「Coding Agent（AI 程式助理）」及其運作原理
• 了解 OpenAI Codex 與 Cursor 等工具如何加速開發流程
• Odoo 開發實例：在 CRM 模組中新增自訂欄位與按鈕
• 如何運用提示工程、多人成果協作、範本建立等策略，充分發揮 AI 助力開發的潛力

關鍵字

Coding Agent、OpenAI Codex、Cursor AI 編輯器、提示工程

Coding Agent 工具簡介與原理

生成式 AI 出現之後，很快的如何讓 AI 作為代理（Agent）來更好的協助人類工作，成為了當前最熱的戰場。

而在軟體開發領域，Coding Agent 指的是能協助程式設計的 AI 工具，它們透過大型語言模型來理解開發者的指令並自動產生程式碼。知名的例子包括 OpenAI Codex 與 AI 程式編輯器 Cursor。這類工具的運作原理類似於一個隨時待命的AI 程式設計夥伴：理解你的需求，參照龐大的程式碼知識庫，提供即時的程式碼建議甚至自動完成整段程式。

開發者只需描述想要的功能，Coding Agent 就能產生對應的程式碼雛形、打磨、測試，如同有位全年無休且軟體開發技能點滿的隊友來協助你開發。

• OpenAI Codex： Codex 是 OpenAI 基於 GPT 模型專門為程式碼訓練的模型。它能將自然語言指令轉換為多種程式語言的碼段，甚至理解既有程式碼並進行修改。Codex 最初驅動了 GitHub Copilot 等工具，而現在已融入 ChatGPT 平臺供開發者使用。最新的 Codex（如 GPT-5 Codex）更進一步優化了在軟體工程情境中的能力，可以根據任務複雜度調整思考時間，在簡單請求上反應更迅速、面對大型重構時能持續自主運行、迭代測試直至完成。這使得 Codex 不僅會補齊程式碼，甚至能獨立執行較長時間的任務，如整個專案的建構或大型功能增加。

• Cursor AI 編輯器： Cursor 是一款整合了 AI Coding Agent 的程式編輯器。它的特色是在熟悉的 IDE (VS Code-forked) 環境中提供強大的 AI 智能輔助功能。使用 Cursor 時，開發者可以直接以自然語言對話：例如選取一段函式並輸入指令「重構此函式以提高效能」，Cursor 就能理解並提議修改整段程式碼。它也支援自動完成，根據你目前編輯的內容預測下一段程式碼，你只需按下 TAB 即可套用建議。更厲害的是，Cursor 深度結合了你的整個程式碼庫：它可以從既有專案檔案中尋找答案或引用文件，在你需要時提供相關的程式碼片段。這意味著當你在 Odoo 專案中編輯模型檔案時，Cursor 理解 Odoo 框架的常用模式，可以自動補全 ORM 方法或欄位定義，大幅提高編碼效率。

💡 Gary’s Pro Tip｜善用 AI 編輯器的上下文感知能力
在 Cursor 中編輯 Odoo 模型時，不妨把相關的模型類別或匯入的模組打開或引用，AI 將更明確了解你所處的情境，提供更精準的程式碼建議。

MCP 擴展 Agent 能力

這邊需要注意的是傳統 LLM 存在的一些侷限。例如，一般的 ChatGPT 可能因訓練資料時效性而給出過期的文件資訊或無法運行的範例程式碼。對 Odoo 開發者而言，不同版本的 API 差異很大，一段適用於 Odoo 14 的程式碼到了 Odoo 18 可能就不適用了。如果 AI 模型沒有參照最新的官方文件或版本資訊，開發者可能需要花時間檢驗和修正 AI 輸出的結果。

幸運的是，新一代的 Coding Agent 工具開始引入外部知識整合。例如上節提到的 Cursor 或 Codex Cli，都可以引入像 Context7 這類 MCP 代理伺服器，可以讓 LLM 即時查詢對應版本的 Odoo 文件。透過這種方式，AI 助手能提供更準確、符合當前環境的建議，減少我們與過時資訊「角力」的時間。

因為這系列主題不是講解 AI Agent，所以就不多著墨 MCP 了（如果有想要了解的讀者歡迎下面留言按讚讓我知道！😎）。

Odoo 開發情境範例：自訂 CRM 欄位與按鈕功能

讓我們將焦點轉向一個實際的 Odoo 開發情境。假設你收到一項需求：在 Odoo CRM 中新增一個「潛在客戶等級」自訂欄位，並在客戶表單上增加一個按鈕，一鍵將該潛在客戶標記為重點對象。這個需求涉及到後端模型與前端視圖的調整，也就是我們需要建立一個自訂模組來擴充 Odoo CRM 模組的功能。

回顧 Odoo 模組開發的基本流程，我們通常需要以下步驟：

1. 建立模組結構： 使用 odoo-bin scaffold 指令產生模組樣板，或手動建立目錄和必要檔案。例如本例中我們的模組可命名為 crm_lead_ext，包含 __manifest__.py（模組描述）、models/ 資料夾及其內的 Python 檔案，以及 views/ 資料夾下的 XML 檔案等。
2. 撰寫模型（Model）擴充： 在 models/crm_lead_ext.py 中撰寫 Python 類別去繼承 Odoo 內建的 CRM 潛在客戶模型（crm.lead）。我們會在類別中定義一個新的欄位，如 x_priority_level = fields.Selection([...], string="潛在客戶等級")，以及一個方法 action_mark_important 來處理按鈕點擊時的邏輯（例如將該欄位設為特定值，或觸發其他業務操作）。
3. 撰寫視圖（View）定義： 在 views/crm_lead_ext_views.xml 中，我們透過繼承既有的 CRM 表單視圖，加入一個新的欄位欄位顯示，以及一個按鈕元件。按鈕將綁定前述定義的方法（使用 type="object" 呼叫 server 動作）。
4. 載入並測試： 將模組安裝到 Odoo 中，觀察表單上是否出現新欄位和按鈕，點擊按鈕確認其功能是否如預期。

上述流程對有經驗的 Odoo 開發者或工程師來說並不陌生，但編寫這些樣板式的程式碼與 XML 常常繁瑣且容易因小細節出錯。如果有 AI 工具的輔助，這部分工作能否變得輕鬆？接下來，我們將嘗試使用 Codex 與 Cursor 來從需求自動生成程式碼，看看結果如何。

示例(偽代碼)：用 Cursor 生成 Odoo 程式碼

讓我們把 Coding Agent 真正應用在上述 Odoo 開發情境中。我們將透過 Cursor 編輯器內建的 AI 助手（其背後可由 OpenAI Codex 或 GitHub Copilot 提供支援）來完成以下任務：

• 在 crm.lead 模型中新增名為 x_priority_level 的 Selection 欄位（選項例如「一般」、「重點」）。
• 添加一個按鈕，點擊後執行 Python 方法將該潛在客戶標記為「重點」（將欄位值設為相應選項，僅作示範）。

步驟 1：撰寫提示（Prompt）

首先，我們在 Cursor 中開啟一個新的 Python 檔案（預計放置模型定義）。接著以自然語言輸入開發需求，例如：

# prompt
建立一個 Odoo 模組繼承 CRM 潛在客戶 (crm.lead)，加入一個 Selection 欄位 x_priority_level（選項 'normal' 和 'important'），預設為 'normal'。並添加一個按鈕「標記為重點」，按下後執行 action_mark_important 方法將該記錄的 x_priority_level 設為 'important'。

這段提示清楚描述了我們希望達成的功能，包括模型繼承目標、欄位類型與選項、以及按鈕及其對應方法的行為。完善的提示是成功的關鍵 —— 詳細說明欄位類型（Selection）及取值，有助於 AI 產生正確的欄位定義和常數。許多開發者分享經驗指出，提供明確的規範和上下文（例如指定 Odoo 版本或模型名稱）能顯著提升 AI 產出的品質，使其更貼近需求且符合框架規範。

步驟 2：觀察 AI 產出模型程式碼

在我們輸入提示後，Cursor 隨即開始生成程式碼。例如：

from odoo import models, fields, api

class CrmLead(models.Model):
    _inherit = 'crm.lead'

    x_priority_level = fields.Selection(
        [('normal', 'Normal'), ('important', 'Important')],
        string="潛在客戶等級", default='normal'
    )

    def action_mark_important(self):
        for record in self:
            record.x_priority_level = 'important'
            # 可以在此處加入其他業務邏輯，例如發送通知或建立紀錄
        return True

上述程式碼片段就是 AI 根據提示自動生成的結果（經過整理以利閱讀）。可以看到，Coding Agent 已幫我們：

• 匯入了必要的 Odoo 模組 models, fields, api。
• 建立繼承 crm.lead 的類別，並定義了 x_priority_level 欄位，包含選項及預設值。
• 定義 action_mark_important 方法，將每個記錄的 x_priority_level 設為 'important'。這裡還預留了擴充點（註解）以便我們加入更多邏輯。

值得注意的是，AI 產出的程式碼相當符合預期且風格與 Odoo 官方範例一致。Selection 欄位的 tuple 清單、default 值以及方法操作 ORM 的寫法都很正確。

步驟 3：觀察 AI 產出視圖 XML

接下來，我們要求 AI 生成對應的 XML 視圖來呈現新欄位和按鈕。在 Cursor 中開啟一個 XML 檔案（放置於 views/crm_lead_ext_views.xml），輸入提示：

# 輸入對 XML 視圖的需求
在 CRM 潛在客戶表單視圖中繼承原有視圖，加入 x_priority_level 欄位（放在某個頁籤或主要欄位區），以及一個標題為「標記為重點」的按鈕，按鈕點擊調用 action_mark_important 方法。

AI 隨即給出了 XML 定義片段，例如：

<odoo>
  <data>
    <!-- 繼承 CRM 潛在客戶的主要表單視圖 -->
    <record id="view_crm_lead_form_inherit_priority" model="ir.ui.view">
      <field name="name">crm.lead.form.inherit.priority</field>
      <field name="model">crm.lead</field>
      <field name="inherit_id" ref="crm.crm_lead_view_form"/>
      <field name="arch" type="xml">
        <!-- 在表單視圖的字段區域內加入新欄位 -->
        <field name="partner_id" position="after">
          <field name="x_priority_level"/>
        </field>
        <!-- 在頁面頂部的按鈕區域加入新按鈕 -->
        <header>
          <button name="action_mark_important" type="object" string="標記為重點" class="btn btn-primary"/>
        </header>
      </field>
    </record>
  </data>
</odoo>

以上 XML 將 crm.lead 原始表單（通過 inherit_id 參照）做繼承，在合作夥伴欄位後面插入了我們的新欄位，並利用 <header> 標籤在表單標頭區塊新增一個按鈕。按鈕透過 name="action_mark_important" 綁定我們在模型中定義的方法，並設置了樣式與顯示文字。

💡 Gary’s Pro Tip｜提供程式碼片段精準定位
在讓 AI 生產 Odoo XML 時，可以提供已有視圖的片段或至少指出插入位置的元素，例如「在 partner_id 欄位後加入...」。這能降低 AI 在猜測 XPath 定位時出錯的機率，生成更精確的視圖定義。

步驟 4：整合與測試

透過 AI 的協助，我們幾乎不用手寫太多程式碼就得到了完整的模組定義。接下來只需要將 AI 生成的 Python 和 XML 內容填入相應檔案，補充 __manifest__.py 等模組資訊，安裝模組後就能在系統中看到效果。實際安裝測試中，新欄位「潛在客戶等級」成功出現在 CRM 潛在客戶表單，預設值為「Normal」，而點擊「標記為重點」按鈕後，該記錄的狀態也更新為「Important」，符合我們的預期。

為了衡量 AI 助力的價值，我們將這次AI 產出與人工撰寫進行簡單比較：

• 開發速度： 使用 AI 從需求到寫出模型和視圖，大約幾十秒到一兩分鐘內就完成初稿；相較之下，人工從頭建立模組可能需要 10-30 分鐘不等（需查欄位用法、確認 XML 語法等）。AI 明顯加快了原型實現的速度。
• 程式碼品質： AI 產出的碼遵循了 Odoo 框架慣例，初步看相當整潔正確。然而在人工審查時，我們還是發現一兩處細節需要調整：例如 AI 產生的 XML 插入點一開始放錯了頁籤位置，後來我們根據實際 UI 調整到適合的位置；又如 action_mark_important 方法中，為保險起見我們改用 write 方法批量更新欄位而非逐筆賦值。這些修改屬於小幅調整，顯示 AI 結果已相當接近可用水準，只需要經驗豐富的開發者花點時間後處理即可完善。
• 後續維護： 值得慶幸的是，AI 協助產生的程式碼可讀性不錯，變數命名、欄位定義皆合乎常理，後續維護者不會看不懂。然而由於 AI 並非專案上下文中的人，它無法替我們決策所有細節（例如安全權限設定、進階的業務條件），這部分仍需開發者自行補充。因此，把 AI 當作輔助產生樣板碼、減少重複勞力是恰當的定位，真正的業務邏輯和細節則由我們掌控。

透過將 AI 整合開發環境並連結 Odoo 文件，能一鍵生成包含模型、視圖在內的模組骨架程式碼，免除手工查找文件的時間。然而，結果仍需經過人工驗證和測試，確保符合特定版本的正確性。透過這樣的 Coding Agent，我們從需求描述直接跳躍到可執行的代碼，大大縮短了實作循環。

AI 助力開發流程的策略與潛力分析

經過上述示範，我們體驗了 Coding Agent 在開發階段的強大威力。那麼，如何將這種助力最大化？以下我們從策略與潛力兩方面進行分析：

1. 提示工程（Prompt Engineering）的技巧

AI 給出的程式碼好壞，與我們提供的提示描述息息相關。提示工程是一門學問，強調如何精確地向 AI 表達需求。對 Odoo 開發而言，建議在提示中明確包括：

• Odoo 版本（例如 Odoo 16 或 Odoo 18），因為模型/欄位可能隨版本異動。
• 具體的 模型名稱 或技術名詞，例如 "crm.lead", "res.partner"，避免語意模糊。
• 產出形式，例如要 Python 模型代碼還是 XML 視圖，抑或兩者都需要。
• 風格偏好 或限制，例如「遵循 PEP8 標準格式」或「避免使用舊版 API」。

這些細節能引導 Coding Agent 輸出更符合期望的內容。如果第一次生成結果不理想，可以嘗試分段詢問：先請 AI 產生模型類別，再請它產生視圖 XML，逐步細化。此外，善用範例驅動的方法也是訣竅之一：如果有類似功能的程式碼片段，可包含在提示裡供 AI 參考學習。

2. 多人協作與 AI 聯合開發

引進 AI 工具後，團隊協作方式也可相應調整。舉例來說，一個開發小組可以共用一組標準提示模板：針對常見任務（如建立模型欄位、撰寫 Compute 方法、產生報表樣板）整理出有效的提示語句，方便成員複用，保持程式風格一致性。

還有團隊嘗試為 AI 助手設定多種「角色」或子代理（Sub-Agents）─每個子代理專精不同任務，例如有的負責產生新功能碼、有的專職程式碼審查與優化。開發者可以在發送請求時指定由哪個子代理處理，獲得更針對性的協助。例如，當我們完成一個模組開發後，可以呼叫「Code Review Agent」來檢查潛在問題；當我們想編寫測試時，可以請「Test Agent」生成測試樣本。這種多人+AI 協作模式猶如把AI升級成團隊中的多位專家顧問，各司其職又能互相補強。

3. 建立專案範本與知識庫

AI 的另一大潛力在於知識傳承。在 ERP 開發中，每家公司都有特定的客製模式和範本。如果我們能將這些慣用範式輸入AI的知識庫（或在提示中提供例子），那 AI 下次就能直接產生符合自家風格的程式碼。

想像建置一個內部範本庫：包含各種 Odoo 功能模組樣板（從簡單的資料模型，到複雜的工作流程、自動化腳本）。當有類似需求時，AI 透過檢索範本庫，很快就能組合出新的解決方案。此外，結合版本控制與文件，AI 還可以成為即時文件助理：在撰寫程式時自動附上相關文件連結，或幫忙更新技術文件內容，使開發與文件同步進行。

💡 Gary’s Pro Tip｜Context is All You Need
使用 Agent 的時候，提供優質且資訊充足的上下文，可以讓 Agent 的輸出品質，大幅提升。

4. AI 助手的未來潛力：

AI 助力開發並不僅止步於寫程式碼。未來，我們可能在 Odoo 的各個層面看到 AI 的蹤影。例如：

• 自動除錯與測試： 當出現錯誤時，Coding Agent 可以根據錯誤日誌自動定位問題程式碼，甚至提議修改方案；在測試方面，AI 可依據模組邏輯產生單元測試或整合測試案例，提高品質保證的效率。
• 使用者操作智能化： Odoo 19 企業版已經傳出將內建 AI Agent 來協助使用者，例如摘要聊天紀錄、翻譯內容等這意味著開發者也許能以類似技術構築對話式的系統操作，讓終端使用者透過語言指令驅動 ERP 操作（例如「生成本月的銷售報表」AI 就幫忙調用相應功能）。
• 更深的框架融合： Odoo 社群也開始關注 AI 的結合，像 OCA (Odoo Community Association) 就有專門的專案在研發 AI 結合的套件。未來可能出現更多 plug-and-play 的 AI 模組，讓開發者能輕鬆將 LLM 功能嵌入自家應用，例如智能客服機器人、即時語意分析等。

今日結語

從本篇實例可以看到，Coding Agent 正在改變 Odoo 開發的遊戲規則：從需求到程式碼的過程被大幅壓縮。

我們只要善用這些 AI 工具，繁瑣重複的樣板工作將不再是負擔，取而代之的是更高層次的架構思考與業務邏輯設計。當然，AI 產生的程式碼並非毫無瑕疵的終極答案，依然需要開發者運用專業知識去檢驗、調整。但這正符合 AI 助手的角色定位——它為我們節省80%的機械性工作，讓我們有更多時間投入那關鍵的20%創造性任務。

今天探討了 Coding Agent 在 Odoo 開發各環節的應用藍圖。從理解需求、分析設計，到今天展示的程式碼產出，再到沒詳細深入的測試、部署與持續改進，每一步都充滿了 AI 可以施展拳腳的空間。

身為中階開發者的你，或是剛入門的 Odoo 技術顧問，趁早擁抱這股 AI 浪潮將使你在未來的專案中如虎添翼。在下一篇文章中，我們將延續這個主題，探索如何將 AI 更進一步融入 Odoo 開發流程的其他面向，敬請期待！