不知道你有沒(méi)有這種經(jīng)歷模型明明已經(jīng)接好了外部工具結(jié)果調(diào)用的時(shí)候要么參數(shù)填得亂七八糟要么該調(diào)函數(shù)的時(shí)候不調(diào)、不該調(diào)的時(shí)候硬調(diào)。我在做一個(gè)內(nèi)部助手項(xiàng)目時(shí)為了給模型加上查天氣、查庫(kù)存、創(chuàng)建工單這幾個(gè)基礎(chǔ)能力前后改了六版function calling的交互設(shè)計(jì)才把可用性從“勉強(qiáng)能跑”拉到“敢給業(yè)務(wù)同事用”。這篇文章不是function calling的入門(mén)教程而是一份設(shè)計(jì)取舍筆記。記錄的是我在確定函數(shù)入?yún)?、返回值格式、調(diào)用策略、錯(cuò)誤恢復(fù)這些環(huán)節(jié)里踩過(guò)的坑和最終敲定的方案重點(diǎn)講每個(gè)決策的“為什么”。如果你正在給LLM應(yīng)用接工具或者已經(jīng)在用function calling但覺(jué)得效果不穩(wěn)這篇應(yīng)該能幫你少走不少?gòu)澛贰?. 設(shè)計(jì)前先定邊界function calling到底承擔(dān)什么1.1 先把能力邊界畫(huà)出來(lái)動(dòng)手寫(xiě)第一個(gè)函數(shù)定義之前我建議你先想清楚一件事function calling在整套系統(tǒng)里扮演的角色到底是什么。我的答案很直接它是“意圖識(shí)別后的參數(shù)抽取器”不是業(yè)務(wù)執(zhí)行器。模型通過(guò)function calling完成的任務(wù)本質(zhì)上只有兩個(gè)——決定“該調(diào)用哪個(gè)能力”以及“把用戶這句自然語(yǔ)言里的關(guān)鍵信息填進(jìn)這個(gè)能力需要的參數(shù)里”。至于調(diào)用之后業(yè)務(wù)邏輯怎么跑、數(shù)據(jù)怎么落庫(kù)、異常怎么處理那是業(yè)務(wù)系統(tǒng)的事不應(yīng)該讓模型替你做決定。這個(gè)邊界想清楚后續(xù)所有取舍都會(huì)變?nèi)菀?。比如?nèi)部助手項(xiàng)目里要接“創(chuàng)建工單”一開(kāi)始產(chǎn)品同事提的需求很豐富要支持緊急程度、附件上傳、自動(dòng)分配處理人、抄送相關(guān)人員。如果把這些全塞進(jìn)一個(gè)函數(shù)里模型要同時(shí)抽取七八個(gè)參數(shù)出錯(cuò)概率大幅上升用戶說(shuō)一句“幫我提個(gè)工單”就夠模型糾結(jié)半天。我的做法是砍。第一版只保留三個(gè)核心字段標(biāo)題title必填、描述description必填、優(yōu)先級(jí)priority選填枚舉值。附件、分派人、抄送這些能力全部走后續(xù)的業(yè)務(wù)頁(yè)面補(bǔ)齊不進(jìn)function calling。這不是偷懶而是因?yàn)閒unction calling的價(jià)值在于“快速把用戶的請(qǐng)求轉(zhuǎn)化為一個(gè)可執(zhí)行的結(jié)構(gòu)化動(dòng)作”參數(shù)越少抽取越準(zhǔn)響應(yīng)越快。1.2 極端場(chǎng)景下模型會(huì)“硬湊”參數(shù)邊界不清晰的另一個(gè)后果是模型會(huì)在缺乏信息時(shí)硬湊參數(shù)。這個(gè)現(xiàn)象我在測(cè)試階段遇到過(guò)很多次用戶只說(shuō)了“幫我查一下訂單”沒(méi)提供訂單號(hào)但因?yàn)槲医o查詢函數(shù)把訂單號(hào)設(shè)成了必填模型就自己編了一個(gè)“unknown”或者“123456”出來(lái)。后來(lái)我把這類標(biāo)識(shí)性字段全部改成“非必填允許為空”同時(shí)在前端交互層做補(bǔ)償——如果模型返回的查詢類函數(shù)里關(guān)鍵參數(shù)為空就主動(dòng)追問(wèn)用戶補(bǔ)齊而不是讓模型瞎猜。這一點(diǎn)算是第一版到第二版之間最關(guān)鍵的修改之一。2. 參數(shù)定義的嚴(yán)謹(jǐn)性是Function Calling第一道護(hù)城河2.1 JSON Schema的約束要“寧嚴(yán)勿松”很多開(kāi)發(fā)者在定義函數(shù)參數(shù)時(shí)只簡(jiǎn)單標(biāo)注類型比如“type: string”然后就交給模型自由發(fā)揮。實(shí)測(cè)下來(lái)這種做法在簡(jiǎn)單場(chǎng)景勉強(qiáng)能用一旦參數(shù)含義稍微復(fù)雜一點(diǎn)模型就會(huì)給你整出各種意想不到的格式。我舉一個(gè)真實(shí)案例。查天氣功能里有個(gè)參數(shù)叫“date”我用的是string類型。結(jié)果測(cè)試時(shí)發(fā)現(xiàn)用戶說(shuō)“明天呢”模型有時(shí)候返回“明天”有時(shí)候返回“tomorrow”有時(shí)候返回“2026-09-04”同一個(gè)意思四種格式下游代碼根本沒(méi)法處理。解決方案不是去提示詞里反復(fù)強(qiáng)調(diào)“請(qǐng)用YYYY-MM-DD格式”而是徹底相信JSON Schema的約束能力。我在scheme里加了pattern正則校驗(yàn)同時(shí)把description寫(xiě)清楚并且給枚舉值盡量都用上。{ name: query_weather, description: 查詢指定城市在指定日期的天氣情況, parameters: { type: object, properties: { city: { type: string, description: 城市名稱例如北京、上海、廣州, minLength: 2, maxLength: 10 }, date: { type: string, description: 查詢?nèi)掌诟袷綖閅YYY-MM-DD。如果是當(dāng)天請(qǐng)返回今天如果是明天請(qǐng)按實(shí)際日期計(jì)算后返回。, pattern: ^\\d{4}-\\d{2}-\\d{2}$ } }, required: [city, date] } }關(guān)鍵點(diǎn)在description里那句“如果是明天請(qǐng)按實(shí)際日期計(jì)算后返回”。不要指望模型會(huì)主動(dòng)做日期推算你必須在描述里把這個(gè)操作交代清楚它才會(huì)把“明天”轉(zhuǎn)換成具體日期。這類“參數(shù)語(yǔ)義前置說(shuō)明”的經(jīng)驗(yàn)后續(xù)在多個(gè)函數(shù)上都驗(yàn)證過(guò)有效。2.2 枚舉能鎖死就鎖死不給模型自由發(fā)揮的空間凡是取值集合可控的參數(shù)務(wù)必用enum。比如優(yōu)先級(jí)高/中/低、狀態(tài)待處理/處理中/已關(guān)閉、類型故障/咨詢/建議這類參數(shù)用枚舉可以顯著降低模型輸出的不確定性。但枚舉有個(gè)小坑如果枚舉值和用戶口語(yǔ)差異較大模型會(huì)匹配不上。比如用戶說(shuō)“挺著急的”你枚舉里只有“緊急”模型可能就困惑了。這時(shí)可以在description里補(bǔ)一句映射說(shuō)明“當(dāng)用戶表達(dá)時(shí)間緊、催辦、著急時(shí)映射為緊急”。這個(gè)技巧本質(zhì)上是把“口語(yǔ)理解規(guī)則”前置到函數(shù)描述里讓模型在抽取階段就完成歸一化而不是抽完再靠代碼硬轉(zhuǎn)效果會(huì)好很多。3. 提示詞與函數(shù)描述這是最容易忽略的“隱藏調(diào)參區(qū)”3.1 函數(shù)描述寫(xiě)的是“給模型看的Prompt”大多數(shù)人的注意力都放在“怎么把函數(shù)邏輯實(shí)現(xiàn)好”卻忽略了函數(shù)名和描述本身就是提示詞的一部分。模型對(duì)函數(shù)的選擇、參數(shù)的抽取都依賴它對(duì)函數(shù)描述的理解。這個(gè)描述寫(xiě)得好不好直接影響調(diào)用準(zhǔn)確性。舉個(gè)例子我在項(xiàng)目里有一個(gè)函數(shù)“send_message”第一版描述寫(xiě)的是“發(fā)送一條消息”。結(jié)果用戶說(shuō)“幫我提醒我下午三點(diǎn)開(kāi)會(huì)”模型居然也調(diào)用了這個(gè)函數(shù)把內(nèi)容設(shè)成了“下午三點(diǎn)開(kāi)會(huì)”。后來(lái)我改成“向指定聯(lián)系人發(fā)送一條即時(shí)消息用于用戶主動(dòng)發(fā)消息的場(chǎng)景。提醒、定時(shí)任務(wù)、日程相關(guān)需求請(qǐng)勿使用本函數(shù)”誤調(diào)用概率明顯下降。函數(shù)別名的取舍也值得一提。你是否遇到過(guò)模型想表達(dá)“改”的時(shí)候反復(fù)嘗試update、update_info、modify等不同的函數(shù)名這是因?yàn)椴怀Ｓ玫膭?dòng)詞對(duì)模型來(lái)講容易混淆。此時(shí)你可以在函數(shù)描述里主動(dòng)列舉同義表達(dá)。比如把“update”改成“update_order”description為“修改/更新/變更訂單信息比如改地址、改數(shù)量、改備注等”讓模型一眼就從用戶話癆式的表達(dá)里對(duì)應(yīng)上函數(shù)。3.2 系統(tǒng)提示詞里的“工具提示”需要單獨(dú)寫(xiě)系統(tǒng)提示詞越堆越長(zhǎng)模型對(duì)function的感知力往往越低。我后來(lái)單獨(dú)劃出了一小段“工具使用規(guī)則”放在工具調(diào)用前比如順序、什么情況不用調(diào)用工具、調(diào)用完該干嘛等。實(shí)測(cè)下來(lái)這個(gè)策略能明顯降低兩個(gè)問(wèn)題一是模型在閑聊場(chǎng)景強(qiáng)行調(diào)工具二是模型調(diào)用完工具后不把結(jié)果組織成自然語(yǔ)言就直接吐JSON。我給“工具使用規(guī)則”的示例文本大概是這樣的只有用戶的提問(wèn)涉及實(shí)時(shí)數(shù)據(jù)或需要執(zhí)行某個(gè)操作時(shí)才調(diào)用工具。調(diào)用工具前必須先向用戶簡(jiǎn)短確認(rèn)意圖避免誤操作。工具返回結(jié)果后用自然語(yǔ)言向用戶匯報(bào)不要直接展示原始JSON。如果用戶問(wèn)題與所有工具都無(wú)關(guān)直接正?；卮鸺纯?。這段內(nèi)容沒(méi)有放在函數(shù)定義里而是放在系統(tǒng)提示詞的工具段落跟function calling配合使用。兩者有前后關(guān)系模型先讀系統(tǒng)提示詞再看到可用函數(shù)列表。這樣做能避免模型一臉懵地面對(duì)一堆函數(shù)——先給它規(guī)矩再給它工具它才知道怎么用。4. 調(diào)用策略該調(diào)就調(diào)不該調(diào)也別硬調(diào)4.1 tool_choice的三種模式怎么選使用函數(shù)調(diào)用時(shí)平臺(tái)基本都會(huì)提供tool_choice設(shè)置一般有auto、none、required三種。很多初學(xué)者一律用auto然后祈禱模型自覺(jué)。實(shí)測(cè)結(jié)果經(jīng)常是閑聊時(shí)瘋狂調(diào)用函數(shù)真該調(diào)用時(shí)又靜默跳過(guò)。我的建議是分場(chǎng)景定策略。如果是內(nèi)部工具型助手比如“幫我提交請(qǐng)假申請(qǐng)”這種操作建議直接把tool_choice設(shè)為required強(qiáng)制模型先調(diào)用對(duì)應(yīng)工具再回答避免模型跳過(guò)工具生成一個(gè)“假結(jié)果”。如果是問(wèn)答型助手比如“幫我整理一下最近的銷售數(shù)據(jù)”用auto即可讓模型自己判斷是否需要調(diào)用。另外我還測(cè)試過(guò)none的效果——在任務(wù)適合用純文本回答時(shí)強(qiáng)制關(guān)閉工具調(diào)用能明顯降低生成延遲和幻覺(jué)。這提示了一個(gè)方向你可以先用一個(gè)輕量分類模型判斷屬于“工具型查詢”還是“純問(wèn)答”再?zèng)Q定給主對(duì)話模型設(shè)置哪種tool_choice。這一步對(duì)成本控制也很有幫助。4.2 多函數(shù)并行調(diào)用的取舍部分推理模型支持一次返回多個(gè)函數(shù)調(diào)用。表面上看這是效率提升用戶問(wèn)“北京和上海明天天氣怎么樣”模型一次返回兩個(gè)query_weather調(diào)用。但它在實(shí)際工程里帶來(lái)了復(fù)雜度多個(gè)函數(shù)參數(shù)是否都正確、多個(gè)結(jié)果如何組合、模型是否需要二次推理。我第一版嘗試了并行調(diào)用很快就回退成“一次只調(diào)一個(gè)函數(shù)”。原因有兩條一是并行調(diào)用時(shí)模型會(huì)比較多地把兩個(gè)城市的天氣參數(shù)搞串二是代碼處理多個(gè)函數(shù)調(diào)用結(jié)果時(shí)如果不加一個(gè)“匯總環(huán)節(jié)”直接拼結(jié)果給用戶看觀感會(huì)差很多。比如兩個(gè)天氣對(duì)象的溫度單位渲染方式可能不一致。如果你一定要用并行我建議加一個(gè)“匯總函數(shù)”并行調(diào)用全部返回后再讓模型基于各個(gè)結(jié)果生成一段綜合回復(fù)。相當(dāng)于多一次推理。這個(gè)思路跟“ReAct”有點(diǎn)像但落地成本會(huì)高一些看你項(xiàng)目預(yù)算和延遲指標(biāo)能不能接受。5. 錯(cuò)誤處理Function Calling不是銀彈它也會(huì)失敗5.1 參數(shù)抽取失敗的兜底策略模型抽取參數(shù)偶爾會(huì)失敗比如用戶說(shuō)“幫我看看明天穿什么衣服”模型需要先查天氣預(yù)報(bào)再生成穿衣建議。它能正確調(diào)用天氣函數(shù)但date參數(shù)可能因?yàn)闆](méi)理解“明天”而傳錯(cuò)?；蛘哂脩舾緵](méi)提供城市模型返回一個(gè)空值。應(yīng)對(duì)這類問(wèn)題我準(zhǔn)備了兩層兜底。第一層模型側(cè)函數(shù)定義里把“參數(shù)缺失時(shí)該怎么做”寫(xiě)清楚。比如description里加一句“如果城市不存在請(qǐng)?jiān)儐?wèn)用戶提供城市名稱后再次調(diào)用”。第二層代碼側(cè)函數(shù)返回結(jié)果如果是空參數(shù)不要直接報(bào)錯(cuò)而是封裝一個(gè)“參數(shù)缺失”的結(jié)構(gòu)體回傳模型讓模型基于這個(gè)結(jié)果組織追問(wèn)話術(shù)。這兩層設(shè)計(jì)完成后“模型瞎編參數(shù)”的問(wèn)題基本消失了。核心思路是把“無(wú)法抽取參數(shù)”本身當(dāng)成一種函數(shù)調(diào)用的正常返回情況而不是異常。5.2 工具返回結(jié)果格式要統(tǒng)一工具返回的內(nèi)容如果格式混亂模型二次加工時(shí)很吃虧。比如一個(gè)函數(shù)返回JSON嵌套很深另一個(gè)函數(shù)返回純文本模型在處理“把結(jié)果轉(zhuǎn)成自然語(yǔ)言”這一層時(shí)表現(xiàn)會(huì)明顯不穩(wěn)定。我做了一個(gè)約定所有工具返回結(jié)果必須是結(jié)構(gòu)化JSON至少包含status、data、message三個(gè)字段有報(bào)錯(cuò)時(shí)在message里寫(xiě)明原因。這樣模型不用猜每次都能從JSON里穩(wěn)定提取內(nèi)容。{ status: success, data: { city: 北京, date: 2026-09-03, weather: 晴, temperature_max: 31, temperature_min: 22 }, message: 查詢成功 }出現(xiàn)業(yè)務(wù)性錯(cuò)誤時(shí)比如查無(wú)此訂單、庫(kù)存不足message字段里會(huì)寫(xiě)清楚原因status為“fail”。模型看到statusfail就會(huì)自動(dòng)組織一段“很抱歉您查詢的訂單不存在”之類的自然語(yǔ)言回復(fù)。這個(gè)設(shè)計(jì)的核心價(jià)值是把業(yè)務(wù)異常判斷交給了代碼把“如何禮貌地向用戶解釋”留給了模型各司其職。6. 上下文管理別讓歷史記錄毀掉下一次調(diào)用質(zhì)量6.1 函數(shù)調(diào)用過(guò)程和結(jié)果要不要放進(jìn)歷史消息里這是個(gè)容易被忽略的細(xì)節(jié)第一輪模型先后調(diào)用了天氣函數(shù)拿到了結(jié)果生成了回復(fù)。第二輪用戶追問(wèn)“那后天呢”。如果Assistant消息里包含了第一輪的函數(shù)調(diào)用細(xì)節(jié)包括那個(gè)很大的JSON返回體模型就能理解“后天”是基于北京繼續(xù)問(wèn)。但是如果不放模型就不知道上下文會(huì)重新問(wèn)用戶要城市。我經(jīng)歷過(guò)這兩個(gè)極端。只放自然語(yǔ)言回復(fù)、不放函數(shù)調(diào)用細(xì)節(jié)時(shí)多輪追問(wèn)垮得很明顯。把完整JSON都放進(jìn)去時(shí)效果好了但上下文體積暴漲token開(kāi)銷蹭蹭往上走。后來(lái)我的方案是函數(shù)調(diào)用后把原始JSON結(jié)果精簡(jiǎn)之后再放回歷史消息。等價(jià)的策略是建一個(gè)JSON轉(zhuǎn)換器去掉冗余字段保留核心信息。比如此前天氣查詢返回了一堆數(shù)值我對(duì)歷史保留只保留“北京 2026-09-03 晴 22-31℃”這行摘要既讓模型有足夠的上下文又不至于把上下文撐爆。6.2 超長(zhǎng)對(duì)話時(shí)的“工具記憶”壓縮如果對(duì)話超過(guò)十輪模型對(duì)早前函數(shù)調(diào)用結(jié)果的記憶通常已經(jīng)不可靠。這時(shí)候與其指望模型記住不如主動(dòng)用摘要替換早期消息。我做過(guò)一個(gè)簡(jiǎn)易方案每當(dāng)對(duì)話達(dá)到6輪以上就把前面所有函數(shù)調(diào)用記錄壓縮成一段純文本摘要替換掉原來(lái)的消息列表再繼續(xù)往下對(duì)話。這類壓縮摘要的prompt也可以寫(xiě)成符合極簡(jiǎn)原則的幾條規(guī)則。實(shí)測(cè)節(jié)省token約40%多輪追問(wèn)的準(zhǔn)確率基本不變。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 高頻問(wèn)題速查表問(wèn)題表現(xiàn)常見(jiàn)原因解決方案模型中返回參數(shù)類型不是預(yù)期類型JSON Schema描述不清晰或沒(méi)加pattern加強(qiáng)枚舉與正則約束描述里寫(xiě)清楚格式要求該調(diào)用函數(shù)時(shí)不調(diào)用tool_choiceauto且系統(tǒng)提示詞沒(méi)有強(qiáng)制規(guī)則針對(duì)工具型場(chǎng)景把tool_choice設(shè)為required并在系統(tǒng)提示詞中寫(xiě)明觸發(fā)條件不該調(diào)用時(shí)反復(fù)調(diào)用函數(shù)描述過(guò)于寬泛涵蓋了許多場(chǎng)景收緊描述加入否定排除條件如“僅限……不要用于……”模型編造缺失參數(shù)參數(shù)必填且沒(méi)有在描述中要求追問(wèn)對(duì)標(biāo)識(shí)字段設(shè)非必填代碼側(cè)檢測(cè)空值并引導(dǎo)追問(wèn)日期時(shí)間類參數(shù)格式不統(tǒng)一沒(méi)有在schema中做pattern約束用正則鎖死格式配合description做口語(yǔ)映射說(shuō)明函數(shù)調(diào)結(jié)果直接原樣吐出系統(tǒng)提示詞缺少“組織語(yǔ)言回復(fù)”的指令加入工具結(jié)果后處理規(guī)則提示模型用自然語(yǔ)言總結(jié)返回結(jié)果多輪追問(wèn)失效歷史消息缺少工具調(diào)用摘要把函數(shù)調(diào)用JSON精簡(jiǎn)成一行摘要放回歷史消息報(bào)錯(cuò)信息模型看不懂工具返回結(jié)構(gòu)混亂不統(tǒng)一統(tǒng)一封裝status/data/message結(jié)構(gòu)并明確message文案7.2 一個(gè)典型的排查過(guò)程復(fù)現(xiàn)有一次我的助手在測(cè)試“幫我創(chuàng)建一個(gè)高優(yōu)先級(jí)工單內(nèi)容是打印機(jī)壞了”時(shí)返回的優(yōu)先級(jí)字段竟然是“HIGH”。代碼里校驗(yàn)枚舉是“緊急/高/中/低”死活匹配不上。乍一看以為是模型問(wèn)題但后來(lái)查日志發(fā)現(xiàn)是我在函數(shù)定義的description寫(xiě)了“priority level”模型把“高優(yōu)先級(jí)”直接映射成英文的“high”了。修正方式不復(fù)雜把description改成“優(yōu)先級(jí)枚舉值為緊急、高、中、低”并加了一句“請(qǐng)根據(jù)用戶表達(dá)的語(yǔ)氣程度映射比如‘很急’對(duì)應(yīng)緊急‘加急’對(duì)應(yīng)高”。從那以后優(yōu)先級(jí)字段的抽取準(zhǔn)確率基本穩(wěn)定在95%以上。這個(gè)案例印證了一個(gè)規(guī)律功能調(diào)用的異常排查優(yōu)先檢查的不是代碼邏輯而是你看不見(jiàn)的“描述文本”。描述是模型理解的唯一入口描述稍微有歧義模型就會(huì)用自己的方式給你驚喜。8. 這套設(shè)計(jì)還可以怎么擴(kuò)展8.1 從單函數(shù)到多Agent任務(wù)編排當(dāng)前這套設(shè)計(jì)是圍繞“單個(gè)模型多個(gè)函數(shù)”展開(kāi)的。如果你想進(jìn)一步擴(kuò)展可以考慮把“工具調(diào)用”和“Agent編排”結(jié)合一個(gè)模型負(fù)責(zé)決策另一個(gè)模型負(fù)責(zé)具體執(zhí)行工具調(diào)用主模型做總結(jié)。這樣能規(guī)避單模型在“既要對(duì)話又要工具調(diào)用”時(shí)的狀態(tài)切換損耗代價(jià)是多一次模型調(diào)用延遲。8.2 增加函數(shù)調(diào)用的權(quán)限控制與審計(jì)在偏業(yè)務(wù)場(chǎng)景工具調(diào)用意味著操作真實(shí)數(shù)據(jù)此時(shí)“函數(shù)級(jí)權(quán)限控制”就很有必要。每個(gè)函數(shù)配置需要的權(quán)限標(biāo)簽調(diào)用前由代碼側(cè)校驗(yàn)當(dāng)前用戶的權(quán)限符合才放行否則直接返回“無(wú)權(quán)限”的結(jié)果給模型。這樣模型即便產(chǎn)生了錯(cuò)誤的調(diào)用意圖也不會(huì)真的執(zhí)行操作安全邊界始終由代碼兜底。這一點(diǎn)對(duì)于生產(chǎn)環(huán)境非常重要——你永遠(yuǎn)不會(huì)希望在測(cè)試時(shí)發(fā)現(xiàn)模型調(diào)了刪除接口。在內(nèi)部項(xiàng)目上我最終把函數(shù)調(diào)用的準(zhǔn)確率從最初的70%出頭提升到95%上下核心改動(dòng)都不是什么復(fù)雜工程而是把一個(gè)一個(gè)細(xì)節(jié)摳清楚參數(shù)約束是否嚴(yán)格、描述是否可以減少歧義、失敗時(shí)是否有兜底路徑、多輪對(duì)話時(shí)上下文是否連續(xù)。這套方法論放在任何LLM應(yīng)用里都適用。最后分享一個(gè)我反復(fù)強(qiáng)調(diào)的習(xí)慣每個(gè)函數(shù)上線前先準(zhǔn)備30條真實(shí)用戶語(yǔ)料手工標(biāo)注出希望模型抽取的參數(shù)結(jié)果然后跑一遍評(píng)測(cè)。跑完把失敗case逐個(gè)打開(kāi)看大多數(shù)問(wèn)題都能追溯到函數(shù)定義本身。適配評(píng)測(cè)跑完后再開(kāi)發(fā)業(yè)務(wù)邏輯往往能少加一個(gè)星期的班。