AI 生成代碼的陷阱：從 Odoo 模組開發看「架構師」的真實價值
嶼點科技 | 2025-01-18
在軟體開發的領域裡，AI 輔助編程已是標配。但作為 Odoo 技術顧問，我常被問：「既然 AI 都能寫程式了，為什麼還需要資深架構師？」 為了回答這個問題，我們進行了一場實戰實驗：讓 DeepSeek、Gemini 與 Qwen 同時開發同一個模組，結果令人深思。
🧪 實驗背景：不只是一個 CRUD
我們的需求看似簡單，實則考驗對 Odoo 框架的理解：
- 停車位管理：區域、價格、車位數。
- 合約管理：需記錄車主資訊、租期、車牌。
- 財務整合：租金收取與押金管理。
關鍵挑戰在於：如何將這些新功能與 Odoo 原有的銷售 (Sales) 與會計 (Accounting) 模組完美融合？
🔍 選手一：DeepSeek
工整的「孤島製造者」DeepSeek 展現了極佳的工程師素養。它生成的目錄結構非常標準，從 mkdir 指令到權限設定檔都寫得一絲不苟。
代碼檢視：
[cite_start]# DeepSeek 的方案 [cite: 6] class ParkingLot(models.Model): _name = 'parking.lot' # 全新模型 # ... 欄位定義 ... # 它並沒有繼承 sale.order，而是自創了合約模型 class CustomerContract(models.Model): _name = 'customer.contract' # ...
DeepSeek 選擇了「從零開始」。雖然短期內很安全，但在 ERP 實務中是下策。因為這個新合約與 Odoo 原生的
sale.order 毫無關聯，創造了典型的「資料孤島 (Data Silo)」。
🚫 選手二：Qwen
邏輯斷層的「幻覺系」Qwen 的回應速度很快，但它犯了一個新手工程師最容易犯的錯誤：前後端不一致。
代碼檢視：
後端 Python 定義新模型，但前端 XML 卻試圖綁定原生模型：
<!-- Qwen 的 XML 視圖錯誤示範 --> <record id="view_customer_contract_form" model="ir.ui.view"> <field name="name">customer.contract.form</field> <field name="model">sale.order</field> <!-- 這裡變成了 sale.order！ --> </record>
這是一個嚴重的 Critical Bug。安裝時 Odoo 會直接報錯（Field Error）。這顯示 AI 在處理長文本時，發生了上下文邏輯的丟失。
✅ 選手三：Gemini
懂「行規」的資深工匠Gemini 的代碼讓我眼前一亮。它沒有選擇「新建」，而是選擇了「繼承」。
代碼檢視：
[cite_start]# Gemini 的方案 [cite: 39-40] class CustomerContract(models.Model): _name = 'parking.customer.contract' _inherit = 'sale.order' # <--- 關鍵：繼承原生銷售訂單 # 新增停車專用欄位 license_plate = fields.Char(string='License Plate')
這才是 "The Odoo Way"。透過繼承，我們直接擁有了 Odoo 強大的訂單確認流程、電子簽章、發票連動機制。開發時間減少，且未來的維護成本極低。
嶼點科技觀點
AI 是一個強大的「生成器」，但它不是一個合格的「決策者」。
我們不重造輪子，我們讓輪子跑得更快。
您的企業系統是否也充斥著無法連動的「資料孤島」？
歡迎與嶼點數位工匠交流您的技術需求。
AI 生成代碼的陷阱：從 Odoo 模組開發看「架構師」的真實價值
嶼點科技 | 2025-01-18
在軟體開發的領域裡，AI 輔助編程已是標配。但作為 Odoo 技術顧問，我常被問：「既然 AI 都能寫程式了，為什麼還需要資深架構師？」 為了回答這個問題，我們進行了一場實戰實驗：讓 DeepSeek、Gemini 與 Qwen 同時開發同一個模組，結果令人深思。
🧪 實驗背景：不只是一個 CRUD
我們的需求看似簡單，實則考驗對 Odoo 框架的理解：
- 停車位管理：區域、價格、車位數。
- 合約管理：需記錄車主資訊、租期、車牌。
- 財務整合：租金收取與押金管理。
關鍵挑戰在於：如何將這些新功能與 Odoo 原有的銷售 (Sales) 與會計 (Accounting) 模組完美融合？
🔍 選手一：DeepSeek
工整的「孤島製造者」DeepSeek 展現了極佳的工程師素養。它生成的目錄結構非常標準，從 mkdir 指令到權限設定檔都寫得一絲不苟。
代碼檢視：
[cite_start]# DeepSeek 的方案 [cite: 6] class ParkingLot(models.Model): _name = 'parking.lot' # 全新模型 # ... 欄位定義 ... # 它並沒有繼承 sale.order，而是自創了合約模型 class CustomerContract(models.Model): _name = 'customer.contract' # ...
DeepSeek 選擇了「從零開始」。雖然短期內很安全，但在 ERP 實務中是下策。因為這個新合約與 Odoo 原生的
sale.order 毫無關聯，創造了典型的「資料孤島 (Data Silo)」。
🚫 選手二：Qwen
邏輯斷層的「幻覺系」Qwen 的回應速度很快，但它犯了一個新手工程師最容易犯的錯誤：前後端不一致。
代碼檢視：
後端 Python 定義新模型，但前端 XML 卻試圖綁定原生模型：
<!-- Qwen 的 XML 視圖錯誤示範 --> <record id="view_customer_contract_form" model="ir.ui.view"> <field name="name">customer.contract.form</field> <field name="model">sale.order</field> <!-- 這裡變成了 sale.order！ --> </record>
這是一個嚴重的 Critical Bug。安裝時 Odoo 會直接報錯（Field Error）。這顯示 AI 在處理長文本時，發生了上下文邏輯的丟失。
✅ 選手三：Gemini
懂「行規」的資深工匠Gemini 的代碼讓我眼前一亮。它沒有選擇「新建」，而是選擇了「繼承」。
代碼檢視：
[cite_start]# Gemini 的方案 [cite: 39-40] class CustomerContract(models.Model): _name = 'parking.customer.contract' _inherit = 'sale.order' # <--- 關鍵：繼承原生銷售訂單 # 新增停車專用欄位 license_plate = fields.Char(string='License Plate')
這才是 "The Odoo Way"。透過繼承，我們直接擁有了 Odoo 強大的訂單確認流程、電子簽章、發票連動機制。開發時間減少，且未來的維護成本極低。
嶼點科技觀點
AI 是一個強大的「生成器」，但它不是一個合格的「決策者」。
我們不重造輪子，我們讓輪子跑得更快。
您的企業系統是否也充斥著無法連動的「資料孤島」？
歡迎與嶼點數位工匠交流您的技術需求。