这篇不讲它怎么实现,只讲一件事:它到底能帮你省掉多少无效搜索、无效阅读和无效 Token。
如果你平时会用 Cursor、Claude、Codex 这类 AI 编程工具写前端代码,你大概率已经踩过这几类坑:
- 项目一大,AI 一上来就先读大文件,Token 烧得飞快,回答还不稳定。
- 你明明想找业务实现,结果全局搜索先把你带到
utils、helpers、wrapper。 - 你知道"这段逻辑在写 localStorage",但你根本不知道函数名,传统符号搜索直接失效。
- 想追一个变量到底从哪来、在哪改、最后写到哪,最后只能手动点文件、滚页面、补脑数据流。
- 改一个公共函数之前,心里没底,不知道会炸到哪些页面和调用点。
最近我把自己做的前端 MCP 打磨到一个我觉得足够值得安利的状态:frontend-code-skimmer。
它不是那种"什么都能聊一点"的泛用型代码问答工具,而是一个专门给前端项目和 AI 编程助手做结构化检索、片段召回、数据流追踪、影响面分析的 MCP。
一句话概括它的价值:
不是让 AI 去硬读整个仓库,而是先把它真正该看的那几段代码,从屎山里捞出来。
这篇文章基于当前仓库代码版本 v0.4.9 整理。
先说结论:它最适合解决什么问题
我先不讲工具名,先讲结果。
1. 大文件先瘦身,再让 AI 读
skimmer_get_component_outline 会先给你一份"骨架视图"。
在当前 README 的典型场景里,一个 7000 行 的大页面,可以先压成大约 60 行 的结构骨架,官方文档给出的结论是节省约 95% Token 。
这类收益对 AI 编程工具特别直接,因为你不再需要让模型先吞整页代码,先看状态、方法、生命周期、行为标签就够了。
我在这个仓库里直接测自己的 src/tools/all-tools.ts,它有 1824 行 ,skimmer_get_component_outline 会先把它归纳成 18 个函数骨架 。
先知道"这文件到底有啥",再决定读哪个函数,体验和直接滚 1800 多行完全不是一个量级。
2. 不知道函数名,也能搜到代码
这是我最想安利的一点。
很多时候你脑子里只有"它应该是在写缓存""它应该在做路由跳转""它应该在调用某个接口",但你根本不知道函数名。
这时候传统的全局搜索、IDE 符号搜索,基本都要求你先猜名字。
frontend-code-skimmer 不是。
它支持:
skimmer_find_by_behavior:按行为搜,比如直接搜storage、network、routerskimmer_search_snippets:按自然语言或 API 意图搜,比如save to cache、localStorage setItem
也就是说,你不必再先猜"这个项目里到底叫 saveCache、persistDraft 还是 updateStorageParams"。
3. AI 第一跳不再总是命中 util 包装层
这是很多人没明说,但每天都在被坑的地方。
你问 AI:"帮我看看 localStorage 是在哪写的。"
很多工具第一跳先给你 utils/storage.ts、helpers/cache.ts、wrapper/local.ts 之类的封装层。
但你真正关心的,通常是业务页面到底在哪调了它。
这版 skimmer_search_snippets 已经在做几件很关键的事:
- 区分查询意图:
symbol_like / behavior_like / api_like / natural_language - 走 snippet-first 排序,而不是先丢一堆文件名
- 对
views/pages/features/modules这类业务文件加权 - 对
config/utils/helpers/lib/shared这类通用封装降权
这意味着它更像一个"前端业务检索器",而不是一个"把所有命中字面量都扔给你"的普通搜索器。
4. 变量数据流追踪终于不是体力活了
前端项目里最费脑子的事之一,就是追数据流。
尤其在这些场景里:
- 表单数据先初始化,再缓存回填,再被用户修改,最后再写回 storage
- 一个对象在多个方法里被改属性
- 变量经过参数传递,最后落到接口请求或 localStorage
- 想确认某个字段到底是从 props、watch、computed、用户输入还是缓存来的
skimmer_trace_data_lifecycle 是我认为这个 MCP 最"救命"的能力之一。
它不是只告诉你"哪几行提到了这个变量",而是一次聚合几个你真正关心的维度:
- 声明和整体赋值
- 属性修改
- 参数传递
- 读取引用
- Storage 落点
如果你平时经常在别人写了两三年的业务项目里接需求,这个能力的实际价值会比"智能补全"高很多。
5. 改代码之前,先知道会炸到哪
skimmer_get_call_graph 和 skimmer_get_blast_radius 这两个工具,非常适合改共享函数、公共 hooks、工具模块之前先做风险评估。
很多时候你不是不会改,你是不敢改。
因为你不知道这个函数到底被谁调,调了几层,改完会不会把一个看起来不相关的页面打挂。
这两个工具的意义,就是先把"改动影响面"变成显式信息,而不是靠经验猜。
它和常见方案相比,强在哪
我不想把它写成"吊打一切"的万能工具,因为那不真实。
更准确的说法是:它解决的是一类非常明确、而且非常高频的前端检索问题。
下面这个对比,基本就是我做它时想解决的痛点。
| 方案 | 擅长什么 | 常见问题 | frontend-code-skimmer 的优势 |
|---|---|---|---|
grep / rg / IDE 全局搜索 |
精确搜字符串,速度快 | 只能搜字符,不理解"行为""数据流""影响面" | 能按行为搜、按片段搜、按生命周期搜,不要求你先知道名字 |
| IDE 符号搜索 | 你已知函数名/类名时很方便 | 不知道名字时基本没用,拼写错也容易断掉 | find_symbol 支持精确 + FTS5 + Levenshtein,拼错也能兜住 |
| 直接让 AI 读整个文件/整个目录 | 零配置,最省事 | Token 很贵,命中不稳定,大文件尤其痛苦 | 先给 outline / snippet / code slice,把 AI 上下文压缩到真正需要看的部分 |
| 通用型 repo-RAG / 代码问答工具 | 广义问答、跨文档总结 | 第一跳容易噪,业务实现容易被 util/mock/test 抢掉 | 这个 MCP 明显偏前端代码语义,内置行为标签、业务文件优先、调用关系和生命周期追踪 |
换句话说:
它不是要替代 rg,而是补上 rg 不理解语义的那一段。
它也不是要替代通用代码问答,而是把"第一跳找对代码"这件事做扎实。
为什么我更推荐前端团队装这个,而不是继续靠"手动找"
因为前端项目有几个天然特点,特别适合这种工具:
- 文件大,页面重,状态和副作用多
- 命名不稳定,尤其历史项目里一个意思有三四种叫法
- 业务逻辑常常藏在事件回调、watch、computed、hook、storage 读写里
- 真实需求通常不是"给我搜这个字符串",而是"告诉我这个值怎么流动的"
而 frontend-code-skimmer 当前已经覆盖的场景,基本都贴着这些痛点:
- Vue 2
- Vue 3
- React Hooks
- 纯 TS/JS 工具模块
甚至连很多代码助手最容易忽略的"工具类模块"它也没放掉。
像 parser、indexer、cache、CLI、MCP、自定义 util 这类文件,也能提基础结构符号,不会只盯着组件文件看。
它最值得记住的几个能力
如果你只想记住几个关键词,我建议记这几个:
skimmer_get_component_outline
看大文件先用它。
作用是先拿骨架,不直接吃全文。
适合:
- 刚接手一个 3000 行以上的页面
- 想先看状态、方法、行为标签、生命周期分布
- 想把 AI 的上下文消耗先打下来
skimmer_search_snippets
这是我很推荐你优先体验的一个。
适合:
- 你只知道"想找缓存写入""想找接口调用""想找某个自然语言意图"
- 想让 AI 第一跳就先命中最像业务实现的代码片段
- 不想先猜函数名,再二跳
get_code_slice
skimmer_find_by_behavior
这是"绕过命名问题"的典型能力。
它会识别并打标签的行为包括:
storagenetworkroutervuexdomeventtimeri18n
也就是说,你可以直接按"做了什么"来找,而不是按"叫什么"来找。
skimmer_trace_data_lifecycle
如果你只打算深用一个工具,我建议就是它。
适合:
- 查"这个变量从哪里来"
- 查"这个对象被谁改过"
- 查"它最后有没有写进 localStorage / sessionStorage"
- 查"它被传给了哪些函数"
skimmer_get_blast_radius
改公共函数前先跑一遍。
尤其适合:
- 公共 hooks
- shared utils
- 表单转换函数
- 缓存写入函数
- 复杂页面的提交逻辑
5 分钟上手:最小配置和第一天用法
如果你是 Cursor、Claude Desktop、Codex 这类 MCP 客户端用户,直接用 npx 就行。
json
{
"mcpServers": {
"frontend-code-skimmer": {
"command": "npx",
"args": [
"-y",
"@jokeran/frontend-code-skimmer@latest"
],
"autoApprove": [
"skimmer_index_project",
"skimmer_get_component_outline",
"skimmer_find_symbol",
"skimmer_search_snippets",
"skimmer_get_code_slice",
"skimmer_trace_assignments",
"skimmer_trace_property_changes",
"skimmer_find_by_behavior",
"skimmer_trace_data_lifecycle",
"skimmer_get_call_graph",
"skimmer_get_blast_radius",
"skimmer_index_health",
"skimmer_get_project_overview"
]
}
}
}
注意一下:如果你之前见过旧版配置,里面有些能力名已经迭代过了。
现在建议直接按上面这一套最新工具名来配。
第一天最实用的调用顺序,我建议这样:
1. 先索引 你也可以对ai说帮我初始化项目,ai会自动调用该工具并自动初始化当前项目(vue,react),注意将.agent文件给忽略掉即可(.gitignore)
js
skimmer_index_project({
project_path: "/your/project"
})
README 里的首次使用示例给的量级是:50 个文件约 2 秒 。
中小项目基本就是能接受的秒级启动成本。
2. 先看骨架,不直接读全文
js
skimmer_get_component_outline({
file_path: "src/views/apply/index.vue"
})
3. 不知道名字时,先搜 snippet 或行为
js
skimmer_search_snippets({
query: "localStorage setItem"
})
js
skimmer_find_by_behavior({
category: "storage",
operation: "setItem"
})
4. 真要读实现,再切片
js
skimmer_get_code_slice({
file_path: "src/views/apply/index.vue",
symbol_name: "saveDraft"
})
5. 要追变量,就别再手动翻了
js
skimmer_trace_data_lifecycle({
variable: "storageParams",
file_path: "src/views/apply/index.vue",
storage_api: "localStorage",
max_depth: 2
})
6. 要改公共函数,先看影响面
js
skimmer_get_blast_radius({
symbol_name: "saveToCache"
})
如果你的项目跨文件 import/export 很复杂,或者同名函数比较多,建议索引时直接开精度模式:
js
skimmer_index_project({
project_path: "/your/project",
precision_mode: "precise",
selective_precise: true,
max_precise_files: 20
})
这里不用理解实现细节,你只需要知道一件事:
大项目里别傻乎乎每次都全量重算,selective_precise 就是为大仓库准备的。
哪些人会最喜欢它
我觉得至少这几类人装上后会立刻觉得值:
- 经常接手历史前端项目的人
- 团队里大量使用 AI 辅助编程的人
- Vue 2 / Vue 3 / React 混合仓库维护者
- 需要频繁定位缓存、接口、路由、副作用逻辑的人
- 害怕改公共函数、改完不知道会不会炸的人
如果你现在的开发流还是:
- 先让 AI 硬读文件
- 读不明白再继续贴更多文件
- Token 越贴越多
- 最后还是自己手动搜
那这个 MCP 基本就是你该补上的一层基础设施。
最后说一句
我做这个 MCP,不是想再造一个"会搜代码"的工具。
真正想做的是:让 AI 在前端项目里先找对代码,再谈理解和修改。
前端代码搜索最怕的不是"搜不到",而是"看起来搜到了,但第一跳就偏了"。
偏到 util、偏到 mock、偏到封装层、偏到错误的同名函数,后面所有分析都会跟着歪。
frontend-code-skimmer 想解决的,就是这个问题。
如果你也受够了让 AI 读大文件、猜函数名、在屎山里盲找逻辑,建议直接试试:
json
{
"mcpServers": {
"frontend-code-skimmer": {
"command": "npx",
"args": ["-y", "@jokeran/frontend-code-skimmer@latest"]
}
}
}
先用一次 skimmer_get_component_outline,再用一次 skimmer_search_snippets 或 skimmer_trace_data_lifecycle。
你大概率会马上明白,它为什么比"再让 AI 多读几个文件"更值。