AI Code Review 与 AI 重构
AICR 和 AI 重构在前端研发中的适用场景、局限，以及质量验证方法。
#tech / dev / frontend
#type / synthesis
#status / growing
[!info] related notes
AI Code Review 与 AI 重构
相比从零写复杂业务，AI 往往更擅长做第一轮质量扫描和受约束的代码整理。
一句话定义
AICR 更适合承担第一层自动化审查，AI 重构更适合在已有代码基础上做拆分、抽象和风格统一，但最终质量仍然要靠验证闭环保证。
AICR 常适合检查什么
- 命名是否混乱
- 重复逻辑是否明显
- 类型约束是否松散
- 空值和异常处理是否缺失
- 可读性和复杂度是否过高
AI 重构常适合做什么
- 拆大组件
- 抽公共 hooks
- JS 迁移到 TS
- 统一样式或目录结构
- 去重和抽象公共逻辑
为什么它们有价值
- 减少人工 review 的低层重复劳动
- 提前暴露一批明显问题
- 对历史代码整理特别友好
局限在哪里
- 容易误判业务正确性
- 上下文理解常不完整
- 可能做出看起来干净但不稳的抽象
- 难以独立承担架构级判断
怎么验证结果
- lint 和 test
- 对比重构前后行为
- 检查类型约束
- 人工 review 关键逻辑和边界条件
最短记忆方式
AICR 先筛一遍，AI 重构先整理一遍，最终都要靠验证和人工判断兜底。
面试要点
来自 ai-generated-code-risks-interview-question 的面试视角整理。
补充来自 aicr-interview-question：
一句话回答
AICR 就是 AI Code Review，适合承担命名规范、重复逻辑、简单复杂度、类型问题和部分性能风险的第一层自动化检查，但不能替代人工对业务正确性和架构合理性的判断。
最稳的回答主线
- 先定义它是什么
- 再说明它最适合检查什么
- 最后强调它为什么不能替代人工 review
AICR 最适合做什么
- 扫重复逻辑和命名问题
- 扫类型约束和空值风险
- 提示过大的组件和过长函数
- 提醒潜在性能问题或明显坏味道
面试里最好补的一句
我会把 AICR 放在人工 review 之前，先做第一层低成本质量筛查，帮团队把注意力留给真正需要判断的部分。
常见误区
- 把 AICR 当成自动批准器
- 只谈效率，不谈误报和漏报
- 忽略项目规范、业务约束和上下文缺失
可能追问
- AICR 和 lint、静态分析有什么区别
- 哪类 review 问题最适合交给 AI
- 你会怎么把 AICR 接进团队流程
最短记忆方式
AICR 先筛一遍，人工再做关键判断。
一句话回答
AI 生成代码的主要风险包括上下文理解不完整、边界条件遗漏、类型不严谨、风格不统一和潜在性能或安全问题；因此必须通过 lint、测试、本地运行和人工 review 建立验证闭环。
最稳的回答主线
- 先说风险来源：上下文、边界、规范、质量
- 再说兜底方式：lint、test、人工 review
- 最后补一句：AI 负责提效，开发者负责最终结果
常见风险可以怎么分
- 业务风险：误解需求、遗漏边界条件
- 工程风险：风格不统一、结构不合理、可维护性差
- 质量风险：类型不严、异常处理缺失、测试覆盖不足
- 非功能风险：性能问题、安全问题、依赖使用不当
面试里最好补的一句
如果任务越接近核心业务，我越会把 AI 当成初稿生成器和检查器，而不是最终交付者。
一个实用兜底闭环
- 先给清楚上下文和约束
- 生成后跑 lint、类型检查和测试
- 本地验证关键流程
- 人工 review 业务边界和关键逻辑
常见误区
- 只谈 hallucination，不谈工程质量和维护成本
- 只说人工 review，不说自动化验证
- 把 AI 代码问题归因成模型不行，而不是流程没有约束好
可能追问
- 你实际遇到过哪些 AI 生成代码的问题
- 哪类代码你最不放心直接接受
- 你会怎么给 AI 提上下文来减少风险
最短记忆方式
AI 可以先写，不能直接信，必须进验证闭环。