Вайб-кодинг — это прекрасно. Ты описываешь идею, ИИ пишет код, ты чувствуешь себя демиургом. Но эйфория заканчивается примерно на четвёртом-пятом промпте.
Именно тогда начинается настоящее:
- ИИ «забывает», что вы договорились три промпта назад, и переписывает всё с нуля — по-своему.
- Функционал, который вы час настраивали, исчезает. ИИ решил, что он «лишний».
- Проект отлично работает локально. На сервере — тишина. Потому что доступов нет.
- Доступы дали — и теперь ИИ бодро экспериментирует прямо в продакшене. Поздравляем.
Всё это не баги, это особенности работы с LLM на проектах чуть крупнее «сделай мне лендинг». И лечится это не молитвами, а одним простым приёмом: файл todo.md с правилами прямо в корне проекта. ИИ его видит, учитывает — и внезапно становится гораздо более предсказуемым соседом по кодовой базе.
Вот правила, которые реально работают:
🛡️ Правила безопасной разработки (todo.md)
1. Минимальные изменения
В существующий код вносим только необходимый минимум. Новый функционал — отдельными функциями/модулями поверх, не трогая то, что уже работает.
2. Большие изменения — через форк
Если переделка неизбежна, делаем копию модуля/файла и подключаем её. Оригинал остаётся нетронутым.
3. Декомпозиция задач
Любую задачу делим на микрозадачи. ИИ с маленькими чёткими шагами справляется на порядок лучше, чем с размытым «сделай всё и сразу».
4. Todo-список с приоритетами
Микрозадачи расставляем в оптимальном порядке: заголовок + одна строка описания. Без романов. Выполняем строго по порядку.
5. Краткость — сестра таланта
Общаемся на русском, без длинных рассуждений. Отчёт о работе — в чат, коротко.
6. Этот файл — неприкосновенен
Правила в todo.md не редактируются в процессе работы. Никогда. Ни под каким предлогом.
7. Локальная разработка + инструкция по деплою
Разрабатываем и тестируем локально. К каждой задаче — краткая инструкция по проверке на VDS.
8. exec() — табу
Функция exec() не применяется. Совсем. Вообще. Даже если очень хочется.
9. Порядок в документации
Все .md-файлы (кроме README.md) — в папку /docs/. README.md живёт в корне проекта. Беспорядок в документации — первый шаг к беспорядку в голове.
10. Устаревшие файлы — в архив
Неиспользуемые исходники не удаляем, а переносим в /wf/_bup. Потом скажете спасибо.
11. Версионирование — кратко
История изменений ведётся одной строкой на версию в README.md (или в /docs/CHANGELOG.md, если версий накопилось много).
12. Деплой — только точечный
Изменения вносим локально, затем точечно закачиваем на сервер через scp/rsync/sftp. Редактировать файлы прямо на сервере (vim, nano и т.п.) — запрещено. git push на сервер не используем, деплой — не через git.
13. Git — отдельный процесс
По команде «пушкоммит» — git commit + git push в удалённый репозиторий. Это отдельная история от деплоя на VDS (см. п. 12).
14. Ошибки на VDS — сначала логи
Что-то сломалось на сервере? Сначала подключаемся, скачиваем логи, анализируем. Не гадаем, не правим вслепую.
15. ТЗ — только для чтения
Файлы с исходными заданиями не редактируются. Никогда.
16. Архитектура без мусора
Папки со скриптами, логами и архивами не должны расти бесконечно. Предусматриваем ротацию логов, ротацию архивов, автоочистку устаревших данных.
Скопируйте эти правила в todo.md в корне вашего проекта — и ИИ-ассистент превращается из непредсказуемого джуна в более-менее управляемого разработчика. Не идеального. Но хотя бы не сносящего продакшн в пятницу вечером.
Копи-френдли правила и принципы разработки для LLM
Правила и принципы разработки
1. Минимальные изменения в код проекта. В существующий функционал и код проекта вносим только необходимые минимальные изменения. Новый функционал дописываем сверху — отдельными функциями/модулями.
2. При необходимости больших изменений делаем форк-копию и подключаем её.
3. Раздели задачу на микрозадачи.
4. Расставь микрозадачи в оптимальном порядке приоритета в виде краткого todo-списка (заголовок + 1 строка на пункт, без развёрнутых обоснований). Выполняй по порядку до результата.
5. Пиши на русском, кратко, без длинных рассуждений.
6. В этот файл с правилами изменения не вносить. Отчёт о работе — краткий, в чат.
7. Разрабатываем и тестируем локально. К каждой задаче — краткая инструкция по проверке на VDS.
8. Функцию exec() не применять.
9. Документация и прочие .md-файлы (кроме README.md) — в папку /docs/. README.md остаётся в корне проекта.
10. Устаревшие неиспользуемые исходные файлы переносим в /wf/_bup.
11. Версия и история изменений ведётся кратко, одной строкой на изменение, в README.md (или в /docs/CHANGELOG.md, если версий много).
12. Деплой на VDS: изменения вносим только в локальную копию, затем точечно закачиваем (scp/rsync/sftp) готовые файлы на сервер. Редактировать файлы прямо на сервере (через vim/nano и т.п.) запрещено. git push на сервер не используем — деплой не через git.
13. Git: по команде «пушкоммит» — git commit + git push в удалённый репозиторий (это отдельный процесс от деплоя на VDS, см. п.12).
14. При ошибках на VDS — сначала подключиться и скачать логи для анализа.
15. Файлы с исходными заданиями/ТЗ не редактировать.
16. Архитектура должна исключать бесконечный рост папок со скриптами: ротация логов, ротация архивов данных, автоочистка устаревших данных.