fff — молниеносный поиск файлов для AI-агентов, Neovim и не только

«A file search toolkit for humans and AI agents. Really fast.» — официальный слоган проекта

Что такое fff и для кого он создан

fff — это набор инструментов для поиска файлов, предназначенный как для людей, так и для AI-агентов. В основе — устойчивый к опечаткам поиск по путям и содержимому, ранжирование по frecency (частота + давность открытия), фоновый наблюдатель за файловой системой и лёгкий in-memory индекс контента.

Проект изначально появился как плагин для Neovim, который полюбился многим, однако выяснилось, что многочисленным AI-оркестраторам и редакторам кода нужно то же самое: точный и быстрый поиск файлов в виде библиотеки.

Целевая аудитория:

• Разработчики, использующие Neovim в качестве основного редактора
• Инженеры, строящие AI-агентов (Claude Code, Codex, Cursor, Cline и любые MCP-клиенты)
• Авторы расширений для IDE и pre-commit хуков
• Разработчики на Rust, C и Node.js, работающие с крупными кодовыми базами

Архитектура и принцип работы

fff — это библиотека для поиска файлов, а не CLI-утилита. ripgrep и fzf — отличные инструменты, но они являются программами командной строки: каждый вызов порождает новый процесс, заново читает .gitignore, обходит директории и восстанавливает состояние в памяти. Это нормально при одиночном поиске из шелла, но плохо, когда редактор или AI-агент хочет выполнять сотни поисковых запросов за сессию.

fff хранит индекс и кэш файлов в одном долгоживущем процессе и предоставляет один и тот же Rust-ядро через четыре тонких слоя: нативный крейт (fff-search), C-библиотеку (libfff_c), SDK для Node/Bun (@ff-labs/fff-node) и MCP-сервер. Вы вызываете FileFinder.create() один раз, и все последующие поиски попадают в прогретую память.

graph TD
    A[Пользователь / AI-агент] --> B[MCP-сервер fff]
    A --> C[Neovim Plugin fff.nvim]
    A --> D[Node.js SDK @ff-labs/fff-node]
    A --> E[C FFI libfff_c]
    B --> F[Rust Core\nfff-search / fff-grep]
    C --> F
    D --> F
    E --> F
    F --> G[In-memory индекс\n+ mmap файлов]
    F --> H[SIMD fuzzy matching\nSmith-Waterman]
    F --> I[Frecency DB\nLMDB]

Ключевые возможности

1. Экстремальная скорость

На 500-тысячном чекауте Chromium разница составляет от 3 до 9 секунд на один вызов ripgrep против менее чем 10 мс на один запрос к fff.

На macOS fff примерно в 20–50 раз быстрее ripgrep при поиске по содержимому и примерно в 10 раз быстрее fzf при поиске по именам файлов.

2. Frecency-ранжирование

Каждый индексированный файл несёт оценку доступа и оценку изменения. Поиски ставят файлы, которые вы открывали недавно и часто, выше «холодных» результатов. Это та же идея, что список недавно открытых файлов в VS Code, но применённая к каждому результату поиска, а не только к боковой панели.

3. Устойчивость к опечаткам

Алгоритм Smith-Waterman для нечёткого скоринга доступен на пути grep; поиск по путям использует SIMD-ускоренное нечёткое совпадение, которое переживает пропущенные символы и перестановки.

Пример из документации:

*.rs !test/ shcema

Алгоритм нечёткого сопоставления fff значительно более полный, чем у fzf: он устойчив к опечаткам и имеет язык запросов с дополнительным синтаксическим разбором ограничений для пред-фильтрации. Например, "*.rs !test/ shcema" — полностью валидный запрос для fff, тогда как fzf ничего не найдёт даже при одной опечатке в "shcema".

4. Git-осведомлённость

Git-aware аннотации: изменённые, неотслеживаемые и поставленные на стейдж файлы помечаются тегами, чтобы агент тянулся к тому, что вы активно меняете.

5. Definition-first hinting

Строки, похожие на определения кода, классифицируются на стороне Rust — никакого накладного расхода регулярных выражений в вашем промпте.

6. Пагинация результатов

Курсорная пагинация, которая переживает вызовы. ripgrep не имеет понятия «страница 2 этих совпадений» — fff имеет.

7. Умное управление памятью

fff хранит индекс контента объёмом около 360 байт на индексированный файл — примерно 36 МБ для репозитория с 100 тыс. файлов. Бинарные, слишком большие файлы и всё, что не подходит для grep, пропускается. Если даже такой объём слишком велик, индекс может быть подкреплён файлом, отображённым в память, вместо анонимной RAM.

8. Интеграция с AI-агентами через MCP

Работает с Claude Code, Codex, OpenCode, Cursor, Cline и любым MCP-совместимым клиентом. Меньше roundtrip’ов grep, меньше потраченного контекста, более быстрые ответы.

curl -fsSL https://raw.githubusercontent.com/dmtrKovalenko/fff.nvim/main/install-mcp.sh | bash

Структура проекта (монорепозиторий)

Репозиторий организован следующим образом:

• crates/fff-search, crates/fff-grep, crates/fff-query-parser — ядро на Rust
• crates/fff-c — C FFI, используемый каждым языковым байндингом
• crates/fff-nvim — привязки Lua/mlua для плагина Neovim
• crates/fff-mcp — бинарный MCP-сервер
• packages/fff-node — Node.js SDK (@ff-labs/fff-node)
• packages/fff-bun — Bun SDK

Пример: подключение к Neovim (lazy.nvim)

{
  'dmtrKovalenko/fff.nvim',
  build = function()
    require("fff.download").download_or_build_binary()
  end,
  opts = {
    debug = { enabled = false }
  },
  lazy = false,
  keys = {
    { "ff", function() require('fff').find_files() end, desc = 'FFFind files' },
    { "fg", function() require('fff').live_grep() end, desc = 'Live grep' },
    { "fz", function() require('fff').live_grep({ grep = { modes = { 'fuzzy', 'plain' } } }) end },
  }
}

Тарифы и цены

fff — полностью бесплатный open-source проект. Никаких платных планов, токенов или подписок не существует. Единственные «затраты» — это дополнительная оперативная память, которую занимает in-memory индекс.

Плюсы и минусы

Сравнение с альтернативами

Существующие инструменты решают ту же проблему — быстрый поиск кода для AI-агентов — но с принципиально разными архитектурными решениями.

Если вы запускаете один grep из терминала — rg всё ещё правильный инструмент. Если внутри одного процесса вы запускаете их десятки — fff окупится, начиная со второго вызова.

Инструменты fff и codedb скорее дополняют друг друга, нежели конкурируют: агент может использовать fff для нечёткого поиска файлов и grep по содержимому, а codedb — для поиска символов, обзоров и анализа зависимостей.

*.rs !test/ shcema

Вердикт

fff — исключительно сфокусированный инструмент, который делает одно дело и делает это превосходно: быстрый, умный поиск файлов в долгоживущих процессах. Для людей он обеспечивает невероятный устойчивый к опечаткам опыт, для AI-агентов реализует самый быстрый поиск файлов с дополнительной «памятью», предлагающей лучшие результаты на основе frecency, статуса git, размера файла, совпадений определений и многого другого. fff — отличный способ сократить время и токены, давая AI-агенту небольшую встроенную память для поиска файлов.

Кому подойдёт:

• ✅ Пользователям Neovim, которые хотят заменить Telescope/fzf-lua на что-то умнее
• ✅ Разработчикам AI-агентов, работающим с Claude Code, Cursor, Cline
• ✅ Инженерам, строящим IDE-расширения или инструменты для больших репозиториев
• ❌ Тем, кто ищет разовый grep из терминала (используйте rg)
• ❌ Проектам, которым нужен полный AST-анализ и символьный индекс

Рейтинг: 8.5/10

Минус балл за pre-release статус и ограниченную поддержку не-ASCII символов, минус полбалла за необходимость Rust-тулчейна при сборке из исходников.