前端工程經(jīng)驗如何沉淀為可執(zhí)行規(guī)則線上事故復(fù)盤里常見問題包括組件卸載后沒有清理微前端的全局事件監(jiān)聽、在 Vue3 計算屬性中執(zhí)行異步請求以及 React Hooks 漏寫依賴項造成閉包問題。每次出問題都只要求“下次注意”很難形成可執(zhí)行、可復(fù)查的約束。AI 代碼審查也不能只把源碼交給模型缺少項目上下文時它可能盯著命名和格式卻漏掉閉包、資源清理等真正的風(fēng)險。大模型沒有項目特有的上下文。要讓 AI 審查發(fā)揮作用需要把線上故障和 Code Review 的教訓(xùn)轉(zhuǎn)成計算機能執(zhí)行的決策規(guī)則。1. 為什么傳統(tǒng)的 Code Review 總是變成無休止的扯皮如果評審留言大多落在縮進、命名和引號偏好上內(nèi)存泄漏、競態(tài)條件、無效重渲染等風(fēng)險就容易被淹沒。可以先統(tǒng)計一段時間內(nèi)的 PR 留言分類確認(rèn)團隊的注意力實際花在了哪里。很多人以為買個 AI Code Review 工具就能解決問題。實際上沒有上下文約束的模型不知道微前端基座如何路由也不知道封裝的useRequest已自帶防抖。直接問它“這段代碼有沒有 Bug”它只能按通用經(jīng)驗回答甚至可能編造不存在的語法錯誤。代碼審查的核心不是評判“代碼寫得漂不漂亮”而是攔截“與當(dāng)前架構(gòu)不符的危險動作”。只有把團隊在特定業(yè)務(wù)場景下的失敗經(jīng)驗沉淀為結(jié)構(gòu)化的決策記錄Architecture Decision Record, ADRAI 才能擁有精準(zhǔn)的判斷依據(jù)。2. 故障轉(zhuǎn)化的兩層防線AST 確定性規(guī)則與 Agent 語義規(guī)則不是所有的經(jīng)驗都適合讓 LLM 去判斷。如果一個規(guī)則能用確定性的語法樹AST檢測出來就絕對不要交給消耗 Token 且存在隨機性的 AI。我們在工程上把從故障中提取的規(guī)則分為兩層確定性防線AST 層針對 API 誤用、特定語法禁用、強制屬性檢查。例如“在components/business目錄下避免直接 import 底層axios實例”。這種規(guī)則直接編譯為自定義 ESLint 插件在本地 Git Hook 階段就應(yīng)抹殺。語義化防線Agent 語義層針對業(yè)務(wù)邏輯完備性、競態(tài)控制、狀態(tài)同步風(fēng)險。例如“在涉及到支付狀態(tài)變更的自定義 Hook 中應(yīng)處理網(wǎng)絡(luò)中斷時的兜底狀態(tài)”。這種規(guī)則需要依靠大模型理解上下文意圖由 Agent 在 PR 階段掃描。下面這套 TypeScript 實現(xiàn)的復(fù)盤規(guī)則提取與分發(fā)引擎展現(xiàn)了我們?nèi)绾螌⒔Y(jié)構(gòu)化的故障復(fù)盤記錄轉(zhuǎn)化為可執(zhí)行的審查邏輯。import * as parser from babel/parser; import traverse from babel/traverse; import { GoogleGenerativeAI } from google/generative-ai; // 1. 結(jié)構(gòu)化決策記錄定義 (ADR) export interface IncidentRule { id: string; title: string; category: MEM_LEAK | RACE_CONDITION | SECURITY | PERFORMANCE; astPattern?: string; // 靜態(tài)檢測特征描述 semanticPrompt: string; // 提供給 LLM 的語義檢查指令 severity: CRITICAL | WARN; } // 2. 復(fù)盤引擎實現(xiàn) export class ReviewRuleEngine { private rules: IncidentRule[] []; private ai: GoogleGenerativeAI; constructor(apiKey: string) { this.ai new GoogleGenerativeAI(apiKey); } // 注冊從故障中提煉的規(guī)則 public registerRule(rule: IncidentRule) { this.rules.push(rule); } // 第一層防線確定性 AST 節(jié)點靜態(tài)分析以檢測未清理的 EventListener 為例 public checkAST(code: string): { ruleId: string; line: number; message: string }[] { const violations: { ruleId: string; line: number; message: string }[] []; try { const ast parser.parse(code, { sourceType: module, plugins: [typescript, jsx], }); let hasAddEventListener false; let hasRemoveEventListener false; let addLine 0; traverse(ast, { CallExpression(path) { const callee path.node.callee; if ( callee.type MemberExpression callee.property.type Identifier ) { if (callee.property.name addEventListener) { hasAddEventListener true; addLine callee.property.loc?.start.line || 0; } if (callee.property.name removeEventListener) { hasRemoveEventListener true; } } }, }); if (hasAddEventListener !hasRemoveEventListener) { violations.push({ ruleId: RULE-MEM-01, line: addLine, message: 檢測到 addEventListener 但缺乏對應(yīng)的 removeEventListener 清理邏輯存在內(nèi)存泄漏隱患。, }); } } catch (err) { console.error(AST 解析失敗:, err); } return violations; } // 第二層防線基于 LLM 的非確定性語義審查 public async checkSemantics(code: string): Promisestring[] { const model this.ai.getGenerativeModel({ model: gemini-1.5-pro }); const semanticRules this.rules.map(r - [${r.id}] ${r.title}: ${r.semanticPrompt}).join(\n); const prompt 你是一名嚴(yán)格的前端代碼審查專家。請根據(jù)以下團隊歷史故障提煉的審查規(guī)則分析給出的代碼是否存在隱患。 團隊歷史故障規(guī)則庫 ${semanticRules} 被審查代碼 \\\typescript ${code} \\\ 輸出要求 1. 只輸出命中的違規(guī)規(guī)則格式為[規(guī)則ID] 行號: 具體風(fēng)險說明與修改建議。 2. 若無違規(guī)僅輸出 PASSED。 3. 嚴(yán)禁評價命名風(fēng)格或格式等無關(guān)問題。 ; const response await model.generateContent(prompt); const text response.response.text(); return text.split(\n).filter(line line.trim().length 0); } }3. 把決策過程寫入 Git 提交鏈路規(guī)則引擎應(yīng)嵌入開發(fā)者的日常流程避免額外維護一個需要反復(fù)登錄的后臺。我們的做法是直接把規(guī)則庫放到項目根目錄的.github/review-rules.json中。每次出現(xiàn)生產(chǎn)環(huán)境 P2 級以上的事故責(zé)任人在完成 Bug 修復(fù)后應(yīng)提交一份包含規(guī)則更新的 PR。在 CI 流水線中通過 GitHub Actions 或 Git Hooks 觸發(fā)審查腳本。如果靜態(tài) AST 階段發(fā)現(xiàn)CRITICAL級錯誤構(gòu)建直接中斷并在 PR 評論區(qū)附上違規(guī)行號和對應(yīng)的線上故障單鏈接。開發(fā)者看到的不再是“格式不符合規(guī)范”而是帶有歷史背景的提示“上個月 15 號這里沒處理競態(tài)導(dǎo)致用戶重復(fù)扣款 5 萬元請參考 ADR-0815 加防抖處理”。4. 效果評估與防線上移效果應(yīng)通過上線前后的 PR 平均通過時間、規(guī)則命中率和線上同類問題數(shù)來評估并記錄統(tǒng)計口徑。復(fù)盤中反復(fù)出現(xiàn)的風(fēng)險可以被寫成規(guī)則新成員也能在提交階段看到對應(yīng)的背景和處理方式。此時 AI 只是審查鏈路的一環(huán)規(guī)則本身仍應(yīng)由團隊持續(xù)維護。能由編譯期或 AST 檢查確定的問題應(yīng)優(yōu)先交給確定性規(guī)則需要業(yè)務(wù)上下文的部分再交給 AI 輔助判斷。規(guī)則要能在日常提交流程中執(zhí)行也要隨事故復(fù)盤持續(xù)更新。