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