小回顧1，在這三十天的實驗裡，我選擇以我過往熟悉的不同會計軟體與成本架構 作為參照點，原因很簡單：在地化軟體在台灣的製造業 ERP 應用已行之有年，它的邏輯深深影響了許多財會人員的工作習慣，然而，當我把這些思路帶進 Odoo 時，我發現這並不是單純的「移植」，而更像是一場程式語言翻譯與試煉，Odoo 的 ORM 與模組化設計，要求我重新檢視 ERP 的批次邏輯、在製品分攤、月結處理……，這些挑戰，讓我不只是在複製，而是在嘗試回答一個問題：如何讓傳統 ERP 的經驗，在新世代的開源架構裡重生？
小回顧2，過往29天文章更多是一個試驗的實踐，測試看看想法是否能被完成，舉例來說：Day20的成本單價修改，我過往認為是不太可能可以完成的事情，主要是一個原料，在許多BOM都有設定，並且有成品或半成品的多次領料情況與成品出貨的情況下，真的可以清楚地計算出軌跡嗎?經過與AI多次的討論與測試，確實是可以完成，只是在程式的架構要非常仔細，每一段的內容可能的情況也要說明，雖然已完成，但是否有更好的方式尚未思考，僅為一次實踐過程紀錄。
29 天的鐵人賽，並不只是挑戰的紀錄，這段自我對話，讓我觸碰到一個奇異點：AI 彷彿改寫了時間的尺度，三十天的挑戰，不只是「完成」兩個念頭，而是一次軌跡的再凝視。
使用AI開發的經驗在Day29有進行說明，我想我驗證了Vibe Coding。
在Day28的AI模組是訓練模型的應用，幾年前開始接觸 Python 時，因緣際會認識了同樣以 Python 為基礎的 Odoo。當時就一直在思考，Python 的強項是大數據與 AI，而 ERP 系統本身又累積了大量資料，若能將兩者整合，應用場景一定非常廣，這次的挑戰，真的落實了這個想法直接取用現有資料，經過整理、特徵化、套用模型，再將結果呈現在自製的報表上，整個過程感覺能解決一些問題時，讓我覺得充滿樂趣，近年LLM快速發展，常見的就是與AI的對話與執行，非常好奇LLM+RAG未來在ERP會有什麼樣的應用。
在製作「在地化會計模組」的過程中，並沒有太多的創新，就是打地基工作，重新檢視了過往輔導企業時常遇到的痛點，並嘗試補齊那些「總覺得 Odoo 少了點什麼」的缺口，製作過往覺得理所當然的功能，真的捲起袖子要進製作時，才發現製作在地化並沒有想像中的那麼簡單，你看到的一天文章，可能是我好幾天的成果，過程中滿多細節可能要注意，在總結再詳細說明。
第30天，我想把之前為了測試不同情境，在不同DB的模組安裝在一起，呈現如下:
透過 AI 的幫助，快速回顧了這 29 天，如何一步步把腦中的想法，轉化為可以實際運作的原型。
首先，從入門開始，先練練手，增加信心，寫一些報表，說明設計結構並重構了報表結構與更完善報表的呈現方式：
接者，休息一下，寫比較簡單的關聯報表優化，為後續成本鋪路
報表完成後，寫一個獨立的固定模組，從頭開始，完全製作新的內容。
固定資產完成後，加一些難度，開始寫與前後端比較密切關聯的票據資金模組，目的是財務的職能區分清楚。
資金模組完成後，進行大難關前的練習，移動平均成本一直想要優化可以增加關聯修改，讓後續可以批次更新。
最後大難關，增加非常有挑戰性，但台灣味十足的月加權平均，嘗試由根本去解決成本計算的問題。
保留一天，想發揮過往AI所學，將訓練後的模組架構在ODOO上進行使用。
今年鐵人賽看起來有滿多主題都與AI相關，例如
以及本篇的AI開發、AI檢測到會計的落地應用，都是在不同領域的應用，Make可以整合多種工具，搭配現下的生成式AI給適合Prompt來搭配LINE與ODOOO的結合應用，或是直接透過GenAI+RAG去解析資料庫產生資料，都是可以透過文章去了解原來AI在不同工具下的連結，我想這都是大家看到這套開源軟體的好處，可以更快速的去實踐所學與應用。近期筆者也在學習新的ERP軟體，在AI的應用上更是隨處可見，可自行新增AI應用與自定義Prompt，分成了詢問、回應、行動三種方法，這樣讓AI的應用更有彈性。
思考寫文章的初衷，應該是製作過程的經驗分享與個人筆記紀錄，是這系列文章主要的目的，其中希望表達這套軟體的現況，第三方軟體的現況，以及根據個人過往經驗，覺得應該怎麼做，以及實際做出來什麼，並透過思考如何用最簡單的案例來進行分享，可能過往也滿多人覺得ODOO不錯，但常會遇到會計跟你說這套軟體不符合我們期待，那如果你有遇到情況，就可以稍微看一下這篇文章，或許有說明差異之處。
近期觀察到 ERP 的發展趨勢，已經逐步走向智能化，過去評估使用者能力，往往看的是「打單打得有多快與多準」，但現在的評分標準正在改變──更看重的是使用者能否設計出有效的 AI 功能。未來的價值，不再只是熟練操作，而是能將個人使用經驗轉化為規則，並透過 AI 的設計與應用，讓這些規則自動化、制度化。
在這樣的背景下，會計工作的定位也正在改變。過去仰賴人工登錄與核算，如今憑證 OCR、自動對帳、AI審核等技術，已經讓基礎作業逐漸由系統完成。未來會計人員的價值，不再只是記錄數字，而是將自身的專業判斷與操作經驗，提煉為一套「可被規則化」的邏輯，並交由 AI 自動執行。
換句話說，會計角色正從「親自做」轉向「定義怎麼做」，把經驗轉換成規則，讓系統學會在不同情境下自動反應。這樣的轉型，不僅提升效率，也讓會計能將更多心力放在制度設計與策略推動，而不只是單純的數據處理。
以上是願景，回歸現實還有一些事情要做，有想做但還沒落實執行的紀錄如下:
那在功能面相關，紀錄中如下:
那在軟體測試中，案例驅動的測試情境仍還不夠。
這些未盡事項，休息一段時間後，未來會在思考如何進行，或是根據願景在去思考設計如何讓AI更容易應用的架構。
近期常聽曾博恩的博音，分享一個在EP188 | 兒童發展專家，其中介紹孩子「帶著他去走這條路，他大腦才會學到新的彈性」，突然很像切中近期在做的事情，要感謝過往的ERP經驗，先充分了解一套在地化軟體應該要有什麼樣的功能，在面對ODOO這套軟體時，這30天正在增加這套軟體在地化的彈性，也就是在影片中介紹，此彈性或許就可以解決70-80%的問題。
那製作彈性會遇到什麼問題，最常見的就是架構問題，例如，Day10的固定資產是全新的模組，當我想要重新計算，我只要增加還原機制需要的架構即可，就可以進行反覆操作，讓人有Try Error的過程，此時使用者在和只能單方向的功能相比之下，可能對這套軟體的滿意度就會增加，我想這是台灣軟體環境所帶來的基礎體驗；此外，在移動平均的優化過程，其實也是非常受限於架構問題，僅能透過底層的異動做最基礎的處理來滿足成本結算需求，很難真的執行單據的還原來進行操作，但是如果要連成本都要有彈性，那就要增加Day23的月加權平均成本架構，再來搭配Day20的SVL異動解決時序或金額問題。
那分享製作彈性的缺點，就是在防呆機制的管控，在還原過程，有許多內容要管控，例如不能隨便還原前幾個月份的折舊、有異動的單據不能隨便還原..等，我想這確實不應該是原生開源軟體公司要思考的事項，這些在地化未來高機率ODOO不會進行處理，但如果要讓庫存異動有彈性，可能就會是完全開發一套進銷存軟體的議題了。
回顧這 30 天，其實可以把這段歷程看成一場「雙線並行」的學習：一條是模組開發的技術線，另一條是與 AI 合作的思維線。前者讓我更清楚 Odoo 的結構與限制，後者則逼我去思考 —— 在這樣一個充滿不確定性的環境裡，如何快速試錯、如何找到能被複製的架構、如何不被細節淹沒。
我覺得 AI 不是要幫你寫出「完美的程式」，而是讓你敢去嘗試那些過去看似難以挑戰的題目。Day29提到，當你知道有個隨時可用的「陪練員」，就會更願意去試著拼接出一個雛形，哪怕最後要自己花時間收尾。這其實就是軟體開發的日常：快速建立、打磨修正、最後沉澱。
而這一系列文章的價值，或許並不在於「有沒有產出一個最終可商用的模組」，而是自己紀錄留下了一條參考的路徑。ERP 在地化是一個長遠的過程，不是一次馬拉松衝刺就能結束的，比較像是一場接力，2025我先跑一段，把經驗留下來，休息一段時間後，再接著跑完未盡之事。
總結一句話：模組是產品，文章是地圖，AI 是夥伴。
產品需要持續維護，地圖要不斷更新，而夥伴提醒我們：不必一個人苦撐，很多路可以有AI陪著走。也許，如同Day29所說，AI增加效率所創造的時間，讓我們學會應用時間去探索與試錯，看見未來更多的可能。
我的繪製 30 天地圖已經要結束了，地圖不會告訴你終點，只會提醒每一步可能的方向。
iThome鐵人賽
看影片追技術