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