Claude Code пишет код для 1С:Предприятие 8.3 так, что его не стыдно отдать в продуктив: каждый шаг проходит через проверку по стандартам 1С и через инструменты самой платформы. Ниже — идея, цикл и результаты.
Зачем это было нужно
ИИ и так умеет писать код на языке 1С. Проблема в другом: без правил он пишет его так, как видел в интернете, а не так, как требует платформа и стандарты фирмы «1С». Код выглядит правильно, компилируется, а потом ломает права доступа, блокирует таблицы или не проходит проверку ревьюера.
До осени 2026 года попытки заканчивались одинаково. Помощник уверенно предлагал решение, разработчик тратил время на проверку и находил ошибки, которых сам бы не допустил. Выигрыш в скорости съедался проверкой.
Вывод был простой: ИИ нужен не как «умный автодополнитель», а как участник процесса, которого проверяют теми же средствами, что и человека — стандартами, инструментами платформы и коллегами.
Главная идея: три роли и ворота
Мы не стали учить ИИ «писать лучше». Мы построили процесс, в котором плохой код не может пройти дальше своего этапа. Две мысли лежат в основе.
Три роли вместо одной. Один и тот же ИИ по очереди выступает архитектором, разработчиком и ревьюером. Архитектор решает, какие объекты нужны и почему. Разработчик пишет только то, что утвердил архитектор. Ревьюер ищет нарушения стандартов и не знает, кто писал код. Разделение ролей убирает главную слабость ИИ — склонность одобрять собственные решения.
Ворота между этапами. Перейти к следующему шагу можно только с доказательством: код собрался, проверка платформы прошла, ревьюер не нашёл нарушений. Слова «должно работать» не принимаются. Каждые ворота — это команда, которую можно запустить и увидеть ответ.
Человек стоит на входе и на выходе цепочки, агент делает всё между ними. Три роли — это не три человека и не три программы: один агент переключается между ними по разным инструкциям, а ревьюер запускается отдельным процессом и не видит рассуждений автора.
|
Человек |
Агент |
|
|
Задача |
Формулирует своими словами, отвечает на уточнения |
Читает конфигурацию, предлагает решение с обоснованием |
|
Код и |
Не участвует |
Пишет код, разворачивает в тестовой базе, пишет и запускает проверку |
|
Ревью |
Не участвует |
Отдельный процесс сверяет код со стандартами и возвращает замечания разработчику |
|
Решение |
Читает протоколы и готовый файл, решает о переносе в продуктив |
Предъявляет результат с числами; в продуктив не ходит |
Как выглядит цикл
От задачи до готового расширения — шесть шагов, и у каждого есть проверяемый результат. Всё происходит в обычном git-проекте, без ручной работы в конфигураторе.
|
Шаг |
Что делает ИИ |
Что считается доказательством |
|
1. Задача |
Читает типовую конфигурацию и формулирует, что именно меняем |
Список объектов и обоснование по стандартам |
|
2. Код |
Пишет расширение в исходниках, не трогая типовую |
Анализатор кода не нашёл нарушений |
|
3. Ревью |
Вторая роль сверяет код с 33 карточками стандартов 1С |
Замечания разобраны, отступления записаны |
|
4. Развёртывание |
Загружает расширение в тестовую базу одной командой |
Платформа ответила «ошибок нет» на каждом из пяти подшагов |
|
5. Прогон |
Запускает свою же проверку на реальных данных базы |
Протокол «ИТОГ: УСПЕХ» с числами |
|
6. Решение |
Человек смотрит готовый файл и протоколы |
Коммит с описанием, что и как проверено |
Ключевое отличие от привычной работы: шаги 4 и 5 раньше делал человек вручную и часто пропускал. Теперь они выполняются автоматически и оставляют журнал, который можно перечитать через месяц.
Что уже доказано
За два дня работы по новому циклу (21–23 сентября 2026) получены три результата, которые можно повторить и перепроверить.
|
Результат |
Число |
Что это значит |
|
Ревью существующего кода |
167 замечаний анализатора, 1 по существу |
ИИ-ревьюер отделяет шум от реальных проблем |
|
Точность со стандартом и без |
1 ложное срабатывание против 9 |
Карточки стандартов снижают ложные замечания в девять раз |
|
Новое расширение для ЗУП |
1511 строк отчёта, 380 с детьми, 0 расхождений |
Результат проверен независимым запросом на реальных данных |
Третий результат — самый важный. Задача была обычной для кадровой службы: добавить в отчёты по сотрудникам поле с детьми и датами рождения. ИИ прошёл весь цикл сам: написал расширение, написал к нему отдельную проверку, развернул оба на тестовой базе и сравнил отчёт с независимым запросом по всем сотрудникам. Человеку достался готовый файл и протокол проверки.
1C Platform Tools: изучили и отложили
1C: Platform Tools — расширение для редактора Visual Studio Code и Cursor: сборка и загрузка расширений, запуск тестов, управление сеансами. Сессия 22 сентября начиналась с вопроса, как встроить его в цикл Claude Code, и закончилась решением пока обойтись без него.
Причина простая: команды Platform Tools живут внутри открытого окна редактора, и агент может вызывать их только через посредника, пока редактор запущен. Для серверных тестовых баз те же операции доступны напрямую через командную строку конфигуратора — без окон и посредников. Владелец выбрал этот путь: конфигуратор и обмен исходниками в XML, без EDT и без редактора как обязательного звена.
Что вместо этого появилось в той же сессии и на чём сделан отчёт для ЗУП:
- Реестр тестовых баз в проекте. Один файл описывает базы бухгалтерии, зарплаты и финансов, путь к платформе и исходники типовых; все команды читают его, а не параметры из головы.
- Отдельный пользователь для ИИ. Агент входит в тестовые базы под своим именем, без паролей в файлах и без доступа к продуктиву.
- Развёртывание одной командой. Загрузка в базу, обновление, проверка модулей и сборка файла идут подряд, каждый шаг пишет журнал и останавливает цепочку при ошибке. Сюда же вшито снятие «безопасного режима», в котором платформа молча не вызывает новый код.
- Проверка поведения, а не только синтаксиса. К каждому расширению ИИ пишет отдельную проверку, которая запускается в базе без окон и возвращает протокол с числами.
- Исходники совпадают с базой. Расширения в проекте выгружены из тестовой базы, а не переписаны по памяти.
Platform Tools остаётся в запасе на случай, если команда перейдёт на работу в VS Code или понадобятся его тестовые каркасы.
Два подхода: Platform Tools и наш
Для отчётов, обработок и расширений наш цикл даёт проверяемый результат без человека у экрана; Platform Tools даёт удобный запуск тех же команд из редактора, но не проверяет смысл сделанного. Сравнение сделано по документации и коду Platform Tools 0.9.4; сам продукт мы не запускали.
Наш стек. Claude Code с правилами проекта, навык стандартов 1С на 33 карточки, отдельный агент-ревьюер, анализатор BSL Language Server, 77 навыков сборки закреплённой версии, реестр тестовых баз в проекте, командная строка конфигуратора 8.3.27 и два скрипта — развёртывание и прогон проверки в базе. Всё лежит в git-шаблоне, из которого одной командой создаётся проект под задачу. Полигон — серверные тестовые базы бухгалтерии, зарплаты и финансов, восстанавливаемые из архивов.
|
|
1C Platform Tools |
Наш подход |
|
Что это |
Расширение VS Code/Cursor поверх vanessa-runner и OneScript |
Команды и правила вокруг Claude Code и конфигуратора; редактор не нужен |
|
Кто ведёт цикл |
Человек в редакторе; ИИ нажимает те же кнопки |
ИИ ведёт цикл, человек принимает результат |
|
Работа без интерфейса |
Нет: команды живут в открытом окне редактора |
Да: каждый шаг — команда с кодом возврата и журналом |
|
Стандарты 1С |
Не проверяет |
Карточки стандартов + ревьюер, отделённый от автора кода |
|
Проверка кода |
Синтаксическая проверка платформы |
Та же проверка с контрольной ошибкой + анализатор + ревью |
|
Проверка поведения |
Каркасы тестов YAxUnit, Vanessa |
Прогон в базе на реальных данных, протокол с числами |
|
Ловушки платформы |
Не знает |
«Безопасный режим» снимается автоматически |
|
Пароли |
В файле окружения |
Не хранятся; отдельный пользователь для агента |
|
Зрелость |
Готовый продукт с пользователями |
Собственная схема, несколько расширений и отчетов доведенных до продуктива |
Почему наш подход выигрывает для отчётов, обработок и расширений:
- Цикл замкнут без человека у экрана: расширение для ЗУП прошло путь от кода до собранного файла без единого окна.
- Есть ворота, которых у Platform Tools нет: стандарты, независимый ревьюер, контрольная ошибка. Platform Tools отвечает на вопрос «чем собрать», но не «правильно ли это».
- Доказательство — числа, а не «ошибок нет»: 0 расхождений с независимым запросом на 1 511 строках.
- Знание платформы накапливается: ловушка безопасного режима встроена в скрипт и больше не повторится.
- Меньше движущихся частей: нет редактора, OneScript, vanessa-runner и второго формата проекта.
Где Platform Tools честно впереди: готовые каркасы тестов, сообщество и обновления, удобство для тех, кто работает в VS Code и хочет кнопки. Это не меняет вывода для потока доработок под серверными тестовыми базами.
Что это меняет и куда дальше
Разработчик перестаёт быть контролёром каждой строки и становится заказчиком: ставит задачу, читает протоколы, принимает решение. Типовая доработка вроде нового поля в отчёте проходит весь цикл за одну рабочую сессию, а протоколы остаются в репозитории.
Для команды это значит три вещи:
- Стандарты 1С применяются к каждой доработке, а не только когда есть время на ревью.
- Любой результат можно перепроверить через месяц: команды и журналы сохранены.
- Продуктив не трогается: ИИ работает только с тестовыми базами, перенос — решение человека.
Ближайшие шаги:
- Перевести на работу по циклу все задачи из реальной очереди команды— для зарплаты, бухгалтерии и финансов.
- Оптимизировать процесс переноса готовых решений в продуктив.
- Считать время от постановки задачи до протокола «УСПЕХ» и сравнить с прежним ручным путём.
Вступайте в нашу телеграмм-группу Инфостарт