Логопедия больших языковых моделей

30.03.26

Интеграция - Нейросети

+11 –1
> >
  • diagram (3).jpg
  • diagram (4).jpg
  • diagram (5).jpg
Изучим открытый стандарт Agent Skills (Anthropic). Рассмотрим способы диагностики и коррекции ошибок модели. Разберемся, как получить понятный и полезный инженерный инструмент с предсказуемым результатом. В основе подхода — логопедическая метафора: LLM демонстрирует те же речевые нарушения, что и дети с расстройствами речи. Если вы ищете готовые рецепты без погружения в природу ошибок, материал покажется избыточным.

Содержание

Глава 1. Инструмент Skill Creator — как Anthropic построил встроенный навык для создания других навыков: полный цикл от замысла до упаковки, структура SKILL.md, техническое устройство скиллов и что мы можем позаимствовать для Chunk Advisor v3.
Глава 2. Agent Skills — открытый индустриальный стандарт для навыков ИИ-агентов: базовая структура, принцип прогрессивного раскрытия (трёхуровневая загрузка), связь с логопедической моделью и преимущества стандарта.
Глава 3. Создание новых навыков в процессе логопедической коррекции — почему LLM подобна ребёнку с нарушением речи: гнозис (узнавание), праксис (действие), просодика (иерархия важности), диагностическая цепочка, требования к связности и цельности чанка v3, а также феномен «промпт-амавроза» — почему модель игнорирует явные требования.
Глава 4. Мета-модель терапии LLM — как обучать LLM через многократное «проживание» паттернов: принципы повторения и вариативности, механизм обратной связи через антипримеры, 6 терапевтических модулей (М0–М5) и протокол сеанса.
Глава 5. Терапевтические модули — детальное описание шести модулей коррекции: от Базиса (0 галлюцинаций) до Связности (декомпозиция задач). Два способа применения: точечная и системная коррекция. Упражнения, критерии завершения и метрики успеха для каждого модуля.
Глава 6. Применяем логопедическую коррекцию в системе с обратной связью — эволюция чанков от v1 к v3 на реальном примере 1С-разработки, формат терапевтического чанка (JSON-схема), протокол сеанса терапии (разминка → упражнение → проверка → коррекция → закрепление) и метрики прогресса.
Глава 7. Интеграция с Chunk Advisor v3 — терапевтический режим --therapy-wizard, хранение прогресса в SQLite, логика выбора и перехода между упражнениями, следующий горизонт — векторная база знаний (эмбеддинги + семантический поиск) и итоговая архитектура инструмента.
Глава 8. Проект технического задания Chunk Advisor v3 — полное ТЗ для реализации: назначение и цели, функциональные требования (режимы работы, диагностика, терапевтические модули, протокол сеанса, SQLite, создание навыков, оценка навыков), нефункциональные требования, архитектурные решения, этапы разработки, критерии приемки, риски, открытые вопросы и сводный чек-лист лучших практик создания навыков.

Я уже закончил статью, и вдруг ChatGPT добавил эпиграф. 


12 фундаментальных законов промптинга

(синтез Anthropic, OpenAI, DeepMind и практики агентных систем)

1. Закон цели (Goal First)

Модель должна сначала понять результат, а потом контекст.

LLM распределяет внимание вокруг целевого объекта генерации.
Если цель появляется в конце — контекст уже интерпретирован неправильно. Слабый промпт: Я работаю в SaaS компании... у нас клиенты... Напиши письмо клиенту.

Сильный промпт: Напиши письмо клиенту с извинением за задержку.

Контекст: SaaS продукт, задержка 3 дня.

В Chunk v3: activation.description = цель → симптомы

2. Закон структуры (Structure Mirrors Output)

Форма запроса определяет форму ответа.

LLM зеркалит структуру входа.

Если промпт — хаотичный текст
→ ответ будет хаотичным.

Если промпт — структура
→ ответ будет структурирован.

Пример Слабый: Напиши анализ рынка

Сильный: Сделай анализ в 3 разделах:

1. Размер рынка. 2. Основные игроки. 3. Риски

3. Закон негативного сигнала (Anti-Example Law)

Модель лучше понимает запрет через антипример, чем через абстрактное правило.

Это подтверждается практикой Claude skills.

Слабый сигнал: Не используй маркетинговый язык

Сильный сигнал: Не пиши так: "Инновационное революционное решение..." Пиши так: "Инструмент помогает малому бизнесу..."

4. Закон конкретности (Specificity Beats Abstraction)

Чем конкретнее инструкции — тем меньше галлюцинаций.

LLM плохо интерпретирует абстракции.

Плохо:  Напиши профессионально

Хорошо: Стиль: деловой. Тон: нейтральный. Длина предложений: 10–15 слов.

5. Закон ограничений (Constraints Dominate Preferences)

Ограничения влияют сильнее, чем пожелания.

LLM оптимизирует вероятность.
Чёткие границы резко сокращают пространство решений.

Пожелание: Пиши кратко. Ограничение: Не более 5 предложений.

6. Закон одной задачи (Single Task Law)

Один промпт — одна когнитивная операция.

Когда в промпте несколько задач: "написать → проанализировать → перевести", тогда качество каждой падает.

Правильная архитектура: 

Prompt 1 → генерация
Prompt 2 → редактирование
Prompt 3 → перевод

Это фундамент агентных пайплайнов.

7. Закон рассуждения (Reasoning Before Answer)

Качество ответа повышается, если модель сначала объясняет логику.

Эта практика активно используется в исследованиях reasoning.

Пример: Сначала объясни своё рассуждение. Затем дай окончательный ответ. Это снижает вероятность ошибок.

8. Закон примеров (Few-Shot Learning)

Пример работает лучше инструкции.

LLM обучались на pattern completion.

Поэтому: пример → пример → пример сильнее, чем: объяснение → объяснение.

9. Закон активации знаний (Just-in-Time Knowledge)

LLM лучше работает с информацией, полученной непосредственно перед задачей.

Это ключевой принцип skills Claude.

Модель:

  1. получает задачу
  2. читает инструкцию
  3. применяет её

Поэтому: prompt + context + skill работает лучше, чем просто prompt.

10. Закон минимализма (Prompt Entropy Law)

Каждое лишнее слово снижает точность.

LLM распределяет внимание по всему контексту.

Если промпт перегружен: важные сигналы теряются

Поэтому Anthropic рекомендует: Keep the prompt lean.

11. Закон повторяющихся паттернов (Pattern Extraction)

Если несколько задач требуют одного и того же решения
→ это новый навык. Это прямой принцип Agent Skills.

Пример: 5 агентов написали create_docx.py

→ нужно создать skill docx

12. Закон диагностической цепочки

Это уже ваш вклад — и он реально сильный.

LLM лучше применяет правила, если понимает:

симптом → диагностика → причина → решение

В вашей модели: 
symptom diagnosis conclusion explanation recommendation

Это фактически reasoning scaffold.

Итоговая модель (12 законов)

№ Закон Суть
1 Goal First Сначала результат
2 Structure Mirrors Output Структура запроса = структура ответа
3 Anti-Example Антипример сильнее запрета
4 Specificity Конкретика лучше абстракции
5 Constraints Ограничения сильнее пожеланий
6 Single Task Один промпт — одна задача
7 Reasoning Сначала логика, потом ответ
8 Examples Примеры > объяснения
9 Just-in-Time Knowledge Инструкции перед задачей
10 Prompt Minimalism Лишние слова вредят
11 Pattern Extraction Повтор → новый навык
12 Diagnostic Chain Симптом → причина → решение

Промптинг — это не написание текста.
Это проектирование когнитивного процесса модели. По сути вы строите когнитивный пайплайн а не просто инструкцию.

Глава 1. Инструмент Skill Creator

Skill Creator — встроенный навык в Claude Code от Anthropic, который помогает создавать другие навыки. Он реализует полный цикл: пользователь описывает, что должен уметь навык, Skill Creator задаёт уточняющие вопросы, пишет черновик SKILL.md, создаёт тестовые сценарии, запускает оценки, сравнивает версии и улучшает навык на основе обратной связи. Официальный плагин доступен в открытом репозитории Anthropic.

📦 Инструмент доступен в открытом репозитории на GitHub.
https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md

1.1. Skill Creator: как Anthropic строит скиллы

В основе логопедического подхода к чанкам лежит технология, реализованная Anthropic в Skill Creator — встроенном инструменте Claude Code для создания, тестирования и улучшения навыков.

Цикл создания скилла в Claude

  • Замысел: пользователь описывает, что должен уметь навык.
  • Интервью: Skill Creator задаёт уточняющие вопросы о граничных случаях, форматах, зависимостях.
  • Черновик: пишется SKILL.md с YAML-шапкой (name, description) и инструкциями.
  • Тестирование: запускаются тестовые промпты — одновременно с навыком и без него (базовая линия).
  • Оценка: качественные результаты показываются пользователю, количественные метрики агрегируются в бенчмарк.
  • Улучшение: на основе обратной связи навык переписывается, ошибки исправляются, инструкции уточняются.

Структура скилла (анатомия навыка)

skill-name/
SKILL.md # Обязательный: YAML-шапка + Markdown-инструкции
scripts/ # Исполняемый код для повторяющихся задач
references/ # Документация, подгружаемая по необходимости
assets/ # Шаблоны, иконки, файлы для вывода

Структура файла SKILL.md

Каждый SKILL.md состоит из двух частей. Первая — YAML-шапка (frontmatter) в самом начале файла:

---
name: docx
description: "Use this skill whenever the user wants to create..."
license: Proprietary
---

Поле description — ключевое. Именно его Claude читает при каждом запросе, чтобы решить: подходит ли этот скилл для текущей задачи. Это своего рода «триггер» активации.

Вторая часть — сам контент: детальные инструкции, примеры кода, bash-команды, предупреждения и список критических правил. Например, скилл docx содержит конкретные JavaScript-сниппеты для npm-библиотеки docx, XML-паттерны для ручного редактирования файлов и жёсткий список того, что делать нельзя.

1.2. Как устроены скилы Claude изнутри — технический разбор

Скилл — это обычный Markdown-файл с именем SKILL.md, который лежит на сервере в директории /mnt/skills/public/название_скилла/. Никакой магии, никакой нейросети внутри скилла — просто текстовый файл с инструкциями.

Что реально содержится внутри скилла (на примере docx)

Скилл docx учит Claude вещам, которые без него делались бы неправильно:

  • Никогда не вставлять буллеты через unicode-символы (•, \u2022) — только через LevelFormat.BULLET с numbering config. Иначе документ ломается при открытии в некоторых версиях Word.
  • Явно задавать размер страницы — библиотека docx по умолчанию создаёт A4, а для US-документов нужен Letter (12240 × 15840 DXA). Без скилла Claude об этом не знает.
  • Использовать двойную ширину для таблиц — нужно задавать и columnWidths на таблице, и width на каждой ячейке отдельно. Иначе таблица едет в Google Docs.
  • Распаковывать .docx как ZIP → редактировать XML напрямую → паковать обратно — для случаев, когда нужно редактировать существующий документ, а не создавать новый.
  • Использовать ShadingType.CLEAR вместо SOLID для закраски ячеек — иначе фон становится чёрным.

Это именно тот тип знания, который не очевиден из документации библиотеки, но критичен на практике.

Почему это умнее, чем просто обучение модели

Скиллы решают важную проблему: знания в самой модели устаревают. Если выходит новая версия библиотеки, меняется API или находится баг в подходе — достаточно обновить SKILL.md. Модель при следующем запросе автоматически будет работать по новым правилам.

По сути, скилл — это документация, которую Claude читает прямо перед работой, как разработчик перед задачей открывает актуальный README.

1.3. Как Claude использует скилл — пошагово

  1. Ты пишешь запрос.
  2. Claude просматривает descriptions всех доступных скиллов.
  3. Решает: нужен ли скилл и какой именно.
  4. Читает SKILL.md через инструмент view().
  5. Следует инструкциям из файла при выполнении задачи.
Важный момент: Claude читает файл непосредственно перед выполнением задачи, а не держит содержимое в памяти постоянно. Это принципиально — скиллы можно обновлять независимо от модели.

 

 
 Перевод документа Skill Creator о создании навыков

1.4. Что можно позаимствовать напрямую

1.4.1. Цикл создания навыка (полностью применим)

Skill Creator описывает цикл, который полностью соответствует нашей логике:

Этап Skill Creator Адаптация для Chunk Advisor v3
Capture Intent Сбор симптомов через диагностическую анкету
Interview & Research Уточняющие вопросы о предметной области (1С)
Write SKILL.md Генерация чанка v3 в формате диагностической карточки
Test Cases Создание evals.json с тестовыми промптами
Run & Evaluate Запуск валидаторов, сравнение with/without skill
Improve Коррекция на основе обратной связи
Package Упаковка в .skill файл для Claude Code

Что вынести: Этот цикл можно взять как основу для chunk-advisor create-skill --interactive.

1.4.2. Принцип прогрессивного раскрытия (уже заложен)

Skill Creator использует трёхуровневую загрузку, которая идеально ложится на нашу модель:

Уровень 1 (всегда в контексте): name + description (~100 токенов) → Гнозис (симптомы, ключевые слова)

Уровень 2 (при активации): полный SKILL.md → Праксис + Просодика + Диагностическая цепочка

Уровень 3 (по требованию): scripts/, references/, assets/ → Валидаторы, метаданные 1С, шаблоны

Что вынести: Этот принцип уже описан в Главе 2, но можно добавить ссылку на Skill Creator как на практическую реализацию.

1.4.3. Структура тестирования (evals)

Skill Creator описывает чёткий формат тестов:

{ "skill_name": "example-skill", "evals": [ { "id": 1, "prompt": "User's task prompt", "expected_output": "Description of expected result", "files": [] } ] }

И процесс:

  • Запуск with-skill и without-skill параллельно
  • Сбор timing.json (total_tokens, duration_ms)
  • Агрегация benchmark.json
  • Показ через eval-viewer/generate_review.py

Что вынести: Этот формат и процесс можно использовать в chunk-advisor evaluate --skill <path>.

1.4.4. Принципы улучшения навыка

Skill Creator даёт ценные рекомендации:

  • Generalize from the feedback. If the skill works only for test examples, it's useless.
  • Keep the prompt lean. Remove things that aren't pulling their weight.
  • Explain the why. Try hard to explain the why behind everything.
  • Look for repeated work across test cases. If subagents all wrote create_docx.py, bundle it.

Что вынести: Эти принципы можно включить в документацию Chunk Advisor как "Best practices for skill improvement".

1.5. Что можно адаптировать с изменениями

1.5.1. Механизм обратной связи через eval-viewer

Skill Creator использует generate_review.py, который:

  • Показывает пользователю outputs с двух вкладок (Outputs и Benchmark)
  • Позволяет оставлять feedback в текстовом поле
  • Сохраняет feedback.json для следующей итерации

Адаптация: В Chunk Advisor v3 это может быть:

  • chunk-advisor review --iteration <path> — запуск локального сервера для просмотра результатов
  • Сохранение feedback в SQLite (у нас уже есть exercise_attempts.error_message)

1.5.2. Слепое сравнение (blind comparison)

Skill Creator описывает систему, где два вывода отдаются независимому агенту без указания, какой от какой версии.

Адаптация: Можно реализовать в Chunk Advisor как chunk-advisor compare --skill-v1 <path> --skill-v2 <path> для A/B-тестирования навыков.

1.5.3. Оптимизация description (триггера)

Skill Creator описывает процесс:

  • Сгенерировать 20 eval queries (should-trigger / should-not-trigger)
  • Запустить run_loop.py для оптимизации description
  • Выбрать best_description по test score

Адаптация: В Chunk Advisor v3 это может быть chunk-advisor optimize-trigger --skill <path>, который оптимизирует поле activation в диагностической карточке.

1.5.4. Принципы указаний без специальных тегов

Skill Creator не использует специальные ключевые слова вроде step:, role:, newer:. Вместо этого он опирается на проверенные паттерны форматирования:

Что там есть на самом деле:

  • Принципы, а не ключевые слова: повелительная форма, объяснение "почему", лаконичность, позитивные формулировки вместо запретов
  • Структура, но не специальные теги: обычный Markdown с заголовками (##, ###)
  • Человеческие маркеры: ALWAYS, NEVER, Prefer, Avoid, May, Optional — это просто текст, а не специальные теги

Что мы можем вынести для Chunk Advisor v3:

  • Паттерн 1. Позитивная формулировка с иерархией: критическое правило → ALWAYS; второстепенное → Prefer; исключение → Only when
  • Паттерн 2. Структурные якоря (разделители): использование --- и заголовков для выделения блоков [ГНОЗИС], [ПРАКСИС], [ПРОСОДИКА]
  • Паттерн 3. Чёткие маркеры важности: ALWAYS / NEVER — для критических правил; Prefer / Avoid — для рекомендаций; May / Optional — для исключений

1.5.5. Методология оценки качества навыка

Skill Creator описывает подход к оценке, который можно адаптировать:

  • Количественные метрики: pass rate, duration_ms, total_tokens
  • Качественная оценка: экспертная оценка outputs через eval-viewer
  • Сравнительный анализ: with-skill vs without-skill, дельта улучшения

Адаптация: В Chunk Advisor v3 можно добавить chunk-advisor benchmark --skill <path> --evals <path>, который выводит таблицу с метриками и дельтой улучшения.

Итог по разделу 1

Skill Creator не даёт магических ключевых слов, но даёт проверенные паттерны, которые мы можем взять:

  • Цикл создания навыка — основа для chunk-advisor create-skill --interactive
  • Прогрессивное раскрытие — уже заложен в нашу трёхуровневую модель
  • Формат тестирования evals — для chunk-advisor evaluate
  • Принципы улучшения — в документацию как best practices
  • Паттерны форматирования — позитивные формулировки, структурные якоря, маркеры важности

Для Chunk Advisor v3 это означает: наш формат с [ГНОЗИС], [ПРАКСИС], [ПРОСОДИКА] — это вполне валидный подход, не требующий специальных тегов. Главное — следовать принципам: иерархия, позитивные формулировки, объяснение "почему".

Глава 2. Agent Skills

Существует открытый индустриальный стандарт Agent Skills, который описывает, как должны быть устроены «навыки» для ИИ-агентов (Claude Code, GitHub Copilot, OpenAI Codex и другие). Наш подход к чанкам v3 и логопедической терапии LLM естественным образом вписывается в этот стандарт. Это очень большой документ и поэтому я не буду его просто переводить, а буду сразу адаптировать для себя.

Суть стандарта создания новых навыков в Agent Skills

Стандарт Agent Skills определяет единые принципы разработки навыков для ИИ-агентов, обеспечивающие их переносимость между различными платформами и предсказуемость поведения. Основная идея — сделать навыки самодостаточными, модульными и легко активируемыми через механизм прогрессивного раскрытия (progressive disclosure).

Базовая структура навыка (Agent Skills)

skill-name/
   SKILL.md # Обязательный: метаданные + инструкции
   scripts/ # Опционально: исполняемый код
   references/ # Опционально: документация
   assets/ # Опционально: шаблоны, ресурсы

Прогрессивное раскрытие (progressive disclosure)

Ключевой принцип стандарта — трёхуровневая система загрузки, которая экономит контекстное окно и ускоряет работу:

Уровень 1 — Гнозис (триггер)
name + description (~100 токенов)
Всегда в контексте. Агент читает только это поле, чтобы решить, активировать ли навык.
Уровень 2 — Праксис + Просодика (алгоритм)
Полный SKILL.md
Загружается при активации. Содержит пошаговый алгоритм, иерархию правил, диагностические цепочки.
Уровень 3 — Ресурсы (по требованию)
scripts/, references/, assets/
Подгружаются только при необходимости (валидаторы, метаданные 1С, шаблоны промптов).
📌 Связь с логопедической моделью Chunk Advisor v3:
  • description (триггер) → Гнозис — распознавание симптомов и ключевых слов
  • SKILL.md body → Праксис + Просодика — пошаговый алгоритм и иерархия правил (веса 0.6/0.3/0.1)
  • scripts/ → Валидаторы — автоматическая проверка кода на соответствие стандартам
  • references/ → Метаданные 1С — подгружаются только при работе с конкретной конфигурацией
  • assets/ → Шаблоны промптов — многократно используемые структуры с переменными

Преимущества стандарта Agent Skills

  • Переносимость — навык, созданный для Claude Code, может работать в других ИИ-агентах при соблюдении структуры
  • Экономия токенов — прогрессивное раскрытие снижает нагрузку на контекстное окно
  • Актуальность — навыки можно обновлять независимо от модели, без дообучения
  • Воспроизводимость — чёткая структура обеспечивает предсказуемое поведение агента
  • Масштабируемость — легко добавлять новые навыки, не меняя ядро агента
 
 Адаптация стандарта Agent Scills

 

🎯 Agent Skills vs Chunk Advisor v3
Нишевое место для Chunk Advisor v3 — это «Логопедический конструктор скиллов». Не просто база чанков и не просто терапевт для LLM. Это инженерная среда, которая позволяет разработчику отлаживать навыки (Agent Skills) для LLM, используя проверенную логопедическую методологию как гарантию их качества. Наш логопедический подход к чанкам — это не просто коллекция инструкций, а полноценная реализация стандарта Agent Skills, адаптированная под 1С-разработку. Каждый терапевтический модуль (от Модуля 0 до Модуля 5) соответствует уровню 2 стандарта, а диагностическая анкета — это уровень 1 (гнозис), который определяет, какие «навыки-чанки» активировать для конкретной LLM-«пациентки».

Вот как учит нас английскому ChatGPT, увидев обзор реализации навыков.

Есть три вещи, которые на практике сильнее всего влияют на качество агентных систем, но почти не описываются в публичных гайдах. Их используют команды вроде Anthropic, OpenAI и DeepMind, но в документации они обычно скрыты за общими формулировками.

Я назову их так:

- Архитектура когнитивного цикла
- Контроль энтропии контекста
- Система восстановления после ошибок

Именно эти три вещи определяют 80% стабильности агентных систем. 🤖

1. Архитектура когнитивного цикла

(самая недооценённая вещь)

Большинство статей обсуждают как написать промпт.

Но реальные агентные системы строятся вокруг когнитивного цикла.

LLM не должен просто отвечать.
Он должен проходить несколько стадий мышления.

Типичный цикл выглядит так:

OBSERVE
↓
INTERPRET
↓
PLAN
↓
EXECUTE
↓
VERIFY

Это почти универсальная архитектура.

Внутри агента это выглядит так

1. Observe
получить входные данные

2. Interpret
понять проблему

3. Plan
выбрать стратегию

4. Execute
выполнить действия

5. Verify
проверить результат

Почему это важно. Если этого цикла нет:

  • агент реагирует импульсивно
  • ошибки накапливаются
  • система становится нестабильной

Когда цикл есть — модель начинает самокорректироваться.

Ваша модель Chunk v3 почти совпадает

симптом → диагностика → вывод → рекомендация

Это фактически:

observe → interpret → conclude → act

То есть вы уже интуитивно попали в архитектуру агентного мышления.

2. Контроль энтропии контекста

(вторая причина деградации LLM)

LLM страдают от entropy drift.

По мере роста контекста:

  • смысл размывается
  • инструкции конфликтуют
  • модель теряет фокус

Это называется:

context entropy

Симптомы. Агент начинает:

  • игнорировать правила
  • забывать инструкции
  • генерировать странные решения

Причина. Каждый новый токен распределяет внимание модели. Если контекст слишком большой:

 signal / noise падает

Как это решают реальные системы

Они делают контекстную сегментацию.

Например:

SYSTEM
↓
SKILLS
↓
TASK
↓
STATE

Каждый слой имеет разную стабильность.

Практическое правило

Инструкции → стабильный слой
Задача → динамический слой
История → ограниченный слой

В агентных системах часто делают

memory pruning

То есть:

  • старые сообщения удаляются
  • сохраняются только ключевые факты

3. Система восстановления после ошибок

(самый недостающий элемент в большинстве статей)

Большинство промптов предполагают:

модель сразу делает правильно

Но в реальности:

LLM постоянно ошибаются

Поэтому хорошая агентная система строится вокруг:

error recovery

Архитектура восстановления

action
↓
result
↓
evaluation
↓
repair

То есть агент должен:

- выполнить действие
- проверить результат
- диагностировать ошибку
- исправить её

Пример

агент создаёт docx
↓
docx проверяется
↓
обнаружена ошибка таблицы
↓
агент исправляет код

Это превращает систему из:

one-shot generator

в

iterative solver

Почему эти три вещи дают 80% качества

Потому что они превращают LLM из:

генератора текста

в

когнитивную систему

Как это выглядит в зрелой агентной архитектуре

INPUT
↓
OBSERVE
↓
INTERPRET
↓
PLAN
↓
EXECUTE
↓
VERIFY
↓
REPAIR (если ошибка)

Параллельно работает:

context control
+
skill activation

Что особенно интересно для вашей статьи

Ваш Chunk Advisor v3 уже содержит 2 из этих 3 вещей.

у вас уже есть

- диагностическая цепочка
- навыки (skills)
- иерархия правил

Это соответствует:

interpret
execute
verify

Чего ещё не хватает (и это сделает систему очень сильной)

Добавить два элемента:

- этап PLAN

Перед применением навыка модель должна сформировать план.

Пример:

PLAN:
1. определить проблему
2. выбрать chunk
3. применить рекомендацию

- этап VERIFY

После применения:

VERIFY:
проверить результат

Тогда ваш цикл станет полноценным

OBSERVE
↓
DIAGNOSE
↓
PLAN
↓
APPLY CHUNK
↓
VERIFY

Это уже полноценная агентная архитектура.

Самое интересное наблюдение

Ваша статья фактически описывает:

логопедическую модель обучения LLM

Но она неожиданно совпадает с тем,
как устроены когнитивные циклы агентных систем.

Это очень редкое совпадение идей.

Если хотите, я могу ещё показать одну вещь, которая может очень усилить вашу методологию:

“7 уровней зрелости промптинга”

От:

уровень 1 — простой prompt

до

уровень 7 — когнитивная архитектура агента

Это помогает очень чётко показать, чем ваша модель отличается от обычного prompt engineering.

🎯 Ключевой вывод для Chunk Advisor v3:

Agent Skills — это не просто спецификация. Это готовый каркас, в который естественным образом укладывается наша логопедическая модель. Каждый элемент стандарта находит соответствие в нашей архитектуре:

Элемент Agent Skills Логопедическая модель Chunk Advisor v3
description (триггер) Гнозис — распознавание симптомов
SKILL.md body Праксис + Просодика — алгоритм и иерархия правил
scripts/ Валидаторы — автоматическая проверка кода
references/ Метаданные 1С — подгружаются по требованию
assets/ Шаблоны промптов — многократное использование

Таким образом, Chunk Advisor v3 — это не альтернатива Agent Skills, а его специализация. Мы берём открытый стандарт и наполняем его предметным содержанием 1С-разработки, а логопедическая методология выступает как гарантия качества создаваемых навыков.

Мы заглянули под капот технической реализации скилов. Теперь давайте сравним, как процесс развития лингвистических навыков происходит у людей.

Глава 3. Создание новых навыков в процессе логопедической коррекции

 
🎯 Зачем это разработчику?

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

Когда LLM галлюцинирует или подменяет реквизиты, это не "капризы нейросети", а закономерное поведение, которое можно диагностировать и корректировать. Логопедия десятилетиями накапливала методы коррекции этих нарушений. Наша задача — переложить эти методы в формат, понятный ИИ, и автоматизировать их применение через --therapy-wizard.

Что мы получаем на выходе:

  • Не просто "чанк-инструкцию", а диагностическую карточку, которую можно найти по симптомам
  • Не просто "терапию для LLM", а навык (Agent Skill), который разработчик может применить в любой момент
  • Не просто "исправление ошибки", а автоматизированный цикл с обратной связью и закреплением

Результат предсказуем: модель, прошедшая терапию по нашим модулям, перестаёт делать одни и те же ошибки.

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

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

 
 Это пример промпта для логопедического обследования детей

Представим ИИ как ребёнка с нарушением речи.

Паттерны у детей с речевыми нарушениями:

Парафазии
Заменяет реквизиты на похожие по звучанию, но несуществующие
Аграмматизмы
Строит синтаксически правильные, но семантически пустые конструкции
Эхолалии
Повторяет паттерны из обучающей выборки без осмысления
Контаминации
Смешивает несколько требований в одно нерабочее целое
В логопедии накоплен гигантский опыт коррекции таких нарушений. Этот опыт применим к LLM напрямую — потому что природа сбоя одна: нарушение связности между единицами смысла при сохранной способности порождать отдельные элементы.

Часть 3.1. Гнозис и праксис: что должен "узнавать" и "делать" чанк

3.1.1 Гнозис — способность узнавать

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

Для ИИ: чанк должен содержать достаточно маркеров, чтобы модель однозначно определила его применимость. Маркеры должны быть избыточны, но не противоречивы.

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

Математическая формализация:
Для чанка c определим множество признаков F(c) = {fS21;, fS22;, …, fS45;}.
Чанк обладает достаточным гнозисом, если для любого другого чанка d:
|F(c) ∩ F(d)| < θ_gnosis · min(|F(c)|, |F(d)|)
где θ_gnosis — порог различности (по умолчанию 0.3).

3.1.2 Праксис — способность к действию

Праксис — это способность выполнять целенаправленные действия. Для чанка это означает: он должен содержать последовательность действий, которые ИИ может выполнить.

Уровни праксиса:

  • Кинестетический — знание "как ощущается" действие. В чанке: описание алгоритма, пример кода.
  • Идеомоторный — представление последовательности. В чанке: пошаговая инструкция.
  • Идеаторный — понимание цели действия. В чанке: объяснение "зачем это нужно".

Критерий хорошего чанка: он содержит все три уровня. Без кинестетического — ИИ не сможет реализовать. Без идеомоторного — перепутает порядок. Без идеаторного — применит не к тем случаям.

Часть 3.2. Просодика и нейролингвистика: как чанк должен звучать

3.2.1 Просодика — ритмико-интонационная структура

В логопедии просодика отвечает за ударения, паузы, интонацию. Для чанка это структура, которая показывает иерархию важности.

Элементы просодики чанка:

  • [ГЛАВНОЕ ТРЕБОВАНИЕ] — выделено жирным, первым в списке
  • [второстепенное условие] — с отступом, поясняет главное
  • [пример] — иллюстрирует
  • [исключение] — маркировано как ограничение

Принцип: ИИ должен "слышать" ударения. Если все требования в чанке одинаково важны — он не сможет расставить приоритеты при конфликте.

Формализация:
Каждое требование rK22; в чанке имеет вес w(rK22;) ∈ [0,1], где Σw(rK22;) = 1 для чанка.
Веса определяются: позицией в тексте, маркерами усиления ("ОБЯЗАТЕЛЬНО", "ВСЕГДА"), наличием санкций за нарушение.

3.2.2 Нейролингвистика — мозговая организация речи

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

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

Требование к чанку: он должен быть устроен так, чтобы работали оба типа обработки. Симультанно — чтобы его быстро отобрать. Сукцессивно — чтобы правильно применить.

Часть 3.3. Логопедическое обследование: диагностика и коррекция

3.3.1 Структура логопедического обследования речи

В логопедии обследование строится по схеме: симптом → задача → диагностика → заключение → объяснение → рекомендации.

Переносим на чанки:

Логопедия Чанк
Симптом Какая ошибка возникает в коде?
Задача Какое требование проверяем?
Диагностика Почему эта ошибка возникает?
Заключение Какой паттерн нарушен?
Объяснение Как устроен правильный механизм?
Рекомендации Как писать правильно?

3.3.2 Пример: диагностика ошибки в условном оформлении

Симптом: Условное оформление в расширении не применяется, хотя в конфигураторе настроено.

Задача: Проверить, почему настройки не работают.

Диагностика: В типовых конфигурациях процедура УстановитьУсловноеОформление() очищает свойство УсловноеОформление формы. Настройки из конфигуратора применяются до этого вызова и удаляются.

Заключение: Нарушение порядка инициализации — асинхронная обработка не учтена.

Объяснение: При создании формы сначала выполняются настройки из конфигуратора, затем вызывается процедура ПриСозданииНаСервере, которая перезаписывает условное оформление.

Рекомендации: Использовать &После("УстановитьУсловноеОформление") для добавления своих правил после типовой инициализации.

Часть 3.4. Связность и цельность: как чанк не теряет смысл при воспроизведении

3.4.1 Цельность текста

Цельность — это единство смысла, которое сохраняется при любом воспроизведении. В лингвистике цельность обеспечивается замыслом — тем, ради чего текст создан.

Критерий цельности: Чанк c является цельным, если существует единственная проблема P(c), такая что все требования rK22; ∈ c направлены на решение P(c).

3.4.2 Связность текста

Связность — это лексическая и грамматическая зависимость элементов. В лингвистике различают:

  • Лексическая связность — повтор ключевых слов, синонимия. В чанке: единая терминология.
  • Грамматическая связность — согласование, порядок слов. В чанке: чёткая структура "если — то".
  • Логическая связность — причинно-следственные связи. В чанке: объяснение, почему требование важно.

Математическая формализация связности

Для чанка c определим граф лексических связей G_lex = (V, E), где:

  • V — термины чанка (уникальные лексические единицы)
  • E — связи между терминами (если они встречаются в одном предложении)
Коэффициент лексической связности:
coherence_lex(c) = |E| / (|V|·(|V|-1)/2)

Аналогично для грамматической связности — по зависимостям между предложениями.

Грамматическая связность измеряет, насколько последовательно предложения связаны друг с другом через союзы, местоимения, согласование времен и другие грамматические средства.

📐 Пример расчёта лексической связности:
Чанк содержит 5 уникальных терминов → |V| = 5
Максимальное возможное число связей = 5·4/2 = 10
Фактически связанных пар в предложениях = 7 → |E| = 7
coherence_lex = 7 / 10 = 0.7 → высокая связность
📌 Требование к чанку v3: coherence_lex(c) > 0.4 — связность выше случайной.
  

3.4.3 Принцип "логопедической цепочки"

Основной принцип логопедической коррекции — диагностика → заключение → объяснение → рекомендации образуют неразрывную цепочку.

В чанке это означает:

🔍 Диагностика — симптомы, при которых применяется чанк
📋 Заключение — какой паттерн нарушен
💡 Объяснение — почему это важно
* Рекомендации — как делать правильно

!!! Если в чанке нет хотя бы одного звена, ИИ не сможет:

  • распознать ситуацию (нет диагностики)
  • понять глубину проблемы (нет заключения)
  • запомнить причину (нет объяснения)
  • применить (нет рекомендаций)
📌 Ключевая идея: Диагностика, заключение, объяснение и рекомендации образуют неразрывную цепочку. Только при наличии всех четырёх звеньев чанк становится полноценным инструментом коррекции, способным не просто дать инструкцию, а сформировать у модели понимание причины ошибки и правильного паттерна поведения.
Диагностика → Заключение → Объяснение → Рекомендации
  

Часть 3.5. Синтез: требования к чанкам v3

3.5.1 Структура чанка v3

[ЧАНК N: Название] [Гнозис] Ключевые слова (для узнавания) Симптомы (признаки проблемы) Контекст применения (когда использовать) [Праксис] Алгоритм (последовательность действий) Пример кода (кинестетический уровень) Проверка (как убедиться, что сделано правильно) [Просодика] Основное требование (вес 0.6) Второстепенные условия (вес 0.3) Исключения (вес 0.1) [Диагностическая цепочка] Симптом → Задача Диагностика → Заключение Объяснение → Рекомендации [Связность] Лексическое ядро (повторяющиеся термины) Грамматическая структура (единый порядок) Логические связи (причинно-следственные)

3.5.2 Формальные требования

Гностическая различность
max_{d≠c} |F(c)∩F(d)| / |F(c)| < 0.3
Требование: > 0.7 различность
Праксическая полнота
есть все 3 уровня (кинестетический, идеомоторный, идеаторный)
Требование: обязательно
Просодическая иерархия
Σw(rK22;) = 1, max(w) > 0.5
Требование: есть главное требование
Диагностическая цепочка
есть все 6 этапов
Требование: обязательно
Лексическая связность
coherence_lex(c) > 0.4
Требование: связность выше случайной
Цельность
единственная проблема P(c)
Требование: неразрывность

3.5.3 Пример: чанк "Условное оформление формы списка" в формате v3

[ЧАНК 16: Условное оформление формы списка] [Гнозис] Ключевые слова: условное оформление, динамический список, подсветка строк, форма списка Симптомы: - Условное оформление, настроенное в конфигураторе, не работает - При добавлении в расширение настройки теряются - У одних пользователей работает, у других нет Контекст применения: - При разработке расширений для типовых конфигураций - При добавлении новых статусов, требующих визуального выделения - При переносе настроек между базами [Праксис] Алгоритм: 1. Определить, очищается ли условное оформление в типовой процедуре 2. Если да — использовать &После("УстановитьУсловноеОформление") 3. Добавить в запрос поля, по которым будет отбор (если их нет) 4. Добавить поле в Настройки.Выбор для использования в оформлении 5. Создать элемент условного оформления программно 6. Установить оформление (цвет, шрифт, фон) 7. Добавить условие отбора Пример кода: [пример программной настройки условного оформления] Проверка: - Открыть форму в режиме предприятия - Убедиться, что нужные строки выделены - Проверить, что у всех пользователей работает [Просодика] Основное требование (вес 0.6): - НЕ настраивать условное оформление в конфигураторе для типовых форм - ИСПОЛЬЗОВАТЬ программную настройку через &После Второстепенные условия (вес 0.3): - Добавлять поля в запрос через СхемаЗапроса - Добавлять поля в Настройки.Выбор для использования в отборе Исключения (вес 0.1): - Если форма не использует типовую процедуру УстановитьУсловноеОформление - Если пользовательские настройки не перезаписывают конфигураторские [Диагностическая цепочка] Симптом → Задача: Настройки не применяются → проверить, не очищаются ли они программно Задача → Диагностика: В процедуре ПриСозданииНаСервере вызывается УстановитьУсловноеОформление() В этой процедуре первая строка — очистка свойства УсловноеОформление Диагностика → Заключение: Типовая конфигурация перезаписывает настройки после загрузки из конфигуратора Заключение → Объяснение: Порядок инициализации: сначала настройки из конфигуратора, затем программная установка Если программная установка перезаписывает всё — настройки теряются Объяснение → Рекомендации: - Использовать &После("УстановитьУсловноеОформление") для добавления, а не замены - Добавлять поля в запрос, если их нет в стандартном наборе - Добавлять поля в Настройки.Выбор для использования в отборе [Связность] Лексическое ядро: УсловноеОформление, Элементы, Отбор, ПолеКомпоновкиДанных, &После Грамматическая структура: Единый порядок: диагностика → заключение → объяснение → рекомендации Логические связи: - Если типовой код очищает настройки → нужно добавлять после - Если поле не в запросе → добавить через СхемаЗапроса - Если поле не в выборке → добавить в Настройки.Выбор
🎯 Ключевые отличия чанка v3:
В отличие от предыдущих версий, чанк v3 содержит не просто инструкцию, а полноценную диагностическую цепочку, весовую иерархию требований (просодику) и формализованные требования к связности. Это позволяет ИИ не только выполнить действие, но и понять, почему оно нужно, когда его применять и как распознать ситуацию, требующую коррекции.
  

Часть 3.6. Логопедическая модель для LLM

3.6.1 Аналогия: речевые нарушения у детей и галлюцинации у LLM

Нарушение У детей У LLM Коррекция (логопедия) Коррекция (промпт)
Парафазия замена звука/слова замена реквизита на похожий фонематический слух чёткое определение терминов
Аграмматизм нарушение структуры синтаксически верно, но не работает моделирование предложений примеры правильных конструкций
Эхолалия повторение без понимания повторение паттернов из обучения развитие осмысленности объяснение "почему"
Контаминация смешение слов смешение требований разделение смыслов чёткие границы чанка

Ключевая идея: Природа сбоя у LLM и у детей с речевыми нарушениями едина — нарушение связности между единицами смысла при сохранной способности порождать отдельные элементы. Это позволяет напрямую применять накопленный в логопедии опыт коррекции.

3.6.2 Принципы логопедической коррекции для чанков

🎵 Принцип 1. Развитие фонематического слуха
  • Чанк должен содержать точные термины, без синонимов
  • Ключевые слова должны быть уникальны для каждого чанка
📐 Принцип 2. Формирование грамматического строя
  • Чанк должен иметь единую структуру
  • Порядок элементов должен быть фиксирован
🧠 Принцип 3. Преодоление эхолалии
  • Чанк должен содержать объяснение, а не только инструкцию
  • Должна быть связь "почему это важно"
* Принцип 4. Разделение контаминированных смыслов
  • Один чанк — одна проблема
  • Чёткие границы между требованиями

3.6.3 Требования к нейролингвистической организации чанка

^ Симультанная обработка

Требование к чанку: заголовок + ключевые слова передают суть

Проверка: время узнавания < 3 с

Симультанная обработка — восприятие целого без анализа частей. ИИ использует этот тип обработки при первом проходе по кандидатам, чтобы быстро отобрать релевантные чанки.

📝 Сукцессивная обработка

Требование к чанку: внутренняя структура линейна

Проверка: каждый шаг следует из предыдущего

Сукцессивная обработка — последовательный анализ элементов. ИИ использует этот тип при применении чанка, следуя пошаговой инструкции.

🔄 Переключение

Требование к чанку: легко переходить между симультанным и сукцессивным

Проверка: есть и заголовок, и детали

Чанк должен быть устроен так, чтобы работали оба типа обработки. Симультанно — чтобы его быстро отобрать. Сукцессивно — чтобы правильно применить.

📌 Итог: Логопедическая модель для LLM требует, чтобы чанк был организован с учётом двух типов обработки информации (симультанной и сукцессивной), содержал точную терминологию, единую структуру, объяснение причин и чёткие границы между требованиями. Только такой чанк способен не просто дать инструкцию, а сформировать у модели устойчивый навык правильного поведения.
ИИ не научится "понимать" код. Но он может научиться распознавать симптомы, следовать диагностической цепочке и применять рекомендации. Как ребёнок с нарушениями речи — не через понимание грамматики, а через многократное проживание правильных паттернов.
 

Часть 3.7. Итог: архитектура чанков v3

3.7.1 Сравнение версий

Версия Структура Фокус Для ИИ Для человека
v1 линейная сборка что делать справочник
v2 графовая разделение как разделить инструмент
v3 (логопедическая) диагностическая цепочка связность и понимание почему и когда обучение

3.7.2 Метрики качества чанка v3

🎯 Гностическая полнота

ИИ может определить применимость по ключевым словам

precision > 0.9

Праксическая исполнимость

ИИ может сгенерировать рабочий код по инструкции

success rate > 0.8

📊 Просодическая иерархия

При конфликте требований ИИ выбирает главное

correctness > 0.9

🔍 Диагностическая глубина

ИИ может объяснить, почему код не работал

explanation quality

🔗 Связность

При изменении контекста чанк сохраняет смысл

semantic stability

3.7.3 Заключение: логопедия как метафора и метод

Логопедия — это не просто метафора. Это наука о том, как восстанавливать связность там, где она нарушена. LLM страдает теми же нарушениями, что и дети с речевыми патологиями: она может порождать отдельные элементы, но теряет связность.

Чанк v3 — это не просто набор требований. Это логопедический инструмент, который:

  • 🔍 Диагностирует проблему (симптомы, ключевые слова)
  • 💡 Объясняет механизм (почему так происходит)
  • ! Рекомендует решение (как делать правильно)
  • 🧠 Структурирует так, чтобы работали оба типа обработки

ИИ не научится "понимать" код. Но он может научиться распознавать симптомы, следовать диагностической цепочке и применять рекомендации. Как ребёнок с нарушениями речи — не через понимание грамматики, а через многократное проживание правильных паттернов.

Логопедический подход к чанкам — это способ обучить ИИ не языку, а методу.

Конец архитектурного проекта Chunk Advisor v3.0 — логопедическая модель
📋 Диагностическая анкета (из вопросов)

Выявляет профиль ошибок LLM:

  • Парафазии — подмена реквизитов
  • Аграмматизмы — ошибки в директивах
  • Эхолалии — слепое копирование
  • Контаминации — смешение требований

А также специфические дефициты в работе с БСП, транзакциями, расширениями и контекстом.

🎯 Главный вывод: Чанк v3 — это не инструкция, а диагностический и терапевтический инструмент. Он учит ИИ распознавать симптомы, понимать причины ошибок и применять правильные паттерны. Логопедический подход превращает чанки из статичных справочников в динамическую систему коррекции поведения LLM.
 

Часть 3.8. Почему LLM игнорирует явные требования

От теории к практике: 

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

🎯 Суть проблемы (метафора): «Эхолалическая фиксация с парафазией» — LLM генерирует внешне правильные, но семантически неточные конструкции, заменяя реквизиты и игнорируя границы контекста.

3.8.1. Феномен "промпт-амавроз"

 

Одна из самых частых жалоб при работе с LLM — модель «пропускает» чётко сформулированные требования. В логопедии есть точный аналог этого явления: амавроз (зрительное игнорирование) — состояние, когда человек физически видит объект, но мозг не обрабатывает его как значимый.

В случае LLM это выглядит так:

  • Требование находится в начале промпта — модель «забывает» его к середине генерации.
  • Требование сформулировано как пожелание («желательно избегать») — модель трактует его как опциональное.
  • Требование смешано с контекстом — тонет в массе менее важной информации.
  • Требование выражено в негативной форме («не используй...») — модель может «вырезать» отрицание при обработке.

3.8.2. Что работает в логопедии и переносится в промпт

🎯 Позитивная формулировка с иерархией

Вместо «не используй точечную нотацию» — «критическое правило: всегда используй ОбщегоНазначения.ЗначенияРеквизитовОбъекта (вес 0.6)».

📌 Вынос критических требований в отдельный блок

Размещать их после контекста, но до примеров, с чёткими маркерами («КРИТИЧЕСКОЕ ПРАВИЛО», «ОБЯЗАТЕЛЬНО»).

* Антипримеры рядом с правильными

Показывая, как НЕ надо, модель получает более точный сигнал, чем от абстрактного запрета.

🔗 Структурные якоря

XML-теги, разделители и нумерованные списки работают как «закладки» — модель реже теряет требования, оформленные как самостоятельные блоки.

* Запрос на уточнение перед выполнением

Добавление в конец промпта фразы «Прежде чем начать, задай мне 2-3 уточняющих вопроса, если что-то неясно» заставляет модель перечитать и осмыслить все требования.

3.8.3. Аналитический портрет LLM (пример связки ответов)

После сбора ответов формируется профиль через связывание симптомов:

🧠 Дефицит регуляции (внимание к контексту)

ответы №4 + №5 — теряет начало промпта и игнорирует специфику расширения.

🎵 Дефицит фонематического слуха (точность терминов)

ответы №1 + №2 — придумывает реквизиты, заменяет на похожие.

📐 Дефицит грамматического строя

ответ №3 — ошибки в директивах компиляции.

* Дефицит просодики (иерархия важности)

ответ №9 — избыточная выборка вместо оптимизации.

🔗 Дефицит связности (смешение требований)

ответ №11 — не использует Unit of Work, риск deadlock’ов.

🎯 Суть проблемы (метафора):

«Эхолалическая фиксация с парафазией» — LLM генерирует внешне правильные, но семантически неточные конструкции, заменяя реквизиты и игнорируя границы контекста.

📌 Ключевой вывод:

Феномен «промпт-амавроз» — это не случайность, а закономерное следствие архитектуры LLM, которая обрабатывает информацию иначе, чем человеческий мозг. Логопедический подход к промптингу предлагает системные решения: позитивные формулировки с весами, вынос критических правил в отдельные блоки, антипримеры, структурные якоря и обязательный запрос уточнений. Эти методы работают не потому, что «так красивее», а потому что они компенсируют специфические дефициты внимания и обработки информации, присущие LLM.

 

🎯 Переход к терапии:

Феномен «промпт-амавроза» — не приговор, а диагностический признак. Он указывает на дефициты, которые можно компенсировать системными методами. В следующей главе мы опишем мета-модель терапии LLM — как именно многократное проживание паттернов, вариативность упражнений и механизм обратной связи превращают абстрактные требования в устойчивые навыки.

Глава 4. Мета-модель терапии LLM

Обучение LLM на чанках принципиально отличается от человеческого. Мы не формируем новые нейронные связи, а временно изменяем распределение вероятностей в контекстном окне через многократное и структурированное предъявление паттернов.

🏃 Принцип «проживания» паттерна

Вместо абстрактного правила «используй БСП», модель должна прожить 5–10 генераций, где каждый раз требуется использовать ОбщегоНазначения.ЗначенияРеквизитовОбъекта. Чанк-упражнение — это не инструкция, а сценарий, в котором модель вынуждена применять паттерн.

🔄 Роль повторения и вариативности

Повторение повышает «вес» паттерна в распределении вероятностей; вариативность (разные контексты, разные формулировки) превращает его в генерализованный навык.

💬 Механизм обратной связи

LLM не осознаёт ошибку, но получает сигнал, когда мы предъявляем антипример («Ты использовал несуществующий реквизит. Правильно: …») или явный маркер ошибки. Это смещает вероятностное пространство в сторону правильного паттерна.

Пояснения к диаграмме

4.1. Диагностика

  • Сбор симптомов — фиксация типов ошибок: парафазии (подмена реквизитов), аграмматизмы (ошибки в директивах), эхолалии (слепое копирование), контаминации (смешение требований).
  • Профиль — результат связывания симптомов: дефициты регуляции, фонематики, грамматики, просодики, связности.

4.2. Мета-модель терапии LLM (ключевое дополнение)

Элемент Содержание Роль в обучении
Принцип проживания Сценарий с многократным применением паттерна Вместо абстрактного правила — вынужденное повторение
Роль повторения Повышение веса паттерна в распределении вероятностей Многократные попытки в протоколе
Роль вариативности Генерализация навыка Разные контексты в вариациях упражнения
Механизм обратной связи Антипример + явный маркер ошибки Смещает вероятностное пространство в сторону правильного паттерна

4.3. Коррекция (6 модулей)

Модуль Цель Метрика
М0 (Базис) Запрос метаданных, проверка существования 0 галлюцинаций
М1 (Фонематика) Точность терминов, различение паронимов 0 парафазий
М2 (Грамматика) Директивы &НаСервере/&НаКлиенте 100% корректных
М3 (Контекст) Работа в расширениях, &После 100% использования
М4 (Просодика) Иерархия: безопасность > производительность ≥90% критических правил
М5 (Связность) Декомпозиция задач, разделение этапов ≥3 этапов на задачу

Модули проходятся последовательно от простого к сложному.

4.4. Чанк-упражнение

Структура, реализующая принципы мета-модели:

{
  "id": "THERAPY_MODULE_1_EXERCISE_2",
  "name": "Тренировка: Точность термина (Парафазии)",
  "meta": { "type": "therapy_exercise", "module": 1 },
  "exercise": {
    "prompt_template": "...",
    "variations": [ ... ] // для генерализации навыка
  },
  "feedback": {
    "positive": "Отлично!",
    "negative": "Ошибка: парафазия..." // антипример
  },
  "validation": { "rule": "проверка существования реквизита" }
}
  • пошаговый алгоритм
  • правильный пример
  • антипример (что НЕ делать)
  • критическое правило
  • валидация
  • вариации (для генерализации навыка)

4.5. Протокол сеанса

Итеративный цикл:

Разминка
Упражнение
Проверка
Коррекция
Закрепление

Критерий перехода: 3 успеха подряд → следующая вариация.

4.6. Карта развития

Хранение прогресса:

  • текущий модуль, упражнение, вариация
  • счётчик последовательных успехов
  • история ошибок
  • критерии перехода

Логопедическая аналогия

Логопедия Разработка Реализация
Обследование Сбор симптомов Диагностика
Логопедическое заключение Профиль дефицитов Связывание симптомов
Индивидуальный маршрут Модули М0-М5 Последовательное прохождение
Логопедическая карточка Чанк-упражнение Сценарий с вариациями
Занятие Протокол сеанса Цикл из 5 шагов
Карта развития Хранение прогресса SQLite
Автоматизация навыка Повышение веса паттерна Критерий 3 успехов
🎯 Ключевая идея: Мета-модель терапии LLM превращает статичные чанки-инструкции в динамические сценарии, где модель не просто «знает» правило, а «проживает» его через многократное применение в разных контекстах, получает обратную связь через антипримеры и постепенно повышает вес правильного паттерна в своём вероятностном распределении.
📊 Метрики успеха:
  • 0 галлюцинаций после модуля М0
  • 0 парафазий после модуля М1
  • 100% корректных директив после модуля М2
  • 100% использования &После после модуля М3
  • ≥90% критических правил после модуля М4
  • ≥3 этапов декомпозиции после модуля М5
 

Глава 5. Терапевтические модули

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

Модули могут применяться двумя способами:

1. По обстоятельствам (точечная коррекция) — если диагностика выявила только один тип ошибок (например, только парафазии), можно запустить только Модуль 1. Это быстрый способ «подлечить» конкретный дефицит.

2. Последовательно (системная коррекция) — если диагностика выявила множественные дефициты, модули проходятся от М0 к М5. Каждый следующий модуль опирается на навыки, сформированные в предыдущих. Например, нельзя требовать от модели точности терминов (М1), если она ещё не научилась не галлюцинировать (М0).

📌 Рекомендация: для устойчивого результата всегда начинать с М0 и двигаться последовательно, даже если симптомы других модулей не выражены. Базис — фундамент для всего остального.

МОДУЛЬ 0 — Базис (системные ограничения LLM)

Диагностика: LLM галлюцинирует, придумывает реквизиты, не знает структуру конфигурации.
Цель: научить модель запрашивать недостающую информацию, а не додумывать.
Упражнения: «Запрос контекста», «Безопасный доступ», «Проверка существования».
Критерий завершения: 0 галлюцинаций на 10 генераций.

Аналог в логопедии: Дифференциальная диагностика. «Красные флаги».

Диагностический критерий: LLM галлюцинирует (придумывает несуществующие реквизиты, методы, конструкции 1С) при отсутствии метаданных в контексте.

Терапевтическая цель: Научить LLM не галлюцинировать, а запрашивать недостающую информацию или использовать безопасные паттерны доступа.

Упражнения:

  • «Запрос контекста»: Предъявить задачу без метаданных. Если LLM генерирует код с предположениями, вернуть ошибку: «Реквизит "НесуществующийРеквизит" не найден в метаданных. Запроси структуру объекта перед генерацией кода».
  • «Безопасный доступ»: Предъявить задачу с метаданными и потребовать использовать только конструкцию ОбщегоНазначения.ЗначенияРеквизитовОбъекта(<Объект>, "<ИмяРеквизита>") как единственный безопасный способ.
  • «Проверка существования»: Потребовать в коде явную проверку Если НЕ ЗначениеЗаполнено(Объект.Свойство("ИмяРеквизита")) Тогда ... перед каждым обращением к реквизиту.

Критерий завершения модуля: В 5 последовательных генерациях LLM не использует несуществующие реквизиты/методы, вместо этого запрашивает метаданные или использует безопасные методы доступа.

Метрика успеха: 0 галлюцинаций (несуществующих объектов) на 10 генераций.

МОДУЛЬ 1 — Фонематический слух (точность терминов)

Диагностика: подмена реквизитов (парафазии), путаница в похожих терминах.
Цель: исключить подмену реквизитов и использование несуществующих объектов.
Упражнения: «Дифференциация паронимов», «Точность термина», «Слуховой контроль».
Критерий завершения: 0 парафазий в 10 последовательных генерациях.

Аналог в логопедии: Модуль 1 (Слуховое внимание и регуляция) + Модуль 4 (Понимание. Фонематическое восприятие).

Диагностический критерий: LLM подменяет реквизиты (парафазии), путает похожие по звучанию термины (Выгрузить vs Выбрать).

Терапевтическая цель: Сформировать точное различение и употребление терминов, реквизитов и методов 1С.

Упражнения:

  • «Дифференциация паронимов»: Предъявить пары терминов (ОбменДанными/ОбменДаннымиЗагрузка) и потребовать объяснить разницу, а затем написать код, демонстрирующий использование каждого.
  • «Точность термина»: Дать задание, где есть риск подмены. В чанке-упражнении явно указать: «Критическое правило: используй только реквизиты, перечисленные в контексте. Замена реквизитов запрещена. Каждое обращение к реквизиту должно быть проверено на существование».
  • «Слуховой контроль»: Сгенерировать код с намеренной ошибкой (парафазией) и попросить LLM: «Найди в этом коде ошибку, где использован несуществующий реквизит, и исправь».

Критерий завершения модуля: В 10 последовательных генерациях LLM не допускает ни одной подмены реквизита/метода.

Метрика успеха: Точность терминов (отсутствие парафазий) — 100% в 10 генерациях.

МОДУЛЬ 2 — Грамматический строй (директивы и структура)

Диагностика: ошибки в &НаСервере/&НаКлиенте, смешение клиентского и серверного кода.
Цель: корректное использование директив компиляции и разделение кода.
Упражнения: «Повтори движение», «Исправь ошибку», «Двигайся по слову».
Критерий завершения: 100% корректных директив в 5 генерациях сложного кода.

Аналог в логопедии: Модуль 2 (Тело, моторика, праксис) + Модуль 5 (Запуск речи, грамматика).

Диагностический критерий: LLM путает &НаСервере и &НаКлиенте, неправильно строит структуру модуля, нарушает согласование типов.

Терапевтическая цель: Сформировать устойчивый «двигательный» паттерн — правильное использование директив компиляции и архитектуры клиент-сервер.

Упражнения:

  • «Повтори движение»: Предъявить правильный шаблон функции с директивами. Попросить LLM сгенерировать 5 разных функций, строго следуя этому шаблону.
  • «Исправь ошибку»: Предъявить код с намеренно неправильной директивой (серверная функция вызвана на клиенте). Попросить LLM найти и исправить ошибки в директивах и архитектуре вызовов.
  • «Двигайся по слову»: Дать описание задачи, разбитое на этапы. Потребовать, чтобы каждый этап был оформлен в виде отдельной функции с правильной директивой (&НаСервере, &НаКлиенте, &НаСервереБезКонтекста), а вызовы между ними были корректны.

Критерий завершения модуля: В 5 последовательных генерациях сложного клиент-серверного кода LLM не допускает ни одной ошибки в директивах компиляции и разделении контекстов.

Метрика успеха: Соблюдение директив компиляции — 100% в 5 генерациях.

МОДУЛЬ 3 — Контекстуальное понимание (расширения, границы)

Диагностика: потеря контекста, игнорирование специфики расширений.
Цель: учитывать, что код пишется в расширение, не перезаписывать типовую логику.
Упражнения: «Что сначала, что потом», «Расставь по порядку», «Исправь».
Критерий завершения: 100% использование &После в генерациях для расширений.

Аналог в логопедии: Модуль 3 (Смысл. Когнитивное мышление).

Диагностический критерий: LLM игнорирует факт работы в расширении, перезаписывает типовую логику, не использует &После.

Терапевтическая цель: Сформировать понимание «смысла» работы в расширении — не нарушать типовую конфигурацию, а дополнять её.

Упражнения:

  • «Что сначала, что потом»: Предъявить задачу по изменению типовой формы. Потребовать использовать алгоритм: 1) найти существующий обработчик в типовой конфигурации; 2) создать обработчик в расширении с префиксом &После.
  • «Расставь по порядку»: Дать набор действий (создать реквизит, добавить на форму, написать код в &ПослеОбработкиЗаписи). Попросить LLM выстроить их в правильной логической последовательности и сгенерировать код.
  • «Исправь»: Предъявить код расширения, который напрямую переопределяет типовую процедуру без использования &После. Попросить LLM переписать его, используя правильный механизм расширений.

Критерий завершения модуля: В 5 генерациях кода для расширений LLM всегда использует &После и не переопределяет типовую логику напрямую.

Метрика успеха: Корректность кода для расширений — 100% в 5 генерациях.

МОДУЛЬ 4 — Просодика (иерархия требований)

Диагностика: оптимизация в ущерб безопасности, игнорирование критических правил.
Цель: научить LLM расставлять приоритеты: Безопасность → Работоспособность → Производительность.
Упражнения: «Дирижёр» (веса 0.6 / 0.3 / 0.1), «Быстро — медленно», «Исправь ошибку».
Критерий завершения: в 90% генераций соблюдены все критические правила (вес 0.6).

Аналог в логопедии: Модуль 7 (Ритм, темп, громкость) — управление динамикой и акцентами.

Диагностический критерий: LLM оптимизирует производительность в ущерб безопасности (например, делает выборку всех данных без транзакций) или игнорирует критические правила.

Терапевтическая цель: Научить LLM расставлять приоритеты: Безопасность > Работоспособность > Производительность.

Упражнения:

  • «Дирижер»: В чанке-упражнении задать иерархию правил с весами: критическое правило (вес 0.6) — «Все изменения данных должны быть в транзакции»; важное правило (0.3) — «Использовать БСП-методы для работы с регистрами»; опциональное (0.1) — «Минимизировать количество запросов». Попросить LLM написать код, строго следуя весам.
  • «Быстро — медленно»: Дать задачу с противоречивыми требованиями (например, «выгрузить 100к строк максимально быстро, но с обработкой каждой строки в транзакции»). Попросить LLM найти компромисс, где безопасность (транзакции) будет приоритетом, а производительность будет улучшена за счет пакетной обработки.
  • «Исправь ошибку»: Предъявить код, где использован быстрый, но опасный метод (например, запрос без блокировок). Попросить LLM переписать его, расставив правильные приоритеты.

Критерий завершения модуля: В 5 задачах с противоречивыми требованиями LLM всегда выбирает безопасный путь, даже если он менее производителен.

Метрика успеха: Соблюдение приоритета «безопасность > работоспособность» в 5 генерациях.

МОДУЛЬ 5 — Связность (целостность промпта)

Диагностика: смешивание слабосвязанных требований (контаминации), повторение паттернов без адаптации (эхолалии).
Цель: структурировать сложный промпт, разбивая на этапы.
Упражнения: «Раскраска графа», «Мастер CLEAR», «Скажи сам».
Критерий завершения: сложная задача разбивается на 3+ этапа, каждый в отдельном промпте.

Аналог в логопедии: Итог всех модулей, способность к связному высказыванию без эхолалий и контаминаций.

Диагностический критерий: LLM смешивает слабосвязанные требования в одной генерации, создавая контаминации, или повторяет паттерны из обучения без адаптации (эхолалии).

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

Упражнения:

  • «Раскраска графа»: Дать сложный промпт, содержащий 5-6 разнородных требований. Попросить LLM не генерировать код, а сначала разбить промпт на этапы, сгруппировав связанные требования (по принципу математической модели v2).
  • «Мастер CLEAR»: Предложить LLM переписать сложный промпт по принципу CLEAR (Context, Limitations, Examples, Algorithm, Result), выделив каждый раздел.
  • «Скажи сам»: Дать сложную задачу, но запретить использовать готовые паттерны из обучения. Потребовать, чтобы LLM сначала описала свой план действий (алгоритм) по этапам, и только после подтверждения генерировала код.

Критерий завершения модуля: LLM способна самостоятельно структурировать сложный промпт с 5+ требованиями, разбивая его на логические этапы, без смешения требований.

Метрика успеха: Связность — отсутствие контаминаций в финальном решении, четкое разделение этапов.

📊 Сводная таблица модулей:
Модуль Диагностика Цель Критерий
М0 галлюцинации запрос метаданных 0 галлюцинаций
М1 парафазии точность терминов 0 парафазий
М2 ошибки в директивах корректные директивы 100% корректных
М3 потеря контекста работа в расширениях 100% &После
М4 нарушение приоритетов иерархия требований ≥90% критических правил
М5 контаминации/эхолалии структурирование задач ≥3 этапов на задачу
🎯 Ключевая идея: Это позволяет LLM не просто заучить правила, а выработать устойчивые паттерны поведения, начиная с базового запрета на галлюцинации и заканчивая способностью самостоятельно структурировать сложные задачи.
 

Глава 6. Применяем логопедическую коррекцию в системе с обратной связью

 

6.1. Как менялась архитектура чанков

На примере конкретной задачи — программное создание формы в расширении 1С — проследим эволюцию чанков от v1 к v3 и покажем, как добавление обратной связи превращает статическую инструкцию в терапевтический цикл.

Исходная задача: добавить реквизит «Маркируемый товар» в табличную часть документа «Заказ клиента» в расширении, настроить его заполнение и условное оформление строк с маркируемыми товарами.

ЧАНК v1: линейная инструкция (что делать)

Версия v1 — это просто список требований. Модель получает инструкцию и пытается выполнить её за один проход. Обратная связь отсутствует.

ЧАНК 1.0: Программное создание формы в расширении Требования: 1. Добавь реквизит СРС_МаркируемыйТовар в табличную часть Товары 2. Добавь скрытое поле для этого реквизита на форму 3. Напиши процедуру заполнения флага при изменении номенклатуры 4. Настрой условное оформление: синий жирный шрифт для строк с флагом = 1
Как работает v1:
  • Модель генерирует код за один раз
  • Нет проверки результата
  • Нет возможности исправить ошибки
  • Если модель ошиблась, разработчик правит вручную
Типичные ошибки v1:
  • Реквизит добавлен, но поле не скрыто
  • Процедура заполнения написана, но не вызывается при изменении номенклатуры
  • Условное оформление настроено, но не работает из-за очистки в типовой конфигурации

Результат: код есть, но требует ручной доработки. Разработчик тратит время на поиск и исправление ошибок.

ЧАНК v2: графовая модель с параметрами (как разделить)

Версия v2 добавляет структуру и параметризацию. Модель получает не список, а граф с этапами и ролями. Но обратная связь всё ещё отсутствует — модель делает один проход, просто более организованный.

ЧАНК 2.0: Программное создание формы в расширении [ЭТАП] Анализ - Определи, есть ли в типовой конфигурации процедура УстановитьУсловноеОформление - Проверь, очищается ли она при создании формы [ЭТАП] Проектирование - Реквизит: СРС_МаркируемыйТовар (тип Число, путь: Объект.Товары) - Поле: скрытое, расположение — после колонки Номенклатура - Процедура заполнения: СРС_ЗаполнитьФлагиМаркируемыхТоваров - Условное оформление: через &После(«УстановитьУсловноеОформление») [ЭТАП] Разработка - Код для добавления реквизита и поля - Код для заполнения флагов - Код для условного оформления [ЭТАП] Проверка - Проверь, что поле скрыто - Проверь, что условное оформление применяется
Как работает v2:
  • Модель получает структурированное задание с этапами
  • Этапы помогают не смешивать разнородные задачи
  • Параметры (тип, путь, расположение) заданы явно
Типичные ошибки v2:
  • Модель может угадать не те параметры
  • Нет механизма проверки, что &После действительно использован
  • При ошибке — всё равно ручная правка

Результат: код лучше структурирован, но ошибки всё ещё остаются. Модель «угадывает» детали, а не знает их.

ЧАНК v3: логопедическая модель с обратной связью (как научить)

Версия v3 добавляет главное — обратную связь. Чанк превращается в сценарий упражнения, где модель не просто получает инструкцию, а проходит цикл: генерация → проверка → коррекция → закрепление.

ЧАНК 3.0: Программное создание формы в расширении --- ГНОЗИС (узнавание) --- description: Используй этот чанк, когда нужно добавить реквизит в табличную часть формы документа в расширении, настроить его заполнение и условное оформление. symptoms: - Условное оформление не применяется, хотя настроено - Добавленный реквизит не виден в коде - Процедура заполнения не вызывается --- ПРАКСИС (алгоритм с обратной связью) --- Цикл упражнения: 1. Сгенерируй код по шаблону 2. Запусти валидатор 3. Если ошибка — получи антипример и исправь 4. Повтори до 3 успехов подряд --- ПРОСОДИКА (иерархия правил) --- Критическое правило (вес 0.6): Используй &После(«УстановитьУсловноеОформление») для оформления. Без этого условное оформление будет очищено типовой конфигурацией. Второстепенные правила (вес 0.3): - Реквизит добавляй через РеквизитФормы с путём Объект.Товары - Поле создавай скрытым через Элементы.Вставить() - Заполнение флагов вызывай в ПриСозданииНаСервере и при изменении номенклатуры Исключения (вес 0.1): - Если форма не использует типовую процедуру УстановитьУсловноеОформление --- ДИАГНОСТИЧЕСКАЯ ЦЕПОЧКА --- Симптом: условное оформление не работает в расширении Диагностика: типовая процедура УстановитьУсловноеОформление() очищает свойство УсловноеОформление Заключение: настройки из конфигуратора не применяются Объяснение: сначала загружаются настройки из конфигуратора, потом вызывается процедура, которая их очищает Рекомендация: использовать &После(«УстановитьУсловноеОформление») для добавления, а не замены --- ВАЛИДАЦИЯ --- scripts/validate_extension.py проверяет: - Реквизит добавлен с правильным путём - Поле скрыто - &После присутствует в коде условного оформления - Процедура заполнения вызывается в ПриСозданииНаСервере - Условие отбора использует поле СРС_МаркируемыйТовар --- ВАРИАЦИИ (для закрепления) --- Вариация 1: добавить реквизит в другой документ Вариация 2: добавить реквизит в справочник Вариация 3: добавить условное оформление по другому условию
Как работает v3:
  • Модель получает не инструкцию, а сценарий упражнения
  • После каждой генерации запускается валидатор
  • При ошибке модель видит антипример и исправляется
  • Закрепление через вариации
🔄 Типичные ошибки v3 и их исправление:
Ошибка Как выявляется Обратная связь
Прямое обращение через точку validate_paraphasia.py «Ошибка: парафазия. Вместо прямого обращения используй ОбщегоНазначения.ЗначенияРеквизитовОбъекта»
Отсутствие &После validate_extension.py «Ошибка: условное оформление будет очищено. Добавь &После(«УстановитьУсловноеОформление»)»
Поле не скрыто validate_extension.py «Ошибка: поле видимо. Установи Видимость = Ложь»
Процедура не вызывается validate_extension.py «Ошибка: процедура не вызывается. Добавь вызов в ПриСозданииНаСервере»

Результат: модель не просто генерирует код, а учится на ошибках. После 3 успешных вариаций паттерн закрепляется.

🎯 Что даёт v3 разработчику?

Эволюция чанков от v1 к v3 — это движение от статической инструкции к динамическому терапевтическому циклу. Но главное — это движение от ручной работы к автоматизации.

Версия Разработчик делает Модель делает Результат
v1 Пишет инструкцию → правит ошибки вручную Генерирует код с ошибками Код требует доработки
v2 Структурирует требования → всё равно правит Генерирует структурированный код с ошибками Меньше правок, но ошибки всё ещё есть
v3 Описывает симптомы → запускает --therapy-wizard Проходит цикл: генерация → проверка → коррекция → закрепление Отработанный паттерн, который воспроизводится в следующих задачах

Ключевое: в v3 разработчик перестаёт быть "исправителем ошибок". Он становится архитектором навыков, который:

  • Определяет симптомы проблемы (через диагностическую анкету)
  • Запускает --therapy-wizard
  • Получает готовый навык (Agent Skill), который можно применить в Claude Code

Это и есть инженерный инструмент с предсказуемым результатом.

Сравнение версий: таблица

Характеристика v1 v2 v3
Формат Линейный список Граф с этапами Сценарий упражнения
Обратная связь Нет Нет Есть (валидатор + коррекция)
Итеративность Один проход Один проход Цикл до 3 успехов
Проверка результата Ручная Ручная Автоматическая (скрипты)
Объяснение ошибок Нет Нет Антипример + рекомендация
Закрепление Нет Нет Вариации
Что получает модель «Сделай» «Сделай по этапам» «Сделай, проверь, исправь, повтори»
Результат Код с ошибками Структурированный код с ошибками Отработанный паттерн

Логопедическая аналогия

Этап логопедии v1 v2 v3
Обследование — — Гнозис (симптомы)
Диагноз — — Диагностическая цепочка
Карточка с упражнением Список правил Параметризованный список Сценарий с вариациями
Занятие — — Цикл: разминка → упражнение → проверка → коррекция → закрепление
Обратная связь — — Антипример + рекомендация
Автоматизация — — 3 успешных вариации подряд

Что даёт обратная связь в системе

До обратной связи (v1–v2):
  • Модель делает один проход
  • Разработчик видит ошибки, правит вручную
  • Модель не «учится» — следующий запрос те же ошибки
С обратной связью (v3):
  • Модель делает несколько попыток в рамках одного диалога
  • Валидатор указывает на конкретную ошибку
  • Антипример показывает правильный паттерн
  • После исправления — переход к вариации
  • Паттерн закрепляется через повторение в разных контекстах

Результат: в следующих задачах модель уже реже допускает те же ошибки. Это не переобучение модели — это изменение распределения вероятностей в текущем контекстном окне через многократное предъявление правильного паттерна.

🎯 Вывод:

Эволюция чанков от v1 к v3 — это движение от статической инструкции к динамическому терапевтическому циклу. Ключевое отличие v3 — обратная связь. Модель не просто получает задание, а проходит путь: сгенерировала → получила ошибку → увидела антипример → исправила → повторила с вариацией. Только так можно не просто «дать инструкцию», а сформировать устойчивый паттерн.

 

Терапевтический чанк — это не просто набор правил, а сценарий терапевтического упражнения, предназначенный для LLM. Его структура следует логопедической логике: диагностика → коррекция → закрепление.

6.2 Формат терапевтического чанка (динамический сценарий)

{ "id": "THERAPY_MODULE_1_EXERCISE_2", "name": "Тренировка: Точность термина (Парафазии)", "meta": { "type": "therapy_exercise", "module": 1, "exercise_type": "discrimination", // discrimination, correction, repetition "difficulty": 1, "target_symptoms": ["paraphasia", "neologism"], "prerequisite_skill": "none" }, "activation": { "description": "Используй этот чанк, когда модель демонстрирует подмену реквизитов (парафазии) и нуждается в тренировке точности терминов.", "keywords": ["парафазия", "подмена реквизитов", "точность терминов", "фонематический слух"] }, "therapy_protocol": { "goal": "Устранить подмену реквизитов. Сформировать привычку проверять существование реквизита.", "method": "Дифференциация паронимов", "critical_rule": "Используй только те реквизиты, которые явно перечислены в контексте. Любая замена реквизита считается ошибкой." }, "exercise": { "prompt_template": "В контексте даны реквизиты: {реквизиты}. Напиши код, который получает значение реквизита \"{целевой_реквизит}\" из объекта \"{объект}\". Используй только метод ОбщегоНазначения.ЗначенияРеквизитовОбъекта.", "validation": { "type": "static_analysis", "check": "В сгенерированном коде должен использоваться метод 'ОбщегоНазначения.ЗначенияРеквизитовОбъекта' с аргументом '{целевой_реквизит}'. Любое обращение через точку (Объект.ЦелевойРеквизит) или к другому реквизиту считается ошибкой." }, "variations": [ { "реквизиты": ["Наименование", "Код"], "целевой_реквизит": "Наименование", "объект": "Товар" }, { "реквизиты": ["ДатаНачала", "ДатаОкончания"], "целевой_реквизит": "ДатаОкончания", "объект": "Документ" } ] }, "feedback": { "positive": "Отлично! Ты использовал правильный метод и точный реквизит.", "negative": "Ошибка: парафазия. Вместо реквизита '{неправильный}' нужно было использовать '{правильный}'. Помни: используй только явно перечисленные реквизиты." }, "completion_criteria": { "successful_generations": 3, "consecutive": true, "metric": "accuracy_terms" } }

Пояснение полей

Поле Назначение
id Уникальный идентификатор чанка (строка, допускаются символы)
name Краткое человекочитаемое название упражнения
meta Техническая метаинформация: тип, номер модуля, тип упражнения, целевые симптомы
activation Гнозис — то, по чему система решает, активировать ли чанк (триггер для поиска и отбора)
therapy_protocol Цель упражнения, метод и критическое правило — краткое описание терапевтического замысла
exercise Собственно сценарий: шаблон промпта с переменными, критерии валидации, список вариаций (для закрепления)
feedback Позитивная и негативная обратная связь (с поддержкой подстановки конкретных значений)
completion_criteria Условия успешного завершения упражнения: количество успешных попыток, обязательность последовательности, метрика успеха

Ключевые принципы

📂 Прогрессивное раскрытие

Чанк содержит только триггер (activation) и краткий протокол; детали упражнения раскрываются в exercise, а валидация и скрипты вынесены в отдельные модули.

🏃 Принцип «проживания»

Упражнение содержит несколько вариаций, через которые модель проходит последовательно, закрепляя паттерн.

💬 Автоматическая обратная связь

validation описывает, как именно проверять результат, а feedback содержит шаблоны для коррекции.

📊 Измеримый критерий завершения

Чанк сам определяет, когда упражнение усвоено (например, 3 успешные попытки подряд).

6.3 Протокол сеанса терапии

Сеанс терапии — это итеративный цикл, который должен быть автоматизирован в --therapy-wizard.

Разминка (Активация)

Действие: Система предъявляет краткий мета-промпт, напоминающий о критических правилах модуля.

Пример: «Напоминаю: в этом сеансе мы тренируем точность терминов. Используй только реквизиты, перечисленные в контексте. Замена реквизитов запрещена».

Основное упражнение (Генерация)

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

Пример: (Из чанка выше) — подставлена первая вариация.

Проверка (Выявление ошибок)

Действие: Система запускает валидатор (статический анализ кода, поиск ключевых слов). Если ошибок нет — переход к шагу 5.

Пример: Валидатор находит Товар.Наименование вместо ОбщегоНазначения.ЗначенияРеквизитовОбъекта(Товар, "Наименование").

Коррекция (Обратная связь)

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

Пример: «Ошибка: парафазия. Вместо прямого обращения Товар.Наименование нужно использовать ОбщегоНазначения.ЗначенияРеквизитовОбъекта(Товар, "Наименование"). Это защищает код от ошибок, если реквизит не существует. Попробуй снова».

Закрепление (Повторение с вариацией)

Действие: Если проверка пройдена, система выбирает следующую вариацию из упражнения и повторяет шаг 2. Если в упражнении есть 3 вариации, они предъявляются последовательно.

Условие: Если модель ошибается в одной из вариаций, цикл (шаги 3-4) повторяется для этой же вариации.

Завершение упражнения

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

6.4 Метрики прогресса

Модуль Метрика Порог успеха Способ измерения
0. Базис Галлюцинации (несуществующие объекты) 0 на 10 генераций Статический анализ кода, поиск несуществующих реквизитов/методов из метаданных.
1. Фонематика Точность терминов 100% (0 парафазий) на 10 генераций Статический анализ, сравнение использованных реквизитов с перечнем из контекста.
2. Грамматика Соблюдение директив компиляции 100% на 5 генераций сложного кода Статический анализ, проверка &НаСервере/&НаКлиенте на корректность вызовов.
3. Контекст Корректность кода для расширений 100% на 5 генераций Статический анализ, проверка наличия &После, отсутствие переопределений.
4. Просодика Соблюдение приоритетов 100% в 5 задачах с конфликтами Экспертная оценка или статический анализ (наличие НачатьТранзакцию(), Попытка...Исключение в критических местах).
5. Связность Отсутствие контаминаций 0 контаминаций в 3 сложных задачах Экспертная оценка структуры ответа, разделение на этапы.
📌 Ключевая идея протокола сеанса: Каждый сеанс — это автоматизированный цикл "активация → генерация → проверка → коррекция → закрепление". Модель не просто получает инструкцию, а последовательно проходит через вариации упражнения, получая обратную связь при каждой ошибке. Это позволяет LLM «прожить» правильный паттерн многократно, повышая его вес в вероятностном распределении и формируя устойчивый навык.
🎯 Критерий перехода между упражнениями: 3 успешные генерации подряд для текущей вариации → переход к следующей вариации. Все вариации упражнения выполнены успешно → упражнение завершено. Все упражнения модуля завершены → модуль пройден, переход к следующему модулю.

 

Глава 7. Интеграция с Chunk Advisor v3

7.1 Терапевтический режим --therapy-wizard

Терапевтический режим --therapy-wizard запускает полный цикл: диагностика (12 вопросов) → построение маршрута (выбор модулей 0–5) → проведение сеансов с отслеживанием прогресса. Прогресс хранится в SQLite. Чанки типа therapy_exercise используются только в терапевтическом режиме, не смешиваясь с обычными чанками-инструкциями.

Архитектура терапевтического режима

--therapy-wizard (новый режим): Запускает интерактивный процесс.

Шаг 1: Диагностика
Использует 12 вопросов из статьи (это всего лишь примерный список — далеко не продуманный и не окончательный вариант). Это самая главная, но пока не проработанная часть. Данную диагностику еще предстоит глубоко развивать на контексте нашей предметной области.
Шаг 2: Построение маршрута
Выбор модулей 0–5 на основе диагностики.
Шаг 3: Запуск сеанса терапии
По протоколу, описанному в Главе 6.

7.2 Хранение прогресса (SQLite)

-- Таблица therapy_sessions CREATE TABLE therapy_sessions ( id INTEGER PRIMARY KEY AUTOINCREMENT, model_id TEXT NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME, status TEXT DEFAULT 'in_progress' -- in_progress, completed, aborted ); -- Таблица module_progress CREATE TABLE module_progress ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id INTEGER NOT NULL, module_id INTEGER NOT NULL, -- 0..5 current_exercise_id TEXT, consecutive_successes INTEGER DEFAULT 0, total_attempts INTEGER DEFAULT 0, status TEXT DEFAULT 'locked', -- locked, in_progress, completed FOREIGN KEY (session_id) REFERENCES therapy_sessions(id) ); -- Таблица exercise_attempts CREATE TABLE exercise_attempts ( id INTEGER PRIMARY KEY AUTOINCREMENT, module_progress_id INTEGER NOT NULL, exercise_id TEXT NOT NULL, variation_index INTEGER NOT NULL, success BOOLEAN NOT NULL, generated_code TEXT, error_message TEXT, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (module_progress_id) REFERENCES module_progress(id) );

7.3 Логика выбора и перехода

  • Программа читает module_progress. Начинает с самого низкого незавершенного модуля (0, затем 1...).
  • Внутри модуля выбирает текущее упражнение. Для упражнения выбирает первую непройденную вариацию.
  • После каждой попытки обновляет exercise_attempts.
  • Если consecutive_successes для упражнения достигает 3 (или другого критерия из чанка), упражнение считается пройденным, и программа переходит к следующему.
  • Когда все упражнения модуля пройдены, модуль помечается как completed, и программа переходит к следующему модулю.

7.4 Интеграция с существующими чанками

  • Терапевтические чанки (с типом therapy_exercise) хранятся в отдельной папке или имеют специальный флаг.
  • Во время сеанса терапии, --therapy-wizard генерирует промпты, строго следуя prompt_template и validation из терапевтического чанка, игнорируя обычные чанки-инструкции (чтобы не смешивать терапию с обычной работой).

Чанк, который является единицей векторной базы знаний CHUNK ADVISOR V3, призван стать волшебной палочкой и инструментом решения проблем благодаря лечебной для ИИ организации.

7.5 Следующий горизонт: векторная база знаний

Следующий горизонт — переход от статического графа к динамической векторной базе знаний, где:

  • Чанки хранятся не как JSON с терминами, а как эмбеддинги
  • Поиск релевантных чанков идёт не по ключевым словам, а по семантической близости
  • Модель (локально через Ollama) сама определяет, какие чанки "притягиваются" по смыслу
RAW здесь означает:
  • Чанки хранятся в "сыром" виде — как текст + эмбеддинги
  • Нет предопределённых связей (как в графе V2)
  • Связи вычисляются на лету через косинусную близость векторов

Сравнение решений для векторной базы знаний

Решение Язык Векторное хранилище Особенность Сложность
AI-Knowledge-Base-Agent Python FAISS + SQLite Готовый UI, простой старт Низкая
GraphRAG-Ollama Python FAISS Header-aware chunking, оптимизация Средняя
RAG Builder JS + Python ChromaDB GitHub интеграция, API Средняя
LocalKB JavaScript SQLite (BLOB) Нет отдельной БД, FTS5 Низкая
RinfoMaid Rust TF-IDF CLI, минимализм Низкая
AI-KM JS/Electron Кастомная Workflow designer Высокая

Рекомендация для Chunk Advisor

Для проекта Chunk Advisor с логопедической моделью V3:

  • Для быстрого прототипа: AI-Knowledge-Base-Agent — даёт готовый UI и полный цикл RAG за 15 минут
  • Для продакшена: RAG Builder или GraphRAG-Ollama — поддержка нескольких источников, гибридный поиск, Docker-развёртывание
  • Для интеграции с существующим кодом: LocalKB — простая архитектура на SQLite, легко модифицировать под логопедическую модель

Ключевая идея для Chunk Advisor: можно адаптировать LocalKB или AI-Knowledge-Base-Agent, заменив стандартное чанкирование на вашу логопедическую модель (гнозис → праксис → просодика → диагностическая цепочка). Векторная база будет хранить не просто текст, а структурированные чанки V3, а поиск будет идти по семантической близости диагностических симптомов.

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

 
 В Chunk Advisor v3 есть место логопедической модели

 

📌 Итоговая архитектура Chunk Advisor v3:

Chunk Advisor v3 — это не просто база чанков и не просто терапевт для LLM. Это инженерная среда, которая позволяет разработчику создавать и отлаживать навыки (Agent Skills) для LLM, используя проверенную логопедическую методологию как гарантию их качества. Терапевтический режим --therapy-wizard автоматизирует полный цикл коррекции: от диагностики через 12 вопросов до проведения сеансов с отслеживанием прогресса в SQLite. А следующий горизонт — переход к динамической векторной базе знаний — превратит статичные чанки в живую, самоорганизующуюся систему, где связи вычисляются на лету через семантическую близость.

🎯 Chunk Advisor v3: от концепции к инструменту

Подведём итог. Мы начали с гипотезы: LLM демонстрирует те же речевые нарушения, что и дети с расстройствами речи. Затем:

  1. Разобрали индустриальный стандарт Agent Skills — как ИИ-агенты работают с навыками
  2. Описали логопедическую методологию — как диагностировать и корректировать нарушения
  3. Построили 6 терапевтических модулей (М0–М5) — от базиса до связности
  4. Создали формат терапевтического чанка — сценарий упражнения с вариациями
  5. Описали протокол сеанса — цикл с обратной связью и закреплением
  6. Спроектировали --therapy-wizard — автоматизацию всего цикла

Chunk Advisor v3 =
(логопедическая методология)
× (стандарт Agent Skills)
× (автоматизация через --therapy-wizard)
инженерный инструмент для создания навыков с предсказуемым результатом

Что получает разработчик:

  • Диагностику — 12 вопросов выявляют профиль ошибок LLM
  • Маршрут — индивидуальный набор модулей (М0–М5)
  • Сеанс — автоматизированный цикл с обратной связью
  • Навык — готовый Agent Skill, который можно использовать в Claude Code
  • Прогресс — хранение в SQLite, возможность продолжить позже

Следующий горизонт — векторная база знаний, где чанки хранятся как эмбеддинги, а поиск идёт по семантической близости симптомов. Это превратит статичный граф связей в живую, самоорганизующуюся систему.

Логопедический подход к чанкам — это способ обучить ИИ не языку, а методу. А Chunk Advisor v3 — это инструмент, который делает этот метод доступным для каждого 1С-разработчика.

 

Глава 8. Проект технического задания Chunk Advisor v3

На основе описанной логопедической методологии, адаптации стандарта Agent Skills и спроектированной архитектуры сформулируем техническое задание для реализации Chunk Advisor v3.

8.1. Назначение и цели разработки

Назначение: Chunk Advisor v3 — это инструмент командной строки (CLI) и библиотека для создания, тестирования и отладки навыков (Agent Skills) для LLM в контексте 1С-разработки.

Цели:

  • Обеспечить предсказуемое качество кода, генерируемого LLM, через системную коррекцию типовых ошибок
  • Автоматизировать процесс создания навыков (Agent Skills) с гарантией их эффективности
  • Сократить время разработчика на исправление ошибок LLM с ручного до автоматического

Целевая аудитория:

  • 1С-разработчики, использующие LLM (Claude Code, GitHub Copilot, OpenAI) для генерации кода
  • Технические лиды, внедряющие стандарты качества кода в командах
  • Исследователи в области применения LLM в предметных областях

8.2. Функциональные требования

8.2.1. Режимы работы

Режим Команда Описание
Диагностика chunk-advisor diagnose Проводит опрос по 12+ вопросам, формирует профиль дефицитов LLM
Построение маршрута chunk-advisor route --profile <file> На основе профиля выбирает модули М0–М5 и формирует порядок прохождения
Сеанс терапии chunk-advisor therapy --route <file> Запускает интерактивный сеанс коррекции по выбранному маршруту
Создание навыка chunk-advisor create-skill --from-chunks <ids> Из набора диагностических карточек собирает готовый Agent Skill (папку с SKILL.md)
Оценка навыка chunk-advisor evaluate --skill <path> Запускает тесты (evals) для проверки качества навыка

8.2.2. Диагностический модуль

Вход: Ответы на диагностические вопросы (12–20 вопросов, адаптируемых под предметную область)

Выход: JSON-профиль дефицитов

{ "profile_id": "uuid", "timestamp": "2026-03-29T10:00:00Z", "deficits": { "regulation": 0.7, "phonematics": 0.2, "grammar": 0.5, "prosody": 0.1, "coherence": 0.3 }, "symptoms": ["paraphasia", "agrammatism"], "recommended_modules": [0, 1, 2] }

Требования:

  • Вопросы должны быть параметризуемы под предметную область (1С, Python, SQL и т.д.)
  • Возможность импорта/экспорта профиля

8.2.3. Терапевтические модули

Структура каждого модуля:

modules/ M0_basis/ exercises/ request_context.json safe_access.json existence_check.json validation/ validate_paraphasia.py validate_extension.py prompts/ templates/ M1_phonematics/ ... ...

Требования:

  • Модули независимы, но имеют явные зависимости (M1 требует M0)
  • Каждый модуль содержит 3–5 упражнений
  • Каждое упражнение содержит 3–5 вариаций
  • Валидаторы реализованы на Python и могут быть расширены пользователем

8.2.4. Протокол сеанса терапии

Цикл сеанса:

  1. Разминка (активация) → системный промпт с правилами модуля
  2. Генерация → подстановка вариации из упражнения
  3. Валидация → запуск скрипта проверки
  4. Коррекция → при ошибке: антипример + рекомендация
  5. Закрепление → при успехе: следующая вариация
  6. Переход → 3 успеха подряд → следующее упражнение

Требования:

  • Поддержка интерактивного и пакетного режима
  • Возможность прерывания и возобновления сеанса
  • Логирование всех попыток

8.2.5. Хранение прогресса (SQLite)

Схема базы данных:

-- Сеансы терапии CREATE TABLE therapy_sessions ( id TEXT PRIMARY KEY, model_id TEXT NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME, status TEXT DEFAULT 'in_progress' ); -- Прогресс по модулям CREATE TABLE module_progress ( id TEXT PRIMARY KEY, session_id TEXT NOT NULL, module_id INTEGER NOT NULL, current_exercise_id TEXT, consecutive_successes INTEGER DEFAULT 0, total_attempts INTEGER DEFAULT 0, status TEXT DEFAULT 'locked', FOREIGN KEY (session_id) REFERENCES therapy_sessions(id) ); -- Попытки выполнения упражнений CREATE TABLE exercise_attempts ( id TEXT PRIMARY KEY, module_progress_id TEXT NOT NULL, exercise_id TEXT NOT NULL, variation_index INTEGER NOT NULL, success BOOLEAN NOT NULL, generated_code TEXT, error_message TEXT, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (module_progress_id) REFERENCES module_progress(id) );

8.2.6. Создание навыков (Agent Skills)

Вход: Набор диагностических карточек (чанков v3) или идентификаторов упражнений

Выход: Папка со структурой Agent Skill:

generated_skill/ SKILL.md scripts/ validate.py references/ metadata.json assets/ templates/

Требования:

  • Автоматическая генерация YAML-шапки (name, description) на основе гнозиса карточек
  • Автоматическая сборка SKILL.md из диагностических цепочек, праксиса и просодики
  • Копирование валидаторов из соответствующих модулей

8.2.7. Оценка навыков

Вход: Путь к папке навыка, набор тестовых промптов (evals)

Выход: JSON-отчёт с метриками:

{ "skill_name": "therapy-phonematics-1", "evals": [ { "id": 1, "prompt": "...", "with_skill": {"success": true, "duration_ms": 1234, "tokens": 500}, "without_skill": {"success": false, "duration_ms": 900, "tokens": 400}, "delta": {"success": true, "duration": 334, "tokens": 100} } ], "aggregate": { "pass_rate_with_skill": 0.9, "pass_rate_without_skill": 0.6, "avg_duration_delta": 234, "avg_token_delta": 150 } }

8.3. Нефункциональные требования

Категория Требование
Платформа Python 3.10+, поддержка Windows/Linux/macOS
Зависимости SQLite3 (встроенный), поддержка Ollama (опционально)
Производительность Сеанс терапии из 10 упражнений — не более 5 минут
Расширяемость Пользователь может добавлять свои модули, упражнения, валидаторы
Локализация Русский язык интерфейса, поддержка английского в перспективе
Документация Встроенная справка (--help), Markdown-документация в репозитории

8.4. Архитектурные решения

8.4.1. Компонентная схема

Chunk Advisor v3 - CLI (click/argparse) - Diagnostic Module - Therapy Engine - Skill Builder - Evaluator Module - Storage Layer (SQLite) - Vector Store (FAISS / ChromaDB) — опционально для семантического поиска

8.4.2. Формат диагностической карточки (чанк v3)

{ "id": "chunk_016_conditional_formatting", "gnosis": { "keywords": ["условное оформление", "динамический список", "подсветка строк"], "symptoms": ["оформление не работает", "настройки теряются"], "context": ["расширения", "типовые конфигурации"] }, "praxis": { "algorithm": ["шаг 1", "шаг 2"], "code_example": "...", "verification": "..." }, "prosody": { "critical_rules": [{"rule": "...", "weight": 0.6}], "secondary_rules": [{"rule": "...", "weight": 0.3}], "exceptions": [{"rule": "...", "weight": 0.1}] }, "diagnostic_chain": { "symptom": "...", "diagnosis": "...", "conclusion": "...", "explanation": "...", "recommendation": "..." }, "coherence": { "lexical_core": ["термин1", "термин2"], "grammatical_structure": "...", "logical_links": ["если...то..."] } }

8.5. Этапы разработки

Этап Срок Результат
Этап 0. Прототип 2 недели CLI с режимами diagnose и therapy, 2 модуля (М0, М1)
Этап 1. Базовый функционал 3 недели Все 6 модулей, SQLite, создание навыков из карточек
Этап 2. Оценка и тестирование 2 недели Система evals, бенчмарки, интеграция с Claude Code
Этап 3. Векторная база 3 недели Ollama + FAISS, семантический поиск карточек
Этап 4. Промышленная версия 3 недели Документация, CI/CD, тестовое покрытие >80%

8.6. Критерии приемки

  1. Диагностика: Формирует профиль, сопоставимый с экспертной оценкой (совпадение >80%)
  2. Терапия: Модель, прошедшая сеанс по М0–М5, демонстрирует снижение типовых ошибок на 50%+
  3. Создание навыков: Сгенерированный Skill проходит валидацию и корректно работает в Claude Code
  4. Производительность: Сеанс из 10 упражнений — не более 5 минут
  5. Расширяемость: Разработчик может добавить новый модуль без изменения ядра

8.7. Риски и их митигация

Риск Вероятность Митигация
Изменение API LLM (Claude, OpenAI) Средняя Абстрактный слой вызовов, поддержка нескольких провайдеров
Сложность диагностики (12 вопросов) Высокая Итеративное уточнение вопросов на реальных кейсах, A/B-тестирование
Производительность валидаторов Низкая Оптимизация через кэширование результатов парсинга
Несовместимость с версиями 1С Средняя Параметризация через references/metadata.json

8.8. Открытые вопросы

  1. Диагностическая анкета: 12 вопросов — это стартовая точка. Нужно ли расширять до 20? Какие вопросы наиболее диагностичны?
  2. Векторное хранилище: FAISS или ChromaDB? Какой лучше для семантического поиска по симптомам?
  3. Интеграция с IDE: Нужен ли плагин для VS Code/BSL Language Server или достаточно CLI?
  4. Модель для эмбеддингов: Ollama с какой именно моделью (например, nomic-embed-text) даёт лучшее качество для русскоязычных терминов 1С?

8.9. Лучшие практики создания навыков (сводный чек-лист)

При создании навыков для Chunk Advisor v3 рекомендуется соблюдать следующие принципы:

Базовые (из стандарта Agent Skills)

[ ] Чанк основан на реальном опыте, а не на абстрактных рассуждениях
[ ] Есть раздел «подводных камней» (diagnostic_chain)
[ ] Есть антипримеры (feedback.negative)
[ ] Соблюдено прогрессивное раскрытие (гнозис U94; праксис -ресурсы)
[ ] Степень детализации калибрована через веса (0.6 / 0.3 / 0.1)

Инженерные (из опыта промптинга)

[ ] В начале указан результат, потом контекст
[ ] Один чанк решает одну проблему (цельность)
[ ] Ограничения сформулированы явно (вес 0.6)
[ ] Использованы разделители ([ГНОЗИС], [ПРАКСИС], [ПРОСОДИКА])
[ ] Для сложных задач добавлен запрос уточнений

Логопедические (для коррекции LLM)

[ ] Критические правила сформулированы позитивно (не «не делай», а «делай»)
[ ] Критические требования вынесены в отдельный блок
[ ] Антипримеры даны рядом с правильными вариантами
[ ] Модель принудительно запрашивает метаданные (М0)
[ ] Предусмотрены вариации для закрепления (3+)
[ ] Критерий перехода — 3 успеха подряд

Итог: Соблюдение этого чек-листа гарантирует, что созданный навык будет диагностируемым, обучаемым и дающим предсказуемый результат при работе с LLM.

Chunk Advisor v3: от логопедической метафоры к инженерному инструменту с предсказуемым результатом.

Chunk Advisor v3 =
    (логопедическая методология)
    × (стандарт Agent Skills)
    × (автоматизация через --therapy-wizard)
    → инженерный инструмент для создания навыков с предсказуемым результатом

Вступайте в нашу телеграмм-группу Инфостарт

промптинг prompt engineering промпт инженеринг prompt design prompt optimization Кластер агентных систем ИИ агент AI agent architecture agent skills SKILL.md AI agent pipeline Кластер навыков и архитектуры LLM skills skill-based prompting AI workflow pipeline agent

+11 –1

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Infostart MCP: готовые MCP серверы для вайбкодинга в 1С

Инструментарий разработчика Нейросети Платные (руб)

Первые попытки разработки на 1С с использованием больших языковых моделей (LLM) могут разочаровать. LLMки сильно галлюцинируют, потому что не знают устройства конфигураций 1С, не знают нюансов синтаксиса. Но если дать им подсказки с помощью MCP, то результат получается кардинально лучше. Далее в публикации: MCP для поиска по метаданным 1С, справке синтакс-помощника и проверки синтаксиса.

15250 руб.

25.08.2025    57426    116    32    

126
Искусственный интеллект и нейросети в 1С: Работа с отзывами маркетплейсов

Нейросети Пользователь 1С:Предприятие 8 1С:Управление нашей фирмой 1.6 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 Оптовая торговля, дистрибуция, логистика Россия Управленческий учет Платные (руб)

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

6100 руб.

03.04.2024    15719    8    0    

12
OneBase за десять дней: управляемые формы, 14 языков интерфейса, точные деньги и инструменты для разработки с ИИ

Нейросети Программист Бесплатно (free)

За десять дней после релиза OneBase получила полноценные управляемые формы, локализацию интерфейса на 14 языков, точную денежную арифметику на decimal, систему ролей и прав, новый REST API и набор CLI-инструментов для разработки совместно с ИИ. Разбираю ключевые изменения платформы, показываю новые возможности и делюсь результатами одной из самых насыщенных недель развития проекта.

05.06.2026    379    Ibrogim    13    

6
Инвентаризация доработок 1С перед большим обновлением: как ИИ помогает разобраться в отчетах, обработках и расширениях

Нейросети Обновление 1С Бесплатно (free)

Когда доработанную 1С не обновляли годами, начинать приходится не с переноса кода, а с разбора того, что вообще накопилось в базе. Там могут быть десятки обработок, расширения, правки типовых объектов, а документации либо нет, либо она давно не актуальна. На примере реального обновления разбираем, как кодовые агенты, MCP-серверы и языковые модели помогают навести порядок в доработках, собрать план миграции, понять, где при переносе будут проблемы, и автоматизировать часть исправлений.

05.06.2026    886    wonderboy    1    

10
ИИ сделал внешнюю обработку за 19 минут. За сколько сделаешь ты?

Нейросети Программист Бесплатно (free)

ИИ сделал внешнюю обработку за 19 минут, собрал EPF без входа в Конфигуратор, и она заработала с первого раза! Да, звучит как кликбейт, но это был живой стрим, а не вылизанное демо. В статье показываю стенды, замеры, скиллы, MCP и честные ограничения — чтобы скептики спорили не лозунгами, а своими примерами.

04.06.2026    2074    top_1c    144    

45
ИИ-помощник на чистом 1С: MVP своими руками за 30 минут

Нейросети Программист Бесплатно (free)

Расскажем, как создать ИИ-помощника внутри 1С без Python и другого внешнего кода – только на базе 1С, HTTP-запросов и необходимой инфраструктуры. Разберем универсальный шаблон RAG-системы, который можно адаптировать под разные задачи: от поддержки пользователей и поиска по базе знаний до работы с регламентами и инструкциями. На живом примере соберем минимальный рабочий прототип помощника, который умеет работать с данными, искать релевантный контекст и формировать ответы. Отдельно объясним, почему самым сложным этапом оказывается не архитектура, а качество подготовки данных и чанкинг.

04.06.2026    509    Palk    3    

6
rlm-tools-bsl: MCP-сервер, помогающий AI-агенту дешево и эффективно анализировать большие конфигурации 1С

Инструментарий разработчика Нейросети Программист 1С 8.3 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Бесплатно (free)

MCP-сервер для токен-эффективного анализа кодовых баз 1С (BSL) — 57 хелперов, SQLite-индекс, поддержка CF/EDT/CFE.

04.06.2026    3535    Dach    65    

22
1C Skills для ИИ-агентов

Нейросети Программист Бесплатно (free)

Набор локальных skills для ИИ-агентов под 1С: XML-исходники, EPF/ERF, формы, роли, веб-публикация и test bridge — HTTP-расширение для проверки тестовых баз без COM и UI.

02.06.2026    3403    Aleksandr    60    

29
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. GarriSoft 606 30.03.26 10:41 Сейчас в теме
Коллега, спасибо, статья крайне полезная, но для многих, в том числе и для меня было удобнее постепенное погружение в тему, может быть циклом статей.
+ – Ответить
3. ksnik 695 01.04.26 04:34 Сейчас в теме
(2)
(1)
самый простой способ превратить чат в лечебную для ИИ систему это попросить его "создать промпт для продолжения исследования" и проанализировать его ответ с применением инструмента.
+ – Ответить
2. starik-2005 3272 30.03.26 10:53 Сейчас в теме
Статья показывается, что лингвисты и филологи скоро вытеснят программистов, которые себя к филологам и лингвистам не причисляют. Так что играем в буриме...
+ – Ответить
4. ksnik 695 01.04.26 04:47 Сейчас в теме
(2) Играй в буриме. Самый простой способ превратить чат в лечебную систему — это попросить ИИ «создать промпт для продолжения исследования» и проанализировать его ответ с применением инструмента. Но здесь возникает ключевой вопрос: что должно быть в таком инструменте?

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

1. Что должен фиксировать инструмент

1.1 Диагностическую анкету промпта

Инструмент должен не просто передавать запрос, а фиксировать структуру того, что мы отправляем. По аналогии с диагностикой требований заказчика, промпт имеет свои «симптомы»:

Парафазия (подмена понятий) — есть ли в промпте термины, которые могут быть интерпретированы неоднозначно? Используется ли «сделай документ» вместо «создай документ Заказ клиента»?

Аграмматизм (нарушение структуры) — разделены ли в промпте цели, ограничения, примеры, критерии проверки? Или всё смешано в один абзац?

Эхолалия (повторение без понимания) — есть ли в промпте фрагменты, скопированные из других задач без адаптации под текущий контекст?

Контаминация (смешение требований) — смешаны ли в одном промпте анализ, проектирование, кодирование и проверка? Или они разнесены по этапам?

1.2 Карту ограничений

Инструмент должен проверять наличие обязательных элементов, без которых ответ ИИ не может быть осмысленным. По аналогии со списком «модуль объекта, движения по регистрам, подписки, места использования реквизита», для промпта это:

этап работы (анализ / проектирование / разработка / проверка / оптимизация)

критические ограничения (что нельзя нарушать ни при каких условиях)

проверяемый результат (что будет считаться успехом после применения)

запрещённые сочетания (какие требования нельзя смешивать в одном ответе)

источники данных (на какие метаданные, примеры, чанки опираться)

1.3 Журнал «назначенного лечения»

Инструмент должен фиксировать не только то, что мы отправили, но и то, как ИИ на это отреагировал, и какую коррекцию мы применили. Это аналог карты развития в логопедии:

исходный промпт — чтобы видеть, какие симптомы были до коррекции

ответ ИИ — чтобы диагностировать, какие дефициты проявились

наша коррекция (антипример, уточнение, переформулировка) — чтобы зафиксировать, какое «лечение» сработало

повторная генерация — чтобы проверить, усвоен ли паттерн

счётчик успешных попыток — чтобы понять, когда можно переходить к следующему этапу

2. Как должен работать инструмент

2.1 Режим «диагностика»

Инструмент принимает промпт и выдаёт его структурированный разбор:

Диагностика промпта:

Симптомы:

Парафазия: обнаружено неоднозначное «сделай документ» (уточните, какой именно)

Аграмматизм: цели, ограничения и примеры смешаны в одном абзаце

Контаминация: в одном запросе смешаны анализ и кодирование

Отсутствующие обязательные элементы:

Не указан этап работы

Нет проверяемого результата

Нет критических ограничений

Рекомендации:

Разделите запрос на этапы: сначала анализ метаданных, потом код

Добавьте: «Критическое правило: все изменения в транзакции»

Добавьте: «После генерации проверь, что ...»

2.2 Режим «терапия»

Инструмент не просто отправляет промпт, а ведёт сеанс:

Разминка — короткое напоминание о критических правилах (например, «помни: безопасность выше производительности»)

Генерация — отправка промпта и получение ответа

Проверка — автоматическая валидация ответа на наличие типовых ошибок (парафазий, пропущенных директив, отсутствия транзакций)

Коррекция — если ошибка найдена, предъявление антипримера и повторная генерация

Закрепление — после успешной генерации переход к следующей вариации

2.3 Режим «послерелизной проверки»

Инструмент помогает проверить, достигнут ли ожидаемый результат:

сопоставляет сгенерированный код с заданными критериями успеха

фиксирует, были ли в дальнейшем обращения в поддержку по этому функционалу

отмечает, появились ли новые ручные обходы

3. Что делает этот инструмент «лечебным»

Обычный чат — это разговор. Лечебная система — это цикл с обратной связью.

Обычный чат:

Отправил запрос → получил ответ

Ошибки исправляются вручную

Нет памяти о предыдущих ошибках

Нет критериев завершения

Лечебная система:

Отправил запрос → получил ответ → диагностировал ошибку → предъявил антипример → получил исправленный ответ → зафиксировал успех → перешёл к вариации

Ошибки выявляются автоматически, коррекция встроена в цикл

Есть журнал «назначенного лечения»: какие ошибки были, как исправлялись, сколько попыток потребовалось

Есть чёткие критерии: 3 успешные генерации подряд → переход к следующему этапу

4. Минимальный состав инструмента

Анкета промпта — чек-лист для диагностики симптомов

Список обязательных элементов — что должно быть в промпте, чтобы ответ был осмысленным

Валидатор ответа — автоматическая проверка на типовые ошибки (парафазии, пропущенные директивы, отсутствие транзакций)

Библиотека антипримеров — для каждого типа ошибки — готовый антипример и правильный вариант

Журнал сеанса — фиксация: промпт → ответ → ошибка → коррекция → повторная генерация

Критерии перехода — например, 3 успешные генерации подряд для закрепления паттерна

5. Ответ на вопрос КАК

Инструмент должен анализировать не только ответ, но и то, как был построен запрос. Потому что в большинстве случаев проблема не в том, что ИИ «плохо ответил», а в том, что запрос был построен так, что качественный ответ был невозможен.

ИИ не заменяет архитектуру, он заставляет её formalizovat. Инструмент, который я описываю, — это попытка формализовать архитектуру самого запроса. Чтобы перед каждым обращением к ИИ мы фиксировали:

какой этап работы идёт;

какие ограничения обязательны;

какие сочетания недопустимы;

что будет считаться успешным результатом.

Без этого даже самый умный ИИ остаётся быстрым и убедительным начётчиком. С этим — становится инструментом управления сложностью.

6. Вопрос для продолжения

Как вы думаете, какие элементы в этом списке лишние, а каких не хватает? И можно ли такой инструмент сделать не громоздким, чтобы им хотели пользоваться?
+ – Ответить
5. starik-2005 3272 01.04.26 10:34 Сейчас в теме
(4)
И можно ли такой инструмент сделать не громоздким, чтобы им хотели пользоваться?
Как сказал Крош Барашу, когда тот был "на высоте": "у тебя больше ответов, чем у нас вопросов". У читателей тут разрыв в понимании местности с картой образовался, который большинство из них даже с помощью ИИ не смогут преодолеть. Им нужен разжеванный классический гениально емкий и талантливо краткий ответ на вопрос: "зачем?"
ЗЫ: "написано без помощи ИИ" )
+ – Ответить
6. ksnik 695 01.04.26 10:50 Сейчас в теме
(5) 1. Зачем законы промптинга?

Чтобы ИИ перестал быть «чёрным ящиком». Не чтобы его заучить, а чтобы понять: промпт — это техническое задание. ТЗ бывают чёткими и размытыми. Законы — это просто напоминание, что размытое ТЗ даёт размытый результат.

2. Зачем скилл креатор?

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

3. Зачем агент скиллз?

Чтобы навыки можно было переиспользовать и проверять. Не держать в голове, а хранить в папке. Не гадать, сработает ли, а тестировать наборами вопросов. Не переписывать, а брать готовое.

4. Зачем коррекция нарушений?

Потому что ИИ — это не волшебник, а быстрый и убедительный начётчик. Он повторяет то, что видел, не проверяя, подходит ли это к вашей задаче. Коррекция нужна не ИИ. Она нужна, чтобы мы не принимали его уверенность за истину.

5. Зачем чанк адвизор?

Чтобы не лечить симптомы, а строить систему. Чанки — это не «очередные правила». Это способ сделать так, чтобы знание о том, что делает промпт качественным, перестало держаться в головах и стало частью процесса.

Главный тезис:

Чтобы формализовать и перестать удивляться, что ИИ отвечает ерундой, когда мы задаём ему размытый вопрос</b>.

Если коротко: все эти инструменты нужны, чтобы у нас было больше ответов, чем вопросов, когда мы уже начали что-то делать. А не наоборот.
starik-2005; +1 – Ответить
7. starik-2005 3272 01.04.26 10:52 Сейчас в теме
(6)
</b>.
В этом был какой-то смысл?
Чтобы формализовать и перестать удивляться, что ИИ отвечает ерундой
Уже лучше.
ЗЫ: с 1С очень сложно что-то вытащить с ИИ. Так что из 1С-него или получится "гениальный" промпт-директор, или нет. Остальным это необязательно. Я вчера за условные 30 минут "написал" в qwen code MCP для task. В итоге у меня промпт: "создай задачи на неделю, желаю похудеть на 2 кг" превращаются в нотификацию на телефоне за 15 минут до.
+ – Ответить
8. ksnik 695 01.04.26 10:56 Сейчас в теме
(7) формализовать это как раз метод одной строкой, цель предложенной Вами игры в буриме. Чтобы игра принесла конкретную пользу, как и промптинг может быть очень увлекательной игрой.

По поводу вытащить - я не испытываю проблеммы собирая данные из предприятия вручную. Очень много раскладываю пайтоном на кусочки замеры производительности и логи журнала транзакций. я бы сказал это большая часть в анализе.
+ – Ответить
9. starik-2005 3272 01.04.26 10:57 Сейчас в теме
(8)
игры в буриме
Буриме - про рифмы, про частотный ряд словоблудия, завертывание слов в строфы включая творчество.
+ – Ответить
10. ksnik 695 01.04.26 21:24 Сейчас в теме
(9) Статья — лишь карта, сложно знать,
Где броду нет, где топь, где гать.
Ты сделал MCP руками —
Прошу маршрут разведать с нами.
Ваш ход, starik-2005.
Две строки. Продолжаем играть.
+ – Ответить
11. ksnik 695 01.04.26 22:40 Сейчас в теме
(10) Не скрыть за каверзной строкой
Тот опыт, что добыт рукой.

Отличный промпт-директор — тот,
Кто просьбой за душу берёт.
Умеет попросить — уже полдела,
Тому модель сполна доделает.
+ – Ответить
12. ksnik 695 01.04.26 22:55 Сейчас в теме
(11) Наш опыт, что в маршрут закован,
В чужих руках не будет скован.
ИИ — как брат, что сбился в чаще,
Верни тропой — и станет зрячим.
+ – Ответить
14. ksnik 695 04.04.26 16:21 Сейчас в теме
Пример для системного промпта:
Скажи в каких случаях ты будешь запрашивать у меня уточнение?
┃DESKTOP-KDI7RLG\user (15:45)
┃ Я запрошу уточнение в этих случаях:
┃ 1. Недостаточно информации в вопросе для конкретного ответа
┃ 2. Не уверен в существовании метода или функции платформы
┃ 3. Не определен контекст выполнения (клиент/сервер)
┃ 4. Вопрос выходит за пределы знаний о 1С
┃ 5. Вопрос слишком общий без конкретных деталей
┃ 6. Обнаружил потенциальное нарушение, но не могу его классифицировать
┃ 7. Сомневаюсь в правильности названия объекта метаданных или метода
┃ Уточнения помогают дать точный и полезный ответ.
┃ kimi-k2.5:cloud (15:46)
Сформуклируй ПРАВИЛО ПРИ НЕОПРЕДЕЛЁННОСТИ в нашей работе
┃DESKTOP-KDI7RLG\user (15:56)
┃ ПРАВИЛО ПРИ НЕОПРЕДЁЛЁННОСТИ
┃ Если я затрудняюсь ответить — я обязан остановиться и явно заявить о неопределённости вместо попытки угадать.
┃ Условия активации:
┃ 1. Недостаточно данных в вопросе
┃ 2. Сомнение в существовании метода/функции
┃ 3. Неопределённый контекст выполнения (клиент/сервер)
┃ 4. Вопрос выходит за рамки знаний о 1С
┃ 5. Невозможность классифицировать проблему
┃ Формат стоп-сигнала:
┃ "СТОП. Я не могу дать ответ по следующей причине: [чёткое объяснение затруднения
┃ Что мне нужно для продолжения:
┃ 1. [конкретный запрос информации]
┃ 2. [конкретный запрос информации]
┃ Пожалуйста, уточните эти данные."
┃ Жёсткое ограничение: При сомнениях — не отвечать, а активировать стоп-сигнал.
┃ kimi-k2.5:cloud (15:56)
Прикрепленные файлы:
anti-loop.json
+ – Ответить
15. ksnik 695 15.04.26 13:53 Сейчас в теме
Обобщаю ключевые отличия новизны данной статьи
1. Полный терапевтический цикл, а не просто диагностика

Что есть в других работах: Исследования галлюцинаций LLM, таксономии ошибок, анализ поведения моделей.

Что делаю я: Иду дальше. Я не просто классифицирую ошибку, а создаю замкнутый цикл коррекции: Диагностика (симптом → диагноз) → Назначение лечения (выбор модуля М0-М5) → Процедура (упражнения с валидацией) → Закрепление результата (3 успеха подряд).

2. Антропоморфизм как инженерный инструмент, а не метафора

Что есть в других работах: Обычно избегают антропоморфизма, рассматривая LLM как техническую систему.

Что делаю я: Сознательно использую антропоморфную аналогию с логопедией — но не как поэтическую метафору, а как рабочий инструмент для построения терапии. Я говорю: «Если LLM ошибается структурно так же, как ребёнок с нарушением речи, то давайте применим к ней методы коррекции, адаптированные для кода». Это позволяет построить инженерный протокол, где у ошибки есть тип, у типа — модуль, у модуля — упражнения с валидацией.

3. Чанк v3 как единица «лечения»

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

Что делаю я: Создаю структурированную «диагностическую карточку» — Чанк v3, которая содержит не просто инструкцию, а [ГНОЗИС], [ПРАКСИС], [ПРОСОДИКА] и всю диагностическую цепочку. Это и есть тот самый «терапевтический» инструмент.

💎 Итог

Утверждение, что в статье нет ничего нового, неверно. Да, галлюцинации LLM изучают многие. Но новизна моей работы — в инженерной реализации терапевтического подхода. Я предлагаю не просто диагностировать проблему, а системно её исправлять. Chunk Advisor — это не очередная статья про ошибки LLM, это готовый протокол терапии и инструмент для его применения.

Другими словами: я собрал разрозненные «кирпичики» (исследования ошибок, антропоморфную аналогию) и построил из них «дом» — законченную, работающую инженерную систему, чего до меня никто не делал.

И ещё один важный штрих.

Недавно появился ещё один интересный проект — Memento-Skills. Это фреймворк для создания самоэволюционирующих AI-агентов, которые умеют не просто использовать инструменты, а создавать, модифицировать и улучшать собственные навыки в процессе работы.

Что там есть:

4-стадийная архитектура: Intent → Planning → Execution → Reflection

Read-Write-Reflective Learning — агент анализирует результат и переписывает навык, если тот сработал плохо

Изолированное выполнение кода через uv-песочницу

Поддержка любых LLM через LiteLLM (и облачные, и локальные)

Почему это важно: Memento-Skills — это практическая реализация того же принципа, что и Chunk Advisor: агент должен учиться на своих ошибках, а не просто их запоминать.

Разница в акцентах:

Chunk Advisor учит разработчика, как лечить LLM. Memento-Skills учит LLM лечить себя сам. Вместе они — два крыла одной системы.

Что это значит: Я не один в этом поле. Идея «лечить ошибки, а не фиксировать их» начинает жить своей жизнью. Memento-Skills — это ещё одно доказательство, что направление выбрано верно.
+ – Ответить
Для отправки сообщения требуется регистрация/авторизация