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