AI 程式開發的下個戰場：從模型能力到脈絡系統的典範轉移

近幾年，AI 程式開發（AI Coding）工具的進展有目共睹，從自動補完到單一函式的生成，它們在提升局部開發效率上扮演了重要角色。然而，當我們將任務尺度拉高到整個專案、整個程式碼庫（codebase）的層級時，現有工具的侷限性便顯露無遺。它們就像一位記憶短暫的專家，雖然能出色地完成單點任務，卻無法理解任務在整個系統中的來龍去脈。

我認為，AI 程式開發的下一波競爭關鍵，將不再是單純比拼語言模型本身的推理或生成能力，而是取決於誰能建立更完整的「脈絡理解系統」（Context Understanding System）。這是一場從模型為中心，轉向以系統為中心的典範轉移。

現代 AI 助手的盲點：破碎的上下文

當前主流的 AI 程式開發工具，其根本限制在於「上下文視窗」（context window）的物理極限。無論視窗有多大，面對一個動輒數十萬、甚至數百萬行程式碼的現代軟體專案，都顯得捉襟見肘。開發者往往需要手動挑選相關的檔案片段，餵給 AI，期待它能「窺斑見豹」。

這種工作模式帶來了幾個核心痛點：

• 不完整的理解：AI 無法看到一個函式被呼叫的所有位置，或是一個類別與系統中其他模組的複雜依賴關係。
• 高風險的修改：基於片面資訊所做的修改，極有可能引發意想不到的副作用，導致系統迴歸（regression）或產生難以追蹤的 bug。
• 低效的工作流：開發者將大量時間耗費在扮演「人肉上下文過濾器」的角色，而非專注於更高層次的架構設計與問題解決。

這種困境，就像要求一位建築師在只能看到單一房間設計圖的情況下，去修改整棟大樓的承重結構。這不僅效率低落，而且極其危險。

新典範：從手動提示到脈絡自動編排

為了解決這個根本問題，一個新的方向正在浮現：將整個程式碼庫轉化為一個 AI 可即時查詢、可語意理解的知識庫。最近看到的一個實驗性專案 claude-context，便體現了這種思維的轉變。

其核心概念是透過一個模組化的脈絡插件（Modular Context Provider, MCP），讓 AI Agent 在接收到任務時，能主動、即時地從整個專案中，透過語意搜尋（semantic search）找出最相關的程式碼片段。這徹底改變了過去的工作流程。

想像一下，過去我們的工作流是：開發者手動尋找相關資訊，提供給 AI 作為上下文，然後 AI 執行任務。這就像是開發者扮演著「人肉上下文過濾器」的角色。而新的典範，則將流程顛倒過來：開發者只需下達高層次指令，AI Agent 會自主地搜尋、理解並編排最精確的上下文，最終交由語言模型執行。這不僅是效率的提升，更是工作模式的質變，讓開發者能更專注於高價值的架構設計與問題解決。

關鍵不在於將更多資料塞進上下文視窗，而在於如何精準地放入「對的」資料。

這個轉變意味著，AI 不再是被動的工具，而是成為一個能自主探索、理解專案全貌的協作者。當開發者提出一個高層次的需求，例如「重構使用者身份驗證模組以支援 OAuth 2.0」，Agent 能夠自行找出所有與身份驗證相關的控制器、服務、模型與設定檔，形成一個完整且精確的上下文，再交給語言模型進行修改。這才是真正意義上的「AI 驅動開發」。

系統設計的取捨：建構可擴展的脈絡層

從系統設計與治理的角度來看，這種「脈絡層」（Context Layer）的建立，比單純等待或升級到更大規模的語言模型，是更具策略性的選擇。

直接升級模型看似簡單，但它帶來的是極高的運算成本與潛在的「資訊噪音」問題——更大的上下文視窗不保證模型能聚焦在最重要的資訊上。相反地，建立一個獨立的脈絡系統，具備以下幾個戰略優勢：

對開發團隊或企業而言，這意味著我們應該將投資重心，從單純追逐最強大的模型，轉移到建構一個穩固、高效的脈絡基礎設施上。這個基礎設施將成為所有 AI Agent 運作的基石，決定了它們能否在複雜的真實世界專案中發揮價值。

未來，評估一個 AI 程式開發平台的優劣，我們看的將不再只是它用了哪個模型，而是它的脈絡系統有多深、多廣、多即時。誰能掌握最完整的程式碼脈絡，誰就能在下一波 AI 開發浪潮中，處理最複雜的工程挑戰，取得最終的競爭優勢。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。

延伸閱讀

• tripleh.ai on Threads