user10429766

Три формулировки, которые путают:

1. «Хватит почты с формы» — почта резерв, не единственный канал; спам и info@ глушат скорость.

2. «Сначала CRM, потом уведомления» — сначала тест-заявка и подтверждение получения.

3. «Подключим Albato и всё само» — iPaaS без пилота даёт дубли и тихие сбои webhook.

На разборе у сервисной компании Tilda слала на sales@, владелец видел копию через секретаря, «таблица» обновлялась раз в два дня. Предложил одно уведомление в рабочий чат с полями и ссылкой — за неделю стало видно, сколько заявок «зависло».

## Контур пилота

1. Одна форма с наибольшим потоком или самой болезненной потерей.

2. 3–5 полей письменно: имя · контакт · суть · источник/UTM · ссылка на учёт.

3. Ответственный по **имени** и резервный — оба подтверждают тест.

4. Один канал сигнала: Telegram, почта интеграции или webhook в чат.

5. Тест-заявка с **публичной** страницы, не из редактора конструктора.

SLA на пилоте — согласованные N минут до первого контакта (обычно 15–60 в рабочее время), не «100% доставка».

## Каналы: Telegram, email, webhook

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

| Канал | Когда беру | Риск на пилоте |

| --- | --- | --- |

| Telegram | Нужен push в рабочее время | Личный аккаунт вместо чата; бот не в группе |

| Email | Резерв, копия владельцу | Спам, общий ящик, нет открытия в час |

| Webhook → чат/таблица | Склейка полей, лог | Таймаут, 401, дубли без дедупа |

Webhook: Tilda ждёт HTTPS и ответ 200 за ≤5 секунд (до трёх попыток). Яндекс.Формы шлют асинхронно с заголовком `x-delivery-id` — на приёмнике нужен дедуп, иначе дубли.

## Tilda и конструкторы

Проверяю по порядку: тест с публичной страницы → почта интеграции → webhook (лог 200, тело совпадает) → @TildaFormsBot в чате ответственного. Один основной канал, второй — резерв. Одна форма, один шаблон текста, один ответственный.

## Типичные ошибки

- Заявка в ленте, сигнала нет → тест с публичной страницы, лог приёмника, резервный канал.

- Два одинаковых уведомления → один основной канал + дедуп по `answer_id` / `x-delivery-id`.

- Webhook молчит при «зелёном» в Tilda → приёмник не 200 или дольше 5 с.

- CRM раньше сигнала → сначала уведомление человеку 3–7 дней.

- Cursor /automate до стабильного POST → 401 и ночной триггер на пустом контуре.

## Чеклист × 8 (3–7 дней)

1. Одна форма и один основной канал (второй — только резерв).

2. Согласованы 3–5 полей: имя, контакт, суть, источник, ссылка.

3. Ответственный по имени и резервный — оба подтвердили тест.

4. Единый шаблон: источник, поля, время, ссылка.

5. Тест с публичной страницы, не из предпросмотра.

6. Сигнал в согласованные N минут; при webhook — дедуп по `x-delivery-id` или `answer_id`.

7. Строка учёта с верным временем — второй шаг, но до CRM.

8. Приёмка 3–7 дней: сверка ленты формы и обработанных сигналов; ни одна заявка не «зависла».

Если пункт 8 не выполняется — чаще два параллельных учёта или webhook без быстрого 200, а не «та» CRM.

CRM, второй лендинг и Cursor /automate — поверх стабильного сигнала, не вместо него. Разбор схемы пилота можно обсудить в Telegram — без спама и «оставьте заявку».

— Пётр

1. «Создать таблицу одной кнопк» — в справке такй кнопки нет.

2. 2. «Хватит почты» — нет единого списка кто не обработан».

3. 3. «Сразу CRM» — сначала строка и уведоление 1–2 недели.

## Контур пилота

1. Одна форма.

2. 2. 3–5 полей: имя · контакт · суь · источник · статус.

3. 3. Один канал строки: Вики 360 / HTTP → n8n|Albato|Make / ежедневный экпорт.

4. 4. Отетственный — **имя**, не «отдел».

5. 5. Тест с **пубичной** ссылки формы.

## ри пути к строке

| анал | Когда | На что смотреть |

| --- | --- | --- |

| Вики 360 | Есть 360 | «Добавить в таблицу» — это Вики, не Яндекс Таблицы |

| HTTP → iPaaS | Нужны Sheets/CRM | IPv6 `2a02:6b8:c00::/40`, дедуп `x-delivery-id` |

| Экспорт XLSX/CSV | Бюджет 0 | Один чеовек, ода выгрузка в день, колонка «обработано» |

Пример HTTP: форма шлёт JSON + заголово `x-delivery-id`. Без дедупа — дубли строк.

## Типичые ошибки

- Ждут «нативные Таблицы» из статьи в выаче → сторонний видет, строк нет.

- 12 полей + три интеграции в день один → красные строки в «Выплненных интеграциях».

- Почта + HTTP без дедупа → дубли в талице и CRM.

- Cursor /automate до стабильной доставки → ночной триггер на пустом контуре.

- Сверка ленты формы и строк раз в месяц → пропуски в спаме и упавших HTTP.

## Чеклист × 8 (1–2 недели)

Одна форма · один канал строки · 3–5 полей · ответственный по мени · уведомлеие подтверждено · тест с пуличо сылки · строка + `x-delivery-id` · «Выполненные инеграции» итые · сверка лента↔сроки без «зависших».

Если пункт про потери не выполняется — чините IPv6/дедуп/два учёта, не «ту» CRM.

## Когда CRM

После 1–2 недель без потерь. Те же поля → сделка. Один сценарий HTTP/iPaaS. Ответсвенный совпадает.

— Пётр

Привет. Меня зовут Пётр, я разбираю идеи продуктов и автоматизацию для малого бизнеса. Сегодня — про MVP, который реально работает, а не про красивые презентации.

Главная ловушка

«Нам нужен бот + CRM + аналитика» — слышу это постоянно. Открываю переписку — и в 80% случаев боль в одном месте: заявка из Telegram доходит с задержкой или теряется. Остальное можно отложить.

MVP продукта — не мини-копия всего ТЗ. Это проверка одной рискованной гипотезы за 1–2 недели: один операционный сценарий, явный критерий «готово» и список того, что вы сознательно не делаете.

ИИ ускоряет прототип, но агент в ноутбуке без прод-метрики — не MVP.

Шесть шагов (код — последний)

# — Шаг — Суть

1 — Гипотеза — Что должно измениться в операции

2 — Сценарий — Кто → что → куда записано

3 — Критерий — Порог: число, срок, допустимые потери

4 — Anti-scope — Что НЕ делаем в этом цикле

5 — Живые заявки — Не демо-аккаунты

6 — Решение — Масштаб / смена гипотезы / стоп

Заказ кода — шаг 6, не шаг 1.

Гипотеза: плохо vs хорошо

❌ «Клиентам будет удобнее с ботом»

✅ «Если заявка из Telegram попадает в таблицу за 3 минуты без ручного копирования, ночные обращения перестанут теряться до утра»

Вторая формулировка можно опровергнуть. Первая — просто пожелание.

Concierge — это нормально

Владелец салона пересылает сообщения в чат, админ вносит строку в таблицу — это валидный MVP, если есть гипотеза и метрика потерь. Ручной процесс на старте — не стыдно. Стыдно — заказать разработку до проверки.

Если ручной процесс работает и заявки не теряются — честный исход «код не нужен». Серьёзно.

MVP scorecard — четыре поля

Заполняю до любого прототипа:

Поле — Пример

hypothesis — Ночные заявки из Telegram не теряются до 10:00

scenario — Клиент → бот → уведомление менеджеру → строка в таблице

done_criterion — 5 реальных заявок без потерь за 7 дней

anti_scope — Оплата, ЛК, 1С, аналитика

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

ИИ: ускоритель, не замена проверки

Cursor/n8n соберут webhook за вечер. Ловушка — пустой scorecard. NIST называет confabulation риском: агент уверенно генерит код, который пишет не в ту таблицу.

До продакшена фиксирую:

- HTTPS webhook + «secret_token«

- Не смешивать «setWebhook« и long polling

- Лог каждого Update

- Алерт, если запись не создалась за 60 секунд

- Human-fallback, если бот молчит

Зелёный lint агента ≠ production MVP.

Типичные косяки

1. Весь ТЗ в MVP — оплата, ЛК, три интеграции «на всякий случай»

2. Тест на своих — бот работает у команды, живых заявок ноль

3. Vanity-метрики — считают клики, не потери ночных сообщений

4. Нет запасного канала — webhook упал ночью, клиенты в пустоту

Когда идти в разработку

- Критерий выполнен (или провален) с цифрами

- Anti-scope согласован

- Сценарий описан так, что разработчик напишет ТЗ на один поток

- Понятна цена ошибки

Не когда «выглядит готово».

Если у вас заявки живут в Telegram, а учёт — в таблице, начните с одного scorecard на неделю.

Пётр Пашкуров, наставник

Приходит заказчик: «Соберите бота за выходные». Открываю переписку — заявки живут в личном Telegram владельца, менеджер вечером копирует их в таблицу, ночные сообщения висят до утра. Идея «бот + CRM» звучит логично. Но без проверки непонятно, что считать успехом: скорость ответа? Отсутствие дублей? Запись в учёт за N минут?

Пока критерий не записан — любой прототип это работа ради работы.

Я занимаюсь разбором процессов и наставничеством по Cursor. И вот что вижу снова и снова: люди бегут в код, не проверив одну простую вещь — есть ли боль в одном операционном сценарии и готов ли кто-то платить временем или деньгами, чтобы её закрыть.

ПЯТЬ ШАГОВ, КОТОРЫЕ Я ПРОХОЖУ НА КАЖДОМ РАЗБОРЕ

Не месяцы исследований. Один проход по сценарию:

1. Один сценарий — не «автоматизировать весь бизнес», а одну дыру: заявка из Telegram, запись клиента, перенос в CRM.

2. Гипотеза + метрика — бинарный или числовой критерий «сработало/нет» с порогом заранее.

3. 5–10 интервью по Mom Test — про последний реальный эпизод, не «вам было бы интересно?»

4. Lean canvas — проблема и сегмент первыми, обновляем после каждого разговора.

5. Эксперимент — concierge, лендинг, прототип или узкий пилот.

ПРИМЕР ГИПОТЕЗЫ (КАК Я ФИКСИРУЮ НА РАЗБОРЕ)

Гипотеза: владелец салона теряет записи, когда клиент пишет в личный Telegram после 21:00.

Метрика: доля заявок с меткой «ночь», попавших в учёт до 10:00 следующего дня.

Порог: ≥ 90% за 7 дней пилота при ≥ 20 заявках.

Сегмент: салон 2–4 мастера, заявки в Telegram + звонки.

Эксперимент: concierge — админ пересылает в общий чат + строка в таблице по шаблону.

Без порога пилот превращается в «вроде работает».

5 ВОПРОСОВ ДЛЯ ИНТЕРВЬЮ (НЕ «ПОНРАВИЛСЯ БЫ БОТ?»)

1. Как в последний раз обработали заявку из чата? — конкретный эпизод.

2. Сколько времени от сообщения до записи в учёт? — метрика боли.

3. Что пошло не так? — последствия.

4. Чем пользуетесь сейчас? — текущее решение.

5. Если бы потери исчезли — что изменилось бы в дне? — ценность без продажи.

4 ПРИЗНАКА, ЧТО БОЛЬ НАСТОЯЩАЯ

— Уже тратят время/деньги на обходной путь (таблица, второй телефон).

— Описывают последствия: потерянный клиент, срыв записи.

— Сами поднимают проблему до вашего предложения.

— Готовы на тестовый шаг: дать доступ к чату, вести учёт по шаблону.

ТИПИЧНЫЕ КОСЯКИ (УЗНАЁТЕ СЕБЯ?)

— Друзья вместо операторов. Симптом: «всем нравится». Что делать: интервью с теми, кто ведёт заявки.

— Фичи до боли. Симптом: «ИИ-аналитика» в канвасе, а боль — «неэффективность». Что делать: 3 конкретных эпизода из интервью.

— Пилот без цифр. Симптом: «клиенты довольны». Что делать: порог метрики зафиксировать до старта.

— ИИ вместо custdev. Симптом: ChatGPT одобрил идею. Что делать: Mom Test по прошлому опыту.

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

КОГДА МОЖНО ИДТИ В ПИЛОТ

Четыре условия одновременно:

— боль подтверждена интервью

— плательщик назван

— canvas обновлён

— метрика с порогом согласована

Если Excel и Telegram уже работают без потерь — «код не нужен» это нормальный исход. Не провал, а честный результат.

Пишу как практик, который каждый месяц разбирает такие процессы. Если полезно — сохраните чеклист.

Cursor Agent переписал вам полпроекта, отчитался «lint зелёный» — и вы жмёте merge. Через час форма на лендинге шлёт 500. Знакомо?

Я веду разборы по Cursor для соло-разработчиков и основателей. Тесты после AI-diff — не про «90% coverage» и не про TDD-курс. Это про то, чтобы до деплоя понять, какой сценарий сломался.

С чего начинаю на разборе

Не с pytest. С критерия готовности.

Пример: бот принимает заявку с лендинга → пишет в CRM без дублей → отвечает за 3 секунды. Пока цепочка не зелёная — merge рано. Даже если агент уверенно написал «всё ок».

Три слоя после Apply All

1. Lint + targeted test на затронутый модуль — не весь suite.

2. Регрессия сценария — путь, который правили, не весь репо.

3. Полный CI — только на PR в GitHub Actions.

Матрица, которая экономит вечер:

— CSS / текст: lint + глазами страницу; suite не нужен.

— Одна функция: pytest один файл; модуль + smoke.

— package.json: npm ci + build; полный CI.

— auth / платёж: интеграция + откат; staging обязателен.

Unit-тесты: что реально важно

Приоритет с разборов бизнес-репо:

— деньги и доступ;

— данные клиента (телефон, дедуп заявок);

— контракты API;

— пограничные значения (агенты любят «счастливый путь»).

Классика: агент переписал normalize_phone(), тест только на +7999..., а 8 (999) падает в проде.

Команды:

— Python: pytest tests/test_phone.py -q

— JS: npm test -- src/utils/phone.test.ts

Регрессия без религии

Не гоняю 300 тестов после правки одной строки в CSS.

pytest -m smoke # мелкая правка

pytest -m regression # широкий diff

Маркеры smoke / regression надо один раз прописать в pytest.ini. Agent часто добавляет тесты без маркеров — тогда targeted path надёжнее.

Чеклист перед merge (5 минут)

npm run lint

pytest path/to/test_module.py -q

pytest -m regression --maxfail=3 -q # если diff шире одного файла

git push -u origin HEAD

ручной smoke критического пути

Зелёный прогон агента в чате ≠ PASS. Галочку ставлю только когда сам скопировал команду в terminal и увидел exit code 0.

Что ломается чаще всего

— Flaky — time.sleep(1) в тесте. Лечится моком времени.

— Ложнозелёный — assert result is not None. Нужен assert на конкретное значение.

— Agent закомментировал assert «временно». Временно = до инцидента в проде.

Если тестов вообще нет

Честный минимум: один smoke на критический путь + lint. Написание полноценного test suite — отдельная задача. Здесь — что гонять уже сегодня, когда Agent только что переписал handler.

Пётр Пашкуров — наставник по Cursor. Пишу практические разборы, без обещаний zero bugs и без магического процента покрытия.

Привет, Пикабу! Делюсь рабочей схемой из разборов с учениками. Без воды, с конкретными примерами.

TL;DR

«Сделай интеграцию» — это не задача для AI-агента, а эпик на неделю. Нужны: один результат, список файлов и критерий готовности.

Почему агент «творит дичь»

Cursor Agent = Instructions + Tools + Model. Когда цель размыта, инструменты работают вслепую:

• находит похожие файлы (lead.ts, Lead.ts, leads.service.ts)

• тянет соседние модули

• добавляет либу «как в туториале»

Реальный кейс с разбора: CRM-бот, промпт «подключи AmoCRM». Diff затронул web/, bot/ и deploy/. Заявка не ушла, прод-конфиг уже изменён.

Как резать эпик

Вопрос: что изменится после merge?

• Не так: «интеграция готова»

• Так: «POST /api/leads отдаёт 201 с leadId»

• Так: «бот после /start показывает кнопку без ошибки в логе»

Чеклист:

1. Один исход

2. Один слой (backend ИЛИ frontend ИЛИ handler)

3. Max 3-5 файлов

4. Запреты (deploy/, .env*)

5. Verify-команда + ручной smoke

Пример нарезки «Telegram - Amo»:

• Чат 1: mapper полей (без HTTP)

• Чат 2: HTTP-клиент с mock

• Чат 3: handler + log amo_lead_created

Scope — не «где-нибудь в src»

Пишу в промпте:

Разрешено: bot/handlers/lead.ts, shared/validators/phone.ts

Запрещено: deploy/*, web/src/*, package.json, .env*

Плюс .cursorignore на секреты. Плюс @ на entrypoint.

Критерий «готово»

«Агент сказал готово» — не критерий.

npm run lint && npm test — exit 0

изменены только файлы из scope

тестовая заявка - log "lead_accepted"

.env* не в diff

После Agent: diff пофайлово - smoke - commit. Не Apply All сразу.

Шаблон промпта

До:

Сделай интеграцию с AmoCRM. Почини если не работает. Деплой тоже.

После:

Результат: handler пишет "lead_mapped", возвращает AmoLeadPayload

Scope: @Bot/handlers/lead.ts @Shared/mappers/amoLead.ts

Verify: npm run lint && npm test

Готово: unit-тест TestMapTelegramLeadToAmo — green

Типовые ошибки: diff в 5 папках - итерация только на mapper; API-ключ в config.ts - env + ротация; два follow-up в одном чате - commit и новый чат.

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

Автор: Пётр Пашкуров, разработка и наставничество по Cursor.

git pull --ff-only

git checkout -b feat/одна-задача

git add -A

git commit -m "checkpoint: before agent"

Проверка: git branch --show-current не main.

В Cursor то же через Source Control: Create new branch, stage, commit.

Diff - не формальность

Agent закончил - не жать Accept All.

1. git diff --stat - сколько файлов и где.

2. Открыть diff по файлам - нет ли .env, лишних зависимостей.

3. Accept только scope задачи.

4. npm run lint / npm test руками.

5. git add точечно, commit одного шага.

Один большой commit «агент всё сделал» откатывать больно. Три маленьких - проще.

Грубый grep по diff на секреты:

git diff | grep -E '\.env|TOKEN|password|api_key'

Ловит «временный ключ в config.ts» до push.

.gitignore до первого add

.env

.env.*

secrets/

*.pem

*.key

node_modules/

dist/

Дублирую в .cursorignore, чтобы @ не тащил секреты в контекст. Но terminal агент всё равно может прочитать файл - не давать cat .env в задаче.

Если .env уже в истории - ignore не спасёт. Ротация ключа + git rm --cached.

Откат без паники

Ситуация — Действие

Diff не приняли — Reject в UI

Файл испорчен, не в commit — git restore path

Плохой commit, ветка не pushed — git reset --hard HEAD~1

Плохой commit на общем main — git revert <hash>

Rebase от агента завис — git rebase --abort

На shared main без согласования - не force-push.

Типичные косяки с разборов

Деплой с main. Agent закоммитил, CI ушёл, форма 404. Урок: main только через merge после review, локально агент - в ветке.

Ключ в git log. Вставили токен в промпт «чтобы заработало». Урок: ротация сразу, не «потом уберём».

12 файлов, половина мусор. Нет scope в rules. Урок: globs в AGENTS.md, узкий промпт.

Чеклист на холодильник

До: ветка, checkpoint, ignore, rules.

Во время: diff → lint/test → commit по шагам.

После: git diff main, merge только если зелёное.

Одна строка после сессии:

git diff --stat && npm run lint && npm test && git status

Красное - не merge.

Вопрос вам

Agent уже коммитил в main у вас? Чем откатывались - restore, reset, revert? Пишите в комментах стек и симптом - разберём по шагам.