ИИ в разработке 1С: что поручить нейросети и как проверить результат

Что можно поручить, а что нужно оставить под контролем

Можно поручить помощнику четыре ограниченные задачи. Ожидаемый результат в каждом случае нужно задать заранее:

1. Разобрать запрос: список неясных требований, входных и выходных данных и вопросов до начала изменения.
2. Подготовить черновик небольшой обработки: вариант реализации по описанию с перечнем допущений для проверки.
3. Объяснить ошибку: понятная формулировка сообщения, вероятное место причины и шаги для воспроизведения.
4. Подобрать проверки: обычный сценарий, граничные условия и ошибки с ожидаемым поведением.

Сложнее всего оценить ответ, когда постановка не задает правило. Например, «исправь расчет скидки» не говорит, как обрабатывать округление, возврат, ручную цену, несколько видов скидки и права пользователя. Модель может уверенно заполнить пробел предположением. Поэтому сначала перечисли поведение, которое ожидаешь, а затем сравни предложение с этим списком.

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

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

Рабочий порядок проверки

1. Подготовь задачу. Укажи конфигурацию, объект, цель изменения и наблюдаемое поведение. Передай только те фрагменты кода и данные, которые разрешено использовать.
2. Ограничь объем. Попроси объяснить или предложить изменение для конкретного участка. Отдельно перечисли то, что нельзя менять: поведение документа, права, формат обмена или существующие имена объектов.
3. Сверь каждую правку. Проверь, откуда взялись используемые поля и методы, как обрабатываются пустые значения, исключения и повторный вызов, не обходятся ли проверки прав.
4. Запусти проверки проекта. Используй доступные в конкретной среде проверки кода и конфигурации. Например, 1C:EDT умеет выполнять проверки конфигурации в процессе редактирования; это не отменяет проверку измененного сценария.
5. Проверь в тестовой базе. Повтори обычный ход работы и важные исключения на данных, которые можно использовать для проверки. Сравни документы и отчеты до и после изменения.
6. Посмотри на соседние процессы. Убедись, что изменение не нарушило связанные формы, права, печать, отчетность, обмены и последующее обновление конфигурации.
7. Сохрани объяснение. Зафиксируй, что изменено, какие проверки пройдены и какие ограничения остались, чтобы другой специалист мог восстановить логику.

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

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

Данные и границы доступа

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

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

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

Частые вопросы

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

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

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

Официальные источники 1С: направления применения ИИ в продуктах 1С, руководство 1С:Напарника, руководство по проверкам 1C:EDT.