1. 項(xiàng)目概述從“淺嘗”到“深挖”的探索最近在折騰AI編程助手時(shí)我花了些時(shí)間專門研究了一下Claude Code的“記憶系統(tǒng)”。這玩意兒聽起來挺玄乎但說白了就是AI在跟你一起寫代碼時(shí)能記住之前聊過的上下文、你提過的需求、甚至是你修改過的代碼片段從而在后續(xù)的對(duì)話中給出更連貫、更懂你的建議。這和我們平時(shí)用ChatGPT那種“一問一答答完就忘”的模式完全不同更像是一個(gè)有“長(zhǎng)期工作記憶”的編程伙伴。我之所以對(duì)這個(gè)功能感興趣是因?yàn)樵趯?shí)際的編碼工作中我們面對(duì)的項(xiàng)目往往不是三言兩語就能說清的。一個(gè)功能模塊的迭代、一個(gè)Bug的排查可能需要來回溝通十幾輪。如果每次都要把之前的對(duì)話歷史、代碼上下文重新貼一遍效率實(shí)在太低而且AI也容易“失憶”給出前后矛盾的方案。Claude Code的記憶系統(tǒng)理論上就是為了解決這個(gè)痛點(diǎn)而生的。它適合所有需要與AI進(jìn)行深度、持續(xù)協(xié)作的開發(fā)者無論是想提升日常編碼效率還是在探索復(fù)雜項(xiàng)目架構(gòu)時(shí)需要一個(gè)“不會(huì)忘事”的討論對(duì)象。2. 記憶系統(tǒng)的核心機(jī)制與工作原理拆解2.1 記憶的“存儲(chǔ)”與“索引”不只是聊天記錄剛開始接觸時(shí)我以為Claude Code的記憶就是把我們的對(duì)話歷史存起來下次對(duì)話時(shí)一股腦塞給模型。但實(shí)測(cè)和查閱相關(guān)資料后發(fā)現(xiàn)事情沒這么簡(jiǎn)單。它的記憶系統(tǒng)更像是一個(gè)經(jīng)過結(jié)構(gòu)化處理的“知識(shí)庫”。首先記憶的生成并非被動(dòng)記錄。Claude Code會(huì)主動(dòng)分析對(duì)話中的核心實(shí)體和概念。比如當(dāng)你提到“我們需要實(shí)現(xiàn)一個(gè)用戶認(rèn)證模塊使用JWT令牌有效期設(shè)為7天”系統(tǒng)不僅會(huì)記住這句話更可能提取出關(guān)鍵實(shí)體“用戶認(rèn)證模塊”、“JWT”、“7天”并理解它們之間的關(guān)系。這種結(jié)構(gòu)化的記憶方式比單純的文本堆砌要高效得多。其次記憶的“召回”依賴于智能檢索。當(dāng)你開啟一個(gè)新的對(duì)話并提到“之前說的那個(gè)令牌怎么弄來著”系統(tǒng)不會(huì)把整個(gè)歷史對(duì)話都作為上下文喂給模型那會(huì)嚴(yán)重消耗Token并可能降低回復(fù)質(zhì)量。相反它會(huì)根據(jù)你當(dāng)前的問題從記憶庫中檢索最相關(guān)的片段。這個(gè)過程可能涉及語義搜索即理解你問題的意圖然后匹配記憶中語義相近的內(nèi)容。比如你問“令牌”它能關(guān)聯(lián)到記憶中存儲(chǔ)的“JWT”。注意這里的“記憶”是Claude Code產(chǎn)品層面的功能實(shí)現(xiàn)其底層具體是調(diào)用了模型的哪些能力如長(zhǎng)上下文窗口、外部向量數(shù)據(jù)庫檢索等官方并未完全公開。我們討論的是其表現(xiàn)出的行為和效果。2.2 記憶的“保鮮期”與“容量”并非無限永存這是很多開發(fā)者關(guān)心的問題Claude Code能記住多久以前的事情能記住多少東西根據(jù)我的使用經(jīng)驗(yàn)和社區(qū)討論記憶系統(tǒng)有幾個(gè)特點(diǎn)會(huì)話內(nèi)記憶強(qiáng)跨會(huì)話記憶有條件在同一個(gè)“會(huì)話”Session或“項(xiàng)目”上下文中Claude Code的記憶能力非常連貫。你可以就同一個(gè)文件修改幾十次它都能清晰地追蹤變化。但如果你關(guān)閉了對(duì)話窗口或開始了全新的會(huì)話之前的記憶是否還能被喚起取決于平臺(tái)如何設(shè)計(jì)“項(xiàng)目”或“工作區(qū)”級(jí)別的記憶持久化。目前看來在同一個(gè)項(xiàng)目空間內(nèi)跨對(duì)話的記憶召回是可行的但可能需要你明確提及或觸發(fā)相關(guān)關(guān)鍵詞。記憶有優(yōu)先級(jí)和衰減機(jī)制系統(tǒng)不可能無限制地記住所有細(xì)節(jié)。它更傾向于記住那些被反復(fù)提及、修改或者你明確表示重要的內(nèi)容比如你說“記住這個(gè)API密鑰格式”。一些邊緣的、一次性的對(duì)話細(xì)節(jié)可能會(huì)被逐漸“淡忘”或置于檢索優(yōu)先級(jí)較低的位置。容量受模型上下文窗口限制無論記憶系統(tǒng)多么智能最終在生成回復(fù)時(shí)相關(guān)的記憶片段需要被放入模型的上下文窗口。Claude 3系列模型雖然有巨大的上下文窗口如200K但實(shí)際用于“記憶檢索結(jié)果”的空間也是有限的。這意味著在極其龐大和復(fù)雜的項(xiàng)目里它可能無法一次性關(guān)聯(lián)所有歷史記憶而是選擇最相關(guān)的部分。理解這些機(jī)制有助于我們更好地“使用”而非“對(duì)抗”這個(gè)系統(tǒng)。比如對(duì)于非常重要的架構(gòu)決策可以在對(duì)話中明確總結(jié)并讓AI確認(rèn)“好的所以我們確定采用微服務(wù)架構(gòu)服務(wù)間通過gRPC通信對(duì)嗎” 這樣能強(qiáng)化相關(guān)記憶的權(quán)重。3. 實(shí)操如何有效“訓(xùn)練”與利用Claude Code的記憶3.1 項(xiàng)目初始化為記憶系統(tǒng)打下好基礎(chǔ)很多人打開Claude Code就直接開始問問題這其實(shí)浪費(fèi)了記憶系統(tǒng)的潛力。更好的做法是在項(xiàng)目開始時(shí)進(jìn)行一次“初始化對(duì)話”。這相當(dāng)于給你的AI伙伴做一次項(xiàng)目簡(jiǎn)報(bào)。我會(huì)怎么做呢首先我會(huì)上傳或粘貼項(xiàng)目的核心文件比如package.json、README.md、主要的配置文件或架構(gòu)概覽圖。然后我會(huì)用自然語言向Claude Code介紹項(xiàng)目“這是一個(gè)基于React 18和TypeScript的前端管理后臺(tái)項(xiàng)目狀態(tài)管理使用ZustandUI庫是Ant Design。我們目前正在開發(fā)用戶管理模塊需要實(shí)現(xiàn)增刪改查和角色分配功能。項(xiàng)目的代碼規(guī)范是ESLint Prettier提交信息遵循Conventional Commits。”這樣的介紹一次性注入了大量關(guān)鍵信息技術(shù)棧、當(dāng)前任務(wù)、開發(fā)規(guī)范。Claude Code的記憶系統(tǒng)會(huì)將這些信息作為項(xiàng)目的“背景知識(shí)”存儲(chǔ)起來。在后續(xù)所有關(guān)于這個(gè)項(xiàng)目的對(duì)話中它都會(huì)默認(rèn)在這個(gè)背景下思考。你再問“怎么實(shí)現(xiàn)一個(gè)表格組件”時(shí)它就不會(huì)給你Vue或者純JavaScript的方案而是直接基于React TypeScript Ant Design來給出建議。3.2 迭代式開發(fā)讓記憶成為“第二大腦”在具體的功能開發(fā)中記憶系統(tǒng)的威力才真正顯現(xiàn)。假設(shè)我們?cè)趯?shí)現(xiàn)一個(gè)“上傳文件并顯示進(jìn)度”的功能。第一輪對(duì)話你問“如何在React中用axios實(shí)現(xiàn)文件上傳并顯示進(jìn)度條” Claude Code給出了基礎(chǔ)代碼包含了一個(gè)帶有onUploadProgress回調(diào)的axios配置。第二輪對(duì)話你修改了代碼將上傳邏輯封裝成了一個(gè)自定義HookuseFileUpload并發(fā)現(xiàn)進(jìn)度條在快速上傳時(shí)動(dòng)畫不流暢。你問“我封裝了Hook但進(jìn)度條動(dòng)畫卡頓有什么優(yōu)化建議” 此時(shí)Claude Code已經(jīng)“記住”了你剛才在討論文件上傳并且看到了你新寫的useFileUploadHook代碼。它給出的建議會(huì)非常具體可能會(huì)提到“在你的Hook里onUploadProgress事件觸發(fā)非常頻繁導(dǎo)致React狀態(tài)更新太快。可以嘗試使用setTimeout或requestAnimationFrame來節(jié)流進(jìn)度狀態(tài)的更新或者考慮使用Web Worker來處理進(jìn)度計(jì)算?！钡谌唽?duì)話你想增加一個(gè)功能上傳前校驗(yàn)文件類型和大小。你問“怎么在上傳前校驗(yàn)文件類型和大小” 這時(shí)Claude Code不會(huì)從頭開始講如何用File對(duì)象獲取type和size屬性因?yàn)樗坝浀谩蹦阏谕晟颇莻€(gè)useFileUploadHook。它很可能會(huì)直接給出修改建議“在你的Hook的入口函數(shù)里在調(diào)用axios之前先對(duì)傳入的file對(duì)象進(jìn)行判斷if (![image/png, image/jpeg].includes(file.type)) { throw new Error(文件類型不支持) } 并且if (file.size 10 * 1024 * 1024) { throw new Error(文件大小不能超過10MB) }。”你看整個(gè)對(duì)話過程是連貫的、迭代的。你不需要每次都重復(fù)“我在做一個(gè)React項(xiàng)目正在寫文件上傳”。記憶系統(tǒng)讓Claude Code像一個(gè)真正的結(jié)對(duì)編程伙伴始終記得你們正在做什么做到了哪一步遇到了什么問題。3.3 調(diào)試與排錯(cuò)記憶讓問題定位更精準(zhǔn)調(diào)試是記憶系統(tǒng)另一個(gè)高光場(chǎng)景。當(dāng)你遇到一個(gè)Bug時(shí)排查過程往往是線性的提出假設(shè) - 查看日志/代碼 - 驗(yàn)證 - 修正。比如你發(fā)現(xiàn)用戶列表頁面突然不顯示數(shù)據(jù)了。你可能會(huì)把錯(cuò)誤信息貼給Claude Code“控制臺(tái)報(bào)錯(cuò)Cannot read properties of undefined (reading map)。”如果這是一個(gè)全新的對(duì)話AI可能會(huì)給出一個(gè)泛泛的列表檢查數(shù)據(jù)是否成功返回、檢查變量名是否正確、檢查組件渲染時(shí)機(jī)等等。但如果是在一個(gè)已經(jīng)進(jìn)行了多次關(guān)于“用戶列表頁面”開發(fā)的會(huì)話中Claude Code的記憶系統(tǒng)會(huì)立刻關(guān)聯(lián)上下文。它可能“記得”你之前寫過一個(gè)從/api/users獲取數(shù)據(jù)的函數(shù)。你剛剛修改了后端API的響應(yīng)格式。你不久前在父組件里調(diào)整過狀態(tài)傳遞的邏輯?；谶@些記憶它的回答會(huì)精準(zhǔn)得多“看起來是userList變量為undefined了。你剛剛修改了fetchUsers函數(shù)將返回的數(shù)據(jù)結(jié)構(gòu)從{ data: [...] }改成了{(lán) users: [...] }。請(qǐng)檢查調(diào)用fetchUsers的地方是否正確地解構(gòu)了users字段而不是原來的data字段。”這種精準(zhǔn)定位極大地縮短了調(diào)試時(shí)間。它不僅僅是看到了當(dāng)前的錯(cuò)誤更是結(jié)合了“歷史變更”這個(gè)關(guān)鍵上下文直接指出了最可能的原因——就是你最近的一次改動(dòng)。4. 高級(jí)技巧與邊界探索4.1 主動(dòng)管理記憶強(qiáng)化、修正與清除記憶系統(tǒng)雖然智能但并非完美。有時(shí)它可能記住了錯(cuò)誤的信息或者關(guān)聯(lián)了不相關(guān)的上下文。我們需要學(xué)會(huì)主動(dòng)管理它。強(qiáng)化關(guān)鍵記憶對(duì)于重要的約定如項(xiàng)目命名規(guī)范、特定的API路徑、團(tuán)隊(duì)內(nèi)部術(shù)語可以在對(duì)話中明確強(qiáng)調(diào)?！拔覀兗s定所有API請(qǐng)求的基地址都從環(huán)境變量VITE_API_BASE讀取請(qǐng)記住這一點(diǎn)?！?甚至可以讓AI復(fù)述一遍來確認(rèn)。修正錯(cuò)誤記憶如果你發(fā)現(xiàn)AI基于一個(gè)錯(cuò)誤的前提給出建議直接指出并糾正?！安粚?duì)我之前說用MySQL但我們后來決定改用PostgreSQL了。請(qǐng)更新你的記憶這個(gè)項(xiàng)目使用PostgreSQL數(shù)據(jù)庫。” 清晰的糾正指令能有效更新其記憶庫中的信息。處理無關(guān)記憶干擾在開啟一個(gè)全新但無關(guān)的話題時(shí)如果感覺AI的回答受到了之前項(xiàng)目記憶的干擾最直接的方法是開啟一個(gè)新的、獨(dú)立的“會(huì)話”或“聊天窗口”。這是物理上的記憶隔離最干凈徹底。4.2 記憶的邊界與局限性認(rèn)知經(jīng)過一段時(shí)間的深度使用我也摸清了這套系統(tǒng)的一些邊界和局限清楚這些能避免不切實(shí)際的期望。代碼變更的“理解”深度有限Claude Code能“看到”你修改了代碼但它對(duì)修改意圖的深層理解可能不如人類開發(fā)者。比如你將一個(gè)函數(shù)從A類重構(gòu)到了B類它知道代碼變了也能在后續(xù)對(duì)話中引用新的位置。但如果你問“我為什么要把這個(gè)函數(shù)移出來”它可能無法準(zhǔn)確復(fù)現(xiàn)你當(dāng)時(shí)重構(gòu)的架構(gòu)思考比如為了遵循單一職責(zé)原則除非你在當(dāng)時(shí)的對(duì)話中明確解釋過。長(zhǎng)鏈邏輯推理的挑戰(zhàn)對(duì)于需要跨越非常多步驟的復(fù)雜邏輯推理記憶系統(tǒng)可能會(huì)力不從心。例如你從需求分析開始到數(shù)據(jù)庫設(shè)計(jì)再到API定義最后到前端組件實(shí)現(xiàn)經(jīng)歷了十幾輪高度抽象和細(xì)節(jié)交織的對(duì)話。當(dāng)你最后問一個(gè)關(guān)于最初數(shù)據(jù)庫設(shè)計(jì)的問題時(shí)AI可能無法完美地將最終前端的一個(gè)表現(xiàn)回溯到最初數(shù)據(jù)庫的一個(gè)字段定義上因?yàn)橹虚g的推理鏈太長(zhǎng)記憶檢索可能丟失某些關(guān)鍵環(huán)節(jié)?！半[性知識(shí)”難以記憶那些你沒有說出來的、基于經(jīng)驗(yàn)的“常識(shí)”或“默契”AI是無法記憶的。比如你的團(tuán)隊(duì)習(xí)慣用_前綴表示私有方法但你沒告訴過AI。它看到代碼里有_internalProcess()可能不會(huì)自動(dòng)理解這是私有方法除非你明確告知。4.3 與其他工具結(jié)合的增效模式Claude Code的記憶系統(tǒng)不是孤島結(jié)合其他工具能產(chǎn)生奇效。與版本控制Git結(jié)合在討論一個(gè)復(fù)雜的Bug時(shí)你可以將git diff的輸出粘貼給Claude Code。它不僅能分析當(dāng)前的代碼差異還能結(jié)合記憶中的項(xiàng)目背景給出更準(zhǔn)確的回歸影響分析。例如“這次提交修改了用戶驗(yàn)證的邏輯根據(jù)我們之前的對(duì)話這個(gè)邏輯在訂單創(chuàng)建流程中也被調(diào)用可能需要同步檢查訂單模塊?！迸c文檔README、注釋結(jié)合養(yǎng)成將重要的討論結(jié)論沉淀到項(xiàng)目文檔或代碼注釋中的習(xí)慣。你可以對(duì)AI說“把我們剛才決定的API設(shè)計(jì)規(guī)范總結(jié)一下生成一段Markdown格式的文字我放到項(xiàng)目的API_GUIDELINE.md文件里?！?這樣記憶不僅存在于AI的上下文中也固化到了項(xiàng)目資產(chǎn)里方便所有團(tuán)隊(duì)成員包括未來的AI會(huì)話查閱。與命令行操作結(jié)合當(dāng)你讓Claude Code幫你編寫一個(gè)復(fù)雜的Shell腳本或Dockerfile時(shí)它的記憶能確保腳本中的路徑、環(huán)境變量名與你的項(xiàng)目結(jié)構(gòu)保持一致。比如它“記得”你的前端靜態(tài)資源構(gòu)建后放在dist/目錄那么它在編寫Nginx配置時(shí)就會(huì)正確地設(shè)置root /app/dist;。5. 常見問題與實(shí)戰(zhàn)排坑記錄在實(shí)際使用中我遇到了一些典型問題也總結(jié)了一些應(yīng)對(duì)策略。5.1 問題一AI似乎“失憶”了不記得剛才討論的內(nèi)容現(xiàn)象在同一個(gè)會(huì)話中你剛剛詳細(xì)討論了一個(gè)函數(shù)實(shí)現(xiàn)幾分鐘后問一個(gè)相關(guān)的問題AI的回答卻像是第一次聽到這個(gè)概念?？赡茉蚺c排查上下文長(zhǎng)度超限這是最常見的原因。雖然Claude支持長(zhǎng)上下文但單次交互的“工作記憶”仍有其限制。如果你在兩次提問之間進(jìn)行了大量其他無關(guān)的對(duì)話或粘貼了很長(zhǎng)的文本可能將之前關(guān)于目標(biāo)函數(shù)的討論擠出了最近的上下文窗口。話題切換過于突兀如果你的新問題與之前的話題在表面用詞上關(guān)聯(lián)度很低AI的記憶檢索系統(tǒng)可能沒有成功匹配。比如之前討論“用戶登錄的JWT實(shí)現(xiàn)”接著突然問“首頁的輪播圖怎么優(yōu)化”系統(tǒng)可能不會(huì)自動(dòng)將這兩個(gè)話題聯(lián)系起來。解決方案主動(dòng)建立連接在新問題中簡(jiǎn)要提及之前的上下文?！敖又覀儎偛庞懻摰腏WT認(rèn)證現(xiàn)在用戶登錄成功了我想在首頁顯示他的用戶名該從哪里獲取” 這樣能極大地幫助AI召回相關(guān)記憶。使用“引用”或“提及”功能如果Claude Code的界面支持如通過上傳文件或引用特定消息直接引用之前相關(guān)的對(duì)話記錄或代碼片段。分會(huì)話管理對(duì)于大型項(xiàng)目中完全獨(dú)立的模塊如前端UI組件和后端數(shù)據(jù)庫設(shè)計(jì)可以分別開啟不同的會(huì)話避免記憶互相干擾。5.2 問題二記憶產(chǎn)生了“幻覺”或錯(cuò)誤關(guān)聯(lián)現(xiàn)象AI confidently地引用了一個(gè)你從未說過或已經(jīng)糾正過的“事實(shí)”。可能原因這通常發(fā)生在項(xiàng)目信息復(fù)雜或存在多處相似概念時(shí)。AI的記憶檢索可能發(fā)生了“誤匹配”將另一個(gè)相似話題中的信息關(guān)聯(lián)到了當(dāng)前問題。例如項(xiàng)目里既有“用戶訂單”模塊也有“管理員訂單”模塊它們都有status字段。當(dāng)你在討論用戶訂單狀態(tài)流轉(zhuǎn)時(shí)AI可能錯(cuò)誤地引用了管理員訂單的狀態(tài)枚舉值。解決方案立即澄清一旦發(fā)現(xiàn)立刻用清晰、肯定的語氣糾正?！安粚?duì)用戶訂單的狀態(tài)沒有‘審核中’這個(gè)值只有‘待支付’ ‘已支付’ ‘已完成’ ‘已取消’。請(qǐng)更新你的記憶?！碧峁?quán)威來源將正確的代碼片段、配置文件或文檔截圖再次提供給AI強(qiáng)化正確信息的權(quán)重?！澳憧催@是UserOrderStatus枚舉的定義只有這四種?！焙?jiǎn)化提問對(duì)于容易混淆的概念在提問時(shí)使用更完整、限定更明確的名稱。例如直接問“UserOrder模型的status字段如何更新”而不是泛泛地問“訂單狀態(tài)怎么改”。5.3 問題三如何衡量記憶系統(tǒng)帶來的效率提升這是一個(gè)很實(shí)際的問題。我的體會(huì)是不要期望它在簡(jiǎn)單、一次性的代碼片段生成上有巨大提升。它的價(jià)值在于中、長(zhǎng)周期的復(fù)雜任務(wù)協(xié)作。效率提升感知明顯的場(chǎng)景功能迭代開發(fā)從一個(gè)功能的雛形討論到具體實(shí)現(xiàn)再到多次優(yōu)化和Bug修復(fù)整個(gè)周期內(nèi)溝通成本顯著降低。技術(shù)方案討論對(duì)比A方案和B方案時(shí)你可以不斷追問細(xì)節(jié)AI能基于之前討論過的A方案的優(yōu)缺點(diǎn)來對(duì)比B方案而不用你反復(fù)復(fù)述。新人接手項(xiàng)目你可以讓AI基于項(xiàng)目記憶快速為新人生成一份針對(duì)性的項(xiàng)目導(dǎo)讀或常見問題解答這比從零開始寫文檔快得多。一個(gè)簡(jiǎn)單的衡量方法是記錄你在完成一個(gè)復(fù)雜功能時(shí)復(fù)制粘貼歷史對(duì)話內(nèi)容、重復(fù)解釋同一概念的次數(shù)。在使用記憶系統(tǒng)后這個(gè)次數(shù)應(yīng)該會(huì)大幅減少甚至降為零。那種“它居然還記得我三天前說的那句話”的驚喜時(shí)刻就是效率提升最直接的證明。6. 個(gè)人使用體會(huì)與未來展望深度使用Claude Code的記憶系統(tǒng)后我的工作流發(fā)生了微妙但深刻的變化。我不再把它僅僅視為一個(gè)“更聰明的代碼補(bǔ)全工具”而更像是一個(gè)“可交互的、動(dòng)態(tài)的項(xiàng)目知識(shí)庫”。它的記憶能力將一次性的問答延伸成了持續(xù)性的對(duì)話和協(xié)作。最大的體會(huì)是與AI協(xié)作的方式需要轉(zhuǎn)變。從“榨取單次回答的最優(yōu)解”轉(zhuǎn)變?yōu)椤肮餐S護(hù)和增長(zhǎng)一個(gè)項(xiàng)目的上下文”。這意味著我們需要更有意識(shí)地去“塑造”AI的記憶清晰地定義概念、及時(shí)地糾正錯(cuò)誤、結(jié)構(gòu)化地傳遞信息。這個(gè)過程反過來也促使我自己更清晰地思考和組織項(xiàng)目信息。目前這套系統(tǒng)還存在依賴平臺(tái)、記憶邊界模糊等限制。我期待未來能看到更開放的“記憶”管理功能比如允許用戶手動(dòng)查看、編輯、導(dǎo)出AI為某個(gè)項(xiàng)目生成的記憶摘要或者記憶能力能夠更深地與本地開發(fā)環(huán)境如VS Code插件集成直接關(guān)聯(lián)到本地的Git提交歷史、文件變更記錄。無論如何“淺嘗”之后我認(rèn)為AI編程助手擁有持久化、智能化的記憶能力是一個(gè)不可逆的趨勢(shì)。它解決的正是人機(jī)協(xié)作中最令人頭疼的“上下文斷層”問題。雖然現(xiàn)在還不夠完美但已經(jīng)足夠讓我們以一種全新的、更連貫的方式與機(jī)器共同思考和構(gòu)建。對(duì)于開發(fā)者而言盡早適應(yīng)并善用這種能力無疑是在為未來更高階的人機(jī)協(xié)同編程做準(zhǔn)備。