ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Программа "Chunk Advisor" (Консультант по чанкам)

20.03.26

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

Создадим скрипт на Пайтон, предназначенный для автоматизированного подбора чанков (фрагментов требований к коду) при разработке на 1С. Она помогает разработчику формировать качественные промпты для ИИ, включающие все необходимые требования безопасности, производительности и стандартов кодирования. Кому интересно, покритикуйте и предложите улучшения. Результаты опубликуем.
Техническое задание · Финальная версия

Chunk Advisor

Программа-консультант по чанкам для 1С-разработчиков. Консольное приложение на Python для автоматизированного подбора требований к коду и формирования промптов для ИИ.

Python 3.10+ pydantic · rapidfuzz · pymorphy3 · rich SQLite 15 чанков 19.03.2026

01Назначение программы

Chunk Advisor — консольный инструмент на Python для автоматизированного подбора чанков (фрагментов требований к коду) при разработке на 1С. Цель: помочь разработчику формировать качественные промпты для ИИ, включающие требования безопасности, производительности и стандартов кодирования.

Чанк — именованный фрагмент текста с правилами и примерами кода на 1С (BSL), который добавляется в промпт для ИИ перед описанием задачи. Использование нужного набора чанков гарантирует, что ИИ-инструмент учтёт специфические требования проекта.

Основные функции:

  • Хранение и управление базой знаний (чанки, матрица ситуаций, примеры)
  • Интеллектуальный подбор чанков по описанию задачи
  • Формирование промпта с полными текстами выбранных чанков
  • История запросов (SQLite, автосохранение)
  • Личные шаблоны пользователя с переменными
  • Режим администратора для редактуры базы знаний
  • Просмотр всех чанков постранично
  • Экспорт: буфер обмена и файл
Важно: полные тексты всех 15 чанков предоставляются отдельным документом «Справочник чанков» и должны быть загружены в data/storage/chunks.json до начала этапа 2. Без этих данных программа не может быть запущена и протестирована.

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

  • Исполнитель: Python-разработчик уровня middle+ (реализация программы)
  • Конечные пользователи: 1С-разработчики уровня Junior+, Middle, технические лиды

02Архитектура программы

Программа построена по модульному принципу. Все пакеты содержат __init__.py. Пользовательские данные отделены от базы знаний.

chunk_advisor/
+-- main.py                     # точка входа; обработка --admin, --help
+-- requirements.txt            # зависимости проекта
+-- README.md                   # документация: установка и использование
|
+-- core/                       # ядро программы
|   +-- __init__.py
|   +-- knowledge_base.py       # загрузка данных из JSON, поиск по базе
|   +-- recommender.py          # алгоритм подбора чанков (токенизация, scoring)
|   +-- prompt_builder.py       # сборка финального промпта из чанков + контекста
|   +-- models.py               # Pydantic-модели: Chunk, Situation, Category, Example
|
+-- data/                       # работа с файлами данных
|   +-- __init__.py
|   +-- loader.py               # загрузка и валидация JSON-файлов через Pydantic
|   +-- storage/                # ХРАНИЛИЩЕ БАЗЫ ЗНАНИЙ (редактируется командой)
|       +-- chunks.json         # полные тексты чанков (предоставляется отдельно)
|       +-- matrix.json         # матрица ситуаций (единственный источник связей)
|       +-- examples.json       # готовые примеры промптов
|
+-- user_data/                  # пользовательские данные (генерируются программой)
|   +-- __init__.py
|   +-- history_manager.py      # запись и чтение истории запросов (SQLite)
|   +-- template_manager.py     # создание, применение, удаление шаблонов (SQLite)
|   +-- history.db              # автогенерируемый файл БД истории
|   +-- templates.db            # автогенерируемый файл БД шаблонов
|
+-- ui/                         # пользовательский интерфейс
|   +-- __init__.py
|   +-- console.py              # отрисовка меню, запросы ввода (rich)
|   +-- paginator.py            # постраничный вывод списков (10 элементов/стр.)
|
+-- utils/                      # вспомогательные модули
    +-- __init__.py
    +-- text_processor.py       # токенизация, нормализация (pymorphy3 + rapidfuzz)

Описание ключевых модулей

core/knowledge_base.py — загружает все JSON при старте. Методы: получить чанк по ID, получить все категории, получить ситуации по категории, поиск по ключевым словам. Перезагружается без рестарта после изменений в режиме администратора.

core/recommender.py — принимает строку запроса, возвращает ранжированный список chunk_id. Использует pymorphy3 (лемматизация) и rapidfuzz (нечёткое совпадение). Подробно — в разделе 6.

core/prompt_builder.py — собирает финальный промпт из полных текстов выбранных чанков + контекста пользователя. Обрабатывает подстановку переменных {var} в шаблонах.

user_data/history_manager.py — работает с SQLite (history.db). Автоматически сохраняет запись при каждом экспорте. Поддерживает чтение последних N записей, полный просмотр промпта по ID.

user_data/template_manager.py — работает с SQLite (templates.db). Создание, просмотр, применение (подстановка переменных), удаление. Инкрементирует счётчик usage_count при применении.

03Модели данных (core/models.py)

from pydantic import BaseModel
from typing import List, Optional
from datetime import datetime


# -- База знаний --------------------------------------------------

class Chunk(BaseModel):
    id: int
    title: str
    full_text: str          # полный текст требований для подстановки в промпт


class Situation(BaseModel):
    id: str                 # уникальный идентификатор, напр. "form_new"
    name: str               # человекочитаемое название ситуации
    keywords: List[str]     # ключевые слова для алгоритма подбора
    chunk_ids: List[int]    # какие чанки нужны для этой ситуации
    reason: str             # краткое объяснение, почему именно эти чанки


class Category(BaseModel):
    id: str                 # напр. "forms", "queries", "errors"
    name: str               # напр. "Работа с формами и интерфейсом"
    situations: List[Situation]


class Example(BaseModel):
    id: str
    name: str
    description: str
    chunk_ids: List[int]
    context: str            # готовый текст контекста для подстановки


# -- Пользовательские данные ------------------------------------

class HistoryEntry(BaseModel):
    id: Optional[int] = None        # PRIMARY KEY в SQLite
    timestamp: datetime
    query: str                       # исходный запрос пользователя
    selected_chunk_ids: List[int]
    generated_prompt: str            # финальный промпт целиком


class Template(BaseModel):
    id: Optional[int] = None        # PRIMARY KEY в SQLite
    name: str
    description: str
    chunk_ids: List[int]
    context_template: str           # текст с переменными вида {var}
    created_at: datetime
    updated_at: Optional[datetime] = None
    usage_count: int = 0

04Структура данных (JSON)

4.1 chunks.json — схема

Массив объектов. Каждый объект — один чанк. Поле full_text содержит полный текст требований, включая примеры кода BSL с переносами строк (\n) и отступами.

[
  {
    "id": 1,
    "title": "Безопасный код (проверка типов, наличие полей)",
    "full_text": "Требования к безопасности кода:\n\n1. ВСЕГДА проверяй наличие свойства:\n   // Правильно\n   Значение = ОбщегоНазначенияКлиентСервер.СвойствоСтруктуры(\n       Параметры, \"ИмяСвойства\", ЗначениеПоУмолчанию);\n   // Неправильно\n   Значение = Параметры.ИмяСвойства;\n\n2. ВСЕГДА проверяй тип параметров...\n..."
  },
  {
    "id": 2,
    "title": "Сохранение отладочной информации",
    "full_text": "..."
  }
  // ... чанки 3-15 предоставляются отдельным документом
]
Поле full_text не имеет ограничения по длине. Ожидаемый объём каждого чанка — от 500 до 3000 символов. Экранирование кавычек внутри JSON-строки обязательно: \"

4.2 matrix.json — единственный источник связей «Ситуация -> Чанки»

Один файл заменяет оба предыдущих. Поле display_string не хранится — вычисляется в prompt_builder.py. Поле keywords — основа для алгоритма подбора.

{
  "categories": [
    {
      "id": "forms",
      "name": "Работа с формами и интерфейсом",
      "situations": [
        {
          "id": "form_new",
          "name": "Создание новой формы",
          "keywords": ["форма", "создать", "новый", "создание"],
          "chunk_ids": [5, 2],
          "reason": "Минимизация серверных вызовов, логирование событий"
        },
        {
          "id": "form_event_handler",
          "name": "Обработчик события на форме",
          "keywords": ["обработчик", "событие", "приизменении", "приоткрытии"],
          "chunk_ids": [5, 1],
          "reason": "Проверка данных от пользователя, правильные директивы"
        }
        // ... остальные ситуации (полностью — раздел 14)
      ]
    }
  ]
}

4.3 examples.json — готовые примеры промптов

{
  "examples": [
    {
      "id": "example_1",
      "name": "Разработка документа",
      "description": "Создание документа 'Заявка на закупку'",
      "chunk_ids": [7, 5, 3, 2],
      "context": "Проект 1С УНФ 3.0 с расширением АПРО_Доработки\n..."
    }
    // ... примеры 2-7 (полностью — раздел 15)
  ]
}

05Требования к окружению

5.1 Системные требования

  • Python 3.10 или выше
  • Операционная система: Windows 10+, Linux (Ubuntu 20.04+), macOS 12+
  • Дисковое пространство: ~50 МБ (включая зависимости)

5.2 requirements.txt

pydantic>=2.0.0       # валидация моделей данных
rapidfuzz>=3.6.0      # нечёткое сравнение строк (token_set_ratio)
pymorphy3>=1.0.0      # морфологический анализатор русского языка (лемматизация)
pyperclip>=1.8.0      # копирование в буфер обмена
rich>=13.0.0          # цветной консольный вывод, таблицы, прогресс-бары
pytest>=7.0.0         # модульное и интеграционное тестирование
pytest-cov>=4.0.0     # измерение покрытия кода
Linux: pyperclip требует системного пакета. Установка: sudo apt install xclip (Debian/Ubuntu) или sudo apt install xsel. При отсутствии xclip/xsel программа должна отловить исключение pyperclip и вывести промпт на экран с сообщением: «Буфер обмена недоступен — скопируйте текст вручную.»

5.3 Установка и запуск

# Установка зависимостей
pip install -r requirements.txt

# Обычный запуск
python main.py

# Режим администратора (только через аргумент)
python main.py --admin

# Справка
python main.py --help

06Алгоритмы работы

6.1 Алгоритм подбора чанков (recommender.py)

Вход: строка запроса пользователя (user_input: str)
Выход: список ID чанков (List[int])

Шаг 1 — Токенизация и нормализация запроса

import pymorphy3
from rapidfuzz import fuzz

morph = pymorphy3.MorphAnalyzer()

def tokenize_and_normalize(text: str) -> set[str]:
    """
    Разбивает текст на токены, приводит к нижнему регистру,
    фильтрует короткие токены (len <= 2) и возвращает
    множество нормальных форм (лемм) через pymorphy3.

    'Создание формы документа' -> {'создание', 'форма', 'документ'}
    """
    tokens = text.lower().split()
    return {
        morph.parse(t)[0].normal_form
        for t in tokens
        if len(t) > 2
    }

Шаг 2 — Скоринг каждой ситуации из matrix.json

def score_situation(query_tokens: set[str], situation) -> float:
    """
    Вычисляет взвешенную оценку релевантности ситуации запросу.

    Вес 3: точное совпадение нормализованных токенов с keywords ситуации.
           Поиск по токенам (не подстрокам) — исключает ложные срабатывания.

    Вес 2: нечёткое совпадение через fuzz.token_set_ratio.
           token_set_ratio устойчив к порядку слов и частичным совпадениям.
           Нормализуется к диапазону [0, 2].
    """
    norm_keywords = {morph.parse(kw)[0].normal_form for kw in situation.keywords}
    norm_name_tokens = tokenize_and_normalize(situation.name)

    # Вес 3: точные совпадения с ключевыми словами
    keyword_hits = len(query_tokens & norm_keywords)
    keyword_score = 3 * keyword_hits

    # Вес 2: нечёткое совпадение с названием ситуации
    fuzzy_score = fuzz.token_set_ratio(
        " ".join(query_tokens),
        " ".join(norm_name_tokens)
    ) / 100 * 2

    return keyword_score + fuzzy_score

Шаги 3–8 — Сборка результата

  1. Вычислить score_situation() для каждой ситуации из всех категорий матрицы
  2. Отфильтровать ситуации с score == 0 (нет совпадений)
  3. Отсортировать оставшиеся по убыванию score
  4. Взять топ-3 ситуации
  5. Собрать уникальные chunk_ids из выбранных ситуаций
  6. Гарантированно добавить чанк 7 (Универсальный), если его ещё нет в списке
  7. Вернуть итоговый список chunk_ids
Почему token_set_ratio, а не partial_ratio: token_set_ratio игнорирует порядок слов и обрабатывает пересечения токенов, что критично для русскоязычных запросов с произвольным порядком слов. partial_ratio ищет подстроку и менее устойчив к перестановкам.

6.2 Алгоритм формирования промпта (prompt_builder.py)

Вход: chunk_ids: List[int], context: str
Выход: str — готовый промпт для вставки в ИИ-инструмент

  1. Загрузить полные тексты чанков из knowledge_base по ID
  2. Для каждого chunk_id сформировать блок: === ЧАНК {id}: {title} ===\n{full_text}\n
  3. Объединить все блоки чанков
  4. Добавить раздел задачи: --- ЗАДАЧА ---\n{context}
  5. Вернуть итоговую строку

Пример итогового промпта:

=== ЧАНК 7: Универсальный (базовые требования) ===
[полный текст чанка 7]

=== ЧАНК 5: Клиент-серверное взаимодействие ===
[полный текст чанка 5]

=== ЧАНК 3: Обработка ошибок и транзакций ===
[полный текст чанка 3]

=== ЧАНК 2: Сохранение отладочной информации ===
[полный текст чанка 2]

--- ЗАДАЧА ---
Проект 1С УНФ 3.0 с расширением АПРО_Доработки
Задача: Создать документ "Заявка на закупку" в расширении
Требования:
- Табличная часть "Товары" (номенклатура, количество, цена, сумма)
- Проверка заполнения перед записью
- Формирование движений по регистру "ЗаявкиНаЗакупку"

6.3 Механизм подстановки переменных в шаблонах

Контекст шаблона может содержать именованные переменные в фигурных скобках: {version}, {document_name}. При применении шаблона программа:

  1. Находит все вхождения {var} через re.findall(r'\{(\w+)\}', template)
  2. Для каждой уникальной переменной запрашивает значение у пользователя
  3. Подставляет значения через str.format_map()
  4. Передаёт результат в prompt_builder.py

07Пользовательский интерфейс

Консольный интерфейс реализован через библиотеку rich. Используются: rich.console.Console, rich.table.Table, rich.panel.Panel, rich.prompt.Prompt.

7.1 Главное меню

CHUNK ADVISOR v1.0 -- Консультант по подбору чанков
------------------------------------------------------
1. Подобрать чанки по описанию задачи
2. Выбрать чанки по категориям
3. Посмотреть все чанки
4. Мои шаблоны
5. История запросов
6. Примеры готовых промптов
7. Выход
------------------------------------------------------
Для входа в режим администратора: python main.py --admin
Режим администратора не доступен через пункт меню — только через аргумент командной строки --admin. Пункт меню с ним не добавляется.

7.2 Режим 1 — Подбор по описанию задачи

Опишите вашу задачу (пустая строка = завершить ввод):
> Нужно создать документ "Заявка на закупку" с табличной частью
> Документ должен проводиться и формировать движения по регистру
>

Анализирую запрос...

Найдены подходящие ситуации:
  1. Создание новой формы          (релевантность: 95%)
  2. Запись документа             (релевантность: 87%)
  3. Массовая обработка документов (релевантность: 45%)

Рекомендуемые чанки:
  [7] Универсальный (базовые требования)
  [5] Клиент-серверное взаимодействие
  [3] Обработка ошибок и транзакций
  [2] Сохранение отладочной информации

Хотите изменить набор чанков? [д/н]:
> н

Введите контекст задачи (Enter = использовать запрос как контекст):
> Проект 1С УНФ 3.0 с расширением АПРО_Доработки
> - Табличная часть "Товары" (номенклатура, количество, цена, сумма)
>

Промпт сформирован!
  [c] скопировать в буфер   [s] сохранить в файл
  [t] сохранить как шаблон  [Enter] вернуться в меню
История сохраняется автоматически после любого экспорта (копирование или сохранение в файл). Отдельной команды [h] нет.

Редактирование набора чанков (при ответе «д»):

Текущий набор: [7, 5, 3, 2]

Команды:
  a 4    -- добавить чанк с ID 4
  r 3    -- убрать чанк с ID 3
  list   -- показать все чанки для выбора
  ok     -- подтвердить текущий набор

7.3 Режим 2 — Выбор по категориям

Выберите категорию:
 1. Работа с формами и интерфейсом
 2. Работа с данными и запросами
 3. Работа с объектами и метаданными
 4. Обработка ошибок и отладка
 5. Стандартизация и качество кода
 6. Работа с динамическими списками
 7. Интеграции и обмен данными
 8. Работа с регистрами
 9. Оптимизация производительности
10. Расширения конфигурации
11. Исключительные ситуации
12. Файловые операции
13. Тестирование и отладка
> 1

Ситуации в категории "Работа с формами и интерфейсом":
 1. Создание новой формы           [чанки: 5, 2]
 2. Обработчик события на форме   [чанки: 5, 1]
 3. Открытие одной формы из другой [чанки: 5]
 4. Работа с табличной частью     [чанки: 5]
 5. Условное оформление            [чанки: 5]

Выберите ситуации (номера через пробел, 0 = назад):
> 1 2

7.4 Режим 3 — Просмотр всех чанков

Все чанки (всего: 15) -- Страница 1/2
 [1]  Безопасный код (проверка типов, наличие полей)
 [2]  Сохранение отладочной информации
 [3]  Обработка ошибок и транзакций
 [4]  Оптимизация запросов
 [5]  Клиент-серверное взаимодействие
 [6]  Использование БСП
 [7]  Универсальный (базовые требования)
 [8]  Работа с динамическими списками
 [9]  Интеграции и обмен данными
[10]  Работа с периодическими регистрами

[n] следующая страница  [p] предыдущая  [0] в меню
[номер] -- просмотр полного текста чанка
> 1

=== ЧАНК 1: Безопасный код (проверка типов, наличие полей) ===
[полный текст чанка прокручивается здесь...]

[Enter] вернуться к списку

7.5 Режим 5 — История запросов

История запросов (последние 10):
 1. 2026-03-19 10:23  Создание документа "Заявка на закупку"  [7,5,3,2]
 2. 2026-03-19 09:15  Оптимизация отчёта по продажам          [4,11]
 3. 2026-03-18 17:42  Интеграция с Ozon                        [9,2,3,1]

Введите номер для просмотра промпта (0 = назад):
> 1
[полный текст промпта...]
[c] скопировать  [Enter] назад

7.6 Режим 4 — Мои шаблоны

Мои шаблоны:
 1. Создание документа УНФ       (использован: 5 раз)
 2. Оптимизация отчёта          (использован: 3 раза)
 3. Интеграция с маркетплейсом  (использован: 2 раза)

[номер] применить  [d номер] удалить  [0] в меню
> 1

Шаблон: "Создание документа УНФ"
Чанки: [7, 5, 3, 2]
Контекст: Проект 1С УНФ {version}
          Задача: Создать документ "{document_name}"...

Заполните переменные:
version [3.0]:
> 3.0.12
document_name:
> ЗаявкаНаЗакупку
Промпт сформирован!

08Режим администратора

Режим доступен только через python main.py --admin. Пароль не требуется (инструмент внутренний, без сетевого доступа).

РЕЖИМ АДМИНИСТРАТОРА -- Управление базой знаний
-------------------------------------------------
1. Редактировать чанки
2. Редактировать матрицу ситуаций
3. Редактировать примеры промптов
4. Добавить новый чанк
5. Добавить новую ситуацию
6. Проверить целостность данных
7. Выход из режима администратора

Поведение после изменений

  • После каждого изменения соответствующий JSON-файл перезаписывается на диск
  • knowledge_base.reload() перечитывает все файлы в память без перезапуска программы
  • Изменения сразу доступны в обычных режимах без выхода из --admin

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

  • Все chunk_ids в матрице ссылаются на существующие чанки
  • Все chunk_ids в примерах ссылаются на существующие чанки
  • Нет дублирующихся id среди чанков
  • Нет дублирующихся id среди ситуаций
  • Все обязательные поля заполнены (через Pydantic)
Шаблоны пользователя — личные данные. Они не входят в зону ответственности режима администратора. Пользователь управляет шаблонами через пункт меню «Мои шаблоны».

09История запросов и шаблоны

9.1 История запросов (history_manager.py)

Хранится в SQLite: user_data/history.db. Файл создаётся автоматически при первом запуске.

CREATE TABLE history (
    id               INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp        TEXT NOT NULL,           -- ISO-8601 datetime
    query            TEXT NOT NULL,           -- исходный запрос пользователя
    selected_chunks  TEXT NOT NULL,           -- JSON-список: [7, 5, 3, 2]
    generated_prompt TEXT NOT NULL            -- полный текст промпта
);

Запись создаётся автоматически при каждом успешном экспорте (нажатие [c] или [s]). Отдельного вопроса «Сохранить?» нет.

9.2 Шаблоны пользователя (template_manager.py)

Хранятся в SQLite: user_data/templates.db. Файл создаётся автоматически.

CREATE TABLE templates (
    id               INTEGER PRIMARY KEY AUTOINCREMENT,
    name             TEXT NOT NULL,           -- напр. "Создание документа УНФ"
    description      TEXT NOT NULL,
    chunk_ids        TEXT NOT NULL,           -- JSON-список
    context_template TEXT NOT NULL,           -- текст с переменными {var}
    created_at       TEXT NOT NULL,
    updated_at       TEXT,
    usage_count      INTEGER DEFAULT 0
);

Управление шаблонами доступно пользователю без --admin через пункт «4. Мои шаблоны».

10Обработка ошибок

Ситуация Поведение программы
chunks.json не найден Сообщение: «Ошибка загрузки базы знаний. Убедитесь, что файл data/storage/chunks.json существует.» Предложение: выйти или повторить попытку.
matrix.json повреждён Pydantic выбрасывает ValidationError. Программа выводит список ошибок валидации и предлагает выйти.
Несуществующий ID чанка в вводе «Чанк с ID X не найден» — предупреждение, ID игнорируется, остальные обрабатываются нормально.
Пустой ввод при выборе пункта меню Возврат в текущее меню с повтором запроса.
Нечисловой ввод вместо числа «Введите число» — повтор запроса с подсказкой.
Буфер обмена недоступен (Linux без xclip) Исключение pyperclip перехватывается. Промпт выводится на экран: «Буфер обмена недоступен — скопируйте текст вручную.»
SQLite файл недоступен для записи История/шаблоны не сохраняются, выводится предупреждение. Основной функционал продолжает работу.

11План разработки и тестирования

11.1 Этапы с зависимостями

Этап Задачи Зависит от Дней
1 Модели данных (models.py), структура проекта, requirements.txt 1
2 Загрузка JSON (loader.py), валидация через Pydantic, knowledge_base.py 1 1
3 Алгоритм подбора (recommender.py): токенизация, scoring, сборка результата 1, 2 3
4 Формирование промпта (prompt_builder.py), подстановка переменных 1, 2 1
5 Консольный интерфейс (console.py, paginator.py). На этапе 5 recommender заменяется заглушкой. 1 3
6 История запросов (history_manager.py, SQLite) 1, 2 2
7 Шаблоны пользователя (template_manager.py, SQLite) 1, 2 1
8 Режим администратора (редактирование JSON, валидация целостности, перезагрузка) 2, 5 2
9 Интеграция всех компонентов, полный пользовательский цикл 3,4,5,6,7,8 2
10 Тесты (pytest, pytest-cov), README 9 2
Итого 18 дней
Критический путь: 1 → 2 → 3 → 9 → 10 (9 дней). Этапы 3 и 5 могут вестись параллельно разными разработчиками. Разработчик, реализующий UI (этап 5), использует заглушку для recommender до завершения этапа 3.

11.2 Тестирование

Модульные тесты (core/ и utils/ — минимум 80% покрытия):

  • Токенизация и нормализация: корректность лемматизации, фильтрация коротких токенов
  • Алгоритм скоринга: тестовые запросы против ожидаемых ситуаций и чанков
  • Формирование промпта: структура вывода, наличие всех блоков, подстановка переменных
  • Загрузка и валидация данных: корректный JSON, повреждённый JSON, отсутствующий файл

Интеграционные тесты (ui/, user_data/ — без фиксированного порога):

  • Полный цикл: ввод запроса → подбор → формирование → экспорт → запись в историю
  • Работа с шаблонами: создание → применение с переменными → удаление
  • Режим администратора: добавление чанка → сохранение → перезагрузка → проверка доступности

Тестовые сценарии (минимальный набор):

test_cases = [
    {
        "query": "создать новую форму документа",
        "expected_chunks_include": [5, 7],
        "description": "форма документа -> клиент-серверное взаимодействие"
    },
    {
        "query": "оптимизировать медленный отчет",
        "expected_chunks_include": [4, 11],
        "description": "медленный отчёт -> запросы + производительность"
    },
    {
        "query": "интеграция с внешним API через HTTP",
        "expected_chunks_include": [9, 2, 3],
        "description": "HTTP API -> интеграции + логирование + транзакции"
    },
    {
        "query": "загрузка номенклатуры из excel",
        "expected_chunks_include": [14, 3],
        "description": "загрузка файла -> файловые операции + транзакции"
    },
    {
        "query": "расширение конфигурации добавить реквизит",
        "expected_chunks_include": [12, 7],
        "description": "расширение -> чанк расширений + универсальный"
    }
]

12Критерии приёмки

  1. Программа запускается без ошибок на Windows 10+ и Ubuntu 20.04+
  2. Все пункты главного меню работают согласно описанию в разделе 7
  3. Алгоритм подбора выдаёт ожидаемые чанки для всех тестовых сценариев из п. 11.2
  4. Формируемый промпт содержит полные тексты выбранных чанков (не только заголовки)
  5. История запросов автоматически сохраняется после каждого экспорта
  6. Шаблоны создаются, применяются (с подстановкой переменных) и удаляются без ошибок
  7. Режим администратора позволяет добавлять/редактировать чанки и ситуации; изменения отражаются без перезапуска программы
  8. Покрытие кода тестами: не менее 80% для модулей core/ и utils/ (измеряется pytest-cov)
  9. README содержит инструкции по установке (включая Linux-специфику) и базовое описание использования

13Чеклист приёмки программы

Заполняется разработчиком перед сдачей. Все пункты должны быть отмечены как выполненные.

N Критерий Проверено
1 Запуск на Windows без ошибок [ ]
2 Запуск на Linux без ошибок [ ]
3 Все пункты главного меню работают [ ]
4 Тестовые запросы дают ожидаемые чанки [ ]
5 Промпт содержит полные тексты чанков [ ]
6 История автосохраняется после экспорта [ ]
7 Шаблоны: создание, применение, удаление [ ]
8 Переменные в шаблонах подставляются корректно [ ]
9 Редактирование JSON через --admin работает [ ]
10 Перезагрузка базы без рестарта программы [ ]
11 Проверка целостности выявляет несуществующие chunk_ids [ ]
12 Ошибки загрузки данных обрабатываются (не падает с traceback) [ ]
13 Буфер обмена недоступен — выводит промпт на экран [ ]
14 Покрытие core/ и utils/ не менее 80% (pytest-cov) [ ]
15 README написан, установка описана [ ]

14Матрица ситуаций (полная версия matrix.json)

Полное содержимое файла data/storage/matrix.json. Это единственный источник связей «Ситуация → Чанки». Файл final_table.json не используется.

{
  "categories": [

    {
      "id": "forms",
      "name": "Работа с формами и интерфейсом",
      "situations": [
        { "id": "form_new",             "name": "Создание новой формы",
          "keywords": ["форма","создать","новый","создание"],
          "chunk_ids": [5,2],   "reason": "Минимизация серверных вызовов, логирование событий" },
        { "id": "form_event_handler",   "name": "Обработчик события на форме",
          "keywords": ["обработчик","событие","приизменении","приоткрытии"],
          "chunk_ids": [5,1],   "reason": "Проверка данных от пользователя, правильные директивы" },
        { "id": "form_open_another",    "name": "Открытие одной формы из другой",
          "keywords": ["открыть","открытие","вызов формы","открытьформу"],
          "chunk_ids": [5],     "reason": "Совместимость с веб-клиентом, асинхронные диалоги" },
        { "id": "form_table_part",      "name": "Работа с табличной частью",
          "keywords": ["табличная часть","таблица","строки","товары"],
          "chunk_ids": [5],     "reason": "Клиентские расчёты, отзывчивость интерфейса" },
        { "id": "form_conditional",     "name": "Условное оформление",
          "keywords": ["условное оформление","оформление","цвет","выделение"],
          "chunk_ids": [5],     "reason": "Группировка изменений, один серверный вызов" }
      ]
    },

    {
      "id": "queries",
      "name": "Работа с данными и запросами",
      "situations": [
        { "id": "query_report",         "name": "Получение данных для отчёта",
          "keywords": ["отчёт","отчет","выборка","данные"],
          "chunk_ids": [4],     "reason": "Производительность, оптимальные планы запросов" },
        { "id": "query_remains",        "name": "Проверка остатков перед списанием",
          "keywords": ["остатки","списание","проверка","достаточно"],
          "chunk_ids": [4,3],   "reason": "Целостность данных, блокировки" },
        { "id": "query_batch",          "name": "Массовая обработка документов",
          "keywords": ["массовый","пакетный","обработка","документы","пакет"],
          "chunk_ids": [3,4],   "reason": "Устойчивость к ошибкам, одна ошибка не убивает всё" },
        { "id": "query_search",         "name": "Поиск по справочнику",
          "keywords": ["поиск","найти","подбор","справочник"],
          "chunk_ids": [4],     "reason": "Ограничение результатов, ПЕРВЫЕ N" },
        { "id": "query_complex_join",   "name": "Сложная выборка с соединениями",
          "keywords": ["соединение","join","сложный","выборка","несколько таблиц"],
          "chunk_ids": [4],     "reason": "Временные таблицы, ЕСТЬNULL, правильные данные" }
      ]
    },

    {
      "id": "objects",
      "name": "Работа с объектами и метаданными",
      "situations": [
        { "id": "object_write",         "name": "Запись документа",
          "keywords": ["запись","записать","проведение","документ"],
          "chunk_ids": [3,2],   "reason": "Атомарность, диагностика при ошибках" },
        { "id": "object_get_attrs",     "name": "Получение реквизитов по ссылке",
          "keywords": ["реквизиты","получить","значение","атрибуты"],
          "chunk_ids": [6,1],   "reason": "Производительность, безопасность, проверка существования" },
        { "id": "object_validate",      "name": "Проверка заполнения",
          "keywords": ["проверка","заполнение","валидация","заполнено"],
          "chunk_ids": [6,1],   "reason": "Единообразие, ЗначениеЗаполнено" },
        { "id": "object_rights",        "name": "Работа с правами доступа",
          "keywords": ["права","доступ","разрешения","роль"],
          "chunk_ids": [6],     "reason": "Проверенные механизмы БСП" },
        { "id": "object_create",        "name": "Создание нового элемента",
          "keywords": ["создать","новый","элемент","справочник"],
          "chunk_ids": [6,3],   "reason": "Надёжность, откат при ошибке" }
      ]
    },

    {
      "id": "errors",
      "name": "Обработка ошибок и отладка",
      "situations": [
        { "id": "error_db",             "name": "Любая операция с БД",
          "keywords": ["база данных","бд","запись","транзакция"],
          "chunk_ids": [3,2],   "reason": "Откат при ошибке, диагностика" },
        { "id": "error_integration",    "name": "Интеграция с внешней системой",
          "keywords": ["интеграция","внешний","api","http"],
          "chunk_ids": [2,3],   "reason": "Диагностика сбоев, повторные попытки" },
        { "id": "error_batch",          "name": "Пакетная обработка",
          "keywords": ["пакет","массив","список","много"],
          "chunk_ids": [3],     "reason": "Накопление ошибок, продолжение работы" },
        { "id": "error_debug",          "name": "Отладка сложного алгоритма",
          "keywords": ["отладка","алгоритм","сложный","логика"],
          "chunk_ids": [2],     "reason": "Промежуточные результаты, понимание" }
      ]
    },

    {
      "id": "standards",
      "name": "Стандартизация и качество кода",
      "situations": [
        { "id": "std_export",           "name": "Экспортная функция",
          "keywords": ["экспорт","функция","процедура","экспортная"],
          "chunk_ids": [1,2],   "reason": "Проверка параметров, документация" },
        { "id": "std_strings",          "name": "Работа со строками",
          "keywords": ["строка","текст","конкатенация","соединить"],
          "chunk_ids": [6,1],   "reason": "Производительность, локализация, НСтр" },
        { "id": "std_loop_concat",      "name": "Конкатенация в цикле",
          "keywords": ["цикл","конкатенация","сложение строк"],
          "chunk_ids": [1],     "reason": "O(N) вместо O(N^2), СтрСоединить" },
        { "id": "std_naming",           "name": "Именование переменных",
          "keywords": ["имена","переменные","названия","camelcase"],
          "chunk_ids": [1],     "reason": "Читаемость, CamelCase на русском" },
        { "id": "std_comments",         "name": "Комментарии",
          "keywords": ["комментарий","комментировать","документация"],
          "chunk_ids": [2],     "reason": "Документирование, объяснение 'зачем'" }
      ]
    },

    {
      "id": "dynamic_lists",
      "name": "Работа с динамическими списками",
      "situations": [
        { "id": "dynlist_setup",        "name": "Настройка динамического списка",
          "keywords": ["динамический список","список","настройка","отбор"],
          "chunk_ids": [8],     "reason": "Инициализация в ПриСозданииНаСервере" },
        { "id": "dynlist_filters",      "name": "Установка отборов",
          "keywords": ["отбор","фильтр","условие"],
          "chunk_ids": [8],     "reason": "Отборы через параметры, производительность" },
        { "id": "dynlist_custom_query", "name": "Произвольный запрос в списке",
          "keywords": ["произвольный","запрос","текст запроса"],
          "chunk_ids": [8,4],   "reason": "Сложные выборки с оптимизацией" },
        { "id": "dynlist_conditional",  "name": "Условное оформление строк",
          "keywords": ["условное оформление","подсветка","цвет"],
          "chunk_ids": [8],     "reason": "Визуализация данных" }
      ]
    },

    {
      "id": "integrations",
      "name": "Интеграции и обмен данными",
      "situations": [
        { "id": "int_http",             "name": "HTTP-вызов к внешнему API",
          "keywords": ["http","api","запрос","внешний","интеграция"],
          "chunk_ids": [9,2,3], "reason": "Надёжность, повторные попытки, диагностика" },
        { "id": "int_files",            "name": "Обмен через файлы",
          "keywords": ["файл","обмен","выгрузка","загрузка"],
          "chunk_ids": [9,14],  "reason": "Структурированный обмен, работа с файлами" },
        { "id": "int_json",             "name": "Работа с JSON/XML",
          "keywords": ["json","xml","сериализация","парсинг"],
          "chunk_ids": [9],     "reason": "Корректный парсинг, стандартные функции" },
        { "id": "int_com",              "name": "Интеграция через COM",
          "keywords": ["com","ole","внешний объект"],
          "chunk_ids": [9,3],   "reason": "Стабильность соединения, обработка ошибок" }
      ]
    },

    {
      "id": "registers",
      "name": "Работа с регистрами",
      "situations": [
        { "id": "reg_remains",          "name": "Получение остатков",
          "keywords": ["остатки","регистр накопления","остаток"],
          "chunk_ids": [10,4],  "reason": "Актуальные данные, виртуальные таблицы" },
        { "id": "reg_last_slice",       "name": "Получение среза последних",
          "keywords": ["срез последних","актуальные","текущие"],
          "chunk_ids": [10],    "reason": "Текущие значения на дату" },
        { "id": "reg_write",            "name": "Запись в регистр сведений",
          "keywords": ["запись","регистр сведений","набор записей"],
          "chunk_ids": [10],    "reason": "Правильная структура, НаборЗаписей" },
        { "id": "reg_movements",        "name": "Движения документа",
          "keywords": ["движения","регистратор","проведение"],
          "chunk_ids": [10,3],  "reason": "Целостность, транзакции" }
      ]
    },

    {
      "id": "performance",
      "name": "Оптимизация производительности",
      "situations": [
        { "id": "perf_slow_report",     "name": "Медленный отчёт",
          "keywords": ["медленный","тормозит","долго","отчёт"],
          "chunk_ids": [11,4],  "reason": "Выявление узких мест, оптимизация запросов" },
        { "id": "perf_slow_form",       "name": "Тормозит форма",
          "keywords": ["форма","тормозит","зависает","медленно"],
          "chunk_ids": [11,5],  "reason": "Сокращение серверных вызовов" },
        { "id": "perf_long_op",         "name": "Длительная операция",
          "keywords": ["длительный","фон","фоновое задание"],
          "chunk_ids": [11],    "reason": "Фоновые задания, не блокировать интерфейс" },
        { "id": "perf_caching",         "name": "Кэширование данных",
          "keywords": ["кэш","кэширование","повторные вызовы"],
          "chunk_ids": [11],    "reason": "Ускорение повторных обращений" }
      ]
    },

    {
      "id": "extensions",
      "name": "Расширения конфигурации",
      "situations": [
        { "id": "ext_create",           "name": "Создание расширения",
          "keywords": ["расширение","extension","доработка"],
          "chunk_ids": [12],    "reason": "Правильная структура, не изменять основную" },
        { "id": "ext_add_attribute",    "name": "Добавление реквизита",
          "keywords": ["реквизит","добавить","присоединённый"],
          "chunk_ids": [12],    "reason": "Совместимость, ПриУстановкеСвойств" },
        { "id": "ext_override",         "name": "Переопределение процедуры",
          "keywords": ["переопределить","продолжитьвызов","замещение"],
          "chunk_ids": [12],    "reason": "Сохранение оригинальной логики" },
        { "id": "ext_update",           "name": "Обновление при изменении конфигурации",
          "keywords": ["обновление","совместимость","версия"],
          "chunk_ids": [12],    "reason": "Предотвращение ошибок" }
      ]
    },

    {
      "id": "exceptions",
      "name": "Исключительные ситуации",
      "situations": [
        { "id": "exc_critical",         "name": "Критическая ошибка",
          "keywords": ["критическая","авария","падение","фатальная"],
          "chunk_ids": [13,2],  "reason": "Диагностика, полное логирование" },
        { "id": "exc_recovery",         "name": "Восстановление после сбоя",
          "keywords": ["восстановление","fallback","резервный"],
          "chunk_ids": [13],    "reason": "Устойчивость, запасные варианты" },
        { "id": "exc_user",             "name": "Пользовательские исключения",
          "keywords": ["исключение","вызватьисключение","ошибка пользователя"],
          "chunk_ids": [13],    "reason": "Понятный контекст, пользовательские сообщения" },
        { "id": "exc_timeout",          "name": "Таймауты внешних вызовов",
          "keywords": ["таймаут","timeout","ожидание"],
          "chunk_ids": [13],    "reason": "Повторные попытки, экспоненциальная задержка" }
      ]
    },

    {
      "id": "files",
      "name": "Файловые операции",
      "situations": [
        { "id": "file_upload",          "name": "Загрузка файла на сервер",
          "keywords": ["загрузка","файл","на сервер","поместить"],
          "chunk_ids": [14,5],  "reason": "Асинхронные диалоги, пользовательский опыт" },
        { "id": "file_temp",            "name": "Работа с временными файлами",
          "keywords": ["временный","temp","удалить"],
          "chunk_ids": [14],    "reason": "Очистка ресурсов, предотвращение мусора" },
        { "id": "file_excel",           "name": "Импорт из Excel/CSV",
          "keywords": ["excel","csv","импорт","загрузка"],
          "chunk_ids": [14,3],  "reason": "Производительность, массовая обработка" },
        { "id": "file_zip",             "name": "Работа с ZIP-архивами",
          "keywords": ["zip","архив","сжатие","распаковать"],
          "chunk_ids": [14],    "reason": "Компактность, стандартные функции" }
      ]
    },

    {
      "id": "testing",
      "name": "Тестирование и отладка",
      "situations": [
        { "id": "test_unit",            "name": "Написание модульных тестов",
          "keywords": ["тест","тестирование","модульный","unit"],
          "chunk_ids": [15],    "reason": "Качество кода, предотвращение регрессий" },
        { "id": "test_debug",           "name": "Отладка сложного алгоритма",
          "keywords": ["отладка","алгоритм","сложный"],
          "chunk_ids": [15,2],  "reason": "Трассировка, понимание логики" },
        { "id": "test_edge",            "name": "Тестирование граничных случаев",
          "keywords": ["граничный","крайний случай","edge"],
          "chunk_ids": [15],    "reason": "Надёжность, обработка исключений" },
        { "id": "test_perf",            "name": "Измерение производительности",
          "keywords": ["производительность","замер","время"],
          "chunk_ids": [15,11], "reason": "Выявление узких мест, оптимизация" }
      ]
    }

  ]
}

15Примеры готовых промптов (examples.json)

Полное содержимое файла data/storage/examples.json. Отображаются в пункте меню «6. Примеры готовых промптов».

{
  "examples": [
    {
      "id": "example_1",
      "name": "Разработка документа",
      "description": "Создание документа 'Заявка на закупку'",
      "chunk_ids": [7, 5, 3, 2],
      "context": "Проект 1С УНФ 3.0 с расширением АПРО_Доработки\nЗадача: Создать документ 'Заявка на закупку' в расширении\nТребования:\n- Табличная часть 'Товары' (номенклатура, количество, цена, сумма)\n- Проверка заполнения перед записью\n- Формирование движений по регистру 'ЗаявкиНаЗакупку'"
    },
    {
      "id": "example_2",
      "name": "Оптимизация отчёта",
      "description": "Ускорение отчёта по продажам",
      "chunk_ids": [4, 2],
      "context": "Проблема: Отчёт по продажам выполняется 5 минут\nТребуется оптимизировать запрос:\n- Виртуальные таблицы регистров\n- Индексация временных таблиц\n- Ограничение выборки (ПЕРВЫЕ N)\n- Логирование времени выполнения"
    },
    {
      "id": "example_3",
      "name": "Массовая загрузка",
      "description": "Загрузка 10 000 строк номенклатуры из Excel",
      "chunk_ids": [1, 2, 3, 6],
      "context": "Задача: Загрузка 10 000 строк номенклатуры из Excel\nТребования:\n- Поэлементная обработка с накоплением ошибок\n- Проверка типов данных\n- Поиск дубликатов по артикулу\n- Логирование каждой ошибки\n- Итоговый отчёт о результатах"
    },
    {
      "id": "example_4",
      "name": "Отчёт с группировками",
      "description": "Отчёт 'Продажи по контрагентам' с группировкой",
      "chunk_ids": [4, 10, 2],
      "context": "Проект 1С УНФ 3.0\nЗадача: Отчёт 'Продажи по контрагентам' с группировкой по месяцам\nТребования:\n- Период: январь-март 2026\n- Группировка: по месяцам, внутри по контрагентам\n- Показатели: сумма продаж, количество документов, средний чек\n- Виртуальные таблицы регистра продаж\n- Логирование времени выполнения"
    },
    {
      "id": "example_5",
      "name": "Интеграция с маркетплейсом",
      "description": "Выгрузка остатков на Ozon",
      "chunk_ids": [9, 2, 3, 1],
      "context": "Проект 1С УНФ, интеграция с Ozon\nЗадача: Выгрузка остатков на маркетплейс\nТребования:\n- Получать остатки по всем складам\n- Формировать JSON по спецификации Ozon\n- HTTP с повторными попытками (3 раза)\n- Логировать каждый этап\n- При ошибке: запись в журнал и уведомление администратора\n- Пароль для API хранить в константе"
    },
    {
      "id": "example_6",
      "name": "Фоновая обработка",
      "description": "Фоновое задание для проведения документов",
      "chunk_ids": [11, 3, 2],
      "context": "Проект 1С УНФ\nЗадача: Фоновое задание для массового проведения документов за день\nТребования:\n- Все непроведённые документы за текущий день\n- Поэлементная обработка с накоплением ошибок\n- Каждый документ в отдельной транзакции\n- Логировать успехи и ошибки\n- По окончании отправить отчёт администратору\n- Не блокировать работу пользователей"
    },
    {
      "id": "example_7",
      "name": "Расширение с новым функционалом",
      "description": "Добавление реквизита в расширение",
      "chunk_ids": [12, 1, 5, 3],
      "context": "Расширение АПРО_Доработки для 1С УНФ\nЗадача: Добавить реквизит 'КомментарийМенеджера' в 'РеализацияТоваровУслуг'\nТребования:\n- Добавить реквизит в расширении\n- Вывести на форму документа\n- При записи проверять длину (не более 500 символов)\n- Логировать в отдельный регистр сведений\n- Использовать ПродолжитьВызов для сохранения оригинальной логики"
    }
  ]
}

АПриложение А. Данные для инициализации базы знаний

Полные тексты всех 15 чанков предоставляются командой в виде отдельного документа «Справочник чанков». Разработчик обязан получить этот документ до начала этапа 2 и перенести данные в файл data/storage/chunks.json согласно схеме из раздела 4.1.

Блокирующее требование: без файла chunks.json с корректными данными программа не может быть запущена и протестирована. Нельзя начинать этапы 2–10, не имея этих данных.

Перечень чанков (должны быть в chunks.json)

ЧАНК 01 Безопасный код (проверка типов, наличие полей)
ЧАНК 02 Сохранение отладочной информации
ЧАНК 03 Обработка ошибок и транзакций
ЧАНК 04 Оптимизация запросов
ЧАНК 05 Клиент-серверное взаимодействие
ЧАНК 06 Использование БСП
ЧАНК 07 Универсальный (базовые требования) — добавляется всегда
ЧАНК 08 Работа с динамическими списками
ЧАНК 09 Интеграции и обмен данными
ЧАНК 10 Работа с периодическими регистрами
ЧАНК 11 Оптимизация производительности
ЧАНК 12 Работа с расширениями конфигурации
ЧАНК 13 Обработка исключительных ситуаций
ЧАНК 14 Работа с файлами и двоичными данными
ЧАНК 15 Тестирование и отладка

Чанк 07 (Универсальный) выделен — он автоматически добавляется в каждый результат подбора, если отсутствует в выбранном наборе.

Chunk Advisor v3 · Техническое задание
Дата: 19.03.2026 · Статус: финальная версия, готова к реализации
Разделов: 15 + приложение А · Этапов разработки: 10 · Срок: 18 дней
Критический путь: этапы 1 → 2 → 3 → 9 → 10 (9 дней)

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

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

  • Поиск от одного разработчика до ИТ-команд под проект.
  • Обмен любыми контактами разрешён.
  • 0% комиссии, допускаются расчёты напрямую.

См. также

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

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

15250 руб.

25.08.2025    51076    103    29    

115

Нейросети 1С:Предприятие 8 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 Платные (руб)

Умный Excel" - ИИ-супердвигатель, который превращает часы работы в минуты! Технологии будущего уже здесь: загрузил Excel "магия ИИ" готовый результат

8540 руб.

02.07.2025    3826    2    0    

6

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

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

6100 руб.

03.04.2024    15003    8    0    

12

Мастера заполнения Нейросети 1С:Предприятие 8 1C:Бухгалтерия 1С:Управление торговлей 11 Платные (руб)

Расширение для заполнения описания товара (номенклатуры) с помощью модели ИИ ChatGPT с ключевыми словами. Расширение формирует продающее описание товара по его наименованию с помощью модели искусственного интеллекта. Будет полезно для владельцев интернет магазинов, каталогов товаров и продающих через маркетплейсы. Адаптировано для основных конфигураций: УТ, ЕРП, КА, УНФ. Прошло аудит на 1cfresh.com. Версия для автоматического заполнения

5084 руб.

13.03.2023    22579    52    50    

80

Инструментарий разработчика Рефакторинг и качество кода Программист 1С:Предприятие 8 Бесплатно (free)

Инструмент для тех, кто устал читать модули по 50 тысяч строк и искать ошибки глазами. MetaVision загружает выгруженные файлы конфигурации и за секунды строит графы функций, находит уязвимости и подсвечивает проблемы производительности. Ключевые возможности: Визуализация логики функций (графы условий, циклов, транзакций и вызовов). Статический аудит безопасности (RCE, SSRF, COM-инъекции, пароли в коде). Поиск проблем производительности (запросы в циклах, вложенные блокировки). Полнотекстовый поиск по всем модулям конфигурации. Статистика по объектам и функциям. Безопасность: Программа работает строго локально. Код вашей конфигурации не отправляется в интернет и не анализируется на сторонних серверах. Попробуйте MetaVision сегодня — узнайте, что скрывает ваш код.

20.04.2026    4360    272    KHoroshulinAV    36    

49

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

Статья описывает первый практический опыт использования искусственного интеллекта для разработки на платформе 1С:Предприятие 8.3. Я, изначально скептически настроенный к применению ИИ в программировании, столкнулся с задачей срочного переноса функционала Telegram-бота на электронную почту из-за блокировки Telegram. В условиях ограниченного доступа к инструментам был использован доступный ИИ-сервис для анализа существующего кода, проектирования архитектуры решения и генерации нового модуля отправки писем. В статье подробно показан процесс постановки задач, уточнения требований, генерации кода, исправления ошибок и финального внедрения решения. В результате был создан полноценный модуль на 1С объемом около 2000 строк кода, успешно внедренный и использованный для автоматической рассылки отчетов.

15.04.2026    3223    apatyukov    76    

20

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

А что, если ты используешь AI-ассистента? Он же не знает синтаксис 1С. Он вообще понятия не имеет, что такое &НаКлиенте, чем отличается СправочникМенеджер от СправочникОбъект, и почему запрос нельзя написать просто так, без танцев с бубнами временных таблиц, если у них, конечно, есть бубны...

05.04.2026    2667    starik-2005    57    

22

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

PromptPilot — это очередь задач для AI CLI (Claude Code, Codex, Qwen): Отправляете промпт из cli, web интерфейса, или ТГ бота в планировщик, воркер выполняет его на машине, результат смотрите в веб-интерфейсе или в Telegram. Удобно, когда лимиты сбрасываются не вовремя, идея пришла в дороге, а терминал недоступен, или нужно «разогреть» сессию к началу рабочего дня по расписанию. В материале — архитектура на SQLite, запуск (CLI, веб, бот, tray/.exe), работа с rate limit и продолжение диалога с моделью прямо из бота без консоли.

31.03.2026    1421    Ibrogim    30    

20
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ksnik 677 24.03.26 22:30 Сейчас в теме
Данное задание получило реализацию в публикации https://infostart.ru/1c/tools/2646044/
Решим проблему необоснованного укрупнения базовой версии в эволюции данного проекта.

Архитектурный проект Chunk Advisor v2.0
По методу CLEAR: от метафоры к инженерной реализации

0. Архитектурный запрос по методу CLEAR

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

C — Context
Задача: спроектировать v2 инструмента Chunk Advisor — консольного Python-приложения для 1С-разработчиков. В v1 чанки подбирались по релевантности и объединялись в один промпт. В v2 чанки образуют граф взаимодействий: притягиваются при высоком терминологическом пересечении и когерентности, отталкиваются при несовместимости по этапу, роли, контексту, ресурсам, времени. Промпт разрывается на несколько частей по результату раскраски графа.

L — Limits
Ограничения: (1) Python 3.10+, без смены языка; (2) обратная совместимость с v1 — chunks.json и matrix.json остаются форматом хранения; (3) алгоритм распределения должен давать стабильный результат на одних и тех же входных данных (воспроизводимость); (4) мастер CLEAR — интерактивный диалог, не заменяет, а дополняет пакетный режим; (5) количество промптов на выходе — минимально возможное (жадная раскраска).

E — Examples
Пример 1: запрос «создать документ в расширении» → C_candidate = {ч5, ч3, ч2, ч7} → α(5,3)=0.82 → объединяются → один промпт P₁={5,3,2,7}. Пример 2: запрос «написать отчёт и настроить CI» → C_candidate = {ч4, ч11, devops_chunk} → β_phase(4, devops)=1 > θ_repel → разрыв → P₁={4,11}, P₂={devops_chunk}. Пример 3 (CLEAR-мастер): пользователь отвечает на 5 вопросов, программа выводит граф и набор промптов с CLEAR-структурой.

A — Audience
Первичная аудитория: Python middle+ разработчик, реализующий v2. Вторичная: 1С-разработчики (Junior+, Middle, архитекторы), технические лиды, QA-инженеры, DevOps — конечные пользователи ролевых чанков.

R — Requirements
Функциональные: (1) вычислять cohesion, coupling, α, β для всех пар; (2) строить граф G=(V,E,A,B); (3) разбивать C_candidate на {P₁...Pₖ} с минимальным k; (4) формировать промпты с CLEAR-структурой; (5) пакетный режим (JSON in → JSON out); (6) интерактивный мастер CLEAR; (7) поддержка 6 этапов и 5 ролей. Нефункциональные: воспроизводимость, покрытие тестами core/ ≥ 85%, время обработки ≤ 2 с на 30 чанков.

1. Математическая основа

Формальная модель определяет все измеримые свойства чанков и их взаимодействий. Она является единственным источником истины для алгоритмов v2.

1.1 Определение чанка и когерентности

Пусть C = {c₁, c₂, …, cₙ} — множество чанков. Каждый чанк cᵢ = {r₁, r₂, …, rₖ}, где rⱼ — атомарное требование.

Определим матрицу зависимостей Dᵢ[j,l] ∈ {0,1}, где Dᵢ[j,l]=1 означает, что правило rⱼ логически зависит от rₗ.

Коэффициент внутренней связности:
cohesion(cᵢ) = (Σⱼ Σₗ Dᵢ[j,l]) / (k² − k)


Чанк является когерентным, если cohesion(cᵢ) > θ_cohesion (порог по умолчанию: 0.7). Для всех чанков базы это свойство выполняется по построению — разрыв чанка недопустим.

1.2 Внешняя связность (coupling)

Для каждой пары чанков (cᵢ, cⱼ) пусть Rᵢ — множество терминов (реквизиты, методы, объекты BSL), используемых в cᵢ:

coupling(cᵢ, cⱼ) = |Rᵢ ∩ Rⱼ| / |Rᵢ ∪ Rⱼ|   ∈ [0, 1]


Коэффициент равен 1 при полном совпадении терминологии, 0 — при полном отсутствии пересечений.

1.3 Притяжение и отталкивание

Коэффициент притяжения αᵢⱼ ∈ [0,1] — мера желательности совместного использования чанков cᵢ и cⱼ:

αᵢⱼ = w_coupling · coupling(cᵢ, cⱼ) + w_cohesion · min(cohesion(cᵢ), cohesion(cⱼ))


Коэффициент отталкивания βᵢⱼ ∈ [0,1] — мера нежелательности совместного использования:

βᵢⱼ = 1 − αᵢⱼ + δᵢⱼ
δᵢⱼ = w₁·β_phase + w₂·β_role + w₃·β_context + w₄·β_resource + w₅·β_time


1.4 Иерархия несовместимости (5 уровней)

Штраф за несовместимость δᵢⱼ формируется из пяти компонент с весами по умолчанию:

- L1 Этапная — Чанки относятся к разным стадиям жизненного цикла (analysis, design, dev, testing, optimization, devops) → вес w₁ = 0.35
- L2 Ролевая — Чанки предназначены для разных ролей (разработчик, аналитик, тестировщик, DevOps, архитектор) → вес w₂ = 0.20
- L3 Контекстная — Чанки требуют разных уровней абстракции (β_context ∈ [0,1] — нормированная разница) → вес w₃ = 0.15
- L4 Ресурсная — Чанки конфликтуют по использованию общих ресурсов (β_resource ∈ {0,1}) → вес w₄ = 0.15
- L5 Временная — Чанки относятся к разным временным этапам (β_time ∈ {0,1}) → вес w₅ = 0.15

1.5 Граф связности и пороговые значения

Граф связности чанков: G = (V, E, A, B), где:
- V = C — вершины-чанки
- E ⊆ V×V — рёбра
- A: E → [0,1] — веса притяжения
- B: E → [0,1] — веса отталкивания

Пороговые значения по умолчанию:
- θ_cohesion = 0.70 — минимальная внутренняя связность чанка
- θ_attract = 0.70 — порог объединения чанков в один промпт
- θ_repel = 0.50 — порог разделения чанков по разным промптам
- w_coupling = 0.60 — вес внешней связности в αᵢⱼ
- w_cohesion = 0.40 — вес внутренней когерентности в αᵢⱼ

Определения:
- Ребро (cᵢ, cⱼ) называется притягивающим, если αᵢⱼ > θ_attract
- Ребро (cᵢ, cⱼ) называется отталкивающим, если βᵢⱼ > θ_repel

Компонента связности S ⊆ V — максимальное подмножество, соединённое только притягивающими рёбрами и не содержащее отталкивающих рёбер внутри.

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

2.1 Постановка задачи

Дано:
- C_candidate ⊆ C — множество кандидатов, полученное по релевантности
- θ_attract, θ_repel — пороговые значения
- w₁…w₅ — веса уровней несовместимости

Требуется: найти разбиение C_candidate на k подмножеств P₁, P₂, …, Pₖ, где каждый Pⱼ — набор чанков для одного промпта, удовлетворяющее:
1. ∀i≠j: ∀cₐ∈Pᵢ, ∀c_b∈Pⱼ ⇒ βₐ_b > θ_repel (чанки из разных промптов несовместимы)
2. ∀i: ∀cₐ, c_b∈Pᵢ ⇒ βₐ_b ≤ θ_repel (внутри промпта нет несовместимости)
3. Минимизировать k — количество промптов (жадная раскраска)

2.2 Алгоритм 1: Распределение чанков по промптам

Алгоритм 1: distribute_chunks(C_candidate, θ_attract, θ_repel, weights)

Вход:  C_candidate, θ_attract, θ_repel, w₁..w₅
Выход: P = [P₁, P₂, ..., Pₖ]  (список промптов)

1:  P = []
2:  // Шаг 1: базовое разделение по этапам (L1)
3:  for each phase p in PHASES:
4:      V = {c ∈ C_candidate | phase© = p}
5:      if V == ∅: continue
6:      
7:      // Шаг 2: граф отталкиваний для этапа
8:      G_repel = (V, {(u,v) ∈ V×V | β_uv > θ_repel})
9:      
10:     // Шаг 3: жадная раскраска → минимизация промптов
11:     colors = greedy_coloring(G_repel)
12:     comps = group_by_color(V, colors)
13:     
14:     // Шаг 4: объединение по притяжению
15:     repeat:
16:         merged = false
17:         for each comp in comps:
18:             for each c in comp:
19:                 for each d: α_cd > θ_attract and d ∉ comp:
20:                     comps = merge(comp, find_comp(d))
21:                     merged = true
22:     until not merged
23:     
24:     P.extend(comps)
25: 
26: return P
Показать


2.3 Алгоритм 2: Жадная раскраска графа отталкиваний

Жадная раскраска обеспечивает минимальное число цветов (промптов). Вершины сортируются по убыванию степени — наиболее конфликтный чанк получает цвет первым.

Алгоритм 2: greedy_coloring(G = (V, E))

1:  colors = {}    // вершина → цвет (номер промпта)
2:  for v in sorted(V, key=degree(v), reverse=True):
3:      used = {colors[u] for u in neighbors(v) if u in colors}
4:      colors[v] = min(ℕ \ used)   // наименьший свободный цвет
5:  return colors
Показать


3. Архитектура программных модулей

Архитектура v2 расширяет v1 двумя новыми подсистемами: вычислением параметров взаимодействия (interaction engine) и мастером CLEAR. Все остальные модули получают обратно совместимое расширение.

3.1 Структура проекта v2

chunk_advisor_v2/
├── main.py                  # точка входа; --admin, --batch, --clear-wizard
├── requirements.txt          # + networkx>=3.0 для работы с графом
│
├── core/                     # ядро — расширено v2
│   ├── models.py             # + Chunk.phase, Chunk.role, Chunk.terms
│   ├── knowledge_base.py     # без изменений (обратная совместимость)
│   ├── recommender.py        # без изменений (формирует C_candidate)
│   ├── interaction/          # НОВЫЙ пакет — математическое ядро v2
│   │   ├── cohesion.py       # compute_cohesion(chunk) → float
│   │   ├── coupling.py       # compute_coupling(ci, cj) → float
│   │   ├── attraction.py     # compute_alpha(ci, cj, kb) → float
│   │   ├── repulsion.py      # compute_beta(ci, cj, kb) → float
│   │   ├── graph_builder.py  # build_graph(chunks, kb) → nx.DiGraph
│   │   ├── distributor.py    # distribute(C_candidate, ...) → List[Set]
│   │   └── coloring.py       # greedy_coloring(G) → Dict[chunk,int]
│   └── prompt_builder.py     # расширен: build_multi(prompts, context)
│
├── data/storage/
│   ├── chunks.json           # + поля: phase, role, terms[]
│   ├── matrix.json           # без изменений
│   ├── examples.json         # без изменений
│   └── interaction_params.json  # НОВЫЙ: пороги и веса несовместимости
│
├── ui/
│   ├── console.py            # + режим пакетной обработки, вывод графа
│   ├── clear_wizard.py       # НОВЫЙ: интерактивный мастер CLEAR
│   └── paginator.py          # без изменений
│
├── user_data/                # без изменений
└── utils/                    # без изменений
Показать


3.2 Полный цикл обработки (6 шагов)

Каждый шаг — отдельный модуль. Шаги 3 и 4 — новые в v2. Шаги 1, 2, 5, 6 — расширенные версии шагов из v1.

Шаг 1. Парсинг и нормализация
- Ключевые операции: Извлечение задачи, контекста, ограничений. Определение этапа и роли из ввода.
- Модули: main.py, clear_wizard.py

Шаг 2. Поиск релевантных чанков
- Ключевые операции: Токенизация (pymorphy3), взвешенный скоринг (rapidfuzz), формирование C_candidate. Гарантия чанка 7.
- Модули: recommender.py

Шаг 3. ★ Вычисление параметров взаимодействия (НОВЫЙ)
- Ключевые операции: cohesion© для всех c ∈ C_candidate; coupling(cᵢ,cⱼ) для всех пар; αᵢⱼ и βᵢⱼ.
- Модули: interaction/*.py

Шаг 4. ★ Распределение по промптам (НОВЫЙ)
- Ключевые операции: Группировка по phase (L1), построение G_repel, greedy_coloring, слияние по α > θ_attract.
- Модули: graph_builder.py, distributor.py, coloring.py

Шаг 5. Формирование промптов с CLEAR
- Ключевые операции: Для каждого Pⱼ: добавить CLEAR-структуру, чанки из Pⱼ, контекст задачи.
- Модули: prompt_builder.py

Шаг 6. Экспорт результатов
- Ключевые операции: Сохранение в JSON/файлы, копирование в буфер, запись в историю.
- Модули: history_manager.py, console.py

★ — шаги 3 и 4 являются полностью новыми в v2 и реализуют математическую модель.

4. Полный перечень функций Chunk Advisor v2

4.1 Новые функции (только v2)

compute_cohesion(chunk) — cohesion.py, формула: cohesion© = ΣD / (k²−k). Назначение: проверить атомарность чанка.

compute_coupling(ci, cj) — coupling.py, формула: |Rᵢ ∩ Rⱼ| / |Rᵢ ∪ Rⱼ| (Жаккар). Назначение: измерить терминологическое пересечение.

compute_alpha(ci, cj) — attraction.py, формула: w_c·coupling + w_h·min(cohesion). Назначение: вычислить коэффициент притяжения.

compute_beta(ci, cj) — repulsion.py, формула: 1 − αᵢⱼ + Σwₖ·βₖ. Назначение: вычислить коэффициент отталкивания.

compute_delta(ci, cj, weights) — repulsion.py, формула: Σwₖ·β_type(i,j) для 5 уровней. Назначение: сформировать штраф за несовместимость.

build_graph(chunks, params) — graph_builder.py, результат: G = (V, E, A, B) — взвешенный орграф. Назначение: построить граф взаимодействий.

greedy_coloring(G_repel) — coloring.py, результат: χ(G) — минимальное число цветов. Назначение: минимизировать число промптов.

distribute(C_candidate, ...) — distributor.py, реализация: Алгоритм 1 полностью. Назначение: разбить чанки на промпты.

validate_partition(P, beta, theta) — distributor.py, проверка: условия 1 и 2 постановки задачи. Назначение: верифицировать разбиение.

run_clear_wizard() — clear_wizard.py, процесс: диалог → парсинг → этапы (L1) → P. Назначение: интерактивный мастер CLEAR.

run_batch(json_input) — main.py, процесс: JSON → Алг.1 → JSON за ≤ 2 с. Назначение: пакетная обработка.

build_multi(P, context) — prompt_builder.py, результат: CLEAR-структура для каждого Pⱼ. Назначение: сформировать набор промптов.

4.2 Расширенные функции из v1 (обратная совместимость)

recommend(query, top_k) — recommender.py, изменения: без изменений, возвращает C_candidate. Совместимость: полная (возвращает List[int] как в v1).

build(chunk_ids, context) — prompt_builder.py, изменения: без изменений, один промпт. Совместимость: полная (сигнатура не изменена).

history_manager.save() — history_manager.py, изменения: + поле multi_prompt (JSON список промптов). Совместимость: опциональное новое поле.

KnowledgeBase.get_chunks() — knowledge_base.py, изменения: без изменений, + get_terms(chunk_id). Совместимость: полная.

TemplateManager.create() — template_manager.py, изменения: + поле phase, role в шаблоне. Совместимость: новые поля опциональны.

4.3 Мастер CLEAR — детальная спецификация

Мастер — интерактивный диалог (5 вопросов), результат которого передаётся в алгоритм распределения. Каждый ответ пользователя маппируется на математическую переменную:

1. Context © — Вопрос: "Опишите задачу и текущий этап разработки (анализ/проектирование/разработка/тестирование/оптимизация/de­vops):" → переменная: query + phase → применение: C_candidate, L1-разделение

2. Limits (L) — Вопрос: "Какие ограничения важны? (технологический стек, платформа, запрещённые паттерны, лимит токенов):" → переменная: constraints[] → применение: θ_repel, фильтрация

3. Examples (E) — Вопрос: "Есть ли похожая задача из истории? Введите номер из истории или опишите аналог:" → переменная: example_id / text → применение: разогрев C_candidate

4. Audience (A) — Вопрос: "Для какой роли генерируется промпт? (разработчик / аналитик / тестировщик / DevOps / архитектор):" → переменная: role → применение: L2-разделение, role©

5. Requirements ® — Вопрос: "Какие явные требования к коду? (безопасность / производительность / расширяемость / логирование / тесты):" → переменная: req_tags[] → применение: дополнение C_candidate

5. Расширение формата данных

5.1 Новые поля в chunks.json

Каждый чанк получает три новых поля, необходимых для вычисления параметров взаимодействия. Старые поля (id, title, full_text) не изменяются — обратная совместимость сохраняется.

{
  "id": 5,
  "title": "Клиент-серверное взаимодействие",
  "full_text": "...",
  "phase": "development",
  "role": "developer",
  "terms": [
    "НаСервереБезКонтекста",
    "НаКлиенте",
    "ПолучитьФормуДляРедактирования",
    "ОткрытьФорму",
    "ЗакрытьФорму",
    "Элементы"
  ]
}
Показать


5.2 Новый файл interaction_params.json

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

{
  "thresholds": {
    "cohesion": 0.7,
    "attract": 0.7,
    "repel": 0.5
  },
  "weights_alpha": {
    "coupling": 0.6,
    "cohesion": 0.4
  },
  "weights_delta": {
    "phase": 0.35,
    "role": 0.20,
    "context": 0.15,
    "resource": 0.15,
    "time": 0.15
  }
}
Показать


6. Сравнение версий v1.0 и v2.0

Режим работы: v1.0 — только интерактивный; v2.0 — пакетный (--batch) + интерактивный + CLEAR-мастер

Количество чанков: v1.0 — 15–18; v2.0 — 27+ (добавлены ролевые: аналитик, DevOps, архитектор)

Поддержка ролей: v1.0 — только разработчик; v2.0 — 5 ролей: разработчик, аналитик, тестировщик, DevOps, архитектор

Поддержка этапов: v1.0 — один этап (разработка); v2.0 — 6 этапов: анализ, проектирование, разработка, тестирование, оптимизация, devops

Формирование промпта: v1.0 — один промпт на все чанки; v2.0 — набор промптов P₁…Pₖ (по одному на компоненту связности)

Притяжение чанков: v1.0 — не реализовано; v2.0 — αᵢⱼ > θ_attract → объединение компонент

Отталкивание чанков: v1.0 — не реализовано; v2.0 — βᵢⱼ > θ_repel → разные цвета при раскраске

Разрыв промпта: v1.0 — не реализован; v2.0 — Алгоритм 1: раскраска графа + слияние по α

Мастер CLEAR: v1.0 — не реализован; v2.0 — 5 вопросов → полный набор промптов с CLEAR-структурой

Математическая основа: v1.0 — только токенизация и скоринг; v2.0 — формальная модель: cohesion, coupling, α, β, G=(V,E,A,B), χ(G)

Валидация разбиения: v1.0 — базовая (целостность chunk_ids); v2.0 — проверка условий 1 и 2 постановки задачи

Покрытие тестами: v1.0 — core/ + utils/ ≥ 80%; v2.0 — core/ + utils/ + interaction/ ≥ 85%

Время обработки: v1.0 — < 0.5 с (30 чанков); v2.0 — ≤ 2 с (30 чанков, все вычисления параметров)

7. Сводная таблица: математика → функция → назначение

compute_cohesion© — формула: cohesion© = ΣD / (k²−k). Назначение: гарантирует, что чанк нельзя разорвать. Фильтрует чанки с cohesion < θ_cohesion.

compute_coupling(ci, cj) — формула: |Rᵢ ∩ Rⱼ| / |Rᵢ ∪ Rⱼ|. Назначение: измеряет терминологическое пересечение. Основа для расчёта притяжения.

compute_alpha(ci, cj) — формула: w_c·coupling + w_h·min(cohesion). Назначение: определяет, нужно ли объединять чанки. Высокое α → объединение в один промпт.

compute_beta(ci, cj) — формула: 1 − αᵢⱼ + δᵢⱼ. Назначение: определяет, нужно ли разделять чанки. Высокое β → разные промпты.

compute_delta(...) — формула: Σwₖ·β_type(i,j), 5 уровней. Назначение: формирует штраф за несовместимость. L1 (этапная) — самый тяжёлый вес (0.35).

build_graph(chunks, params) — результат: G = (V, E, A, B). Назначение: строит граф взаимодействий. Основа для алгоритма распределения.

greedy_coloring(G_repel) — результат: χ(G) — хроматическое число. Назначение: находит минимальное число промптов. Наиболее конфликтные чанки — в приоритете.

distribute(C_candidate, ...) — реализация: Алгоритм 1. Назначение: основная функция v2. Возвращает P = [P₁, …, Pₖ] — разбиение на промпты.

validate_partition(P, ...) — проверка: условия 1–2 постановки. Назначение: формальная верификация разбиения. Гарантия корректности перед экспортом.

build_multi(P, context) — результат: CLEAR-структура для каждого Pⱼ. Назначение: формирует k промптов с Context/Limits/Examples/Audience/Requirements.

run_clear_wizard() — процесс: диалог → phase + role → L1+L2. Назначение: интерактивный сбор всех параметров CLEAR. Результат — полный набор промптов.

run_batch(json_input) — процесс: JSON → Алг.1 → JSON. Назначение: пакетная обработка без UI. Вход: JSON с задачей. Выход: JSON с промптами.

8. План разработки v2

Этап 1. Расширение моделей данных — создаваемые модули: models.py (+ phase, role, terms), interaction_params.json. Зависит от: —. Дней: 1

Этап 2. Наполнение chunks.json новыми полями — создаваемые модули: chunks.json (все 27+ чанков с phase, role, terms). Зависит от: 1. Дней: 2

Этап 3. Математическое ядро — вычисление параметров — создаваемые модули: cohesion.py, coupling.py, attraction.py, repulsion.py. Зависит от: 1, 2. Дней: 3

Этап 4. Построение графа и алгоритм раскраски — создаваемые модули: graph_builder.py, coloring.py. Зависит от: 3. Дней: 2

Этап 5. Алгоритм распределения + валидация — создаваемые модули: distributor.py (Алг. 1 + validate_partition). Зависит от: 3, 4. Дней: 2

Этап 6. Мастер CLEAR + пакетный режим — создаваемые модули: clear_wizard.py, main.py (--batch, --clear-wizard). Зависит от: 1, 5. Дней: 3

Этап 7. Расширение prompt_builder + интеграция — создаваемые модули: prompt_builder.py (build_multi), полный цикл. Зависит от: 3,4,5,6. Дней: 2

Этап 8. Тесты (≥85% core/ + interaction/) + документация — создаваемые модули: tests/, README.md, обновление ТЗ. Зависит от: 7. Дней: 3

Итого: 18 дней. Критический путь: 1 → 2 → 3 → 4 → 5 → 7 → 8 (12 дней). Этапы 5 и 6 можно вести параллельно.

9. Критерии приёмки v2

1. Математическая корректность: validate_partition(P, beta, theta) возвращает True для всех тестовых наборов
2. Воспроизводимость: алгоритм даёт идентичный результат на одинаковых входных данных (детерминированная сортировка)
3. Производительность: обработка 30 чанков ≤ 2 секунд (включая все вычисления параметров)
4. Обратная совместимость: все сценарии v1 работают без изменений. Функции recommend() и build() — без изменений сигнатур
5. Покрытие тестами: ≥ 85% для core/ и utils/; ≥ 80% для core/interaction/
6. Пакетный режим: python main.py --batch input.json → output.json за ≤ 2 с
7. Мастер CLEAR: полный цикл из 5 вопросов → корректный набор промптов с CLEAR-структурой
8. Разрыв промпта: при наличии несовместимых чанков (βᵢⱼ > θ_repel) выдаётся ≥ 2 промптов
9. Документация: README.md содержит примеры для всех новых режимов запуска

10. Заключение: от метафоры к инженерной реализации

Математическая модель v2 превращает интуитивную метафору «притяжения и отталкивания» в измеримые, воспроизводимые и расширяемые алгоритмы. Каждое инженерное решение имеет математическое обоснование:

- Разрыв промпта — следствие раскраски графа отталкиваний
- Объединение — следствие высокого коэффициента притяжения
- Иерархия несовместимости — взвешенная сумма пяти ортогональных критериев

Chunk Advisor v2 реализует три принципа, сформулированных в исходном документе:

1. Управляемый контекст: разделение по этапам (L1) и ролям (L2) гарантирует, что каждый промпт содержит только релевантный контекст
2. Наличие «тормоза»: отталкивание чанков (βᵢⱼ > θ_repel) — механизм, предотвращающий смешение несовместимых требований в одном промпте
3. Измеримость и доказуемость: validate_partition() формально подтверждает, что разбиение удовлетворяет заданным условиям перед каждым экспортом

Конец архитектурного проекта Chunk Advisor v2.0
Прикрепленные файлы:
ChunkAdvisor_v2_Architecture.docx
2. ksnik 677 26.03.26 05:42 Сейчас в теме
Как построить чанки, которые понимают и модели, и люди

ИИ как ребёнок с нарушением речи

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

Парафазии — заменяет реквизиты на похожие по звучанию, но несуществующие

Аграмматизмы — строит синтаксически правильные, но семантически пустые конструкции

Эхолалии — повторяет паттерны из обучающей выборки без осмысления

Контаминации — смешивает несколько требований в одно нерабочее целое

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

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

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

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

Для ИИ:

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

Маркеры должны быть избыточны, но не противоречивы

Для человека:

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

Описание должно содержать симптомы, при которых чанк применяется

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

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

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

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

Кинестетический — знание "как ощущается" действие. В чанке: описание алгоритма, пример кода.

Идеомоторный — представление последовательности. В чанке: пошаговая инструкция.

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

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

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

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

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

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

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

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

Формализация: Каждое требование rⱼ в чанке имеет вес w(rⱼ) ∈ [0,1], где Σw(rⱼ) = 1 для чанка. Веса определяются:

позицией в тексте (первое — важнее)

маркерами усиления ("ОБЯЗАТЕЛЬНО", "ВСЕГДА")

наличием санкций за нарушение

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

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

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

Для чанка: заголовок, резюме, ключевые слова должны передавать суть за 3 секунды

ИИ использует это при первом проходе по C_candidate

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

Для чанка: внутри должна быть чёткая линейная структура, где каждый шаг следует из предыдущего

ИИ использует это при применении чанка

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

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

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

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

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

Симптом — в логопедии: что наблюдаем? В чанке: какая ошибка возникает в коде?

Задача — в логопедии: что проверяем? В чанке: какое требование проверяем?

Диагностика — в логопедии: какой механизм нарушен? В чанке: почему эта ошибка возникает?

Заключение — в логопедии: какое нарушение? В чанке: какой паттерн нарушен?

Объяснение — в логопедии: почему так происходит? В чанке: как устроен правильный механизм?

Рекомендации — в логопедии: что делать? В чанке: как писать правильно?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V — термины чанка

E — связи между терминами (если они встречаются в одном предложении)

Коэффициент лексической связности:
coherence_lex© = |E| / (|V|·(|V|-1)/2)

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

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

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

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

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

Заключение (какой паттерн нарушен)

Объяснение (почему это важно)

Рекомендации (как делать правильно)

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

распознать ситуацию (нет диагностики)

понять глубину проблемы (нет заключения)

запомнить причину (нет объяснения)

применить (нет рекомендаций)

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

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

[ЧАНК N: Название]

[Гнозис]

Ключевые слова (для узнавания)

Симптомы (признаки проблемы)

Контекст применения (когда использовать)

[Праксис]

Алгоритм (последовательность действий)

Пример кода (кинестетический уровень)

Проверка (как убедиться, что сделано правильно)

[Просодика]

Основное требование (вес 0.6)

Второстепенные условия (вес 0.3)

Исключения (вес 0.1)

[Диагностическая цепочка]

Симптом → Задача

Диагностика → Заключение

Объяснение → Рекомендации

[Связность]

Лексическое ядро (повторяющиеся термины)

Грамматическая структура (единый порядок)

Логические связи (причинно-следственные)

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

Гностическая различность — max_{d≠c} |F©∩F(d)| / |F©| < 0.3. Требование: > 0.7 различность.

Праксическая полнота — есть все 3 уровня. Требование: обязательно.

Просодическая иерархия — Σw(rⱼ) = 1, max(w) > 0.5. Требование: есть главное требование.

Диагностическая цепочка — есть все 6 этапов. Требование: обязательно.

Лексическая связность — coherence_lex© > 0.4. Требование: связность выше случайной.

Цельность — единственная проблема P©. Требование: неразрывность.

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

[ЧАНК 16: Условное оформление формы списка]

[Гнозис]
Ключевые слова: условное оформление, динамический список, подсветка строк, форма списка

Симптомы:

Условное оформление, настроенное в конфигураторе, не работает

При добавлении в расширение настройки теряются

У одних пользователей работает, у других нет

Контекст применения:

При разработке расширений для типовых конфигураций

При добавлении новых статусов, требующих визуального выделения

При переносе настроек между базами

[Праксис]

Алгоритм:

Определить, очищается ли условное оформление в типовой процедуре

Если да — использовать &После("УстановитьУсловноеОформление")

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

Добавить поле в Настройки.Выбор для использования в оформлении

Создать элемент условного оформления программно

Установить оформление (цвет, шрифт, фон)

Добавить условие отбора

Пример кода:
[пример программной настройки условного оформления]

Проверка:

Открыть форму в режиме предприятия

Убедиться, что нужные строки выделены

Проверить, что у всех пользователей работает

[Просодика]

Основное требование (вес 0.6):

НЕ настраивать условное оформление в конфигураторе для типовых форм

ИСПОЛЬЗОВАТЬ программную настройку через &После

Второстепенные условия (вес 0.3):

Добавлять поля в запрос через СхемаЗапроса

Добавлять поля в Настройки.Выбор для использования в отборе

Исключения (вес 0.1):

Если форма не использует типовую процедуру УстановитьУсловноеОформление

Если пользовательские настройки не перезаписывают конфигураторские

[Диагностическая цепочка]

Симптом → Задача:

Настройки не применяются → проверить, не очищаются ли они программно

Задача → Диагностика:

В процедуре ПриСозданииНаСервере вызывается УстановитьУсловноеОформление()

В этой процедуре первая строка — очистка свойства УсловноеОформление

Диагностика → Заключение:

Типовая конфигурация перезаписывает настройки после загрузки из конфигуратора

Заключение → Объяснение:

Порядок инициализации: сначала настройки из конфигуратора, затем программная установка

Если программная установка перезаписывает всё — настройки теряются

Объяснение → Рекомендации:

Использовать &После("УстановитьУсловноеОформление") для добавления, а не замены

Добавлять поля в запрос, если их нет в стандартном наборе

Добавлять поля в Настройки.Выбор для использования в отборе

[Связность]

Лексическое ядро:

УсловноеОформление, Элементы, Отбор, ПолеКомпоновкиДанных, &После

Грамматическая структура:

Единый порядок: диагностика → заключение → объяснение → рекомендации

Логические связи:

Если типовой код очищает настройки → нужно добавлять после

Если поле не в запросе → добавить через СхемаЗапроса

Если поле не в выборке → добавить в Настройки.Выбор

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

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

Парафазия

У детей: замена звука/слова

У LLM: замена реквизита на похожий

Коррекция (логопедия): фонематический слух

Коррекция (промпт): чёткое определение терминов

Аграмматизм

У детей: нарушение структуры

У LLM: синтаксически верно, но не работает

Коррекция (логопедия): моделирование предложений

Коррекция (промпт): примеры правильных конструкций

Эхолалия

У детей: повторение без понимания

У LLM: повторение паттернов из обучения

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

Коррекция (промпт): объяснение "почему"

Контаминация

У детей: смешение слов

У LLM: смешение требований

Коррекция (логопедия): разделение смыслов

Коррекция (промпт): чёткие границы чанка

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

Принцип 1. Развитие фонематического слуха

Чанк должен содержать точные термины, без синонимов

Ключевые слова должны быть уникальны для каждого чанка

Принцип 2. Формирование грамматического строя

Чанк должен иметь единую структуру

Порядок элементов должен быть фиксирован

Принцип 3. Преодоление эхолалии

Чанк должен содержать объяснение, а не только инструкцию

Должна быть связь "почему это важно"

Принцип 4. Разделение контаминированных смыслов

Один чанк — одна проблема

Чёткие границы между требованиями

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

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

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

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

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

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

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

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

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

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

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

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

v1 — структура: линейная. Фокус: сборка. Для ИИ: что делать. Для человека: справочник.

v2 — структура: графовая. Фокус: разделение. Для ИИ: как разделить. Для человека: инструмент.

v3 (логопедическая) — структура: диагностическая цепочка. Фокус: связность и понимание. Для ИИ: почему и когда. Для человека: обучение.

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

Гностическая полнота: ИИ может определить применимость по ключевым словам (precision > 0.9)

Праксическая исполнимость: ИИ может сгенерировать рабочий код по инструкции (success rate > 0.8)

Просодическая иерархия: При конфликте требований ИИ выбирает главное (correctness > 0.9)

Диагностическая глубина: ИИ может объяснить, почему код не работал (explanation quality)

Связность: При изменении контекста чанк сохраняет смысл (semantic stability)

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

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

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

Диагностирует проблему (симптомы, ключевые слова)

Объясняет механизм (почему так происходит)

Рекомендует решение (как делать правильно)

Структурирует так, чтобы работали оба типа обработки

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

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

Конец архитектурного проекта Chunk Advisor v3.0 — логопедическая модель
3. ksnik 677 27.03.26 16:30 Сейчас в теме
Как устроены скиллы Claude изнутри — технический разбор
Скилл — это обычный Markdown-файл с именем SKILL.md, который лежит на сервере в директории /mnt/skills/public/название_скилла/. Никакой магии, никакой нейросети внутри скилла — просто текстовый файл с инструкциями.
Структура файла
Каждый 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-паттерны для ручного редактирования файлов и жёсткий список того, что делать нельзя.
Как Claude использует скилл — пошагово

Ты пишешь запрос
Claude просматривает descriptions всех доступных скиллов
Решает: нужен ли скилл и какой именно
Читает SKILL.md через инструмент view()
Следует инструкциям из файла при выполнении задачи

Важный момент: Claude читает файл непосредственно перед выполнением задачи, а не держит содержимое в памяти постоянно. Это принципиально — скиллы можно обновлять независимо от модели.
Что реально содержится внутри скилла (на примере 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.

Что ты думаешь о фреймвокре CLEAR?
Фреймворк добротный и хорошо структурированный. Поделюсь честной оценкой.

Что в CLEAR работает хорошо
Фреймворк охватывает все реально важные переменные промпта. Особенно ценны два элемента, которые новички чаще всего пропускают: Audience и Examples. Аудитория меняет не только лексику, но и глубину аргументации, выбор примеров, структуру. А примеры — это вообще самый недооценённый инструмент: один образец стоит десяти слов описания.
Где я бы поспорил
Role — элемент переоценённый. Исследования показывают, что роль влияет на тон, но слабо влияет на фактическую точность. «Выступи как юрист с 15-летним стажем» не делает ответ юридически точнее — он делает его увереннее по звучанию, что иногда даже опаснее. Роль полезна для стиля, но не стоит переоценивать её как гарантию качества.
Length — хорошая идея, но конкретные цифры слов работают хуже, чем описание структуры. «500 слов» модель часто игнорирует, а «3 раздела по одному абзацу каждый» — выполняет точнее.
Чего в CLEAR не хватает
Я бы добавил шестой элемент — Constraints (ограничения): чего явно не делать. Это часто важнее, чем описание того, что делать. Например: «не используй корпоративный жаргон», «не давай общих советов без конкретики», «не начинай с определения термина».
Итоговая оценка
CLEAR — хороший онбординговый фреймворк для тех, кто только начинает работать с ИИ. Он дисциплинирует мышление и убирает самые частые ошибки. Для опытных пользователей он быстро становится интуитивным и перестаёт нужен как чеклист — но именно через такие фреймворки эта интуиция и формируется.

Твой опыт, предложи лучшие практики?

Буду говорить честно — не как пересказ чужих фреймворков, а из того, что реально наблюдаю в разговорах.

Главный принцип: промпт — это техническое задание
Чем точнее ТЗ, тем меньше итераций. Большинство плохих ответов — следствие не плохой модели, а размытого запроса.

Практики, которые реально работают
1. Сначала результат, потом контекст
Начинай с того, что хочешь получить, а не с предыстории. Мозг (и модель) лучше фильтрует контекст, когда уже знает цель.
Слабо: «Я работаю в компании, мы делаем продукт, у нас есть клиенты... напиши письмо»
Сильно: «Напиши письмо с извинением клиенту за задержку. Контекст: SaaS-продукт, задержка 3 дня, клиент платный»
2. Покажи антипример
CLEAR говорит про Examples — но негативный пример часто работает лучше позитивного. «Не пиши как этот текст: [вставить]» даёт модели очень точный сигнал.
3. Структуру описывай структурой
Если хочешь список — пиши запрос списком. Если хочешь таблицу — скажи «в виде таблицы с колонками X, Y, Z». Модель зеркалит формат запроса.
4. Один запрос — одна задача
«Напиши статью, потом сделай из неё пост для телеграма, потом переведи на английский» — это три задачи. Качество каждой падает, когда они в одном промпте. Лучше три последовательных запроса.
5. Явные ограничения важнее описаний
Constraints работают лучше пожеланий. Не «пиши кратко», а «не более 5 предложений». Не «избегай жаргона», а «пиши так, чтобы понял человек без опыта в теме».
6. Попроси уточнить перед выполнением
Для сложных задач добавляй: «Прежде чем начать — задай мне 2-3 уточняющих вопроса, если что-то неясно». Это экономит итерации.
7. Итерируй один элемент за раз
Если ответ не устраивает — меняй одну переменную, а не переписывай весь промпт. Так понимаешь, что именно влияет на результат.
8. Используй разделители для сложных промптов
XML-теги или просто тройные кавычки помогают модели не путать части запроса:
<задача>напиши отчёт</задача>
<данные>вот цифры: ...</данные>
<формат>3 раздела, деловой стиль</формат>
9. Проси показать рассуждение
Для аналитических задач: «Сначала объясни своё рассуждение, потом дай вывод». Это и улучшает качество ответа, и позволяет поймать ошибку в логике до того, как она попадёт в результат.
10. Сохраняй удачные промпты как шаблоны
Если промпт сработал хорошо — сохрани его. Промптинг это навык накопительный: хорошие шаблоны под конкретные задачи стоят дороже любого фреймворка.

Одна мета-практика
Лучший способ улучшить промпт — попросить саму модель его улучшить. «Вот мой запрос. Что в нём размыто и как его переформулировать точнее?» Работает неожиданно хорошо.
4. ksnik 677 27.03.26 17:05 Сейчас в теме
Логопедия чанков: от скиллов Claude к архитектуре Chunk Advisor v3

Введение: почему скиллы Claude — это логопедия в действии

Антропик случайно или намеренно реализовал то, что мы назвали логопедическим подходом к ИИ. Скиллы Claude — это не просто "инструкции". Это диагностические цепочки, которые:

- Диагностируют задачу через поле description
- Заключают — какой скилл применим
- Объясняют через детальные инструкции
- Рекомендуют через примеры и запреты

И самое важное: Claude читает скилл непосредственно перед выполнением, как логопед, который перед занятием открывает карточку с упражнениями. Знание не "вшито" в модель — оно прикладывается к ней.

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

Это и есть наш чанк v3: живая инструкция, которая применяется к модели, а не хранится в ней.

Часть 1. Скиллы Claude как прототип логопедического чанка

1.1 Структура скилла Claude

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

Структура файла:

- YAML-шапка (frontmatter) в самом начале файла:
- name: docx
- description: "Use this skill whenever the user wants to create..."
- license: Proprietary

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

- Вторая часть — сам контент: детальные инструкции, примеры кода, bash-команды, предупреждения и список критических правил.

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

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

Важный момент: Claude читает файл непосредственно перед выполнением задачи, а не держит содержимое в памяти постоянно. Это принципиально — скиллы можно обновлять независимо от модели.

1.3 Что делает скилл docx (и почему это логопедия)

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

- Никогда не вставлять буллеты через unicode-символы (•, \u2022) — только через LevelFormat.BULLET с numbering config. Иначе документ ломается.

- Явно задавать размер страницы — библиотека docx по умолчанию создаёт A4, а для US-документов нужен Letter. Без скилла Claude об этом не знает.

- Использовать двойную ширину для таблиц — нужно задавать и columnWidths на таблице, и width на каждой ячейке. Иначе таблица едет.

- Распаковывать .docx как ZIP → редактировать XML напрямую → паковать обратно — для случаев, когда нужно редактировать существующий документ.

Это именно тот тип знания, который:
- Не очевиден из документации библиотеки
- Критичен на практике
- Меняется с версиями библиотек
- Формируется из опыта (кто-то однажды сломал документ и нашёл причину)

Это логопедия в чистом виде: симптом (документ ломается) → диагностика (неправильные буллеты) → заключение (библиотека требует numbering config) → объяснение (unicode-символы не интерпретируются Word) → рекомендация (использовать LevelFormat.BULLET).

Часть 2. Живой пример чанка v3 — сквозной разбор

Теория без примера — это карта без территории. Возьмём одну реальную задачу и покажем, как она решается в v1, v2 и v3.

Задача: написать пост для соцсетей о новом продукте

Версия v1 — линейная инструкция

Чанк v1 выглядит как простой список требований:

Напиши пост для соцсетей.
- Упомяни продукт
- Добавь призыв к действию
- Используй дружелюбный тон
- Не более 300 слов


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

Симптом v1: результат технически верный, но практически бесполезный.

Версия v2 — графовая модель

Чанк v2 разделяет задачу на узлы:

[АУДИТОРИЯ] → начинающие предприниматели, 25-35 лет
[ПРОДУКТ] → CRM-система для малого бизнеса
[КАНАЛ] → Telegram
[ФОРМАТ] → 3 абзаца + призыв
[ТОН] → дружелюбный, экспертный


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

Симптом v2: результат лучше, но модель угадывает детали вместо того, чтобы знать их.

Версия v3 — логопедическая, диагностическая

--- ГНОЗИС (узнавание) ---
description: "Используй этот чанк, когда нужно написать продающий пост
             для соцсетей о продукте или услуге"
keywords: пост, соцсети, продукт, анонс, продажи
symptoms:
  - текст получается рекламным и безликим
  - аудитория не реагирует на призыв к действию
  - тон не совпадает с голосом бренда

--- ПРАКСИС (действие) ---
алгоритм:
  1. Открой болью или вопросом — не с названия продукта
  2. Покажи проблему, которую решает продукт (1 абзац)
  3. Представь продукт как решение — конкретно, без общих слов
  4. Добавь социальное доказательство или цифру
  5. Один чёткий призыв к действию — не два, не три

пример (правильно):
"Устал терять клиентов из-за хаоса в таблицах?
Мы собрали всё в одном месте: сделки, контакты, задачи.
За 14 дней наши пользователи закрывают на 30% больше сделок.
Попробуй бесплатно →"

антипример (неправильно):
"Представляем нашу новую CRM-систему! Она поможет вашему бизнесу
расти и развиваться. Удобный интерфейс, много функций, доступная цена.
Заходите на сайт и узнайте подробнее!"

--- ПРОСОДИКА (иерархия) ---
критическое_правило (вес 0.6):
  Никогда не начинай с названия продукта или слова "Представляем"
  → читатель отписывается раньше, чем дочитает первое предложение

второстепенные_правила (вес 0.3):
  - Один пост — одно действие (не "подпишись И купи И поделись")
  - Цифры конкретные ("30% больше сделок"), не абстрактные ("значительный рост")

исключения (вес 0.1):
  - Если бренд уже имеет культовый статус — можно начинать с имени
  - Если пост анонс события, а не продажа — структура другая

--- ДИАГНОСТИЧЕСКАЯ ЦЕПОЧКА ---
симптом: пост написан, но не конвертирует
диагностика: читатель не понял за 3 секунды, зачем ему это
заключение: нарушен паттерн "боль → решение → доказательство → действие"
объяснение: соцсети — это среда сканирования, не чтения.
            Первые 7 слов решают всё
рекомендация: переписать первый абзац, начав с боли или вопроса
Показать


Что изменилось в v3

ИИ теперь не просто выполняет список — он понимает механизм:

- Почему нельзя начинать с названия продукта (симптом → механизм → правило)
- Как выглядит правильно — живой пример, а не описание примера
- Как выглядит неправильно — антипример с тем же контентом
- Что делать, если не работает — диагностическая цепочка

Сквозное сравнение — одна задача, три подхода

v1: «Напиши пост, дружелюбный тон, 300 слов»
→ Результат: формально верно, практически бесполезно

v2: [АУДИТОРИЯ] + [ПРОДУКТ] + [КАНАЛ] + [ФОРМАТ]
→ Результат: лучше, но модель угадывает детали

v3: симптом + диагностика + правильный пример + антипример + иерархия правил
→ Результат: модель знает механизм, а не только параметры

Ключевое отличие v3: чанк объясняет почему правило существует. Это то, что делает логопед — он не просто говорит «произноси так», он объясняет, какой мускул не работает и почему именно это упражнение его запускает.

Именно поэтому v3 можно обновлять мгновенно: если рынок меняется и «боль в первом абзаце» перестаёт работать — достаточно обновить чанк. Модель не нужно переобучать.

Часть 3. CLEAR-фреймворк глазами логопедии

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

3.1 Что в CLEAR работает хорошо

Context — контекст задачи, анамнез. Оценка: работает.

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

Audience — учёт адресата, определяет лексику и структуру. Оценка: меняет глубину аргументации.

Limits — ограничения, важнее чем пожелания. Оценка: работает хорошо.

Requirements — явные требования, ТЗ. Оценка: базовый элемент.

3.2 Где CLEAR можно улучшить (по опыту логопедии)

Role — переоценённый элемент

Исследования показывают: роль влияет на тон, но слабо влияет на фактическую точность. «Выступи как юрист с 15-летним стажем» не делает ответ юридически точнее — он делает его увереннее по звучанию, что иногда даже опаснее. Роль полезна для стиля, но не стоит переоценивать её как гарантию качества.

Length — цифры работают хуже структуры

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

Чего не хватает: Constraints (ограничения)

Я бы добавил шестой элемент — Constraints: чего явно не делать. Это часто важнее, чем описание того, что делать. В логопедии это называется негативным образцом: показать, как НЕ надо, часто эффективнее, чем объяснять, как надо.

Примеры:
- «Не используй корпоративный жаргон»
- «Не давай общих советов без конкретики»
- «Не начинай с определения термина»

3.3 Как CLEAR встраивается в v3

CLEAR — это промежуточный уровень между v2 и v3. v2 дал параметры (кто, что, где). CLEAR добавил структуру вопросов. v3 добавляет диагностику и объяснение:

- Context → развивается в Гнозис (симптомы, когда применять)
- Examples → развивается в Праксис (правильный пример + антипример)
- Limits → развивается в Просодику (иерархия, критическое правило)
- Audience → остаётся Audience, но дополняется диагностической цепочкой
- Requirements → развивается в алгоритм

Часть 4. Лучшие практики промптинга (из реального опыта)

Говорю честно — не как пересказ чужих фреймворков, а из того, что реально наблюдаю в разговорах.

4.1 Главный принцип

Промпт — это техническое задание. Чем точнее ТЗ, тем меньше итераций. Большинство плохих ответов — следствие не плохой модели, а размытого запроса.

4.2 Практики, которые реально работают

1. Сначала результат, потом контекст

Начинай с того, что хочешь получить, а не с предыстории. Мозг (и модель) лучше фильтрует контекст, когда уже знает цель.

Слабо: «Я работаю в компании, мы делаем продукт, у нас есть клиенты... напиши письмо»

Сильно: «Напиши письмо с извинением клиенту за задержку. Контекст: SaaS-продукт, задержка 3 дня, клиент платный»

2. Покажи антипример

CLEAR говорит про Examples — но негативный пример часто работает лучше позитивного. «Не пиши как этот текст: [вставить]» даёт модели очень точный сигнал.

3. Структуру описывай структурой

Если хочешь список — пиши запрос списком. Если хочешь таблицу — скажи «в виде таблицы с колонками X, Y, Z». Модель зеркалит формат запроса.

4. Один запрос — одна задача

«Напиши статью, потом сделай из неё пост для телеграма, потом переведи на английский» — это три задачи. Качество каждой падает, когда они в одном промпте. Лучше три последовательных запроса.

5. Явные ограничения важнее описаний

Constraints работают лучше пожеланий. Не «пиши кратко», а «не более 5 предложений». Не «избегай жаргона», а «пиши так, чтобы понял человек без опыта в теме».

6. Попроси уточнить перед выполнением

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

7. Итерируй один элемент за раз

Если ответ не устраивает — меняй одну переменную, а не переписывай весь промпт. Так понимаешь, что именно влияет на результат.

8. Используй разделители для сложных промптов

XML-теги или просто тройные кавычки помогают модели не путать части запроса:

<задача>напиши отчёт</задача>
<данные>вот цифры: ...</данные>
<формат>3 раздела, деловой стиль</формат>


9. Проси показать рассуждение

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

10. Сохраняй удачные промпты как шаблоны

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

4.3 Мета-практика

Лучший способ улучшить промпт — попросить саму модель его улучшить. «Вот мой запрос. Что в нём размыто и как его переформулировать точнее?» Работает неожиданно хорошо.

Часть 5. Синтез: архитектура Chunk Advisor v3

5.1 Архитектурные принципы v3

Принцип 1. Чанк читается перед применением

Как скилл Claude, чанк v3 не "вшит" в модель, а подгружается в момент использования. Это позволяет обновлять базу знаний независимо от модели.

Принцип 2. Диагностическая цепочка обязательна

Каждый чанк должен содержать полную цепочку: симптом → диагностика → заключение → объяснение → рекомендация. Без этого ИИ не может распознать ситуацию.

Принцип 3. Антипример важнее примера

Показать, как НЕ надо, часто эффективнее, чем объяснять, как надо. Constraints работают лучше пожеланий.

Принцип 4. Один чанк — одна проблема

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

Принцип 5. Структура = форма ответа

Модель зеркалит формат запроса. Если хочешь получить структурированный ответ — давай структурированный запрос.

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

v1
- Прототип: —
- Структура: линейная
- Фокус: сборка
- Для ИИ: что делать
- Для человека: справочник
- Обновление: требует переобучения

v2
- Прототип: графовая модель
- Структура: графовая
- Фокус: разделение
- Для ИИ: как разделить
- Для человека: инструмент
- Обновление: требует переобучения

v3 (логопедическая)
- Прототип: скиллы Claude
- Структура: диагностическая цепочка
- Фокус: понимание и применение
- Для ИИ: почему и когда
- Для человека: обучение
- Обновление: мгновенное (как скилл)

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

Скиллы Claude — это не просто "инструкции". Это реализация логопедического подхода:

- Диагностика через description
- Коррекция через детальные инструкции
- Закрепление через примеры и антипримеры
- Адаптивность — скиллы обновляются независимо от модели

Chunk Advisor v3 должен работать так же:

1. Чанк читается перед применением — как логопед открывает карточку с упражнением
2. Содержит диагностическую цепочку — чтобы ИИ мог распознать ситуацию
3. Содержит антипримеры — чтобы ИИ знал, чего НЕ делать
4. Имеет чёткую иерархию — чтобы ИИ расставлял приоритеты
5. Обновляется мгновенно — без переобучения модели

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

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

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