在 AI 輔助開發（AI-assisted development）普及的今天，許多工程師會發現一個弔詭的現象：AI 幫我們寫程式碼的速度極快，但我們對這段程式碼「為什麼這樣寫」的理解卻跟不上。這種現象被稱為上下文斷層（Context Gap）。
對於 Junior 工程師來說，最容易掉入的陷阱是認為 AI 提高了生產力。事實上，AI 能快速完成功能開發的前 80%（如搭建框架、撰寫基礎邏輯、生成測試用例），但剩下的 20% 才是真正的挑戰。這 20% 包含：與既有系統的複雜整合、邊緣案例的處理、性能限制以及深層的設計意圖。
當程式碼產出速度超越人類理解速度時，我們面臨的風險不再是開發太慢，而是我們正在失去對系統的掌控力。
什麼是 Context Store
為了彌補這個斷層，我們需要建立一個 Context Store（上下文儲存庫）。它不是一份靜態的說明文件，而是一個版本化、可查詢且具備決定性的紀錄，記錄了設計意圖（Design Intent）與行為一致性（Behavioral Conformance）。
簡單來說，Context Store 是將「為什麼這麼做」的推理過程，與「程式碼本身」同步儲存在版本控制系統（如 Git）中。它讓人類審核者與 AI Agent 都能在變更程式碼前，先對齊系統的設計初衷，而非僅僅依賴 LLM 的機率性推測。
構建 Context Store 的三大核心實踐
要建立這個儲存庫，不能靠事後補寫文件，而必須將三種驗證機制整合進開發流程中，使其成為自動化的反饋迴路。
第一，以規格為核心的開發（Spec-anchored SDD）
這是為了建立意圖層（Intent Layer）。開發者應在儲存庫中維護一份機器可讀的規格文件（Specification），定義功能的範圍、約束條件與驗證標準。
在 AI 時代，這份規格文件就是給 AI Agent 的指令集（Brief），也是人類 Reviewer 的參考基準。關鍵在於這份文件必須像程式碼一樣經過審核並隨版本更新。如果規格文件在 AI 生成程式碼後就被丟棄，就會變成所謂的「文件劇場」，對後續維護毫無幫助。
第二，測試驅動開發（TDD）
這是為了建立行為層（Behavior Layer）。在 AI 快速產出程式碼時，人類審核者很難在短時間內發現細微的行為回歸（Regression）。
透過先寫失敗測試（Red），再讓 AI 產出程式碼使其通過（Green），測試就變成了驗證 AI 輸出的唯一真理。這要求工程師將重心從「寫程式」轉移到「定義如何驗證」，確保 AI 產出的行為符合預期。
第三，架構適應度函數（Architectural Fitness Functions）
這是為了建立結構層（Structural Layer）。適應度函數是一種自動化的執行檢查，用來驗證系統是否符合架構約束（例如：模組間的依賴關係、性能指標、安全性要求）。
例如使用 ArchUnit 或 dependency-cruiser 等工具，將架構規範直接寫成 CI 流程中的測試。當 AI 生成的程式碼違反了分層架構或引入了非法依賴時，CI 會直接攔截。這樣可以將資深工程師從瑣碎的架構檢查中解放出來，讓 Code Review 專注於討論「為什麼這麼設計」，而非檢查「是否符合規範」。
Context Store 的實際影響與運作
當這三者結合，儲存庫中就形成了一個完整的 Context Store，包含結構、血統、行為與合規性四個維度。
在部署前，它能引導 AI Agent 生成符合規範的程式碼，並讓審核者快速對齊意圖。在部署後，當系統發生故障或需要重構時，工程師可以透過查詢規格文件、測試案例與適應度函數，迅速重建對該模組的理解，而不需要在數千行 AI 生成的程式碼中苦苦尋找蛛絲馬跡。
總結
AI 讓程式碼產出變得廉價，這使得「設計階段」重新變得至關重要。我們不應該追求讓 AI 寫得更快，而應該追求讓系統的推理過程（Reasoning）變得可執行且可追溯。
透過將規格、測試與架構檢查整合為一個 Context Store，我們才能在享受 AI 高速開發的同時，確保軟體架構依然可演進，且不會在複雜度增加時崩潰。
來源：infoq.com Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。