Проблема: ваш AI-ассистент ничего не понимает в вашем терминале
Вы открываете диалог с Claude Code, Cursor или любым другим AI-ассистентом. Пишете: "Посмотри, в чём ошибка в этом коде". Ассистент отвечает: "Где логи? Что происходило до ошибки? Какую команду вы запускали?"
Вы копируете последние 20 строк из терминала. Контекст съедается. Ассистент теряет нить. Вы тратите 5 минут на объяснение, что вы вообще делали последние полчаса.
Знакомо? Я потратил на это полгода, пока не осознал: проблема не в ассистенте. Проблема в том, что у него нет контекста моей работы. Терминал — это черный ящик. Для ассистента это просто поток случайных символов.
Большинство разработчиков копируют логи вручную. Это как каждый раз заново объяснять коллеге, над чем ты работал. Утомительно, неэффективно, убивает поток.
Решение: фоновая суммаризация каждой сессии
Вместо ручного копирования — автоматическая суммаризация. Каждая сессия терминала (от открытия до закрытия) записывается в SQLite. Каждые N команд или по таймеру фоновый процесс на Rust запускает Qwen2.5-0.5B через llama.cpp и генерирует краткое описание: что делал пользователь, какие команды выполнил, какие ошибки получил, какой вывод был.
Эта суммаризация сохраняется вместе с сырыми логами. Когда вы обращаетесь к ассистенту — он получает не 200 строк сырого текста, а 3-5 предложений контекста плюс ключевые команды и ошибки.
Почему именно этот стек? (И почему не другие)
Перед тем как писать код, давайте разберёмся с выбором технологий. Потому что 80% провальных проектов начинаются с неправильного выбора инструментов.
Модель: Qwen2.5-0.5B, а не Llama 3.2 или Gemma3
На 29.01.2026 есть десятки моделей. Почему именно Qwen2.5-0.5B?
- Размер: 0.5 миллиарда параметров. После квантования в Q4_K_M — около 300 МБ. Загружается за секунды, работает в фоне без съедания всей оперативки.
- Контекст: 32к токенов. Для суммаризации сессии терминала (обычно 500-2000 строк) хватит с запасом.
- Качество суммаризации: Qwen2.5 специально доучивали на задачах сжатия текста. В сравнении с Llama-3.2-1B-Instruct он даёт более структурированные и точные выводы для технических логов.
- Лицензия: Apache 2.0. Можно использовать в коммерческих проектах без головной боли.
Пробовал Llama 3.2 1B? Она чаще галлюцинирует в технических контекстах. Gemma3 2B? Тяжелее, медленнее, а выигрыша в качестве для нашей задачи нет. Подробнее о сравнении локальных альтернатив для разработки читайте в статье "Замена Claude Code для команды разработчиков".
Инференс: llama.cpp, а не Ollama или text-generation-webui
llama.cpp — это не просто "ещё один бэкенд". Это:
- Нативный C++: минимальные оверхэды, можно встраивать в Rust через FFI или использовать как отдельный процесс.
- Поддержка квантования: Q4_K_M, Q5_K_S — выбирайте баланс скорость/качество под ваше железо. Без квантования 0.5B модель весила бы 1.9 ГБ вместо 300 МБ.
- Стабильность: Не падает при долгой работе в фоне. Не течёт память. Проверено на серверах, которые работают месяцами.
Ollama? Хорош для экспериментов, но для production-фонового процесса слишком тяжёлый. text-generation-webui? Это веб-интерфейс, а нам нужна библиотека. Если хотите глубже разобраться в аргументах llama.cpp, смотрите "Аргументы llama.cpp: от слепого копирования команд к осознанной настройке".
Язык: Rust, а не Python или Go
Python? Забудьте. GIL, оверхэды, dependency hell. Фоновый процесс должен работать годами без перезагрузки и утечек памяти.
Go? Лучше, но... сборка мусора может вызвать лаг в самый неподходящий момент. А нам нужна предсказуемая производительность.
Rust:
- Нет рантайма, нет сборки мусора.
- Статическая линковка — один бинарный файл, который можно скопировать на любую машину.
- Отличные биндинги к SQLite (rusqlite) и работа с процессами.
- Если система упадёт — SQLite транзакции обеспечат целостность данных.
Пошаговая реализация: от нуля до работающего демона
1 Подготовка модели и llama.cpp
Сначала скачиваем и квантуем модель. На 29.01.2026 актуальная версия — Qwen2.5-0.5B-Instruct.
# Скачиваем оригинальную модель (если нет)
# Используем Hugging Face Hub
pip install huggingface-hub
huggingface-cli download Qwen/Qwen2.5-0.5B-Instruct --local-dir ./qwen2.5-0.5b-instruct
# Клонируем и собираем llama.cpp с поддержкой Metal/CUDA
# (актуальный коммит на 29.01.2026)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j8
# Конвертируем модель в формат GGUF и квантуем в Q4_K_M
# Это оптимальный баланс для нашей задачи
python3 convert-hf-to-gguf.py ../qwen2.5-0.5b-instruct --outtype q4_k_m
# Получаем файл: qwen2.5-0.5b-instruct-q4_k_m.gguf
# Размер: ~300 МБНе используйте INT8 квантование для этой модели — потеря качества заметна для суммаризации. Q4_K_M сохраняет достаточно информации о внимании, что критично для понимания контекста. Подробнее о тонкостях квантования Qwen моделей читайте в практическом руководстве по квантованию.
2 Схема базы данных SQLite
Создаём базу для хранения сессий терминала. Не просто файл с логами — структурированную базу с метаданными.
-- schema.sql
CREATE TABLE IF NOT EXISTS terminal_sessions (
id INTEGER PRIMARY KEY AUTOINCREMENT,
session_id TEXT NOT NULL UNIQUE, -- UUID сессии
start_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
end_time TIMESTAMP,
working_directory TEXT,
hostname TEXT,
raw_logs TEXT, -- Сырые логи (можно сжимать gzip)
summary TEXT, -- AI-суммаризация
commands_count INTEGER DEFAULT 0,
error_count INTEGER DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE IF NOT EXISTS terminal_events (
id INTEGER PRIMARY KEY AUTOINCREMENT,
session_id TEXT NOT NULL,
event_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
event_type TEXT CHECK(event_type IN ('command', 'output', 'error')),
content TEXT,
FOREIGN KEY (session_id) REFERENCES terminal_sessions(session_id)
);
CREATE INDEX idx_sessions_time ON terminal_sessions(start_time);
CREATE INDEX idx_events_session ON terminal_events(session_id);Зачем такая сложность? Потому что потом вы захотите:
- Искать сессии по дате
- Анализировать частоту ошибок
- Строить графики активности
- Экспортировать данные в другие системы
Плоский файл с логами этого не позволит. SQLite — бесплатно, без сервера, транзакционно.
3 Ядро на Rust: перехват и запись событий
Создаём новый проект Rust:
cargo new terminal-summarizer --bin
cd terminal-summarizer
# Добавляем зависимости в Cargo.toml
# cargo add rusqlite serde_json uuid chrono
# cargo add --git https://github.com/ggerganov/llama.cpp.rs llama-cpp-rsОсновной модуль для перехвата событий терминала:
// src/recorder.rs
use rusqlite::{Connection, params};
use uuid::Uuid;
use chrono::Utc;
use std::process::{Command, Stdio};
use std::io::{BufRead, BufReader};
use std::sync::{Arc, Mutex};
pub struct TerminalRecorder {
db: Arc>,
session_id: String,
working_dir: String,
}
impl TerminalRecorder {
pub fn new(db_path: &str) -> Result> {
let conn = Connection::open(db_path)?;
// Инициализируем таблицы если их нет
conn.execute_batch(include_str!("../schema.sql"))?;
let session_id = Uuid::new_v4().to_string();
let working_dir = std::env::current_dir()?
.to_string_lossy()
.to_string();
// Записываем начало сессии
conn.execute(
"INSERT INTO terminal_sessions (session_id, working_directory, hostname) VALUES (?, ?, ?)",
params![&session_id, &working_dir, hostname::get()?.to_string_lossy()],
)?;
Ok(Self {
db: Arc::new(Mutex::new(conn)),
session_id,
working_dir,
})
}
pub fn record_command(&self, command: &str) -> Result<(), Box> {
let db = self.db.lock().unwrap();
db.execute(
"INSERT INTO terminal_events (session_id, event_type, content) VALUES (?, 'command', ?)",
params![&self.session_id, command],
)?;
// Обновляем счётчик команд в сессии
db.execute(
"UPDATE terminal_sessions SET commands_count = commands_count + 1 WHERE session_id = ?",
params![&self.session_id],
)?;
Ok(())
}
pub fn record_output(&self, output: &str) -> Result<(), Box> {
let db = self.db.lock().unwrap();
// Простая эвристика для определения ошибок
let is_error = output.contains("error:")
|| output.contains("Error:")
|| output.contains("ERROR")
|| output.to_lowercase().contains("fail");
let event_type = if is_error { "error" } else { "output" };
db.execute(
"INSERT INTO terminal_events (session_id, event_type, content) VALUES (?, ?, ?)",
params![&self.session_id, event_type, output],
)?;
if is_error {
db.execute(
"UPDATE terminal_sessions SET error_count = error_count + 1 WHERE session_id = ?",
params![&self.session_id],
)?;
}
Ok(())
}
pub fn finalize_session(&self) -> Result<(), Box> {
let db = self.db.lock().unwrap();
db.execute(
"UPDATE terminal_sessions SET end_time = ? WHERE session_id = ?",
params![Utc::now().to_rfc3339(), &self.session_id],
)?;
// Собираем все события для суммаризации
let events: Vec = db
.prepare("SELECT event_type || ': ' || content FROM terminal_events WHERE session_id = ? ORDER BY event_time")?
.query_map(params![&self.session_id], |row| row.get(0))?
.collect::>()?;
let raw_logs = events.join("\n");
// Сохраняем сырые логи
db.execute(
"UPDATE terminal_sessions SET raw_logs = ? WHERE session_id = ?",
params![&raw_logs, &self.session_id],
)?;
Ok(())
}
} Это основа. На практике нужно интегрировать с конкретным shell (bash, zsh, fish) через хуки типа preexec и precmd. Но это тема отдельной статьи.
4 Суммаризатор: интеграция с llama.cpp
Вот где начинается магия. Создаём отдельный процесс (или поток), который раз в N минут или после N команд запускает суммаризацию.
// src/summarizer.rs
use std::process::{Command, Stdio};
use std::io::Write;
use serde_json::json;
pub struct TerminalSummarizer {
model_path: String,
llama_cpp_path: String,
}
impl TerminalSummarizer {
pub fn new(model_path: &str, llama_cpp_path: &str) -> Self {
Self {
model_path: model_path.to_string(),
llama_cpp_path: llama_cpp_path.to_string(),
}
}
pub fn summarize_session(&self, logs: &str) -> Result> {
// Промпт специально для терминальных логов
// Qwen2.5-0.5B-Instruct отлично работает с таким форматом
let prompt = format!(
"<|im_start|>system\nТы — ассистент, который анализирует логи терминала разработчика. \
Суммаризируй, что делал пользователь, в 3-5 предложениях. \
Выдели: 1) Основную задачу 2) Ключевые команды 3) Ошибки если были 4) Результат.\n<|im_end|>\n\
<|im_start|>user\nВот логи терминальной сессии:\n\n{}\\n\nКраткая суммаризация:<|im_end|>\n\
<|im_start|>assistant\n",
logs
);
// Запускаем llama.cpp как отдельный процесс
// Можно использовать llama-cpp-rs биндинги, но процесс проще для изоляции
let mut cmd = Command::new(&self.llama_cpp_path)
.arg("-m")
.arg(&self.model_path)
.arg("-p")
.arg(&prompt)
.arg("-n")
.arg("256") // Максимальная длина ответа
.arg("-c")
.arg("4096") // Контекст
.arg("--temp")
.arg("0.1") // Низкая температура для детерминированной суммаризации
.arg("--top-p")
.arg("0.9")
.arg("--repeat-penalty")
.arg("1.1")
.stdin(Stdio::piped())
.stdout(Stdio::piped())
.stderr(Stdio::null()) // Подавляем stderr
.spawn()?;
// Записываем промпт в stdin
if let Some(mut stdin) = cmd.stdin.take() {
stdin.write_all(prompt.as_bytes())?;
}
let output = cmd.wait_with_output()?;
let summary = String::from_utf8_lossy(&output.stdout)
.trim()
.to_string();
// Очищаем ответ от артефактов промпта
let summary = summary
.replace("<|im_start|>assistant", "")
.replace("<|im_end|>", "")
.trim()
.to_string();
Ok(summary)
}
} 5 Интеграция с AI-ассистентами
Теперь самое интересное — как дать этот контекст ассистентам вроде Claude Code, Cursor, или любому другому, который поддерживает контекст из файлов.
Создаём простой HTTP сервер (или расширение для IDE), который по запросу возвращает последние суммаризации:
// src/api.rs
use axum::{Router, extract::State, Json};
use rusqlite::params;
use serde_json::{json, Value};
use std::sync::Arc;
struct AppState {
db: Arc>,
}
async fn get_recent_summaries(
State(state): State>,
) -> Json {
let db = state.db.lock().unwrap();
let mut stmt = db.prepare(
"SELECT session_id, start_time, summary, commands_count, error_count \
FROM terminal_sessions \
WHERE summary IS NOT NULL \
ORDER BY start_time DESC LIMIT 5"
)?;
let sessions: Vec = stmt
.query_map([], |row| {
Ok(json!({
"session_id": row.get::<_, String>(0)?,
"start_time": row.get::<_, String>(1)?,
"summary": row.get::<_, String>(2)?,
"commands_count": row.get::<_, i64>(3)?,
"error_count": row.get::<_, i64>(4)?,
}))
})?
.collect::>()?;
Json(json!({ "sessions": sessions }))
}
#[tokio::main]
async fn main() {
let db = Connection::open("terminal_logs.db").unwrap();
let state = Arc::new(AppState {
db: Arc::new(Mutex::new(db))
});
let app = Router::new()
.route("/api/summaries", get(get_recent_summaries))
.with_state(state);
axum::Server::bind(&"0.0.0.0:3030".parse().unwrap())
.serve(app.into_make_service())
.await
.unwrap();
} Теперь в вашем AI-ассистенте можно:
- Добавить плагин, который перед ответом запрашивает
GET http://localhost:3030/api/summaries - Вставлять последние суммаризации в системный промпт
- Или просто копировать их вручную перед сложным вопросом
Результат: ассистент понимает, что вы последние 20 минут дебажили Dockerfile, столкнулись с ошибкой сборки, попробовали три разных решения, и сейчас как раз смотрите на логи контейнера.
Нюансы, которые сломают вашу реализацию (если не учесть)
Собрать работающий прототип — просто. Сделать систему, которая работает стабильно месяц — сложно. Вот что я узнал на своих ошибках:
| Проблема | Решение | Почему важно |
|---|---|---|
| Модель "забывает" начало длинного контекста | Использовать sliding window attention в llama.cpp (флаг --sliding-window 4096) |
Qwen2.5-0.5B имеет окно 32к, но без sliding window качество суммаризации длинных сессий падает |
| Суммаризация запускается на каждую команду — нагрузка на CPU | Дебаунс: запускать суммаризацию только после 10 команд или 5 минут неактивности | llama.cpp даже с 0.5B грузит CPU на 30-40%. Частые запуски съедят батарею ноутбука |
| Пароли и ключи в логах | Фильтровать строки с паттернами типа password=, SECRET_KEY, token= до записи в БД |
Иначе модель увидит ваши секреты. И они сохранятся в базе на диске |
| Многопользовательская среда | Разные файлы БД на пользователя + шифрование при необходимости | В корпоративной среде логи разных разработчиков не должны смешиваться |
А что насчёт производительности?
Цифры на 29.01.2026 для MacBook M2 Pro 16 ГБ:
- Загрузка модели: 1.2 секунды (с диска NVMe)
- Суммаризация 100 строк логов: 0.8-1.5 секунды
- Память: ~450 МБ RAM (модель + контекст)
- Потребление в фоне: 0% CPU когда не активен
Можно ли быстрее? Да. Можно закешировать загруженную модель в памяти между сессиями. Можно использовать техники из статьи про запуск Llama 3.1 на 6 ГБ VRAM — offload части слоёв на GPU. Но для фоновой суммаризации раз в 5-10 минут текущей скорости более чем достаточно.
Альтернатива: зачем это нужно, если есть встроенные истории?
Справедливый вопрос. Ведь bash имеет history, zsh имеет расширенную историю, есть инструменты вроде atuin для поиска по истории.
Но история команд — это что. AI-суммаризация — это зачем и что получилось.
Пример:
История bash:
cd ~/projects/api
docker-compose up
curl localhost:3000/health
docker logs api_container
vim Dockerfile
AI-суммаризация:
"Пользователь запустил Docker Compose для проекта API, но сервис не ответил на health check. Проверил логи контейнера, обнаружил ошибку подключения к БД. Открыл Dockerfile для исправления конфигурации подключения."
Чувствуете разницу? История — это сырые данные. Суммаризация — это смысл.
Что дальше? Куда развивать систему
Базовая система работает. Но это только начало. Вот что можно добавить:
- Классификация сессий: Модель может автоматически тегировать сессии — "дебаг", "настройка", "исследование", "деплой".
- Выявление паттернов: "Вы часто запускаете
docker-compose downпосле ошибок сборки. Возможно, стоит добавить--buildв workflow?" - Интеграция с таск-трекерами: Автоматическое создание тасков в Jira/GitHub Issues на основе обнаруженных багов.
- Преемственность между сессиями: "В прошлой сессии вы работали над багом аутентификации. В этой — продолжаете ту же тему?"
Самое интересное — когда таких систем несколько в команде. Появляется коллективный интеллект: "Алексей вчера решил похожую проблему с тем же error code. Вот как он это сделал..."
Предупреждение: прежде чем внедрять такое в команде, обсудите политику приватности. Некоторые разработчики могут быть против записи их терминальной активности, даже анонимизированной. Прозрачность и опт-ин обязательны.
Главный урок, который я вынес из этого проекта: самые полезные AI-инструменты — не те, которые заменяют разработчика, а те, которые делают его сотрудничество с AI-ассистентами более осмысленным. Это не автопилот. Это — общий контекст.
Как сказал один мой коллега после недели использования: "Теперь Claude понимает меня с полуслова. Как будто он сидел рядом все это время".
А разве не этого мы хотим от AI-ассистентов?
