1. 為什么我要把AI助手改造成專屬后端開發(fā)搭子剛接觸AI編程助手那會兒我跟大多數(shù)人一樣把它當(dāng)成一個高級點的代碼補全工具——敲幾個字符它幫我補全一行寫個函數(shù)名它幫我生成個大概框架。用了一段時間之后我發(fā)現(xiàn)這玩意兒的能力遠(yuǎn)不止于此問題出在我自己身上我一直在用“通用助手”的方式去使喚一個本可以深度定制的工具。打個比方你招了一個知識面極廣的實習(xí)生什么語言都懂一點什么框架都能聊兩句。但你讓他幫你寫后端接口他給你的代碼風(fēng)格跟你團隊規(guī)范不一致你讓他幫你排查線上問題他缺少你項目的上下文信息你讓他幫你做代碼審查他不知道你們團隊踩過哪些坑、有哪些約定俗成的紅線。結(jié)果就是他給的答案“能用但不好用”你每次還得花大量時間做二次加工。自定義智能體要解決的就是這個問題。它允許你給AI助手預(yù)設(shè)角色、注入項目上下文、綁定工具鏈、設(shè)定行為邊界把一個“什么都懂一點的通才”變成“深度理解你項目、遵循你團隊規(guī)范、能調(diào)用你常用工具”的專屬后端開發(fā)搭子。我花了大概三周時間在日常后端開發(fā)工作中反復(fù)打磨這套工作流從接口設(shè)計、代碼生成、單元測試到問題排查逐步把AI助手嵌入到了整個開發(fā)鏈路里。這篇文章就是我這段時間的實戰(zhàn)總結(jié)適合有一定后端開發(fā)經(jīng)驗、想讓AI助手真正融入日常工作流的開發(fā)者參考。不管你是剛接觸AI編程助手的新手還是已經(jīng)用了一段時間但覺得“也就那樣”的老用戶相信都能從中找到可以直接抄作業(yè)的思路和配置。2. 自定義智能體到底改了什么核心機制拆解2.1 從“通用對話”到“角色綁定”的底層邏輯普通AI編程助手的工作模式是“你問我答”每次對話都是獨立的它不記得你上次說了什么也不知道你的項目長什么樣。自定義智能體的核心變化在于三個層面角色預(yù)設(shè)、上下文注入、工具綁定。角色預(yù)設(shè)解決的是“你是誰”的問題。你可以告訴它“你是一個有八年經(jīng)驗的Java后端工程師熟悉Spring生態(tài)注重代碼可讀性和異常處理”這樣它生成的代碼風(fēng)格、注釋習(xí)慣、異常處理方式都會向這個角色靠攏。上下文注入解決的是“你在什么項目里工作”的問題。你可以把項目的目錄結(jié)構(gòu)、核心依賴版本、數(shù)據(jù)庫表結(jié)構(gòu)、接口規(guī)范文檔喂給它讓它在回答問題時自動帶上這些背景信息。工具綁定解決的是“你能調(diào)用什么”的問題。你可以讓它直接讀取項目文件、執(zhí)行終端命令、調(diào)用內(nèi)部API文檔而不是每次都要你手動復(fù)制粘貼。這三個層面疊加起來效果是質(zhì)變的。我實測下來同一個接口生成任務(wù)通用助手給出的代碼我需要改40%左右而經(jīng)過角色預(yù)設(shè)和上下文注入的自定義智能體需要改動的比例降到了10%以內(nèi)。這個差距在日積月累的開發(fā)工作中非?？捎^。2.2 后端開發(fā)場景下最值得定制的三個方向不是所有場景都值得花時間做自定義智能體。根據(jù)我的經(jīng)驗后端開發(fā)中有三個方向投入產(chǎn)出比最高接口代碼生成。后端開發(fā)有大量重復(fù)性的CRUD接口編寫工作這部分最適合交給自定義智能體。你只需要把項目的Controller層規(guī)范、Service層分層邏輯、DTO轉(zhuǎn)換規(guī)則、統(tǒng)一異常處理方式預(yù)設(shè)進去它就能生成高度符合項目風(fēng)格的接口代碼。代碼審查與規(guī)范檢查。每個團隊都有自己的代碼規(guī)范比如“禁止在Controller層寫業(yè)務(wù)邏輯”“所有數(shù)據(jù)庫操作必須走DAO層”“接口返回值必須統(tǒng)一包裝”等等。把這些規(guī)范寫成審查規(guī)則注入智能體它就能在你提交代碼前幫你做一輪自動化審查比人工Review效率高得多。問題排查輔助。后端排查線上問題往往需要結(jié)合日志、監(jiān)控指標(biāo)、數(shù)據(jù)庫狀態(tài)、近期變更記錄等多維信息。自定義智能體可以綁定你的日志查詢工具和監(jiān)控面板當(dāng)你描述一個異?，F(xiàn)象時它能自動拉取相關(guān)日志和指標(biāo)給出更有針對性的排查建議而不是泛泛地告訴你“檢查一下數(shù)據(jù)庫連接”。2.3 一個關(guān)鍵認(rèn)知智能體不是越復(fù)雜越好我剛開始折騰的時候恨不得把所有能想到的規(guī)則、文檔、工具都塞進去結(jié)果發(fā)現(xiàn)效果反而不好。原因很簡單信息過載。當(dāng)你給智能體的上下文太多太雜時它抓不住重點生成的回答反而變得模棱兩可。后來我調(diào)整了策略每個智能體只聚焦一個具體場景。比如“接口生成智能體”就只管接口代碼生成不摻和代碼審查的事“排查助手智能體”就只管問題定位不負(fù)責(zé)寫新代碼。這樣每個智能體的預(yù)設(shè)規(guī)則可以寫得更精準(zhǔn)上下文也可以控制在一個合理的范圍內(nèi)。實測下來聚焦單一場景的智能體輸出質(zhì)量比“萬能智能體”高出不止一個檔次。3. 手把手搭建后端開發(fā)專屬智能體3.1 環(huán)境準(zhǔn)備與基礎(chǔ)配置在開始之前你需要確認(rèn)你的AI編程助手支持自定義智能體功能。目前主流的一些AI編程工具都陸續(xù)開放了這類能力具體入口一般在設(shè)置或擴展面板里。我用的工具支持通過配置文件的方式定義智能體這種方式的好處是可以版本化管理團隊里每個人都能共享同一套配置。基礎(chǔ)配置我建議從以下幾個維度入手角色描述用兩三句話定義智能體的專業(yè)背景和行事風(fēng)格。比如“你是一名資深后端工程師擅長Java和Go注重代碼的健壯性和可維護性回答時優(yōu)先給出可運行的代碼示例”。技術(shù)棧聲明明確列出項目使用的語言版本、框架版本、數(shù)據(jù)庫類型、中間件等。這一步很關(guān)鍵因為不同版本之間的API差異很大不聲明清楚的話生成的代碼可能跑不起來。輸出格式約定告訴它你希望的回答格式。比如“代碼塊請標(biāo)注語言類型”“涉及多個步驟時用有序列表”“需要對比時用表格呈現(xiàn)”。這里有一個我踩過的坑一開始我沒有約定輸出格式結(jié)果它有時候給一大段文字描述有時候給代碼但不標(biāo)注語言有時候把配置和代碼混在一起讀起來很費勁。后來我在預(yù)設(shè)里加了一段輸出格式約定閱讀效率立刻上來了。3.2 注入項目上下文讓智能體真正懂你的項目這一步是自定義智能體區(qū)別于通用助手的關(guān)鍵。你需要把項目的核心上下文信息整理成結(jié)構(gòu)化的文檔注入到智能體的知識庫里。我一般會準(zhǔn)備以下幾類材料項目結(jié)構(gòu)說明。用樹形結(jié)構(gòu)列出主要目錄和關(guān)鍵文件的作用。不需要列出每一個文件但Controller層、Service層、DAO層、工具類、配置文件這些核心目錄要寫清楚。這樣智能體在生成代碼時就知道該把文件放在哪個位置。接口規(guī)范文檔。包括URL命名規(guī)范、請求方法約定、參數(shù)校驗規(guī)則、返回值格式、錯誤碼定義等。這部分越詳細(xì)越好因為接口代碼生成是最高頻的使用場景。數(shù)據(jù)庫表結(jié)構(gòu)。至少包含核心業(yè)務(wù)表的字段定義和關(guān)聯(lián)關(guān)系。如果表特別多可以只注入當(dāng)前開發(fā)涉及的那幾張表。常用工具類和方法。列出項目中已經(jīng)封裝好的工具類及其主要方法這樣智能體在生成代碼時會優(yōu)先復(fù)用現(xiàn)有工具而不是重新造輪子。我通常把這些材料放在一個Markdown文件里按章節(jié)組織好然后通過智能體的知識庫功能導(dǎo)入。導(dǎo)入之后每次對話它都會自動參考這些上下文。實測下來有了項目上下文之后生成的代碼直接能跑的比例從不到一半提升到了八成以上。3.3 綁定工具鏈打通開發(fā)環(huán)境的最后一公里工具綁定是讓智能體從“顧問”變成“搭檔”的關(guān)鍵一步。以我自己的配置為例我綁定了以下幾個工具文件讀寫工具允許智能體直接讀取項目中的源代碼文件也允許它把生成的代碼寫入指定文件。這樣我就不用來回復(fù)制粘貼了。終端執(zhí)行工具允許它執(zhí)行編譯、運行測試、查看日志等命令。比如我讓它生成一個接口之后可以直接讓它跑一下單元測試驗證。數(shù)據(jù)庫查詢工具允許它執(zhí)行只讀的SQL查詢用于排查數(shù)據(jù)相關(guān)的問題。接口文檔查詢工具允許它查詢內(nèi)部接口文檔系統(tǒng)獲取最新的接口定義和變更記錄。綁定工具的時候要注意權(quán)限控制。我建議遵循最小權(quán)限原則只開放當(dāng)前場景必需的權(quán)限寫操作和刪除操作要格外謹(jǐn)慎。比如數(shù)據(jù)庫工具我只開放了SELECT權(quán)限終端工具禁止執(zhí)行刪除文件和修改系統(tǒng)配置的命令。這些限制在配置里都可以設(shè)置。3.4 配置文件的完整示例與參數(shù)解讀下面是我實際使用的一個智能體配置文件的核心結(jié)構(gòu)以YAML格式為例agent: name: backend-dev-assistant role: | 你是一名有十年經(jīng)驗的Java后端工程師熟悉Spring Boot 3.x、 MyBatis-Plus、Redis、RabbitMQ。注重代碼分層清晰、異常處理完善、 日志記錄規(guī)范?；卮饡r優(yōu)先給出可直接運行的代碼并附帶關(guān)鍵注釋。 context: - type: file path: ./docs/project-structure.md - type: file path: ./docs/api-spec.md - type: file path: ./docs/db-schema.md tools: - name: file-reader enabled: true permissions: [read] - name: file-writer enabled: true permissions: [write] allowed-paths: [./src/main/java] - name: terminal enabled: true allowed-commands: [mvn test, mvn compile, cat *.log] - name: db-query enabled: true permissions: [select] output: format: markdown code-block-language: true max-response-length: 3000幾個關(guān)鍵參數(shù)值得展開說一下。role字段里的描述要具體不要寫“你是一個優(yōu)秀的程序員”這種空話要寫清楚技術(shù)棧、經(jīng)驗?zāi)晗?、關(guān)注點。context部分支持多種類型除了文件還可以是URL、純文本片段等。tools里的allowed-paths和allowed-commands是安全邊界一定要設(shè)置否則智能體可能會誤操作不該動的文件。output里的max-response-length用來控制單次回答的長度太長了閱讀體驗差太短了信息不夠我一般設(shè)在2000到3000字之間。4. 后端開發(fā)全鏈路實戰(zhàn)從接口設(shè)計到問題排查4.1 接口設(shè)計與代碼生成十分鐘完成一個標(biāo)準(zhǔn)CRUD先說說我日常用得最多的場景生成一個標(biāo)準(zhǔn)的CRUD接口。以前我手動寫一個完整的CRUD接口包括Controller、Service、DAO、DTO、單元測試大概需要四十分鐘到一個小時。用了自定義智能體之后這個時間壓縮到了十分鐘左右。具體操作流程是這樣的我先用自然語言描述需求比如“幫我生成一個訂單查詢接口支持按訂單號、用戶ID、訂單狀態(tài)、時間范圍四個條件分頁查詢返回值需要包含訂單基本信息和商品明細(xì)”。然后智能體會自動完成以下步驟根據(jù)項目結(jié)構(gòu)說明確定各個文件應(yīng)該放在哪個目錄下。根據(jù)接口規(guī)范文檔生成符合團隊規(guī)范的Controller層代碼包括URL路徑、請求方法、參數(shù)校驗注解。根據(jù)分層邏輯生成Service層接口和實現(xiàn)類包含分頁查詢的核心邏輯。根據(jù)數(shù)據(jù)庫表結(jié)構(gòu)生成對應(yīng)的查詢條件和返回DTO。根據(jù)單元測試規(guī)范生成對應(yīng)的測試用例。生成完之后我會快速過一遍代碼重點檢查幾個地方參數(shù)校驗是否完整、分頁邏輯是否正確、返回值包裝是否符合規(guī)范、異常處理是否到位。確認(rèn)沒問題后直接讓智能體把代碼寫入對應(yīng)文件然后跑一下編譯和測試。這里有一個實操心得描述需求的時候盡量把邊界條件也說清楚。比如“時間范圍參數(shù)如果為空則不參與過濾”“訂單狀態(tài)支持多選”“分頁大小默認(rèn)20最大100”。這些細(xì)節(jié)如果你不說智能體可能會按自己的理解來生成的結(jié)果就不一定符合你的預(yù)期。4.2 代碼審查自動化把團隊規(guī)范變成可執(zhí)行的檢查規(guī)則代碼審查是另一個讓我覺得“回不去了”的場景。以前團隊里做Code Review每個人關(guān)注的點不一樣有的人看邏輯有的人看風(fēng)格有的人看安全經(jīng)常漏掉一些問題。現(xiàn)在我把團隊的代碼規(guī)范整理成了審查規(guī)則注入到智能體里每次提交代碼前先跑一輪自動審查。審查規(guī)則我分了幾個類別分層規(guī)范類。比如“Controller層不允許直接調(diào)用DAO層”“Service層不允許出現(xiàn)HttpServletRequest”“DAO層不允許寫業(yè)務(wù)邏輯判斷”。這類規(guī)則用自然語言描述清楚就行智能體能理解。異常處理類。比如“所有外部調(diào)用必須捕獲異常并記錄日志”“不允許吞掉異常”“自定義異常必須繼承統(tǒng)一基類”。這類規(guī)則我會附上正反示例幫助智能體更準(zhǔn)確地判斷。安全規(guī)范類。比如“SQL查詢必須使用參數(shù)化查詢”“用戶輸入必須做校驗和轉(zhuǎn)義”“敏感信息不允許打印到日志”。這類規(guī)則是紅線違反了直接標(biāo)記為嚴(yán)重問題。性能規(guī)范類。比如“循環(huán)內(nèi)不允許查詢數(shù)據(jù)庫”“批量操作必須使用批量接口”“大列表查詢必須分頁”。這類規(guī)則我會標(biāo)注建議級別不強制但提醒開發(fā)者注意。實際使用的時候我把代碼文件路徑告訴智能體它就會逐文件、逐方法地檢查最后輸出一份審查報告按嚴(yán)重程度分級列出問題并給出修改建議。我統(tǒng)計過自動審查能覆蓋大約70%的常見問題剩下30%需要人工判斷的通常是業(yè)務(wù)邏輯層面的問題。這個覆蓋率已經(jīng)幫我節(jié)省了大量Review時間。4.3 單元測試生成與邊界條件覆蓋寫單元測試是很多后端開發(fā)者的痛點——知道重要但寫起來費時間。自定義智能體在這個場景下也能幫上大忙。我的做法是先生成接口代碼然后直接讓智能體基于接口代碼生成對應(yīng)的單元測試。生成測試用例的時候我會特別要求它覆蓋以下幾類邊界條件參數(shù)為空或null每個必填參數(shù)都測一遍傳空的情況。參數(shù)格式錯誤比如日期格式不對、數(shù)字傳了字母、枚舉值超出范圍。業(yè)務(wù)邊界值比如分頁頁碼為0或負(fù)數(shù)、分頁大小超過最大值、金額為0或負(fù)數(shù)。并發(fā)場景對于涉及狀態(tài)變更的接口要求生成并發(fā)測試用例。異常路徑模擬數(shù)據(jù)庫連接失敗、外部服務(wù)超時等異常情況驗證異常處理邏輯是否正確。這里有一個我踩過的坑一開始我讓智能體生成測試用例它只生成了正常路徑的測試邊界條件一個都沒覆蓋。后來我在預(yù)設(shè)里明確要求“每個接口的測試用例必須包含至少三個邊界條件測試”情況才改善。所以預(yù)設(shè)規(guī)則一定要寫具體不能指望它自己領(lǐng)悟。另外生成的測試用例我建議跑一遍再提交。有時候智能體對某些工具類的Mock方式理解不對生成的測試跑不起來需要手動調(diào)整。但總體來說即使需要調(diào)整也比從零開始寫快得多。4.4 線上問題排查讓智能體幫你讀日志和指標(biāo)線上問題排查是我最近才開始嘗試的場景效果出乎意料地好。以前排查一個線上異常我需要登錄服務(wù)器看日志、打開監(jiān)控面板看指標(biāo)、查數(shù)據(jù)庫確認(rèn)數(shù)據(jù)狀態(tài)一套流程下來至少十幾分鐘。現(xiàn)在我把日志查詢工具和監(jiān)控查詢工具綁定到智能體上直接用自然語言描述問題它就能自動拉取相關(guān)信息并給出分析。舉個例子有一次線上反饋“訂單查詢接口偶爾超時”。我把這個現(xiàn)象告訴智能體它自動執(zhí)行了以下操作查詢該接口最近一小時的響應(yīng)時間指標(biāo)發(fā)現(xiàn)確實有幾個時間點的P99超過了閾值。拉取對應(yīng)時間段的慢查詢?nèi)罩径ㄎ坏揭粭lSQL執(zhí)行時間異常。查詢該SQL對應(yīng)的數(shù)據(jù)庫表狀態(tài)發(fā)現(xiàn)該表近期數(shù)據(jù)量增長較快且缺少一個關(guān)鍵索引。給出建議添加復(fù)合索引并調(diào)整查詢條件順序。整個過程不到三分鐘而且它給出的分析比我手動排查還要全面因為它不會漏掉任何一個維度的信息。當(dāng)然最終的決策還是由我來做——加索引這種操作需要評估對寫入性能的影響不能盲目執(zhí)行。但至少排查階段的時間被大幅壓縮了。這里要特別提醒綁定日志和監(jiān)控工具的時候一定要做好權(quán)限隔離。我用的日志查詢工具是只讀的監(jiān)控工具也是只讀的智能體只能看不能改。另外涉及敏感數(shù)據(jù)的日志字段比如用戶手機號、身份證號在注入之前要做脫敏處理避免隱私泄露。5. 踩坑實錄與常見問題速查5.1 智能體“不聽話”的幾種典型情況及解法用自定義智能體的過程中最讓人頭疼的就是“不聽話”——你明明預(yù)設(shè)了規(guī)則它就是不遵守。我總結(jié)了幾種典型情況和對應(yīng)對策情況一生成的代碼風(fēng)格與預(yù)設(shè)不符。這通常是因為預(yù)設(shè)描述太籠統(tǒng)。比如你寫“遵循項目代碼規(guī)范”它不知道具體是什么規(guī)范。解法是把規(guī)范拆成具體的、可執(zhí)行的條目比如“類名使用大駝峰方法名使用小駝峰常量全大寫加下劃線”。情況二忽略了項目上下文信息。這可能是因為上下文文檔太長關(guān)鍵信息被淹沒了。解法是把最重要的信息放在文檔開頭并用加粗或標(biāo)題標(biāo)記出來。另外上下文文檔不要超過智能體的上下文窗口限制太長了反而效果差。情況三工具調(diào)用失敗或調(diào)用錯誤的工具。這通常是因為工具描述不夠清晰。每個工具都要寫清楚用途、參數(shù)格式、返回值格式。比如“db-query工具用于執(zhí)行只讀SQL查詢參數(shù)為SQL語句字符串返回JSON格式的查詢結(jié)果”。情況四回答越來越短或越來越敷衍。這可能是對話輪次太多導(dǎo)致的上下文漂移。解法是定期開啟新對話或者把關(guān)鍵規(guī)則在每輪對話中重復(fù)強調(diào)。5.2 上下文注入的常見誤區(qū)與優(yōu)化策略上下文注入是自定義智能體最核心也最容易出問題的環(huán)節(jié)。我踩過的坑包括誤區(qū)一把所有文檔一股腦全塞進去。結(jié)果智能體抓不住重點回答質(zhì)量反而下降。優(yōu)化策略是分層注入核心規(guī)范放在主上下文里詳細(xì)文檔按需加載。誤區(qū)二上下文文檔格式混亂。有的是純文本有的是表格有的是代碼塊智能體解析起來容易出錯。優(yōu)化策略是統(tǒng)一用Markdown格式結(jié)構(gòu)清晰層級分明。誤區(qū)三注入了一次就不管了。項目在迭代規(guī)范在更新但上下文文檔還是老版本。優(yōu)化策略是建立定期更新機制每次項目有重大變更時同步更新上下文文檔。誤區(qū)四忽略了上下文的優(yōu)先級。當(dāng)多個文檔之間有沖突時智能體不知道該聽誰的。優(yōu)化策略是在文檔開頭聲明優(yōu)先級比如“本文檔中的規(guī)范優(yōu)先級高于其他文檔”。5.3 性能與成本平衡什么時候該用自定義智能體自定義智能體雖然好用但也不是所有場景都適合。我總結(jié)了一個簡單的判斷標(biāo)準(zhǔn)場景特征適合用自定義智能體適合用通用助手任務(wù)重復(fù)性高每天都要做低偶爾做一次項目上下文依賴強需要了解項目細(xì)節(jié)弱通用知識即可規(guī)范要求嚴(yán)格有明確規(guī)范寬松能用就行輸出一致性要求高需要統(tǒng)一風(fēng)格低每次不一樣也無所謂配置維護成本可接受一次配置長期使用不值得用一次就扔按照這個標(biāo)準(zhǔn)接口代碼生成、代碼審查、單元測試生成這三個場景非常適合自定義智能體因為它們是高頻、強上下文依賴、有明確規(guī)范的任務(wù)。而一些一次性的腳本編寫、技術(shù)方案調(diào)研等場景用通用助手就夠了沒必要花時間配置智能體。另外成本也是需要考慮的因素。自定義智能體因為要加載大量上下文和調(diào)用工具單次對話的token消耗通常比通用助手高不少。我建議對智能體的使用做一定的監(jiān)控看看哪些場景的投入產(chǎn)出比最高把資源集中在最有價值的地方。5.4 團隊協(xié)作中的智能體配置管理如果你是在團隊里推廣自定義智能體配置管理是一個繞不開的問題。我的做法是配置文件版本化。把智能體配置文件放在項目的代碼倉庫里跟代碼一起做版本管理。這樣每個人拉取最新代碼后智能體配置也是最新的。規(guī)范文檔集中維護。接口規(guī)范、代碼規(guī)范、數(shù)據(jù)庫文檔這些上下文材料統(tǒng)一放在一個文檔目錄下指定專人維護更新。定期同步與反饋。每周或每兩周做一次簡短的同步收集大家在使用智能體過程中遇到的問題集中優(yōu)化配置。我試過讓每個人自己維護自己的配置結(jié)果就是各搞各的規(guī)范執(zhí)行不到位后來改成統(tǒng)一配置加個性化覆蓋的方式效果好很多。新人上手引導(dǎo)。新加入的開發(fā)者第一件事就是配置好智能體環(huán)境然后通過幾個預(yù)設(shè)的示例任務(wù)快速熟悉使用方式。這比看文檔學(xué)得快多了。6. 我個人的一些實操體會這套自定義智能體加后端開發(fā)工作流的組合我用了大概三個月最大的感受是它改變的不是我寫代碼的速度而是我分配時間的方式。以前我大概60%的時間花在寫重復(fù)性的接口代碼和測試上30%花在排查問題和代碼審查上10%花在設(shè)計和技術(shù)調(diào)研上。現(xiàn)在重復(fù)性編碼的時間壓縮到了20%左右省下來的時間我可以更多地花在架構(gòu)設(shè)計、技術(shù)方案對比、性能優(yōu)化這些更有價值的事情上。當(dāng)然它也不是銀彈。有些場景它確實幫不上忙比如復(fù)雜的業(yè)務(wù)邏輯設(shè)計、跨系統(tǒng)的架構(gòu)決策、需要跟產(chǎn)品經(jīng)理反復(fù)溝通的需求澄清。這些還是得靠人。我的建議是把它當(dāng)成一個執(zhí)行力很強但需要明確指令的搭檔你負(fù)責(zé)想清楚要做什么、怎么做它負(fù)責(zé)快速執(zhí)行和查漏補缺。最后分享一個小技巧每次智能體給出了一個特別好的回答我會把它保存下來作為后續(xù)類似任務(wù)的參考示例。積累多了之后這些示例本身就成了最好的上下文材料比任何文檔都管用。這個習(xí)慣我堅持了三個月現(xiàn)在我的智能體回答質(zhì)量比剛開始的時候又上了一個臺階。