探索

在前 28 天的分享中，我們一路從 會計報表、進銷存、固定資產、票據資金、成本核算，最後還延伸到 AI 模組，逐步拼湊出一個「台灣在地化 ERP 會計模組」的雛形。這些模組雖然多數仍停留在 PoC（概念驗證）階段，但也累積出不少實作心得。

那麼，若要真正推進到企業落地，開發上有哪些建議或方向值得注意？ Day1提到的是最初的架構，期間朋友推薦看保哥的AI 程式設計代理人開發全攻略，根據課程又調整了一版在Cursor上使用，主要增加上下文使用讓AI能更快速理解，與更好的提示(Prompt)讓AI順利產出符合需求的文件，那這是一個練功的過程紀錄，主要目的是如何架構，如何容易維護，如何能更Vibe Coding。

架構

如何新增一個全新模組

如果你是一位完全的新手，我建議還是要去上一些基礎課程，有基礎的除錯能力，一直貼上錯誤的LOG並不會完全解決問題，AI很棒，會逐漸減少程式找到錯誤原因，再建構回去，但是很常在減少或增加的過程中，架構已經不是你想要的樣子，建議還是介入主要的架構內容有沒有改變，避免未來人員維護的痛苦。

雖然很常聽到說，設計圖AI指令下完，就已經完全寫好程式，並且已經可以使用了，那來分享我實際的過程，可以使用到可以交付還有好長一段路，筆者僅只有一個模組有這個體驗，那主要原因是因為這個模組比較簡單，在ERP的應用功能，你很難去一次完成所有功能，因此我的經驗可能不夠聰明，但是為我能掌握的，作法參考如下:

前期準備

1. 建議程式的架構
   • ODOO的XML與報表可以很多寫法，寫一組讓AI知道未來要產出的架構。
2. 建置Cursor的架構-參考實作的cursor.rule使用。
3. 提示(Prompt)的重要
   • 初期與AI溝通你要的台灣情境，說明需要的功能，讓AI了解整體架構。
   • 請AI產出適合的Prompt，反覆調整後，複製最好的，然後結束對話。
   • 新對話貼上Prompt，請優先產出py檔案，功能先產出空白的。
   • 逐步修改PY直到滿意後，才產生後續的VIEW與權限。

以上你可能會發現我並不是一次產出所有文件，主要是過往初期的經驗，我會想看AI如何發展，然後很勉強的持續不斷的配合AI架構去做思緒改變，但最後發現結果相同，架構已經不是我要得，因此前幾隻的程式，每個都長得不太一樣，導致後續又花時間重構了一次。

前 28 天的練習中，除了少數幾個較為簡單的模組能夠讓 AI 自由發揮之外，其餘多數模組仍是依循筆者過往的使用經驗框架進行調整。這樣的安排主要考量到系統彈性與後續維護的便利性，因此常讓 AI 承擔的是一些拆解或輔助性的任務，因此整體架構顯得不那麼「聰明」。未來若有新的專案主題，將會考慮放手讓 AI 自由發揮，嘗試以不同的框架來呈現，累積更多元的學習與實驗經驗。

實作

cursor.rule使用

.cursor.rule是說明一些規則，聽完保哥的課程後，有嘗試調整一版進階版本，優先去讀.cursor目錄，以下是我的架構參考:

.cursor.rule
├──.cursor/
    ├── README.md              # Cursor 設定說明文件
    ├── rules.md               # 專案開發規則與規範
    ├── context.md             # 專案上下文
    ├── personal.md            # 個人偏好設定
    ├── settings.json          # Cursor 專案設定檔
    └── examples/              # 程式碼範例目錄
        └── module_examples.md # Odoo 模組範例

建立有效上下文的策略

1. 分層架構設計

   • 專案層級：整體架構與規範
   • 模組層級：具體功能與實現
   • 個人層級：偏好設定與工具配置

2. 引用機制

   • 使用 @檔案名 建立檔案間的引用關係
   • 避免內容重複，提升維護效率

3. 定期更新

   • 隨著專案演進持續更新上下文
   • 確保資訊的 準確性 與 時效性

4. 版本控制

   • 將上下文文件納入版本控制
   • 追蹤變更歷史，促進團隊協作

如何進行測試

分享一些寫到後期較困難模組的心得參考:

1. 考量到測試人員的工作負擔
   因為筆者是開規格、寫程式、測試、寫文件、交付都是同一個人，這邊要邊寫邊測試的過程，就會去思考到這個問題，就是「如何讓我反覆測試比較容易?」，因此我都會為自己增加一些情境或案例，讓程式是我可以掌握的情況，避免來來回回，雙方都會非常痛苦，例如在後期的開法越來越困難，例如移動平均成本的修改，需要記錄異動，紀錄影響，紀錄差異..等，這些都是非常大量的程式邏輯，因此將測試方式列入程式架構中非常重要。

2. 功能拆解成幾個按鈕
   這邊所謂的測試並不是指寫一個test目錄，那要如何去進行測試，就是把每一個測試過程寫成一個的按鈕，拆解功能，將每一個按鈕完成後再通知測試，那測試功能當然包含自動刪除之前產生資料，讓使用者能自主與快速測試沒問題後，在往下寫第二個按鈕、第三個按鈕...以此類推，比較容易去收斂後續的情況，或是在增加功能，等到完全寫完後，再去隱藏功能按鈕，整併成一個背景程式即可，因為也是一段段的函式，未來也會比較好進行維護與調整。

小結

在Day1有說明AI工具選擇，從最早的ChatGPT，到現在使用Cursor，主要是筆者算是Python新手，有AI幫我寫在適合的段落對筆者來說很重要，可以避免一些基礎的錯誤，那使用的過程，難免有許多的生氣，沒錯，真的會有對AI有情緒性的語言，一個非常簡單功能，但是卻錯了好幾次後，經過一番不理性對話後，發現還是自己研究架構再來寫比較快，被AI磨出寫程式的耐性，還是要回歸理性，直接使用上下文與溝通關鍵點是近期的改變。

延伸上述，個人觀點是要考量「每次對話的範圍」，不知道各位使用Cursor是否有相同感覺，就是每次新的對話，就是一個新的新人，而且知識背景程度很像不太一樣(或許是我Prompt每天寫的也不一樣)，曾經Claude有限制對話長度時，當你在寫困難功能且有對話長度限制時，真的很容易火起來，還曾經寫信給Cursor這個限制太讓人有挫折感。因為當Cursor了解架構後，反覆出現問題，對話很快又要結束了，你又遇到下一個AI，又要重新說明，所以後續做了上述的改變，拆解問題，逐步使用按鈕功能的故事。

其實 AI 幫助開發，就像一個隨時待命的助理，它可以幫忙搬運、做草稿、甚至提出一些靈感，但最終能不能落地，還是取決於開發者自己。很多人誤會 AI 可以「直接幫你寫好一切」，但真正的價值在於 縮短摸索時間、提供思路、降低試錯成本。

如同Day1所說，如果把 ERP 模組的開發比喻成蓋房子，AI 也許能幫忙先拉出一個骨架，甚至幫忙搬磚、打底，但房子能不能住，結構穩不穩固，還是要靠人去檢查、去調整。尤其是企業落地要考慮 維護性、擴充性、與既有流程的整合，這些不是單純靠 AI 就能搞定的。

所以，AI 帶來的學習過程很珍貴，它讓人更快看到全貌，但也逼你面對細節。長遠來看，這種「反覆被 AI 搞生氣、再冷靜下來補好架構」的經驗，反而會讓你更懂得怎麼設計一個能被未來人員維護的系統，再把架構放大一點來看，等你有開發經驗後，可以整理這些知識與AI討論自動化的過程，我在AI代理人課程中學到了很多AI應用的可能性，未來可能會透過CLI與搭配SDK想像來執行更多的應用。

近期看博音與侯文詠的對話時，我開始思考「效率」是否真的應該是我們追求的唯一目標。AI 的出現不僅提升了效率，更重新定義了「時間」的價值。與其把 AI 帶來的時間盈餘單純視為「可以做更多」，或許我們也該思考：是否能把這些時間用在更深層的反思、更有創意的探索，甚至單純的休息。AI 不只是讓我們跑得更快，而是邀請我們重新選擇前進的方向。

總結一句話：AI 不會取代開發者，但會淘汰不願意調整開發習慣的人，與其期待 AI 一次就幫你寫完，不如把它當成練功的陪練夥伴，拆解問題、逐步收斂，才是走得長久的方式。