第24期 | AI辅助调试与代码审查 今天你将学会用 AI 定位 Bug 的系统性方法不只是「帮我看看哪里错了」用 AI 做 Code Review 的完整流程用 AI 分析性能瓶颈和潜在隐患建立一个「AI 调试 Prompt 工具箱」 核心知识调试的三个层次你在哪一层很多前端开发者遇到 Bug 的第一反应是打开 DevTools看 Console然后盯着报错信息发呆。这是Level 1——看表象。层次行为效率AI 能帮什么L1 看表象读报错信息、猜测原因低靠经验直觉AI 解读报错、给出可能原因L2 追链路从报错位置追踪到根因中需要理解代码流程AI 分析调用链、追踪状态变化L3 防隐患还没报错就发现潜在问题高预防性AI 审查代码、发现边界情况AI 在每个层次都能帮你——但用法不同。L1 给报错信息L2 给相关代码上下文L3 给整段逻辑让 AI 审查。用 AI 定位 Bug系统方法STEP 1收集信息在给 AI 之前你先收集完整的报错信息不是截取一部分出错时的输入数据预期行为 vs 实际行为STEP 2构建 CRISP 调试 Prompt[Context] {出错的文件} {相关文件} [Role] 前端调试专家 [Instruction] 定位并修复以下 Bug [Specification] - 错误现象{实际行为} - 预期行为{应该怎样} - 错误信息{完整报错} - 触发条件{在什么操作下出错} - 已排除{你已经确认不是问题的方向} [Proof] 修复后正常工作写出验证步骤STEP 3让 AI 先分析根因再给修复方案关键不要让 AI 直接改代码。让它先分析你确认分析对了再让它修。第一步分析这个 Bug 的根因列出所有可能的原因按可能性排序 第二步等我确认后再给出修复方案为什么要先分析再修复因为 AI 有时会「修 A 却说修了 B」——它改了代码但分析原因说错了。你先确认分析就能确保修复方向是对的。常见 Bug 类型及 AI 定位策略Bug 类型特征AI 定位策略类型错误TypeError: Cannot read property x of undefined引用相关文件 类型定义让 AI 找到数据流断点异步时序数据还没返回就渲染引用 fetch/async 代码 组件渲染逻辑让 AI 分析 Promise 链状态不更新点击/输入后 UI 没变化引用 store/setState 事件处理器让 AI 检查 state 是否正确触发样式冲突CSS 不生效/覆盖引用组件 CSS 全局样式让 AI 分析 specificity 和层叠顺序渲染循环页面卡死/无限更新引用 useEffect state 依赖让 AI 检查依赖数组是否完整实战示例定位一个「列表不刷新」Bug报错信息没有报错但现象是「上传新文件后列表没更新」[Context] src/features/ipa/store.ts src/features/ipa/components/IPAList.tsx src/features/ipa/services/upload.ts [Role] 前端调试专家 [Instruction] 定位以下 Bug上传 IPA 文件后列表没有自动刷新 [Specification] - 错误现象上传成功后列表仍然是旧数据手动刷新页面后才更新 - 预期行为上传成功后列表自动更新显示新上传的文件 - 已排除上传接口本身是正常的后端返回了新数据 [Proof] 修复后上传成功列表自动更新AI 分析可能原因按可能性排序 1. 【高概率】上传成功后没有重新调用 fetchIPAList - 分析upload.ts 的 onSuccess 回调没有触发 store 的刷新 action 2. 【中概率】fetchIPAList 返回了新数据但组件没有重新渲染 - 分析组件可能用了 stale 数据或者 selector 没正确订阅 3. 【低概率】缓存问题 - 分析如果用了 React Query 或 SWR可能是缓存策略导致 建议先检查第1个原因在 upload service 的 onSuccess 中是否调用了 store.fetchIPAList()根因确认第1个原因是对的——upload.ts 的onSuccess只显示了一个 toast 提示没有调用store.fetchIPAList()。修复方案在 upload service 的 onSuccess 回调中加上ipaStore.fetchIPAList()。用 AI 做 Code ReviewAI Code Review 不是让 AI 替你审查整段代码——那样太泛了。好的 AI Review 是按维度审查每个维度单独输出。多维度审查 Prompt{要审查的文件} 请从以下6个维度逐一审查这段代码每个维度给出 - 问题列表无问题则写✅ 无问题 - 严重程度 高 / 中 / 低 - 建议修复方案 维度1类型安全TypeScript 类型是否完整、any 是否滥用 维度2性能是否有不必要的重渲染、内存泄漏风险 维度3可维护性代码是否清晰、命名是否规范、耦合度 维度4边界情况空值、undefined、异常输入的处理 维度5可访问性ARIA 属性、键盘操作、语义化标签 维度6安全XSS 风险、数据验证、敏感信息暴露审查输出示例维度1类型安全 - [高] API 响应类型用了 any应定义 ResponseT 类型 → 建议从 Swagger/API 文档生成类型定义 - [中] Props 类型缺少可选标记有些 prop 不必必传 → 建议review Props 定义合理标记 optional 维度2性能 - [中] useMemo 缺少依赖项可能导致 stale 计算 → 建议补齐依赖数组或使用 useCallback 包裹引用 - [低] 列表渲染缺少 key 优化大数据量时可能慢 → 建议确保 key 用唯一 id 而不是 index 维度3可维护性 - ✅ 无问题 维度4边界情况 - [高] 搜索输入没有处理空字符串可能导致 API 报错 → 建议搜索为空时跳过 API 调用直接显示全部数据 维度5可访问性 - [中] 按钮缺少 aria-label屏幕阅读器无法理解 → 建议给图标按钮添加 aria-label 描述 维度6安全 - [低] 使用了 dangerouslySetInnerHTML但内容来自可信来源 → 建议即便内容可信也建议用 DOMPurify 做 sanitize用 AI 分析性能瓶颈性能分析 Prompt{要分析的组件/页面} 分析以下性能问题 1. 列出所有可能导致性能问题的代码重渲染、大计算、DOM 操作过多 2. 对每个问题给出 - 影响程度在什么数据量下会变慢 - 修复方案优先级排序 3. 给出整体优化策略哪些值得现在做哪些可以等数据量大了再做 参考数据当前数据量约 {N} 条预计未来可能增长到 {M} 条常见误区误区1把报错截图直接丢给 AI截图里的报错信息 AI 可能读不全或读错。复制文本不要截图。误区2只给 AI 报错的那一个文件Bug 的根因往往不在报错文件——可能在数据来源、状态管理、异步处理。给 AI 相关文件的上下文。误区3AI 说改什么就改什么先确认 AI 的分析是对的再改代码。有时候 AI 的「修复」只是掩盖了症状根因还在。 AI协作实战实战找出 3 个隐藏 Bug下面这段代码里我故意埋了 3 个 Bug用 AI 找出来// UserList.tsximport{useEffect,useState}fromreact;import{fetchUsers}from../services/user;interfaceUser{id:number;name:string;email:string;role:string;}exportfunctionUserList(){const[users,setUsers]useStateUser[]([]);const[search,setSearch]useState();const[loading,setLoading]useState(false);useEffect((){setLoading(true);fetchUsers().then(data{setUsers(data);setLoading(false);});},[search]);// Bug 1: search 变化触发 fetch但 search 应该是本地过滤而非重新请求constfilteredUsersusers.filter(uu.name.includes(search)// Bug 2: 没有 toLowerCase大小写敏感匹配);return(divinput value{search}onChange{esetSearch(e.target.value)}/{loadingp加载中.../p}ul{filteredUsers.map((u,i)(li key{i}{/* Bug 3: 用 index 作为 key用户排序会出问题 */}{u.name}-{u.email}/li))}/ul/div);}我给 AI 的 PromptUserList.tsx 请从类型安全、性能、边界情况、可维护性四个维度审查这段代码。 对每个发现的问题标注严重程度(高/中/低)并给出修复方案。AI 审查结果 [高] useEffect 依赖数组包含 search但 search 应该只做本地过滤 → 修复移除 search 依赖只在初始化时 fetchUsers() → 如果需要搜索触发 API应单独处理搜索请求 [中] filter 用 includes 没有大小写不敏感匹配 → 修复改为 u.name.toLowerCase().includes(search.toLowerCase()) [中] 用 index 作为 key → 修复改为 key{u.id}因为 User 有 id 字段 [中] fetchUsers 没有 error 处理 → 修复加 .catch() 和 error state [低] setLoading(false) 在 .then 中如果请求失败 loading 状态不会重置 → 修复在 .catch 中也 setLoading(false)AI 找到了我埋的 3 个 Bug还额外发现了 2 个我没刻意埋但确实存在的问题错误处理缺失。这就是 AI Review 的价值——不只找你已知的问题还能发现你没注意到的隐患。学到了什么让 AI 按维度审查比让它「随便看看」更有效。维度审查强制 AI 系统性思考而不是凭直觉挑几个明显问题。 动手练习练习1简单用 CRISP 调试模板定位一个你项目中的真实 Bug找一个你项目中存在的小 Bug或者刚修过的一个 Bug用 CRISP 调试模板写 Prompt对比 AI 分析和你的原始定位过程看哪个更快。练习2中等对你的一个组件做 AI Code Review选你项目中最复杂的一个组件用本期提供的多维度审查 Prompt 做 Review。记录 AI 发现的问题中有多少是你之前没注意到的。练习3挑战故意埋 Bug 再找 Bug写一个 50-100 行的 React 组件故意埋 5 个 Bug至少 1 个性能问题、1 个类型问题、1 个边界情况。让 AI 审查看它能找到几个。评估 AI 没找到的 Bug 的特征——是太隐蔽还是 AI 的审查维度不够 本期要点调试三层L1看表象→ L2追链路→ L3防隐患AI 在每层都能帮你但用法不同先分析再修复让 AI 先给根因分析你确认后再修复——避免「修了症状没修根因」多维度审查按类型安全/性能/可维护性/边界情况/可访问性/安全六个维度比「随便看看」系统得多给够上下文Bug 的根因往往不在报错文件引用相关的数据流文件才能让 AI 精准定位复制文本不要截图报错信息用文本形式给 AI不要截图——AI 读文本更准确 下期预告下一期我们看设计稿→代码的快速通道——v0、Figma AI、截图转代码。你将学会用 AI 从设计稿生成可用的 React 组件以及如何审查和修改 AI 生成的 UI 代码。如果你没有苹果电脑需要上传ios到APPStore可以访问以下网站iPA上传工具 - IPA解析与AppStore提交