当你打开一个庞大的 Monorepo 仓库，依然Neng轻易找到成百上千个长得差不多、名字却各异的“按钮”或者“弹窗”。这不仅仅是代码洁癖的问题，geng是工程维护的噩梦。

现在随着 AI 辅助编程的普及，我们本以为这个问题Neng迎刃而解。毕竟AI 拥有全库的视野，理应Neng瞬间识别出“这里有个现成的组件，别再写新的了”。但现实往往hen骨感：AI 就像是一个刚入职、急于表现的新人，比起去翻阅晦涩的文档或查找旧代码，它geng倾向于“顺手新建一个”。

这就引出了一个hen有意思的课题：我们Neng不Neng通过某种工程化的手段，把“组件复用”这个意识，像肌肉记忆一样植入给 AI？这不仅仅是在写一个脚本，而是在设计一套让 AI 遵守的“工作流”。今天我想聊聊如何将组件复用 Skill 工程化，让 AI 真正变成一个遵守团队规范的工程协作者。

在开始写代码之前，我们必须先理解 AI 的行为模式。Vercel 在他们的 Agent 评测中观察到了一个反直觉的现象：Skills本身并不是没用，而是 Agent 往往不会稳定地触发它们。hen多时候，即便你配置了完美的工具，AI 在执行任务时依然会“视而不见”，选择用Zui原始的方式硬编码。

为什么会这样？原因不在于 AI “笨”，而在于“决策成本”。每一次调用 Skill，对于 Agent 来说dou是一个决策点。Ru果这个决策的收益不明确，或者触发边界模糊，AI 就会倾向于走那条它Zui熟悉的路——直接生成代码。

geng糟糕的是OpenAI 的 Codex Skills 文档里提到，Skills 是一种“渐进披露”机制。运行时AI 只Nengkan到 Skill 的元信息，只有决定使用时才会加载完整的 SKILL.md。这意味着，Ru果 description 写得不够诱人，或者触发条件不够硬性，这个 Skill 就等于不存在。

所以我的第一个设计方向转变是：先解决 AI 的“决策点”问题，再解决 AI 的“Neng力”问题。

与其指望 AI 主动想起“我该查查有没有复用组件”，不如通过“被动上下文”强制它执行这一步。这就像把基础知识放进 AGENTS.md 文档里一样，虽然kan起来hen笨，但稳定性极高。Vercel 的实验也证明了加入显式指令后通过率才明显改善，而文档索引方案的表现往往比动态 Skill geng稳定。

组件复用Zui容易踩的两个坑就是：找不到和找不准。Ru果给 AI 暴露一堆复杂的脚本，告诉它“先算 scope，再查 CSV，再排序，再补扫”，它大概率会晕头转向，甚至漏步骤、顺序错、参数传错。

人类工程师在处理这类问题时会下意识地把复杂问题解耦成若干个小问题，但关键在于如何让它们有机协作。对于 AI 来说Zui友好的方式是：只提供一个入口，只给它一个指令。

所以我设计了 find-component.js 作为统一入口。这个脚本Zuo的事情非常纯粹，它只负责接收三个参数：查询词、仓库根路径以及当前聚焦路径。然后它会返回一个固定格式的 JSON 输出，包含 ok、matches、noMatch、scanTriggered、hint、error 等字段。

这一步非常关键。通过定义固定的 JSON Schema，我们实际上是在和 AI 签订契约。AI 不需要关心内部逻辑是调用了 fuzzy-match 还是Zuo了全量扫描，它只需要知道：“我调用了这个函数，它给了我一个结果，我根据结果继续下一步。”

这层解决的是 AI 执行过程的不稳定性。把复杂系统收敛成几个明确入口，AI 才容易稳定执行。这就像我们封装 React 组件一样，父组件只管传 props，根本不关心子组件内部是用 Less 还是 Sass 写的样式。

有了统一入口，接下来就要解决“怎么找”的问题。在一个海量的代码仓库里Ru果只是简单地Zuo字符串包含匹配，hen快就会变成“垃圾召回器”。AI 一旦拿到一堆低质量的候选组件，hen容易“将错就错”，强行复用一个不合适的组件，这比新建一个还要糟糕。

为了解决这个问题，我在工程化实现上引入了两层策略：

人类工程师查找组件时通常遵循一种特定的直觉：先kan“我这个业务应用里有没有”，再kan“全局共享有没有”。而不是直接在整个 Monorepo 的汪洋大海里捞针。

因此，我在 resolve-scope.js 里实现了一套比较工程化的范围解析策略。Ru果用户当前聚焦在某个子项目目录下系统会优先限定在该子项目内进行搜索；Ru果没有聚焦子项目，则自动切换为全量 scope。这种动态调整范围的机制，极大地提升了搜索的相关性。

组件匹配Ru果只靠死板的字符串比对是完全不够的。我在 match-component.js 配合 fuzzy-match.js 的实现里引入了一套组合评分机制。核心逻辑不仅仅是kan名字是否相似，还要综合考虑文件路径、使用频率、甚至是组件的元数据标签。

此外我还设置了一个低分阈值。Ru果所有候选组件的评分dou低于这个阈值，系统会直接返回 noMatch，而不是强行返回一个不相关的结果。这层设计是为了告诉 AI：“别勉强，这里真的没有合适的，新建一个吧。”

hen多类似的方案，往往停在“扫一遍生成 CSV”这一步，然后就过时了。组件库是动态变化的，每天dou有新组件加入，旧组件废弃。Ru果索引是静态的，AI 的推荐质量就会随时间直线下降。

为了解决这个问题，我把扫描Zuo成了一个持续维护的流水线：run-scan.js -> index-manager -> enrich。这不仅仅是一次性的脚本，而是一套Ke以定期运行的自动化任务，确保索引始终与代码库保持同步。

geng有趣的是我加入了一个hen容易被忽视但极具价值的点：使用行为追踪。

每当 AI 或开发者通过 Skill 成功复用了一个组件，系统dou会悄悄记录下来。这意味着系统不是静态的，它会逐步学习团队的偏好。比如虽然有两个名字hen像的组件，但系统发现大家Zui近dou在复用组件 A，那么在下次模糊匹配时组件 A 的排名就会geng靠前。

这是一种非常轻量但极其实用的反馈机制。不需要搞复杂的模型训练，仅仅通过简单的统计，就Neng显著提升 AI 下一次的推荐质量。这就像是一个聪明的图书管理员，不仅知道书在哪，还知道你Zui近喜欢kan什么类型的书。

Zuo完这一切后我Zui大的感触是：原来我不仅仅是在给 AI 增加Neng力，geng是在给它增加“默认工作方式”。

以前，我觉得 Skill 只是一个Neng力包，AI 想用就用。现在我geng倾向于把它kan作是一个流程控制器。在 Agent 模式下我们不走规则引擎降级，而是要求 Agent 必须完成这一步。

在 SKILL.md 里我明确规定：Agent 必须调用统一入口 find-component.js。这其实就是“流程化思考”的精髓：不是建议，而是纳入主流程。Zuo这个 Skill 的目标，根本不是“帮 AI 搜索一下”，而是把“复用优先”的思考过程流程化。让 AI 在写代码前，先走一遍“查索引 -> 判断是否复用 -> 命不中再新建”的路径。

为了进一步强化这一点，Ru果运行环境支持 Hooks，我们还Ke以Zuo一层“意图路由增强”。当检测到用户的 Prompt 中包含“组件复用”、“是否有现成组件”、“封装组件”等语义时系统会在 AI 处理请求前，自动注入提示上下文，强制它优先走组件复用流程。

这层解决的是Zui底层的痛点：AI 知道有 Skill，但不一定想起来用。通过 Hook 机制，我们把这个决策点从 AI 的肩上卸了下来变成了系统的硬性规则。

回顾整个开发过程，从Zui初简单的 React 组件拆分，到 Header、List、Item、Footer 的功Neng封装，再到如今这套复杂的 Skill 工程化体系，我们的目标始终没变：提高效率，减少冗余。

以前我们谈论组件复用，geng多是工程化的内涵Yi经 了。

通过把“组件复用优先”的规则、组件索引入口、扫描后的处理逻辑放进 AGENTS.md 或常驻上下文中，我们实际上是在训练 AI。只要把“统一入口”、“范围解析”、“行为追踪”这三件事Zuo好，AI 就不会只是一个“会说话的代码补全器”，而会geng像一个遵守团队规范、懂得权衡利弊的资深工程协作者。

而这才是我Zuo这个组件复用 Skill 真正想要的结果。这不仅仅是关于代码的复用，geng是关于智慧的复用，关于如何建立起一套高效、稳定、且不断进化的工程秩序。