程式碼庫上下文
為 Coding Agent 提供持久的程式碼庫上下文。
把儲存庫知識轉化為不隨單次提示消失的上下文。FiboCode 在專案中串連規格、設計、計畫、分析、變更說明、程式碼、文件與圖譜，讓下一項 Agent 任務從比聊天歷史更持久的基礎出發。
Agent 需要專案上下文，而不只是更長的提示詞。
Coding Agent 可以在一次工作階段中檢視檔案，但如果早期決策只存在於對話中，相關推理很容易丟失。反覆解釋架構、約束和先前變更既耗時，也仍會迫使 Agent 重建團隊已經理解過的關係。
上下文工程讓這類知識變得持久、可選擇。FiboCode 用 Markdown 在程式碼旁記錄專案理解，再用路徑和圖譜建立串連。Agent 獲得的是人可以審查、改善並帶入下一次變更的具體儲存庫資料。
看看專案上下文如何隨程式碼成長。
真實產品示範呈現相連知識如何跨視圖流動，並隨著儲存庫變更持續演進。
重要專案記錄圍繞真實工作逐步沈澱，而不是隨 Agent 對話結束而消失。
沿連結復原一段專案上下文背後的證據，供 Agent 或開發者繼續核對。
建立 Agent 可以重複使用的上下文。
目標不是保留每條訊息，而是保留未來工作真正依賴的專案事實與決策。
確定上下文邊界。
從 Agent 必須理解的功能、模組、決策或故障出發，選擇相關檔案與符號，而不是把整個儲存庫當作一個無差別提示詞。
用 Markdown 記錄持久知識。
記錄規格、設計、計畫、分析與變更說明，使這些內容脫離原始聊天工作階段後仍然可讀。
把知識串連到原始碼與關係。
用路徑、標籤與圖譜保留每個判斷的來源，以及它與其他模組或文件的關係。
把上下文帶入下一項 Agent 任務。
讓選定的 Agent CLI 閱讀相關專案資料，並在實作與理解演進時繼續審查、更新這些記錄。
始終可以檢查的上下文。
由儲存庫承載的記錄。
重要上下文以可讀 Markdown 留在專案中，不依賴單一供應商工作階段或私有記憶。
可追溯的原始碼串連。
路徑與標籤讓解釋貼近它所描述的程式碼，也讓人可以核對 Agent 的起始假設。
多種上下文視圖。
程式碼提供實作事實，文件說明行為與意圖，圖譜揭示文字不易呈現的關係。
跨變更持續演進。
規格、設計、計畫、diff 記錄與分析文件保留改了什麼、為何變更，讓後續工作延續已有理解。
使用情境：把功能交給新的 Agent 工作階段。
團隊已經盤點某個子系統、記錄一項約束並完成過相關變更。開發者無需把舊對話貼上到新工作階段，而是讓 Agent CLI 閱讀相關分析、設計、變更記錄與原始碼檔案。
Agent 從經過審查的專案資料開始。新變更推進時，團隊也能繼續完善同一份上下文，讓儲存庫繼續服務下一位開發者或 Agent，而不是增加另一份孤立說明。
上下文工程不是不斷累積提示詞。
長提示可以把細節帶入一次請求，卻不會自動成為易於維護的專案知識。FiboCode 把持久上下文與臨時對話分開，並為它建立通向程式碼、文件與圖譜的可見串連。
Agent 仍透過你選擇的 Agent CLI 推理並編輯；FiboCode 提供可共同檢查的上下文。“規格驅動開發”則進一步提供從新需求走向計畫執行的結構化路徑。
程式碼庫上下文常見問題
這裡的“持久上下文”是什麼意思？
重要專案知識以可重複使用文件和串連記錄在程式碼旁，而不是只存在於一次臨時 Agent 對話中。
FiboCode 會提供新的 Coding Agent 嗎？
不會。你繼續使用信賴的 Agent CLI；FiboCode 豐富它的工作區上下文，並把 Agent 工作接回編輯器中的理解與審查。
為什麼用 Markdown 保留 Agent 上下文？
Markdown 便於人和 Agent 讀寫，適合規格與解釋，也能作為專案資料持續接受檢查。
上下文能包含圖示和關係嗎？
可以。圖譜與標籤補充 Markdown 和程式碼，讓關係可導覽，同時保留回到底層專案資料的路徑。
程式碼變化後應該如何處理上下文？
根據新實作審查相關記錄並按需更新。目標是一座可成長、可追溯的知識庫，而不是靜態摘要。