前端面试官：你让AI生成组件，怎么保证不重复造轮子？ 💥 #前端 #程序员 #前端面试 #前端开发 #web前端

今天面了一个五年资深前端。 简历上写着，深度使用AI辅助开发，擅长用Copilot和GPT5生成前端代码。 我直接问他：现在团队全面用AI生成组件页面和业务逻辑，你一周能产出一倍的代码量，但我发现，同一个按钮组件，AIGC在订单页生成了一个带margin-top的版本，在用户中心页，又生成了一个不带边距的版本。两个地方的弹窗逻辑，一个用useState控制显隐，另一个用Ref加类名切换。你怎么保证，AI生成的代码，在整个项目里风格一致，逻辑可维护，不会变成屎山加速器？ 他回答：我们会在提示词里，写清楚项目规范，比如使用Tailwind CSS，组件用函数式声明，状态用useState，每次生成后，人工review一下，不一致的地方手动改。 我点点头，思路对。但如果团队十个人都在用AI，每个人写的提示词不一样，AI上下文窗口长度有限，它记不住你三个月前定下的所有表单必须用Formik加Yup，而且AI为了解决问题，经常自己引入新的依赖库，比如为了一个日期格式化，就装了moment.js，而项目本来已经有dayjs。你怎么防止AI重复造轮子，引入技术债？ 他愣了一下：那可以在代码审查里卡住，或者做一个内部的AI规则文件。 我追问：好，那如果AI生成了一段复杂的列表渲染逻辑，性能没问题，但可读性极差。 辨量名权是ABtemp函数，拆分力度混乱，另一个同事接手完全看不懂。你总不能要求每个bug都让AI再解释一遍吧？怎么保证AI代码的长期可维护与互信？ 它有点犹豫：“可以要求AI加注释，或者用eslint强制命名规范。” 我笑了：“你说的是手工时代的答法。2026年，一个项目中70%的代码由AI生成，靠人工review和规范文档已经堵不住了。这考的根本不是你会不会写提示词，而是你如何设计一套AI生成代码的契约、校验、重构与知识沉淀的四层工程体系，让AI像资深老员工一样守规矩、可追溯、好维护。” 它彻底沉默了，面试到此结束。 如果这道题你也不会回答的话，我整理了让大厂HR沉默的必考题库，涵盖VO灵魂考问、React高频陷阱、JS十年面试题，点个赞，评论区甩666，打包带走。 这道题表面是怎么用AI写代码，内核是生成规约、一致性校验、依赖治理、可读性度量四个维度的交织。会问ChatGPT只是常识，能设计出AI代码自动符合设计系统、依赖不重复、逻辑可解释、变更可追溯的流水线，才是2026年该有的工程底盘思维。 第一层，生成契约书，让AI自带项目记忆。2026年已经不是靠提示词手写规范的年代了，标准化AI生成要做三件事：项目知识库注入。在团队的AI工作流里挂载一个架构知识库，包含组件库、文档、设计令牌和指南。 已有工具函数清单、依赖白名单。 每次AI生成代码前，自动检索这个知识库，把相关约定注入到上下文中。 比如生成表单时，AI会被强制要求使用Formic，日期处理只能用Degis，颜色值必须从设计令牌里取，不允许硬编码。 FuseShot 范例锚定。为每个常用模式：列表页、弹窗、表单、卡片，提供1-2个标杆代码范例。AI在生成同类组件时，模板仅修改业务字段和接口调用，保持结构、命名、错误处理风格完全一致，这叫范例驱动生成，比自由生成加事后规范稳定十倍。 依赖白名单与沙箱。AI的依赖提案自动被一个依赖治理引擎拦截，如果它想引入一个新库，引擎先检查有没有功能重叠的已有库，有则拒绝，并提示请使用Degis。确实需要新库，必须附带CVE安全评分、包体及影响、维护活跃度，通过后才能纳入，AI没有自由引入依赖的权利。 第二层，生成后校验，自动化置信锁。代码生成出来，不等人工看，流水线先跑三道关。 结构指纹比对：把AI生成的AST抽象语法树和项目基准模式做差异分析，比如弹窗组件必须有一个isOpen状态和一个onClose回调，如果AI生成的没有，自动拒绝并触发重新生成。指纹库从存量代码中学习，新项目可以手工标注核心规则。 依赖与API漂移检测：AI调用的任何函数、组件、Hook，先查一下是否在项目 已有导出列表里，它自作主张写了一个format date，而项目中有Utxtate，电梯S里的format，检测引擎直接标红。 要求AI复用现有实现，不生成重复逻辑。 可读性评分：引入代码可解释性模型，变量名的语义密度、函数圈复杂度、浅套深度、注释覆盖度。 自动触发重构模式，AI自己或交给重构机器人重写一遍，直到可读性达标，让AI写的代码像人写的，甚至比人写的更干净。 第三层，运行时可维护性。AI代码也是资产，不是一次性产物。你合入了AI生成的代码，三个月后需求变更，谁来改？ 双向追溯链：AI生成的每个函数、每个组件，都自动打上生成标签，记录它是由哪个模型、哪条提示词、基于哪些范例生成的。修改时，AIMO是因为列表预期超过100项，AI当时为什么这么做，清清楚楚，不再是一团黑盒。 持续对齐机器人：每天晚上，一个后台服务会把当天新生成的AI代码，和项目最新的架构规范做一次对齐检查。比如规范升级了，要求所有异步操作必须用React Query，而三个月前的AI代码还在写UseEffect加Fetch，机器人自动发起重构PR，把老旧模式升级到当前标准。 AI债务不过夜，抽象一致性守护：如果AI在三个不同地方生成了几乎一样的逻辑片段，比如从EL取参数并校验格式，守护机器人会自动检测到，重复度超过80%。 提示是否抽成公共Hook，并给出推荐实现。 AI生成时不知道复用，系统提示做二次归纳。 第四层，知识反哺。 AI越用越守规矩。所有上述校验拦截过的错误、修正过的代码、人工Review时给的反馈，都会回流到项目知识库里，用于微调团队自己的专属代码生成模型，不会再犯重复装依赖、命名不规范、不遵循设计系统的初级错误。它从一个只会写代码的实习生，进化成了完全理解你们团队架构风格的核心贡献者。 标准化AI生成代码，从来都不是写几句“请按规范生成”的提示词就完事儿的事，它是一个集设计知识注入、指纹校验、依赖治理、可读性度量、债务自动化重构、模型持续微调六位一体工程体系的能力。会问AI要代码只是入门，能教会AI守规矩才是本事。 最后留个思考题：如果你的AI生成的代码完全通过了所有校验，但业务逻辑理解错了，它实现了一个折扣计算，却把满100减20当成了满100打8折，你如何在生成阶段就让AI自动对齐产品的业务规则文档？想清楚这个，2026年的AI工程化就算真正过关了。