采訪嘉賓 | 黃廣民、天豬（按嘉賓姓氏首字母排列）

編輯 | Tina

本文為《2025 年度盤點(diǎn)與趨勢洞察》系列內(nèi)容之一，由 InfoQ 技術(shù)編輯組策劃。本系列覆蓋大模型、Agent、具身智能、AI Native 開發(fā)范式、AI 工具鏈與開發(fā)、AI+ 傳統(tǒng)行業(yè)等方向，通過長期跟蹤與業(yè)內(nèi)專家深度訪談，對(duì)重點(diǎn)領(lǐng)域進(jìn)行關(guān)鍵技術(shù)進(jìn)展、核心事件和產(chǎn)業(yè)趨勢的洞察盤點(diǎn)。本文聚焦 AI Coding 在專業(yè)程序員群體中的演進(jìn)與落地；本系列中另有文章從 進(jìn)行討論。

2025 年的 AI Coding 生態(tài)，正在為 2026 年的程序員定義一個(gè)新角色。答案可能藏在一堆冒煙的 Markdown 文件里。

這半年，Spec 驅(qū)動(dòng)開發(fā)火到爆炸。倉庫里迅速堆起一層層面向 Agent 的“Markdown 腳手架”，它被捧為 AI Coding 的最前沿解法：用一份契約，逼 Agent 真的干活。

但問題來了：這套契約，真能接住軟件工程幾十年的復(fù)雜度嗎？還是說，程序員的終極價(jià)值，將從“寫代碼”轉(zhuǎn)向“定義規(guī)則”——用 AI 聽得懂的自然語言，馴服這場技術(shù)革命？

1 補(bǔ)全的天花板，與 Agent 的必然上位

AI Coding 的演進(jìn)，已經(jīng)清晰地分為了兩個(gè)時(shí)代。

第一波由 Copilot 與 Cursor 開創(chuàng)：這是一種以人為主導(dǎo)的編程方式，AI 的角色是預(yù)測“下一個(gè)字符”或“下一個(gè)編輯位置”，在局部范圍內(nèi)提高速度和流暢度。

這種范式的邊界其實(shí)非常清楚。補(bǔ)全必須足夠絲滑，才能不打斷心流，這意味著端到端時(shí)延被嚴(yán)格壓在幾百毫秒量級(jí)，可用模型規(guī)模和上下文長度都受到天然約束：模型參數(shù)不能太大，上下文長度也遠(yuǎn)不可能用全。

與此同時(shí)，補(bǔ)全的能力卻在不斷被拉長——從行內(nèi)預(yù)測走向跨行、跨函數(shù)、跨文件的續(xù)寫與改寫，甚至局部重構(gòu)。雖然體驗(yàn)上仍有不少提升空間，但要在如此短的時(shí)間內(nèi)理解全局意圖、項(xiàng)目約束和依賴關(guān)系等，本身就接近工程極限：對(duì)泛補(bǔ)全系統(tǒng)的后訓(xùn)練、上下文選擇、推理策略與工程鏈路提出了接近極限的要求。

第二波，尤其是在過去 6–12 個(gè)月里，我們迎來了真正的范式顛覆：Agent 的崛起。它不再局限于“下一個(gè)字符”的預(yù)測，而是直接接管任務(wù)——從需求分析到代碼生成，從工具調(diào)用到結(jié)果驗(yàn)證。

相比起來，補(bǔ)全范式自身存在修改范圍小、占用開發(fā)者注意力多等局限，與能高效生成代碼的 Agent 對(duì)話模式相比，其持續(xù)優(yōu)化的邊際效用正在遞減。隨著模型能力與工具鏈完善，Agent 會(huì)覆蓋從需求到交付的更多環(huán)節(jié)，逐漸成為主流程；在 Agent 主導(dǎo)的場景中，補(bǔ)全可能退到幕后，成為支撐 Agent 精細(xì)執(zhí)行的底層能力之一。

在這一點(diǎn)上，TRAE 核心開發(fā)者天豬指出，這并不意味著補(bǔ)全范式已經(jīng)觸及技術(shù)天花板：一方面，仍有大量開發(fā)者享受“親自寫代碼”的過程，在這些場景下補(bǔ)全體驗(yàn)本身仍有不小的提升空間；更重要的是，從能力層面看，補(bǔ)全解決的始終是同一個(gè)問題——在給定上下文下，預(yù)測下一步最合理的編輯動(dòng)作。過去，這一能力主要用來輔助人類編碼；而在 Agent 體系中，它同樣可以被復(fù)用來輔助 AI 自身的執(zhí)行。比如，Agent 的對(duì)話面板、工具調(diào)用參數(shù)的生成與補(bǔ)全，本質(zhì)上都可以視為不同形式的“補(bǔ)全場景”。

另外，今年你能看到一個(gè)很有意思的現(xiàn)象：幾乎所有頭部編程工具都開始演化出三種形態(tài)并行的能力組合：IDE、CLI、Cloud。很多產(chǎn)品會(huì)以其中一種形態(tài)起家，但很快就會(huì)把觸角伸向另外兩種，因?yàn)橛脩粽嬲枰牟皇悄骋环N交互方式，而是“在不同場景下都能把任務(wù)交付出來”的完整鏈路。也正因如此，我們能更清晰地理解一些代表性工具的“出身”和氣質(zhì)：Claude Code 起源自 CLI，所以在 CLI 上可能更強(qiáng)；OpenAI Codex 起源于 Cloud；Cursor 起源于 IDE，是 IDE 領(lǐng)域最大的玩家之一。

其中，CLI 和 Cloud Agent 從一開始就是 Agent 主導(dǎo)的形態(tài)，它們對(duì) UI 的要求沒那么高，要么是 Terminal 里干活，要么是簡化的 Web 界面，再加上 GitHub PR 來做協(xié)作和交付。

但天豬判斷 IDE 依然會(huì)是最多人使用的入口，原因很簡單：它最符合程序員長期形成的工作習(xí)慣。他在團(tuán)隊(duì)更早期的實(shí)踐中就意識(shí)到：專業(yè)生產(chǎn)力工具的顛覆式創(chuàng)新，往往伴隨著對(duì)開發(fā)者認(rèn)知和工作方式的全面重塑。在他看來，IDE 的形態(tài)本身很可能在三年內(nèi)發(fā)生根本變化，不再以 Editor 為中心展開 —— TRAE 的 SOLO 模式、Cursor 的 Agent 模式，正是業(yè)界圍繞這一方向展開的探索與實(shí)踐。

用更直白的話說：IDE 正在從“給人用的工具箱”，變成“給 AI 和人一起共用的工具箱”。過去 IDE 里大量以人為中心設(shè)計(jì)的能力，現(xiàn)在正在被拆解為一個(gè)個(gè)更小的、更明確、更 AI 友好化的 Tool，由 AI Agent 按需調(diào)用。于是 IDE 會(huì)隨著技術(shù)演進(jìn)，越來越像一個(gè)能力容器和執(zhí)行環(huán)境，供 Agent 與人協(xié)作使用。

這三條路線最終都在不同程度上向Agentic Behavior收斂。

IDE 在“人 + Agent”的協(xié)作體驗(yàn)上持續(xù)進(jìn)化，CLI 在工程自動(dòng)化和流水線中強(qiáng)化 Agent 能力，而 Cloud Agent 則在時(shí)間和空間上擴(kuò)展了研發(fā)協(xié)作的邊界。

形態(tài)不同，但目標(biāo)高度一致：以 Agent 為主導(dǎo)的范式。Agent 形態(tài)下，大家核心訴求都趨同：能正確使用工具，能保持長程任務(wù)穩(wěn)定性，能在反饋信號(hào)下持續(xù)修正。因此，Coding Agent 能力，本質(zhì)上就是長程任務(wù)穩(wěn)定性和工具調(diào)用能力。

當(dāng)執(zhí)行權(quán)從人轉(zhuǎn)移到 Agent，軟件工程幾十年來靠經(jīng)驗(yàn)與默契兜底的復(fù)雜度，被迫前置成顯性規(guī)則——Spec 也就在這一刻被重新召回。

截圖來自《》評(píng)論區(qū)

2 Spec，真的能解決 AI Coding 的問題嗎？

從這個(gè)詞被喊熱到現(xiàn)在，不過短短幾個(gè)月，一個(gè)有些尷尬、卻無法回避的現(xiàn)實(shí)逐漸浮出水面：大家口中的“Spec”，早就不是同一個(gè)東西了。

有人說 Spec 是寫更好的 Prompt，有人把它理解為更詳細(xì)的產(chǎn)品需求文檔，也有說是架構(gòu)設(shè)計(jì)文檔，但對(duì)更多工程團(tuán)隊(duì)來說，Spec 只是“在寫代碼的時(shí)候，多用幾個(gè) Markdown 文件”。

于是你會(huì)看到 Repo 里迅速堆起 gemini.md、claude.md、agent.md、cursor-rules、各種 Skills，再加上 GitHub 的配置文件。過去幾個(gè)月，大廠的各類代理工具，都在推出“可復(fù)用上下文框架”：Claude Skills、Cursor Team Rules、GitHub Copilot Spaces，再加上第三方 Tessl、BMad Method (BMM) 等，整個(gè)工具鏈在一年內(nèi)爆炸式演進(jìn)，催生了一大批基礎(chǔ)設(shè)施新物種。

很多團(tuán)隊(duì)在實(shí)踐中會(huì)有一個(gè)直觀感受是 AI 寫代碼時(shí)并不是缺 Spec，而是缺 Context。于是就有人干脆把兩者畫上了等號(hào)：“Spec 就是上下文工程”，或“Spec 驅(qū)動(dòng)開發(fā)等價(jià)于上下文工程”。

但國內(nèi)一線工具團(tuán)隊(duì)更偏向認(rèn)為“它們不是一回事兒”。

在他們看來，Spec 更像是上下文中最關(guān)鍵、也最穩(wěn)定的一類內(nèi)容，承擔(dān)的是“指導(dǎo)性 Context”的角色：把目標(biāo)、約束和驗(yàn)收口徑講清楚，相當(dāng)于給 Agent 一份可執(zhí)行的契約，明確它要做什么、做到什么程度才算對(duì)。

在這種分工下，Spec 解決的是“我們到底要造什么”，而 Context Engineering 關(guān)注的是“在這一刻，模型是否拿到了足夠的信息”。Spec 本身不會(huì)自動(dòng)轉(zhuǎn)化為有效上下文，但往往是高質(zhì)量 Context 的長期來源——兩者高度耦合，卻無法相互替代。

也正因?yàn)槿绱耍琒pec 不應(yīng)該被限制在某幾種固定文檔形態(tài)里。更準(zhǔn)確地說，Spec 是一切用于指導(dǎo)代碼生成的契約總和：產(chǎn)品文檔、設(shè)計(jì)稿、接口定義、邊界條件、驗(yàn)收標(biāo)準(zhǔn)、執(zhí)行計(jì)劃，都可以被納入 Spec 體系之中，只是處在不同階段、不同粒度下的子集。

然而“覆蓋范圍廣、形態(tài)多、生命周期長”，Spec 才顯得格外難以標(biāo)準(zhǔn)化。

在這一輪 Spec 驅(qū)動(dòng)開發(fā)的討論中，Kiro 常被視為重要推動(dòng)者之一。其技術(shù)負(fù)責(zé)人 Al Harris 曾在公開分享中提到，為了找到合適的 Spec 形態(tài)，團(tuán)隊(duì)內(nèi)部前后嘗試過大約七種不同實(shí)現(xiàn)——從 ephemeral spec、分層 spec 到基于 TDD 的 spec，幾乎“給所有東西都加過 spec 的后綴”。說到底，他們是在反復(fù)回答三件事：Spec 什么時(shí)候該“定稿”，該定到多細(xì)，以及定下來的東西怎么跟著迭代不走樣。

不過他也強(qiáng)調(diào)，這套 Spec 驅(qū)動(dòng)開發(fā)的實(shí)現(xiàn)仍在持續(xù)演進(jìn)之中，而他們最終想押注的方向是讓 Spec 覆蓋 SDLC 的完整鏈條，把需求、設(shè)計(jì)、任務(wù)拆解乃至驗(yàn)證機(jī)制一起納入，從而把傳統(tǒng)軟件工程的嚴(yán)謹(jǐn)性帶回 AI 開發(fā)。

這背后我們繞不開一個(gè)關(guān)鍵問題：Spec 要接住的，是軟件工程幾十年積累下來的復(fù)雜性。

在 CodeBuddy 產(chǎn)品負(fù)責(zé)人黃廣民看來，Spec 的標(biāo)準(zhǔn)，本質(zhì)上是軟件工程理論在 AI 編程工具中的具象化。

但問題在于，軟件工程理論經(jīng)過多年發(fā)展，在生產(chǎn)實(shí)踐中并未形成放之四海而皆準(zhǔn)的統(tǒng)一標(biāo)準(zhǔn)。因此，不同的 Spec 變體實(shí)際上是在權(quán)衡不同的矛盾（比如靈活性與嚴(yán)謹(jǐn)性），因此其最佳粒度也因任務(wù)而異。

他認(rèn)為，Spec 標(biāo)準(zhǔn)是否有效，確實(shí)取決于應(yīng)用場景，因?yàn)?Spec 本質(zhì)上是在用一種文檔 / 結(jié)構(gòu)去交換三樣?xùn)|西：正確性、效率、維護(hù)成本。不同場景對(duì)這三者的權(quán)重不同，所以不會(huì)收斂在單一標(biāo)準(zhǔn)，而是出現(xiàn)多種接受度較高的形態(tài)。

Spec 是被“淘汰”的瀑布流程的回歸？

軟件工程本來就是高度不確定的復(fù)雜系統(tǒng)。在長程任務(wù)中，大模型會(huì)幻覺、會(huì)遺忘，也會(huì)發(fā)生目標(biāo)漂移；如果缺乏機(jī)制補(bǔ)足，Agent 很容易越做越偏，返工成本迅速放大。正因?yàn)槿绱?，Spec 才重新顯得誘人——它試圖把關(guān)鍵目標(biāo)、約束與驗(yàn)收口徑更清晰地固定下來。

但爭議也隨之而來。一位敏捷實(shí)踐者曾直言，SDD 的前進(jìn)方向本身就是錯(cuò)的。在他看來，這套方法試圖解決的，是一個(gè)早已證明走不通的問題：如何將開發(fā)人員從軟件開發(fā)過程中剔除？在這種設(shè)想中，編程 Agent 被用來取代開發(fā)人員，并通過周密的規(guī)劃來確保 Agent 可以實(shí)現(xiàn)這一目標(biāo)。這幾乎跟瀑布模型的要求一致：在編碼前完成大量的文檔工作，開發(fā)人員只需要將規(guī)范轉(zhuǎn)化為代碼即可。

問題在于，軟件開發(fā)是一個(gè)非確定性過程，規(guī)劃無法消除不確定性，正如經(jīng)典論文《沒有銀彈》所指出的那樣。敏捷方法早已淘汰了以大量前置文檔為核心的開發(fā)方式。那么，AI Coding 是否會(huì)因此走向一次“瀑布流程回歸”？

從工程視角討論 Spec，常見的落點(diǎn)并不是“要不要把思考寫全”，而是“到底該結(jié)構(gòu)化哪一部分”。在黃廣民看來，Spec Coding 真正想結(jié)構(gòu)化的并不是開發(fā)者的全部思考過程，而是那些最容易在長程任務(wù)里出錯(cuò)、也最值得被驗(yàn)證和沉淀的部分。

當(dāng)前行業(yè)對(duì) Spec 還處于探索階段。Spec 更合理的形態(tài)是“活的契約”，它不是一份靜態(tài)的、一次性的文檔，而是 Plan-Execute 閉環(huán)中的關(guān)鍵中間態(tài)：好的 Spec 驅(qū)動(dòng)實(shí)踐不是“先寫一份完美 Spec 再開始寫代碼”，而是用 Spec 把正確性口徑說清楚，然后在推理 - 執(zhí)行 - 反饋的過程中不斷校準(zhǔn) Spec 和代碼制品的一致性?！斑@反而比傳統(tǒng)開發(fā)更接近工程真實(shí)狀態(tài)，需求會(huì)變、約束會(huì)變、實(shí)現(xiàn)會(huì)變，關(guān)鍵是讓這些變化可追蹤、可驗(yàn)證、可回滾?！?/p>

把視角拉得更長一些，這個(gè)討論也會(huì)自然指向軟件工程領(lǐng)域一個(gè)由來已久的母題。天豬在交流中提到，AI Coding 的一些探索，讓他重新想起軟件工程早期反復(fù)追求卻始終未完全實(shí)現(xiàn)的目標(biāo)：是否存在一份足夠完備、可驗(yàn)證的描述，它本身就能夠清晰定義系統(tǒng)如何運(yùn)作，并且可以被可靠地復(fù)現(xiàn)。

在這樣的愿景下，Spec 不再只是代碼的前置說明或過程記錄，而是被重新放置到一個(gè)更高的位置——有可能逐步演化為一種比代碼更高層、也更穩(wěn)定的工程產(chǎn)物。

如果把軟件工程的發(fā)展歷史整體拉長來看，從最初的 0 和 1，到匯編語言、高級(jí)編程語言、DSL 以及各類配置與聲明式規(guī)范，本質(zhì)上都是在不斷提升系統(tǒng)對(duì)“人類意圖”的表達(dá)能力和抽象層級(jí)。沿著這條路徑看，Spec 更像是在自然語言這一層級(jí)上，嘗試邁出的下一次抽象升級(jí)。

當(dāng)然，這條路并不輕松。自然語言的模糊性決定了它很難被直接工程化，也注定這是一條充滿挑戰(zhàn)、尚無成熟范式的探索路徑。但正因如此，它才成為當(dāng)下業(yè)界正在反復(fù)試探和逐步推進(jìn)的一個(gè)方向，而不是一個(gè)已經(jīng)被證明或被否定的結(jié)論。

軟件抽象：為什么 Agent 總愛“自己造輪子”

在 AI Coding 的實(shí)踐中，有一個(gè)長期以來被大量開發(fā)者反復(fù)吐槽的問題：Coding Agent 極其偏好“自己從零開始實(shí)現(xiàn)功能”，而不是復(fù)用成熟庫。

一邊是在探索更高層的抽象形態(tài)，另一邊似乎又在繞開軟件工程幾十年積累下來的抽象與復(fù)用體系，特別是那些已經(jīng)被驗(yàn)證、優(yōu)化過的庫和接口。而現(xiàn)實(shí)中的開發(fā)，很少是從零開始寫一個(gè)全新的“綠地項(xiàng)目”，更多是在基于已有開源庫去改動(dòng)和擴(kuò)展已有應(yīng)用，或做修補(bǔ)的活兒。

不過對(duì)模型來說，“自己寫一個(gè)能跑的版本”往往是風(fēng)險(xiǎn)最低的路徑。當(dāng)它對(duì)某個(gè)庫的版本、用法或邊界不確定時(shí)，回退到“自己實(shí)現(xiàn)”幾乎是必然選擇。一方面，預(yù)訓(xùn)練語料在庫層面的分布并不均衡；另一方面，對(duì)齊階段的獎(jiǎng)勵(lì)更偏向“運(yùn)行正確”，而不是“是否優(yōu)先復(fù)用既有抽象”。

再疊加庫知識(shí)的時(shí)效性問題：版本更新快、API 頻繁變更、文檔缺失甚至相互沖突都很常見。即便用戶明確指定了某個(gè)庫，只要這些關(guān)鍵信息沒有被準(zhǔn)確放入上下文，模型依然可能用錯(cuò)。

但這并不是一個(gè)無解的問題。關(guān)鍵不在于反復(fù)對(duì) Agent 進(jìn)行人工糾偏或微觀干預(yù)，而在于補(bǔ)齊它可依賴的信息源。正如黃廣民所強(qiáng)調(diào)的，與其在結(jié)果階段不斷“提醒”，不如在執(zhí)行階段把信息準(zhǔn)備好：通過 Context7 這類 MCP 工具補(bǔ)齊版本、用法與示例，再用“漸進(jìn)式披露”把正確用法注入任務(wù)上下文；對(duì)于企業(yè)內(nèi)部組件庫，則需要系統(tǒng)性沉淀文檔、示例、最佳實(shí)踐與使用邊界，才能讓 Agent 穩(wěn)定復(fù)用這些抽象，而不是不斷另起爐灶。

當(dāng)新抽象未成熟、舊抽象被繞開、上下文不斷膨脹，這些問題最終都會(huì)在同一個(gè)地方匯總——運(yùn)行時(shí)成本。

3 Token 工程的崛起：為什么成本突然失控

Token 是什么時(shí)候開始變得扎心的？不是在你第一次用完免費(fèi)額度，而是在你意識(shí)到：它已經(jīng)不再是“一次對(duì)話的消耗”，而是能直接左右工具定價(jià)、產(chǎn)品策略，甚至逼平臺(tái)改規(guī)則的核心變量。

今年有兩件事幾乎同時(shí)把這件事推到了臺(tái)前。一個(gè)是 Cursor：有人在相對(duì)便宜的訂閱檔里，用特定方式跑出遠(yuǎn)超平臺(tái)預(yù)期的調(diào)用量，成本邊界被薅穿。隨后不到一年，，想減少虧空。

另一個(gè)發(fā)生在 Claude Code 的 Token 排行榜： 用 200 美元套餐在 30 天里燒掉 77 億 Token，折算賬單約 5 萬美金。一個(gè)“使用排行”，將 Anthropic 逼到直接給付費(fèi)用戶加上調(diào)用速率限制。

這兩幕背后指向同一個(gè)事實(shí)：Token 已經(jīng)從“計(jì)費(fèi)單位”變成了生死線。

為什么 Token 在 2025 年突然復(fù)雜了一個(gè)數(shù)量級(jí)？

根本原因并不在“模型更貴”，而在范式遷移：大模型應(yīng)用正在從“問答”，躍遷到“Agent 做事”。當(dāng)模型被要求“把一件事做完”，Token 成本就不再是單次輸入輸出，而是貫穿推理—執(zhí)行—反饋鏈路的全生命周期成本。

最關(guān)鍵的變化是：工具調(diào)用的隱形成本開始吃掉大頭。

為了完成一個(gè)任務(wù)，往往需要多輪對(duì)話；而每一輪對(duì)話背后又會(huì)經(jīng)歷幾次到幾百次不等的工具調(diào)用。這意味著上下文里存在大量可復(fù)用的穩(wěn)定信息，也就留下了上下文緩存與重用的空間。模型平臺(tái)的計(jì)價(jià)規(guī)則也有差異，不同模型、不同廠商對(duì)輸入 / 輸出定價(jià)、緩存命中收益、工具調(diào)用的隱性開銷并不一致，進(jìn)一步放大了 Token 經(jīng)濟(jì)學(xué)的復(fù)雜度。

大模型剛出現(xiàn)時(shí)，成本主要是對(duì)話本身。而現(xiàn)在，檢索返回、文件 diff、終端日志等等，大量工具輸出其實(shí)是給下一輪模型閱讀的，它們會(huì)反復(fù)回灌進(jìn)上下文，成為新的主要成本來源。

這也是為什么工程團(tuán)隊(duì)今年會(huì)特別關(guān)注 log 過濾、diff slicing、輸出摘要等能力，本質(zhì)上都是在控制“給模型看的 Token”，把無效信息從上下文里剔掉。

Spec Coding 和多 Agent 協(xié)作讓成本結(jié)構(gòu)繼續(xù)膨脹：隨著 Spec Coding 的興起，Coding Agent 的產(chǎn)出不再只是代碼文件，Spec/Plan/ToDo/ 變更說明 / 驗(yàn)收清單等中間產(chǎn)物會(huì)被反復(fù)生成、引用與迭代，形成新的上下文常駐內(nèi)容；多 Agent 又把 Token 變成通信效率問題——傳什么、傳多細(xì)、怎么壓縮、如何避免失真，本質(zhì)上都是在成本與有效信息之間做取舍。

Token 工程的真正戰(zhàn)場：上下文管理

對(duì)開發(fā)者來說，關(guān)心的仍然只有三件事：效果、效率、成本。但決定這三件事的，早就不是某一次 Prompt 寫得好不好，而是 Agent 在背后怎么組織上下文、怎么調(diào)用工具、怎么重試與糾錯(cuò)。

這也意味著，Token 的復(fù)雜度真正壓在的，是 AI 編程工具本身。

在大多數(shù)模型平臺(tái)里，上下文的執(zhí)行依賴 KV cache。理論上，只要上下文沒有變化，模型就可以直接命中緩存，避免重復(fù)計(jì)算；但在真實(shí)工程中，緩存命中遠(yuǎn)沒有想象中理想。一旦 miss，你等于在重新為同一段上下文付費(fèi)：API 用戶要重新承擔(dān) prefill 成本，訂閱用戶則會(huì)更早、更頻繁地撞上 rate limit——而速率限制，和緩存使用情況高度相關(guān)。

這也是為什么上下文平臺(tái)工程的目標(biāo)聽起來如此“功利”：最大化 KV cache 命中率。不是為了省幾分錢，而是為了避免在長程 Agent 任務(wù)中，被重復(fù)、無意義的上下文刷新拖垮吞吐和穩(wěn)定性。

哪些信息應(yīng)該長期保留，哪些只是階段性的中間產(chǎn)物；哪些內(nèi)容在完成階段目標(biāo)后就應(yīng)該被及時(shí)清理——這些選擇，直接決定了系統(tǒng)的成本結(jié)構(gòu)、速率上限，以及 Agent 能否持續(xù)跑下去。

上下文工程的技術(shù)演進(jìn)

回顧上下文工程的技術(shù)演進(jìn)歷程，天豬認(rèn)為行業(yè)并不存在一勞永逸的解法。更多時(shí)候，是在不斷試錯(cuò)中，從早期的Prompt Engineering，逐步演進(jìn)到今天更系統(tǒng)化的Context Engineering。

在早期，Fine-Tuning被視為一種直接方案：通過在大模型層面注入領(lǐng)域知識(shí)，補(bǔ)充其世界模型的盲區(qū)。但實(shí)踐很快證明，這種方式在 AI Coding 場景下成本高昂、靈活性不足，且難以應(yīng)對(duì)多模型頻繁切換的現(xiàn)實(shí)需求。相比之下，以RAG為代表的 “外掛式知識(shí)補(bǔ)充” 在工程上更具性價(jià)比，也更符合 AI Coding 的實(shí)際使用模式。

在 AI Coding 的早期階段，交互主要是一問一答的Chat 模式，模型對(duì)“首輪輸入 Context”的依賴極高，因此需要在提問時(shí)盡可能一次性注入相關(guān)背景，這直接推動(dòng)了 RAG 召回機(jī)制的普及。

隨著Coding Agent的出現(xiàn)，協(xié)作模式發(fā)生了根本變化：交互從單輪對(duì)話轉(zhuǎn)向多輪、長期的 Agent Loop。此時(shí)，相關(guān)信息不再需要在第一輪全部給出，而是由 Agent 在執(zhí)行過程中按需檢索與召回。這一變化催生了embedding search與grep等能力的逐步登場。

其中，Cline 和 Claude Code 在今年就從傳統(tǒng)的 RAG 轉(zhuǎn)向grep，Cline 甚至直言“不能再用 2023 年的辦法解決今天的問題”。

需要強(qiáng)調(diào)的是，embedding search 并未過時(shí)。它更像是數(shù)據(jù)庫中的 index，在特定條件下能夠顯著提升召回效率，而 grep 則在確定性和精確匹配上具備優(yōu)勢，兩者往往服務(wù)于不同的檢索階段和需求類型。

進(jìn)一步地，隨著任務(wù)復(fù)雜度和檢索路徑的增加，Agentic Search逐漸演化出來，并常與Sub Agent機(jī)制協(xié)同出現(xiàn)。在復(fù)雜場景中，許多 Tool Call 的中間歷史并不具備長期價(jià)值，因此會(huì)出現(xiàn)專門的Search Agent：它自身運(yùn)行一個(gè)獨(dú)立的 Agent Loop，負(fù)責(zé)多輪檢索、篩選與驗(yàn)證，而 embedding search、grep、LSP 等僅僅是其可組合使用的工具能力。

走到這一步，行業(yè)逐漸意識(shí)到：真正稀缺的不是上下文長度，而是有效 Context 的組織能力。

把上下文拆分為穩(wěn)定信息與變化信息，讓變化部分足夠精準(zhǔn)、長度可控、可驗(yàn)證；再通過緩存、裁剪、摘要、檢索等機(jī)制，把 Token 的邊際成本控制在工程可接受的范圍內(nèi)，同時(shí)避免因關(guān)鍵信息缺失而放大返工成本——這正是 Token 工程最終落地的地方。

4 寫在最后

如果把 AI 編程看成一個(gè)系統(tǒng)工程，它至少由四層共同構(gòu)成：模型負(fù)責(zé)“思考”，Tool 負(fù)責(zé)“行動(dòng)”，IDE 承載人機(jī)交互，而上下文負(fù)責(zé)“記憶與連續(xù)性”。

模型層決定上限；Tool 決定它能不能真的做事；IDE 決定人是否能高效表達(dá)意圖、及時(shí)糾偏；而上下文層把這一切粘合在一起，承載歷史決策、工程約束與連續(xù)性，是長期可靠性的基礎(chǔ)。

因此，未來 AI 編程的真正分水嶺，或許并不僅僅在于“誰的模型更強(qiáng)”，而還在于誰能持續(xù)、準(zhǔn)確地把工程世界中那些原本隱性的約束、記憶和共識(shí)，轉(zhuǎn)化為模型可理解、可執(zhí)行、并可被反復(fù)驗(yàn)證的上下文結(jié)構(gòu)，在天豬看來，AI 編程從來不是單一模型能力的比拼，而是工程體系與模型能力共同作用的結(jié)果。

這，才是 AI Coding 正在補(bǔ)上的那幾塊“工程短板”。

想看更完整的對(duì)話與細(xì)節(jié)展開：

《對(duì)話 CodeBuddy 黃廣民：一堆冒煙的上下文，正在決定 AI 編程的成敗》（

https://www.infoq.cn/article/j8jMvIOfmZS8M33t72uP

《對(duì)話 TRAE 天豬：AI 時(shí)代的挑戰(zhàn)與程序員的認(rèn)知進(jìn)化》（https://www.infoq.cn/article/EiO80Aacx4sMZHjtXqNR）

加入InfoQ年度盤點(diǎn)讀者群，第一時(shí)間獲取盤點(diǎn)文章更新

技術(shù)人的年度儀式感！ 年度盤點(diǎn)與趨勢洞察 啟動(dòng)！

《2025 年度盤點(diǎn)與趨勢洞察》由 InfoQ 技術(shù)編輯組策劃。覆蓋大模型、Agent、具身智能、AI Native 開發(fā)范式、AI 工具鏈與開發(fā)、AI+ 傳統(tǒng)行業(yè)等方向，通過長期跟蹤、與業(yè)內(nèi)專家深度訪談等方式，對(duì)重點(diǎn)領(lǐng)域進(jìn)行關(guān)鍵技術(shù)進(jìn)展、核心事件和產(chǎn)業(yè)趨勢的洞察盤點(diǎn)。

力求以體系化視角幫助讀者理解年度技術(shù)演化的底層邏輯、創(chuàng)新方向與落地價(jià)值，并為新一年決策提供參考。內(nèi)容將在 InfoQ 媒體矩陣陸續(xù)放出，歡迎大家持續(xù)關(guān)注。