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)目往往不是三言兩語(yǔ)就能說清的。一個(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í)庫(kù)”。首先記憶的生成并非被動(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)前的問題從記憶庫(kù)中檢索最相關(guān)的片段。這個(gè)過程可能涉及語(yǔ)義搜索即理解你問題的意圖然后匹配記憶中語(yǔ)義相近的內(nèi)容。比如你問“令牌”它能關(guān)聯(lián)到記憶中存儲(chǔ)的“JWT”。注意這里的“記憶”是Claude Code產(chǎn)品層面的功能實(shí)現(xiàn)其底層具體是調(diào)用了模型的哪些能力如長(zhǎng)上下文窗口、外部向量數(shù)據(jù)庫(kù)檢索等官方并未完全公開。我們討論的是其表現(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ì)用自然語(yǔ)言向Claude Code介紹項(xiàng)目“這是一個(gè)基于React 18和TypeScript的前端管理后臺(tái)項(xiàng)目狀態(tài)管理使用ZustandUI庫(kù)是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)更新太快?？梢試L試使用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)用戶列表頁(yè)面突然不顯示數(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)于“用戶列表頁(yè)面”開發(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ù)語(yǔ)可以在對(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ù)庫(kù)。” 清晰的糾正指令能有效更新其記憶庫(kù)中的信息。處理無關(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ù)庫(kù)設(shè)計(jì)再到API定義最后到前端組件實(shí)現(xiàn)經(jīng)歷了十幾輪高度抽象和細(xì)節(jié)交織的對(duì)話。當(dāng)你最后問一個(gè)關(guān)于最初數(shù)據(jù)庫(kù)設(shè)計(jì)的問題時(shí)AI可能無法完美地將最終前端的一個(gè)表現(xiàn)回溯到最初數(shù)據(jù)庫(kù)的一個(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)用可能需要同步檢查訂單模塊。”與文檔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è)的輪播圖怎么優(yōu)化”系統(tǒng)可能不會(huì)自動(dòng)將這兩個(gè)話題聯(lián)系起來。解決方案主動(dòng)建立連接在新問題中簡(jiǎn)要提及之前的上下文?！敖又覀儎偛庞懻摰腏WT認(rèn)證現(xiàn)在用戶登錄成功了我想在首頁(yè)顯示他的用戶名該從哪里獲取” 這樣能極大地幫助AI召回相關(guān)記憶。使用“引用”或“提及”功能如果Claude Code的界面支持如通過上傳文件或引用特定消息直接引用之前相關(guān)的對(duì)話記錄或代碼片段。分會(huì)話管理對(duì)于大型項(xiàng)目中完全獨(dú)立的模塊如前端UI組件和后端數(shù)據(jù)庫(kù)設(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)立刻用清晰、肯定的語(yǔ)氣糾正。“不對(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í)庫(kù)”。它的記憶能力將一次性的問答延伸成了持續(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)備。