AI 组件复用实践：构建工程化的 Skill 工作流

在日常开发中，"顺手新建一个组件"似乎是最自然的选择，但这种做法长期积累下来会导致组件库臃肿、维护成本攀升、UI一致性下降等一系列问题。更棘手的是，当 AI 参与代码生成时，它倾向于复制这种混乱，而非纠正它。我们需要的不是给 AI 一个搜索工具，而是将"复用优先"的思考过程本身流程化。

三层架构的设计逻辑

这套方案的核心设计是三层架构：AGENTS.md 负责放置基础上下文，让 AI 每轮都知道组件复用机制的存在；Hook 负责在用户提到组件相关语义时注入提示，提高触发概率；Skill 则提供统一的执行入口、稳定的输出格式和可执行脚本。三者的分工清晰——AGENTS.md 解决"不知道"的问题，Hook 解决"想不起来用"的问题，Skill 解决"执行不稳定"的问题。

工程落地的关键实现

第一层 AGENTS.md 承载的是"世界观"——告诉 AI 这个仓库有组件复用机制，默认应该先查可复用组件，查不到再考虑新建。这不是简单的文档堆积，而是让 AI 在每一轮决策时都能获得必要的上下文。Vercel 的 agent 评测表明，将基础知识放进 AGENTS.md 这种"被动上下文"后，稳定性反而比依赖 skill 主动触发更高。 第二层 Hook 解决的是"意图路由"问题。当用户在 prompt 中提到"组件复用"、"是否有现成组件"等语义时，通过额外上下文注入让 AI 优先走组件复用流程。 第三层 Skill 则需要直接提供工具函数给 AI 调用，而不是只写说明文档。统一入口的设计至关重要——把所有分散逻辑聚合到一个入口（如 find-component.js），避免 AI 在多个脚本之间犹豫或漏掉前置步骤。

索引构建与反馈机制

在实现层面，有几个值得关注的工程细节。首先是搜索范围的策略设计：在 monorepo 场景下，采用"当前应用 + 根级共享"优先的策略，而不是全仓库乱搜。具体做法是读取 workspace 配置，根据当前聚焦文件反推应用根目录，再结合预设的根作用域模式构建搜索集合。这模拟了人类工程师的查找策略——先看当前业务有没有，再看全局共享有没有。 其次是匹配算法。纯关键字匹配容易变成"垃圾召回器"，因此采用了多因素加权策略：名称精确/包含匹配、模糊匹配（编辑距离）、Token 重叠、首字母缩写匹配、当前应用加权、使用频率加权、来源质量加权等。同时设置低分阈值——如果最高分太低就触发扫描后再查，还是低分则按"无匹配"返回，避免把噪音结果塞给 AI。

AI 流程化的三条原则

很多类似方案停留在"扫一遍生成 CSV"然后过时。这次的做法是将扫描做成可复用流水线：run-scan.js 负责编排流程，index-manager.js 负责增量更新策略（保留历史记录、根据文件 hash 跳过未变化组件、支持并行扫描），扫描后进入 Agent 富化流程自动补充 summary 和 keywords。关键是在配置里启用 agent_mode_no_fallback，要求 Agent 必须完成这一步，而不是走规则引擎降级。 另一个容易被忽视的点是使用行为记录。查找命中后记录 usage，这意味着系统不是静态的——它会逐步学习团队偏好，哪些组件常被复用、哪些在特定应用里更常出现，从而提升下一次的推荐质量。

如有侵权，请联系删除。