者轉(zhuǎn)型：從執(zhí)行者到問題定義者)
這幾天我一直在想一個采訪標(biāo)題“I feel like I dug my own grave”。一位在 AI 轉(zhuǎn)型浪潮中被邊緣化的技術(shù)工作者用這樣一句話形容自己的處境。這句話放在今天的開發(fā)者圈子里其實很有共鳴。過去幾年我們親手搭建自動化流水線、引入 AI 編程助手、推動團(tuán)隊流程標(biāo)準(zhǔn)化結(jié)果發(fā)現(xiàn)這些工作一邊在提升研發(fā)效率一邊也在壓縮“純執(zhí)行型人力”的生存空間。于是很多人開始問我是不是也在給自己挖坑本文不打算販賣焦慮也不想去討論“AI 會不會取代程序員”這種宏大的口號。我會從技術(shù)人的實際處境出發(fā)分析哪些能力正在被 AI 快速替代哪些能力反而是未來幾年最重要的護(hù)城河并且給出具體的技術(shù)學(xué)習(xí)路徑、代碼示例和工程建議。希望這篇文章能幫你從一個“AI 轉(zhuǎn)型中被影響的人”變成“主動使用 AI 解決問題的人”。1. AI 轉(zhuǎn)型焦慮的本質(zhì)那些“親手挖坑”的人在怕什么1.1 一個正在發(fā)生的現(xiàn)象體力型腦力勞動被壓縮先看一個很常見的場景。以前寫一個數(shù)據(jù)報表接口需要熟悉 SQL、熟悉業(yè)務(wù)表結(jié)構(gòu)、寫一堆 CRUD 代碼、再配合前端聯(lián)調(diào)?，F(xiàn)在呢AI 編程助手可以幾秒鐘生成一份可運(yùn)行的 CRUD 代碼甚至能直接根據(jù)數(shù)據(jù)庫 schema 生成查詢語句。團(tuán)隊里真正需要的是能說清楚“這個報表要看什么指標(biāo)、口徑怎么定義、數(shù)據(jù)怎么校驗”的人。這種現(xiàn)象可以概括為“體力型腦力勞動被壓縮”。所謂體力型腦力勞動是指那些流程明確、規(guī)則清晰、重復(fù)度高的腦力工作。比如根據(jù)接口文檔寫模板化代碼。把需求翻譯成 SQL 查詢。寫單元測試的重復(fù)骨架。處理格式固定的日志和配置文件。這些工作的共同點(diǎn)是你不需要做太多決策只需要按照既定規(guī)則執(zhí)行。而 AI 模型恰恰最擅長這類任務(wù)。1.2 焦慮的真正來源不是 AI而是工作結(jié)構(gòu)很多人以為焦慮來自“AI 能力太強(qiáng)”但更深層的原因是過去我們的工作價值有相當(dāng)大一部分來自“執(zhí)行效率”。當(dāng) AI 把執(zhí)行效率拉滿之后執(zhí)行本身就不值錢了。舉個例子以前你寫一個 Python 腳本處理 Excel 報表可能需要半天這個“半天”就是你的產(chǎn)出價值?，F(xiàn)在你告訴 AI“幫我寫個腳本讀取 30 個 Excel按日期匯總輸出一個新的 CSV 文件?！彼赡苋昼娋蛯懲炅?。你省下了時間但你原本用來衡量的“產(chǎn)值”也被抹平了。這時候真正的問題不是“AI 會不會替代我”而是如果你的價值只能通過“執(zhí)行”來體現(xiàn)那 AI 確實會替代你。如果你的價值來自“定義問題、設(shè)計方案、評估結(jié)果、推動落地”AI 會成為你的放大器。1.3 哪些信號說明你已經(jīng)處于“易替代位置”我們可以用下面幾個問題來自查自查問題危險信號相對安全信號你平時是不是總在寫模板代碼是而且很少需要思考否經(jīng)常需要做技術(shù)選型和權(quán)衡你的工作目標(biāo)是什么完成指派的任務(wù)解決一個模糊的業(yè)務(wù)問題你評價自己工作的標(biāo)準(zhǔn)是什么代碼跑通、功能上線業(yè)務(wù)指標(biāo)是否有提升、系統(tǒng)是否更穩(wěn)定你對業(yè)務(wù)理解有多深只知道表和接口不清楚業(yè)務(wù)鏈路能說清數(shù)據(jù)來源、計算口徑、異常影響你用過 AI 工具嗎基本不用覺得“不靠譜”已經(jīng)在用并且清楚它的邊界如果你發(fā)現(xiàn)自己大部分答案都在左邊那這篇文章值得認(rèn)真讀完。接下來我會講清楚怎么從左邊挪到右邊。2. AI 時代技術(shù)崗位的“危險區(qū)”與“安全區(qū)”2.1 危險區(qū)重復(fù)性、模板化、黑盒執(zhí)行從崗位職責(zé)來看以下幾類工作正在快速進(jìn)入 AI 的“舒適區(qū)”基礎(chǔ) CRUD 開發(fā)單表增刪改查、基于模板的后臺管理界面、簡單的接口封裝。這類代碼大量存在公開代碼庫和文檔中AI 模型已經(jīng)學(xué)得非常充分?；A(chǔ)數(shù)據(jù)處理固定格式的數(shù)據(jù)清洗、字段映射、報表導(dǎo)出、定時任務(wù)腳本。如果你做的事情只是“把 A 表數(shù)據(jù)搬到 B 表并做簡單轉(zhuǎn)換”AI 能做得很快。初級運(yùn)維腳本常見的日志收集、磁盤清理、進(jìn)程監(jiān)控、批量部署。只要指令描述清楚AI 也能生成像模像樣的腳本。文檔和重復(fù)性溝通寫簡單的接口文檔、生成周報、整理會議紀(jì)要。大模型處理這類文本任務(wù)已經(jīng)是強(qiáng)項。這些崗位的共同點(diǎn)是不涉及復(fù)雜的上下文理解也不需要對結(jié)果負(fù)責(zé)。只要把規(guī)則描述清楚AI 就有比較高的概率給出可用結(jié)果。2.2 安全區(qū)工程化、評估、業(yè)務(wù)理解、系統(tǒng)設(shè)計那么哪些能力是 AI 短期很難替代的我認(rèn)為有四類第一把模糊需求變成可執(zhí)行方案的能力。業(yè)務(wù)方說“我要讓用戶更快找到想要的商品”這句話離實際代碼非常遠(yuǎn)。你需要拆解是什么商品怎么定義“更快”搜索、推薦、還是分類導(dǎo)航數(shù)據(jù)從哪來效果怎么衡量這種“從模糊到清晰”的能力AI 目前很難替代。第二對系統(tǒng)整體的把控能力。一個業(yè)務(wù)系統(tǒng)會涉及前端、后端、數(shù)據(jù)庫、緩存、消息隊列、定時任務(wù)、權(quán)限控制、日志監(jiān)控。AI 能幫你寫出局部代碼但很難幫你判斷“這里應(yīng)該用緩存還是直接查庫”“這個操作要不要加分布式鎖”“這條鏈路超時了怎么降級”。第三結(jié)果評估與糾錯能力。AI 生成的代碼不一定是對的甚至可能一本正經(jīng)地給出錯誤方案。能看懂它在干什么、知道什么地方可能出錯、并能設(shè)計測試用例覆蓋邊界情況的人價值反而更高。第四跨團(tuán)隊協(xié)作和業(yè)務(wù)影響力。技術(shù)方案最終要落地需要說服業(yè)務(wù)方、協(xié)調(diào)前后端、處理上線風(fēng)險、跟進(jìn)線上問題。這些需要信任積累和溝通能力不是單純寫代碼能解決的。2.3 能力切換的真實案例我之前帶過一個數(shù)據(jù)開發(fā)同學(xué)他剛開始的主要工作是寫 SQL后來發(fā)現(xiàn)很多取數(shù)需求 AI 也能做而且速度不慢。后來他換了一種工作方式每次業(yè)務(wù)方提需求他先不復(fù)述“要怎么查”而是追問“為什么要查這個數(shù)據(jù)拿到之后要做什么決策”。同樣是取數(shù)需求他后來做的事情變成了梳理數(shù)據(jù)口徑確認(rèn)指標(biāo)定義。設(shè)計數(shù)據(jù)質(zhì)量校驗規(guī)則防止臟數(shù)據(jù)影響判斷。把常用的取數(shù)邏輯沉淀成數(shù)據(jù)模型和自動化看板。教會業(yè)務(wù)方自己利用看板做初步分析。這個過程中他寫的 SQL 反而變少了但業(yè)務(wù)方對他更依賴了。因為他從“寫 SQL 的人”變成了“幫業(yè)務(wù)方定義和分析問題的人”。這就是從危險區(qū)往安全區(qū)切換的實際路徑。3. 從“寫代碼的人”到“定義問題的人”核心能力模型3.1 把需求拆成可驗證的問題很多開發(fā)者拿到需求的第一反應(yīng)是“這個怎么做”但更重要的第一步是“這個需求到底是什么、怎么算成功”。舉個例子假設(shè)產(chǎn)品經(jīng)理說“我們想給用戶增加一個 AI 問答助手?！比绻阒苯娱_始想技術(shù)架構(gòu)很可能會做偏。你應(yīng)該先反問用戶會在什么場景下使用這個問答助手回答是基于通用知識還是基于我們內(nèi)部的文檔和數(shù)據(jù)庫允許 AI 自由發(fā)揮還是必須嚴(yán)格基于資料回答回答錯了會有什么影響需要人工介入嗎怎么評估“好用”是看回答準(zhǔn)確率還是看用戶停留時長這些問題拆清楚之后技術(shù)方案才有方向。否則你只是在幫 AI 打下手而不是在利用 AI 創(chuàng)造價值。3.2 讓 AI 進(jìn)入可評估的工作流AI 能力的引入不能停留在“問它一個問題拿一段答案”的層面。真正有價值的是把 AI 能力嵌入到一個可評估、可回滾、可觀測的工作流里。一個標(biāo)準(zhǔn)的工作流至少包含以下幾個環(huán)節(jié)輸入規(guī)范化明確 AI 的輸入格式避免自由文本帶來的不確定性。結(jié)果校驗對 AI 生成的內(nèi)容做格式檢查、邊界判斷、敏感信息過濾。人工兜底設(shè)計降級策略當(dāng) AI 無法給出可信結(jié)果時回退到人工流程。效果追蹤記錄每一次 AI 調(diào)用的輸入、輸出、耗時、用戶反饋持續(xù)優(yōu)化。能做到這四點(diǎn)AI 就不是一個“黑盒玩具”而是系統(tǒng)里的一個穩(wěn)定組件。這也是為什么我說AI 工程化能力比單純會調(diào)用 API 重要得多。3.3 工程化能力是護(hù)城河很多人擔(dān)心 AI 會取代程序員但我看到的實際情況是AI 工具讓低水平代碼的獲取成本趨近于零但讓“讓代碼穩(wěn)定運(yùn)行在生產(chǎn)環(huán)境”的能力變得更稀缺。一個能力很強(qiáng)的開發(fā)者和普通開發(fā)者之間最大的差距不是誰寫代碼更快而是誰更早發(fā)現(xiàn)設(shè)計缺陷誰能在系統(tǒng)崩潰時更快定位根因誰能設(shè)計出更容易維護(hù)和擴(kuò)展的架構(gòu)誰能在引入新技術(shù)時控制風(fēng)險這些能力都需要在真實項目中積累。如果你想轉(zhuǎn)型不要只學(xué)“AI 怎么調(diào)用”更要把注意力放在工程實踐上單元測試、代碼審查、CI/CD、監(jiān)控告警、容量規(guī)劃、故障復(fù)盤。4. 用 AI 工程實踐武裝自己一個 RAG 檢索增強(qiáng)示例4.1 為什么從 RAG 開始RAGRetrieval-Augmented Generation檢索增強(qiáng)生成是目前大模型應(yīng)用落地最常用的技術(shù)路線之一。它可以解決一個核心問題大模型不知道你公司內(nèi)部的業(yè)務(wù)細(xì)節(jié)但你可以把相關(guān)資料檢索出來作為上下文喂給它。掌握 RAG 的意義在于理解大模型應(yīng)用的常見架構(gòu)模式。掌握向量檢索、文本切分、相關(guān)性排序等基礎(chǔ)工程能力。能用較低成本做出“私有知識庫問答”“智能客服”“文檔助手”等產(chǎn)品。這一節(jié)我會帶你實現(xiàn)一個最小可運(yùn)行的 RAG 示例。雖然代碼不復(fù)雜但包含了完整鏈路可以幫你建立整體認(rèn)知。4.2 環(huán)境準(zhǔn)備與依賴本文示例以 Python 3.9 環(huán)境為例需要安裝以下依賴pip install jieba scikit-learn requests依賴說明jieba用于中文文本分詞。RAG 中文場景下直接按字切分效果一般使用分詞器可以提升檢索質(zhì)量。scikit-learn用于 TF-IDF 向量化和余弦相似度計算。這里不依賴外部向量數(shù)據(jù)庫方便你快速跑通邏輯。requests用于調(diào)用大模型 API 生成最終答案。提示如果后續(xù)要處理大規(guī)模文檔或生產(chǎn)環(huán)境高并發(fā)通常會用專門的向量數(shù)據(jù)庫例如 Milvus、Chroma、Qdrant但核心思路是一致的。本文先演示思路不引入重型組件。4.3 最小可運(yùn)行示例文檔加載、向量化、檢索我們先創(chuàng)建一個簡單的文檔集合模擬企業(yè)內(nèi)部知識庫中的幾條問答記錄。# 文件路徑rag_demo/build_index.py import jieba from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity import numpy as np # 模擬知識庫文檔 documents [ 公司內(nèi)部報銷流程員工在OA系統(tǒng)填寫報銷單上傳發(fā)票部門主管審批財務(wù)復(fù)核后打款。, 服務(wù)器部署流程代碼合并到main分支后由Jenkins自動構(gòu)建鏡像并推送到K8s集群。, 客戶反饋處理機(jī)制客服收到反饋后先判斷嚴(yán)重級別緊急問題需要在30分鐘內(nèi)響應(yīng)。, 月度數(shù)據(jù)報告每月1號統(tǒng)計上月活躍用戶數(shù)、付費(fèi)轉(zhuǎn)化率、平均客單價。, ] # 中文分詞函數(shù) def tokenize(text): return .join(jieba.lcut(text)) # 構(gòu)建 TF-IDF 向量化器 vectorizer TfidfVectorizer(tokenizertokenize, token_patternNone) # 對所有文檔做向量化 doc_vectors vectorizer.fit_transform(documents) # 保存分詞器、向量化器和文檔向量方便檢索時復(fù)用這里直接用全局變量簡化處理 questions [ 用戶反饋處理時間要求是多少, 怎么提交報銷申請, 代碼部署的流程是什么, 月報統(tǒng)計哪些指標(biāo), ] for q in questions: q_vec vectorizer.transform([q]) scores cosine_similarity(q_vec, doc_vectors)[0] best_idx int(np.argmax(scores)) print(f問題{q}) print(f最相關(guān)的文檔{documents[best_idx]}) print(f相似度分?jǐn)?shù){scores[best_idx]:.4f}) print(- * 50)這段代碼做的事情本質(zhì)上就是“檢索”。它把問題轉(zhuǎn)換成向量和所有文檔向量計算相似度找到最相關(guān)的文檔片段。預(yù)期輸出如下實際分詞結(jié)果會根據(jù) jieba 版本略有差異問題用戶反饋處理時間要求是多少 最相關(guān)的文檔客戶反饋處理機(jī)制客服收到反饋后先判斷嚴(yán)重級別緊急問題需要在30分鐘內(nèi)響應(yīng)。 相似度分?jǐn)?shù)0.4xxx ...這里我們可以看到僅僅依靠關(guān)鍵詞匹配已經(jīng)能把問題路由到正確的文檔上。這就是 RAG 中“R”的部分。4.4 把檢索結(jié)果接入大模型找到相關(guān)資料后下一步是把它作為上下文拼進(jìn) Prompt調(diào)大模型生成回答。下面我們以 OpenAI 兼容接口為例演示如何調(diào)用。很多國內(nèi)大模型廠商也提供兼容接口只需要替換base_url和api_key。# 文件路徑rag_demo/generate_answer.py import requests import json def chat_with_context(question, context, api_key, base_urlhttps://api.openai.com/v1/chat/completions): 傳入用戶問題和檢索到的上下文讓大模型基于上下文回答。 注意生產(chǎn)環(huán)境應(yīng)把 api_key 放在環(huán)境變量或配置中心不要硬編碼。 system_prompt 你是一個嚴(yán)謹(jǐn)?shù)闹帧Ｕ垏?yán)格根據(jù)以下提供的資料回答問題不要編造資料中不存在的信息。 user_content f資料\n{context}\n\n問題{question} payload { model: gpt-4o-mini, # 實際模型名按服務(wù)商調(diào)整 temperature: 0.2, # 低溫減少自由發(fā)揮 messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], } headers { Content-Type: application/json, Authorization: fBearer {api_key}, } resp requests.post(base_url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() return data[choices][0][message][content] if __name__ __main__: # 這里只做演示實際請從環(huán)境變量讀取 api_key your-api-key context ( 客戶反饋處理機(jī)制客服收到反饋后先判斷嚴(yán)重級別 緊急問題需要在30分鐘內(nèi)響應(yīng)。 ) question 用戶反饋處理時間要求是多少 answer chat_with_context(question, context, api_key) print(answer)這段代碼的核心不是 API 調(diào)用本身而是Prompt 結(jié)構(gòu)。在生產(chǎn)系統(tǒng)中你會希望把“資料”和“問題”明確區(qū)分開并且用 system prompt 強(qiáng)調(diào)“只能基于資料回答”。這樣才能減少模型胡說八道的概率。4.5 運(yùn)行與驗證為了把整個流程串起來我們可以把檢索和生成封裝成一個完整的 RAG 函數(shù)# 文件路徑rag_demo/rag_pipeline.py from build_index import vectorizer, doc_vectors, documents, tokenize from sklearn.metrics.pairwise import cosine_similarity from generate_answer import chat_with_context def search_top_k(query, k2): q_vec vectorizer.transform([query]) scores cosine_similarity(q_vec, doc_vectors)[0] top_indices scores.argsort()[-k:][::-1] results [] for idx in top_indices: results.append({ text: documents[idx], score: float(scores[idx]), }) return results def rag_answer(question, api_key, k2): results search_top_k(question, kk) context \n\n.join([item[text] for item in results]) return chat_with_context(question, context, api_key) if __name__ __main__: api_key your-api-key question 怎么提交報銷申請 print(rag_answer(question, api_key))運(yùn)行之后你就能看到一個大模型基于內(nèi)部文檔生成的回答而不是它在網(wǎng)絡(luò)上隨便找到的通用答案。補(bǔ)充說明這個示例最大的意義是讓你理解 RAG 的骨架。實際項目中你還需要考慮文檔切分策略、向量 embedding 模型的選擇、相似度閾值設(shè)置、多路召回、答案引用溯源等細(xì)節(jié)。這些內(nèi)容我會在后續(xù)的實踐文章中繼續(xù)拆解本文先建立整體認(rèn)知。5. 用 AI 輔助開發(fā)提升效率而不是被替代5.1 用好 AI 編程助手的正確姿勢AI 編程助手已經(jīng)非常普及但很多人用不好原因通常是兩個極端要么完全不信要么無腦接受。我建議的流程是這樣的先把需求拆解成小任務(wù)再讓 AI 幫你寫局部代碼。不要讓 AI 直接“寫整個系統(tǒng)”而是讓它“寫一個工具函數(shù)”“寫一條 SQL”“寫一個正則表達(dá)式”。讓 AI 生成測試用例然后用測試約束它。先寫一個簡單的測試再讓 AI 補(bǔ)實現(xiàn)比直接讓它寫完整模塊要可靠得多。讓 AI 解釋代碼而不是只抄代碼。如果你看不懂它生成的代碼那就不要上生產(chǎn)環(huán)境。5.2 AI Code Review 腳本示例這里分享一個簡單的“AI Code Review 助手”腳本思路。假設(shè)你有一個 Python 函數(shù)想讓 AI 幫忙檢查潛在問題# 文件路徑tools/ai_review.py import requests python_code def get_user_name(user_id): conn get_db_conn() sql fSELECT name FROM users WHERE id {user_id} cursor conn.execute(sql) return cursor.fetchone() prompt f 請對下面的 Python 代碼進(jìn)行代碼審查重點(diǎn)關(guān)注 1. SQL 注入風(fēng)險 2. 異常處理 3. 資源釋放問題 4. 代碼可讀性 代碼 python {python_code}請按問題嚴(yán)重級別列出需要修改的點(diǎn)。 以下為調(diào)用 API 的示意實際使用時請將 api_key 放入環(huán)境變量resp requests.post(url,headers{Authorization: Bearer your-api-key},json{model: gpt-4o-mini,messages: [{role: user, content: prompt}],})你會發(fā)現(xiàn)AI 會指出這段代碼至少有三個問題SQL 注入、數(shù)據(jù)庫連接未關(guān)閉、沒有處理查詢結(jié)果為空的情況。這樣的工具用在做代碼自查時價值很高。 但要注意**AI Code Review 不能取代人工 Review。** 它適合在代碼提交前幫你做一輪快速檢查但最終合不合并、怎么改還是需要人來判斷。 ### 5.3 自動化測試補(bǔ)全 再分享一個場景寫完一個函數(shù)后讓 AI 補(bǔ)充邊界測試。 python # 文件路徑tools/generate_tests.py function_code def calculate_discount(price, level): if price 0: raise ValueError(price cannot be negative) if level gold: return price * 0.8 elif level silver: return price * 0.9 else: return price prompt f 請為以下 Python 函數(shù)生成 pytest 測試用例要求覆蓋正常情況、邊界情況和異常情況 {function_code} # 調(diào)用大模型 API 獲取測試代碼 # 然后將生成結(jié)果保存為 test_discount.py這里的關(guān)鍵點(diǎn)是讓 AI 生成測試實際上也是在幫你審視自己的實現(xiàn)是否完整。如果一個函數(shù)很難被測試覆蓋那它的設(shè)計可能有問題。這種思路可以讓 AI 成為你的“設(shè)計反饋器”而不只是“代碼生成器”。5.4 什么時候不該用 AI使用 AI 工具也要有邊界意識。以下幾個場景我建議謹(jǐn)慎或避免使用敏感業(yè)務(wù)數(shù)據(jù)不要直接把用戶手機(jī)號、身份證、日志信息粘貼到外部 AI 服務(wù)。核心算法邏輯如果代碼邏輯一旦出錯會造成資損或安全問題必須人工逐行審查 AI 生成結(jié)果。缺乏測試保護(hù)的重構(gòu)沒有自動化測試的項目AI 生成的重構(gòu)代碼風(fēng)險非常高。需要深度業(yè)務(wù)判斷的決策比如權(quán)限設(shè)計、數(shù)據(jù)刪除策略、產(chǎn)品定價策略不應(yīng)該直接讓 AI 做決定。簡單來說AI 適合幫你加速但責(zé)任永遠(yuǎn)在你自己身上。6. Agent 與智能體下一個需要掌握的工程方向6.1 從工具調(diào)用到自主規(guī)劃如果說 RAG 是大模型應(yīng)用的第一階段那么 Agent智能體正在成為第二階段的重點(diǎn)方向。RAG 解決的是“讓模型知道更多信息”Agent 解決的是“讓模型能完成多步任務(wù)”。一個典型 Agent 的結(jié)構(gòu)是理解任務(wù)解析用戶意圖。拆解計劃把復(fù)雜任務(wù)拆成步驟。選擇工具調(diào)用搜索引擎、計算器、數(shù)據(jù)庫查詢接口、代碼執(zhí)行器等。執(zhí)行與觀察執(zhí)行工具并觀察結(jié)果。調(diào)整計劃根據(jù)結(jié)果決定下一步行動。很多開發(fā)者已經(jīng)在嘗試用 Agent 做內(nèi)部運(yùn)維助手、自動填單機(jī)器人、智能客服等。6.2 一個最小的 Agent 設(shè)計思路下面是一個簡化版的 Agent 調(diào)度框架幫助你理解核心邏輯# 文件路徑agent_demo/simple_agent.py import json # 1. 定義工具函數(shù) def calculate(expr): 模擬計算器工具 try: result eval(expr) # 注意真實項目中不要直接用 eval這里僅為演示 return str(result) except Exception as e: return f計算失敗: {e} # 2. 定義工具注冊表 TOOLS { calculate: calculate, } # 3. 模擬大模型決定調(diào)用哪個工具 def decide_next_action(user_query): 真實場景中這一步需要調(diào)用大模型讓模型輸出結(jié)構(gòu)化指令。 這里為了演示使用一個簡單規(guī)則。 if 計算 in user_query or 等于 in user_query or 幾 in user_query: return {action: calculate, args: extract_expr(user_query)} return {action: finish, args: {}} def extract_expr(query): # 簡化實現(xiàn)從問題中截取數(shù)字和運(yùn)算符 import re expr re.search(r[\d\-*/().\s], query) if expr: return expr.group().strip() return 0 # 4. Agent 主循環(huán) def run_agent(user_query): max_steps 3 current_query user_query for _ in range(max_steps): action decide_next_action(current_query) print(f當(dāng)前指令: {action}) if action[action] finish: print(Agent 結(jié)束沒有可執(zhí)行工具。) return if action[action] in TOOLS: result TOOLS[action[action]](**action[args]) print(f工具返回: {result}) current_query f上一步結(jié)果為{result}請繼續(xù)判斷 else: print(未知工具結(jié)束。) return if __name__ __main__: run_agent(15加27等于幾)這段代碼把 Agent 的核心循環(huán)簡化成了“決策-調(diào)用-觀察-再決策”。真實項目里decide_next_action是由大模型實現(xiàn)的模型會輸出 JSON 格式的工具調(diào)用指令。但整體的控制流思想是一樣的。6.3 Agent 開發(fā)的常見陷阱Agent 開發(fā)雖然熱門但工程落地并不容易。常見陷阱有幾個陷阱說明應(yīng)對方式無限循環(huán)Agent 反復(fù)調(diào)用工具停不下來設(shè)置最大步驟數(shù)、超時控制、人工確認(rèn)點(diǎn)工具參數(shù)錯誤模型生成的工具參數(shù)格式不對對工具輸入做嚴(yán)格校驗必要時讓模型先思考再生成錯誤累積前一步判斷錯誤導(dǎo)致后面全錯在關(guān)鍵節(jié)點(diǎn)讓結(jié)果可觀測、可回滾權(quán)限邊界Agent 執(zhí)行了不該執(zhí)行的操作嚴(yán)格限制工具權(quán)限重要操作加二次確認(rèn)成本失控每輪都調(diào)大模型Token 消耗過高增加緩存、減少無關(guān)上下文、設(shè)置預(yù)算上限我的建議是先從受控場景開始不要一上來就做一個完全自主的通用 Agent。比如先做一個只能在測試環(huán)境執(zhí)行命令的運(yùn)維助手或者先做一個只能查詢只讀數(shù)據(jù)庫的問答機(jī)器人。等機(jī)制成熟了再逐步擴(kuò)大權(quán)限范圍。7. 技術(shù)人轉(zhuǎn)型避坑指南常見誤區(qū)與解決思路轉(zhuǎn)型過程中開發(fā)者最容易踩的坑不是技術(shù)不會而是方向錯誤。下面這張表總結(jié)了幾個高頻誤區(qū)。誤區(qū)典型表現(xiàn)正確思路拼命學(xué) Prompt不做工程整天研究“咒語”怎么寫但不會寫生產(chǎn)級代碼Prompt 只是能力的一部分工程化、評估、部署才是核心只學(xué)調(diào) API會調(diào)用大模型接口但不理解模型邊界要懂提示詞設(shè)計、上下文窗口、輸出格式約束、成本控制忽視業(yè)務(wù)理解認(rèn)為技術(shù)好就能不被淘汰懂業(yè)務(wù)的人才知道 AI 該用在哪里、怎么評估效果拒絕使用 AI覺得 AI 生成代碼不可靠堅持手寫一切把 AI 當(dāng)成“結(jié)對編程伙伴”用測試約束它的輸出盲目使用 AI不做代碼審查直接把 AI 輸出扔到生產(chǎn)建立人工審核、測試、觀測、回滾機(jī)制后再上線忽略軟技能只會悶頭寫代碼不表達(dá)、不溝通定義問題、推進(jìn)協(xié)作、向上匯報都是護(hù)城河的一部分這里我想特別強(qiáng)調(diào)一點(diǎn)不要把“學(xué) AI”當(dāng)成一門單獨(dú)的課而是要把它融入到你現(xiàn)有的技術(shù)體系里。比如你是后端開發(fā)者那你要研究的是“如何在我的 Spring Boot 服務(wù)里集成大模型能力”你是數(shù)據(jù)開發(fā)者那你要研究的是“如何用 RAG 讓數(shù)據(jù)問答更可靠”你是前端開發(fā)者那你要研究的是“如何把 AI 能力和交互體驗結(jié)合”。這樣學(xué)習(xí)知識是長在業(yè)務(wù)場景里的而不是漂在空中的概念。8. AI 時代開發(fā)者行動清單與學(xué)習(xí)路線8.1 近期行動清單1-2 周如果你想開始做出改變不需要等到“學(xué)完所有東西再行動”可以按下面這個清單起步選一個你最熟悉的業(yè)務(wù)場景把其中重復(fù)性最高的任務(wù)列出來。用 AI 編程助手嘗試完成其中一個小任務(wù)并寫最少 5 個測試用例。搭一個最小的 RAG 項目把內(nèi)部文檔作為知識庫做一次問答體驗。挑一個你最近寫的模塊讓 AI 做一次代碼審查逐條驗證它提出的問題。把學(xué)習(xí)過程記錄下來形成自己的案例庫。8.2 中期學(xué)習(xí)路線1-3 個月再往后你可以按照下面幾個方向逐步深入AI 工程實踐學(xué)習(xí)如何搭建大模型應(yīng)用包括提示詞工程、RAG、Agent、評估、部署調(diào)優(yōu)。模型部署基礎(chǔ)了解量化、推理加速、GPU 顯存占用、接口網(wǎng)關(guān)等概念。不需要成為算法專家但要能聽懂“部署一個模型”的工程成本。數(shù)據(jù)工程理解結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)、向量化、數(shù)據(jù)清洗在大模型應(yīng)用中的角色。穩(wěn)定性建設(shè)學(xué)會給 AI 應(yīng)用加監(jiān)控、加日志、加人工兜底保證上線后可運(yùn)維。8.3 長期定位建議從長期來看技術(shù)人不需要把自己定義為“會寫代碼的人”更合適的定義是“能利用技術(shù)解決業(yè)務(wù)問題的人”。AI 會繼續(xù)改變代碼的生產(chǎn)方式但有一個事實不會變問題永遠(yuǎn)需要人來定義風(fēng)險永遠(yuǎn)需要人來承擔(dān)系統(tǒng)永遠(yuǎn)需要人來設(shè)計。所以我給你的建議是保持對業(yè)務(wù)的敏感度不要只盯著代碼倉庫。保持工程上的嚴(yán)謹(jǐn)不要因為 AI 生成了代碼就放棄審查。保持持續(xù)學(xué)習(xí)但學(xué)習(xí)一定要圍繞實際場景展開。保持開放心態(tài)AI 是工具不是敵人也不是神。回到開頭那句話“I feel like I dug my own grave.”如果你想避免這種感受方法其實不復(fù)雜不要在坑里繼續(xù)只做“挖土”的動作而是抬起頭看看整片工地學(xué)著去設(shè)計挖掘路線、調(diào)配資源、控制風(fēng)險。技術(shù)人的職業(yè)安全感從來不來自某個工具或某一項技能而來自你解決問題、創(chuàng)造價值的綜合能力。希望這篇文章能成為你調(diào)整方向的一塊路標(biāo)。下一步挑一個方向動手做一個小項目比什么都重要。 AI時代開發(fā)者轉(zhuǎn)型：從執(zhí)行者到問題定義者
這幾天我一直在想一個采訪標(biāo)題“I feel like I dug my own grave”。一位在 AI 轉(zhuǎn)型浪潮中被邊緣化的技術(shù)工作者用這樣一句話形容自己的處境。這句話放在今天的開發(fā)者圈子里其實很有共鳴。過去幾年我們親手搭建自動化流水線、引入 AI 編程助手、推動團(tuán)隊流程標(biāo)準(zhǔn)化結(jié)果發(fā)現(xiàn)這些工作一邊在提升研發(fā)效率一邊也在壓縮“純執(zhí)行型人力”的生存空間。于是很多人開始問我是不是也在給自己挖坑本文不打算販賣焦慮也不想去討論“AI 會不會取代程序員”這種宏大的口號。我會從技術(shù)人的實際處境出發(fā)分析哪些能力正在被 AI 快速替代哪些能力反而是未來幾年最重要的護(hù)城河并且給出具體的技術(shù)學(xué)習(xí)路徑、代碼示例和工程建議。希望這篇文章能幫你從一個“AI 轉(zhuǎn)型中被影響的人”變成“主動使用 AI 解決問題的人”。1. AI 轉(zhuǎn)型焦慮的本質(zhì)那些“親手挖坑”的人在怕什么1.1 一個正在發(fā)生的現(xiàn)象體力型腦力勞動被壓縮先看一個很常見的場景。以前寫一個數(shù)據(jù)報表接口需要熟悉 SQL、熟悉業(yè)務(wù)表結(jié)構(gòu)、寫一堆 CRUD 代碼、再配合前端聯(lián)調(diào)?，F(xiàn)在呢AI 編程助手可以幾秒鐘生成一份可運(yùn)行的 CRUD 代碼甚至能直接根據(jù)數(shù)據(jù)庫 schema 生成查詢語句。團(tuán)隊里真正需要的是能說清楚“這個報表要看什么指標(biāo)、口徑怎么定義、數(shù)據(jù)怎么校驗”的人。這種現(xiàn)象可以概括為“體力型腦力勞動被壓縮”。所謂體力型腦力勞動是指那些流程明確、規(guī)則清晰、重復(fù)度高的腦力工作。比如根據(jù)接口文檔寫模板化代碼。把需求翻譯成 SQL 查詢。寫單元測試的重復(fù)骨架。處理格式固定的日志和配置文件。這些工作的共同點(diǎn)是你不需要做太多決策只需要按照既定規(guī)則執(zhí)行。而 AI 模型恰恰最擅長這類任務(wù)。1.2 焦慮的真正來源不是 AI而是工作結(jié)構(gòu)很多人以為焦慮來自“AI 能力太強(qiáng)”但更深層的原因是過去我們的工作價值有相當(dāng)大一部分來自“執(zhí)行效率”。當(dāng) AI 把執(zhí)行效率拉滿之后執(zhí)行本身就不值錢了。舉個例子以前你寫一個 Python 腳本處理 Excel 報表可能需要半天這個“半天”就是你的產(chǎn)出價值?，F(xiàn)在你告訴 AI“幫我寫個腳本讀取 30 個 Excel按日期匯總輸出一個新的 CSV 文件?！彼赡苋昼娋蛯懲炅?。你省下了時間但你原本用來衡量的“產(chǎn)值”也被抹平了。這時候真正的問題不是“AI 會不會替代我”而是如果你的價值只能通過“執(zhí)行”來體現(xiàn)那 AI 確實會替代你。如果你的價值來自“定義問題、設(shè)計方案、評估結(jié)果、推動落地”AI 會成為你的放大器。1.3 哪些信號說明你已經(jīng)處于“易替代位置”我們可以用下面幾個問題來自查自查問題危險信號相對安全信號你平時是不是總在寫模板代碼是而且很少需要思考否經(jīng)常需要做技術(shù)選型和權(quán)衡你的工作目標(biāo)是什么完成指派的任務(wù)解決一個模糊的業(yè)務(wù)問題你評價自己工作的標(biāo)準(zhǔn)是什么代碼跑通、功能上線業(yè)務(wù)指標(biāo)是否有提升、系統(tǒng)是否更穩(wěn)定你對業(yè)務(wù)理解有多深只知道表和接口不清楚業(yè)務(wù)鏈路能說清數(shù)據(jù)來源、計算口徑、異常影響你用過 AI 工具嗎基本不用覺得“不靠譜”已經(jīng)在用并且清楚它的邊界如果你發(fā)現(xiàn)自己大部分答案都在左邊那這篇文章值得認(rèn)真讀完。接下來我會講清楚怎么從左邊挪到右邊。2. AI 時代技術(shù)崗位的“危險區(qū)”與“安全區(qū)”2.1 危險區(qū)重復(fù)性、模板化、黑盒執(zhí)行從崗位職責(zé)來看以下幾類工作正在快速進(jìn)入 AI 的“舒適區(qū)”基礎(chǔ) CRUD 開發(fā)單表增刪改查、基于模板的后臺管理界面、簡單的接口封裝。這類代碼大量存在公開代碼庫和文檔中AI 模型已經(jīng)學(xué)得非常充分?；A(chǔ)數(shù)據(jù)處理固定格式的數(shù)據(jù)清洗、字段映射、報表導(dǎo)出、定時任務(wù)腳本。如果你做的事情只是“把 A 表數(shù)據(jù)搬到 B 表并做簡單轉(zhuǎn)換”AI 能做得很快。初級運(yùn)維腳本常見的日志收集、磁盤清理、進(jìn)程監(jiān)控、批量部署。只要指令描述清楚AI 也能生成像模像樣的腳本。文檔和重復(fù)性溝通寫簡單的接口文檔、生成周報、整理會議紀(jì)要。大模型處理這類文本任務(wù)已經(jīng)是強(qiáng)項。這些崗位的共同點(diǎn)是不涉及復(fù)雜的上下文理解也不需要對結(jié)果負(fù)責(zé)。只要把規(guī)則描述清楚AI 就有比較高的概率給出可用結(jié)果。2.2 安全區(qū)工程化、評估、業(yè)務(wù)理解、系統(tǒng)設(shè)計那么哪些能力是 AI 短期很難替代的我認(rèn)為有四類第一把模糊需求變成可執(zhí)行方案的能力。業(yè)務(wù)方說“我要讓用戶更快找到想要的商品”這句話離實際代碼非常遠(yuǎn)。你需要拆解是什么商品怎么定義“更快”搜索、推薦、還是分類導(dǎo)航數(shù)據(jù)從哪來效果怎么衡量這種“從模糊到清晰”的能力AI 目前很難替代。第二對系統(tǒng)整體的把控能力。一個業(yè)務(wù)系統(tǒng)會涉及前端、后端、數(shù)據(jù)庫、緩存、消息隊列、定時任務(wù)、權(quán)限控制、日志監(jiān)控。AI 能幫你寫出局部代碼但很難幫你判斷“這里應(yīng)該用緩存還是直接查庫”“這個操作要不要加分布式鎖”“這條鏈路超時了怎么降級”。第三結(jié)果評估與糾錯能力。AI 生成的代碼不一定是對的甚至可能一本正經(jīng)地給出錯誤方案。能看懂它在干什么、知道什么地方可能出錯、并能設(shè)計測試用例覆蓋邊界情況的人價值反而更高。第四跨團(tuán)隊協(xié)作和業(yè)務(wù)影響力。技術(shù)方案最終要落地需要說服業(yè)務(wù)方、協(xié)調(diào)前后端、處理上線風(fēng)險、跟進(jìn)線上問題。這些需要信任積累和溝通能力不是單純寫代碼能解決的。2.3 能力切換的真實案例我之前帶過一個數(shù)據(jù)開發(fā)同學(xué)他剛開始的主要工作是寫 SQL后來發(fā)現(xiàn)很多取數(shù)需求 AI 也能做而且速度不慢。后來他換了一種工作方式每次業(yè)務(wù)方提需求他先不復(fù)述“要怎么查”而是追問“為什么要查這個數(shù)據(jù)拿到之后要做什么決策”。同樣是取數(shù)需求他后來做的事情變成了梳理數(shù)據(jù)口徑確認(rèn)指標(biāo)定義。設(shè)計數(shù)據(jù)質(zhì)量校驗規(guī)則防止臟數(shù)據(jù)影響判斷。把常用的取數(shù)邏輯沉淀成數(shù)據(jù)模型和自動化看板。教會業(yè)務(wù)方自己利用看板做初步分析。這個過程中他寫的 SQL 反而變少了但業(yè)務(wù)方對他更依賴了。因為他從“寫 SQL 的人”變成了“幫業(yè)務(wù)方定義和分析問題的人”。這就是從危險區(qū)往安全區(qū)切換的實際路徑。3. 從“寫代碼的人”到“定義問題的人”核心能力模型3.1 把需求拆成可驗證的問題很多開發(fā)者拿到需求的第一反應(yīng)是“這個怎么做”但更重要的第一步是“這個需求到底是什么、怎么算成功”。舉個例子假設(shè)產(chǎn)品經(jīng)理說“我們想給用戶增加一個 AI 問答助手?！比绻阒苯娱_始想技術(shù)架構(gòu)很可能會做偏。你應(yīng)該先反問用戶會在什么場景下使用這個問答助手回答是基于通用知識還是基于我們內(nèi)部的文檔和數(shù)據(jù)庫允許 AI 自由發(fā)揮還是必須嚴(yán)格基于資料回答回答錯了會有什么影響需要人工介入嗎怎么評估“好用”是看回答準(zhǔn)確率還是看用戶停留時長這些問題拆清楚之后技術(shù)方案才有方向。否則你只是在幫 AI 打下手而不是在利用 AI 創(chuàng)造價值。3.2 讓 AI 進(jìn)入可評估的工作流AI 能力的引入不能停留在“問它一個問題拿一段答案”的層面。真正有價值的是把 AI 能力嵌入到一個可評估、可回滾、可觀測的工作流里。一個標(biāo)準(zhǔn)的工作流至少包含以下幾個環(huán)節(jié)輸入規(guī)范化明確 AI 的輸入格式避免自由文本帶來的不確定性。結(jié)果校驗對 AI 生成的內(nèi)容做格式檢查、邊界判斷、敏感信息過濾。人工兜底設(shè)計降級策略當(dāng) AI 無法給出可信結(jié)果時回退到人工流程。效果追蹤記錄每一次 AI 調(diào)用的輸入、輸出、耗時、用戶反饋持續(xù)優(yōu)化。能做到這四點(diǎn)AI 就不是一個“黑盒玩具”而是系統(tǒng)里的一個穩(wěn)定組件。這也是為什么我說AI 工程化能力比單純會調(diào)用 API 重要得多。3.3 工程化能力是護(hù)城河很多人擔(dān)心 AI 會取代程序員但我看到的實際情況是AI 工具讓低水平代碼的獲取成本趨近于零但讓“讓代碼穩(wěn)定運(yùn)行在生產(chǎn)環(huán)境”的能力變得更稀缺。一個能力很強(qiáng)的開發(fā)者和普通開發(fā)者之間最大的差距不是誰寫代碼更快而是誰更早發(fā)現(xiàn)設(shè)計缺陷誰能在系統(tǒng)崩潰時更快定位根因誰能設(shè)計出更容易維護(hù)和擴(kuò)展的架構(gòu)誰能在引入新技術(shù)時控制風(fēng)險這些能力都需要在真實項目中積累。如果你想轉(zhuǎn)型不要只學(xué)“AI 怎么調(diào)用”更要把注意力放在工程實踐上單元測試、代碼審查、CI/CD、監(jiān)控告警、容量規(guī)劃、故障復(fù)盤。4. 用 AI 工程實踐武裝自己一個 RAG 檢索增強(qiáng)示例4.1 為什么從 RAG 開始RAGRetrieval-Augmented Generation檢索增強(qiáng)生成是目前大模型應(yīng)用落地最常用的技術(shù)路線之一。它可以解決一個核心問題大模型不知道你公司內(nèi)部的業(yè)務(wù)細(xì)節(jié)但你可以把相關(guān)資料檢索出來作為上下文喂給它。掌握 RAG 的意義在于理解大模型應(yīng)用的常見架構(gòu)模式。掌握向量檢索、文本切分、相關(guān)性排序等基礎(chǔ)工程能力。能用較低成本做出“私有知識庫問答”“智能客服”“文檔助手”等產(chǎn)品。這一節(jié)我會帶你實現(xiàn)一個最小可運(yùn)行的 RAG 示例。雖然代碼不復(fù)雜但包含了完整鏈路可以幫你建立整體認(rèn)知。4.2 環(huán)境準(zhǔn)備與依賴本文示例以 Python 3.9 環(huán)境為例需要安裝以下依賴pip install jieba scikit-learn requests依賴說明jieba用于中文文本分詞。RAG 中文場景下直接按字切分效果一般使用分詞器可以提升檢索質(zhì)量。scikit-learn用于 TF-IDF 向量化和余弦相似度計算。這里不依賴外部向量數(shù)據(jù)庫方便你快速跑通邏輯。requests用于調(diào)用大模型 API 生成最終答案。提示如果后續(xù)要處理大規(guī)模文檔或生產(chǎn)環(huán)境高并發(fā)通常會用專門的向量數(shù)據(jù)庫例如 Milvus、Chroma、Qdrant但核心思路是一致的。本文先演示思路不引入重型組件。4.3 最小可運(yùn)行示例文檔加載、向量化、檢索我們先創(chuàng)建一個簡單的文檔集合模擬企業(yè)內(nèi)部知識庫中的幾條問答記錄。# 文件路徑rag_demo/build_index.py import jieba from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity import numpy as np # 模擬知識庫文檔 documents [ 公司內(nèi)部報銷流程員工在OA系統(tǒng)填寫報銷單上傳發(fā)票部門主管審批財務(wù)復(fù)核后打款。, 服務(wù)器部署流程代碼合并到main分支后由Jenkins自動構(gòu)建鏡像并推送到K8s集群。, 客戶反饋處理機(jī)制客服收到反饋后先判斷嚴(yán)重級別緊急問題需要在30分鐘內(nèi)響應(yīng)。, 月度數(shù)據(jù)報告每月1號統(tǒng)計上月活躍用戶數(shù)、付費(fèi)轉(zhuǎn)化率、平均客單價。, ] # 中文分詞函數(shù) def tokenize(text): return .join(jieba.lcut(text)) # 構(gòu)建 TF-IDF 向量化器 vectorizer TfidfVectorizer(tokenizertokenize, token_patternNone) # 對所有文檔做向量化 doc_vectors vectorizer.fit_transform(documents) # 保存分詞器、向量化器和文檔向量方便檢索時復(fù)用這里直接用全局變量簡化處理 questions [ 用戶反饋處理時間要求是多少, 怎么提交報銷申請, 代碼部署的流程是什么, 月報統(tǒng)計哪些指標(biāo), ] for q in questions: q_vec vectorizer.transform([q]) scores cosine_similarity(q_vec, doc_vectors)[0] best_idx int(np.argmax(scores)) print(f問題{q}) print(f最相關(guān)的文檔{documents[best_idx]}) print(f相似度分?jǐn)?shù){scores[best_idx]:.4f}) print(- * 50)這段代碼做的事情本質(zhì)上就是“檢索”。它把問題轉(zhuǎn)換成向量和所有文檔向量計算相似度找到最相關(guān)的文檔片段。預(yù)期輸出如下實際分詞結(jié)果會根據(jù) jieba 版本略有差異問題用戶反饋處理時間要求是多少 最相關(guān)的文檔客戶反饋處理機(jī)制客服收到反饋后先判斷嚴(yán)重級別緊急問題需要在30分鐘內(nèi)響應(yīng)。 相似度分?jǐn)?shù)0.4xxx ...這里我們可以看到僅僅依靠關(guān)鍵詞匹配已經(jīng)能把問題路由到正確的文檔上。這就是 RAG 中“R”的部分。4.4 把檢索結(jié)果接入大模型找到相關(guān)資料后下一步是把它作為上下文拼進(jìn) Prompt調(diào)大模型生成回答。下面我們以 OpenAI 兼容接口為例演示如何調(diào)用。很多國內(nèi)大模型廠商也提供兼容接口只需要替換base_url和api_key。# 文件路徑rag_demo/generate_answer.py import requests import json def chat_with_context(question, context, api_key, base_urlhttps://api.openai.com/v1/chat/completions): 傳入用戶問題和檢索到的上下文讓大模型基于上下文回答。 注意生產(chǎn)環(huán)境應(yīng)把 api_key 放在環(huán)境變量或配置中心不要硬編碼。 system_prompt 你是一個嚴(yán)謹(jǐn)?shù)闹帧Ｕ垏?yán)格根據(jù)以下提供的資料回答問題不要編造資料中不存在的信息。 user_content f資料\n{context}\n\n問題{question} payload { model: gpt-4o-mini, # 實際模型名按服務(wù)商調(diào)整 temperature: 0.2, # 低溫減少自由發(fā)揮 messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], } headers { Content-Type: application/json, Authorization: fBearer {api_key}, } resp requests.post(base_url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() return data[choices][0][message][content] if __name__ __main__: # 這里只做演示實際請從環(huán)境變量讀取 api_key your-api-key context ( 客戶反饋處理機(jī)制客服收到反饋后先判斷嚴(yán)重級別 緊急問題需要在30分鐘內(nèi)響應(yīng)。 ) question 用戶反饋處理時間要求是多少 answer chat_with_context(question, context, api_key) print(answer)這段代碼的核心不是 API 調(diào)用本身而是Prompt 結(jié)構(gòu)。在生產(chǎn)系統(tǒng)中你會希望把“資料”和“問題”明確區(qū)分開并且用 system prompt 強(qiáng)調(diào)“只能基于資料回答”。這樣才能減少模型胡說八道的概率。4.5 運(yùn)行與驗證為了把整個流程串起來我們可以把檢索和生成封裝成一個完整的 RAG 函數(shù)# 文件路徑rag_demo/rag_pipeline.py from build_index import vectorizer, doc_vectors, documents, tokenize from sklearn.metrics.pairwise import cosine_similarity from generate_answer import chat_with_context def search_top_k(query, k2): q_vec vectorizer.transform([query]) scores cosine_similarity(q_vec, doc_vectors)[0] top_indices scores.argsort()[-k:][::-1] results [] for idx in top_indices: results.append({ text: documents[idx], score: float(scores[idx]), }) return results def rag_answer(question, api_key, k2): results search_top_k(question, kk) context \n\n.join([item[text] for item in results]) return chat_with_context(question, context, api_key) if __name__ __main__: api_key your-api-key question 怎么提交報銷申請 print(rag_answer(question, api_key))運(yùn)行之后你就能看到一個大模型基于內(nèi)部文檔生成的回答而不是它在網(wǎng)絡(luò)上隨便找到的通用答案。補(bǔ)充說明這個示例最大的意義是讓你理解 RAG 的骨架。實際項目中你還需要考慮文檔切分策略、向量 embedding 模型的選擇、相似度閾值設(shè)置、多路召回、答案引用溯源等細(xì)節(jié)。這些內(nèi)容我會在后續(xù)的實踐文章中繼續(xù)拆解本文先建立整體認(rèn)知。5. 用 AI 輔助開發(fā)提升效率而不是被替代5.1 用好 AI 編程助手的正確姿勢AI 編程助手已經(jīng)非常普及但很多人用不好原因通常是兩個極端要么完全不信要么無腦接受。我建議的流程是這樣的先把需求拆解成小任務(wù)再讓 AI 幫你寫局部代碼。不要讓 AI 直接“寫整個系統(tǒng)”而是讓它“寫一個工具函數(shù)”“寫一條 SQL”“寫一個正則表達(dá)式”。讓 AI 生成測試用例然后用測試約束它。先寫一個簡單的測試再讓 AI 補(bǔ)實現(xiàn)比直接讓它寫完整模塊要可靠得多。讓 AI 解釋代碼而不是只抄代碼。如果你看不懂它生成的代碼那就不要上生產(chǎn)環(huán)境。5.2 AI Code Review 腳本示例這里分享一個簡單的“AI Code Review 助手”腳本思路。假設(shè)你有一個 Python 函數(shù)想讓 AI 幫忙檢查潛在問題# 文件路徑tools/ai_review.py import requests python_code def get_user_name(user_id): conn get_db_conn() sql fSELECT name FROM users WHERE id {user_id} cursor conn.execute(sql) return cursor.fetchone() prompt f 請對下面的 Python 代碼進(jìn)行代碼審查重點(diǎn)關(guān)注 1. SQL 注入風(fēng)險 2. 異常處理 3. 資源釋放問題 4. 代碼可讀性 代碼 python {python_code}請按問題嚴(yán)重級別列出需要修改的點(diǎn)。 以下為調(diào)用 API 的示意實際使用時請將 api_key 放入環(huán)境變量resp requests.post(url,headers{Authorization: Bearer your-api-key},json{model: gpt-4o-mini,messages: [{role: user, content: prompt}],})你會發(fā)現(xiàn)AI 會指出這段代碼至少有三個問題SQL 注入、數(shù)據(jù)庫連接未關(guān)閉、沒有處理查詢結(jié)果為空的情況。這樣的工具用在做代碼自查時價值很高。 但要注意**AI Code Review 不能取代人工 Review。** 它適合在代碼提交前幫你做一輪快速檢查但最終合不合并、怎么改還是需要人來判斷。 ### 5.3 自動化測試補(bǔ)全 再分享一個場景寫完一個函數(shù)后讓 AI 補(bǔ)充邊界測試。 python # 文件路徑tools/generate_tests.py function_code def calculate_discount(price, level): if price 0: raise ValueError(price cannot be negative) if level gold: return price * 0.8 elif level silver: return price * 0.9 else: return price prompt f 請為以下 Python 函數(shù)生成 pytest 測試用例要求覆蓋正常情況、邊界情況和異常情況 {function_code} # 調(diào)用大模型 API 獲取測試代碼 # 然后將生成結(jié)果保存為 test_discount.py這里的關(guān)鍵點(diǎn)是讓 AI 生成測試實際上也是在幫你審視自己的實現(xiàn)是否完整。如果一個函數(shù)很難被測試覆蓋那它的設(shè)計可能有問題。這種思路可以讓 AI 成為你的“設(shè)計反饋器”而不只是“代碼生成器”。5.4 什么時候不該用 AI使用 AI 工具也要有邊界意識。以下幾個場景我建議謹(jǐn)慎或避免使用敏感業(yè)務(wù)數(shù)據(jù)不要直接把用戶手機(jī)號、身份證、日志信息粘貼到外部 AI 服務(wù)。核心算法邏輯如果代碼邏輯一旦出錯會造成資損或安全問題必須人工逐行審查 AI 生成結(jié)果。缺乏測試保護(hù)的重構(gòu)沒有自動化測試的項目AI 生成的重構(gòu)代碼風(fēng)險非常高。需要深度業(yè)務(wù)判斷的決策比如權(quán)限設(shè)計、數(shù)據(jù)刪除策略、產(chǎn)品定價策略不應(yīng)該直接讓 AI 做決定。簡單來說AI 適合幫你加速但責(zé)任永遠(yuǎn)在你自己身上。6. Agent 與智能體下一個需要掌握的工程方向6.1 從工具調(diào)用到自主規(guī)劃如果說 RAG 是大模型應(yīng)用的第一階段那么 Agent智能體正在成為第二階段的重點(diǎn)方向。RAG 解決的是“讓模型知道更多信息”Agent 解決的是“讓模型能完成多步任務(wù)”。一個典型 Agent 的結(jié)構(gòu)是理解任務(wù)解析用戶意圖。拆解計劃把復(fù)雜任務(wù)拆成步驟。選擇工具調(diào)用搜索引擎、計算器、數(shù)據(jù)庫查詢接口、代碼執(zhí)行器等。執(zhí)行與觀察執(zhí)行工具并觀察結(jié)果。調(diào)整計劃根據(jù)結(jié)果決定下一步行動。很多開發(fā)者已經(jīng)在嘗試用 Agent 做內(nèi)部運(yùn)維助手、自動填單機(jī)器人、智能客服等。6.2 一個最小的 Agent 設(shè)計思路下面是一個簡化版的 Agent 調(diào)度框架幫助你理解核心邏輯# 文件路徑agent_demo/simple_agent.py import json # 1. 定義工具函數(shù) def calculate(expr): 模擬計算器工具 try: result eval(expr) # 注意真實項目中不要直接用 eval這里僅為演示 return str(result) except Exception as e: return f計算失敗: {e} # 2. 定義工具注冊表 TOOLS { calculate: calculate, } # 3. 模擬大模型決定調(diào)用哪個工具 def decide_next_action(user_query): 真實場景中這一步需要調(diào)用大模型讓模型輸出結(jié)構(gòu)化指令。 這里為了演示使用一個簡單規(guī)則。 if 計算 in user_query or 等于 in user_query or 幾 in user_query: return {action: calculate, args: extract_expr(user_query)} return {action: finish, args: {}} def extract_expr(query): # 簡化實現(xiàn)從問題中截取數(shù)字和運(yùn)算符 import re expr re.search(r[\d\-*/().\s], query) if expr: return expr.group().strip() return 0 # 4. Agent 主循環(huán) def run_agent(user_query): max_steps 3 current_query user_query for _ in range(max_steps): action decide_next_action(current_query) print(f當(dāng)前指令: {action}) if action[action] finish: print(Agent 結(jié)束沒有可執(zhí)行工具。) return if action[action] in TOOLS: result TOOLS[action[action]](**action[args]) print(f工具返回: {result}) current_query f上一步結(jié)果為{result}請繼續(xù)判斷 else: print(未知工具結(jié)束。) return if __name__ __main__: run_agent(15加27等于幾)這段代碼把 Agent 的核心循環(huán)簡化成了“決策-調(diào)用-觀察-再決策”。真實項目里decide_next_action是由大模型實現(xiàn)的模型會輸出 JSON 格式的工具調(diào)用指令。但整體的控制流思想是一樣的。6.3 Agent 開發(fā)的常見陷阱Agent 開發(fā)雖然熱門但工程落地并不容易。常見陷阱有幾個陷阱說明應(yīng)對方式無限循環(huán)Agent 反復(fù)調(diào)用工具停不下來設(shè)置最大步驟數(shù)、超時控制、人工確認(rèn)點(diǎn)工具參數(shù)錯誤模型生成的工具參數(shù)格式不對對工具輸入做嚴(yán)格校驗必要時讓模型先思考再生成錯誤累積前一步判斷錯誤導(dǎo)致后面全錯在關(guān)鍵節(jié)點(diǎn)讓結(jié)果可觀測、可回滾權(quán)限邊界Agent 執(zhí)行了不該執(zhí)行的操作嚴(yán)格限制工具權(quán)限重要操作加二次確認(rèn)成本失控每輪都調(diào)大模型Token 消耗過高增加緩存、減少無關(guān)上下文、設(shè)置預(yù)算上限我的建議是先從受控場景開始不要一上來就做一個完全自主的通用 Agent。比如先做一個只能在測試環(huán)境執(zhí)行命令的運(yùn)維助手或者先做一個只能查詢只讀數(shù)據(jù)庫的問答機(jī)器人。等機(jī)制成熟了再逐步擴(kuò)大權(quán)限范圍。7. 技術(shù)人轉(zhuǎn)型避坑指南常見誤區(qū)與解決思路轉(zhuǎn)型過程中開發(fā)者最容易踩的坑不是技術(shù)不會而是方向錯誤。下面這張表總結(jié)了幾個高頻誤區(qū)。誤區(qū)典型表現(xiàn)正確思路拼命學(xué) Prompt不做工程整天研究“咒語”怎么寫但不會寫生產(chǎn)級代碼Prompt 只是能力的一部分工程化、評估、部署才是核心只學(xué)調(diào) API會調(diào)用大模型接口但不理解模型邊界要懂提示詞設(shè)計、上下文窗口、輸出格式約束、成本控制忽視業(yè)務(wù)理解認(rèn)為技術(shù)好就能不被淘汰懂業(yè)務(wù)的人才知道 AI 該用在哪里、怎么評估效果拒絕使用 AI覺得 AI 生成代碼不可靠堅持手寫一切把 AI 當(dāng)成“結(jié)對編程伙伴”用測試約束它的輸出盲目使用 AI不做代碼審查直接把 AI 輸出扔到生產(chǎn)建立人工審核、測試、觀測、回滾機(jī)制后再上線忽略軟技能只會悶頭寫代碼不表達(dá)、不溝通定義問題、推進(jìn)協(xié)作、向上匯報都是護(hù)城河的一部分這里我想特別強(qiáng)調(diào)一點(diǎn)不要把“學(xué) AI”當(dāng)成一門單獨(dú)的課而是要把它融入到你現(xiàn)有的技術(shù)體系里。比如你是后端開發(fā)者那你要研究的是“如何在我的 Spring Boot 服務(wù)里集成大模型能力”你是數(shù)據(jù)開發(fā)者那你要研究的是“如何用 RAG 讓數(shù)據(jù)問答更可靠”你是前端開發(fā)者那你要研究的是“如何把 AI 能力和交互體驗結(jié)合”。這樣學(xué)習(xí)知識是長在業(yè)務(wù)場景里的而不是漂在空中的概念。8. AI 時代開發(fā)者行動清單與學(xué)習(xí)路線8.1 近期行動清單1-2 周如果你想開始做出改變不需要等到“學(xué)完所有東西再行動”可以按下面這個清單起步選一個你最熟悉的業(yè)務(wù)場景把其中重復(fù)性最高的任務(wù)列出來。用 AI 編程助手嘗試完成其中一個小任務(wù)并寫最少 5 個測試用例。搭一個最小的 RAG 項目把內(nèi)部文檔作為知識庫做一次問答體驗。挑一個你最近寫的模塊讓 AI 做一次代碼審查逐條驗證它提出的問題。把學(xué)習(xí)過程記錄下來形成自己的案例庫。8.2 中期學(xué)習(xí)路線1-3 個月再往后你可以按照下面幾個方向逐步深入AI 工程實踐學(xué)習(xí)如何搭建大模型應(yīng)用包括提示詞工程、RAG、Agent、評估、部署調(diào)優(yōu)。模型部署基礎(chǔ)了解量化、推理加速、GPU 顯存占用、接口網(wǎng)關(guān)等概念。不需要成為算法專家但要能聽懂“部署一個模型”的工程成本。數(shù)據(jù)工程理解結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)、向量化、數(shù)據(jù)清洗在大模型應(yīng)用中的角色。穩(wěn)定性建設(shè)學(xué)會給 AI 應(yīng)用加監(jiān)控、加日志、加人工兜底保證上線后可運(yùn)維。8.3 長期定位建議從長期來看技術(shù)人不需要把自己定義為“會寫代碼的人”更合適的定義是“能利用技術(shù)解決業(yè)務(wù)問題的人”。AI 會繼續(xù)改變代碼的生產(chǎn)方式但有一個事實不會變問題永遠(yuǎn)需要人來定義風(fēng)險永遠(yuǎn)需要人來承擔(dān)系統(tǒng)永遠(yuǎn)需要人來設(shè)計。所以我給你的建議是保持對業(yè)務(wù)的敏感度不要只盯著代碼倉庫。保持工程上的嚴(yán)謹(jǐn)不要因為 AI 生成了代碼就放棄審查。保持持續(xù)學(xué)習(xí)但學(xué)習(xí)一定要圍繞實際場景展開。保持開放心態(tài)AI 是工具不是敵人也不是神。回到開頭那句話“I feel like I dug my own grave.”如果你想避免這種感受方法其實不復(fù)雜不要在坑里繼續(xù)只做“挖土”的動作而是抬起頭看看整片工地學(xué)著去設(shè)計挖掘路線、調(diào)配資源、控制風(fēng)險。技術(shù)人的職業(yè)安全感從來不來自某個工具或某一項技能而來自你解決問題、創(chuàng)造價值的綜合能力。希望這篇文章能成為你調(diào)整方向的一塊路標(biāo)。下一步挑一個方向動手做一個小項目比什么都重要。