1. 從“本本主義”說起AI 開發(fā)里最隱蔽的坑“本本主義”這個詞最早是講做事只認書本條文、不顧實際情況。放到今天的 AI 開發(fā)里它換了一身更時髦的衣服只認論文、只認框架文檔、只認別人博客里的“最佳實踐”卻不去看自己手里的數(shù)據(jù)長什么樣、業(yè)務到底卡在哪、用戶真正要的是什么。我見過太多團隊一上來就討論要不要上 RAG、要不要接 Agent、要不要搞多智能體協(xié)作結果連最基礎的“模型輸出格式不穩(wěn)定”都沒解決項目拖了三個月還在調(diào) Prompt。AI 開發(fā)這個領域表面上看是技術活實際上更像是一門“在不確定中找確定”的手藝。模型是黑盒數(shù)據(jù)是臟的需求是飄的算力是有限的。你如果拿一本教科書式的思維去套基本都會翻車。我寫這篇東西不是要否定理論和方法論而是想把我這幾年在 AI 應用開發(fā)、Agent 搭建、大模型落地過程中踩過的坑、總結出來的“反本本主義”經(jīng)驗系統(tǒng)地講清楚。適合誰看適合正在做 AI 應用開發(fā)、AI Agent 開發(fā)、AI 測試開發(fā)或者正準備從傳統(tǒng)開發(fā)轉(zhuǎn)向 AI 開發(fā)的工程師和產(chǎn)品同學。不管你是剛?cè)腴T還是已經(jīng)帶團隊這里面的思路和實操細節(jié)應該都能讓你少走一些彎路。核心觀點先擺出來AI 開發(fā)不是“先學完再做”而是“邊做邊學、以做為主”。理論是地圖但地圖不等于地形。真正決定項目成敗的往往不是你知道多少種架構而是你能不能快速驗證一個最小閉環(huán)、能不能在臟數(shù)據(jù)里找到可用信號、能不能把不確定的模型行為約束到可接受的范圍內(nèi)。2. 為什么 AI 開發(fā)特別容易陷入本本主義2.1 信息過載帶來的“方法論焦慮”AI 這個領域信息更新速度極快。今天出一個新框架明天出一個新范式后天又有人喊“某某已死”。打開任何一個技術社區(qū)滿屏都是“AI Native 研發(fā)范式”“Agent 最佳實踐”“大模型應用開發(fā)學習路線”。這種信息密度會讓人產(chǎn)生一種錯覺我必須先把這些都搞懂才能開始做。但實際情況是這些內(nèi)容里 80% 是營銷包裝15% 是特定場景下的經(jīng)驗只有 5% 是真正通用的底層邏輯。你如果按“學習路線”從頭學到尾等你學完你學的東西可能已經(jīng)過時了。更關鍵的是很多知識只有在動手做的過程中才會真正內(nèi)化。你看十篇講 RAG 的文章不如自己搭一個最小檢索問答跑一遍因為只有跑起來你才會遇到“切塊大小怎么定”“向量模型選哪個”“召回不準怎么辦”這些真實問題。我個人的做法是先定一個最小可驗證目標然后倒推需要學什么。比如我要做一個“根據(jù)用戶問題從產(chǎn)品文檔里找答案”的功能那我需要的就是一個能讀文檔的解析器、一個向量化方案、一個檢索邏輯、一個能拼 Prompt 的調(diào)用鏈。其他的什么多路召回、重排序、查詢改寫先不管。等最小閉環(huán)跑通了再根據(jù)實際效果決定要不要加。2.2 論文思維與工程思維的錯位學術論文追求的是“在特定數(shù)據(jù)集上刷到最高分”工程追求的是“在真實場景下穩(wěn)定可用”。這兩者的目標函數(shù)根本不一樣。論文里可以假設數(shù)據(jù)是干凈的、標注是準確的、評測指標是明確的工程里你面對的是用戶隨手輸入的錯別字、格式混亂的 PDF、前后矛盾的對話歷史、以及老板明天就要看 demo 的壓力。我見過一個團隊嚴格按照某篇論文的方法做了一套多輪對話系統(tǒng)在公開數(shù)據(jù)集上指標很好看但一上線就崩。原因很簡單論文里的對話歷史是人工構造的而真實用戶的對話是跳躍的、省略的、帶情緒的。用戶說“那個東西再便宜點”系統(tǒng)根本不知道“那個東西”指什么。這就是典型的用論文思維做工程忽略了真實場景的復雜性。反本本主義的做法是把論文當靈感來源不當施工圖紙。看到一篇好論文先問自己三個問題它的假設在我的場景里成立嗎它的方法我能用現(xiàn)有資源復現(xiàn)嗎它的收益值得我投入的成本嗎三個問題有一個答不上來就先放一放。2.3 框架崇拜與“一鍵式”幻覺現(xiàn)在很多 AI 開發(fā)框架都宣傳“幾行代碼搞定一個 Agent”“拖拽式搭建智能體”。這當然降低了門檻但也制造了一種幻覺好像 AI 開發(fā)就是調(diào) API、拼組件。實際上框架幫你處理的是“標準情況”而真實項目里全是“非標準情況”。模型突然返回空結果怎么辦工具調(diào)用超時怎么辦用戶輸入觸發(fā)了安全策略怎么辦這些框架文檔里往往一筆帶過但卻是你每天都要面對的。我的經(jīng)驗是可以用框架但必須理解框架替你做了什么。至少要知道它的核心流程、關鍵參數(shù)、失敗模式。否則一旦出問題你連排查的方向都沒有。比如用某個 Agent 框架時我習慣先把它的執(zhí)行鏈路打日志看清楚每一步的輸入輸出這樣出問題時能快速定位是模型的問題、工具的問題、還是編排邏輯的問題。3. 反本本主義的 AI 開發(fā)核心原則3.1 原則一先跑通最小閉環(huán)再談優(yōu)化這是我最想強調(diào)的一條。很多項目失敗不是因為技術不夠先進而是因為一開始就想做“完整版”。完整版意味著你要同時處理數(shù)據(jù)清洗、模型選型、Prompt 設計、工具集成、前端展示、權限管理……任何一個環(huán)節(jié)卡住整個項目就停擺。正確的做法是用最短路徑跑通一個端到端的最小閉環(huán)。比如你要做一個 AI 客服最小閉環(huán)可以是用戶輸入問題 → 直接調(diào)模型 → 返回答案。先不管知識庫、不管多輪、不管兜底。跑通之后你至少知道模型能不能用、響應速度能不能接受、成本大概多少。然后在這個基礎上一步步加檢索、加歷史、加審核。我自己的習慣是任何新項目第一周只做一件事讓數(shù)據(jù)從輸入流到輸出中間哪怕全是硬編碼都行。這個閉環(huán)跑通了心里就有底了后面所有的優(yōu)化都是在這個骨架上長肉。3.2 原則二用真實數(shù)據(jù)驅(qū)動決策而不是用直覺AI 開發(fā)里最容易犯的錯就是憑直覺調(diào)參。覺得溫度調(diào)低一點會更穩(wěn)定覺得切塊大一點會保留更多上下文覺得換個更大的模型效果會更好。這些直覺有時候?qū)τ袝r候錯但你如果不做對比實驗永遠不知道。我的做法是建一個最小評測集每次改動都跑一遍。這個評測集不需要很大二三十條真實用戶問題就夠。關鍵是要覆蓋典型場景和邊界情況。比如做文檔問答評測集里要有直接能查到答案的、需要跨段落推理的、文檔里根本沒有答案的、問題本身有歧義的。每次改 Prompt、換模型、調(diào)參數(shù)都拿這個集子跑一遍看準確率、看響應時間、看成本。數(shù)據(jù)說話比拍腦袋靠譜得多。這里有個細節(jié)評測集的答案不要只標“對/錯”最好標出“錯在哪里”。是檢索沒召回是模型理解錯了還是答案格式不對這樣你才知道下一步該優(yōu)化哪個環(huán)節(jié)。3.3 原則三把不確定性當作設計輸入而不是異常傳統(tǒng)軟件開發(fā)里我們習慣“輸入確定 → 處理確定 → 輸出確定”。AI 開發(fā)里這個鏈條中間那環(huán)是概率性的。同樣的輸入模型可能給出不同的輸出。這不是 bug是特性。你不能指望它像傳統(tǒng)函數(shù)一樣穩(wěn)定但你可以通過設計來管理這種不確定性。具體怎么做幾個實用手段結構化輸出約束讓模型按 JSON 格式返回方便程序解析多路投票同一個問題跑三次取多數(shù)一致的結果置信度過濾讓模型自己評估答案可靠性低于閾值就轉(zhuǎn)人工兜底策略模型答不上來時有預設的回復。這些手段不能消除不確定性但能把不確定性控制在可接受的范圍內(nèi)。我特別想說的是不要試圖用 Prompt 去“根治”模型的不穩(wěn)定。你寫再多“你必須”“你一定要”模型該飄還是飄。真正有效的是在系統(tǒng)層面做約束把模型的輸出當作一個“需要校驗的輸入”來處理。3.4 原則四迭代速度比單次質(zhì)量更重要AI 項目的質(zhì)量不是一次做出來的是迭代出來的。你第一版的 Prompt 可能只有 60 分但如果你能一天迭代三次一周后就能到 85 分。反過來如果你花兩周憋一個“完美方案”上線后發(fā)現(xiàn)方向錯了損失更大。所以我在團隊里推行的做法是縮短反饋周期。能今天上線的就不拖到明天能小范圍試的就不要全量推。每次迭代只改一個變量改完立刻看數(shù)據(jù)。這樣你才能建立起“改動 → 效果”的因果認知。如果一次改五個地方效果好了你不知道是哪個起作用效果差了也不知道該回退哪個。4. 實操一個反本本主義的 AI 應用開發(fā)流程4.1 第一步把需求翻譯成可驗證的問題很多 AI 項目的需求描述是模糊的“做一個智能助手”“提升用戶體驗”“實現(xiàn)自動化”。這種描述沒法直接開發(fā)。你需要把它翻譯成可驗證的問題用戶會在什么場景下使用輸入大概長什么樣期望的輸出是什么格式成功的標準是什么舉個例子“做一個 AI 旅游助手”這個需求翻譯之后可能是用戶輸入“幫我規(guī)劃一個三天的北京行程”系統(tǒng)輸出一個包含景點、交通、餐飲建議的結構化行程要求景點不重復、每天不超過三個、總預算在兩千以內(nèi)。這樣你才知道要做什么、怎么測。這一步最容易被跳過但恰恰最重要。我見過太多項目做到一半發(fā)現(xiàn)大家對“做好”的定義不一樣返工成本極高。4.2 第二步用最笨的方法先跑通需求明確后不要急著選框架、搭架構。先用最笨的方法跑通直接調(diào)模型 API把輸入拼成 Prompt把輸出打印出來?？纯茨Ｐ湍懿荒芾斫馊蝿铡⑤敵鲑|(zhì)量如何、有沒有明顯的坑。這個階段我通常只寫幾十行代碼甚至直接在 Playground 里試。目的是快速建立對模型能力的直覺。比如你會發(fā)現(xiàn)模型對格式要求很敏感你不明確說“用 JSON 返回”它就會給你一段散文你說了 JSON它有時候還會加個“好的以下是結果”的前綴。這些細節(jié)只有親手試過才知道。4.3 第三步識別瓶頸逐個擊破最小閉環(huán)跑通后你會看到明顯的瓶頸?？赡苁悄Ｐ椭R不夠需要 RAG可能是輸出格式不穩(wěn)需要結構化約束可能是多輪對話記不住上下文需要歷史管理可能是響應太慢需要流式輸出或緩存。這時候再針對性地引入技術方案。注意是“針對性”不是“全面性”。哪個環(huán)節(jié)弱就補哪個不要一次性把所有高級技術都堆上去。每加一個組件都要問它解決了什么問題帶來了什么新問題成本增加了多少4.4 第四步建立評測與監(jiān)控上線不是終點是起點。你需要一套機制來持續(xù)觀察系統(tǒng)表現(xiàn)用戶滿意度、答案準確率、響應時間、異常率。這些數(shù)據(jù)會告訴你下一步該優(yōu)化什么。評測集要持續(xù)更新把線上發(fā)現(xiàn)的 bad case 加進去。監(jiān)控要能定位問題最好能追溯到具體的請求鏈路。我習慣在關鍵節(jié)點打日志用戶輸入、檢索結果、模型輸出、最終返回。這樣出問題時能快速復現(xiàn)和排查。5. 常見問題與排查技巧實錄5.1 模型輸出格式不穩(wěn)定怎么辦這是最高頻的問題。你要求 JSON它給你 Markdown你要求簡潔它給你長篇大論。排查思路先看 Prompt 里有沒有明確的格式示例最好給一個完整的輸入輸出樣例再看溫度參數(shù)是不是太高結構化任務建議調(diào)到 0 到 0.3如果還不行就在代碼層面做后處理用正則提取關鍵字段提取失敗就重試或走兜底。我實測下來給樣例比給規(guī)則更有效。你寫“請用 JSON 格式返回”不如直接寫“輸入xxx輸出{name: xxx, age: 20}”。模型對示例的模仿能力很強。5.2 檢索召回不準怎么調(diào)RAG 場景里召回不準通常有三個原因切塊太大或太小、向量模型不適合中文、查詢和文檔的語義空間不匹配。排查順序先看切塊一般中文文檔 300 到 500 字一塊比較合適太大噪音多太小上下文斷再看向量模型中文場景建議用專門的中文模型或 multilingual 模型最后看查詢用戶的問題往往很短可以先用模型做一次查詢改寫再拿去檢索。還有個容易被忽略的點文檔預處理。PDF 里的表格、頁眉頁腳、亂碼如果不清理會嚴重干擾檢索。我一般會先做一輪清洗把明顯無意義的字符去掉。5.3 Agent 工具調(diào)用失敗怎么排查Agent 調(diào)工具失敗常見原因有工具描述不清楚模型不知道什么時候該調(diào)參數(shù)格式不對模型傳的參數(shù)和工具要求的不匹配工具本身超時或報錯但 Agent 沒有正確處理。排查時先把 Agent 的完整執(zhí)行鏈路打出來看模型決定調(diào)哪個工具、傳了什么參數(shù)、工具返回了什么。大部分問題出在工具描述上。我的經(jīng)驗是工具描述要寫得像給新人看的文檔這個工具是干什么的、什么時候用、參數(shù)是什么格式、返回什么。越具體模型調(diào)用越準。5.4 常見問題速查表問題現(xiàn)象可能原因排查方向解決手段輸出格式亂Prompt 缺示例、溫度高檢查 Prompt 和溫度參數(shù)加示例、降溫度、后處理檢索不準切塊不當、向量模型不匹配檢查切塊大小和模型調(diào)整切塊、換模型、查詢改寫工具調(diào)用失敗工具描述不清、參數(shù)不匹配打印執(zhí)行鏈路完善描述、加參數(shù)校驗響應太慢模型太大、無緩存、串行調(diào)用看耗時分布換小模型、加緩存、并行化多輪丟上下文歷史管理不當檢查歷史拼接邏輯限制輪數(shù)、做摘要壓縮成本過高模型選型不當、重復調(diào)用統(tǒng)計 token 消耗換模型、加緩存、批處理5.5 幾個獨家避坑技巧第一不要在生產(chǎn)環(huán)境直接用最新模型。新模型往往有未知的坑先在小流量上試穩(wěn)定了再切。第二Prompt 要版本管理。每次改動都記錄出問題能回滾。第三給模型留退路。設計 Prompt 時就想好“如果模型答不上來怎么辦”預設兜底話術。第四不要迷信大模型。很多任務小模型加好的 Prompt 就能做成本低、速度快。第五日志要打全。AI 系統(tǒng)的問題往往難以復現(xiàn)日志是你唯一的線索。6. 工具選型與團隊協(xié)作的反本本主義6.1 工具選型適合的比先進的更重要AI 開發(fā)工具鏈更新極快今天流行的框架明天可能就沒人維護了。選型時不要只看 star 數(shù)和技術先進性要看社區(qū)是否活躍、文檔是否完整、出問題能不能找到人問、是否容易替換。我傾向于選那些“薄封裝”的工具它們不會把你鎖死出問題也容易排查。比如做 Agent 開發(fā)有的框架封裝得很重你只需要配置幾個組件就能跑但一旦行為不符合預期你很難干預。有的框架比較輕你需要自己寫編排邏輯但每一步都可控。我一般選后者因為 AI 系統(tǒng)的不確定性太高可控性比開發(fā)效率更重要。6.2 團隊協(xié)作打破“算法”和“工程”的墻AI 項目最容易出現(xiàn)的問題是算法和工程脫節(jié)。算法同學調(diào)出一個模型工程同學不知道怎么集成工程同學搭好服務算法同學發(fā)現(xiàn)線上數(shù)據(jù)和訓練數(shù)據(jù)分布不一樣。反本本主義的做法是讓算法和工程坐在一起從第一天就共同定義接口和數(shù)據(jù)格式。我推行的做法是算法同學要能跑通工程的部署流程工程同學要能看懂算法的評測報告。大家用同一套評測集、同一套日志、同一套指標。這樣出了問題不會互相甩鍋而是一起看數(shù)據(jù)、找原因。6.3 學習路線以項目為綱缺什么補什么最后說說學習。網(wǎng)上有很多“AI 應用開發(fā)學習路線”從數(shù)學基礎到深度學習到到大模型到到應用開發(fā)列了幾十個知識點。如果你按這個學兩年都學不完。我的建議是以項目為綱缺什么補什么。你想做 RAG就去學檢索和向量你想做 Agent就去學工具調(diào)用和編排你想做微調(diào)就去學數(shù)據(jù)構造和訓練。學的時候帶著問題學效率比系統(tǒng)學習高得多。而且AI 這個領域很多知識是“用進廢退”的。你學了一個技術如果三個月不用基本就忘了。所以不要囤積知識要用的時候再學學了立刻用。7. 我個人的幾點體會做 AI 開發(fā)這幾年我最大的體會是這個領域沒有標準答案只有適合當前場景的答案。別人的最佳實踐到你這里可能就是最差實踐。所以不要迷信任何權威包括我上面說的這些。你要做的是理解背后的邏輯然后根據(jù)自己的數(shù)據(jù)、場景、資源去調(diào)整。第二個體會是快速失敗比緩慢成功更有價值。一個方案不行早點知道早點換方向。最怕的是在一個錯誤的方向上投入太多舍不得放棄。AI 項目的不確定性很高試錯是常態(tài)關鍵是要控制試錯成本。第三個體會是保持手感比積累知識更重要。AI 開發(fā)很像手藝活你需要持續(xù)動手才能保持對模型行為的敏感度。我即使不做新項目也會定期拿一些新模型、新工具來試看看它們能做什么、不能做什么。這種手感是看文章看不來的。最后分享一個小技巧每次遇到模型輸出不符合預期先不要改 Prompt先問自己“如果我是模型看到這個輸入我會怎么理解”。很多時候問題不在模型而在你的輸入本身就有歧義。把輸入改清楚比在 Prompt 里加十句“你必須”都管用。這個思路其實也是反本本主義的精髓不要從規(guī)則出發(fā)要從實際情況出發(fā)。