AI Coding Agent 做代码审查，不能停留在“看 diff、挑语法问题”的层面。它更适合做一种带验证能力的审查：先理解需求和代码上下文，再检查变更是否符合既有架构，最后通过测试、类型检查、运行结果去验证判断。

比较合理的流程是先读变更背景，包括需求描述、关联接口、路由、组件层级、状态来源和已有约定。前端项目里很多问题不是单行代码错误，而是数据流、生命周期、权限边界、交互状态没有对齐。例如一个表单提交逻辑，看起来只是改了几个字段，但实际要确认默认值、校验规则、接口入参、错误提示、重复提交、权限控制和列表刷新是否都闭环。

审查时可以分几层看。第一层是正确性，比如条件分支是否完整、异步请求是否有竞态、React Hook 依赖是否遗漏、状态是否可能 stale、接口返回为空时是否会崩。第二层是工程质量，比如类型是否收窄准确、组件边界是否清晰、是否引入了不必要的全局状态、是否破坏了已有抽象。第三层是用户体验和前端特有问题，比如 loading、empty、error 状态，移动端适配，键盘可访问性，表格分页筛选是否保留，弹窗关闭后状态是否清理。第四层是安全和性能，比如 XSS 风险、敏感信息泄露、大列表渲染、重复请求、bundle 体积和缓存策略。

AI Coding Agent 的优势在于可以把“怀疑”变成“验证”。发现风险后，不应该只说“这里可能有问题”，而是尽量运行 lint、typecheck、单元测试，必要时启动页面做交互验证。对于 UI 改动，还可以用截图或浏览器自动化确认布局没有溢出、遮挡和回归。这样输出的结论会更接近工程审查，而不是静态文本分析。

审查结果也要有优先级。高质量的 review 不应该把风格建议和线上 bug 混在一起，而是先指出会导致功能错误、数据错误、安全问题、性能退化的点，并且给出文件位置、触发条件、影响范围和建议改法。能直接修复的小问题，可以由 Agent 提交补丁；涉及产品语义或架构取舍的问题，则应该明确列为需要确认的开放问题。

同时要控制 AI 的边界。Agent 不能凭空假设业务规则，也不能为了“看起来更好”做大范围重构。代码审查最重要的是基于证据：仓库里的现有模式、测试结果、接口契约、运行行为。AI 适合提高审查覆盖率和发现常见缺陷，但最终仍需要人对业务语义和风险取舍负责。