user10429766

Хотите «систему на весь бизнес», а на деле заявки живут в личных чатах, счета бьют руками, а склад сверяют по пятницам. Я на разборах ИП и команд до 15 человек почти всегда вижу одно: нет карты as-is, зато уже куплен софт.

Ниже - как за вечер описать один процесс, выбрать слой (таблица / бот / CRM / код) и прогнать пилот 1-2 недели. Офисная рутина, не цех и не АСУТП. Не серебряная пуля: если процесс раз в квартал или каждое решение - переговоры, автоматизация его не спасёт.

Шаг 1. Снять as-is на одну страницу

Не «как должно быть». Как работает сейчас. Минимум блоков:

1. Триггер - что запускает цепочку: сообщение клиента, оплата, дата, конец смены.

Салон, упрощённо, как я вижу на разборах:

Триггер: клиент пишет в Telegram «хочу на стрижку в субботу»

Студия или SMM из трёх человек обычно ломается на передачах:

Триггер: заявка с сайта или DM «нужен логотип»

На разборе прошу скрин переписки, фото блокнота или экспорт таблицы за неделю - не презентацию. Если в схеме больше трёх «ответственных без имени», сначала владелец шага, потом любой бот.

Вопросы, которые реально двигают карту:

- Где одно и то же вбивают дважды?

Карта может жить в Doc, Miro или на бумаге. Важно, чтобы двое-пятеро узнали себя и спорили о шагах, а не о бренде CRM.

Три фильтра:

Критерий — Вопрос — Сигнал «берём»

Плюс с разборов: шаги описываются как «если - то», без творческой оценки на каждом шаге. И на пилоте лучше напоминание и запись, чем автосписание денег без человека.

Частый первый кандидат - приём заявок: канал известен, поля согласовываются за час, эффект виден за две недели. Второй - однотипные счета или акты. Третий - напоминания по статусам, если CRM уже есть, но ею не живут.

Не первый пилот: нестандартные договоры с юристом на каждую сделку; креатив без чеклиста; склад без учёта остатков; ИИ в переписке, пока нет стабильной записи в карточку.

Ответы не «правильные». Они показывают, какого слоя хватит на пилоте.

1. Повторяется не реже раза в неделю? Нет - не автоматизируем сейчас, фиксируем в регламенте. Да - дальше.

Сводка:

Ситуация — Инструмент на пилоте — Комментарий

Поля лучше зафиксировать до настройки. Минимальный каркас заявки:

{

Если остаётесь в Google Sheets и хотите SLA «ответ за два часа», колонка «Просрочено?»:

=IF(AND(B2<>""; C2=""); IF(NOW()-A2>TIME(2;0;0); "ДА"; "нет"); "")

A2 - время создания, B2 - ответственный, C2 - время первого ответа. Условное форматирование по «ДА» - уже половина пилота без кода.

Когда бот шлёт в n8n или Make, типичный webhook:

{

Не меняю стек ради модного бота, если команда пять лет в Bitrix. Сначала контур и поля. Таблица, которой все пользуются каждый день, на первой неделе часто лучше «переезда» в CRM. Ошибка из разборов и кейсов на vc.ru: ERP «на вырост», пока as-is не нарисован. Страница карты дешевле лицензии.

Шаг 4. Куда пилот не пускать

Автоматизация - не «убрать людей». Пока нет дисциплины записи, я не веду сюда:

- Всё сразу: пять процессов, три интеграции, новая CRM и бот в один релиз.

Антипаттерн — Чем грозит — Что вместо

Типичные грабли

На салонах, студиях и агентствах одни и те же симптомы.

Симптом — Что проверить

Кейс салона: администратор отвечала из личного Telegram, запись в блокноте. Бот поставили «для статуса», напоминания остались руками - no-show не упал. Фикс: бот пишет в ту же Google-таблицу, откуда печатают расписание; напоминание - триггер из таблицы за 24 часа. Один источник правды.

Кейс агентства на пятерых: лиды в общий чат, CRM купили, карточки не заводили - «долго». Фикс: бот с четырьмя полями — строка в таблице — уведомление ответственному по очереди (round-robin формулой или вручную на пилоте). CRM после двух недель без потерь в журнале.

Если за пилот больше трёх строк с одним симптомом - меняем сценарий, не добавляем второй сервис.

Без цифр это шоу, которое не включают в работу. Пример для заявок, подставьте свои числа:

- 15-25 срабатываний триггера за две недели.

Если вход - форма на сайте и DM в Instagram, отдельно считайте заявки в обход учёта. Цель к концу второй недели - ноль.

Перед стартом:

1. Карта согласована с тем, кто делает процесс каждый день.

Стресс-тест: пятница вечер. Должны сработать запись, уведомление или отложенное правило и понятный автоответ, если процесс клиентский.

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

Когда имеет смысл сесть с кем-то ещё, а не покупать каталог: несколько процессов и спорный приоритет; карта у владельца и у исполнителей разная; CRM или бот уже пробовали, учёт всё равно ручной; нужен один документ - as-is, критерий, рекомендация слоя. Brief себе самому перед этим: название процесса, частота, кто участвует, где последний раз сломалось. Без этого любой созвон превращается в обзор SaaS.

Cursor, rules и MCP - отдельный слой для разработчика. Для салона, агентства или небольшого магазина первый шаг остаётся бумажной картой и одним пилотом. Скрипт и репозиторий - когда процесс уже описан.

Чеклист на завтра

• Выбрать один процесс с повтором не реже раза в неделю и понятным сбоем

У кого какой обход сработал: таблица, бот или сразу CRM? Напишите в комменты, какой процесс брали первым и где сломалось.

4. Формат — diff в одном файле / план из N пунктов / таблица «было — стало».

5. Проверка — npm test -- …, зелёный кейс, или ручной сценарий из 2–3 шагов.

Постоянные запреты лучше держать в .cursor/rules, в чате оставлять цель и проверку. К коду всегда цепляйте минимум один @ — иначе агент ищет похожие имена по всему дереву.

Контекст: ветка fix/login, файл @src/auth/login.ts, падает тест «invalid password» (лог ниже).

Цель: исправить причину падения без смены поведения для валидного пароля.

Ограничения: не менять @src/auth/types.ts и не добавлять зависимости.

Формат: правки только в @src/auth/login.ts, в конце — 2–3 предложения «что было не так».

Проверка: npm test -- login.test.ts — все кейсы зелёные.

Антипример: «Почини логин, что-то сломалось» — можно получить переписанную авторизацию и сломанную регистрацию.

Проверь себя: файл + имя теста/ошибка; что считать регрессией; команда одной строкой; один чат = одна гипотеза. Не помогло — новый чат: «попытка 2: …» + факты из diff и stdout, без эмоций.

Контекст: @src/components/OrderForm.tsx — дублируется валидация полей (строки 40–90).

Цель: вынести валидацию в хук useOrderValidation без изменения UI и пропсов формы.

Ограничения: не трогать стили, не переименовывать экспорты, не менять тесты кроме импортов при необходимости.

Формат: сначала короткий план из 3 шагов, после моего «ок» — diff.

Проверка: npm run lint && npm test -- OrderForm — без новых warning.

Антипример: «Отрефактори, сделай красиво» — агент сменит библиотеку форм или разнесёт файл на пять модулей.

Граница — один модуль или явный список файлов. Если тестов нет — честно: «тестов нет, проверяю вручную: сценарий А, Б». Для React отдельно: «поведение для пользователя не меняется» + клики/поля. Для Python: «сигнатуры публичных функций те же».

Контекст: @src/utils/price.ts, функция formatPrice; покрытия нет.

Цель: добавить unit-тесты на граничные значения: 0, отрицательное, большое число, null.

Ограничения: Vitest, файл тестов @src/utils/price.test.ts, не менять реализацию formatPrice.

Формат: только тесты + краткая таблица «кейс — ожидание» в комментарии к describe.

Проверка: npx vitest run price.test.ts — 100% pass.

Антипример: «Напиши тесты на utils» — появится Jest, файлы в tests/, и прод-код «чтобы тесты прошли».

Назовите фреймворк и путь. Явно: «не менять прод-код». Перечислите граничные кейсы, не «покрой всё». Перед генерацией откройте @ на сам модуль — иначе агент выдумает поля.

Контекст: @Legacy/importPipeline.js, меняю только шаг нормализации (функция normalizeRow).

Цель: объяснить поток данных от входа CSV до записи в БД — только цепочка вызовов.

Ограничения: не предлагать рефакторинг и не писать код.

Формат: нумерованный список шагов (≤12 пунктов) + один абзац «где ломается при битой строке».

Проверка: я могу вслух пройти по списку и указать файл каждого шага; если шаг без файла — ответ неполный.

Антипример: «Объясни этот файл» — пересказ строк и совет «перепиши на TypeScript».

Здесь уместен Ask: только анализ. Точка входа обязательна. Для больших репо: «игнорируй vendor/» / «смотри только apps/api/». Если ответ расползается — ужесточите лимит: «не больше 12 пунктов, на каждый — один файл».

Контекст: Next.js app, уже есть @app/settings/page.tsx; нужна смена языка интерфейса.

Цель: план внедрения i18n без реализации — файлы, которые затронем, риски.

Ограничения: не добавлять код в этом чате; не выбирать библиотеку без сравнения 2 вариантов.

Формат: таблица «шаг | файл/папка | риск | как проверить» + открытые вопросы (≤5).

Проверка: по плану можно оценить трудозатраты; у каждого шага есть способ проверки.

Антипример: «Добавь мультиязычность» — пакет уже стоит, десять страниц переписаны, сборка красная.

Запретите реализацию в этом сообщении (Plan или дисциплина «только план»). Реализацию шага 1 — отдельным чатом.

Контекст: git diff в ветке feature/notifications (только @src/notifications/*).

Цель: найти риски перед merge: безопасность, регрессии, нарушение rules.

Ограничения: не править код; не предлагать «переписать всё».

Формат: список findings с severity high/medium/low; на каждый — файл и строка.

Проверка: каждый high привязан к конкретному фрагменту diff; если high нет — явно написать «high не найдено».

Антипример: «Посмотри, норм ли?» — «в целом хорошо, можно мержить» без строк.

Ограничьте область diff. CI гоняете вы сами — агент не заменяет pipeline. Запреты (API-ключи в репо, console.log в prod) удобно держать в rules, чтобы ревью сверялось с ними.

Контекст: @src/api/webhooks/stripe.ts, экспорт handleStripeEvent.

Цель: JSDoc + пример вызова для внутренней wiki (русский язык).

Ограничения: не менять логику; не документировать приватные хелперы; ≤15 строк на блок.

Формат: JSDoc над функцией + markdown-блок «Пример» с телом запроса и ожидаемым статусом.

Проверка: по доке новый разработчик может вызвать webhook в Postman без чтения всего файла.

Антипример: «Задокументируй API» — generic параметры без тел и кодов ошибок.

Укажите конкретный экспорт, язык, лимит объёма и пример с реальными полями из типов, не foo/bar.

### Типичные грабли

Симптом — Что проверить

Правки не там — `@файл` + «только этот модуль»

«Сделал», но не работает — Команда lint/test или ручной сценарий в промпте

Разросся diff — Несколько целей в одном сообщении → новый чат, одна цель

Повторяет старую ошибку — Нет «что уже пробовали» — попытка 1, результат

Смешали Ask и Agent — «Почему падает?» ≠ «исправь и прогони тест» — разные чаты

Нет checkpoint — Перед рискованным промптом — коммит или stash

Промпт-роман — Пять экранов хуже пяти строк формулы; вытесняет rules

Агент снова лезет в package.json — Допишите rule, а не третий раз орёте в чат

Это не серебряная пуля: rules, открытая папка проекта, выбранная модель и чистый git — фундамент. Промпт — надстройка на одну итерацию. Нормальный цикл: промпт — проверка — уточнение. После трёх итераций тупик — упростите цель или разбейте на два чата.

Чеклист на завтра

• Взять последнюю задачу, где агент «навредил», переписать исходный промпт по одному из семи шаблонов

• В каждом промпте на код — минимум один @ и блок «Проверка»

• Постоянные запреты вынести в .cursor/rules, в чате оставить цель + проверку

• Перед рискованным Agent — git commit или stash

• Ask и Agent не мешать в одном чате

• Если восьмая повторяющаяся задача (миграция, релиз) — завести восьмой шаблон по той же формуле

У кого какой обход/шаг сработал на реальном репо? Напишите в комменты — интересен именно ваш стек и команда проверки, не абстрактный «идеальный промпт».

У меня на разборах почти каждую неделю одна и та же история: человек открыл чат в браузере, попросил «сделай сайт», вставил куски в проект — через день всё разъехалось. Потом вердикт: «вайбкодинг не работает».

Работает другое: правка реального репозитория в редакторе с ИИ. Вы держите цель и критерий «готово», модель предлагает патч, вы читаете diff и принимаете или откатываете. Не замена программирования — ускорение рутины при вашей проверке.

Ниже — определение без маркетинга, когда Cursor уместен, типичные провалы и первый безопасный сценарий на один вечер. Серебряной пули нет: без чтения diff это генерация текста, не разработка.

Шаг 1. Чем вайбкодинг не равен «промптам в ChatGPT»

Вайбкодинг (vibe coding) — цикл: формулируете задачу — ИИ предлагает изменения в файлах — читаете diff — принимаете, правите запрос или откатываете. «Вайб» здесь про поток итераций, не про «пиши код настроение».

Три условия, без которых термин превращается в рекламу:

1. Редактор с контекстом — открыта папка проекта (Open Folder), не один файл в блокноте.

2. Режим с действием — в Cursor это Agent (правит файлы), а не только болтовня.

3. Ваша проверка — запуск, тест, взгляд в браузер, git diff. Без этого — генерация текста.

Типичная путаница: скопировали ответ из браузерного чата — в проекте нет связи с файлами — «не запускается». Лечится не новым промптом, а открытием папки и работой внутри репозитория.

Вайбкодинг не снимает:

- Архитектуру и границы — кто с чем связан, где данные. Модель предложит «логичную» структуру; ваши бизнес-ограничения знает только текст, который вы дали.

- Ключи и доступы — ключи API, пароли, персональные данные не должны уезжать в промпты и логи. .env и ротация токенов — ваша зона.

- Ответственность за прод — деплой, бэкап, откат. Кнопку «в прод» жмёт человек.

- Согласование с заказчиком — сроки и объём код не ускоряет.

Честный минимум грамотности: файл, функция, ошибка в консоли, git commit. Без этого вы зависите от каждого ответа модели. Нормальный старт для новичка: «объясни эту ошибку и предложи один фикс».

Ожидание — Реальность

«ИИ сам всё поймёт» — Нужен контекст: файлы, rules, примеры

«Git не нужен» — Git или копия — страховка от плохого diff

«Сразу большой проект» — Сначала модуль или одна фича

«Без проверки» — Хотя бы ручной чеклист за 5 минут

Классика: алгоритм — набор — запуск — фикс.

Вайбкодинг: намерение — патч от модели — оценка патча — уточнение. Ручной набор не исчезает: правите строки, когда diff «почти верный», или когда быстрее самому.

Что меняется по навыкам:

- фокус с синтаксиса на спецификацию поведения («при пустом email — подсказка, форму не слать»);

- больше мелких итераций за час;

- чтение diff становится таким же навыком, как писать цикл;

- промпт = тикет: плохой тикет — не то.

Пример с формой. Классика: находите handler, пишете if (!email), проверяете в браузере. Вайбкодинг: в Ask — «где сейчас валидация», в Agent — «добавь проверку email и сообщение под полем, не меняй стили», смотрите diff, поднимаете dev-сервер.

Риск по умолчанию: модель любит переписать лишнее («заодно улучшил»). В промпте режьте явно: «только файл X», «не трогай CSS», «без новых зависимостей». Помогают Rules / короткий AGENTS.md в корне.

Совпадают несколько условий:

1. Задача локальна — один репозиторий, лендинг, скрипт, плагин. Не «десять сервисов с нуля за вечер».

2. Есть или будет папка на диске (лучше с git).

3. Вы можете проверить результат: страница, npm run dev, traceback.

4. Итерации короткие — фича на 20–60 минут, не «перепиши всё приложение».

5. Есть эталон — «как на странице Y», скрин, кусок кода, дока.

Слабые сценарии для старта: прод без staging/бэкапа; legacy без тестов и без человека, который помнит «почему так»; «сделай как у конкурента» без ТЗ и без доступа к коду; персональные данные без политики обработки.

Чеклист «готов ли я вайбкодить эту задачу»:

• Результат в одном предложении

• Знаю файл или модуль

• Проверка за 5 минут

• Есть откат (git или копия)

• Понимаю, что не должно измениться

Пять галочек — хороший кандидат. Две — сначала сузьте задачу. Agent включайте, когда план ясен; если не знаете, где живёт логика — сначала Ask и поиск по файлам.

Ускоряются и хорошие, и плохие правки.

- Раздувание diff — переименования, формат соседних файлов, «улучшения». Через неделю — конфликт или регрессия.

- Несуществующие API — уверенный вызов функции, которой нет в вашей версии package.json.

- Ключи в коде — токен из примера уехал в репозиторий. В diff ищите api_key, password, token.

- Отказ от git — каждый эксперимент лотерея. Минимум: коммит «до Agent», коммит «после проверки».

- Оракул-промпт — «сделай CRM» одним махом. Режьте: модель данных — одна форма — список — фильтр.

Риск — Как снижать

Большой diff — Лимит файлов в промпте, Rules

Галлюцинации API — Дока + версия в package.json

Утечка ключей/токенов — `.env`, ручной diff, pre-commit

Слепое принятие — Понимать каждую принятую правку

Выгорание — Малые победы, не «до 3 ночи»

Полезно вести лог на две недели: что просили — что изменилось — что проверили. Паттерн ошибок почти всегда один: слишком большой запрос и нет критерия готовности.

Не начинайте с «нового SaaS». Провал должен быть дешёвым.

Задача: в существующем статическом HTML или React-странице добавить блок «Контакты» (email + ссылка), стили в том же файле/модуле, без новых библиотек.

Почему безопасно: 1–2 файла, видно в браузере, легко откатить.

Шаги:

1. Копия папки или git checkout -b vibe-first.

2. Open Folder в Cursor, глянуть README / package.json.

3. Ask: «Где рендерится главная? Перечисли файлы, код не меняй.»

4. Agent: «В файле … добавь секцию Contact с … Другие секции не трогай.»

5. Dev-сервер, проверка в браузере.

6. git diff, коммит с понятным сообщением.

Альтернатива не-фронту: Python-скрипт — читает CSV, считает сумму по столбцу. Один файл, проверка на тестовом CSV.

Ограничения вслух: не подключать оплату/авторизацию/внешние API; не трогать прод; не «оптимизировать весь проект».

После успеха — форма с валидацией; потом Rules под стиль кода. Лестница вверх, не прыжок в сложность.

Оценка не «сколько промптов», а «от запроса до работающей фичи».

1. Intent — одно предложение для пользователя: «Под email — ошибка, если формат неверный». Не «сделай красиво».

2. Scope — какие файлы трогаем и что не трогаем: «только ContactForm.tsx, стили из существующего module.css».

3. Patch — Agent правит, вы читаете diff. Diff больше трети файла без причины — стоп, уточнение.

4. Verify — happy path, пустое поле, кривой формат, соседняя кнопка не отвалилась.

На мелкой задаче цикл укладывается в 30–45 минут. Время обычно жрёт неясный intent и принятие лишнего diff.

Признак, что цикл удался: можете объяснить коллеге, что изменилось, без открытия чата; есть коммит или копия до/после; следующий шаг маленький, а не «теперь всё приложение».

Одна строка после сессии: «Сегодня я …, проверил …, следующий шаг …». Это отделяет вайбкодинг от бесконечного чата.

### Типичные грабли

Симптом — Что проверить

«ИИ написал, но не запускается» — Код из браузерного чата без связи с проектом → Open Folder

«Всё сломалось после одного запроса» — Приняли большой diff без чтения → git / Local History

«Не понимаю, что он менял» — Сразу Agent без карты → сначала Ask

«Хочу без кода вообще» — Нет критерия готовности → мини-задача с проверкой за 5 минут

Diff на полрепозитория — Промпт широкий → один файл + «не трогай …»

Падает на API библиотеки — Сверить с докой и версией в package.json

Ключ в репозитории — Diff на token/password; вынести в `.env`

• Описать одну задачу одним предложением + критерий «готово»

• Открыть папку проекта в Cursor (не один файл)

• Сделать ветку или копию «до экспериментов»

• Ask: где живёт нужная логика — без правок

• Agent: один файл, явные «не трогай», без новых зависимостей

• Прочитать diff глазами; при сомнении — откат

• Проверка за 5 минут (браузер / скрипт / traceback)

• Коммит «после проверки» + одна строка лога сессии

У кого какой первый сценарий реально зашёл — HTML-блок, форма или скрипт на CSV? Напишите в комменты, что сломалось на diff.

- кто должен ответить и что считается «заявка принята»;

- исключения: звонок вместо бота, повторный клиент, отказ после цены.

Пока правда «в трёх чатах» — не выбирайте CRM. Сначала поток, потом инструмент.

Шаг 2. Четыре звена минимума

Рабочий минимум — не ИИ, а цепочка:

1. Канал — один основной вход (бот или форма с webhook).

2. Квалификация — 3–5 полей: имя, услуга/тема, срок, комментарий, контакт.

3. Учёт — строка в Google Sheets / Airtable или карточка в amo / Bitrix.

4. Человек — пуш ответственному + эскалация, если статус «новая» висит.

Приём и продажа — разные задачи. На приёме не закрываем сделку: не теряем контакт и даём контекст. Цены, спорные кейсы, жалобы — человеку.

Для ИП часто хватает: Telegram — таблица — пуш в тот же Telegram. CRM — когда поток стабилен и поля уже согласованы.

На пилоте мне хватает детерминированной логики:

- кнопки «Запись / Вопрос / Жалоба» в первом сообщении;

- обязательные имя + телефон или @username;

- таймаут: молчит 10 минут — черновик карточки и напоминание оператору;

- явный выход «позвать человека» без всей ветки;

- короткое подтверждение клиенту: «приняли, ответим в течение…».

Автоматизация приёма (поля, запись, уведомление) и автоматизация ответа (шаблоны, потом черновик с моделью под ревью) — разные слои. Второй подключаю, когда первый две недели подряд не теряет сообщения.

Практический тест: возьмите 10–15 реальных сообщений за месяц. Если большинство типовые — кнопки и три поля. Если каждый второй текст уникален — короче путь к человеку, не длиннее форма.

Правило поля: зачем менеджеру это до первого контакта? Нет ответа — убираем или переносим после звонка.

Таблица ок, если:

- один ответственный или владелец сам ведёт заявку;

- до ~30–50 заявок в месяц и вы их реально смотрите;

- хватает статусов: новая / в работе / закрыта (иногда «отказ»);

- не нужны напоминания по этапам сделки.

CRM имеет смысл, если:

- двое и больше менеджеров, нужен владелец карточки;

- есть этапы: квалификация — КП — оплата — постпродаж;

- нужны «перезвонить завтра», «ждём документы»;

- руководитель смотрит воронку, а не только список новых строк.

Гибрид на пилот нормален: пишем в тестовый лист, привыкаем к полям и SLA, потом меняем только узел учёта на CRM. Перед интеграцией заполните черновик карточки на бумаге: обязательные поля, кто меняет статус, что такое закрытие.

1. «Умный агент» до стабильного приёма — бот вежливо отвечает, учёт остаётся ручным.

2. Пять каналов сразу — четыре типа сбоев одновременно. На пилоте один вход, остальные ведут сюда автоответом или ссылкой.

3. CRM «на вырост» при 15 заявках в месяц и одном менеджере.

4. Цены и обещания в автоответе без ревью.

5. Оплату до карточки заявки («деньги уже прошли, а в учёте пусто»).

6. Эскалацию на десять ролей — все перестают реагировать. Один ответственный, один резервный.

7. Жалобы и конфликты шаблоном — бот принимает текст и создаёт срочную карточку, отвечает человек.

Простой SLA на пилот:

- уведомление ответственному ≤ 2 минут после записи;

- первый ответ клиенту — в согласованный срок (например, 30 минут в рабочие часы);

- если «новая» висит 2 часа — второе уведомление или смена ответственного;

- ночью — автоответ с ожидаемым временем, заявка всё равно в учёте.

Текст пуша: откуда заявка, имя, услуга, ссылка на строку. Без ссылки менеджер снова ищет вручную.

Тест перед включением: отправьте тестовую заявку в пятницу в 22:00. Должны сработать автоответ клиенту, строка в учёте и уведомление (или отложенное правило, если так договорились). Нет хотя бы одного — не гоните трафик на бота.

### Типичные грабли

Симптом — Что проверить

«Клиент писал, мы не видели» — Нет единого канала-источника → один вход + редирект

Дубли в таблице — Ручной перенос из чатов → автозапись из канала

Ответ через сутки — Нет пуша ответственному → уведомление ≤ 2 мин

«Бот не понял» — Сразу NLP вместо правил → кнопки + поля + человек

Ответили в чате, в учёте пусто — Нет обязательного шага записи до/сразу после ответа

Разные статусы у всех — Нет списка полей → 3–5 полей на пилот

Пустые карточки в CRM — Интеграция до согласования полей → черновик карточки сначала

Чеклист на завтра

• Записать каналы и где сейчас «правда» о заявке

• Выбрать один основной вход на 1–2 недели

• Согласовать 3–5 полей и трёх статусов

• Назначить ответственного на каждый день + резервного

• Собрать цепочку: канал — поля — строка — пуш со ссылкой

• Прогнать тестовую заявку (в т.ч. вне рабочих часов)

• Записать критерий пилота до настройки: N заявок, 100% в учёте, SLA пуша, лимит ручных правок, ноль потерянных по журналу канала

• Не масштабировать на второй канал и ИИ, пока критерий не выполнен

Это не серебряная пуля и не «система на весь бизнес». Это дисциплина записи: пока её нет, любой бот только маскирует потери.

У кого какой обход сработал на пилоте — таблица, CRM или гибрид? Напишите в комменты, особенно если ломалось на исключениях (звонок вместо бота, оплата без заявки).

- кто должен ответить и что считается «заявка принята»;

- исключения: звонок вместо бота, повторный клиент, отказ после цены.

Пока правда «в трёх чатах» — не выбирайте CRM. Сначала поток, потом инструмент.

Рабочий минимум — не ИИ, а цепочка:

1. Канал — один основной вход (бот или форма с webhook).

2. Квалификация — 3–5 полей: имя, услуга/тема, срок, комментарий, контакт.

3. Учёт — строка в Google Sheets / Airtable или карточка в amo / Bitrix.

4. Человек — пуш ответственному + эскалация, если статус «новая» висит.

Приём и продажа — разные задачи. На приёме не закрываем сделку: не теряем контакт и даём контекст. Цены, спорные кейсы, жалобы — человеку.

Для ИП часто хватает: Telegram — таблица — пуш в тот же Telegram. CRM — когда поток стабилен и поля уже согласованы.

На пилоте мне хватает детерминированной логики:

- кнопки «Запись / Вопрос / Жалоба» в первом сообщении;

- обязательные имя + телефон или @username;

- таймаут: молчит 10 минут — черновик карточки и напоминание оператору;

- явный выход «позвать человека» без всей ветки;

- короткое подтверждение клиенту: «приняли, ответим в течение…».

Автоматизация приёма (поля, запись, уведомление) и автоматизация ответа (шаблоны, потом черновик с моделью под ревью) — разные слои. Второй подключаю, когда первый две недели подряд не теряет сообщения.

Практический тест: возьмите 10–15 реальных сообщений за месяц. Если большинство типовые — кнопки и три поля. Если каждый второй текст уникален — короче путь к человеку, не длиннее форма.

Правило поля: зачем менеджеру это до первого контакта? Нет ответа — убираем или переносим после звонка.

Шаг 4. Таблица или CRM — по числу рук, не по моде

Таблица ок, если:

- один ответственный или владелец сам ведёт заявку;

- до ~30–50 заявок в месяц и вы их реально смотрите;

- хватает статусов: новая / в работе / закрыта (иногда «отказ»);

- не нужны напоминания по этапам сделки.

CRM имеет смысл, если:

- двое и больше менеджеров, нужен владелец карточки;

- есть этапы: квалификация — КП — оплата — постпродаж;

- нужны «перезвонить завтра», «ждём документы»;

- руководитель смотрит воронку, а не только список новых строк.

Гибрид на пилот нормален: пишем в тестовый лист, привыкаем к полям и SLA, потом меняем только узел учёта на CRM. Перед интеграцией заполните черновик карточки на бумаге: обязательные поля, кто меняет статус, что такое закрытие.

Шаг 5. Что не трогать в первую очередь

1. «Умный агент» до стабильного приёма — бот вежливо отвечает, учёт остаётся ручным.

2. Пять каналов сразу — четыре типа сбоев одновременно. На пилоте один вход, остальные ведут сюда автоответом или ссылкой.

3. CRM «на вырост» при 15 заявках в месяц и одном менеджере.

4. Цены и обещания в автоответе без ревью.

5. Оплату до карточки заявки («деньги уже прошли, а в учёте пусто»).

6. Эскалацию на десять ролей — все перестают реагировать. Один ответственный, один резервный.

7. Жалобы и конфликты шаблоном — бот принимает текст и создаёт срочную карточку, отвечает человек.

Шаг 6. SLA и тест в пятницу вечером

Простой SLA на пилот:

- уведомление ответственному ≤ 2 минут после записи;

- первый ответ клиенту — в согласованный срок (например, 30 минут в рабочие часы);

- если «новая» висит 2 часа — второе уведомление или смена ответственного;

- ночью — автоответ с ожидаемым временем, заявка всё равно в учёте.

Текст пуша: откуда заявка, имя, услуга, ссылка на строку. Без ссылки менеджер снова ищет вручную.

Тест перед включением: отправьте тестовую заявку в пятницу в 22:00. Должны сработать автоответ клиенту, строка в учёте и уведомление (или отложенное правило, если так договорились). Нет хотя бы одного — не гоните трафик на бота.

### Типичные грабли

Симптом — Что проверить

«Клиент писал, мы не видели» — Нет единого канала-источника → один вход + редирект

Дубли в таблице — Ручной перенос из чатов → автозапись из канала

Ответ через сутки — Нет пуша ответственному → уведомление ≤ 2 мин

«Бот не понял» — Сразу NLP вместо правил → кнопки + поля + человек

Ответили в чате, в учёте пусто — Нет обязательного шага записи до/сразу после ответа

Разные статусы у всех — Нет списка полей → 3–5 полей на пилот

Пустые карточки в CRM — Интеграция до согласования полей → черновик карточки сначала

• Записать каналы и где сейчас «правда» о заявке

• Выбрать один основной вход на 1–2 недели

• Согласовать 3–5 полей и трёх статусов

• Назначить ответственного на каждый день + резервного

• Собрать цепочку: канал — поля — строка — пуш со ссылкой

• Прогнать тестовую заявку (в т.ч. вне рабочих часов)

• Записать критерий пилота до настройки: N заявок, 100% в учёте, SLA пуша, лимит ручных правок, ноль потерянных по журналу канала

• Не масштабировать на второй канал и ИИ, пока критерий не выполнен

Это не серебряная пуля и не «система на весь бизнес». Это дисциплина записи: пока её нет, любой бот только маскирует потери.

У кого какой обход сработал на пилоте — таблица, CRM или гибрид? Напишите в комменты, особенно если ломалось на исключениях (звонок вместо бота, оплата без заявки).

Альтернатива — AGENTS.md в корне или подпапке: plain markdown без frontmatter, удобен для Codex/Copilot и nested-правил. Nested AGENTS.md применяется к файлам в каталоге и ниже.

Legacy .cursorrules в корне — deprecated. Если ещё лежит — переношу содержимое в .mdc с alwaysApply: true и убираю дубль: при совпадении текста правки только в .cursorrules часто «не срабатывают».

Уровни коротко:

Уровень — Где — В git?

Team Rules — Dashboard Cursor — Нет

Project Rules — `.cursor/rules/*.mdc` — Да

User Rules — Customize → Rules — Нет

AGENTS.md — Корень / подпапки — Да

При конфликте приоритет: Team — Project — User.

Четыре режима Project Rules (2026):

Режим в UI — Frontmatter — Поведение

Always Apply — `alwaysApply: true` — В каждый Agent-чат

Apply to Specific Files — `globs: [...]`, `alwaysApply: false` — Когда файлы по glob уже в контексте чата

Apply Intelligently — `description: "..."`, без globs — Агент решает сам — для критичных запретов не полагаюсь

Apply Manually — без description/globs/alwaysApply — Только через `@Rule-name`

Нюанс Cursor 2.x: rule с globs подхватывается, когда файл по glob уже в контексте чата (@-mention или агент читает файл), а не просто открыт в табе редактора. Это объясняет половину тикетов «правило молчит».

В монорепо отдельная packages/api/.cursor/rules/ по сообщениям с форума часто не сканируется. Практический обход — AGENTS.md внутри пакета.

Не тащите готовый GitHub-пак «на все случаи». На старте хватает одного alwaysApply на 5–15 строк из вашего package.json.

Типовая раскладка:

project/

Базовый 00-project-overview.mdc:

description: Базовые соглашения проекта

Зональное правило — отдельно, одна тема на файл:

description: React/TSX в src/

Официальный ориентир: до ~500 строк на файл, одна тема — один файл. Длинный код лучше давать через @filename в rule, а не копипастой.

Создать файл можно вручную, через Customize — Rules — Add Rule, command palette «New Cursor Rule» или /create-rule в Agent-чате.

Кейс с разбора: overview на 40 пунктов из чужого monorepo — агент «забывал» код, потому что в контексте почти не оставалось места для файлов. Сократили до 12 пунктов про свой репо — стало стабильнее. полного соблюдения rules никто не обещает.

Без проверки легко жить с молчащим frontmatter. Чеклист, который прохожу сам:

1. Customize — Rules — Project Rules — файл виден, режим совпадает с frontmatter.

2. Новый Agent-чат — не продолжение старого (там контекст уже зашумлён).

3. Спросить: «Какие project rules сейчас активны?»

4. Тестовая правка в зоне glob + @-mention файла под globs.

5. Тест запрета: попросить удалить папку или тронуть lockfile — агент должен остановиться и спросить.

6. После правки: «прогони тесты» — должны уйти команды из overview, не выдуманные.

7. Закоммитить .cursor/rules/ (и AGENTS.md, если есть), чтобы коллега в новом клоне получил те же rules.

Если glob-rule не срабатывает: расширение .mdc — закрывающий --- в YAML — путь glob — файл реально в контексте чата — нет ли конфликтующего .cursorrules.

Rules — Skills — Agent mode

Что это — Текст в `.mdc` / AGENTS.md — Навыки со SKILL.md и скриптами — Режим Agent Chat с правкой файлов

Когда — Каждый чат / по glob / @ — Когда агент вызывает skill — Когда вы в Agent и даёте задачу

Не заменяет — CI, linter, hooks — Rules (дополняет) — Rules (читает их)

Rule сам npm test не запускает — он подсказывает, что выполнить. Skills — отдельные процедуры. Agent mode — режим работы с инструментами, не «магический rule».

Механика та же: .mdc в корне с alwaysApply: true, в теле — стек (1С:Предприятие, версия платформы, где конфигурация), команды проверки (скрипт выгрузки/синтакс-проверки — явно), запреты (не трогать production-выгрузку без подтверждения).

Rules не сделают агента «1С-разработчиком из коробки». Но фиксация вроде «отвечай про процедуры в стиле BSL, не генерируй SQL вместо запросов 1С» снижает разброс так же, как в JS.

### Типичные грабли

Симптом — Что проверить

Правило «молчит» — `.md` вместо `.mdc`; битый YAML; нет закрывающего `---`

Glob не цепляется — Файл по glob в контексте чата, не только открыт в табе

Агент игнорит запрет — Apply Intelligently на критичный пункт → Always Apply или globs + тест

Агент «забывает» код — Два alwaysApply по 300+ строк — съели контекст; дроблю на темы

Противоречия в ответах — Дубль AGENTS.md и overview с разными правилами

Rules не влияют на Tab — Так и задумано — только Agent Chat

Скопированный пак с GitHub — Frontmatter чужой/битый; сократить до своего стека

Монорепо: rule в пакете не виден — Nested `.cursor/rules` ненадёжен; workaround — AGENTS.md в пакете

• Создать .cursor/rules/00-project-overview.mdc с alwaysApply: true

• Вписать свой стек и реальные npm run lint/test/build из package.json

• Добавить 2–3 запрета: .env/ключи API, lockfile, «спросить перед удалением»

• При необходимости — одно зональное правило с globs

• Убрать или смигрировать legacy .cursorrules

• Проверить в Customize — Rules: файл виден, режим верный

• Открыть новый Agent-чат и спросить активные project rules

• Прогнать тест запрета и «прогони тесты»

• Закоммитить .cursor/rules/ в git

У кого какой обход сработал на «молчащем» rule — YAML, glob в контексте или сокращение overview? Напишите в комменты, что именно починили.

На разборе ко мне почти не приходят с запросом «нужен GPT». Приходят с усталостью: администратор до ночи сидит в чате, заявки из Instagram копируют руками в таблицу, PDF летают в общий WhatsApp, а в учёте потом дубли.

Я начинаю не с модели. Сначала — один процесс, пять строк карты и критерий с числом. Ниже — рабочий каркас, которым я пользуюсь на пилотах для малого бизнеса и самозанятых. Серебряной пули нет: если цепочка не описана, любая нейросеть останется демо после оплаты.

Частый кейс — салон. Владелец говорит: «Хочу ИИ, чтобы администратор не сидел в чате до ночи». На столе при этом пять задач сразу: запись, перенос заявок из Instagram, напоминания, отчёт владельцу, «сделайте как у соседа с ботом». Подрядчик отвечает презентацией. Через месяц бот в Telegram есть — а «заявка принята» так и не описали. Администратор снова копирует сообщения в таблицу руками.

Второй сценарий — опт с WhatsApp и 1С. Взяли подписку «ИИ для продаж», менеджеры шлют PDF в общий чат, бухгалтерия ловит дубли. Сбой тот же: сообщение теряется между мессенджером и учётом.

На первой сессии я спрашиваю не про модель, а про сбой:

- сколько заявок в неделю;

- кто отвечает;

- где фиксируется «сделано»;

- что происходит в выходные.

Потом записываю одну цепочку. Пример для салона: клиент написал в Telegram — администратор увидел — слот записан в YClients — клиент получил подтверждение. Под каждой стрелкой — где ломается сейчас: лента уехала вниз, слот заняли дважды, напоминание не ушло. Вот и участок для пилота.

Симптом — Что обычно делают — Что нужно вместо

«ИИ везде» — Берут несколько подписок — Один процесс + измеримый критерий

Нет владельца процесса — «Пусть IT разберётся» — Именованный ответственный с правом остановить пилот

Нет срока проверки — «Оценим через квартал» — Проверка на реальных данных за ~10 рабочих дней

Сценарий расползается — Новые задачи каждую неделю — Scope пилота + список «потом»

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

С чего я реально начинал пилоты:

1. Заявка из Telegram — строка в таблице или карточка в CRM — уведомление ответственному.

2. Запись клиента — подтверждение слота — напоминание за сутки; отмена без звонка менеджеру.

3. Входящий счёт или акт — извлечение полей в черновик — ревью бухгалтером перед проводкой.

Не начинайте с «автоматизировать отдел продаж». Начните с участка, где уже видно поломку: потерянное сообщение, неподтверждённый слот, забытый перезвон, кривые суммы в 1С.

Пять строк, которые я прошу заполнить до выбора инструмента:

1. Триггер — что запускает (сообщение, форма, письмо, звонок с фиксацией).

2. Вход — обязательные поля (имя, услуга, бюджет, город, файл).

3. Действие — что должно произойти без человека (запись, уведомление, черновик).

4. Исключение — когда зовём живого (нет слота, спорная сумма, VIP).

5. Готово — как проверяем (запись есть, пинг ушёл за N минут, клиент получил текст).

Если пять строк не складываются — сначала карта процесса, не заказ «ИИ-агента». Агент уместен, когда цепочка уже стабильна и нужна вариативность с ревью. До этого чаще хватает связки «мессенджер — таблица — уведомление».

Просьбу «сделайте умного помощника на всё» без владельца процесса я перевожу в один сценарий на выбор. Три пилота параллельно на команде из двух человек почти всегда разваливаются по вниманию.

Пилот — короткий прогон на реальных данных с заранее записанным критерием. Не «посмотрим, как нейросеть ответит», а список проверок с галочками. Формулирую до оплаты разработки, иначе спор уходит в «нам не понравилось качество» — субъективно и бесконечно.

Пример для заявок из Telegram (салон, 15–25 записей в неделю):

- 20 реальных сообщений за две недели (не тестовые «привет» от сотрудников);

- каждое в таблице или CRM с меткой времени и источником;

- ответственный получает уведомление за 2 минуты в рабочие часы;

- не больше 2 ручных правок карточки на 10 заявок;

- в выходные сценарий либо работает по расписанию, либо явно пишет «ответим в понедельник» — без молчания.

Пример для записи на услугу:

- клиент выбирает слот в боте или форме;

- подтверждение уходит автоматически с адресом и правилами отмены;

- напоминание за 24 часа; отмена одной кнопкой без звонка;

- администратор видит «сегодня / завтра» без ручного свода.

Срок около десяти рабочих дней выбран практично: видно, держит ли процесс нагрузку и исключения (отмена, перенос, «а можно другое время»). Цель не закрыта — упрощаем сценарий или возвращаемся к карте. Масштабировать рано.

Этап — Срок — Результат

Разбор — 1 сессия 60–90 мин — Карта процесса + черновик критерия

Пилот — ≈10 раб. дней — Рабочий контур на реальных данных

Решение — после пилота — Масштаб, доработка или остановка без «дожимания»

Критерий пишу в прошедшем времени и с числом: «За 10 рабочих дней 18 из 20 заявок попали в CRM без ручного копирования». «Улучшим сервис» и «ускорим работу» — не критерий. Scope подписываем вместе с владельцем: что входит, что явно «после».

Перед оплатой «внедрения под ключ» я смотрю не на технологию, а на управляемость:

- письменное описание процесса: вход, выход, исключения, кто решает спорные кейсы;

- критерий пилота с цифрами и сроком;

- список систем и доступов для первого контура;

- план отката: шаблон извинения, ручной режим, отключение автоматики одной кнопкой;

- поддержка после запуска: кто чинит, в какие сроки, что считается инцидентом.

Если подрядчик отказывается фиксировать критерий в письме — сделку не продолжаю. Без критерия это маркетинг, не внедрение.

На созвоне спрашиваю: кто владелец процесса после запуска? Сколько часов в неделю он готов тратить на первые две недели? Какие системы затронет первый контур? Что уже пробовали и почему бросили?

Часто на разборе выясняется: агент не нужен, нужна связка Telegram — Google Таблица — уведомление в тот же мессенджер. Бывает и наоборот: таблица на 200 заявок в месяц с тремя ролями уже не тянет — нужен backend и нормальные права.

Уровень — Когда хватит — Ограничения

Таблица + уведомления — До 30–50 заявок/мес, один ответственный — Дубликаты, ручной контроль качества

Конструктор бота (Telegram) — Один сценарий: заявка или запись — Сложная логика и несколько CRM — на пределе

n8n / Make + API — Несколько систем, расписания, вебхуки — Нужны API, мониторинг, человек на сбои

Код (бот + backend) — Нестандартная логика, роли, аудит — Выше старт, ниже хаос на объёме

Cursor и режим Agent у меня — инструмент разработки и ускорения правок, не замена описанного процесса.

Порядок, которого придерживаюсь:

1. Неделя ручного или полуручного контура — увидеть реальный поток.

2. Автоматизирую самый скучный шаг (уведомление, запись в таблицу).

3. Потом — исключения.

Так проще понять, где сбой: данные, интеграция или ожидания.

Пилот остаётся короткой задачей: один процесс, один владелец, один измеримый результат. В документе перед стартом фиксирую маршрут заявки, роли, список интеграций и канал обратной связи.

- Владелец отвечает на вопросы команды и принимает спорные случаи.

- В первый этап входит только согласованный сценарий; новые идеи — в отдельный список «потом».

- Каждую неделю смотрим живой поток и правим следующий цикл.

- После запуска остаётся понятный канал поддержки: кто принимает ошибку и когда отвечает.

Расширяю пилот только после того, как базовая цепочка отработала на реальных заявках. Тогда можно второй канал, CRM, отчёт или более сложную логику — без спора о функции, которую ещё никто не проверил в работе.

### Типичные грабли

Симптом — Что проверить

Бот есть, заявки всё равно копируют руками — Есть ли определение «заявка принята» и куда пишется факт

Взяли «ИИ для продаж», дубли в учёте — Где рвётся цепочка мессенджер → учёт, кто владелец

«Нам не понравилось качество ответов» — Был ли критерий с числом до старта

Три пилота сразу на двоих — Scope: один процесс, остальное в backlog

Таблица «не тянет» — Объём >30–50/мес, роли >1 → n8n/код, не ещё одна подписка

Агент «на всё» — Стабильна ли цепочка; нужна ли вариативность с ревью

Нужен ли сразу ИИ-агент? Не всегда. Если проблема — потерянные заявки в чате, часто хватит Telegram — таблица/CRM — уведомление. Агент добавляют, когда сценарий стабилен.

Можно ли без программиста? Для простых сценариев — да: конструктор бота, таблица, n8n с готовыми узлами. Несколько систем, роли и исключения — нужен настройщик с мониторингом.

Как понять, что сработало? Заявки не теряются, уведомления приходят, исключения идут по правилам. Не «модель ответила красиво».

Чеклист на завтра

• Выбрать один процесс, который уже болит (заявки / запись / учёт)

• Записать цепочку от события до результата и отметить, где ломается сейчас

• Заполнить пять строк: триггер — вход — действие — исключение — готово

• Назвать владельца процесса с правом остановить пилот

• Сформулировать критерий в прошедшем времени с числом и сроком ~10 раб. дней

• Список систем и доступов для первого контура

• План отката одной кнопкой + кто чинит после запуска

• Инструмент выбрать только после карты (часто хватит таблицы и уведомлений)

• Scope: что входит в пилот, что явно «потом»

• Через неделю ручного/полуручного контура — автоматизировать самый скучный шаг

У кого какой обход сработал на живом потоке — таблица, бот или связка с CRM? Напишите в комменты, какой был критерий и где споткнулись на исключениях.