FIND研究員：蔡宗融 在實際開發 lancedb-opencode-pro 的過程中，我們逐漸發現，生成式 AI 在軟體開發中的角色正在改變。早期，這類工具多半用於程式碼補齊（Code Completion）；但近一年，像 OpenCode、Aider 這類 AI Agent，已能直接參與跨檔案邏輯的實作，甚至影響模組設計方式。對開發者而言，AI 不再只是「加速工具」，而開始成為能夠共同維護 codebase 的協作者。不過，當專案規模擴大後，一個問題會慢慢浮現：AI 並沒有真正「記住」專案。
問題不是出錯，而是「重複犯錯」
在多次迭代中，我們觀察到兩個具體現象：
1. 脈絡遺失導致的實作偏差，AI 在不同任務之間，無法穩定保留以下資訊
●既有設計決策（Architecture decisions）
●規格文件（Spec）
●歷史修改脈絡（Changelog）
結果不是單純寫錯，而是寫出「看似合理但不符合既有設計」的實作。
2. 測試行為的不穩定
另一個更實際的問題是測試。在高頻迭代下，不論是人類或 AI，都容易出現以下三種情況：
●測試覆蓋不完整
●忽略 edge cases
●回歸測試缺失
差別在於：人類是「知道但沒寫」，AI 則是「不知道要寫什麼」。
實務解法：讓 AI 能「查得到」而不是「記得住」
在這樣的背景下，我們沒有嘗試擴大模型上下文（context window），而是改變策略：
1. 讓 AI 每次實作前，都先「查資料」
這也是 lancedb-opencode-pro 的核心設計思路：
●使用 LanceDB 建立向量檢索層
●將 README、Spec、Changelog 等文件向量化
●在生成程式碼前，先做語意檢索（RAG）
這樣的結果是：AI 不需要記住所有東西，但可以在需要時重新對齊脈絡。
2.從 Spec 到實作：降低「猜測意圖」的比例
除了檢索，我們也同步導入 Spec-Driven Development（SDD）流程：
●所有實作必須對應 openspec 中的定義
●AI 在生成邏輯前，會先讀取相關規格
這帶來一個明顯改變：開發過程從「AI 猜使用者想做什麼」，轉變為「依據規格執行」。
在多模組專案中，這點特別關鍵。
一個實際案例：AI 如何停止重複犯同一個錯誤
在一次處理測試生成的過程中，我們遇到一個典型問題：
●AI 連續產生三次錯誤的測試邏輯
●錯誤原因是誤解某個欄位的邊界條件
在人工修正後，lancedb-opencode-pro 會自動將錯誤原因、修正方式、正確測試案例一併寫入 LanceDB。
之後在相似功能上再次觸發時，AI 的行為就出現以下的變化：
●不再重複原本的錯誤路徑
●產生的測試邏輯直接貼近先前成功案例
這個現象讓我們意識到： AI 不需要「變更聰明」，只需要「能利用過去成功經驗」。
圖1：使用 LanceDB 建立專案長期記憶，解決 AI 失憶問題。
資料來源：lancedb-opencode-pro 專案
對開發流程的實際影響
在持續幾個版本的迭代後，可以觀察到幾個趨勢：
1. 測試覆蓋變得可預期，AI 能依 Spec 補齊：
●edge cases
●錯誤處理
●回歸測試
這在人工開發中通常是最容易被忽略的部分。
2. 理解既有系統的成本下降，透過檢索機制，AI 能快速定位：
●過去設計決策
●相關模組實作
●歷史修正案例
在內部使用情境中，發現AI理解既有邏輯的時間有明顯下降。
3. 回歸錯誤明顯減少，當測試由 AI 主動補齊後：
●CI/CD 階段才發現錯誤的情況下降
●版本釋出穩定度提升
這點在多次 commit 觀察中相當一致。
不只是工具問題，而是開發流程的改變
從這次實作經驗來看，關鍵不在於使用哪一個模型，而是： 是否建立了一套「可被檢索與重用的開發知識體系」。當專案具備：
●可查詢的文件（Spec / README）
●可回溯的歷史（Changelog / 修正案例）
●可被 AI 利用的資料結構（向量化）
AI 才有機會真正參與長週期的開發工作。
結論與建議
在這個專案中，一個最直接的體會是：問題從來不是 AI 會不會寫程式，而是開發過程的經驗與知識沒有被保留下來。
當這些過程（決策、錯誤、修正）能被結構化並重新利用時，AI 的角色才會從輔助工具，逐漸轉變為能協助維持系統穩定度的參與者。這樣的模式，對於需要長期維護的軟體系統，可能比單純提升模型能力，更具有實際價值。
參考資料來源：
1. GitHub - tryweb/lancedb-opencode-pro
2. NPM - lancedb-opencode-pro
3. OpenSpec 技術規範檔案
4. LanceDB 向量資料庫應用手冊
5. 附圖由 Gemini Nano Banana 產生
