★ FEATURED ARTICLE 一、核心回答核心就是让 AI 生成前先查能复用就别新建如果确实要新建生成后把它纳入组件库再人工确认一次。这句话就够作为第一层答案。二、为什么“让 AI 先查组件”还不够因为真正的问题不是有没有一个名字叫 Button 的组件而是这个需求 ↓ 项目里有没有功能相同/相近的组件 ↓ 能不能直接复用 ↓ 能不能通过扩展现有组件解决 ↓ 如果不能才需要新建例如项目里已经有ConfirmButton SubmitButton OkButtonAI 单纯搜索文件名很可能认为我要 ConfirmButton 项目里没有 ConfirmButton ↓ 创建 ConfirmButton但实际上SubmitButton OkButton ConfirmButton ↓ 功能高度重叠所以组件复用不能只靠名称搜索而要让 AI 能理解组件的功能、接口、适用场景和所属业务域。三、第一步建立 AI 能理解的组件索引核心就是给组件建立一份机器可读的组件元数据。例如{name:ConfirmButton,description:用于确认用户操作的按钮,category:business,domain:order,props:{text:string,loading:boolean,disabled:boolean,onConfirm:() void},scenarios:[订单确认,支付确认,删除确认],examples:[ConfirmButton text\确认支付\ /],path:src/components/order/ConfirmButton}这样 AI 搜索的就不只是ConfirmButton.tsx而是功能 Props 使用场景 业务域 示例 代码位置这里可以进一步做语义检索组件数量比较大的时候可以把这些 metadata 做 embedding放到向量数据库里。用户说“我要一个用于确认订单提交的按钮。”检索出来ConfirmButton 相似度0.91 SubmitButton 相似度0.86 ActionButton 相似度0.63AI 就有机会发现已经有一个非常接近的 ConfirmButton不应该直接创建新的。但这里要注意向量相似度只能负责“召回候选”不能直接决定“必须复用”。这是很重要的面试点。四、第二步把“存量检查”变成生成流程的一部分不能只是告诉开发“你让 AI 记得先查。”而应该把它变成固定流程。例如用户提出需求 ↓ 检索组件索引 ↓ 找到候选组件 ↙ ↘ 是 否 ↓ ↓ 分析是否 进入新组件设计 可以复用 ↓ ┌──────────────┐ │ 直接复用 │ │ 扩展现有组件 │ │ 新建组件 │ └──────────────┘甚至可以把规则直接放进 AI Agent 的工作流Step 1检索组件索引 Step 2分析候选组件 Step 3判断能否复用 Step 4如果可以 → 给出复用方案 Step 5如果现有组件需要小幅扩展 → 优先修改/扩展 Step 6只有无法满足需求时 → 创建新组件 Step 7新组件创建后 → 更新组件索引这比单纯在 Prompt 里写一句“生成前检查 components 目录。”可靠得多。五、第三步怎么处理“80% 相似但 Props 不一样”这是这道题真正开始拉开差距的地方。例如ConfirmButton已有ConfirmButton text确认 loading{loading} onConfirm{handleConfirm} /现在 AI 要生成SubmitButton label提交 submitting{submitting} onSubmit{handleSubmit} /表面上代码结构很像但接口不同。这时候不能简单说“相似度超过 70%直接复用。”因为代码相似 ≠ 业务上应该复用。正确做法应该是候选组件召回 ↓ 功能相似度 ↓ 接口相似度 ↓ 代码结构相似度 ↓ 业务域 ↓ 依赖关系 ↓ 最终判断例如最终得到发现 ConfirmButton 功能相似度92% 代码结构相似度84% 接口相似度68% 业务域相同 建议扩展 ConfirmButton 而不是创建 SubmitButton如果只是接口不同但本质功能相同可以考虑统一 Props或者在现有组件上增加能力而不是继续造一个新的组件。六、AST 到底有什么用AST 更适合做代码结构分析。例如function ConfirmButton({ loading, disabled, onConfirm }) { return ( button disabled{loading || disabled} onClick{onConfirm} 确认 /button ); }可以通过 AST 分析组件结构 ├── props │ ├── loading │ ├── disabled │ └── onConfirm ├── button ├── disabled 条件 ├── click handler └── children然后和另一个组件进行结构层面的比较。所以更准确的说法是向量检索负责从大量组件里召回“可能相关”的候选AST 等代码分析手段负责进一步比较代码结构最后再结合功能和业务域做判断。这句话就比较像真正做过工程的人。七、第四步最关键的是业务域隔离这是比较重要、但还可以讲得更深的地方。假设有订单域 OrderConfirmButton 支付域 PaymentConfirmButton两个组件可能长得非常像按钮 loading disabled confirm甚至代码可能达到90% 相似但不能因为相似就合并。因为订单域 ↓ 订单状态 订单权限 订单接口 订单业务规则 支付域 ↓ 支付状态 支付权限 支付接口 支付业务规则强行抽成CommonConfirmButton很可能最后变成CommonConfirmButton isOrder{...} isPayment{...} orderStatus{...} paymentStatus{...} ... /最后组件变成一个巨型条件分支。所以组件复用的原则不是“越多复用越好”而是“稳定的共性才抽业务差异大的就隔离”。这句话非常值得背。八、所以组件应该怎么分层比较合理的是组件体系 │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ 基础组件 通用业务组件 业务域组件 │ │ │ Button/Input UserAvatar OrderCard Modal/Table Upload PaymentPanel1. 基础 UI 组件例如Button Input Modal Select Table特点业务无关 稳定 复用范围大应该尽可能统一。2. 通用业务组件例如UserAvatar FileUploader AddressSelector多个业务都需要但已经带有一定业务语义。3. 业务域组件例如OrderCard PaymentPanel CouponSelector这种组件虽然可能和其他业务组件长得很像但业务边界明显。不要为了消灭重复代码而强行合并。九、完整流程应该是这样的真正落地以后可以形成一个闭环用户需求 ↓ AI 理解需求 ↓ 检索组件 Metadata ↓ ┌─────────┴─────────┐ ↓ ↓ 找到候选组件 没找到 ↓ ↓ 功能/接口/代码分析 新组件设计 ↓ ↓ 业务域判断 代码生成 ↓ ↓ ┌──────┼──────┐ ↓ ↓ ↓ ↓ ↓ 直接复用 扩展 隔离 自动登记 Metadata │ │ │ ↓ └──────┴──────┴──────→ Code Review ↓ 合并/淘汰冗余 ↓ 更新组件索引这才真正形成检索 → 判断 → 复用/新建 → 登记 → Review → 再进入索引的闭环。十、那为什么还需要人工 Review因为有些事情 AI 很难单独做最终决策。例如A 组件和 B 组件 90% 相似AI 可以告诉你高度相似但它不一定知道A 属于订单域 B 属于支付域更不知道未来两个业务团队是否会独立演进所以最终还是需要工程规则AI 负责检索、分析、推荐 工程规则 负责边界约束 人工 负责最终架构决策十一、这道题真正考什么它考的不是“你会不会让 AI 写组件。”而是“你能不能让 AI 在现有工程约束下写组件。”普通开发的思路需求 ↓ AI生成 ↓ 提交高级工程师的思路需求 ↓ 检索现有资产 ↓ 判断复用/扩展/新建 ↓ 生成 ↓ 登记 ↓ Review ↓ 持续治理所以这道题真正考的是AI Coding 组件复用 工程治理 架构边界。十二、面试官继续追问追问 1AI 为什么不能直接扫描整个项目可以扫描但扫描 ≠ 理解 ≠ 正确决策。项目里的组件可能命名不同 目录不同 Props 不同 业务域不同 文档缺失 代码已经废弃所以需要先建立结构化的组件索引降低 AI 每次从源码重新理解整个项目的成本。追问 2为什么不用文件名搜索因为ConfirmButton SubmitButton OkButton完全可能是三个名字但实际上是同一种组件。所以需要关键词检索 语义检索 代码结构分析 业务域过滤追问 3向量相似度高就一定复用吗不一定。向量检索主要用于召回候选而不是直接做最终决策。最终还要结合功能 接口 代码结构 业务域 依赖 演进关系判断。追问 4两个组件 90% 相似为什么不合并因为技术相似不代表业务上应该复用。如果两个组件属于不同业务域而且未来演进方向不同强行复用可能带来更大的耦合。追问 5AI 新生成组件以后怎么办不能生成完就结束。应该新组件 ↓ 生成 Metadata ↓ 注册组件索引 ↓ Code Review ↓ 进入组件库这样下一次 AI 才能检索到它。追问 6如果已经产生了三个重复组件怎么办可以定期做组件扫描 ↓ 语义相似度分析 ↓ 代码结构分析 ↓ 识别重复/近似组件 ↓ 人工确认 ↓ 合并 ↓ 废弃冗余组件所以组件治理不是一次性的而是一个持续过程。十三、最终满分答案如果面试官只给你几十秒我建议直接这么说让 AI 生成组件时我不会只要求它先查目录而是给项目建立一套可检索的组件索引把组件的功能、Props、使用场景、代码位置和业务域都记录下来。AI 生成前先检索优先判断是直接复用、扩展现有组件还是新建对于相似组件可以结合语义检索和 AST 等代码分析手段做二次判断但最终还要结合业务域决定是否复用。新组件生成后再登记到索引并通过 Code Review 和定期治理清理重复组件。再压缩成一句真正适合第一句话的核心就是让 AI 生成前先查、相似时先判断、生成后再登记并用业务域控制复用边界。这比单纯说“让 AI 先查组件没有就生成”高一个层级因为后者解决的是有没有查而真正的工程问题是查到了以后怎么判断该不该复用以及新组件怎么反过来进入这套体系。
阅读完成 · 觉得有帮助？
