Локальный цех: как собрать рабочий стол на ноутбуке, когда интернет под NDA или его просто нет

Слабый интернет или строгий NDA (соглашение о неразглашении) часто ставят разработку на паузу. Заказчик ждет правок, бот падает в проде, а вы не можете отправить ни строчки кода во внешний API нейросети. Выход — собрать верстак из инструментов, которые живут только на вашем жестком диске. Мы разберем одну сквозную ситуацию: у вас есть легковесный сайт на FastAPI + HTMX и Python-бот приема заявок, который нужно чинить и развивать прямо сейчас, опираясь исключительно на ресурсы обычного ноутбука.

Шаг 1. Изоляция среды и редактора: почему ноутбук вообще потянет эту нагрузку

Когда проект живет вне облака, главным узким местом становится диск и оперативная память. Чтобы среда не рассыпалась от случайного обновления системы, берем портативную версию VS Code. Это та же самая программа, но она запускается из одной папки и ничего не пишет глубоко в системные настройки Windows, Linux или macOS. Рядом создаем виртуальное окружение через venv — изолированную коробку для библиотек конкретного проекта, чтобы версии пакетов для бота не конфликтовали с версиями для сайта. Для самого сайта выбираем связку FastAPI (микрофреймворк для создания веб-сервисов на Python, работающий в десятки раз быстрее привычного многим Django за счет асинхронности) и HTMX (библиотека, которая позволяет писать динамические интерфейсы простым HTML без написания сложного JavaScript). Для бота фиксируем python-telegram-bot v20+, так как именно в этой ветке изменилась работа с контекстом обновлений, и docker-compose — инструмент, описывающий все службы вашего приложения (базу данных, кеш, сам скрипт) в одном текстовом файле, чтобы поднять их одной командой.

Что сделать завтра: скачать ZIP-портал VS Code с официального сайта, распаковать в D:\dev\code-server, создать папку проекта с файлами requirements.txt (список нужных библиотек) и docker-compose.yml, выполнить команду python -m venv .venv и активировать ее.

Шаг 2. Автономный мозг ассистента: Ollama и Continue.dev вместо облачных чатов

Облачные помощники вроде GitHub Copilot нам недоступны по условиям задачи. Вместо них ставим два компонента. Первый — Ollama. Это маленькая бесплатная утилита, которая скачивает готовые AI-модели весом 7–8 миллиардов параметров (их называют моделями 7–8B) и превращает ваш компьютер в частный сервер искусственного интеллекта. Нам подходят qwen3-coder:8b (модель, отлично понимающая структуру кода) либо llama3.1:8b-instruct-q4 (версия модели LLaMA со сжатием качества до четвертого уровня, что экономит видеопамять). Второй компонент — плагин Continue.dev для VS Code. Он встраивает окошко чата прямо в редактор. Вы пишете код, выделяете кусок функции, нажимаете хоткей, и модель дописывает логику или объясняет ошибку. Важно понимать механику приватности: при такой связке ваши исходники никогда не покидают жесткий диск. Модель читает ровно то, что вы ей подсунули в текущем окне, внешних логов нет, а скорость ответа зависит только от скорости вашего SSD (твердотельного накопителя) и объема RAM (оперативной памяти).

Что сделать завтра: установить Ollama, вытянуть модель ollama pull qwen3-coder:8b, зайти в маркетплейс VS Code, найти Continue, нажать Connect Local и выбрать выпавшую модель в настройках.

Шаг 3. Память проекта: как заставить автономную модель помнить вашу архитектуру

Автономная модель глупеет между перезапусками редактора. Она не знает, какие поля приходят в webhook (вебхук — автоматическое уведомление от стороннего сервиса вашему серверу), какая структура у вашей базы данных и где лежат секреты. Эту память мы собираем вручную. В корне репозитория создаем файл .cursorrules или AGENTS.md — это инструкция для ИИ простыми словами: «Используй async/await, логируй ошибки в Sentry, токены бери строго из переменных окружения». Отдельно заводим папку docs/context. Туда складываем срезы реальности: YAML-файл api.yml с примерами тела запросов к платежному шлюзу (только методы оплаты и уведомлений, никаких лишних эндпоинтов), схему БД schema.sql и правила коммитов. Когда вам нужно отрефакторить хэндлер загрузки файлов, вы копируете нужный кусок схемы и пример JSON в чат Continue. Модель видит полную картину и предлагает точечный фикс, а не переписывает весь сервис целиком.

Что сделать завтра: создать docs/context/api.yml, выписать туда три самых частых запроса к сайту и два типа входящих вебхуков для бота, написать первые пять правил в .cursorrules про обработку ошибок.

Шаг 4. Мини-кейс спасения: чиним падение бота при загрузке файлов больше 5 МБ

Возвращаемся к нашей ситуации. Бот приема заявок стабильно падал, стоило пользователю прикрепить PDF тяжелее пяти мегабайт. Оперативка улетала в потолок, соединение рвалось. Локально прогоняем сценарий под нагрузкой. Запускаем docker compose up, открываем Postman (или обычный curl — консольную команду для отправки запросов) и шлем тяжелый файл. Смотрим htop (утилита мониторинга ресурсов): потребление RAM выросло с базовых 92 МБ до 380 МБ перед самым крахом.

Почему так происходит? По умолчанию библиотека считывала весь поток файла в один байтовый объект в памяти. Открываем хэндлер загрузки в VS Code, вызываем чат Continue, подсовываем ему фрагмент кода и наш свежий docs/context/api.yml с лимитами. Просим: «Найди место буферизации всего файла, предложи стриминговую запись в /tmp с очисткой по таймеру». Ассистент выдает точный патч: замена одного метода чтения на итеративную запись кусками по 64 КБ напрямую на диск. Меняем две строки, добавляем фоновый процесс, который раз в минуту удаляет временные файлы старше пяти минут. Потребление RAM фиксируется на отметке 92 МБ даже на двадцатимегабайтных архивах, обрывы исчезают. На ревью тот же ассистент предложил тесты на граничные размеры (0 байт, 5 МБ ровно, 5.1 МБ, 100 МБ) и подсказал фиксы в обработке исключений, чтобы бот не сыпал трассировками (подробными отчетами об ошибке) в ответ клиенту.

Что сделать завтра: воспроизвести падение на своем стенде, попросить Continue.dev переписать проблемный участок через aiofiles.stream (асинхронное чтение файлов кусками), добавить cleanup-задачу в cron внутри контейнера.

Чего избегать, чтобы верстак не превратился в свалку

Первое правило — никогда не смешивать реальные секреты и примеры в одном файле контекста. Токен доступа к банку кладем в отдельный зашифрованный vault (хранилище секретов) или хотя бы в .env.example с заглушками, а в docs/context/api.yml оставляем только структуру полей. Второе — пресекать желание отдать модели кнопку «перепиши весь микросервис». Делайте шагами: сегодня только модуль загрузки, завтра — только рассылка статусов. Длинные диалоги в одном чате дробите по задачам, иначе модель начнет галлюцинировать и путаться в функциях. Третье — держите ветки Git короткими. Одна задача — одна ветка feature/safe-upload, мерж (слияние) только после того, как автономные тесты прошли на вашем ноутбуке без единого обращения к сети.

Завтра ваша первая цель звучит предельно конкретно: установите Ollama и подтяните qwen3-coder:8b, подключите Continue к портативному VS Code, создайте docs/context/api.yml и перенесите туда только методы оплаты и вебхуков. Напишите первый промпт не как вопрос, а как техническое задание: цель, входные данные, ожидаемый выход и критерий готовности. Прогоните изменения через короткую ветку Git, измерьте потребление RAM вашим ботом до и после рефакторинга одним и тем же тяжелым файлом и зафиксируйте дельту цифрами в README.