開頭先講一個矛盾同一個大語言模型LLM有些任務讓人驚喜有些任務讓人想砸鍵盤。問題往往不在模型本身而在我們讓它“做”的事不對。很多資料會把模型能力列成一張很長的清單能寫代碼、能翻譯、能總結、能當Agent到了真實業務里我們缺的不是“能不能做”的清單而是“該不該做”的判斷方法。What LLMs Should Do表面是能力問題實際是任務邊界問題。1. 先放下“能不能做”回答“該不該做”1.1 能力邊界不等于使用邊界很多人評估一個模型能否用于業務方式是拿幾條問題去跑一遍看回答像不像。這是體驗不是評估。真實業務里一個任務需要的是重復跑、穩定輸出、在無人盯情況下不出事。你讓模型寫一首詩寫得一般也能接受你讓模型批量處理用戶留言錯一條就需要解釋。同一個模型在不同任務約束下使用價值完全不同。比如模型能“做”會議紀要也能“做”訂單金額匯總。但會議紀要只要要點齊全人可以容忍部分措辭不完美訂單金額只要錯一位數后面所有流程都會被帶偏。所以不能因為模型“認識這些詞”就斷定它適合這個任務。能力邊界回答的是“模型能輸出什么”使用邊界回答的是“我們該讓它負責什么”。1.2 LLM 真正適合的任務通常具備四個特征我一般用四個特征做初步篩選輸入和輸出都以文本/自然語言為主。結果可以被人工或程序快速校驗。任務本質是生成、總結、改寫、抽取、分類或格式轉換。不要求絕對確定性、不依賴實時狀態、不直接執行外部動作。以“把一段會議記錄整理成待辦事項”為例輸入是文本輸出是文本人可以幾秒內判斷待辦是否合理模型可以抽取“負責人、時間、事項”這條任務適合交給LLM。反過來“統計訂單總金額并生成報表”雖然輸入輸出也是文本但數字必須精確一旦出錯影響很大。它不滿足第4條不適合讓模型直接輸出最終數字更合適的方式是讓模型從非結構化描述里抽取訂單號、金額和日期再由代碼完成計算。1.3 為什么先跑通再優化在任務邊界判斷上也成立很多團隊選型時先比參數量、看跑分、看榜單然后才到業務里試。這里的成本很高。更實用的順序是先拿20條真實業務樣本用同一個提示詞、同一個溫度參數跑一遍人工看結果。如果方向不對先調整任務分解而不是急著換大模型。因為很多“模型不行”的結論其實是任務定義不清晰或提示詞沒有圍繞任務結構寫。比如只告訴模型“幫我把評論分類”不如告訴它“存在這三個分類每個分類定義是什么輸出格式是JSON如果無法判斷就返回unknown”。先在小樣本上把任務邊界說清楚再評估模型水平才是有意義的比較。2. 不該交給 LLM 的任務往往就壞在“看起來能做”2.1 幻覺不是模型故意騙人而是概率生成的下界要理解為什么有些任務不該交給LLM需要接受一個底層事實LLM是在做下一個token的概率預測。它擅長的是“在給定上下文中生成最自然的延續”而不是“在數據庫中查詢并返回唯一真理”。所以當模型缺少某個事實時它不會像搜索引擎一樣說“查無此條”而是會用一個看起來合理的回答填補空白。這就是幻覺。可以把LLM想象成一位經驗豐富但偶爾會自信出錯的助手。你讓它起草一份方案它很高效你讓它直接對外發布最終版本就需要有人校對。這不是它能力低而是它的工作機制決定了它適合“生成草稿”不適合“終審發布”。凡是要求100%忠實于事實的任務都必須給模型提供可信來源或者把事實核對邏輯放到模型外面。2.2 用“錯誤代價”給任務分級在做任何決定前先評估“如果輸出是錯的會帶來什么后果”低風險內容可以被人工快速修改例如營銷文案、代碼注釋、會議紀要、非正式郵件草稿。中風險內容涉及結構化數據或下游流程但可以在執行前被程序攔截例如提取字段后由正則校驗、生成SQL后在沙箱執行。高風險內容直接影響資金、權限、人身安全、法律條款或對外承諾例如自動退款、自動發版、自動發送合同。低風險任務可以直接交給LLM。中風險任務需要給LLM套一層“只生成、不執行”的護欄。高風險任務里LLM能做的只是提供參考決策權必須留給人。判斷標準不是“模型能不能做到”而是“錯了之后補救成本高不高”。2.3 很多人忽略的信號任務描述里有沒有“總是”“所有”“一定”如果你的任務描述是“所有郵件都分類正確”“接口每次都返回相同格式”那么LLM不一定是最優選。它擅長處理模糊性和多樣性而不是維持硬性約束。這時需要把任務拆成兩個部分讓LLM處理語義部分比如識別意圖、抽取要素用代碼處理規則部分比如字段校驗、格式校驗、唯一性檢查。這個思路比逼模型變得更精確更可靠。一個常見教訓不要因為框架自帶 Agent 能力就把一個本來可以用固定 prompt 完成的分類任務拆成多輪自省。Agent 每多一步都意味著更高的延遲、更大的出錯概率和更難的日志排查。3. 用 LLM 框架把“該做的事”固化下來3.1 框架不是在包裝模型而是在維護任務的上下文現在提到 LLM 框架很多人會想到 LangChain、LlamaIndex 這類常見選擇。最初我也覺得框架是在簡化模型調用后來才發現框架真正解決的是上下文維護問題。在一次真實任務里模型需要知道的不是一句“幫我分類”而是背景信息、任務目標、字段定義、示例、輸出格式、邊界條件。如果每次都在業務代碼里臨時拼一個prompt遲早會混亂?？蚣馨堰@些內容模板化并把模型調用、日志、重試、結構化輸出等固定成可復用組件。但要注意框架本身不解決“該不該做”的問題。如果任務方向錯了框架只是更快地跑到錯誤地方。所以不要一上來就搭一套完整的 Agent、RAG、記憶、工具調用系統先想清楚任務是否需要這些組件。3.2 提示詞管理是框架的第一層回報提示詞也是代碼需要版本管理和測試。用框架可以把 system prompt、user prompt、示例放到獨立目錄或配置中心再用測試集做一個評估樣板。例如一個分類任務先準備20條標注過的文本每次修改提示詞后都跑一遍看準確率是上升還是下降。這樣提示詞就不再是某個開發者本地的“咒語”而是整個團隊可以迭代的資產。這是 LLM 落地中最容易忽略也最值得投入的部分。很多人把精力放在選模型和調參數上忽略了 prompt 模板本身會隨著業務變化而過期。一個穩定的評測集比換一個大模型更能保證長期效果。3.3 檢索增強和工具調用本質是給 LLM 縮小責任半徑很多復雜任務不適合直接交給LLM因為它們要求模型知道太多外部事實。一個典型解法是檢索增強RAG把私有文檔切成片段用向量庫做相似度檢索再把命中片段和用戶問題一起交給LLM生成答案。這樣一來LLM不用靠記憶回答它只需要基于“給定的片段”做總結和表達。這是 What LLMs Should Do 的一個正面案例讓LLM負責它擅長的語言組織讓檢索系統負責事實召回。工具調用也一樣。別讓LLM直接完成“給用戶發通知”這個動作而是讓LLM決定“應該調用哪個工具并傳什么參數”再由代碼執行工具并校驗結果。這樣即使模型判斷錯了工具層還可以做權限校驗和審批。框架的意義就是把這種“模型只做決策、代碼負責執行”的分工固化下來。4. 部署形態先于任務判斷本地還是 API和“是否同機”不是一回事4.1 一個常見問題的拆解ComfyUI 與 LLM 必須在同一臺電腦上么在社區里看到過一個高頻問題ComfyUI 與 LLM 必須在同一臺電腦上么這個問題的背后不是兩款軟件怎么連而是對 LLM 部署形態的誤解。直接回答不必需。ComfyUI 本身處理的是圖像生成與圖像處理對顯卡和 CUDA 環境要求較高。如果只是想用它調用LLM來生成提示詞、總結標簽或做畫質評估LLM完全可以部署在另一臺機器上通過 HTTP API 或局域網端口調用。反過來如果非要讓兩個服務共享同一塊 GPU才需要關心顯存是否夠大、是否會互相搶占、會不會頻繁 OOM。所以正確的提問方式不是“必須同機嗎”而是“我的資源約束和服務調用關系是什么”。4.2 三種部署形態分別適合什么場景全遠程 API本地只發請求。適合快速驗證、低頻調用、不想維護模型服務。缺點是有網絡依賴、數據要經過外部服務、按量付費。本地模型服務在一臺機器上部署一個模型服務例如通過 ollama、vLLM 這類工具然后把 API 暴露給局域網或其他應用。適合對隱私有要求、需要高頻內網調用、或者要控制成本。同進程內嵌加載在同一個應用里把模型加載進來不走網絡。適合完全離線的小型任務但資源耦合度高多項目共用時容易互相影響。在“ComfyUI 與 LLM 是否同機”這個具體場景里最常見的是第二種LLM 作為獨立服務運行ComfyUI 通過 HTTP 調用。這也是更合理的架構因為圖像生成和文本生成的時間、顯存需求不一樣拆開后可以單獨擴容出問題時也更好排查。4.3 本地部署時真正要盯的是資源約束和生效質量本地跑LLM不等于把模型文件下載下來就萬事大吉。顯存和內存決定了你最多能跑多大參數量、多少并發上下文長度決定了單次任務可以喂多少材料量化精度會影響占用和生成質量溫度參數則影響穩定性和創造性。如果業務任務是分類、抽取這類低隨機性任務temperature 一般直接設為0如果是在做文案生成可以適當調高。這里最容易踩坑的是“模型能加載但效果達不到預期”。本地7B模型在一些簡單分類上可能夠用但如果要做復雜的邏輯推理或多文檔總結效果就會明顯下滑。此時別急著調提示詞先確認是不是模型能力上限的問題再考慮升級模型或切回 API。判斷方法還是一樣固定一批小測試集對比不同模型在相同提示詞下的輸出質量。5. 判斷任務該不該交給 LLM 的一套最小流程5.1 五步評估法把前面的內容收斂成一個可復用流程寫下任務描述標出輸入是什么、輸出是什么。判斷輸出是否以文本/自然語言為主如果不是考慮拆解讓 LLM 只做語義部分。評估錯誤代價如果錯了能否在低成本的條件下被人或程序發現并修復。確認是否需要外部事實或實時狀態如果需要先規劃檢索或工具調用而不是讓模型硬記。準備20條真實樣本作為驗收集用固定提示詞和固定參數跑一遍人工判斷通過率。如果第2、3、4步都提示“不適合”就不要硬上。如果通過了再用最小流程驗證。5.2 一個示例從客戶評論分類到摘要生成假設要處理“客戶評論分類并生成摘要”。輸入是文本評論輸出是“分類摘要”這是典型的文本任務。錯誤代價分類錯誤或摘要不準確運營人員可以在發送反饋前人工抽查問題不大。外部事實不需要實時狀態只需要模型自身語義理解能力。驗收樣本從歷史評論里隨機抽20條先人工標好分類標簽和期望摘要。然后開始第一次測試。提示詞里寫清楚分類定義、輸出格式最好加一兩個示例。temperature 設為0。跑完20條后人工判斷通過率。如果通過率達到90%就可以逐步擴大到一個更大的驗證集如果沒達到先看失敗樣本判斷是分類定義模糊、輸出格式不穩定還是評論本身太復雜再針對性調整提示詞或模型。示例結構可以這樣# 示例結構用統一函數調用本地或遠程 LLM 服務 def run_llm(system_prompt: str, user_prompt: str, temperature: float 0.0): # 內部實現負責調 API、超時、日志記錄 response call_llm_service( messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperaturetemperature, ) return response注意這是示例結構不是某個框架的官方 API。真實項目里還要在這里加上版本號和輸出校驗。5.3 從最小流程到批量化最后才是工程化單次跑通并不等于能穩定批量使用。一個任務驗證通過后還需要做三件事給每次調用加日志記錄模型版本、prompt版本、耗時、輸出結果和校驗結果。加失敗重試和降級策略。例如網絡超時重試兩次仍然失敗就寫入待人工處理隊列。把輸入輸出放到固定的目錄或表結構里方便審計和回溯。如果后續要長期使用還要關注 prompt 測試集維護。隨著業務變化初始的20條樣本會過期需要定期補充新樣本。這個部分看起來瑣碎但在生產環境里它的價值比“換一個更強模型”更大。5.4 輸出不穩定的前四個檢查點如果已經把一個任務交給 LLM但輸出時好時壞建議按順序排查輸入端檢查消息結構、編碼、上下文長度和權限設置。很多空輸出或報錯來自請求格式不對。提示詞看是否給了足夠的示例和明確的輸出格式。如果只是加一句“要準確”效果通常有限。采樣參數分類/抽取任務先確認 temperature 是否設為0同時檢查 top_p、max_tokens 是否限制了輸出長度。模型與框架版本同一個模型在不同兼容層下可能有差異改了 prompt 模板或升級了框架版本也會影響結果。這個排查順序已經能解決大部分“模型不穩定”的困惑。如果還沒有解決再往業務數據觀察看是不是輸入分布超出了預期?；氐介_頭的那個問題What LLMs Should Do。我的答案是LLM 應該承擔那些“由語言驅動、允許校驗、錯誤成本可控”的任務而不是成為一個被強塞一切需求的萬能盒子。能力邊界會隨著模型迭代快速變化但任務邊界判斷方法基本不會變。以后遇到一個“能不能用 LLM 做”的問題先別急著上框架、調參數拿20條真實樣本跑一遍算一下錯誤代價再決定讓它做什么。這一步想清楚了后面的工程化才有意義。