先聊個(gè)很多人都會(huì)問的問題AI 工程AI Engineering到底是不是個(gè)“新瓶裝舊酒”的概念我自己的判斷是它不是。早幾年我們講機(jī)器學(xué)習(xí)、深度學(xué)習(xí)重心大多放在模型訓(xùn)練——調(diào)參、刷榜誰(shuí) AUC 高誰(shuí)厲害。但到了今天一個(gè)模型能不能真正落地、能不能持續(xù)穩(wěn)定地服務(wù)業(yè)務(wù)靠的遠(yuǎn)不只是訓(xùn)練。數(shù)據(jù)怎么管、特征怎么算、模型怎么部署、上線之后怎么監(jiān)控、效果變差了怎么撈回來這些環(huán)節(jié)加在一起才是完整閉環(huán)。而這個(gè)整體能力就是 AI 工程。幾年前沒有人給你規(guī)劃好這條路網(wǎng)上資料要么偏算法理論要么偏純后端能把這整條鏈路串起來講的極少。這個(gè)“ai-engineering-from-scratch”要解決的就是這個(gè)痛點(diǎn)從頭梳理 AI 工程到底學(xué)什么、做什么、怎么一步步做成適合剛?cè)腴T想走 AI 工程方向的同學(xué)也適合已經(jīng)在做后端或算法、想補(bǔ)齊工程能力的人。下文就是我從零到一完整跑通這個(gè)體系的實(shí)戰(zhàn)筆記純干貨不繞彎。1. AI 工程到底是什么為什么值得從頭搭建1.1 先搞清楚 AI 工程和傳統(tǒng)軟件工程的區(qū)別很多人第一次聽說 AI 工程下意識(shí)會(huì)把它理解成“會(huì)寫 Python 調(diào)模型”。如果只是這樣那和算法工程師有什么區(qū)別行業(yè)里現(xiàn)在普遍接受的一種定義是AI 工程是面向 AI 應(yīng)用的軟件工程實(shí)踐它把模型當(dāng)作系統(tǒng)的一個(gè)組件而不是全部。換句話說AI 工程師的職責(zé)是讓 AI 能力以穩(wěn)定、可維護(hù)、可擴(kuò)展的方式嵌入業(yè)務(wù)。對(duì)比傳統(tǒng)軟件工程最核心的區(qū)別有兩個(gè)。第一傳統(tǒng)軟件的邏輯是確定性優(yōu)先——輸入 A輸出 B行為可預(yù)期。模型的邏輯是概率性的——同一個(gè) prompt 或者同一批特征結(jié)果可能有波動(dòng)。所以工程上必須增加一層兜底和校驗(yàn)比如閾值判斷、降級(jí)方案、結(jié)果合理性檢查。第二傳統(tǒng)軟件的生命周期里測(cè)試數(shù)據(jù)和真實(shí)數(shù)據(jù)分布通常一致模型應(yīng)用則經(jīng)常出現(xiàn)“離線效果好、線上效果崩”的窘境。數(shù)據(jù)分布漂移這個(gè)變量傳統(tǒng)軟件工程師幾乎不需要考慮但對(duì) AI 工程來說是家常便飯。所以 AI 工程不是算法工程師的“下位替代”也不是普通后端的“加個(gè)模型接口”。它是一個(gè)更綜合的位置既要懂模型的基本工作原理又得具備軟件工程的紀(jì)律性還得有數(shù)據(jù)敏感度。這也是為什么業(yè)界常說“AI 工程師是 transformer 時(shí)代的全棧工程師”——不是說你什么都會(huì)而是說你需要具備跨層協(xié)調(diào)能力。1.2 從零搭建的必要性不經(jīng)歷底層談何上層這輪大模型浪潮帶來了很多“低門檻”工具比如封裝好的 SDK、托管服務(wù)、微調(diào)平臺(tái)。我舉雙手贊成用工具提效但我強(qiáng)烈不建議一上來就直接懟高層服務(wù)。理由很簡(jiǎn)單你不親手跑一遍訓(xùn)練、評(píng)估、部署、監(jiān)控的完整流程你根本不知道哪個(gè)環(huán)節(jié)會(huì)出問題出了問題也不知道該看哪里。舉個(gè)很典型的例子。有人用了托管的模型 API 做問答應(yīng)用線上反饋偶爾出現(xiàn)胡說八道的情況。他第一反應(yīng)是換個(gè)更強(qiáng)的模型結(jié)果換了還是有問題。后來排查才發(fā)現(xiàn)問題出在他處理用戶輸入時(shí)把一些關(guān)鍵上下文截?cái)嗔四Ｐ透緵]拿到足夠信息。這個(gè)錯(cuò)如果他自己寫過完整的 RAG 鏈路一眼就能定位但如果他只接觸過 API 調(diào)用就很容易在“模型不行”的錯(cuò)誤方向上反復(fù)內(nèi)耗。這就是 from scratch 的核心價(jià)值不是為了復(fù)古是為了建立“故障直覺”。你親手寫過數(shù)據(jù)處理腳本才知道臟數(shù)據(jù)長(zhǎng)什么樣自己部署過推理服務(wù)才知道延遲瓶頸往往卡在序列化和網(wǎng)絡(luò)傳輸上自己寫過評(píng)估腳本才明白人工評(píng)測(cè)在真實(shí)場(chǎng)景里有多不可靠。這些認(rèn)知是任何工具替代不了的。2. 核心能力地圖先畫清楚要學(xué)什么再動(dòng)手2.1 技術(shù)棧全景從底到頂?shù)牧鶄€(gè)層次真要系統(tǒng)學(xué)習(xí) AI 工程我建議把它拆成六層來看每一層都有明確的交付物和驗(yàn)收標(biāo)準(zhǔn)。這樣學(xué)起來不會(huì)迷失方向因?yàn)槊恳粚佣伎梢詥为?dú)驗(yàn)證。第一層是編程基礎(chǔ)與工程素養(yǎng)以 Python 為主必須熟悉面向?qū)ο?、類型注解、虛擬環(huán)境、git 工作流。第二層是數(shù)學(xué)與機(jī)器學(xué)習(xí)基礎(chǔ)重點(diǎn)不是推導(dǎo)公式而是要理解損失函數(shù)、梯度下降、過擬合、評(píng)估指標(biāo)這些概念背后的直覺。第三層是深度學(xué)習(xí)框架PyTorch 為主要做到能自己寫訓(xùn)練循環(huán)、自定義數(shù)據(jù)集、斷點(diǎn)續(xù)訓(xùn)。第四層是模型應(yīng)用與微調(diào)包括預(yù)訓(xùn)練模型的加載、prompt 工程、指令微調(diào)、參數(shù)高效微調(diào)。第五層是推理與部署包括模型量化、服務(wù)化、容器化、GPU 資源管理。第六層是數(shù)據(jù)與評(píng)估體系包括數(shù)據(jù)清洗、標(biāo)注規(guī)范、離線評(píng)估、線上監(jiān)控。很多人會(huì)問數(shù)學(xué)到底要學(xué)到什么程度我的建議是你不需要會(huì)推導(dǎo) transformer 的全部公式但必須理解以下幾個(gè)概念向量與矩陣乘法做 attention 時(shí)能跟上、概率分布理解困惑度和采樣、損失函數(shù)與梯度理解訓(xùn)練和過擬合、以及統(tǒng)計(jì)顯著性理解 A/B 實(shí)驗(yàn)。到這一步就夠支撐任何工程決策。2.2 關(guān)鍵思維轉(zhuǎn)變從“模型優(yōu)先”到“系統(tǒng)優(yōu)先”真正動(dòng)手做項(xiàng)目之后我發(fā)現(xiàn)初學(xué)者最容易卡住的不是技術(shù)而是思維。算法背景的人容易困在“我要把模型效果調(diào)到最好”這個(gè)單點(diǎn)目標(biāo)里后端背景的人容易困在“接口能用就行”的功能交付里。AI 工程要求的是一種系統(tǒng)思維你需要在效果、成本、延遲、可維護(hù)性之間做權(quán)衡。舉個(gè)真實(shí)例子。在公司做智能客服的過程中我們?cè)u(píng)估過兩個(gè)方案一個(gè)是直接調(diào)用商用大模型 APIanswer 質(zhì)量高但每次調(diào)用成本高延遲波動(dòng)大另一個(gè)是用小模型加本地知識(shí)庫(kù)answer 質(zhì)量略低但成本幾乎為零延遲穩(wěn)定在 100ms 內(nèi)。單看模型效果方案一完勝但放到真實(shí)業(yè)務(wù)里客服系統(tǒng)日均調(diào)用量幾十萬(wàn)次成本差是數(shù)量級(jí)的而且延遲一高用戶立刻感知到頁(yè)面卡頓。最終我們選了方案二再用 prompt 優(yōu)化和意圖識(shí)別兜底把質(zhì)量差距壓縮到可接受范圍。這就是“系統(tǒng)優(yōu)先”的典型決策過程。在你的第一個(gè)項(xiàng)目里就要有意識(shí)地去記錄和權(quán)衡這類指標(biāo)而不是只盯著 accuracy 或者 BLEU。這個(gè)習(xí)慣越早建立后面做真實(shí)項(xiàng)目時(shí)越不吃虧。3. 從零到一實(shí)操搭建一個(gè)完整的 AI 工程小項(xiàng)目3.1 項(xiàng)目選型為什么是“本地知識(shí)庫(kù)問答”前面講了一堆理念下面我們用一個(gè)小項(xiàng)目把這些串起來構(gòu)建一個(gè)基于本地知識(shí)庫(kù)的問答系統(tǒng)。這個(gè)項(xiàng)目非常適合入門原因有三個(gè)。第一它覆蓋了完整鏈路——數(shù)據(jù)處理、向量化、檢索、模型生成、服務(wù)封裝、評(píng)估一個(gè)都不少。第二它不需要昂貴資源本地 CPU 也能跑。第三它非常貼近企業(yè)真實(shí)需求你做完之后能直接講出這個(gè)故事的價(jià)值。整體架構(gòu)分成五塊知識(shí)庫(kù)文檔解析、文本切分、向量化與存儲(chǔ)、檢索、生成回答。對(duì)應(yīng)的技術(shù)棧我分別選了python-docx 和 pypdf 做文檔解析RecursiveCharacterTextSplitter 做文本切分text2vec-base-chinese 或 bge-small-zh 做向量化FAISS 做向量存儲(chǔ)和檢索最后用 ChatGLM 或 Qwen 等開源模型做生成。你可能會(huì)問為什么不上 RAG 框架比如 LangChain、LlamaIndex不是不能而是我先建議你手工過一遍。手寫過一遍之后你才能深刻理解哪些步驟耗時(shí)、哪些參數(shù)影響大、哪些環(huán)節(jié)容易出問題。之后再上框架你才算是在用框架而不是被框架用。3.2 步驟一文檔解析與文本切分第一步是準(zhǔn)備幾份產(chǎn)品說明文檔比如把公司的某產(chǎn)品手冊(cè)導(dǎo)出成 PDF 和 Word 兩種格式。這時(shí)候你立刻會(huì)遇到第一個(gè)工程問題PDF 解析出來的文本經(jīng)常帶亂碼、多余換行和頁(yè)碼信息。我的處理流程是這樣先寫一個(gè)解析函數(shù)從不同文件類型抽取純文本再寫一個(gè)清洗函數(shù)統(tǒng)一做去特殊符號(hào)、合并斷行、去空白字符最后打印前 500 字符做目檢。注意這一步千萬(wàn)不能省因?yàn)楹罄m(xù)文本切分和向量化的質(zhì)量完全取決于這一步。文本切分是個(gè)容易被忽略但極其關(guān)鍵的環(huán)節(jié)。切太短語(yǔ)義不完整檢索時(shí)噪聲很大切太長(zhǎng)向量表示被稀釋而且超出 embedding 模型的最大輸入長(zhǎng)度。實(shí)踐經(jīng)驗(yàn)是先用 200 到 500 字作為初始窗口大小重疊 50 到 100 字。這里的“重疊”是為了保證跨段落的語(yǔ)義不斷裂。修改切分參數(shù)之后一定要抽樣檢查切分結(jié)果我在實(shí)際項(xiàng)目里發(fā)現(xiàn)過切出來的文本是一半表格一半正文的情況這種質(zhì)量是沒法檢索的。3.3 步驟二向量化與檢索實(shí)現(xiàn)接下來是向量化。小規(guī)模場(chǎng)景直接用 CPU 跑 text2vec 或者 bge 就夠。關(guān)鍵點(diǎn)有三個(gè)第一模型要統(tǒng)一查詢和文檔必須用同一個(gè) embedding 模型否則向量空間不一致第二文本要?dú)w一化超長(zhǎng)文本截?cái)?、空文本過濾第三向量要?dú)w一化余弦相似度才能正確計(jì)算。存儲(chǔ)我建議先用 FAISS本地文件存儲(chǔ)即可。你只存兩樣?xùn)|西原始文本和向量。入庫(kù)前還要維護(hù)一個(gè) id 映射方便后續(xù)檢索返回原文本。檢索邏輯看起來簡(jiǎn)單——對(duì) query 做向量化然后查 top-k——但實(shí)際有幾個(gè)坑。第一個(gè)坑是混合檢索單靠向量檢索遇到專業(yè)術(shù)語(yǔ)或縮寫時(shí)容易召回不準(zhǔn)確。實(shí)操解法是疊加 BM25 關(guān)鍵詞檢索用加權(quán)融合的方式綜合排序。第二個(gè)坑是重排序rerank初篩 top 50再精排成 top 5效果提升非常明顯。第三個(gè)坑是閾值過濾即使相關(guān)性分?jǐn)?shù)不高系統(tǒng)也會(huì)硬返回結(jié)果導(dǎo)致答非所問。正確做法是設(shè)定一個(gè)最低相似度閾值低于閾值就返回“知識(shí)庫(kù)中未找到相關(guān)信息”。3.4 步驟三生成回答與 Prompt 設(shè)計(jì)生成階段的關(guān)鍵是寫好系統(tǒng)提示詞system prompt。這里的經(jīng)驗(yàn)法則是先給角色定位再給任務(wù)約束再給知識(shí)上下文最后給回答格式。以一個(gè)實(shí)際模板為例我的提示詞是“你是企業(yè)智能助理。請(qǐng)只依據(jù)提供的知識(shí)片段回答用戶問題每句話都需要有依據(jù)如果知識(shí)片段中不含所需信息請(qǐng)直接說明不知道不要編造?；卮鹂刂圃?5 條要點(diǎn)以內(nèi)。知識(shí)片段如下xxx。用戶問題xxx”。這個(gè)模板里有幾個(gè)值得注意的細(xì)節(jié)。第一“每句話都需要有依據(jù)”這句話能顯著減少幻覺因?yàn)槟Ｐ捅灰髮?duì)自己生成的內(nèi)容進(jìn)行隱含的“溯源”檢查。第二“不要編造”比“如實(shí)回答”更直接行為約束更明確。第三限制答案長(zhǎng)度可以避免模型堆砌冗長(zhǎng)文本。第四把知識(shí)片段放在用戶問題之前讓注意力機(jī)制在推理時(shí)更聚焦于知識(shí)內(nèi)容。這些都是低成本高收益的優(yōu)化建議直接抄。3.5 步驟四把服務(wù)封裝成可調(diào)用接口一個(gè)可交付的系統(tǒng)最終要變成服務(wù)。我選擇的是 FastAPI理由很簡(jiǎn)單自帶 OpenAPI 文檔、異步支持、Pydantic 校驗(yàn)、部署方便。你需要構(gòu)建兩個(gè)接口一個(gè)負(fù)責(zé)寫入知識(shí)數(shù)據(jù)入庫(kù)一個(gè)負(fù)責(zé)查詢問答query 進(jìn)來、answer 出去。接口設(shè)計(jì)有幾個(gè)工程細(xì)節(jié)。第一個(gè)是統(tǒng)一響應(yīng)結(jié)構(gòu)比如 {“code”: 0, “data”: {...}}不要讓前端同學(xué)猜你的字段。第二個(gè)是超時(shí)控制模型推理可能很慢必須設(shè)置合理的請(qǐng)求超時(shí)避免連接堆積。第三個(gè)是并發(fā)控制本地小模型在同一時(shí)間只能處理少量請(qǐng)求可以用 Semaphore 限制并發(fā)數(shù)收到超過負(fù)荷的請(qǐng)求時(shí)直接返回 503 提示稍后重試而不是拖死進(jìn)程。我在這步踩過一個(gè)很深的坑第一次部署用的是同步阻塞方式結(jié)果兩個(gè)人同時(shí)提問時(shí)第二個(gè)人硬生生等了 30 秒。理論上模型推理本來就慢但是用異步代理把模型推理放到一個(gè)線程池里之后至少能讓其他請(qǐng)求先響應(yīng)起來體感好了很多。這個(gè)優(yōu)化很小但是系統(tǒng)穩(wěn)定性的關(guān)鍵。4. 評(píng)估體系你做的系統(tǒng)好不好要用數(shù)據(jù)說話4.1 離線評(píng)估別只看準(zhǔn)確率要看細(xì)粒度很多初學(xué)者做 RAG 系統(tǒng)評(píng)估的時(shí)候只會(huì)看“幾道題答對(duì)了幾道”然后報(bào)告一個(gè)準(zhǔn)確率。這在真實(shí)項(xiàng)目里遠(yuǎn)遠(yuǎn)不夠。我建議建立三套評(píng)估維度檢索質(zhì)量、生成質(zhì)量、端到端質(zhì)量。檢索質(zhì)量用 Recallk 和 MRR。簡(jiǎn)單理解就是正確答案是否出現(xiàn)在檢索返回的前 k 條里排得靠不靠前這個(gè)指標(biāo)能獨(dú)立驗(yàn)證你的 embedding 選擇和切分策略。生成質(zhì)量用 faithfulness 和 answer relevance。Faithfulness 檢查生成內(nèi)容是否有知識(shí)庫(kù)依據(jù)相關(guān)性檢查回答是否契合問題。這兩個(gè)指標(biāo)在生成式模型上比準(zhǔn)確率更有意義因?yàn)樗鼈兡茏プ　按鸱撬鶈枴焙汀昂巵y造”這兩類高頻問題。最實(shí)用的做法是準(zhǔn)備 50 條覆蓋不同難度的測(cè)試問題逐條手動(dòng)打分并記錄錯(cuò)誤類型。每次改動(dòng)系統(tǒng)比如換了切割參數(shù)、換了 embedding 模型、改了 prompt都用同一套測(cè)試集重新評(píng)估用得分變化來指導(dǎo)決策。沒有這套基線你后面做的“優(yōu)化”全是拍腦袋。4.2 線上監(jiān)控讓問題在產(chǎn)品化之前暴露離線評(píng)估做得再好線上也會(huì)出現(xiàn)新問題比如用戶問了知識(shí)庫(kù)里沒有的東西、用戶輸入里帶錯(cuò)別字、知識(shí)庫(kù)文檔更新后沒有同步向量庫(kù)。我建議至少做三層的線上日志監(jiān)控。第一層是請(qǐng)求日志記錄 query、檢索結(jié)果、最終回答、延遲和 token 消耗。第二層是效果評(píng)價(jià)定期抽檢日志讓業(yè)務(wù)人員給回答打標(biāo)簽統(tǒng)計(jì)“優(yōu)質(zhì)回答率”。第三層是數(shù)據(jù)漂移監(jiān)控統(tǒng)計(jì)新 query 和知識(shí)庫(kù)的相似度分布如果相似度持續(xù)降低說明用戶的問法在變可能需要更新知識(shí)庫(kù)。在 Python 中做好這兩類監(jiān)控套路已經(jīng)相對(duì)成熟日志直接輸出到 JSON Lines 文件再定時(shí)用腳本聚合統(tǒng)計(jì)指標(biāo)按天歸檔做成最簡(jiǎn)單的小報(bào)表。早期項(xiàng)目不需要復(fù)雜監(jiān)控平臺(tái)先把數(shù)據(jù)和工具鏈搭好后面自然知道怎么擴(kuò)展。5. 常見問題與排查方向速查做這個(gè)項(xiàng)目時(shí)我一邊寫代碼一邊記錄了踩坑日志最終積累了下面這份排查速查表。如果你在做同類項(xiàng)目時(shí)遇到問題可以直接對(duì)照定位。癥狀大概率原因排查方向檢索結(jié)果驢唇不對(duì)馬嘴切分單位過大/過小或 embedding 模型與查詢不匹配檢查切分文本確認(rèn)查詢和文檔使用同一向量模型回答總是“不知道”檢索到的知識(shí)片段與問題無關(guān)降低 top-k 閾值檢查重排序邏輯查看檢索片段原文回答出現(xiàn)幻覺內(nèi)容prompt 約束不足檢索片段為空時(shí)仍硬答強(qiáng)化 prompt 行為約束加入相似度閾值邏輯知識(shí)片段為空時(shí)直接拒答服務(wù)延遲很高模型無并發(fā)控制序列化影響CPU 推理增加緩存批量加載模型并發(fā)信號(hào)量量化模型用戶輸入稍變就答不出來依賴單路檢索增加同義詞改寫、拼寫糾錯(cuò)或混合檢索策略知識(shí)庫(kù)更新后系統(tǒng)不生效增量更新未實(shí)現(xiàn)檢查新增文檔是否寫入向量庫(kù)冪等性校驗(yàn)顯存/內(nèi)存持續(xù)增長(zhǎng)推理框架緩存未釋放定期加載測(cè)試用對(duì)象復(fù)用替代頻繁創(chuàng)建模型對(duì)象prompt 改了但效果沒變化緩存命中舊答案檢查緩存 key 是否包含 prompt 版本號(hào)上面這張表是我最常用的排查起點(diǎn)。現(xiàn)實(shí)中的問題往往不是單點(diǎn)故障而是鏈路多個(gè)環(huán)節(jié)疊加因此排查時(shí)要按“數(shù)據(jù) → 檢索 → prompt → 生成 → 部署”這條鏈路逐層過別一上來就懷疑模型。6. 下一步怎么往深處走6.1 從 MVP 到可用的系統(tǒng)還需要補(bǔ)什么手工搭建完基礎(chǔ)知識(shí)庫(kù)問答之后下一步我會(huì)按優(yōu)先級(jí)補(bǔ)三塊工程能力。第一塊是自動(dòng)化評(píng)測(cè)流水線把 4.1 節(jié)里那套離線評(píng)估腳本接入 CI/CD每次改代碼自動(dòng)跑一遍回歸測(cè)試避免“改壞了一處過了兩周才發(fā)現(xiàn)”。第二塊是知識(shí)庫(kù)管理后臺(tái)支持批量上傳文檔、增量更新向量庫(kù)、人工修正錯(cuò)誤回答并反饋到知識(shí)庫(kù)。第三塊是多路召回的進(jìn)一步升級(jí)比如引入意圖識(shí)別、FAQ 精確匹配、甚至多跳檢索來處理更復(fù)雜的問題。這里插一句個(gè)人經(jīng)驗(yàn)很多項(xiàng)目死于“過度設(shè)計(jì)”。如果你只是做一個(gè) Demo不必一上來就上 Cranium 和龐大的 RAG 框架先把核心鏈路跑通再按真實(shí)數(shù)據(jù)暴露出的問題逐步迭代?？蚣苤皇鞘侄螁栴}才是引領(lǐng)者。6.2 技能棧的縱向延伸三條可選路線走完這個(gè)項(xiàng)目你已經(jīng)具備了 AI 工程的全鏈路基本盤。在此基礎(chǔ)上可以按職業(yè)興趣選擇縱向深入。第一條是算法縱深路線繼續(xù)深入模型訓(xùn)練學(xué)指令微調(diào)、強(qiáng)化學(xué)習(xí)、模型評(píng)估方法論、推理優(yōu)化。適合想走向算法專家路線的同學(xué)。第二條是工程縱深路線學(xué)更多性能優(yōu)化、分布式推理、GPU 調(diào)度、自動(dòng)擴(kuò)縮容和云原生部署走向平臺(tái)工程方向。第三條是數(shù)據(jù)縱深路線深耕數(shù)據(jù)質(zhì)量、標(biāo)注體系、數(shù)據(jù)版本管理、合成數(shù)據(jù)技術(shù)。大模型時(shí)代數(shù)據(jù)能力越來越值錢走這條路的人相對(duì)少但缺口很大。這幾條路線并不是互斥的。我的建議是先用主線打通全鏈路再用支線補(bǔ)強(qiáng)一兩個(gè)方向。AI 工程最忌諱的就是“啥都接觸啥都不精”。7. 一些實(shí)際的經(jīng)驗(yàn)體會(huì)最后聊幾句實(shí)在話。我見過很多人學(xué) AI 工程時(shí)最大的阻礙不是資料少而是“怕”字——怕數(shù)學(xué)看不懂怕環(huán)境配不好怕模型跑不起來。我的體會(huì)是大部分 AI 工程問題你動(dòng)手去碰它就已經(jīng)解決一半了。環(huán)境變量報(bào)錯(cuò)就一行行看模型推理慢就做性能分析數(shù)據(jù)臟就寫好清洗腳本這些東西沒有捷徑但都是確定性的只要人肯坐在那里逐步磨總能磨出來。另一個(gè)特別想說的點(diǎn)是要盡早養(yǎng)成把自己的過程沉淀成文檔和腳本的習(xí)慣。做這個(gè)項(xiàng)目時(shí)我記了一本“踩坑手冊(cè)”后來它直接變成了團(tuán)隊(duì)的新人培訓(xùn)材料。AI 工程里很多隱形知識(shí)是跑在空氣里的只存在于某個(gè)人的工作經(jīng)歷里你寫下來它才成為可復(fù)用的資產(chǎn)?，F(xiàn)在你手里的這份資料本質(zhì)上也是這么來的。我不建議你按部就班每一步都抄一遍而是帶著“如果這里出問題了會(huì)怎樣”的疑問去過代碼。跑通一遍之后再試著換一個(gè)領(lǐng)域的小項(xiàng)目比如做一個(gè)簡(jiǎn)歷匹配助手、做一個(gè)內(nèi)部信息檢索機(jī)器人。一個(gè)項(xiàng)目能讓你學(xué)會(huì)流程兩個(gè)不同領(lǐng)域的項(xiàng)目才能讓你學(xué)會(huì)遷移而遷移能力才是 AI 工程真正值錢的地方。