1С: один метод и AI пишет рабочий код - SDD в деле

Как заставить нейросети писать рабочий код на 1С? Промпты какие-то хитрые нужны. Может быть, магические слова, секретные заклинания. Сегодня поговорим про вещь, которая перевернёт твой подход к нейросетям в 1С, причём с ног на голову. Привет, жёлтый мир.

Существуют три основных метода улучшить работу с нейросетями для программирования. Первый — промтинг. Искусство правильно сформулировать запросы. Штука полезная, но ограниченная. Второй — банк. Банк памяти. Способ дать нейросети долговременный контекст, чтобы она не забывала, над чем мы работаем. Это такие файлы с описанием проекта, которые нейросеть подгружает в начале каждой сессии. И третий — Spec Driven Development (SDD). Разработка через спецификации. Самый мощный из трёх. Вот именно его, SDD, мы сегодня и разберём подробно с примерами, чтобы после этого ролика ты мог прийти и применить это на своей конфигурации.

Но прежде чем разбирать решение, давайте честно посмотрим на проблему без розовых очков. Как обычно действует юное дарование, которое натурально вчера узнало про нейросети и кодирование в 1С. Оно открывает чат с AI, пишет что-то вроде: "Сделаем обработку для загрузки товаров из Excel в 1С" и ждёт чудо. Сидит в монитор, смотрит, губы шевелятся. Нейросеть натурально выдаёт какой-то код. И юное дарование копирует его в конфигуратор. Запускает, не работает, пишет: "Не работает, исправь". Нейросеть исправляет, снова не работает, снова пишет. И так по кругу, высунув язык, бешено часами. Это, граждане, называется вайп-кодинг. Когда ты вибрируешь, а код не рождается. Звучит модно, а по факту — метод тыка. Обезьяна за пишущей машинкой. Только вместо Шекспира на выходе — адская портянка на 5.000 строк.

Давайте разберём, почему вайп-кодинг не работает для серьёзных задач в 1С. Первое и самое главное — контекстное окно. Что это такое? Контекстное окно — это объём информации, которое нейросеть способна держать в своей голове за один сеанс. Грубо говоря, её оперативная память, и она не резиновая, граждане. В продвинутых IDE, вроде Cursor, нейросеть уже знает структуру твоей конфигурации. Я об этом, кстати, рассказывал в одном из прошлых видео. Что такое Cursor, расскажу чуть позже. А сейчас про суть проблемы. Вот беда: на маленькой задаче написать одну обработку — всё прекрасно. А на большом проекте, где шаги состоят из 20-30 итераций, файлов десятки, сотни, а зависимости тысячи, нейросеть начинает забывать, что было на первом шаге. Путается, делает кучу лишних действий, натурально теряет нить. Причём, справедливости ради, современные агенты уже не такие тупые. Cursor и подобное IDE пытаются сами исправить свой код, пытаются найти зависимости в твоём большом проекте, найти правильные объекты, разобраться в структуре. Но как они это делают? Они начинают читать все файлы в твоей конфигурации, один за другим. Отправляют всё это на серверы нейросетям. Там всё это перемалывается, обрабатывается, анализируется. Нейросеть думает, думает, думает, и в итоге, может быть, даже приходит к правильному выводу. Но сколько времени на это уходит, сколько токенов сжигается? А токены — это, на минуточку, реальные деньги. Получается парадокс: нейросеть вроде бы умная, но работает непроизводительно, как экскаватор, который копает котлован чайной ложкой. Результат может быть и будет, но когда и за какую цену? Нам такой подход не подходит. Мы хотим предсказуемых, быстрых, экономичных результатов, а не нянчиться с нейросетью часами, высунув язык.

Второе. Код — это конечный продукт, а не отправная точка. И вот здесь кроется главная ловушка. На большом проекте нейросеть генерирует не 100 и не 500 строк, она генерирует 5.000 строк кода или больше в разных модулях, в разных файлах. Модуль формы, модуль объекта, общий модуль, модуль менеджера. Код размазан по всей конфигурации. И вот где-то в этих 5.000 строк сидит архитектурная ошибка. Например, найти её — уже задача на целый день, а исправить так, чтобы не сломать всё остальное — ещё день. А уже написанный код — это, граждане, как бетон. Застыл, ломай кувалдой. А вот спецификацию подправить — это дело 3 минут.

Что же делать? — спросите вы. Выбросить нейросети на помойку и кодить по старинке, как деды завещали. Как бы не так! Нейросеть — инструмент мощнейший, но любой инструмент без чертежа бесполезен. Дай обезьяне перфоратор, она просверлит себе ногу. Дай инженеру перфоратор и чертёж, он тебе возведёт стену. Нужен метод, инженерный подход. Конвейер, где каждый шаг контролируется, а нейросеть работает не как пьяная обезьяна с перфоратором, а как послушный исполнитель по чётким чертежам. Этот метод — SDD (Spec Driven Development), разработка через спецификацию.

Третьего дня один знакомый комрад, он, значит, на внедрении. Конфигурация большая, 1.000 объектов метаданных. Заказчик хочет доработку. Механизм резервирования товаров на складе слегка подправить. Комрад думает: "А дай-ка я сейчас нейросети скормлю задачку". Написал промт: "Реализуй механизм резервирования товаров так-то и так-то". Запустил. Нейросеть начала работать. Час работает. Два работает. Сгенерировала код в семи модулях, 3.000 строк. Комрад открывает, у него глаза на лоб. Нейросеть создала собственную систему резервирования с нуля. Новый регистр накопления, новый документ, новую подсистему. Хотя в конфигурации уже был встроенный типовой штатный механизм резервирования, работающий. Она просто не знала или забыла. 2 часа работы, куча токенов в мусорку. Комрад почесал затылок, сел и написал спецификацию. Три абзаца. В первом — контекст: "В конфигурации такой-то, такой-то существует штатный механизм резервирования". Во втором — что конкретно нужно доработать. В третьем — ограничение: "Не создавать новых объектов метаданных, использовать существующие регистры". Нейросеть прочитала спецификацию, поняла контекст и за 10 минут выдала ровно то, что нужно — доработку к существующему механизму, а не Франкенштейна с нуля. Вот это и есть разница между вайп-кодингом и SDD, между "сделай что-нибудь" и "вот тебе чертёж".

Суть проще пареной репы. Ты вообще не пишешь код совсем. Твоя задача — написать документ, спецификацию, настолько точную, настолько конкретную, чтобы нейросеть сама написала весь код за тебя от первой строки и до последней. В спецификации — что ты хочешь получить, зачем, какие ограничения, какие данные на входе, какой результат на выходе. Не код, а документ на человеческом языке в формате, например, Markdown. Это такой простой текстовый формат. Выглядит как обычный текст, только слегка структурированный. Если ты хоть раз писал текст со звёздочками и решёточками, ты уже практически знаешь Markdown. Нейросеть читает твою спецификацию и генерирует готовый код. Ты его проверяешь, и всё. Руками код не пишешь. Ты архитектор требований, а не кодер. Вместо "напиши мне что-нибудь", говоришь: "Вот тебе чертёж и исполняй". Как на заводе или как в армии, по-военному чётко.

Теперь разберём, как это работает на практике. Пошагово. И тут важный момент. Можно ли обеспечить весь этот процесс самостоятельно, без всяких инструментов? Ответ: да, можно. Ты сам можешь создать спецификацию, сам отдать её нейросети, сам провести нейросеть по шагам, обсудить план, потом пусть нейросеть этот план выполнит. Потом проверить результат, потом пусть заархивируют. Потом указать, в каких файлах что хранить. Всё руками, всё самостоятельно. Работать будет, будет. Но каждый раз ты будешь заново придумывать эти шаги. Каждый раз вспоминать: "А что идёт первым, а что вторым? А где я в прошлый раз хранил эти файлы? А как я назвал этот файл с требованиями?" А если ты работаешь в команде, это натурально хаос. Один коллега делает спеки так, другой — иначе. Третий вообще про них забывает. Смешались кони, люди, спецификации. Вот для этого и существуют готовые инструменты. Они берут на себя всю механику. Все шаги уже прописаны, все команды готовы. Тебе остаётся только пользоваться.

Для реализации SDD существует несколько таких основных инструментов. Самый известный — это OpenSPC. Больше 30.000 звёзд на GitHub. Это, на минуточку, один из самых популярных проектов в теме AI-разработки. Есть ещё SpecKit на GitHub, но он достаточно тяжеловесный, с жёсткими фазами. Есть также Kiro от Amazon, но он привязан к одной конкретной идее. Мы возьмём OpenSPC — самый доступный, самый гибкий и самый простой в освоении. OpenSPC — это лёгкий фреймворк, набор команд, скриптов, правил, который обеспечивает весь процесс Spec Driven Development. Открытый, бесплатный. Лицензия MIT. Работает с более чем двадцатью AI-инструментами, в том числе Cursor и наш любимый Claude-Code. Мы будем использовать его в связке с Cursor. И важный момент: философия OpenSPC — это гибкость. Это итеративность. Это не бюрократия, но и не водопадный хаос. Если кто-то понимает, о чём я говорю.

Для тех, кто не в курсе, напомню. Cursor — это IDE, среда разработки. По сути, это VS Code, только с нейросетью внутри. Ты в ней пишешь код, открываешь файлы, работаешь с терминалом, всё как обычно, как в VS Code. Но ещё у тебя к тому же появляется чат с нейросетевым ассистентом, который видит весь твой проект, читает твои файлы и может вносить изменения прямо в код. Вот в этой связке Cursor + OpenSPC и происходит вся магия. Про Cursor и как его внедрить в 1С-разработку я рассказывал в одном из предыдущих видео. Вы можете посмотреть его у меня на канале.

Что даёт OpenSPC? Он превращает работу со спецификациями в стандартный, понятный и ежедневный механизм. Внутри его команд уже зашиты все необходимые алгоритмы: создание спецификации, согласование требований, генерация задач, отправка в архив, изменение спецификации на любом этапе. Всё по шагам. Всё структурировано. Тебе не нужно каждый раз изобретать процесс заново. Не нужно обмениваться с нейросетью десятками файлов. Всё уже зашито в командах OpenSPC. И если ты работаешь в команде, это вообще спасение. Каждый разработчик следует одному и тому же процессу. Всем понятно, где лежит спецификация, где требования, где задачи. Не нужно спрашивать коллегу: "А ты какой метод спецификации применяешь?" Процесс становится единым, структура становится единой. Порядок — по-военному чёткий. А если ты работаешь один, тебе этот механизм экономит кучу времени. Стандартный процесс, к которому привыкаешь за один день. Открыл проект, дал команду — и поехал без танцев с бубном.

OpenSPC реализует SDD через цепочку документов. Четыре артефакта. Каждый вытекает из предыдущего, как ступени у ракеты. Управляется всё командами прямо в чате Cursor.

Ступень первая. Explore и Proposal. Исследование и предложения. Ты описываешь задачу по-человечески. Зачем мы это делаем? Какую проблему решаем? Что хотим получить в итоге? Например: "Нужно добавить табличную часть "Прошлые места работы" в справочник "Сотрудники". Реквизиты: организация, дата начала, дата окончания, должность. Вывести всё на форму. Проверить, что дата окончания позже даты начала". OpenSPC создаёт отдельную папку для этой задачи и генерирует документ "Предложение". Нейросеть формализует твои слова в структурированный текст. Ты проверяешь, правильно ли она поняла задачу. Если нет, поправляешь на уровне текста, а не на уровне кода. Поправить предложение — 3 минуты. Поправить 500 строк XML — 3 часа. И это, если повезёт. Почувствуйте разницу, граждане.

Ступень вторая. Specs — спецификации. Здесь уже детали. Инженерная, конкретная. Организация — строка или справочник. Дата начала — дата. Дата окончания — дата. А дата со временем или без? Ограничение: "Дата окончания строго больше даты начала". А если поле пустое? А если дата в прошлом веке, что делаем? Всё это фиксируется в документе Specs.md. Чёрным по белому. И нейросеть его тоже генерирует на основе предложения, а ты верифицируешь. Не наоборот. Ты — генерал, она — штабной писарь. Зачем это нужно? Затем, что на этом этапе ты ловишь ошибки в постановке задачи ещё до того, как кто-то написал хоть одну строчку кода. Ещё до того, как тронул конфигурацию. Дёшево, безопасно и быстро.

Ступень третья. Design, архитектура. А вот здесь начинается самое интересное. И здесь нужно понять один принцип. Для работы с SDD конфигурация 1С должна быть выгружена в файлы. Через конфигуратор выгрузить конфигурацию в файлы. На выходе получается дерево папок и файлов. XML-файлы с описанием метаданных — это структура справочников и тому подобное. И есть ещё BSL-файлы с кодами модулей. Вот с этими всеми файлами и работает наш Cursor. А после всех изменений он загружает всё обратно в конфигуратор. Так вот, на этапе архитектурного дизайна нейросеть расписывает, какие конкретно файлы она собирается трогать. Например, будет изменён файл "Сотрудник.xml". Это описание нашей формы справочника. Внутрь узла будет добавлена, например, новая табличная часть. И это всё ещё до того, как нейросеть прикоснулась к твоим файлам. Она составила план операции, а ты, как генерал, этот план должен утвердить или отправить на доработку. И вот здесь ты ловишь ошибки, которые при вайп-кодинге обнаружились бы только через неделю. Всё на ладони, как рентгеновский снимок. Ошибки будут видны ещё до того, как они станут готовым кодом. И токены не будут потрачены зря.

Ступень четвёртая. Tasks — задачи. Из дизайна генерируется чек-лист. Конкретные атомарные шаги с галочками. FileTasks.md: изменить файл, добавить узел табличной части — галочка, добавить четыре реквизита — галочка и так далее. Провести проверку XML — галочка. И только после этого ты даёшь команду Apply. Выполняй, значит. И уже дальше можно пойти отдыхать и заняться, например, другой задачей. Нейросеть будет сама писать код, пока не напишет, а по окончании подаст сигнал о готовности. Таким образом, можно работать сразу над несколькими задачками, и продуктивность программиста вырастает прямо в разы. Нейросеть открывает файлы, вносит изменения строго по чек-листу и отмечает выполненные пункты. Никакой отсебятины, никаких сюрпризов. Контролируемый, управляемый процесс. А когда задача закрыта — команда Archive. Все документы, планирования и работы уходят, так сказать, в архив. Рабочее пространство становится снова чистым, и контекст нейросети будет готов для следующей новой задачи. Гигиена, порядок.

Давайте подведём промежуточный итог. Вся цепочка выглядит так:

1. **Предложение**: описали задачу.

2. **Спецификация**: уточнили детали.

3. **Дизайн**: согласовали архитектуру.

4. **Задачи**: разбили на шаги.

5. **Выполнение**: нейросеть пишет код.

6. **Архивирование**: убрали всё за собой.

На каждом этапе — контроль. На каждом этапе ты решаешь, двигаемся дальше или возвращаемся. Нейросеть не делает ни одного шага без твоего одобрения. Это не вайп-кодинг, это инженерия.

Также ещё давайте заглянем на GitHub, с которого вы будете скачивать этот OpenSPC, этот фреймворк. На GitHub здесь очень много документации к этому фреймворку. Здесь уже 33.000 звёзд. Это очень популярный фреймворк. Вы можете тут также посмотреть, например, сразу README и посмотреть, каким способом нужно применять этот фреймворк в своей работе. Описано очень подробно. Если зайти в "Get Started", где как начать, описывается. Далее у вас может возникнуть желание вмешиваться в работу этого фреймворка. Тогда вам понадобятся расширенные команды, которые там уже устанавливаются. И также вам ничего не мешает использовать какие-то промежуточные способы, например, не использовать "continue", не использовать "FF" или не использовать "verify". То есть здесь всё уже в ваших руках настроено. Этот фреймворк очень гибко работает, в отличие от других фреймворков, в которых нужно прямо жёстко соблюдать последовательность действий. Ну, конечно, здесь определённая последовательность тоже есть. Например, с архива начинать вы не будете, а начинать вы будете, скорее всего, либо с Explorer, то есть исследования, либо с Prose, то есть что вы уже хотите точно сделать, либо с New. Также помним, что здесь в результате работы этого фреймворка создаются дополнительные файлы, дополнительные директории. Это и есть та самая автоматизация, [откашливается] которая позволяет вам избежать всякой рутины, потому что всё это, вы, напомню, можете сделать вручную. Для этого не нужны никакие скрипты, никакие OpenSPC, никакие фреймворки. Что такое фреймворк — это, грубо говоря, библиотека стандартных подсистем в 1С. А здесь OpenSPC — это та же библиотека подсистем, но для работы со спецификациями. Здесь уже все команды прописаны друг за другом. И там есть специальные скрипты, которые работают за вас, создают каталоги, создают файлы, общаются с нейросетью с помощью специальных скриптов, с помощью специальных промптов, которые уже там зашиты внутри этого фреймворка. Вам уже не надо копипастить это всё и какие-то большие промпты постоянно где-то у вас хранить, упоминать, обмениваться с коллегами. Вы просто устанавливаете вот этот один фреймворк, и у вас всё начинает относительно стандартно работать. Дальше вы уже этот фреймворк можете как-то подогнать под себя. Какие команды вам больше подходят, это вы уже определите в процессе своей работы. Также ещё зависит всё от того, как у вас всё устроено в бизнесе, который вы обслуживаете. Если у вас какая-то, не знаю, крупная корпорация, в которой вы работаете, у вас будет один путь работы с этим фреймворком. А если у вас какая-то сеть розничных магазинов, то у вас, скорее всего, будет какой-то другой цикл разработки на этом OpenSPC. Так что пробуйте, начинайте. Желаю вам удачи на этом прекрасном жёлтом пути.

Теперь давайте запомним основные команды OpenSPC. Их всего четыре. Основные четыре команды — и весь ежедневный рабочий процесс в кармане.

1. **Explorer**. Разведка. Используешь, когда требования ещё не ясны, и ты обсуждаешь идею с нейросетью. Исследуешь проект, сравниваешь подходы. Ничего не создаётся, просто разговор с нейросетью. Она может заглянуть в файлы конфигурации, проанализировать структуру и помочь определиться с направлением. А когда картинка прояснилась, переходишь к следующей команде.

2. **Propose**. Главная рабочая лошадка. Одна команда — и OpenSPC создаёт папку изменения и генерирует все четыре документа: предложение, спецификацию, архитектуру, задачи. Ты затем проверяешь и при необходимости исправляешь. И всё готово к выполнению.

3. **Apply**. Выполняй, так сказать. Нейросеть берёт утверждённый чек-лист задач и начинает вносить изменения в файлы проекта. Строго по плану, ни шага в сторону.

4. **Archive**. Уборка, так сказать. Задача закрыта. Все документы уходят в архив. Рабочее пространство чистое. Контекст нейросети свободен. Готов к следующей задаче.

Цикл простой: Explore, Propose, Apply, Archive. Повторяй для каждой задачи, как отче наш. Кстати, небольшой нюанс: в Cursor команды пишутся через дефис, а не как в инструкции, через двоеточия. Мелочь, но важно знать, чтобы не споткнуться. Есть и расширенные команды, так сказать, для ручной настройки, для пошагового создания артефактов, проверки и синхронизации. Но для начала работы хватит этих четырёх более чем. Также все материалы из видео вы сможете скачать у меня на канале по ссылке в описании бесплатно.

Итак, я открыл нашу каркасную конфигурацию, с которой мы уже однажды работали в прошлых видео. Эта каркасная конфигурация скачивается с сайта 1С и предназначена для того, чтобы тренироваться на ней в сдаче сертификационных разных задачек. Ну, я же буду её использовать для изучения OpenSPC. OpenSPC у меня скачан, установлен. Как его установить? Я дам вам ссылку на сайт, там есть инструкции. В моём канале всё очень просто. Если не получится установить, спрашивайте опять же внутри вашей IDE, в Cursor, например, он вам поможет, даже сам может установить вам OpenSPC. В общем, глобально. Но потом в каждом проекте нужно его отдельно инициализировать, что представляется логичным, потому что вы можете в каких-то проектах захотеть его использовать, а в некоторых — не захотите использовать. Здесь мы его сейчас инициализируем. Вот он говорит: "Нам нужно выбрать, для каких моделей я хочу его инициализировать". Здесь вот с помощью стрелочек вверх-вниз и с помощью пробела. Вот мне нужен Cursor, мне нужен Claude-Code на всякий случай. И нажимаем Enter. Всё готово. Нужно перезапустить окно с моим проектом, чтобы изменения применились. Я перезапустил Cursor. Это закроем терминал, он нам не нужен. Дальше будем работать, как обычно, в агентском чате. Давайте глянем, что у нас тут новенького появилось. Вот у нас появился каталог OpenSPC. Как мы видим, в нём содержатся какие-то файлы. И сюда же будут потом помещаться ещё файлы, которые будут в процессе работы OpenSPC создаваться. Также, если открыть "Skills" в Cursor, мы увидим, что добавились новые скилы. Если открыть "Rules", правил новых не появилось. Если открыть "Commands", вот эти команды, которые добавил OpenSPC. Я добавил расширенных немного команд, потому что изначально, если вы установите OpenSPC, там будет только набор базовых команд. Я добавил ещё несколько расширенных, чтобы вам продемонстрировать, что вообще можно тут делать.

Итак, мы начнём с онбординга. И я советую всем тем, кто впервые сталкивается с OpenSPC и вообще со спецификациями, которые применяются в нейросетях, в разработке программ, в разработке 1С, использовать вот OpenSPC, вот эту команду, которая называется "Onboard". Давайте посмотрим, что там внутри. То есть по сути это какой-то набор команд, набор инструкций для нейросети. По сути, вот они какие-то вот большие, большой, большой файл из себя представляют. Как вводить команду? Мы открываем агентский чат и вводим него через косую. Пишем `/OpenSPC onboard`. Ждём, что он скажет. Вот здесь он будет думать. На самом деле, он вряд ли что-то здесь нам предложит из каких-то доработок полезных. Но тем не менее, он здесь проведёт нас по шагам. И каждый шаг он объяснит нам с точки зрения методологии OpenSPC, то есть как он работает, какие команды в нём существуют и в какой последовательности мы должны работать. Так сказать, он выступит для нас неким учителем, коучем, наставником. Вот, пожалуйста, он поддерживает русский язык автоматически и говорит: "Я вас проведу через полный цикл изменения от ID до реализации". Вот, выберем небольшую задачу, исследуем проблему, создадим change, построим артефакты, реализуем задачи, заархивируем ченджи. Итого, говорит, у вас всё займёт минут 15-20. Вот дальше он пишет, что он собирается просканировать кодовую базу на предмет небольших возможных улучшений. Ну, посмотрим, что он предложит. На самом деле, я здесь уже делал задачу по разработке печатной формы, и это была успешная задача. Мы всё сделали с одного большого промта с применением дополнительных скилов. Ага. Вот он предлагает сделать рефакторинг дублирования, реализовать команду печати, кстати, предлагает. То есть мы сейчас, я ещё напомню, что мы находимся в режиме онбординга. Здесь мы практически должны следовать указаниям нашего вот этого фреймворка, который называется OpenSPC, и просто по шагам он нас поведёт для по решению этой задачи. Это будет один из ваших путей. Вы можете, в принципе, всегда работать в режиме онбординга. Вам никто не мешает это делать. Просто это в последующем, когда вы уже окончательно освоитесь, вам это будет не нужно, вы будете знать уже точно, какие команды когда нажимать. Но мы с вами вот пойдём первым путём — онбордингом. Мы предложим задачу номер два: "Реализация команды печати для приходной накладной". Посмотрим, что скажет дальше нам наш фреймворк. Дальше он планирует следующие шаги. Перед тем, как создать команду change, он предлагает произвести демонстрацию Explorer mod, то есть исследовать проблему перед тем, как приступить к работе. Эксплорер вы будете заниматься регулярно в OpenSPC, потому что, скорее всего, все задачи потребуют эксплор, какого-то обсуждения исследовательского предварительно. Даже если вы знаете, что и как нужно сделать, никогда не будет лишним поговорить с нейросетью, обсудить с ней возможные ваши варианты, которые вы уже собираетесь делать. Скорее всего, она увидит какие-то недостатки в вашем решении и предложит какие-то улучшения. Вот. Вот он пишет, что он выяснил про эту накладную, что в шапке, что в табличной части, что содержится в макете. Он говорит, что макет уже создан, но код его не использует. На самом деле, макет создан, но в нём пусто в этом макете. Дальше он пишет, что есть некая обработка, которая "тестраннер", и есть команда печати. Предлагает двигаться дальше. Ну, давайте двигаться дальше. Здесь, если у него такие же умственные способности, как в прошлый раз, то не получится у него сделать макет. Скорее всего, придётся реализовывать эту печатную форму программным способом, как и было в моём видео в прошлом сделано. Вот он объясняет, что такое change, что такое proposal, какие предполагаются изменения, зачем, какие новые возможности будут, что будет изменено в процессе наших вот этих ченджей. То есть он говорит, что у него есть предложение. Вот он объясняет, что такое предложение и что такое. Это я нахожусь, напомню, что я нахожусь в режиме онбординга. И если бы я не был в этом режиме, мне бы пришлось самому делать вот этот proposal. Он говорит, что создано у нас изменение "print_invoice". Давайте посмотрим, где он у нас создан. Вот под change у нас тут есть, появилась новая папка "print_invoice" и в нём появилась "OpenSPC.yaml". Предлагает добавить в модуль менеджера новую процедуру печати, предлагает добавить в команду "печать" реализацию обработчика команды. Да, что-то тут с "тестраннер" предлагает сделать. Я предлагаю ему этим не заниматься. Я предлагаю отказаться от изменения в "тестраннер" и не использовать его. Ну, давайте об этом так и скажем нейросети: "Не используя логику тестраннера, всю логику печати нужно реализовать в модуле команды и в модуле менеджера. Также всю реализацию печатной формы и формирование табличного документа нужно сделать программно, без использования макета". Я сразу дам подсказку нейросети, чтобы она не мучилась там с формированием макетов, потому что в прошлый раз у неё ничего не получилось. И скорее всего, в этот раз не получится, потому что я не использую MCP-серверы и прочие подсказки. Ну, всё поняла. О'кей, сохраняю. Переходим к спецификациям, да? О'кей, да. Далее он пишет: "Спецификация — это отдельный у нас документ". Здесь он объясняет, что такое спецификация. "Specs определяет то, что мы строим в точных, тестируемых терминах". По сути, спецификация — это есть основной документ, результат работы этого фреймворка. Вот здесь появился документ "Spec.md", созданный этим фреймворком. Вот такой большой кусок текста здесь находится. Ну, на особом языке описывается здесь сценарии, когда, зачем и так далее. Можете сами попробовать поэкспериментировать, то, что там в итоге получится интересное. Далее у него идёт "Design" — это проектирование архитектуры. Здесь, здесь он пишет, что "Design". "Мы фиксируем, как мы это строим. Различные технические решения, компромиссы, подходы". Вот на английском языке это называется "design". Ну, в 1С нет такого понимания "дизайн". Мы действительно, ну, больше как проектированием занимаемся или больше как-то архитектурой мы это ещё называем. Всё о'кей. Какие задачи предполагается сделать? Здесь уже прямо чек-лист, последовательность действий. Я сейчас даже не буду особо вникать. Так, на первый взгляд кажется, что да, действительно, чек-лист похож на то, что нужно сделать. На самом деле, для такой простой задачи, может быть, даже не понадобился бы нам с вами OpenSPC. Ну, слишком уж она простая. И как мы видели в прошлом моём ролике, я добился результатов с помощью одного большого промта, который вы тоже можете увидеть на моём канале и в прошлом видео. Я просто дал один большой промт, величиной он, наверное, там, ну, в 50 строк. И после этого Cursor с помощью GPT-4.6 от нуля и до конца, до 100% всё сделал самостоятельно. Я демонстрирую здесь в образовательных, так сказать, целях. "Готовы, говорит, приступить к имплементации?" Ну, о'кей, да, я готов. Да, начинаем. Ну, тут обратите внимание, ещё я использую голосовой ввод, встроенный в сам IT Cursor, и он сразу переводит всё на английский язык. Это очень удобно, потому что на английском языке токенов тратятся иногда в среднем до 50% меньше. Я дал команду начать. Ну, давайте посмотрим, чем всё закончится, да. Далее я перемотаю на результаты и подожду, пока всё закончится, и уже продемонстрирую вам, чем всё закончилось в этом этапе, чтобы не слишком сильно не удлинять это видео.

Что ж, прошло 10 минут, он говорит, что всё готово. "Implementation complete". Создал какие-то процедуры, отписался, что сделано, и сразу предлагает заархивировать всё. И сразу же сам заархивировал. То есть это последний этап разработки через OpenSPC — это архивация проекта. Давайте посмотрим, что у нас тут изменилось в списке файлов. Вот тут есть OpenSPC, появился новый каталог под названием "archive". И у архива есть дата. То есть получается, три подкаталога было создано: "changes", "archive" и дата. И дальше название нашего проекта "print_invoice". Говорит, что вот вы только что прошли полный цикл OpenSPC, мы с вами прошли онбординг, и я рекомендую вам начать тоже с онбординга. Дальше он напоминает, какие существуют команды. Дальше он предлагает самостоятельно попробовать его применить. На самом деле, существует несколько цепочек для работы с этим фреймворком. То есть первое — это онбординг. Можете, в принципе, каждый раз пользоваться онбордингом. А второй цикл начинается с proposal. То есть мы что-то там делаем уже сразу, то, что знаем. А можете начать с Explorer, то есть тогда фреймворк подумает, посмотрит ваш код. Но если база данных очень большая, то Explorer может надолго задуматься, много потратить токенов, сделать вам очень-очень много предложений, что, наверное, для больших проектов не является рациональным методом. Также интересная команда "Verify". Это относится к циклу, когда вы вносите какие-то изменения, фреймворк, OpenSPC делает это на основании уже созданной спецификации. И после этого вы запускаете "verify", чтобы проверить результаты работы с исходной задачей, тем спецификациям, исходным задачам, которые были изначально поставлены. Далее я загрузил все полученные файлы в каркасную конфигурацию. И действительно, здесь создан уже программный код, есть функция печати документа. Давайте откроем и проверим, всё ли у нас правильно работает. Тем не менее, в основном с написанием кода OpenSPC справился. И на этом мы наш этап изучения практического применения OpenSPC заканчиваем. Желаю вам удачи в изучении, в самостоятельном, этого замечательного, интересного фреймворка. Со спецификациями разработка у вас пойдёт намного более продуктивно. Но помните, что всё-таки использование этого фреймворка и спецификации, оно предназначено для более крупных, комплексных задач.

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

1. **Spec First**. Сначала спецификация, а потом код. Никаких "напиши мне быстренько". Сначала документ. Proposal, Specs, Design, Tasks — чем конкретнее спецификация, тем точнее результат.

2. **Context**. Нейросеть должна видеть твою конфигурацию: какие объекты существуют, какие реквизиты заняты, какая структура метаданных. В Cursor это решается через выгрузку конфигурации в файлы, а также через MCP-серверы. Но это тема отдельного разговора. Главное: без контекста нейросеть — как слепой крот. Роет, но куда — неизвестно.

3. **Fix Spec, Not Code**. Результат не устраивает? Не лезь в сгенерированный код руками. Вернись в спецификацию. Уточни требования. Перегенерируй. Код — расходный материал. Спецификация — это единственный источник правды. Поменял спеку — получил новый код. Быстро, чисто, без костылей.

4. **Incrementality**. Не пытайся за один заход переписать всю конфигурацию. Маленькие шаги: одна задача, одна спецификация, один результат. Сначала добавь справочники, потом документ, потом печатную форму. От простого к сложному. По-военному чётко, последовательно.

Теперь самое важное. Как начать? Конкретный план действий:

1. Устанавливаешь Cursor. Скачиваешь с официального сайта, ставишь как обычную программу. Если умеешь пользоваться VS Code, то освоишь за 5 минут. Там всё то же самое.

2. Устанавливаешь в него OpenSPC. Понадобится Node.js версии двадцатой или выше. Потом в терминале две команды — это установка и OpenSPC в папке проекта инициализация. Вот и всё. Ссылку на источники GitHub оставлю в описании к видео.

3. Выгружаешь свою конфигурацию 1С в файлы, получаешь дерево папок. Это и будет твой проект в Cursor.

4. Открываешь эту папку в Cursor. Пишешь в чат команду OpenSPC и далее описываешь свою задачу. OpenSPC создаёт папку, генерирует документы, планирует. Ты проверяешь, корректируешь, утверждаешь.

5. Когда всё согласовано, даёшь команду Apply. Нейросеть вносит изменения в файлы.

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

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

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

Ссылку на все ресурсы оставлю в описании на моём канале. А на сегодня всё. С вами был Алексей Лопицкий. Подписывайтесь на канал, ставьте лайки. До новых встреч.