1. 從廚房到代碼為什么“備料”是智能體編程的第一性原理如果你在廚房里待過(guò)或者看過(guò)任何一檔像樣的烹飪節(jié)目一定會(huì)對(duì)一個(gè)詞印象深刻Mise en Place。這是一個(gè)法語(yǔ)詞直譯過(guò)來(lái)是“各就各位”在烹飪界它指的是一種工作哲學(xué)——在真正開火烹飪之前把所有食材洗凈、切配、稱量好分門別類地放在小碗里工具也擺放就緒。廚師只需專注于烹飪本身而無(wú)需在油鍋冒煙時(shí)手忙腳亂地去找一顆蒜。聽起來(lái)很基礎(chǔ)對(duì)吧但正是這個(gè)基礎(chǔ)區(qū)分了專業(yè)廚房的井然有序和家庭廚房的兵荒馬亂?，F(xiàn)在讓我們把這個(gè)概念平移到另一個(gè)看似毫不相干的領(lǐng)域智能體編程。當(dāng)我們?cè)谡務(wù)撟孉I智能體去編寫、調(diào)試、重構(gòu)代碼時(shí)我們是否也陷入了“油鍋冒煙才找蒜”的混亂答案是絕大多數(shù)時(shí)候是的。“Mise en Place for Agentic Coding”這個(gè)標(biāo)題正是將這種廚房里的“備料”哲學(xué)提煉為一種嚴(yán)謹(jǐn)?shù)纳舷挛墓こ谭椒ㄕ?。它不是在講某個(gè)具體的AI模型或代碼生成工具而是在講一個(gè)更底層、更決定成敗的環(huán)節(jié)我們?nèi)绾螢橹悄荏w準(zhǔn)備“上下文”這就像是為一位頂級(jí)廚師準(zhǔn)備一個(gè)完美的備料臺(tái)。你給智能體的上下文就是它的“工作臺(tái)”。臺(tái)面是雜亂無(wú)章、堆滿未處理的原始食材還是井井有條、分門別類、隨時(shí)可取的半成品將直接決定它產(chǎn)出的“菜肴”即代碼的質(zhì)量、效率和可靠性。這篇文章就是寫給那些已經(jīng)嘗過(guò)AI編碼甜頭但也飽受其“幻覺(jué)”、上下文溢出、指令漂移之苦的開發(fā)者、技術(shù)負(fù)責(zé)人和AI應(yīng)用架構(gòu)師的。我們將深入拆解為什么“有意識(shí)的準(zhǔn)備”不是可選項(xiàng)而是智能體編碼時(shí)代的必選項(xiàng)。我會(huì)結(jié)合大量一線實(shí)戰(zhàn)中的踩坑經(jīng)驗(yàn)告訴你如何系統(tǒng)性地構(gòu)建你的“智能體備料臺(tái)”把看似玄學(xué)的“提示工程”變成一套可重復(fù)、可評(píng)估、可優(yōu)化的工程化流程。2. 智能體編碼的“油鍋困境”為什么上下文準(zhǔn)備如此關(guān)鍵在深入方法論之前我們必須先理解我們面臨的核心挑戰(zhàn)。直接給智能體比如ChatGPT、Claude、Cursor等丟一個(gè)模糊的需求然后指望它吐出完美的代碼這就像讓一位廚師在堆滿帶泥土豆和整只雞的臺(tái)面上30分鐘內(nèi)做出一道法式燉雞——結(jié)果要么是災(zāi)難要么廚師智能體會(huì)用自己的“想象力”幻覺(jué)來(lái)填補(bǔ)空白比如用番茄醬代替紅酒因?yàn)槟銢](méi)告訴它需要紅酒而它“覺(jué)得”番茄醬可能也行。2.1 智能體的“工作記憶”局限性當(dāng)前的AI編碼智能體無(wú)論其底層模型多么強(qiáng)大都有一個(gè)無(wú)法回避的物理限制上下文窗口。你可以把它想象成廚師工作臺(tái)的面積。面積再大也是有限的。當(dāng)你在對(duì)話中不斷追加需求、發(fā)送文件、進(jìn)行調(diào)試時(shí)這個(gè)“臺(tái)面”很快就會(huì)被占滿。更糟糕的是模型對(duì)于長(zhǎng)上下文中不同位置信息的“注意力”是不均勻的。早期的、中間的關(guān)鍵信息可能會(huì)被“遺忘”或稀釋。注意這里說(shuō)的“遺忘”不是真的丟失而是指在模型生成下一個(gè)詞時(shí)那些信息對(duì)決策的影響權(quán)重降低了。這會(huì)導(dǎo)致智能體前后行為不一致即“指令漂移”。我曾在一個(gè)微服務(wù)重構(gòu)項(xiàng)目中讓智能體基于一個(gè)復(fù)雜的領(lǐng)域模型接口生成實(shí)現(xiàn)類。一開始我提供了清晰的接口定義和業(yè)務(wù)規(guī)則。但在十幾輪來(lái)回調(diào)試和優(yōu)化后智能體突然開始生成與最初業(yè)務(wù)規(guī)則相悖的代碼。回溯上下文發(fā)現(xiàn)最初的規(guī)則描述已經(jīng)被淹沒(méi)在大量調(diào)試日志和代碼片段中智能體的“注意力”已經(jīng)完全被最近的錯(cuò)誤信息所吸引。2.2 “垃圾進(jìn)垃圾出”的放大效應(yīng)在傳統(tǒng)編程中一個(gè)模糊的需求可能導(dǎo)致開發(fā)者產(chǎn)出有偏差的代碼但開發(fā)者的人類常識(shí)和經(jīng)驗(yàn)會(huì)起到一定的糾偏作用。然而智能體極度依賴你輸入的上下文質(zhì)量。你給的上下文如果模糊、矛盾、信息不全“垃圾進(jìn)”那么智能體不僅會(huì)產(chǎn)出有問(wèn)題的代碼“垃圾出”還會(huì)以一種極其自信且邏輯自洽的方式呈現(xiàn)出來(lái)極具迷惑性。例如你只說(shuō)“寫一個(gè)用戶登錄函數(shù)。” 智能體可能會(huì)生成一個(gè)僅驗(yàn)證用戶名密碼的簡(jiǎn)單函數(shù)。但你的真實(shí)上下文可能包括需要集成OAuth 2.0、需要記錄安全日志、需要防范暴力破解、需要返回特定的JWT令牌結(jié)構(gòu)……這些缺失的“食材”智能體不會(huì)主動(dòng)去“市場(chǎng)”采購(gòu)它只會(huì)用臺(tái)面上現(xiàn)有的東西一個(gè)模糊的“登錄”概念來(lái)湊合。2.3 調(diào)試成本的非線性增長(zhǎng)當(dāng)智能體產(chǎn)出的代碼基于一個(gè)糟糕的上下文時(shí)調(diào)試會(huì)變得異常痛苦。因?yàn)槟悴粌H要調(diào)試代碼本身的語(yǔ)法或邏輯錯(cuò)誤更要先逆向工程出“智能體當(dāng)時(shí)到底理解了什么”。這相當(dāng)于你要先猜出廚師腦子里那個(gè)殘缺的菜譜才能知道為什么他往燉雞里加了草莓。這種雙重調(diào)試的認(rèn)知負(fù)荷常常比從頭自己寫代碼還要高。因此“Mise en Place”的核心價(jià)值就在于通過(guò)前置的、系統(tǒng)性的上下文準(zhǔn)備將智能體的“工作記憶”從存儲(chǔ)和回憶原始、雜亂信息的負(fù)擔(dān)中解放出來(lái)讓它100%的“算力”都聚焦于“烹飪”即代碼的推理、生成和組裝這一核心創(chuàng)造性任務(wù)上。這本質(zhì)上是一種認(rèn)知卸載將人類擅長(zhǎng)的規(guī)劃、結(jié)構(gòu)化、明確化工作與AI擅長(zhǎng)的模式匹配、代碼生成工作進(jìn)行最優(yōu)分工。3. 構(gòu)建你的“智能體備料臺(tái)”上下文工程的四大核心食材理解了“為什么”我們來(lái)看“怎么做”。一個(gè)專業(yè)的“智能體備料臺(tái)”應(yīng)該準(zhǔn)備哪些“食材”我將其歸納為四大類它們共同構(gòu)成了高質(zhì)量上下文的基石。3.1 食材一清晰明確的任務(wù)規(guī)格說(shuō)明書這是你的“主菜食譜”。它必須超越自然語(yǔ)言的模糊描述達(dá)到接近“機(jī)器可讀”的精確度。輸入/輸出契約像寫API文檔一樣明確。函數(shù)/模塊的輸入?yún)?shù)名稱、類型、約束、示例、返回值類型、結(jié)構(gòu)、可能的狀態(tài)。例如不只是“處理用戶數(shù)據(jù)”而是“輸入U(xiǎn)serRegistrationForm對(duì)象包含email, password, name字段其中email需符合RFC 5322標(biāo)準(zhǔn)輸出ApiResponse對(duì)象成功時(shí)包含userId和jwtToken失敗時(shí)包含errorCode和message。”驗(yàn)收條件與邊界案例明確告訴智能體什么是“完成”。包括正常流主流程的成功場(chǎng)景。異常流各種錯(cuò)誤處理網(wǎng)絡(luò)超時(shí)、數(shù)據(jù)庫(kù)連接失敗、輸入驗(yàn)證失敗、權(quán)限不足等。邊界案例空輸入、極大/極小值、并發(fā)情況、數(shù)據(jù)一致性要求。非功能性需求性能指標(biāo)如響應(yīng)時(shí)間100ms、安全性要求如密碼必須加鹽哈希。“不要做什么”的負(fù)面清單這往往比“要做什么”更重要。明確禁止的模式、已棄用的庫(kù)、特定的實(shí)現(xiàn)方式如“禁止使用eval()”“避免全局變量”“不要直接拼接SQL語(yǔ)句”。實(shí)操心得我習(xí)慣用一個(gè)結(jié)構(gòu)化的注釋塊來(lái)承載這些信息直接作為給智能體的初始提示的一部分。這比在對(duì)話中零散描述要有效得多。## 任務(wù)創(chuàng)建用戶積分扣除服務(wù)函數(shù) **函數(shù)簽名**: deductUserPoints(userId: string, points: number, reason: string): PromiseDeductionResult **輸入**: - userId: 用戶ID必須是存在的、狀態(tài)為激活的用戶。 - points: 扣除積分?jǐn)?shù)必須為正整數(shù)且不大于用戶當(dāng)前可用積分。 - reason: 扣除原因枚舉值[PURCHASE, REFUND, ADMIN_ADJUSTMENT, PENALTY]。 **輸出**: - success: boolean。 - remainingPoints: number扣除后的積分余額。 - transactionId: string本次積分變動(dòng)的唯一事務(wù)ID。 - error: string | null失敗時(shí)的錯(cuò)誤信息。 **業(yè)務(wù)規(guī)則**: 1. 必須是原子操作查詢當(dāng)前積分和扣除操作必須在同一個(gè)數(shù)據(jù)庫(kù)事務(wù)中。 2. 需要記錄完整的積分流水points_ledger表包含操作前余額、變動(dòng)值、操作后余額、原因、時(shí)間戳。 3. 如果userId不存在或用戶狀態(tài)非激活立即失敗錯(cuò)誤碼USER_INVALID。 4. 如果points超過(guò)可用積分立即失敗錯(cuò)誤碼INSUFFICIENT_POINTS。 **禁止**: - 直接使用UPDATE ... SET points points - ?而不做前置查詢校驗(yàn)。 - 在函數(shù)內(nèi)進(jìn)行任何形式的HTTP調(diào)用或IO阻塞操作日志除外。3.2 食材二精選的代碼范例與風(fēng)格指南這是你的“調(diào)味料和經(jīng)典菜式樣本”。智能體通過(guò)示例學(xué)習(xí)的速度和效果遠(yuǎn)超純文本描述。架構(gòu)與模式范例提供1-2個(gè)項(xiàng)目中類似模塊的完整、簡(jiǎn)潔的代碼文件。例如如果要生成一個(gè)GraphQL Resolver就提供一個(gè)現(xiàn)有的、設(shè)計(jì)良好的Resolver文件。這能傳遞項(xiàng)目整體的架構(gòu)風(fēng)格、分層邏輯、依賴注入方式等隱性知識(shí)。代碼風(fēng)格片段不是給一個(gè)通用的ESLint配置鏈接而是提供具體的代碼片段對(duì)比。好的例子// 使用具名導(dǎo)出而非默認(rèn)導(dǎo)出// 錯(cuò)誤處理使用Result模式而非try-catch遍地開花。壞的例子// 避免嵌套超過(guò)三層的回調(diào)函數(shù)。領(lǐng)域特定語(yǔ)言如果你的項(xiàng)目有自己的一些術(shù)語(yǔ)、工具函數(shù)或設(shè)計(jì)模式提供它們的定義和用法。例如“我們使用Injectable()裝飾器來(lái)自動(dòng)處理依賴”“查詢數(shù)據(jù)庫(kù)統(tǒng)一使用queryBuilder()工具函數(shù)它內(nèi)置了連接池管理和超時(shí)重試”。踩坑經(jīng)驗(yàn)最初我只給智能體看“好”的代碼后來(lái)發(fā)現(xiàn)它有時(shí)會(huì)模仿一些過(guò)時(shí)的模式?，F(xiàn)在我會(huì)有意準(zhǔn)備一個(gè)“模式進(jìn)化說(shuō)明”例如“本項(xiàng)目早期使用X模式處理錯(cuò)誤但現(xiàn)在已全面遷移到Y(jié)模式。請(qǐng)參考service/authV2.ts而非service/auth.ts?！?.3 食材三精確的依賴與環(huán)境上下文這是你的“廚具和灶臺(tái)狀態(tài)”。智能體需要知道在哪個(gè)“廚房”里工作。技術(shù)棧清單精確到主版本號(hào)。Node.js 18 LTS,TypeScript 5.0,React 18,Prisma ORM 4.0。避免只說(shuō)“用最新的”。關(guān)鍵依賴的API風(fēng)格如果你用了某個(gè)特定的庫(kù)說(shuō)明你期望的用法。例如“我們使用axios進(jìn)行HTTP請(qǐng)求并且已經(jīng)配置了全局的請(qǐng)求攔截器添加JWT令牌所以直接使用axios.get(/api/endpoint)即可無(wú)需手動(dòng)處理認(rèn)證頭?！表?xiàng)目結(jié)構(gòu)導(dǎo)航用簡(jiǎn)短文字描述關(guān)鍵目錄的作用。/src/models/存放Prisma生成的數(shù)據(jù)庫(kù)模型和自定義的領(lǐng)域模型/src/services/存放核心業(yè)務(wù)邏輯每個(gè)文件對(duì)應(yīng)一個(gè)領(lǐng)域服務(wù)/src/api/routes/存放Express路由定義它們只負(fù)責(zé)接收請(qǐng)求和返回響應(yīng)邏輯委托給service層。運(yùn)行時(shí)約束代碼將運(yùn)行在什么環(huán)境服務(wù)器less函數(shù)有冷啟動(dòng)時(shí)間限制Docker容器特定的Linux環(huán)境特定的云平臺(tái)如AWS Lambda需要處理特定的環(huán)境變量3.4 食材四動(dòng)態(tài)的會(huì)話狀態(tài)與思維鏈錨點(diǎn)這是你在烹飪過(guò)程中的“火候控制和嘗味記錄”。對(duì)于復(fù)雜的、多輪的任務(wù)你需要管理對(duì)話本身。思維鏈顯式化要求智能體在給出最終代碼前先輸出其思考過(guò)程。例如“請(qǐng)先分析需求列出實(shí)現(xiàn)步驟和可能遇到的坑然后再生成代碼?！?這讓你能中途糾正它的思路偏差而不是等到代碼生成后才發(fā)現(xiàn)問(wèn)題。關(guān)鍵決策記錄在多輪對(duì)話中當(dāng)你們共同做出一個(gè)重要技術(shù)決策時(shí)比如“決定采用策略模式來(lái)解耦不同的支付方式”用一句總結(jié)的話記錄下來(lái)并在后續(xù)提示中簡(jiǎn)要提及作為“會(huì)話記憶錨點(diǎn)”。例如“【決策記錄】支付處理器采用策略模式已定義PaymentStrategy接口?！眴?wèn)題-解決方案對(duì)在調(diào)試過(guò)程中將已識(shí)別的問(wèn)題和已驗(yàn)證的解決方案明確記錄下來(lái)避免智能體在后續(xù)步驟中重蹈覆轍或遺忘。這就像廚師在菜譜邊上標(biāo)注“上次鹽放多了這次減半”。4. 實(shí)戰(zhàn)演練一個(gè)用戶注冊(cè)API的“備料”到“出鍋”全流程讓我們通過(guò)一個(gè)具體的例子看看如何應(yīng)用這套方法論。假設(shè)我們要為一個(gè)已有后端項(xiàng)目添加一個(gè)用戶注冊(cè)API。4.1 步驟一準(zhǔn)備“備料臺(tái)”編寫上下文提示我不會(huì)直接打開AI對(duì)話窗口就開始打字。而是先創(chuàng)建一個(gè)臨時(shí)的文檔或注釋系統(tǒng)性地組裝上下文。# 智能體任務(wù)上下文添加用戶注冊(cè)API ## 1. 項(xiàng)目上下文 - **項(xiàng)目類型**: Node.js TypeScript后端服務(wù)采用分層架構(gòu)。 - **核心框架**: Express.js, Prisma ORM, JWT for auth. - **代碼風(fēng)格**: Airbnb ESLint基礎(chǔ)擴(kuò)展規(guī)則見 .eslintrc.js。使用async/await錯(cuò)誤處理統(tǒng)一使用try/catch包裹并在頂層中間件處理。 - **參考范例**: 請(qǐng)參考 src/api/routes/auth/login.ts 和 src/services/authService.ts 的現(xiàn)有模式。注意登錄API的請(qǐng)求驗(yàn)證、錯(cuò)誤響應(yīng)格式。 ## 2. 任務(wù)規(guī)格說(shuō)明書 **功能**: 實(shí)現(xiàn)用戶注冊(cè)端點(diǎn)。 **端點(diǎn)**: POST /api/v1/auth/register **請(qǐng)求體 (JSON)**: json { email: string, 必須符合郵箱格式且唯一, password: string, 最小長(zhǎng)度8位必須包含字母和數(shù)字, username: string, 可選如未提供則使用郵箱前綴 }成功響應(yīng) (201 Created):{ success: true, data: { user: { id: uuid, email: string, username: string }, token: JWT字符串用于后續(xù)認(rèn)證 } }錯(cuò)誤響應(yīng) (400 Bad Request):郵箱格式無(wú)效:{ success: false, error: INVALID_EMAIL_FORMAT }郵箱已存在:{ success: false, error: EMAIL_ALREADY_EXISTS }密碼強(qiáng)度不足:{ success: false, error: WEAK_PASSWORD }業(yè)務(wù)邏輯:驗(yàn)證請(qǐng)求體字段格式和強(qiáng)度。檢查郵箱在User表中是否已存在。對(duì)密碼進(jìn)行加鹽哈希使用bcrypt強(qiáng)度因子12。創(chuàng)建新用戶記錄寫入數(shù)據(jù)庫(kù)。生成JWT令牌payload包含userId和email有效期7天。返回用戶基本信息不含密碼哈希和JWT令牌。非功能需求:密碼明文絕不可出現(xiàn)在日志中。郵箱唯一性檢查需考慮數(shù)據(jù)庫(kù)并發(fā)注冊(cè)情況使用Prisma的create唯一約束或先f(wàn)indUnique后create在事務(wù)中處理。3. 給智能體的明確指令請(qǐng)按照以下步驟操作首先分析上述需求并列出你認(rèn)為的實(shí)現(xiàn)計(jì)劃1. 創(chuàng)建路由文件2. 創(chuàng)建或更新服務(wù)層函數(shù)3. 更新Prisma模型如果需要...。然后根據(jù)計(jì)劃先生成src/api/routes/auth/register.ts文件。接著生成或修改src/services/userService.ts添加createUser函數(shù)。最后確保生成的代碼遵循項(xiàng)目現(xiàn)有風(fēng)格并處理所有提到的錯(cuò)誤情況。 請(qǐng)分步驟進(jìn)行在每個(gè)步驟后暫停等待我的確認(rèn)或反饋。### 4.2 步驟二執(zhí)行與交互“烹飪”過(guò)程 將上述精心準(zhǔn)備的上下文提示復(fù)制到AI對(duì)話中。由于上下文清晰智能體通常能給出一個(gè)非?？孔V的實(shí)現(xiàn)計(jì)劃。我會(huì)審閱這個(gè)計(jì)劃確保它和我的架構(gòu)理解一致。 然后讓它按步驟生成代碼。在每一步我都會(huì)重點(diǎn)檢查 * **路由文件**是否正確地引入了依賴錯(cuò)誤處理中間件是否使用正確響應(yīng)格式是否符合規(guī)范 * **服務(wù)層函數(shù)**密碼哈希的邏輯是否正確是否考慮了并發(fā)返回的數(shù)據(jù)結(jié)構(gòu)是否匹配 * **代碼風(fēng)格**導(dǎo)入語(yǔ)句順序、命名規(guī)范、異步處理方式是否與項(xiàng)目現(xiàn)有代碼一致 如果在某一步發(fā)現(xiàn)偏差例如它可能用了一個(gè)舊的驗(yàn)證庫(kù)而不是我們項(xiàng)目正在使用的Joi我會(huì)立即中斷并糾正“停。我們項(xiàng)目使用 Joi 進(jìn)行請(qǐng)求驗(yàn)證請(qǐng)參考 login.ts 中 validateLoginRequest 函數(shù)的寫法重寫注冊(cè)請(qǐng)求的驗(yàn)證邏輯。” ### 4.3 步驟三驗(yàn)證與收尾“擺盤”與“嘗味” 代碼生成后我的工作并未結(jié)束。 1. **靜態(tài)檢查**將生成的代碼放入IDE運(yùn)行ESLint和TypeScript編譯器檢查是否有類型錯(cuò)誤或風(fēng)格問(wèn)題。智能體有時(shí)會(huì)忽略一些邊緣的類型定義。 2. **邏輯復(fù)查**人工通讀代碼特別是業(yè)務(wù)邏輯部分。檢查密碼哈希、唯一性約束處理、JWT生成等關(guān)鍵環(huán)節(jié)是否正確無(wú)誤。 3. **集成測(cè)試**編寫或運(yùn)行一個(gè)簡(jiǎn)單的集成測(cè)試可以是手動(dòng)調(diào)用也可以是簡(jiǎn)單的測(cè)試腳本驗(yàn)證API的完整流程。這是發(fā)現(xiàn)上下文理解偏差的最后一道防線。 4. **上下文歸檔**如果這個(gè)任務(wù)模式具有可復(fù)用性比如“添加一個(gè)標(biāo)準(zhǔn)的CRUD API”我會(huì)將這次成功的“上下文提示”作為一個(gè)模板保存下來(lái)下次類似任務(wù)只需做少量修改即可復(fù)用極大提升效率。 ## 5. 高級(jí)技巧應(yīng)對(duì)復(fù)雜任務(wù)與避免常見陷阱 當(dāng)任務(wù)從“炒個(gè)菜”升級(jí)為“籌辦一場(chǎng)宴席”例如重構(gòu)一個(gè)模塊或?qū)崿F(xiàn)一個(gè)包含多個(gè)交互組件的功能時(shí)簡(jiǎn)單的線性提示就不夠了。 ### 5.1 分治與迭代不要試圖一口吃成胖子 對(duì)于復(fù)雜任務(wù)絕對(duì)不要試圖在一個(gè)提示里解決所有問(wèn)題。采用“分治”策略。 * **第一步架構(gòu)設(shè)計(jì)對(duì)話**。提示智能體“我們需要實(shí)現(xiàn)一個(gè)帶實(shí)時(shí)通知的任務(wù)管理系統(tǒng)。請(qǐng)先給出一個(gè)高層次的技術(shù)架構(gòu)設(shè)計(jì)包括主要模塊、數(shù)據(jù)流和技術(shù)選型建議。” 基于它的建議進(jìn)行討論和修正形成共識(shí)。 * **第二步契約先行**?；诠沧R(shí)讓智能體先定義核心的接口Interface、類型Type和數(shù)據(jù)傳輸對(duì)象DTO。例如“請(qǐng)根據(jù)上述設(shè)計(jì)先定義 Task, User, Notification 的TypeScript接口以及創(chuàng)建任務(wù)、更新任務(wù)狀態(tài)的DTO類型?！?* **第三步模塊化實(shí)現(xiàn)**。然后按照模塊逐個(gè)擊破?！艾F(xiàn)在請(qǐng)先實(shí)現(xiàn) TaskService 的核心方法包括 createTask, assignTask, updateTaskStatus。請(qǐng)確保它們符合你剛才定義的接口。” 每一輪都基于上一輪確定的、無(wú)歧義的“契約”進(jìn)行確保上下文像搭積木一樣穩(wěn)步構(gòu)建而不是推倒重來(lái)。 ### 5.2 幻覺(jué)檢測(cè)與事實(shí)錨定 智能體的“幻覺(jué)”在復(fù)雜任務(wù)中尤為危險(xiǎn)。對(duì)抗幻覺(jué)最有效的方法是“事實(shí)錨定”。 * **引用真實(shí)代碼**當(dāng)討論現(xiàn)有代碼時(shí)不要描述而是直接粘貼相關(guān)代碼片段。例如不要說(shuō)“我們的錯(cuò)誤處理中間件是這么做的”而是說(shuō)“請(qǐng)看現(xiàn)有的錯(cuò)誤處理中間件代碼[粘貼代碼]請(qǐng)確保新的API使用相同的方式?！?* **要求提供出處**當(dāng)智能體給出一個(gè)建議或陳述一個(gè)關(guān)于你項(xiàng)目的事實(shí)時(shí)比如“Prisma模型里有一個(gè)createdAt字段”可以要求它“請(qǐng)指出這個(gè)信息是基于我提供的上下文還是你的通用知識(shí)如果是基于我的上下文請(qǐng)引用相關(guān)部分?！?這能迫使它檢查自己的“記憶”減少信口開河。 * **交叉驗(yàn)證**對(duì)于關(guān)鍵邏輯可以讓智能體從不同角度實(shí)現(xiàn)兩次或者要求它解釋代碼的每一行在做什么。解釋不通的地方往往就是幻覺(jué)或錯(cuò)誤所在。 ### 5.3 上下文的版本管理與迭代 一個(gè)項(xiàng)目的“備料臺(tái)”不是一成不變的。隨著項(xiàng)目演進(jìn)、技術(shù)棧升級(jí)、最佳實(shí)踐變化你的上下文模板也需要迭代。 * **建立上下文庫(kù)**為不同類型的任務(wù)CRUD API、數(shù)據(jù)遷移腳本、前端組件、配置部署文件建立標(biāo)準(zhǔn)化的上下文模板。 * **記錄失敗案例**當(dāng)一次智能體交互因?yàn)樵愀獾纳舷挛亩r(shí)事后分析原因并更新對(duì)應(yīng)的上下文模板補(bǔ)充當(dāng)時(shí)缺失的關(guān)鍵信息或糾正誤導(dǎo)性描述。 * **團(tuán)隊(duì)共享**在團(tuán)隊(duì)中推廣這種“備料”文化并共享優(yōu)化后的上下文模板。這能極大統(tǒng)一團(tuán)隊(duì)內(nèi)AI輔助編碼的輸出質(zhì)量減少因個(gè)人提示風(fēng)格差異導(dǎo)致的代碼風(fēng)格不一致問(wèn)題。 ## 6. 工具化與未來(lái)展望將方法論沉淀為工作流 最高效的實(shí)踐最終都會(huì)沉淀為工具或固化的工作流。 * **提示模板化**使用像Cursor IDE的.cursorrules文件或是將精心設(shè)計(jì)的提示保存為代碼片段在需要時(shí)快速插入。 * **上下文文件化**為項(xiàng)目創(chuàng)建一個(gè)AGENT_CONTEXT.md文件存放項(xiàng)目的技術(shù)棧摘要、代碼風(fēng)格公約、常用范例鏈接、以及常見任務(wù)的提示模板。新成員或新的智能體會(huì)話都可以以此為基礎(chǔ)。 * **與開發(fā)流程集成**在創(chuàng)建新的功能分支、或初始化一個(gè)新模塊時(shí)將“編寫智能體上下文提示”作為開發(fā)流程的第一步納入代碼審查的一部分。審查一個(gè)清晰的上下文提示往往能提前發(fā)現(xiàn)很多需求歧義和設(shè)計(jì)缺陷。 “Mise en Place for Agentic Coding”遠(yuǎn)不止是一個(gè)酷炫的類比。它代表了一種思維模式的轉(zhuǎn)變從將AI智能體視為一個(gè)“許愿機(jī)”輸入模糊愿望輸出完美結(jié)果轉(zhuǎn)變?yōu)閷⑵湟暈橐粋€(gè)擁有強(qiáng)大執(zhí)行力的“專業(yè)協(xié)作者”。而作為人類開發(fā)者我們最核心、最不可替代的價(jià)值就在于成為那個(gè)**專業(yè)的“備料師”**——通過(guò)深思熟慮的上下文工程定義清晰的問(wèn)題邊界提供精準(zhǔn)的約束和素材從而將智能體的能力引導(dǎo)向正確、高效、可靠的方向。 這個(gè)過(guò)程本身就是對(duì)問(wèn)題更深層次的思考和解構(gòu)它強(qiáng)迫你厘清需求、明確邊界、審視架構(gòu)。最終即使沒(méi)有智能體經(jīng)過(guò)這番“備料”思考后你自己去實(shí)現(xiàn)代碼的思路也會(huì)清晰數(shù)倍。這或許就是人機(jī)協(xié)同編程帶給我們的、超越工具本身的額外獎(jiǎng)賞一種更嚴(yán)謹(jǐn)、更工程化的思維方式。