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