Вайб‑кодинг уже стал привычным способом разработки: человек описывает задачу обычным языком, а ИИ помогает писать и уточнять код. Но до кода обычно появляются требования, карта процесса и техническое задание. Если этот этап выполнен поверхностно, модель лишь быстрее создаст решение не той задачи.

Для работы аналитика точнее подходит термин вайб‑спекинг — диалог с ИИ, в котором исходная идея постепенно превращается в спецификацию: с границами доработки, объектами конфигурации, исключениями, рисками и критериями приёмки.

Главное условие здесь — контекст. Универсальная языковая модель может хорошо оформить документ, но не обязана знать устройство конкретной версии конфигурации 1С. Поэтому полезность ответа зависит не только от промпта, но и от того, есть ли у агента сведения о метаданных и типовых механизмах системы.

В статье разберём, какие задачи можно делегировать такому помощнику и где его выводы всё равно должен проверять специалист.

Что можно поручить ИИ‑агенту

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

В описываемом примере используется облачный режим «Эксперт по 1С» в MAKER‑STUDIO. Он работает в браузере: для первичного анализа не нужно запускать конфигуратор, 1С:EDT или разворачивать отдельную инфраструктуру. На момент подготовки материала агент ориентируется в следующих типовых решениях:

• 1С:Документооборот;

• 1С:Бухгалтерия;

• 1С:Управление торговлей;

• 1С:Зарплата и управление персоналом;

• 1С:ERP;

• 1С:Цифровое животноводство;

• 1С:Управление нашей фирмой.

Это не означает, что его ответ можно сразу переносить в рабочее ТЗ. Версия конфигурации, расширения, настройки функциональных опций и данные конкретной информационной базы способны заметно изменить картину.

Как формулировать запросы

Запрос полезно строить не вокруг абстрактного «напиши ТЗ», а вокруг результата, который нужен на текущем этапе. Например:

1. «Есть ли в типовой конфигурации учёт совмещения должностей и как он проводится?»

2. «Опиши процесс приёма на работу: документы, кадровые регистры, роли и доступ к формам».

3. «При проведении больничного нужно запрещать расчёт, если не указан стаж. Какие типовые объекты затрагивает изменение и куда корректнее встроиться?»

4. «Составь чек‑лист приёмки для отчёта по остаткам отпусков, включая негативные сценарии».

5. «Подготовь разделы ТЗ: цель, as is, to be, объекты, права, исключения и критерии приёмки».

Хороший рабочий цикл выглядит так:

Аналитик задаёт бизнес‑цель и ограничения → агент собирает факты по типовой конфигурации и предлагает каркас → аналитик проверяет сведения и адаптирует документ под процессы заказчика.

Пример 1. Найти объекты интеграции ERP с 1С:Документооборотом

Допустим, нужно выяснить, существует ли в ERP типовая интеграция с 1С:Документооборотом и какие объекты к ней относятся. Без помощника аналитику пришлось бы обратиться к разработчику либо самостоятельно изучать дерево метаданных.

Запрос агенту можно сформулировать так:

Есть ли модуль интеграции с 1С:Документооборотом в ERP? Если да, перечисли основные объекты подсистемы, их назначение, точки расширения и ограничения. Укажи версию конфигурации, на которой основан ответ.

Для ERP 2.5.27 агент выделил подсистему интеграции с редакциями 2 и 3 «1С:Документооборота» и разложил объекты по назначению:

• план обмена и регламентное задание фонового обмена;

• обработки настройки и администрирования;

• общие модули базовой логики и отдельных редакций;

• правила сопоставления объектов ERP и документооборота;

• регистры очередей, истории отправки, статусов согласования и авторизации;

• функциональные опции, команды интерфейса, роли и подписки на события.

Особенно полезен не сам длинный перечень метаданных, а вывод о границах ответа. По метаданным можно подтвердить наличие механизма, но нельзя определить, включён ли он в конкретной базе, какая редакция используется и какие документы фактически участвуют в обмене. Для этого нужно проверить константы, функциональные опции, правила интеграции и переопределяемые типы в информационной базе заказчика.

Такой ответ не заменяет обследование, но помогает быстрее составить список вопросов и понять, где искать факты.

Пример 2. Подготовить ТЗ с критериями приёмки

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

В запросе стоит сразу назвать:

• бизнес‑цель;

• версию конфигурации;

• обязательные ограничения;

• способ реализации;

• ожидаемую структуру ответа.

Например:

Подготовь ТЗ для «1С:Документооборот 3.0.21». Нужно напоминать обязанным сотрудникам о незаполненном ежедневном отчёте за предыдущий рабочий день. Учти выходные, отпуска и другие отсутствия. Доработка — через расширение. Предложи архитектуру, состав объектов, риски, вопросы заказчику и критерии приёмки.

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

Отсюда появился рабочий вариант архитектуры:

1. В расширении хранится список сотрудников, обязанных вести отчёт.

2. Регламентное задание проверяет предыдущий рабочий день.

3. Из выборки исключаются выходные и полнодневные отсутствия по согласованному правилу.

4. Проверяется наличие проведённого ежедневного отчёта.

5. Уведомление помещается в типовую очередь, чтобы использовать штатные каналы доставки.

6. Для контролёра формируется список сотрудников со статусами «сдан», «не сдан» и «не требовался».

Критерии приёмки при этом получаются проверяемыми:

• обязанный сотрудник без проведённого отчёта получает уведомление в заданное время;

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

• уведомление не отправляется за выходной или день полного отсутствия;

• после проведения отчёта повторы прекращаются;

• повторный запуск задания не создаёт дубли;

• контролёр видит список несдавших за выбранный период;

• при отключённом функционале ежедневных отчётов регламент ничего не делает;

• расширение устанавливается без изменения основной конфигурации.

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

Пример 3. Построить карту процесса в УНФ

Третий тип задачи — описать сквозной процесс «заявка клиента → производство → отгрузка» в УНФ 3.0.13.

Базовая цепочка выглядит так: Заказ покупателя → Заказ на производство → Производство → Расходная накладная → Оплата покупателя. Если материалов не хватает, между заказом на производство и выпуском добавляются заказ поставщику и поступление. Если готовый товар уже есть на складе, производственный блок можно пропустить.

Перед запуском процесса нужно проверить, включена ли подсистема производства, заведены ли номенклатура и спецификации, определены ли склады и производственные подразделения.

Дальше агент может разложить работу по документам:

1. Заказ покупателя фиксирует заявку или подтверждённый заказ и связывает дальнейшие операции.

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

3. При нехватке материалов создаются Заказ поставщику и Приходная накладная.

4. Документ Производство (СборкаЗапасов) отражает фактический выпуск и списание материалов.

5. При необходимости продукция перемещается на склад отгрузки.

6. Расходная накладная отражает отгрузку и закрывает заказ.

Для контроля можно использовать отчёты по заказам покупателей, потребности в запасах, заказам на производство, план‑факту выпуска, остаткам, незавершённому производству, себестоимости и продажам.

Здесь ИИ полезен ещё и тем, что может подготовить описание схемы для последующей визуализации. Но фактический маршрут зависит от настроек базы: этапов производства, ордерных складов, серий, прослеживаемости, вариантов резервирования и принятых у заказчика правил.

Где проходит граница доверия

ИИ‑агент хорошо подходит для черновой аналитической работы, если ответ можно проверить. Самые полезные результаты — это не категоричные утверждения, а структурированный набор фактов, допущений, рисков и следующих шагов.

Перед передачей результата разработчику или заказчику стоит проверить:

• совпадает ли версия конфигурации;

• действительно ли перечисленные объекты существуют и используются;

• не изменены ли они расширениями и доработками;

• какие функциональные опции включены;

• что определяется метаданными, а что — данными конкретной базы;

• отделены ли подтверждённые факты от предположений;

• можно ли однозначно проверить критерии приёмки.

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

Что меняется в работе аналитика

При грамотном использовании ИИ сокращает время на поиск объектов, первичный разбор типового функционала, оформление структуры ТЗ и подготовку тестовых сценариев. Освободившееся время можно потратить на то, что хуже поддаётся автоматизации: интервью с заказчиком, выявление противоречий, согласование границ проекта и проверку того, что предлагаемое изменение действительно решает бизнес‑задачу.

Вайб‑спекинг — это не способ получить готовое ТЗ одной командой. Это управляемый диалог, в котором аналитик остаётся автором решения, а ИИ ускоряет поиск, структурирование и оформление материала.

Источник и дополнительные скриншоты: оригинальная публикация на Инфостарте.