AI 生成的前端组件，凭什么敢合并上线？
前阵子面试，面试官抛给我一个很现实的问题：
团队现在全面用 AI 辅助开发，它能一次性生成完整的前端组件，涵盖状态管理、副作用处理、工程化封装，代码观感十分专业。你怎么判断这类代码是否可靠，能不能直接合并上线？
这个问题问得很刁。因为它戳中了一个真实的认知陷阱——代码看起来专业，和代码真的可靠，是两回事。而 AI 恰恰最擅长前者。
这篇就把我当时的回答，加上后来的补充思考，完整梳理一遍。
先承认一个事实：AI 的代码"卖相"极好
AI 生成的组件，往往比很多人手写的还规整：变量命名考究、注释齐全、目录结构清晰、该有的 loading 和错误处理一个不落，甚至还会贴心地加上 TypeScript 类型和 JSDoc。
这种"专业观感"是有迷惑性的。人天然会用表面信号去推断质量——代码排版整齐、术语用得对，我们就倾向于相信它逻辑也对。但 AI 的训练目标是生成"看起来最像正确代码的文本"，它优化的是相似度，不是正确性。
所以第一条原则就是:把"观感专业"这个信号的权重调到接近零。它既不加分也不减分,该怎么审还怎么审。
判断可靠性的核心:它对不对,我能不能验证
我审 AI 代码,本质上和审一个不太熟的外包同事的代码是一样的逻辑,只是更警惕。我会从几个层面往下查。
第一层:它在解决我真正要的问题吗
AI 最常见的失败不是写错语法,而是正确地解决了一个错误的问题。它会脑补需求里没说清的部分,而且补得很自然,让你不仔细看根本发现不了。
比如你让它写一个"带分页的列表组件",它可能默认分页是前端切片,而你的接口其实是后端分页。代码跑得通、界面也对,但数据量一大就全量拉取卡死。
所以第一步永远是:对着需求逐条核对,而不是对着代码看它写得好不好。代码再漂亮,解决错了问题就是零分。
第二层:状态和副作用,这是 AI 的重灾区
前端组件里最容易藏雷的就是状态管理和副作用,而这恰恰是 AI 最爱"自信地写错"的地方。我会重点盯这几处:
依赖项数组。useEffect / watch 的依赖写漏或写多,是 AI 高频翻车点。漏了导致闭包拿到旧值,多了导致无限重渲染。这种 bug 不一定立刻暴露,而是在特定交互顺序下才出现。
竞态条件。一个搜索框,快速输入触发多次请求,AI 经常不处理"后发的请求先返回"的情况,导致列表闪回旧结果。它写的 loading 看起来很完整,但根本没考虑请求竞态。
清理逻辑。订阅了事件、开了定时器、建了 WebSocket 连接,组件卸载时清理了吗?AI 时灵时不灵。内存泄漏不会让构建失败,但线上跑久了就出问题。
状态的真实来源。它有没有把本该是服务端状态的东西,冗余地拷进了本地 state?有没有用多个 state 存本可以派生计算的值?这类设计问题不影响功能,但会埋下数据不一致的隐患。
第三层:边界和异常,AI 默认走"happy path"
AI 生成的代码,主流程几乎总是对的——因为训练数据里这种正确范例最多。出问题的全在边界:
- 接口返回空数组 / null / 异常状态码,组件会不会白屏或报错?
- 请求失败了,除了一个好看的错误提示,有没有重试或降级?
- 极端输入——超长文本、特殊字符、并发操作——扛得住吗?
- 权限不足、登录过期这些非功能性分支,处理了吗?
AI 写的 try/catch 经常是摆设——catch 里要么空着,要么只 console.error 一下就把错误吞了。这种"假装处理了"的错误处理,比没有还危险,因为它会让你误以为已经覆盖了。
第四层:工程化封装,是真抽象还是过度设计
AI 特别喜欢"秀"工程能力,动不动给你封一堆 hook、抽一层 service、套个泛型。看起来很专业,但要警惕两种问题:
过度抽象。一个只用一次的逻辑,被它封装成了通用工具,反而增加理解成本。YAGNI 原则在这里很适用——不需要的抽象就是负债。
错误抽象。它抽的那一层,边界划对了吗?有没有把不该耦合的东西塞进同一个封装?抽象一旦错了,后面所有基于它的代码都会跟着歪。
判断标准很简单:这个封装,是让代码更好懂还是更难懂了? 如果我得花半天才能看懂它封的那一层在干嘛,那这层抽象就是失败的。
光靠"看"不够,必须让它经过验证
读代码能发现的问题有限,人眼对逻辑分支的覆盖远不如机器。所以审完之后,我一定会让代码跑过几道关:
类型检查和 lint。tsc --noEmit 和 eslint 先跑一遍,AI 写的类型经常是"看起来对",实际有 any 兜底或类型断言糊弄过去的地方,严格模式下一查一个准。
测试,而且是我自己补的测试。这点很关键——不能让写代码的 AI 自己写测试,然后自己跑过。同一个模型,写代码时的盲区,写测试时大概率还是盲区,它会写出"刚好覆盖它已经写对的部分"的测试,看着绿油油一片,其实啥也没验证。测试要针对边界和异常路径来补,专门攻它可能错的地方。
实际跑起来点一遍。再完整的静态检查也替代不了真在浏览器里操作。尤其是那些交互顺序相关的状态 bug,只有手动快速点、乱序点,才暴露得出来。
那到底能不能直接合并上线?
回到面试官的问题。我的答案是:
不能"直接"合并,但可以"高效地"合并。
"直接合并"——看它观感专业就 merge——是绝对不行的,这等于把 AI 的概率输出当成了确定性的正确答案。
但也不必因噎废食,退回到纯手写。正确的姿势是把 AI 当成一个产出快、但需要严格 code review 的初级队友:
- 它负责把活快速干出来,省掉我敲样板代码的时间。
- 我负责审需求对齐、审状态副作用、审边界异常、审抽象合理性。
- 自动化工具(类型、lint、测试)负责兜住我肉眼漏掉的。
- 最终为这段代码上线负责的人是我,不是 AI。
责任主体不变,这是底线。AI 可以参与生产,但不能承担责任——出了线上事故,没人会接受"是 AI 写的"这个解释。
写在最后
AI 全面进入开发流程后,工程师的核心能力正在迁移。以前比谁写得快、写得对;现在 AI 把"写"这件事的成本压到很低,比的是谁的判断力更强——能不能一眼看出哪里不对,知道该验证什么、怎么验证。
代码观感专业,从来不是可以信任的理由。能不能上线,取决于它对不对、我能不能验证、以及谁来为它负责。这套判断标准,在 AI 之前就成立,在 AI 之后只会更重要。
面试官最后说了句我挺认同的话:AI 越强,越考验用它的人。