Стандарты разработки фирмы «1С» написаны для людей, которые читают их один раз и потом помнят. ИИ читает их заново при каждой задаче и ничего не помнит. Мы пересобрали стандарт в форму, которую ИИ может применять и проверять, — и путь к этому был не прямым. Рассказ построен как классическая драма: завязка, нарастание, кульминация, перелом и развязка. Все события и числа в нём настоящие.
Справочник, который должен был всё решить
Сентябрь 2026 года. Разработка 1С переезжает под git, рядом появляется Claude Code, и есть простое желание: пусть ИИ пишет код по стандартам фирмы «1С», а не по образцам из интернета. Стандарты существуют давно: на сайте ИТС 319 записей, из них 212 действующих статей для современной платформы.
Первое решение выглядело очевидным. Пересказать 212 статей компактно, разложить по темам — объекты, код, запросы, формы, безопасность, — добавить шпаргалку для ревью и подключить к агенту как навык. Три слоя — короткое правило, компактный пересказ, полный текст по запросу — и маршрут «какая задача, какой файл читать».
На бумаге ИИ теперь «знал стандарты». Оставалось проверить, помогает ли это на деле. С этой проверки и начинается история.
Каждая проверка находила новую дыру
18 сентября первый аудит навыка вынес вердикт, который никому не понравился: полезный справочник, но ненадёжный инструмент для ревью и генерации кода. Причина одна: при сокращении номер статьи остаётся, а условия, исключения и степень обязательности исчезают. Пересказ выглядит уверенно и при этом врёт.
Три примера из восьми подтверждённых замечаний:
- Совет по оптимизации запроса искажал результат. Короткое правило предлагало заменить условие «или» объединением двух выборок, но потеряло оговорку о пересечении: строка, подходящая под оба условия, считалась бы дважды, и суммы в отчётах завышались бы.
- Эталон теста противоречил самому стандарту. Ожидаемый ответ первой задачи содержал тип денежного поля, который справочник сам называет ошибкой. Проверка поощряла бы неправильный ответ.
- Шпаргалка превратила условное правило в запрет. Она запрещала явную запись движений при проведении документа, хотя статья прямо разрешает её, когда движения нужны следующим алгоритмам. Запомним этот механизм — он ещё вернётся.
Второй аудит сверил компактный слой с живыми статьями по 73 стандартам и добавил ещё 11 находок. Рабочая область формы была завышена на 100 точек. Правило о ролях расширения описывало только простейший случай, а цена ошибки здесь — административные права, розданные всем пользователям.
Потом открылась системная ошибка. На сайте врезка «Методическая рекомендация» относится только к тексту после неё, а не ко всей статье. Из-за этого пять требований — включая обязательную букву «ё» в текстах интерфейса — были понижены до советов. ИИ честно считал их необязательными.
И наконец техника. В адресах 164 статей из 319 стоит неразрывный пробел, и скрипт сверки падал на половине номеров. Сайт отдаёт текст в старой кодировке и во вложенном фрейме — обычный запрос возвращал либо искажённый текст, либо пустую оболочку. А в первую редакцию навыка утекли 58 блоков чужого кода с сайта — их пришлось вырезать и написать свои.
К вечеру список закрытых находок был длиннее исходного плана. Казалось, худшее позади.
Кульминация: линейка оказалась кривой
Чтобы понять, помогает ли навык, нужен честный опыт: одни и те же задачи решаются с навыком и без него, ответы оцениваются по заранее записанным критериям. Среди задач был особый сценарий № 22 — «чистый» модуль без единого нарушения. Он служил линейкой: сколько ложных замечаний ИИ сделает на законном коде.
Пилотный прогон 18 сентября дал результат, которого никто не ждал. Оба режима независимо нашли в «чистом» модуле два настоящих дефекта: привилегированный режим включался там, где данные только читаются, а экспортный метод молча гасил ошибку после отмены транзакции. Линейка, которой мерили ошибки, сама была с ошибками. Полный прогон в тот же день нашёл в ней третий дефект — имя события журнала без основного языка конфигурации.
В тот же день пришла внешняя редакция навыка с семью верными новыми карточками. И с тихим откатом: она была собрана с более раннего снимка и возвращала сценарий № 22 к той самой дефектной линейке. Прими поставку по её собственному отчёту — и день работы исчез бы незаметно.
А третий аудит показал, что знакомый механизм сработал в третий раз: шпаргалка снова сжала условное правило до запрета, теперь про запросы в цикле. Плюс ключ анализатора, приписанный не той статье, и самые дорогие правила — о правах, внешних программах, паролях в коде — без карточек вовсе.
Здесь и наступило узнавание. Проблема была не в количестве пересказанных статей и не в качестве пересказа. Пересказ в принципе нельзя проверить: у него нет условия, нет исключения, нет способа проверки и нет даты, когда его сверяли с источником. А инструмент, который нельзя проверить, нельзя и доверить ИИ. Стандарт нужно было не дописывать, а пересобрать на другом принципе.
Перелом: от пересказа к карточкам правил
Пересборка дала редакцию 3.1. Главная новая сущность — карточка правила. Для 31 статьи с наибольшей ценой ошибки — данные, права, транзакции, запросы, клиент-сервер, локализация, запуск внешних программ — заведены 33 карточки, и каждая сверена с текстом статьи перед записью. Карточка отвечает на вопросы, на которые пересказ ответить не мог.
|
Поле карточки |
На какой вопрос отвечает |
|
Пункт статьи |
Откуда именно взято правило, со ссылкой на страницу |
|
Условие |
Когда правило действует |
|
Исключение |
Когда не действует, хотя выглядит применимым |
|
Окружение |
От чего зависит: версия, режим, вложенность вызовов |
|
Как проверить |
Что именно посмотреть в коде, чтобы доказать нарушение |
|
Тяжесть |
Критично, важно или мелочь — по последствию, а не по номеру |
|
Автопроверка |
Ловит ли анализатор кода: полностью, частично или никак |
|
Дата сверки |
Когда карточку в последний раз сравнивали с источником |
Пример — карточка о транзакциях. Правило: начало и завершение транзакции парны и стоят в одном методе, при ошибке первой строкой идёт отмена, потом запись в журнал. Исключение: явная транзакция не нужна, если кроме записи одного объекта других действий с базой нет. Окружение: вызывается ли метод изнутри уже открытой транзакции. Автопроверка: четыре диагностики анализатора ловят парность и расположение вызовов, но нужна ли транзакция вообще — решает разбор.
Второе изменение — честность про автоматику. Из 33 правил анализатор полностью проверяет 4, частично 17, а 12 не проверяет никак, и это записано в самих карточках. Теперь ИИ знает: срабатывание анализатора — повод проверить, а не приговор, и его молчание — не индульгенция.
Третье — окружение стало частью правила. Перед решением ИИ устанавливает профиль проекта: версия платформы, режим совместимости, библиотека стандартных подсистем, клиент, СУБД, расширение или основная конфигурация. Сначала он читает файлы проекта и спрашивает только то, от чего зависит доступность метода или сохранность данных.
Шпаргалка — та самая, что трижды превращала условие в запрет — понижена в звании. Теперь она даёт повод проверить код, а не готовую находку; порядок ревью закреплён: сначала прикладная логика, потом шпаргалка, потом карточка. Отступление от стандарта разрешено, но только письменно: комментарий в коде и строка в журнале с причиной и датой пересмотра. Отступление без причины считается дефектом: оно неотличимо от незнания правила.
И последнее — навык научился проверять сам себя. 37 сценариев собраны парами «дефект / законный случай», чтобы ловить не только пропущенные ошибки, но и ложные замечания; 59 автотестов следят за целостностью материалов; тексты 31 проверенной статьи закреплены хешами, и изменение на сайте обнаруживается командой. Чужая редакция принимается только после сверки по файлам, а не по её отчёту. Три вещи сознательно не считаются качеством: число пересказанных статей, число ссылок на стандарты в ответе и «процент соответствия».
Развязка: числа
Вечером 18 сентября прошёл полный прогон: 37 сценариев, каждый решён дважды — с навыком и без, по 140 проверяемых утверждений на режим. Ответы и оценки сохранены, их можно перечитать.
|
|
С навыком |
Без навыка |
|
Выполнено утверждений |
136 из 140 (97 %) |
108 из 140 (77 %) |
|
Пропущенные дефекты |
0 |
9 |
|
Законный код, объявленный нарушением |
1 |
9 |
|
Исправления, ломающие поведение |
1 |
9 |
|
Сценариев с полным зачётом только в этом режиме |
17 |
1 |
За числами стоят узнаваемые ситуации. Без навыка ИИ почти нигде не называл пункт статьи — вывод мог быть верным, но спор с ревьюером им не закрыть. Он объявлял дефектом существующую проверку роли и законный возврат «Ложь» вместо проброса ошибки. Он предлагал правки, которые меняют поведение: фильтрацию по правам в запросе бизнес-логики, фиксированную разрядность денежного типа, порцию в 1000 строк как обязательную. И выдумывал факты: несуществующий порог версии платформы и неверный ключ диагностики, по которому подавление просто не сработало бы.
Честность требует назвать и проигрыши навыка. В одном сценарии он нашёл двойное списание, но остановился на диагнозе без исправления, а ответ без навыка исправление дал. Единственное ложное срабатывание с навыком — запись в журнал внутри обработки ошибки объявлена нарушением, хотя статья именно её и предписывает.
Затем стандарт пошёл в бой. 21 сентября в проекте разработки появился анализатор кода, настроенный ровно по ключам из карточек. Первый прогон по трём расширениям: 167 замечаний за 15 секунд, из них по существу — одно, привилегированный режим в расширении для ЭДО, и у него есть карточка. Остальное — ожидаемый шум и оформление. А 22–23 сентября по этому циклу прошла первая боевая задача — расширение для зарплатной конфигурации: 1 511 строк отчёта, 380 сотрудников с детьми, 0 расхождений с независимым запросом.
Эпилог: чего стандарт не решает и как он живёт дальше
Урок этой истории прост: стандарт для ИИ — это не более короткий текст, а более проверяемый. И инструмент, которым проверяют ИИ, нужно проверять так же строго, как сам ИИ. Каждый раз, когда мы это забывали, линейка оказывалась кривой.
Чего редакция 3.1 не утверждает:
- Полная постатейная сверка всех 212 пересказов не заявлена; дата сверки стоит только в карточках.
- Контрольный прогон — одна попытка на сценарий, оценщик — та же модель, что писала навык; оценки проверяемы по сохранённым ответам, но независимой экспертизы не было.
- Код в сценариях не исполнялся в настоящей 1С; это отдельная проверка, и она идёт в проекте на тестовых базах.
- 12 правил из 33 никакой анализатор не ловит. Их проверяет только разбор кода — ИИ или человек.
Как стандарт живёт дальше. Раз в месяц и перед каждой крупной поставкой три команды спрашивают сайт: не изменились ли тексты проверенных статей, что нового в журнале изменений ИТС, целы ли материалы навыка. Изменилась статья — сверяем пункт, правим карточку, ставим новую дату и только потом принимаем новый текст как эталон.
В проекте по каждой задаче считаются четыре числа: доля находок ревью с названным пунктом стандарта; число ложных замечаний; число отступлений без причины; дефекты, найденные после поставки, с пометкой, ловил ли их стандарт в принципе. Через квартал эти четыре числа скажут о стандарте больше, чем любой самоотчёт — включая эту статью.