我最近在帶一個(gè) AI 輔助編程的項(xiàng)目代碼倉(cāng)庫(kù)越來越大開發(fā)新功能時(shí)模型頻繁答非所問要么漏掉關(guān)鍵約束要么把無關(guān)模塊的舊邏輯也帶進(jìn)來。排查到最后問題不在模型本身而在輸入給模型的那塊“背景信息”上——上下文里塞了太多低價(jià)值內(nèi)容真正重要的部分反而被稀釋了。后來我干脆自己寫了套上下文管理模式context-mode專門治理這個(gè)問題。這篇文章就把我做這套東西的完整思路、實(shí)現(xiàn)細(xì)節(jié)和踩坑過程記錄下來。說實(shí)話當(dāng)下的開發(fā)工作流里AI 工具的上下文管理幾乎是個(gè)被所有人感知、但很少有人系統(tǒng)化解決的問題。很多人覺得“上下文不夠就多貼點(diǎn)”結(jié)果上下文越貼越亂模型的表現(xiàn)反而越來越差。context-mode 的核心不是“給更多”而是“給得準(zhǔn)”——對(duì)上下文做結(jié)構(gòu)化、打分排序、按需裁剪讓每一寸上下文窗口都花在刀刃上。這篇文章適合正在用 AI 編程助手、被上下文窗口限制折磨的開發(fā)者也適合想給自己的 AI 工具鏈搭一套上下文管理基礎(chǔ)設(shè)施的技術(shù)負(fù)責(zé)人。順便說一句這套機(jī)制完全和具體模型無關(guān)你用的是閉源 API 也好、本地開源模型也好思路都是一樣適用的。1. context-mode 要解決的問題上下文窗口不是越大越好1.1 一個(gè)具體崩潰場(chǎng)景先說我遇到的那個(gè)具體場(chǎng)景。項(xiàng)目里有一個(gè)支付模塊橫跨前端、網(wǎng)關(guān)、風(fēng)控、回調(diào)通知四個(gè)子系統(tǒng)每個(gè)子系統(tǒng)都有一堆歷史文檔。當(dāng)時(shí)要做的是一個(gè)“基于用戶歷史行為的風(fēng)控策略調(diào)整”我按常規(guī)做法把相關(guān)代碼文件、需求文檔、接口定義全部塞給模型一次性貼了大概兩萬 token 的上下文。模型輸出確實(shí)能看懂需求但給出的方案里混入了大量舊版風(fēng)控規(guī)則的描述還引用了已經(jīng)被下線的一個(gè)“黑名單名單庫(kù)”接口——這個(gè)接口在當(dāng)前代碼庫(kù)里根本不存在因?yàn)樗齻€(gè)月前就廢棄了。這事讓我意識(shí)到模型跑偏不大可能是參數(shù)問題而是我給它的上下文里同時(shí)包含了“正確的舊信息”和“已經(jīng)過時(shí)但仍然存在的舊信息”模型沒有可靠依據(jù)來區(qū)分這兩者。再往深了說人類程序員在接手同樣任務(wù)時(shí)會(huì)自動(dòng)做一件事把注意力聚焦在當(dāng)前版本的關(guān)鍵路徑上忽略掉歷史遺留和無關(guān)模塊。但直接把整個(gè)倉(cāng)庫(kù)丟給模型它做不到這種聚焦。所以 context-mode 的實(shí)現(xiàn)目標(biāo)本質(zhì)上就是把“人類程序員的上下文聚焦能力”用工程手段實(shí)現(xiàn)出來。1.2 根本矛盾信息量 vs 信號(hào)密度上下文管理的核心矛盾用一句話概括上下文窗口的確在變大但模型對(duì)長(zhǎng)上下文的注意力會(huì)分散尤其是在中間位置的信息最容易丟。我把這個(gè)問題拆成兩個(gè)維度信息量上下文里到底包含了多少和當(dāng)前任務(wù)相關(guān)的實(shí)體、約束、代碼位置。信號(hào)密度相關(guān)信息在全部上下文中的占比。大多數(shù)人的做法只提升了前者忽略后者。貼了十個(gè)文件進(jìn)去只有兩個(gè)真正相關(guān)那信息量是上去了但信號(hào)密度下來了模型的選擇性注意力機(jī)制會(huì)讓它更關(guān)注開頭和結(jié)尾的內(nèi)容中間的關(guān)鍵邏輯反而被當(dāng)噪聲濾掉。context-mode 的思路就是反過來主動(dòng)降低無效信息的絕對(duì)量把上下文里塞滿高密度信號(hào)寧可信息量略少也必須保證每條信息都精準(zhǔn)命中當(dāng)前任務(wù)。1.3 上下文管理的三個(gè)實(shí)際成本除了信號(hào)密度問題還有三個(gè)常常被忽略的成本第一是成本問題。按 token 計(jì)費(fèi)的 API 服務(wù)上下文越長(zhǎng)、單次請(qǐng)求就越貴。如果一個(gè)功能要反復(fù)迭代十輪每輪都帶三萬 token 的“行李”那這中間浪費(fèi)的錢非常可觀。第二是延遲。上下文越長(zhǎng)prefill 階段的計(jì)算量越大首 token 返回時(shí)間基本線性增長(zhǎng)。在實(shí)際交互場(chǎng)景里多等三秒和少等三秒體感差異極其明顯。第三是出錯(cuò)風(fēng)險(xiǎn)。長(zhǎng)上下文帶來的一個(gè)隱蔽問題是“慣性漂移”。模型會(huì)順著上下文里既有的寫法往下走哪怕這個(gè)寫法已經(jīng)被標(biāo)記為待廢棄。只要有舊代碼在上下文里模型就會(huì)傾向于產(chǎn)出和舊代碼風(fēng)格一致的新代碼而不是采用你希望的新架構(gòu)。前兩個(gè)還好說第三個(gè)問題幾乎只能靠控制上下文內(nèi)容來解決。這也是我在很多內(nèi)部討論里反復(fù)強(qiáng)調(diào)的別把上下文只當(dāng)成“輸入”要把它當(dāng)成“約束條件”。模型不是被問題塑造的而是被上下文塑造的。2. context-mode 的三層架構(gòu)標(biāo)簽過濾、優(yōu)先級(jí)排序、窗口回收2.1 第一層上下文標(biāo)簽體系要做上下文管理第一步不是寫代碼而是建立一套描述上下文的標(biāo)簽體系。我采用的標(biāo)簽體系是沿著“內(nèi)容類型 × 生命周期 × 權(quán)威層級(jí)”三個(gè)維度展開的。內(nèi)容類型代碼文件、接口定義、依賴配置、需求描述、歷史決策記錄、測(cè)試用例、運(yùn)行日志。 生命周期永久核心項(xiàng)目架構(gòu)說明、全局規(guī)范、版本相關(guān)當(dāng)前迭代的需求文檔、變更記錄、臨時(shí)相關(guān)本次任務(wù)臨時(shí)引入的報(bào)錯(cuò)堆棧、一次性某個(gè)具體函數(shù)的局部實(shí)現(xiàn)。 權(quán)威層級(jí)強(qiáng)約束接口簽名、編譯錯(cuò)誤、命令行規(guī)范、中約束業(yè)務(wù)規(guī)則描述、模塊邊界說明、弱約束歷史討論、個(gè)人偏好、非強(qiáng)制性建議。這個(gè)標(biāo)簽體系直接決定了后續(xù)過濾和排序的效果。比如一個(gè)文件內(nèi)容既有永久核心的架構(gòu)描述又有臨時(shí)相關(guān)的報(bào)錯(cuò)信息那它就應(yīng)該被拆開處理而不是整體塞進(jìn)上下文。實(shí)際落地時(shí)我給每個(gè)代碼倉(cāng)庫(kù)維護(hù)了一份 context-manifest.json里面按模塊寫明哪些路徑屬于“核心穩(wěn)定層”、哪些屬于“版本活躍層”、哪些屬于“禁止自動(dòng)帶入層”。這套文件是人工維護(hù)的但維護(hù)成本極低因?yàn)橐粋€(gè)模塊的結(jié)構(gòu)不會(huì)天天變真正經(jīng)常變的只是版本活躍層里那幾句描述。2.2 第二層上下文優(yōu)先級(jí)打分有了標(biāo)簽接下來就是對(duì)每條候選上下文做打分排序。我給每條候選內(nèi)容算一個(gè)綜合分得分 內(nèi)容類型權(quán)重 × 任務(wù)相關(guān)度系數(shù) × 時(shí)效系數(shù)舉個(gè)簡(jiǎn)單的例子用戶要調(diào)整支付回調(diào)邏輯候選內(nèi)容有當(dāng)前支付回調(diào)的接口實(shí)現(xiàn)文件相關(guān)度 1.0類型權(quán)重 0.9時(shí)效 0.9得分約 0.81三個(gè)月前的風(fēng)控說明文檔相關(guān)度 0.6類型權(quán)重 0.5時(shí)效 0.3得分約 0.09全局架構(gòu) README相關(guān)度 0.4類型權(quán)重 0.8時(shí)效 1.0得分約 0.32。那最后進(jìn)上下文的優(yōu)先級(jí)就是回調(diào)實(shí)現(xiàn)文件 架構(gòu) README 風(fēng)控舊文檔。如果窗口不夠后兩項(xiàng)就得讓位。打分這塊其實(shí)不需要復(fù)雜的語義模型。我用的是關(guān)鍵詞命中加人工標(biāo)注相結(jié)合的方式把任務(wù)描述拆成名詞實(shí)體和動(dòng)詞動(dòng)作兩類然后到候選內(nèi)容里做加權(quán)匹配。命中名詞實(shí)體的權(quán)重高命中動(dòng)詞動(dòng)作的權(quán)重稍低兩邊都命中的內(nèi)容分最高。這套規(guī)則簡(jiǎn)單粗暴但實(shí)際效果比某些復(fù)雜向量檢索穩(wěn)定得多因?yàn)轫?xiàng)目上下文里的大量術(shù)語是高度定制化的向量模型不一定能處理好。2.3 第三層上下文窗口的滾動(dòng)回收前兩層解決的是“選什么進(jìn)上下文”第三層解決的是“上下文滿了怎么辦”。我設(shè)置了一個(gè)硬頂比如 8K token 的窗口上限每當(dāng)要加入新內(nèi)容時(shí)先檢查當(dāng)前總量超了就按得分從低到高淘汰直到塞得下新內(nèi)容。這個(gè)過程我做了兩個(gè)補(bǔ)充約束強(qiáng)約束內(nèi)容永不淘汰接口簽名、錯(cuò)誤信息這類高權(quán)威內(nèi)容一旦進(jìn)入上下文再低分也不踢出去。剛加入的內(nèi)容有短暫保護(hù)期新內(nèi)容加入后 2 輪對(duì)話內(nèi)不會(huì)被立即淘汰避免出現(xiàn)“剛說完就忘了”的情況。這個(gè)回收機(jī)制看起來簡(jiǎn)單但它是整個(gè) context-mode 的穩(wěn)定器。沒有它上下文管理就是一次性快照沒辦法應(yīng)對(duì)長(zhǎng)會(huì)話里的持續(xù)演進(jìn)。3. 手把手實(shí)現(xiàn) context-mode一套輕量級(jí)上下文管理服務(wù)3.1 環(huán)境與工具選型我實(shí)現(xiàn)這套系統(tǒng)的時(shí)候沒有引入重型框架核心就三個(gè)組件Python 3.10 寫服務(wù)端邏輯SQLite 存標(biāo)簽配置和上下文操作日志一個(gè)基于 FastAPI 的本地 HTTP 服務(wù)統(tǒng)一對(duì)外提供上下文組裝接口。選這些不是因?yàn)樗鼈冏睢跋冗M(jìn)”而是因?yàn)?context-mode 的核心價(jià)值不在框架而在策略。換句話說所有策略邏輯加起來也就幾百行代碼不需要為了它去上微服務(wù)那一套。如果后續(xù)要接更大的團(tuán)隊(duì)需要多模接入那就再封裝一層適配器底層的策略邏輯不用動(dòng)。工具選型這一步我給個(gè)明確建議先別碰那些專門做 context 編排的重型平臺(tái)因?yàn)樗鼈兊某橄髮蛹?jí)太高出現(xiàn)問題很難定位到具體是哪條策略導(dǎo)致的。自己寫一個(gè)幾百行的服務(wù)你能看清楚每一次上下文組裝的前因后果這對(duì)調(diào)試來說太重要了。3.2 核心數(shù)據(jù)結(jié)構(gòu)整個(gè)系統(tǒng)的核心數(shù)據(jù)模型就三張表context_items上下文條目、tags標(biāo)簽定義、task_sessions任務(wù)會(huì)話。context_items 表的關(guān)鍵字段字段名用途item_id條目標(biāo)識(shí)比如 file:///src/payment/callback.pycontent_preview內(nèi)容預(yù)覽用于展示時(shí)判斷是否誤選item_typecode / doc / api / log / requirementlifecyclecore / versioned / temp / ephemeralauthoritystrong / medium / weakkeywords逗號(hào)分隔的關(guān)鍵詞列表last_updated最后更新時(shí)間用于時(shí)效系數(shù)計(jì)算task_sessions 表就簡(jiǎn)單一點(diǎn)session_id、task_description、created_at、total_tokens_used。每次組裝上下文都往這個(gè)表里寫一條記錄方便事后復(fù)盤“為什么剛才那次會(huì)話帶了這些內(nèi)容”。這里我特意強(qiáng)調(diào)了復(fù)盤能力因?yàn)樵谡{(diào)試 prompt 效果時(shí)最怕的就是不知道模型看到了什么。有了 session 記錄每一次失敗都能回到當(dāng)時(shí)的上下文去檢查定位問題的速度會(huì)快非常多。3.3 上下文組裝流程的實(shí)現(xiàn)組裝流程有四個(gè)步驟任務(wù)解析、候選召回、打分排序、窗口壓縮。第一步把用戶的任務(wù)描述拆成名詞實(shí)體和動(dòng)詞動(dòng)作。我用了一個(gè)很小的基于規(guī)則的分詞器內(nèi)置了一個(gè)項(xiàng)目專屬名詞表比如“支付回調(diào)”“風(fēng)控”“網(wǎng)關(guān)”“黑名單”……命中名詞表的詞會(huì)被單獨(dú)標(biāo)記不參與通用分詞。第二步根據(jù)名詞實(shí)體和標(biāo)簽體系召回候選。檢查每個(gè)候選條目的關(guān)鍵詞是否命中任務(wù)描述的名詞實(shí)體命中一個(gè)就能召回。這里的召回條件要放寬寧可多召回也不能漏掉關(guān)鍵項(xiàng)。第三步按前面說的公式打分排序。這一步包含時(shí)效系數(shù)的計(jì)算last_updated 距當(dāng)前時(shí)間越近時(shí)效系數(shù)越高超過 90 天沒有更新的代碼文件時(shí)效系數(shù)會(huì)降到 0.3 以下。第四步做窗口壓縮。按得分從低到高淘汰直至總 token 數(shù)小于等于硬頂。但凡是強(qiáng)約束標(biāo)記的內(nèi)容直接跳過淘汰邏輯。這套流程跑起來之后我每次發(fā)起任務(wù)請(qǐng)求都走組裝接口拿到的上下文是動(dòng)態(tài)生成的而不是手工拼貼的。3.4 代碼實(shí)現(xiàn)示例這里給一個(gè)簡(jiǎn)化版的核心代碼幫助理解整個(gè)流程。完整版涉及項(xiàng)目?jī)?nèi)部結(jié)構(gòu)比較多就不貼了只看骨架。# context_mode/assembler.py # 簡(jiǎn)化版上下文組裝流程 from dataclasses import dataclass dataclass class ContextItem: item_id: str item_type: str lifecycle: str authority: str keywords: list last_updated: float content: str token_size: int def assemble_context(task_desc, items, hard_limit8000): # 1. 任務(wù)解析通過關(guān)鍵詞匹配得到一組候選 entities extract_entities(task_desc) # [支付回調(diào), 風(fēng)控策略] candidates [item for item in items if is_hit(item, entities)] # 2. 打分排序 for item in candidates: item.score score_item(item, entities) candidates.sort(keylambda x: x.score, reverseTrue) # 3. 窗口壓縮強(qiáng)約束內(nèi)容不淘汰 selected [] total_tokens 0 for item in candidates: if total_tokens item.token_size hard_limit and item.authority ! strong: continue selected.append(item) total_tokens item.token_size if total_tokens hard_limit: break return selected def extract_entities(task_desc: str) - list: # 用預(yù)置名詞表做提取示例略 return [支付回調(diào), 風(fēng)控策略]在跑通這套基礎(chǔ)流程之后你會(huì)發(fā)現(xiàn)一個(gè)很自然的需求上下文組裝不能只是靜態(tài)快照它必須是一個(gè)持續(xù)演進(jìn)的過程。所以我又加了一個(gè)增量刷新機(jī)制每一輪對(duì)話結(jié)束后會(huì)根據(jù)用戶的新輸入重新運(yùn)行組裝流程把新出現(xiàn)的實(shí)體納入召回范圍再把已經(jīng)失去價(jià)值的舊條目淘汰掉。3.5 與 LLM API 的對(duì)接方式組裝好的上下文怎么傳給模型我用的是 Prompt 模板預(yù)填充的方式。具體來說FastAPI 服務(wù)返回的不是字符串而是一條組裝好的消息列表。最前面是 system 指令說明“以下內(nèi)容是 context-mode 根據(jù)當(dāng)前任務(wù)篩選出的項(xiàng)目背景資料回答時(shí)以其中強(qiáng)約束條目為優(yōu)先級(jí)”。然后按順序附上選中的上下文條目每個(gè)條目前面加一行元信息標(biāo)記它的標(biāo)簽和權(quán)重比如[code][core][strong] file:///src/payment/callback.py模型通過這行標(biāo)記能快速判斷后面內(nèi)容的權(quán)威性和時(shí)效性從而更合理地分配注意力。實(shí)際效果是加了元信息標(biāo)記之后模型對(duì)強(qiáng)約束內(nèi)容的遵守率明顯提升這個(gè)在后面實(shí)測(cè)數(shù)據(jù)里會(huì)展示。4. 實(shí)測(cè)效果開啟 context-mode 前后的直觀對(duì)比4.1 測(cè)試場(chǎng)景設(shè)計(jì)為了量化 context-mode 的提升效果我做了三組測(cè)試任務(wù)任務(wù) A在支付回調(diào)模塊中增加一個(gè)新的冪等校驗(yàn)邏輯任務(wù) B重構(gòu)風(fēng)控策略查詢邏輯從同步查詢改為異步批量上報(bào)任務(wù) C排查一個(gè)偶發(fā)的回調(diào)超時(shí)問題。每個(gè)任務(wù)都跑兩輪一輪用“全量手工貼上下文”的傳統(tǒng)方式一輪用 context-mode 組裝后的精簡(jiǎn)上下文。為了避免隨機(jī)性每個(gè)任務(wù)跑三次取效果中位數(shù)。衡量指標(biāo)我選了三個(gè)首輪答案可運(yùn)行率不報(bào)錯(cuò)、不引用過期接口最終生成代碼需要的人工修正行數(shù)每輪交互平均耗時(shí)從發(fā)送請(qǐng)求到拿到首個(gè) token。4.2 數(shù)值對(duì)比三組任務(wù)跑完的數(shù)據(jù)如下任務(wù)傳統(tǒng)方式可運(yùn)行率context-mode 可運(yùn)行率傳統(tǒng)方式修正行數(shù)context-mode 修正行數(shù)傳統(tǒng)方式平均延遲context-mode 平均延遲任務(wù) A33%89%37 行11 行5.8s2.1s任務(wù) B44%78%52 行19 行6.7s2.5s任務(wù) C67%100%59 行8 行7.2s2.2s數(shù)據(jù)說明兩個(gè)直觀結(jié)論第一首輪答案質(zhì)量提升非常明顯尤其是任務(wù) C幾乎沒有再出現(xiàn)引用過期接口的問題第二延遲下降幅度很大直接原因就是從大約兩萬 token 的上下文降到了四千到五千 token。真正讓我意外的還不是這些正向指標(biāo)而是任務(wù) B 的修正行數(shù)沒有低于預(yù)期深入看原因后發(fā)現(xiàn)問題出在異步改造涉及到的模塊范圍比預(yù)估的大context-mode 召回的上下文里缺少了一個(gè)上游服務(wù)的數(shù)據(jù)結(jié)構(gòu)說明。后來在標(biāo)簽配置里補(bǔ)上了該條目的關(guān)鍵詞這個(gè)缺口就消失了。這說明 context-mode 不是純自動(dòng)系統(tǒng)它的效果很大程度依賴初始標(biāo)簽配置的完整度。4.3 信號(hào)密度提升的量化把上面那次測(cè)試的上下文體積做統(tǒng)計(jì)傳統(tǒng)方式平均每次請(qǐng)求的上下文 token 數(shù)是 18400context-mode 降到 4600。為什么降幅這么明顯核心在于標(biāo)簽過濾的結(jié)果是把整個(gè)目錄全部剔除只留真正命中的文件。那些“順手”貼進(jìn)來的無關(guān)文檔在傳統(tǒng)方式里占了幾乎一半的 token 量現(xiàn)在被完全清掉了。信號(hào)密度方面我統(tǒng)計(jì)了上下文里與任務(wù)直接相關(guān)的句子占全文的比例傳統(tǒng)方式大概是 12%context-mode 提升到 47%。這個(gè)數(shù)字非常直觀地解釋了模型表現(xiàn)提升的來源——它對(duì)相關(guān)信息看得更清楚了。5. 實(shí)測(cè)中的三個(gè)大坑和對(duì)應(yīng)解法5.1 坑一語義相關(guān)但關(guān)鍵詞不命中的條目被誤殺第一次跑測(cè)試時(shí)就發(fā)現(xiàn)了這個(gè)問題。任務(wù)描述是“回調(diào)超時(shí)如何排查”但真正涉及超時(shí)監(jiān)控的模塊文件關(guān)鍵詞只有一句話沒有直接出現(xiàn)“回調(diào)”這個(gè)詞導(dǎo)致召回階段被漏掉。解法是給 keywords 字段加“同義擴(kuò)展”配置。我在項(xiàng)目里手工維護(hù)了一張同義詞表比如“超時(shí)”對(duì)應(yīng)“timeout、延遲、慢請(qǐng)求、上游阻塞”召回時(shí)先做同義詞展開再做匹配。后續(xù)又加了基于源碼注釋的自動(dòng)關(guān)鍵詞提取凡是文檔標(biāo)注過“依賴”“關(guān)聯(lián)”關(guān)系的都會(huì)補(bǔ)充到雙方條目的 keywords 里。這個(gè)坑給到的教訓(xùn)是上下文管理的召回環(huán)節(jié)寧可寬不可窄。漏招的代價(jià)比多招更大因?yàn)樯僖粭l關(guān)鍵上下文模型可能直接方向性錯(cuò)誤而多招一條頂多占點(diǎn) token。5.2 坑二內(nèi)容類型權(quán)重設(shè)計(jì)過細(xì)反而打架最初我給內(nèi)容類型權(quán)重設(shè)計(jì)了十個(gè)檔位比如“接口定義 0.9、代碼實(shí)現(xiàn) 0.8、測(cè)試用例 0.6、運(yùn)行日志 0.5……”結(jié)果發(fā)現(xiàn)這帶來一個(gè)很奇怪的現(xiàn)象排查類任務(wù)召回的日志內(nèi)容被大量淘汰因?yàn)槿罩镜臋?quán)重太低每條得分都拼不過代碼文件。后來我把十檔壓縮成四檔0.9接口和強(qiáng)約束、0.75代碼和架構(gòu)、0.5需求和測(cè)試、0.35日志和臨時(shí)記錄。同時(shí)加了一個(gè)任務(wù)類型修正系數(shù)如果判斷任務(wù)描述偏向排查診斷日志內(nèi)容的權(quán)重自動(dòng)乘以 1.5。這個(gè)改動(dòng)告訴我的道理很樸素權(quán)重設(shè)計(jì)的核心不是精細(xì)而是讓模型和策略都有一致的行為預(yù)期。十個(gè)檔位之間差別太小排序穩(wěn)定性反而差。5.3 坑三強(qiáng)約束內(nèi)容永不淘汰導(dǎo)致上下文僵化強(qiáng)約束內(nèi)容永不淘汰的設(shè)計(jì)起初是為了保證模型不會(huì)丟掉接口約定但實(shí)際跑下來發(fā)現(xiàn)一個(gè)問題如果一場(chǎng)對(duì)話涉及的強(qiáng)約束條目太多比如要同時(shí)改三個(gè)子系統(tǒng)的接口強(qiáng)約束內(nèi)容可能會(huì)累加到一萬多 token擠占掉其他中約束內(nèi)容的空間而某些中約束的上下文在當(dāng)前步驟里其實(shí)更重要?，F(xiàn)在我把“永不淘汰”改成了“核心槽位機(jī)制”。就是把強(qiáng)約束內(nèi)容分成三個(gè)槽位全局強(qiáng)約束比如構(gòu)建命令、語言版本任何時(shí)候都保留任務(wù)相關(guān)的強(qiáng)約束按相關(guān)性排序最多保留五個(gè)超出槽位的強(qiáng)約束降級(jí)為中約束參與整體排序。這個(gè)調(diào)整相當(dāng)于給強(qiáng)約束內(nèi)容設(shè)了一個(gè)“上線”保證它們不會(huì)被極端場(chǎng)景下的過多數(shù)目反噬。修正后重新跑了任務(wù) B修正行數(shù)從 19 行降到了 13 行雖然不如任務(wù) A 那么驚艷但趨勢(shì)是對(duì)的。6. context-mode 的擴(kuò)展方向從編程輔助到跨場(chǎng)景復(fù)用6.1 應(yīng)用在文檔問答場(chǎng)景的改造思路做完編程場(chǎng)景下的驗(yàn)證之后我順手把 context-mode 用到了一個(gè)內(nèi)部知識(shí)庫(kù)問答機(jī)器人上。底層的標(biāo)簽過濾邏輯完全不用改只是把內(nèi)容類型換成了制度文檔、流程手冊(cè)、歷史工單、FAQ。打分排序邏輯也沿用只是把“時(shí)效系數(shù)”換成了“版本有效系數(shù)”。實(shí)際體驗(yàn)下來問答機(jī)器人關(guān)于新流程的準(zhǔn)確率明顯上升。這讓我確認(rèn)了一件事context-mode 本質(zhì)上不是“AI 編程助手專用工具”而是一種通用的上下文治理方法論——只要你的場(chǎng)景是“從大量信息中提取少量高價(jià)值內(nèi)容交給模型”這套三層架構(gòu)就都適用。6.2 與 RAG 檢索增強(qiáng)生成的組合玩法很多人會(huì)問context-mode 和 RAG 有什么關(guān)系是不是重復(fù)了我認(rèn)為它們是互補(bǔ)關(guān)系。RAG 解決的是“在超大知識(shí)庫(kù)里檢索出若干文檔片段”的問題而 context-mode 解決的是“在檢索回的大量片段之間做優(yōu)先級(jí)整合”的問題。實(shí)際使用時(shí)RAG 召回結(jié)果作為 context-mode 的候選集再由 context-mode 按標(biāo)簽體系和任務(wù)相關(guān)度做二次篩選排序效果是 112 的。我在一個(gè)內(nèi)部項(xiàng)目里試過這種組合把候選文檔從二十份壓到五份問答準(zhǔn)確率和回答速度都得到了保證。這個(gè)方向我認(rèn)為值得大家在自己的應(yīng)用里探索并不復(fù)雜只是多了一層策略函數(shù)。6.3 后續(xù)想做的自動(dòng)標(biāo)簽推薦現(xiàn)在的 context-mode 最需要人工維護(hù)的部分是 manifest 配置也就是標(biāo)注入口。我在想兩個(gè)自動(dòng)化的方向基于 AST 解析的代碼依賴關(guān)系自動(dòng)生成模塊關(guān)鍵詞基于歷史任務(wù)會(huì)話的上下文選擇日志自動(dòng)學(xué)習(xí)哪些類型的文件經(jīng)常被同時(shí)選中進(jìn)而調(diào)整標(biāo)簽權(quán)重。這其實(shí)就帶點(diǎn)個(gè)性化了每條項(xiàng)目在實(shí)踐里形成的“上下文操作習(xí)慣”會(huì)被系統(tǒng)保存下來讓 context-mode 越來越貼合團(tuán)隊(duì)自己真實(shí)的開發(fā)套路。我準(zhǔn)備在下一個(gè)版本里加上這兩個(gè)功能試試水看看能不能把人工維護(hù)成本再降一個(gè)檔次。最后分享一個(gè)實(shí)際操作中的小經(jīng)驗(yàn)context-mode 這套東西剛落地時(shí)很長(zhǎng)一段時(shí)間只在你一個(gè)人手工調(diào)用時(shí)會(huì)配置得很準(zhǔn)因?yàn)槟銜?huì)下意識(shí)把該打的標(biāo)簽打上。但一旦團(tuán)隊(duì)其他人開始用你就得把“標(biāo)簽配置評(píng)審”當(dāng)成日常工作中一環(huán)每周過一遍近兩周的新增文件把沒打標(biāo)的補(bǔ)上。第一次漏配標(biāo)簽的教訓(xùn)可能是一小時(shí)的返工但定期維護(hù)配置的習(xí)慣能幫你省下的是所有人每周都會(huì)遇到的十幾分鐘低效拉扯。