前端工程经验如何沉淀为可执行规则线上事故复盘里常见问题包括组件卸载后没有清理微前端的全局事件监听、在 Vue3 计算属性中执行异步请求以及 React Hooks 漏写依赖项造成闭包问题。每次出问题都只要求“下次注意”很难形成可执行、可复查的约束。AI 代码审查也不能只把源码交给模型缺少项目上下文时它可能盯着命名和格式却漏掉闭包、资源清理等真正的风险。大模型没有项目特有的上下文。要让 AI 审查发挥作用需要把线上故障和 Code Review 的教训转成计算机能执行的决策规则。1. 为什么传统的 Code Review 总是变成无休止的扯皮如果评审留言大多落在缩进、命名和引号偏好上内存泄漏、竞态条件、无效重渲染等风险就容易被淹没。可以先统计一段时间内的 PR 留言分类确认团队的注意力实际花在了哪里。很多人以为买个 AI Code Review 工具就能解决问题。实际上没有上下文约束的模型不知道微前端基座如何路由也不知道封装的useRequest已自带防抖。直接问它“这段代码有没有 Bug”它只能按通用经验回答甚至可能编造不存在的语法错误。代码审查的核心不是评判“代码写得漂不漂亮”而是拦截“与当前架构不符的危险动作”。只有把团队在特定业务场景下的失败经验沉淀为结构化的决策记录Architecture Decision Record, ADRAI 才能拥有精准的判断依据。2. 故障转化的两层防线AST 确定性规则与 Agent 语义规则不是所有的经验都适合让 LLM 去判断。如果一个规则能用确定性的语法树AST检测出来就绝对不要交给消耗 Token 且存在随机性的 AI。我们在工程上把从故障中提取的规则分为两层确定性防线AST 层针对 API 误用、特定语法禁用、强制属性检查。例如“在components/business目录下避免直接 import 底层axios实例”。这种规则直接编译为自定义 ESLint 插件在本地 Git Hook 阶段就应抹杀。语义化防线Agent 语义层针对业务逻辑完备性、竞态控制、状态同步风险。例如“在涉及到支付状态变更的自定义 Hook 中应处理网络中断时的兜底状态”。这种规则需要依靠大模型理解上下文意图由 Agent 在 PR 阶段扫描。下面这套 TypeScript 实现的复盘规则提取与分发引擎展现了我们如何将结构化的故障复盘记录转化为可执行的审查逻辑。import * as parser from babel/parser; import traverse from babel/traverse; import { GoogleGenerativeAI } from google/generative-ai; // 1. 结构化决策记录定义 (ADR) export interface IncidentRule { id: string; title: string; category: MEM_LEAK | RACE_CONDITION | SECURITY | PERFORMANCE; astPattern?: string; // 静态检测特征描述 semanticPrompt: string; // 提供给 LLM 的语义检查指令 severity: CRITICAL | WARN; } // 2. 复盘引擎实现 export class ReviewRuleEngine { private rules: IncidentRule[] []; private ai: GoogleGenerativeAI; constructor(apiKey: string) { this.ai new GoogleGenerativeAI(apiKey); } // 注册从故障中提炼的规则 public registerRule(rule: IncidentRule) { this.rules.push(rule); } // 第一层防线确定性 AST 节点静态分析以检测未清理的 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 但缺乏对应的 removeEventListener 清理逻辑存在内存泄漏隐患。, }); } } 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 你是一名严格的前端代码审查专家。请根据以下团队历史故障提炼的审查规则分析给出的代码是否存在隐患。 团队历史故障规则库 ${semanticRules} 被审查代码 \\\typescript ${code} \\\ 输出要求 1. 只输出命中的违规规则格式为[规则ID] 行号: 具体风险说明与修改建议。 2. 若无违规仅输出 PASSED。 3. 严禁评价命名风格或格式等无关问题。 ; const response await model.generateContent(prompt); const text response.response.text(); return text.split(\n).filter(line line.trim().length 0); } }3. 把决策过程写入 Git 提交链路规则引擎应嵌入开发者的日常流程避免额外维护一个需要反复登录的后台。我们的做法是直接把规则库放到项目根目录的.github/review-rules.json中。每次出现生产环境 P2 级以上的事故责任人在完成 Bug 修复后应提交一份包含规则更新的 PR。在 CI 流水线中通过 GitHub Actions 或 Git Hooks 触发审查脚本。如果静态 AST 阶段发现CRITICAL级错误构建直接中断并在 PR 评论区附上违规行号和对应的线上故障单链接。开发者看到的不再是“格式不符合规范”而是带有历史背景的提示“上个月 15 号这里没处理竞态导致用户重复扣款 5 万元请参考 ADR-0815 加防抖处理”。4. 效果评估与防线上移效果应通过上线前后的 PR 平均通过时间、规则命中率和线上同类问题数来评估并记录统计口径。复盘中反复出现的风险可以被写成规则新成员也能在提交阶段看到对应的背景和处理方式。此时 AI 只是审查链路的一环规则本身仍应由团队持续维护。能由编译期或 AST 检查确定的问题应优先交给确定性规则需要业务上下文的部分再交给 AI 辅助判断。规则要能在日常提交流程中执行也要随事故复盘持续更新。 前端工程经验如何沉淀为可执行规则
前端工程经验如何沉淀为可执行规则线上事故复盘里常见问题包括组件卸载后没有清理微前端的全局事件监听、在 Vue3 计算属性中执行异步请求以及 React Hooks 漏写依赖项造成闭包问题。每次出问题都只要求“下次注意”很难形成可执行、可复查的约束。AI 代码审查也不能只把源码交给模型缺少项目上下文时它可能盯着命名和格式却漏掉闭包、资源清理等真正的风险。大模型没有项目特有的上下文。要让 AI 审查发挥作用需要把线上故障和 Code Review 的教训转成计算机能执行的决策规则。1. 为什么传统的 Code Review 总是变成无休止的扯皮如果评审留言大多落在缩进、命名和引号偏好上内存泄漏、竞态条件、无效重渲染等风险就容易被淹没。可以先统计一段时间内的 PR 留言分类确认团队的注意力实际花在了哪里。很多人以为买个 AI Code Review 工具就能解决问题。实际上没有上下文约束的模型不知道微前端基座如何路由也不知道封装的useRequest已自带防抖。直接问它“这段代码有没有 Bug”它只能按通用经验回答甚至可能编造不存在的语法错误。代码审查的核心不是评判“代码写得漂不漂亮”而是拦截“与当前架构不符的危险动作”。只有把团队在特定业务场景下的失败经验沉淀为结构化的决策记录Architecture Decision Record, ADRAI 才能拥有精准的判断依据。2. 故障转化的两层防线AST 确定性规则与 Agent 语义规则不是所有的经验都适合让 LLM 去判断。如果一个规则能用确定性的语法树AST检测出来就绝对不要交给消耗 Token 且存在随机性的 AI。我们在工程上把从故障中提取的规则分为两层确定性防线AST 层针对 API 误用、特定语法禁用、强制属性检查。例如“在components/business目录下避免直接 import 底层axios实例”。这种规则直接编译为自定义 ESLint 插件在本地 Git Hook 阶段就应抹杀。语义化防线Agent 语义层针对业务逻辑完备性、竞态控制、状态同步风险。例如“在涉及到支付状态变更的自定义 Hook 中应处理网络中断时的兜底状态”。这种规则需要依靠大模型理解上下文意图由 Agent 在 PR 阶段扫描。下面这套 TypeScript 实现的复盘规则提取与分发引擎展现了我们如何将结构化的故障复盘记录转化为可执行的审查逻辑。import * as parser from babel/parser; import traverse from babel/traverse; import { GoogleGenerativeAI } from google/generative-ai; // 1. 结构化决策记录定义 (ADR) export interface IncidentRule { id: string; title: string; category: MEM_LEAK | RACE_CONDITION | SECURITY | PERFORMANCE; astPattern?: string; // 静态检测特征描述 semanticPrompt: string; // 提供给 LLM 的语义检查指令 severity: CRITICAL | WARN; } // 2. 复盘引擎实现 export class ReviewRuleEngine { private rules: IncidentRule[] []; private ai: GoogleGenerativeAI; constructor(apiKey: string) { this.ai new GoogleGenerativeAI(apiKey); } // 注册从故障中提炼的规则 public registerRule(rule: IncidentRule) { this.rules.push(rule); } // 第一层防线确定性 AST 节点静态分析以检测未清理的 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 但缺乏对应的 removeEventListener 清理逻辑存在内存泄漏隐患。, }); } } 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 你是一名严格的前端代码审查专家。请根据以下团队历史故障提炼的审查规则分析给出的代码是否存在隐患。 团队历史故障规则库 ${semanticRules} 被审查代码 \\\typescript ${code} \\\ 输出要求 1. 只输出命中的违规规则格式为[规则ID] 行号: 具体风险说明与修改建议。 2. 若无违规仅输出 PASSED。 3. 严禁评价命名风格或格式等无关问题。 ; const response await model.generateContent(prompt); const text response.response.text(); return text.split(\n).filter(line line.trim().length 0); } }3. 把决策过程写入 Git 提交链路规则引擎应嵌入开发者的日常流程避免额外维护一个需要反复登录的后台。我们的做法是直接把规则库放到项目根目录的.github/review-rules.json中。每次出现生产环境 P2 级以上的事故责任人在完成 Bug 修复后应提交一份包含规则更新的 PR。在 CI 流水线中通过 GitHub Actions 或 Git Hooks 触发审查脚本。如果静态 AST 阶段发现CRITICAL级错误构建直接中断并在 PR 评论区附上违规行号和对应的线上故障单链接。开发者看到的不再是“格式不符合规范”而是带有历史背景的提示“上个月 15 号这里没处理竞态导致用户重复扣款 5 万元请参考 ADR-0815 加防抖处理”。4. 效果评估与防线上移效果应通过上线前后的 PR 平均通过时间、规则命中率和线上同类问题数来评估并记录统计口径。复盘中反复出现的风险可以被写成规则新成员也能在提交阶段看到对应的背景和处理方式。此时 AI 只是审查链路的一环规则本身仍应由团队持续维护。能由编译期或 AST 检查确定的问题应优先交给确定性规则需要业务上下文的部分再交给 AI 辅助判断。规则要能在日常提交流程中执行也要随事故复盘持续更新。