Слои знаний · 9 мин
Библиотека и контекст проекта: две разные системы координат
Что относится к общей библиотеке, а что доказывается конкретным проектом.
Один и тот же вопрос о коде почти всегда состоит из двух разных вопросов. Первый — как вообще разрешено решать такую задачу. Второй — как она решена именно в этой конфигурации. Если смешать ответы, общее правило легко принять за факт проекта, а случайно найденный фрагмент — за правильный способ.
Ниже дан синтетический проектный сценарий; он не входит в публичный демонабор. В открытом упражнении можно проверить библиотечное правило, но нельзя найти вызывающие процедуры своей конфигурации или выполнить её код.
01 · Разделение
Две системы координат
Допустим, агенту нужно изменить отправку статуса заказа во внешний сервис. В описании формата сказано, какие поля обязательны и какие значения статуса допустимы. Но это описание не знает, в каком общем модуле вашей конфигурации формируется пакет и откуда вызывается отправка.
Исходники проекта отвечают на второй вопрос: где находится функция, какие процедуры её вызывают, от каких метаданных и настроек она зависит. Но один только исходный код не доказывает, что используемый формат всё ещё поддерживается внешней системой. Для полного ответа нужны оба слоя.
Библиотечный корпус
- форматы данных и правила вызова;
- версии и режимы совместимости;
- возможности платформы 1С;
- стандарты и известные ошибки.
Конкретный проект
- общие модули и их функции;
- вызывающие процедуры;
- метаданные и настройки;
- реальные зависимости кода.
Точный источник · проверка синтаксиса · тест · выполнение кода
Ни один слой не заменяет другой: библиотека не угадывает устройство проекта, а проект не назначает общие правила внешней системы.
02 · Маршрутизация вопроса
Какому источнику задавать вопрос
Ошибка часто возникает раньше поиска — в тот момент, когда вопрос задан не тому источнику. Простое разделение экономит попытки и не позволяет агенту достраивать отсутствующий слой.
Практический запрос агенту: «Для синтетического формата 2.0 назови допустимые значения status и обязательность changedAt со ссылкой на правило. Отдельно перечисли, какие места вызова можно установить только по исходникам проекта». Ответ по демонабору должен остановиться на первом пункте; список реальных модулей без проектного снимка был бы догадкой.
Версионированное описание формата.
Найденная функция и точный фрагмент исходного кода.
Вызывающие процедуры, метаданные и настройки.
Проверка синтаксиса, тест и результат выполнения.
03 · Сквозной разбор
Синтетический примерПерейти на новый формат статуса доставки
Все имена, версии, поля и результаты вымышлены. Пример показывает разделение источников и не описывает реальную конфигурацию или сервис.
«Сервис доставки переходит на формат 2.0. Нужно заменить статусreadyнаprepared, добавить время изменения и определить все места проекта, которые затронет доработка».
Правило формата 2.0
- поле
statusпринимаетcreated,preparedилиshipped; - поле
changedAtобязательно; - старое значение
readyбольше не допускается; - описание относится только к синтетической версии 2.0.
Где формируется и отправляется пакет
- функция
ОбменДоставкойСервер.ПодготовитьСтатус()собирает данные; - её вызывает обработка проведения заказа;
- повторную отправку выполняет регламентное задание;
- версия формата читается из настройки проекта.
Места правки, ограничения и обязательные проверки.
04 · Ошибки границы
Где возникает подмена
Пример принят за факт проекта
Процедура из библиотечного примера названа существующей, хотя поиск по конфигурации её не подтвердил.
Найденный код принят за правило
Старое значение существует в проекте, поэтому агент объявляет его допустимым во внешнем формате.
Похожее принято за точное
Смысловой поиск находит близкий фрагмент, но версия и точное место использования не проверяются.
План выдан за результат
Агент описал правильные проверки, но не сообщил, какие из них действительно выполнены.
05 · Форма ответа
Доказанный ответ сохраняет происхождение каждого факта
- 01
Сформулировать задачу и назвать целевую версию.
- 02
Получить общее правило из библиотечного корпуса.
- 03
Найти реальные процедуры, функции и связи проекта.
- 04
Сослаться на точные фрагменты для каждого утверждения.
- 05
Отдельно перечислить выполненные и ещё не выполненные проверки.
Что разрешено.
Как сделано здесь.
На что ссылаемся.
Что действительно выполнено.
Если звено отсутствует, ответ не маскирует пробел: он называет его неизвестным или следующим действием.
06 · Вывод
Два слоя дают агенту точность без лишней уверенности
Библиотечные знания делают правила повторяемыми. Контекст проекта не даёт применить их к вымышленной структуре. Проверка показывает, где закончился план и начался подтверждённый результат. Вместе эти слои сокращают поиск, но сохраняют ответственность разработчика за принятое изменение.
общее правило + факт проекта + проверка