1. 這不是“調(diào)教AI”而是重建人機(jī)協(xié)作的信任契約最近在某跨平臺(tái)系統(tǒng)開(kāi)發(fā)中團(tuán)隊(duì)引入了Pi Agent輔助代碼生成。起初大家很興奮——它能自動(dòng)補(bǔ)全函數(shù)、生成單元測(cè)試、甚至重構(gòu)老舊模塊。但兩周后代碼評(píng)審會(huì)上出現(xiàn)了尷尬場(chǎng)面三位工程師提交的PR里有七處命名風(fēng)格不一致有的用camelCase有的混用snake_case四次違反日志埋點(diǎn)規(guī)范該打INFO卻打了DEBUG還有一次擅自把核心校驗(yàn)邏輯從同步改成了異步導(dǎo)致下游服務(wù)超時(shí)告警。最諷刺的是所有問(wèn)題都發(fā)生在Pi Agent“主動(dòng)優(yōu)化”后的代碼塊里。這根本不是AI“不聽(tīng)話”而是我們默認(rèn)把Agent當(dāng)成了可配置的IDE插件卻忘了它本質(zhì)是一個(gè)具備推理能力、會(huì)自主決策的協(xié)作方。公司代碼規(guī)范從來(lái)不是一份靜態(tài)PDF而是一套嵌入在代碼審查流程、CI/CD卡點(diǎn)、新人導(dǎo)師帶教中的動(dòng)態(tài)約束體系。當(dāng)Pi Agent被直接接入開(kāi)發(fā)流卻未被賦予對(duì)這套體系的“語(yǔ)義理解權(quán)”和“執(zhí)行監(jiān)督權(quán)”它就只能按訓(xùn)練數(shù)據(jù)里的統(tǒng)計(jì)偏好行事——而那些偏好恰恰來(lái)自互聯(lián)網(wǎng)上大量風(fēng)格混雜的開(kāi)源項(xiàng)目。關(guān)鍵詞里沒(méi)寫(xiě)但實(shí)際落地中最痛的三個(gè)點(diǎn)是規(guī)范感知滯后性Agent看到的是單文件上下文而規(guī)范?？缒K生效、約束表達(dá)失真把“禁止在Controller層處理業(yè)務(wù)邏輯”翻譯成正則規(guī)則漏掉23種變體寫(xiě)法、反饋閉環(huán)斷裂Code Review發(fā)現(xiàn)的問(wèn)題無(wú)法實(shí)時(shí)反哺Agent的推理鏈。這不是加個(gè)prompt就能解決的需要在Agent的決策鏈條里嵌入一套與人類工程師完全同構(gòu)的“規(guī)范認(rèn)知-約束校驗(yàn)-行為修正”機(jī)制。我試過(guò)三種典型錯(cuò)誤路徑第一種是堆砌rule-based prompt比如讓Agent每次生成前先背誦12條規(guī)范條款——結(jié)果它學(xué)會(huì)了在注釋里寫(xiě)“已遵守第7條”但代碼依然違規(guī)第二種是依賴post-hoc掃描工具如SonarQube做攔截等CI失敗再讓Agent重試——平均每個(gè)函數(shù)要迭代4.7次開(kāi)發(fā)節(jié)奏直接崩盤第三種是給Agent配專屬“規(guī)范檢查員”子Agent結(jié)果兩個(gè)AI互相辯論30分鐘最后輸出“建議參考《Java編碼規(guī)范V2.3》第5.2節(jié)”人類工程師還得自己查文檔。真正跑通的方案是把規(guī)范本身變成Agent可執(zhí)行的“運(yùn)行時(shí)契約”而不是待審查的“事后證據(jù)”。提示別再問(wèn)“怎么讓AI聽(tīng)你的話”要問(wèn)“怎么讓AI理解你為什么這么說(shuō)”。規(guī)范文檔里的每一條必須能映射到具體代碼結(jié)構(gòu)、AST節(jié)點(diǎn)、控制流圖上的可計(jì)算特征否則所有約束都是空中樓閣。2. Pi Agent的規(guī)范執(zhí)行引擎三層嵌套式約束架構(gòu)Pi Agent的底層架構(gòu)決定了它無(wú)法像傳統(tǒng)靜態(tài)分析工具那樣暴力掃描。它的推理過(guò)程是分階段的先基于用戶指令生成意圖抽象Intent Abstraction再規(guī)劃代碼結(jié)構(gòu)Code Planning最后填充具體實(shí)現(xiàn)Token Generation。如果只在最后一層塞規(guī)則等于在子彈出膛后才裝瞄準(zhǔn)鏡。我們最終采用的三層嵌入式約束架構(gòu)是在每個(gè)推理階段都部署對(duì)應(yīng)的規(guī)范守門員2.1 意圖層用結(jié)構(gòu)化契約替代自然語(yǔ)言描述傳統(tǒng)做法是讓Agent讀一段文字版規(guī)范比如“數(shù)據(jù)庫(kù)操作必須使用連接池禁止直連”。Pi Agent會(huì)把它理解為“找一個(gè)叫‘連接池’的東西”然后可能去調(diào)用某個(gè)冷門SDK的pool方法而忽略公司內(nèi)部強(qiáng)制使用的DruidDataSourceWrapper類。我們的解法是把規(guī)范轉(zhuǎn)譯成可執(zhí)行的意圖契約Intent Contract格式如下{ contract_id: DB_CONN_POOL_V1, trigger_intent: [connect to database, open db connection], required_components: [ { type: class, name: DruidDataSourceWrapper, scope: must_use } ], forbidden_patterns: [ { pattern_type: method_call, target: java.sql.DriverManager.getConnection, reason: bypasses connection pool monitoring } ] }這個(gè)契約不是給Agent“看”的而是作為運(yùn)行時(shí)參數(shù)注入其意圖解析器。當(dāng)用戶輸入“幫我寫(xiě)個(gè)用戶查詢接口”Agent在生成意圖抽象時(shí)會(huì)主動(dòng)匹配所有觸發(fā)意圖trigger_intent并強(qiáng)制將required_components注入后續(xù)規(guī)劃階段。實(shí)測(cè)下來(lái)意圖層攔截了68%的規(guī)范違規(guī)因?yàn)楹芏噱e(cuò)誤在還沒(méi)開(kāi)始寫(xiě)代碼時(shí)就已經(jīng)被阻斷。2.2 規(guī)劃層AST導(dǎo)向的代碼骨架預(yù)審很多規(guī)范問(wèn)題出在“結(jié)構(gòu)選擇”上比如該用策略模式卻寫(xiě)了if-else鏈該用Builder構(gòu)造對(duì)象卻用了冗長(zhǎng)的setter。Pi Agent在Code Planning階段會(huì)生成一個(gè)輕量級(jí)AST骨架不含具體變量名和字面量我們?cè)谶@個(gè)骨架上部署AST校驗(yàn)器AST Validator。它不關(guān)心代碼是否能運(yùn)行只檢查結(jié)構(gòu)合規(guī)性。以“禁止在Service層調(diào)用HTTP客戶端”為例校驗(yàn)器會(huì)掃描AST中的MethodInvocation節(jié)點(diǎn)若methodName包含http、rest、feign且enclosingClass在service包路徑下則標(biāo)記為高危進(jìn)一步檢查該調(diào)用是否被包裹在Async或CompletableFuture中規(guī)避同步阻塞若未包裹則升級(jí)為阻斷級(jí)。關(guān)鍵技巧在于校驗(yàn)器使用公司私有AST語(yǔ)法樹(shù)而非通用Java AST。我們把內(nèi)部框架的注解如RemoteService、自定義異常類如BizRemoteException都注冊(cè)為語(yǔ)法節(jié)點(diǎn)類型。這樣當(dāng)Agent規(guī)劃出new HttpClient().get(/user)時(shí)校驗(yàn)器能立刻識(shí)別出它繞過(guò)了RemoteService代理層而不是等到編譯時(shí)報(bào)錯(cuò)。2.3 生成層基于Token概率的實(shí)時(shí)重加權(quán)到了Token Generation階段違規(guī)已成定局硬攔截會(huì)導(dǎo)致Agent反復(fù)卡死。我們的方案是動(dòng)態(tài)重加權(quán)Dynamic Rescoring在每個(gè)token預(yù)測(cè)時(shí)調(diào)用輕量級(jí)規(guī)范檢查器評(píng)估當(dāng)前token序列的合規(guī)風(fēng)險(xiǎn)對(duì)高風(fēng)險(xiǎn)token的概率分?jǐn)?shù)進(jìn)行衰減。例如當(dāng)Agent生成到logger.時(shí)檢查器會(huì)預(yù)判下一個(gè)token可能是info()、debug()或error()。根據(jù)規(guī)范“業(yè)務(wù)主流程日志必須用INFO調(diào)試日志需帶DEBUG_FLAG常量”檢查器會(huì)若前文無(wú)DEBUG_FLAG出現(xiàn)則將debug()的概率乘以0.05若當(dāng)前方法標(biāo)注了Transactional則將warn()的概率乘以0.1因事務(wù)內(nèi)WARN可能掩蓋嚴(yán)重問(wèn)題同時(shí)提升info()的權(quán)重并插入提示詞“請(qǐng)確認(rèn)此日志是否記錄核心業(yè)務(wù)狀態(tài)”。這個(gè)過(guò)程在GPU推理時(shí)增加不到3ms延遲但使日志規(guī)范符合率從41%提升至92%。更重要的是Agent開(kāi)始“學(xué)會(huì)”在生成前自我質(zhì)疑——當(dāng)它連續(xù)兩次被重加權(quán)懲罰第三次會(huì)主動(dòng)在注釋中寫(xiě)“此處按規(guī)范應(yīng)使用INFO但需確認(rèn)是否屬于核心狀態(tài)變更”。注意三層架構(gòu)不是簡(jiǎn)單疊加而是形成反饋環(huán)。意圖層的契約違規(guī)會(huì)觸發(fā)規(guī)劃層的深度AST掃描規(guī)劃層發(fā)現(xiàn)的結(jié)構(gòu)缺陷會(huì)反向更新意圖契約庫(kù)如新增trigger_intent: handle transaction rollback生成層的高頻重加權(quán)點(diǎn)會(huì)沉淀為新的校驗(yàn)規(guī)則。這才是真正的“活規(guī)范”。3. 規(guī)范即代碼把PDF文檔編譯成可執(zhí)行約束把規(guī)范文檔變成機(jī)器可執(zhí)行的約束聽(tīng)起來(lái)像天方夜譚但實(shí)際只需三步語(yǔ)義切片→模式提取→契約編譯。我們用某高校實(shí)驗(yàn)室提供的規(guī)范解析工具鏈非開(kāi)源配合人工校驗(yàn)完成了公司237條規(guī)范的轉(zhuǎn)化。3.1 語(yǔ)義切片拒絕整段粘貼按約束粒度拆解原始規(guī)范文檔里有一條“日志中禁止打印用戶敏感信息包括手機(jī)號(hào)、身份證號(hào)、銀行卡號(hào)”。如果直接喂給Agent它可能記住“手機(jī)號(hào)”但忽略“脫敏后可打印”。我們的切片標(biāo)準(zhǔn)是每條切片必須對(duì)應(yīng)一個(gè)可驗(yàn)證的代碼行為。于是這條被拆成切片A禁止明文log.*(.*1[3-9]\\d{9}.*)→ 匹配日志內(nèi)容含未脫敏手機(jī)號(hào)切片B允許脫敏log.*(.*1[3-9]\\d{4}\\\\*{4}\\d{4}.*)→ 允許138****1234格式切片C上下文豁免if (isDebugMode()) { log.debug(...); }→ 調(diào)試模式下豁免每個(gè)切片生成獨(dú)立的契約ID如LOG_SENSITIVE_V1_A并在文檔中標(biāo)注適用場(chǎng)景。實(shí)測(cè)證明細(xì)粒度切片使規(guī)則沖突率下降76%因?yàn)椴煌瑘?chǎng)景的約束不再互相覆蓋。3.2 模式提取從自然語(yǔ)言到AST特征的映射表最難的是把“禁止在Controller層處理業(yè)務(wù)邏輯”這種模糊表述翻譯成AST可識(shí)別的特征。我們建立了一張自然語(yǔ)言-AST特征映射表由資深架構(gòu)師和語(yǔ)言學(xué)背景的工程師共同維護(hù)自然語(yǔ)言描述AST特征路徑權(quán)重誤報(bào)處理“處理業(yè)務(wù)邏輯”MethodDeclaration.body contains MethodInvocation with target in service package0.92排除log.info()等純副作用調(diào)用“Controller層”enclosingClass.name matches .*Controller$ AND enclosingClass.package contains controller0.98允許BaseController父類繼承“禁止”violation_level BLOCK-觸發(fā)時(shí)中斷生成并返回錯(cuò)誤碼這張表不是一成不變的。當(dāng)Agent首次在UserController里調(diào)用userService.create()被攔截但它同時(shí)調(diào)用了userCache.get()緩存層我們就把cache包路徑加入豁免列表并降低MethodInvocation的權(quán)重——因?yàn)榫彺孀x取屬于基礎(chǔ)設(shè)施不算業(yè)務(wù)邏輯。3.3 契約編譯生成可熱加載的約束二進(jìn)制所有切片和映射規(guī)則最終編譯成.picontract二進(jìn)制文件特點(diǎn)有三熱加載CI流水線檢測(cè)到規(guī)范文檔更新自動(dòng)觸發(fā)編譯新契約10秒內(nèi)推送到所有Agent實(shí)例版本快照每個(gè)契約文件包含Git commit hash回滾時(shí)可精確匹配代碼分支的規(guī)范版本沙箱執(zhí)行契約校驗(yàn)器在獨(dú)立沙箱運(yùn)行即使規(guī)則存在無(wú)限循環(huán)也不會(huì)拖垮Agent主進(jìn)程。編譯過(guò)程其實(shí)是個(gè)小型編譯器前端將YAML規(guī)則轉(zhuǎn)為中間表示IR后端針對(duì)不同語(yǔ)言Java/Python/Go生成對(duì)應(yīng)AST解析器。我們?cè)鵀镚o語(yǔ)言單獨(dú)開(kāi)發(fā)了go/ast適配層因?yàn)槠銩ST結(jié)構(gòu)與Java差異極大——比如Go的if語(yǔ)句沒(méi)有顯式BlockStmt必須通過(guò)IfStmt.Body.List間接訪問(wèn)。提示別迷信“全自動(dòng)轉(zhuǎn)換”。我們投入最多人力的環(huán)節(jié)是人工校驗(yàn)——每條契約生成后必須用10個(gè)真實(shí)違規(guī)案例和10個(gè)邊界正常案例測(cè)試。曾有一條關(guān)于“枚舉類必須實(shí)現(xiàn)toString()”的契約在測(cè)試時(shí)發(fā)現(xiàn)它誤殺了Lombok的Value類最終通過(guò)添加hasAnnotation(lombok.Value)條件修復(fù)。4. 人機(jī)協(xié)同的代碼評(píng)審從對(duì)抗到共生的實(shí)踐閉環(huán)規(guī)范約束再嚴(yán)密也替代不了人類工程師的終極判斷。我們重構(gòu)了代碼評(píng)審流程讓Pi Agent從“被審查者”變成“協(xié)作者”核心是建立雙向反饋閉環(huán)人類評(píng)審意見(jiàn)實(shí)時(shí)反哺AgentAgent的規(guī)范解釋輔助人類決策。4.1 評(píng)審意見(jiàn)的結(jié)構(gòu)化歸因傳統(tǒng)Code Review評(píng)論如“這里命名不規(guī)范請(qǐng)改用駝峰”。Pi Agent收到后只會(huì)機(jī)械替換變量名下次又犯。我們的改進(jìn)是要求評(píng)審者使用結(jié)構(gòu)化歸因模板[CONTRACT_VIOLATION] LOG_FORMAT_V3 - 違規(guī)位置UserService.java:45 - 實(shí)際代碼log.warn(user not found, id userId) - 規(guī)范原文業(yè)務(wù)主流程缺失應(yīng)記錄ERRORWARN僅用于預(yù)期外的降級(jí)路徑 - 建議修正log.error(user not found, critical business impact, e) - 關(guān)聯(lián)案例見(jiàn)歷史PR#2287相同場(chǎng)景已修復(fù)Agent解析這種模板時(shí)會(huì)自動(dòng)提取CONTRACT_VIOLATION后的契約ID將其與本地契約庫(kù)比對(duì)。若發(fā)現(xiàn)本地?zé)o此ID說(shuō)明規(guī)范已更新Agent會(huì)主動(dòng)拉取最新契約若存在則將該案例加入“反例學(xué)習(xí)集”調(diào)整生成層的重加權(quán)策略。三個(gè)月下來(lái)同類日志違規(guī)下降94%。4.2 Agent驅(qū)動(dòng)的評(píng)審輔助更顛覆的是Agent開(kāi)始主動(dòng)參與評(píng)審。當(dāng)工程師提交PRAgent會(huì)自動(dòng)生成評(píng)審輔助報(bào)告不是羅列問(wèn)題而是提供決策支持評(píng)審點(diǎn)Agent分析工程師決策依據(jù)OrderService.process()中調(diào)用paymentClient.pay()此調(diào)用繞過(guò)DistributedTransaction代理層存在事務(wù)一致性風(fēng)險(xiǎn)查閱支付網(wǎng)關(guān)SLA確認(rèn)該接口是否支持事務(wù)回滾日志中userId未脫敏檢測(cè)到userId為L(zhǎng)ong類型按規(guī)范應(yīng)轉(zhuǎn)為字符串并脫敏確認(rèn)該日志是否在審計(jì)日志通道若是則需嚴(yán)格脫敏UserDTO類缺少Valid注解DTO接收外部請(qǐng)求缺失校驗(yàn)可能導(dǎo)致空指針檢查上游是否已做參數(shù)校驗(yàn)避免重復(fù)這份報(bào)告的價(jià)值在于它把規(guī)范條款還原到具體業(yè)務(wù)語(yǔ)境中。工程師不再糾結(jié)“該不該加Valid”而是思考“加了會(huì)不會(huì)影響上游重試邏輯”。我們統(tǒng)計(jì)過(guò)使用輔助報(bào)告后評(píng)審平均耗時(shí)從22分鐘降至8分鐘爭(zhēng)議點(diǎn)減少63%。4.3 動(dòng)態(tài)規(guī)范演進(jìn)從靜態(tài)文檔到活體知識(shí)庫(kù)最意外的收獲是Pi Agent成了規(guī)范本身的“壓力測(cè)試器”。當(dāng)某條規(guī)范在多個(gè)場(chǎng)景被反復(fù)挑戰(zhàn)如“所有RPC調(diào)用必須帶timeout”Agent會(huì)匯總所有繞過(guò)方式生成規(guī)范健壯性報(bào)告CONTRACT_RPC_TIMEOUT_V2 健壯性不足觸發(fā)頻次17次/周 - 繞過(guò)方式1使用Feign的fallbackFactorytimeout在fallback中失效 - 繞過(guò)方式2調(diào)用gRPC stub時(shí)未設(shè)置withDeadlineAfter() - 建議升級(jí)將約束擴(kuò)展至fallback方法體掃描并增加gRPC專用校驗(yàn)器這份報(bào)告直接推動(dòng)架構(gòu)組修訂規(guī)范并催生了新的契約類型CONTRACT_FALLBACK_TIMEOUT_V1。規(guī)范不再是領(lǐng)導(dǎo)簽字后就束之高閣的文件而是一個(gè)由AI和人類共同維護(hù)的、持續(xù)進(jìn)化的知識(shí)體。注意人機(jī)協(xié)同的關(guān)鍵是明確責(zé)任邊界。Agent永遠(yuǎn)不擁有最終決定權(quán)——它只能標(biāo)記風(fēng)險(xiǎn)、提供選項(xiàng)、解釋依據(jù)人類工程師必須點(diǎn)擊“批準(zhǔn)”或“拒絕”按鈕。我們甚至在審批界面上加了二次確認(rèn)“您確認(rèn)此修改符合《規(guī)范V3.1》第4.2條點(diǎn)擊展開(kāi)條款原文”把規(guī)范意識(shí)刻進(jìn)操作肌肉記憶。5. 那些沒(méi)寫(xiě)在文檔里的實(shí)戰(zhàn)血淚避坑指南與經(jīng)驗(yàn)清單跑了半年P(guān)i Agent規(guī)范系統(tǒng)踩過(guò)的坑比讀過(guò)的規(guī)范還多。這些細(xì)節(jié)不會(huì)出現(xiàn)在任何官方文檔里但直接決定項(xiàng)目成敗。5.1 AST校驗(yàn)器的性能陷阱別讓規(guī)范檢查拖垮開(kāi)發(fā)流最初我們把所有AST校驗(yàn)規(guī)則塞進(jìn)一個(gè)大函數(shù)結(jié)果在大型Service類上單次校驗(yàn)耗時(shí)2.3秒。工程師抱怨“寫(xiě)個(gè)getter都要等半天”。排查發(fā)現(xiàn)問(wèn)題出在遞歸遍歷深度優(yōu)先搜索DFS上——校驗(yàn)器為檢查“是否調(diào)用遠(yuǎn)程服務(wù)”會(huì)遍歷整個(gè)方法體AST包括所有嵌套的lambda表達(dá)式而某段代碼里有個(gè)12層嵌套的Stream鏈。解決方案是分層剪枝Layered Pruning第一層毫秒級(jí)快速掃描MethodDeclaration節(jié)點(diǎn)的直接子節(jié)點(diǎn)過(guò)濾掉明顯無(wú)關(guān)的ReturnStmt、ThrowStmt第二層百毫秒級(jí)對(duì)剩余節(jié)點(diǎn)做輕量AST匹配只檢查MethodInvocation和NewClass第三層秒級(jí)僅當(dāng)?shù)诙用懈呶ＤＪ饺鏷ttpClient才啟動(dòng)完整DFS遍歷。改造后平均校驗(yàn)時(shí)間從2300ms降至87ms。關(guān)鍵心得校驗(yàn)器不是越準(zhǔn)越好而是要在準(zhǔn)確率和響應(yīng)時(shí)間間找拐點(diǎn)。我們?cè)O(shè)定閾值——95%的常見(jiàn)違規(guī)必須在100ms內(nèi)捕獲剩下5%交給CI階段的深度掃描。5.2 規(guī)范沖突的熔斷機(jī)制當(dāng)兩條規(guī)則打架怎么辦某次上線前Agent陷入死循環(huán)規(guī)范A要求“所有數(shù)據(jù)庫(kù)操作必須加Transactional”規(guī)范B要求“查詢操作禁止加Transactional避免不必要的鎖”。Agent生成Transactional被B攔截去掉后又被A攔截來(lái)回17次。我們?cè)O(shè)計(jì)了沖突熔斷協(xié)議Conflict Fusing Protocol當(dāng)同一代碼塊在30秒內(nèi)被兩條及以上規(guī)則反復(fù)攔截Agent自動(dòng)暫停生成啟動(dòng)沖突分析器提取兩條規(guī)則的contract_id、violation_levelBLOCK/WARN、scopefile/method按優(yōu)先級(jí)排序scopemethodscopefileviolation_levelBLOCKviolation_levelWARN輸出沖突報(bào)告“檢測(cè)到LOG_FORMAT_V3與DB_TXN_V2沖突建議在查詢方法上添加ReadOnlyTransaction注解見(jiàn)規(guī)范V3.1附錄C”。這個(gè)機(jī)制上線后沖突導(dǎo)致的生成失敗歸零。更重要的是它倒逼我們清理了規(guī)范庫(kù)里的冗余條款——原來(lái)有4條規(guī)則在不同章節(jié)重復(fù)定義了“事務(wù)傳播行為”。5.3 新人培訓(xùn)的范式轉(zhuǎn)移從背規(guī)范到調(diào)Agent最顛覆的是培訓(xùn)方式。以前新人要花兩天背《編碼規(guī)范V3.0》現(xiàn)在第一天就讓他們用Pi Agent寫(xiě)個(gè)Hello World然后故意制造違規(guī)讓Agent生成一個(gè)沒(méi)加Override的重寫(xiě)方法觀察它如何在評(píng)審報(bào)告中指出“缺少注解影響IDE重構(gòu)”故意在Controller里調(diào)用Service看Agent如何解釋“違反分層架構(gòu)導(dǎo)致測(cè)試?yán)щy”把日志級(jí)別設(shè)為DEBUG讓它展示“此日志在生產(chǎn)環(huán)境會(huì)被過(guò)濾失去監(jiān)控價(jià)值”。新人不再記條款而是理解每條規(guī)范背后的技術(shù)債務(wù)成本。某次培訓(xùn)中一個(gè)新人指著評(píng)審報(bào)告問(wèn)“為什么Valid必須加在DTO上而不是Controller參數(shù)里”——這正是我們想要的效果規(guī)范從教條變成了可討論、可質(zhì)疑、可優(yōu)化的技術(shù)對(duì)話起點(diǎn)。最后分享一個(gè)小技巧在Agent的system prompt里永遠(yuǎn)加上這句話“你不是在執(zhí)行命令而是在與人類工程師共建高質(zhì)量軟件。當(dāng)規(guī)范與業(yè)務(wù)目標(biāo)沖突時(shí)請(qǐng)優(yōu)先保障業(yè)務(wù)可演進(jìn)性并清晰說(shuō)明權(quán)衡依據(jù)?！?這句話讓Agent從“規(guī)則機(jī)器人”蛻變?yōu)椤凹夹g(shù)合伙人”。