Да, тут уже напрашивается не просто “ещё одно поле в автопрогонах”, а **нормальная управляющая схема**. То есть у вас должно быть не только “модель ответила / оценка 5-балльная”, а три опоры: 1. **эталон идеального поведения ассистента**; 2. **ручная разметка результата прогона с управленческим смыслом**; 3. **канонический файл возможностей ассистента по отработанным маршрутам 1С**. И тогда автопрогоны перестают быть просто логами, а становятся контуром развития системы. Ниже я собрал это так, чтобы можно было почти целиком отдать в Codex. --- # Как я бы это сформулировал концептуально ## 1. Нужен отдельный блок: «Эталон поведения ассистента» Это не просто описание “каким хотелось бы видеть ответ”. Это должен быть **формальный канон**, который понимают: * сам ассистент; * система автопрогонов; * пост-анализ; * Codex, который потом дорабатывает маршруты и поведение. То есть это не prose-блок “идеальная работа”, а именно **Assistant Canon / Behavior Canon**. ### Что в нём должно быть #### А. Что такое хороший ответ Хороший ответ ассистента: * отвечает по существу, если кейс реально покрыт; * не врёт, если кейс не покрыт; * не выдаёт технические внутренности вместо нормальной коммуникации; * не ломается на смежных вопросах; * умеет мягко ограничить себя; * умеет предложить близкий поддерживаемый сценарий; * умеет подсказать, где это обычно смотреть в 1С; * не вываливает полный список возможностей без запроса; * раскрывает возможности по группам и по мере уточнения. #### Б. Что такое плохой ответ Плохой ответ ассистента: * выдумывает функцию, которой нет; * делает вид, что может точно ответить, когда не может; * отвечает внутренним техническим языком; * сухо отказывает без пользы; * валит пользователя в огромный список умений; * не понимает, когда вопрос надо передать в “не покрыто, но рядом”; * не различает безопасный общий ответ и рискованный прикладной совет. #### В. Какой идеал поведения на границе покрытия Вот это вообще ключевой блок. Ассистент должен: * честно понимать границу своих возможностей; * не маскировать отсутствие маршрута; * не ломаться; * не отвечать “не поддерживается” в лоб; * не уходить в системные сообщения; * давать человекочитаемое ограничение; * предлагать ближайший полезный путь. Это и есть ваш **эталон**. --- ## 2. Нужна ручная разметка не только по качеству, но и по судьбе вопроса Вот это очень сильная мысль. Пятибалльная оценка сама по себе почти бесполезна, потому что она **не говорит, что делать дальше**. Нужна ещё одна сущность: ## **Decision Markup / Route Decision Markup** То есть по каждому прогону вы размечаете не только “норм / не норм”, а **каково управленческое решение по классу вопроса**. ### Я бы добавил в UI не просто кнопку, а выпадающий классификатор Например: * `covered_ok` — кейс нормальный, покрывается, поведение ок; * `covered_but_bad_answer` — кейс должен покрываться, но ответ плохой; * `good_question_to_implement` — хороший вопрос, его надо брать в отработку; * `out_of_scope_but_answer_softly` — вопрос не планируется покрывать, но нужно мягко и полезно отвечать; * `unsafe_question_limit_strictly` — вопрос рискованный, на него нужно отвечать осторожно и ограниченно; * `bad_test_case` — сам тестовый вопрос мусорный / нерелевантный; * `needs_routing_extension` — нужен новый маршрут или расширение маршрутизации; * `needs_capability_registry_update` — кейс выявил дыру в файле возможностей; * `needs_dialog_policy_fix` — маршрут, возможно, не нужен, но политика ответа плохая. Вот это уже даст системе смысл. ### Если хочется совсем по-простому Можно ввести более короткий список: * **Отрабатывается** * **Должно отрабатываться** * **Не будет отрабатываться** * **Отвечать мягким ограничением** * **Высокорисковый вопрос** * **Плохой тест-кейс** Но я бы всё-таки оставил более инженерный набор, а в UI уже сделал человекочитаемые названия. --- ## 3. Нужен канонический файл возможностей ассистента Да, это обязательно. И это должен быть не просто текстовый файл “что умеем”. Это должен быть **Capabilities Registry / Supported Routes Registry**. И он должен быть источником истины для трёх вещей: * ответа ассистента; * классификации покрываемости; * автопрогонов и анализа. ### Что там должно быть Для каждого маршрута / домена: * код маршрута; * человекочитаемая группа; * краткое описание; * что реально умеется; * что не умеется; * обязательные параметры; * типовые формулировки вопросов; * похожие смежные сценарии; * безопасные альтернативы; * подсказка, где это обычно смотреть в 1С; * уровень риска; * статус зрелости: * production-ready * partial * planned * deprecated ### Пример групп Не надо сразу показывать всё пользователю. Надо хранить глубоко, а наружу отдавать по группам. Например: * НДС * Контрагенты * Задолженности * Деньги и остатки * Платежи и движения * Аналитика по периодам * Справочные бухгалтерские вопросы А дальше уже внутри группы: * что умеется конкретно. То есть если юзер спрашивает “что ты можешь по НДС?”, ассистент отвечает не списком из 80 пунктов, а компактной группой возможностей по НДС. --- ## 4. Надо отдельно зафиксировать правило раскрытия возможностей Это тоже очень важный продуктовый момент. ### Ассистент не должен * автоматически вываливать весь список поддерживаемого; * отвечать каталогом без запроса; * перегружать пользователя техническими деталями маршрутов. ### Ассистент должен * раскрывать возможности **по группам**; * сначала давать верхнеуровневую сегментацию; * при уточнении — углубляться; * говорить в продуктовой, а не внутренне-технической логике. То есть: “Могу помочь с НДС, остатками и движением денег, контрагентами и задолженностями, а также с частью аналитики по периодам. Если хочешь, могу уточнить отдельно по любому из этих блоков.” А уже потом: “По НДС могу показать суммы, динамику по периодам, сверку по организации, сравнительные разрезы...” --- ## 5. Нужен отдельный тип разметки: «вопрос хороший, но ещё не покрыт» Это, по сути, мост между автопрогоном и roadmap. То есть если в прогоне всплыл вопрос: * он адекватный; * он реально нужен; * пользователь его точно задаст; * сейчас он не покрыт, то это не просто “ответ плохой”. Это **кандидат на новый маршрут / на расширение текущего покрытия**. Поэтому в ручной разметке должен быть отдельный флаг: * `candidate_for_implementation` или * `planned_route_gap` Именно его потом должен видеть Codex и дальше использовать как список задач на развитие. --- ## 6. Надо разделить две разные проблемы Сейчас у тебя в одном описании смешаны две вещи, а их лучше развести. ### Проблема 1. Функциональное покрытие Что система реально умеет по данным и маршрутам. ### Проблема 2. Поведенческая зрелость Как система ведёт себя, когда вопрос: * вне покрытия; * частично в покрытии; * опасный; * слишком общий; * смежный; * абстрактный. То есть даже если маршрут не реализован, поведение всё равно может быть: * хорошим; * плохим; * опасным; * слишком техническим; * бесполезным. И автопрогоны должны это различать. --- # Ниже — готовая мини-ТЗшка для Codex ## Мини-ТЗ: эталон поведения ассистента, ручная разметка прогонов и канонический файл возможностей ### Цель Доработать систему автопрогонов бухгалтерского ассистента так, чтобы она оценивала не только качество конкретного ответа, но и соответствие эталонному поведению ассистента, а также позволяла вручную размечать судьбу вопроса: покрывается, должен быть отработан, не будет отрабатываться, должен обрабатываться мягким ограничением, требует нового маршрута или требует доработки политики ответа. --- ## 1. Ввести отдельную сущность: Assistant Behavior Canon Нужен канонический блок, описывающий эталонную работу ассистента. ### Требования Создать отдельную структуру/файл, который будет использоваться: * в логике ответа ассистента; * в пост-анализе автопрогонов; * в интерфейсе разметки прогонов; * в дальнейшей работе Codex по развитию маршрутов и поведения. ### В Assistant Behavior Canon зафиксировать: #### 1.1. Поведение на покрытых кейсах * отвечать уверенно и по существу; * не уходить в лишние оговорки; * не использовать технические внутренние формулировки. #### 1.2. Поведение на частично покрытых кейсах * явно разделять, что ассистент может сделать, а что нет; * не маскировать ограничения; * предлагать полезное продолжение. #### 1.3. Поведение на непокрытых, но близких кейсах * не выдумывать поддержку функциональности; * мягко и по-человечески объяснять ограничение; * предлагать ближайший поддерживаемый сценарий; * при уместности подсказывать, где это обычно посмотреть в 1С. #### 1.4. Поведение на высокорисковых вопросах * не выдавать неподтверждённые рекомендации как надёжный ответ; * не делать вид, что прикладная логика существует, если её нет; * сохранять полезность без ложной уверенности. #### 1.5. Поведение при вопросе “что ты умеешь” * не вываливать весь список возможностей сразу; * раскрывать возможности по крупным группам; * углубляться только после уточнения; * использовать человекочитаемые продуктовые группы, а не внутренние названия маршрутов. --- ## 2. Ввести канонический файл возможностей ассистента Нужен отдельный реестр отработанных возможностей ассистента по маршрутам 1С. ### Назначение Этот файл является источником истины для: * определения покрытия вопроса; * ответа ассистента на вопросы о своих возможностях; * similarity-логики; * автопрогонов и пост-анализа; * Codex при дальнейшем развитии маршрутов. ### Для каждого маршрута / домена хранить: * `route_code` * `group_code` * `group_title` * `title` * `description` * `supported_operations` * `unsupported_operations` * `required_entities` * `optional_entities` * `typical_queries` * `related_routes` * `safe_alternatives` * `one_c_hints` * `risk_level` * `maturity_status` (`production_ready`, `partial`, `planned`, `deprecated`) ### Требования к пользовательскому раскрытию возможностей Ассистент должен уметь: * сначала показывать верхнеуровневые группы; * по запросу раскрывать детали внутри выбранной группы; * не использовать длинные технические перечни без необходимости. --- ## 3. Доработать интерфейс автопрогонов: ручная управленческая разметка Существующую 5-балльную оценку оставить, но дополнить отдельной выпадающей ручной классификацией результата прогона. ### Добавить новое поле: `manual_case_decision` ### Возможные значения: * `covered_ok` * `covered_but_bad_answer` * `candidate_for_implementation` * `needs_routing_extension` * `out_of_scope_but_answer_softly` * `unsafe_question_limit_strictly` * `needs_dialog_policy_fix` * `needs_capability_registry_update` * `bad_test_case` ### Смысл значений * `covered_ok` — кейс уже покрыт, поведение нормальное; * `covered_but_bad_answer` — кейс покрывается, но ответ/диалог плохой; * `candidate_for_implementation` — хороший пользовательский кейс, которого пока нет, его стоит брать в разработку; * `needs_routing_extension` — нужен новый маршрут или расширение существующего; * `out_of_scope_but_answer_softly` — кейс не планируется покрывать, но нужен качественный мягкий ответ без техничности; * `unsafe_question_limit_strictly` — кейс относится к рискованным, и ассистент должен ограничивать себя особенно строго; * `needs_dialog_policy_fix` — проблема не в маршруте, а в стиле/логике ответа; * `needs_capability_registry_update` — реестр возможностей неактуален или недостаточно формализован; * `bad_test_case` — вопрос мусорный, нерелевантный или бесполезный для развития системы. ### Дополнительно Для каждой ручной метки предусмотреть: * короткий комментарий; * автора разметки; * timestamp; * возможность использовать эту разметку в пост-анализе и отборе задач для Codex. --- ## 4. Доработать логику пост-анализа прогонов После прогона система должна уметь отделять: * ошибки покрытия; * ошибки маршрутизации; * ошибки политики ответа; * хорошие, но ещё не покрытые кейсы; * мусорные тест-кейсы; * высокорисковые кейсы; * кейсы на обновление файла возможностей. ### На выходе пост-анализа нужны агрегаты: * список кейсов на доработку маршрутов; * список кейсов на доработку policy; * список кейсов на обновление capabilities registry; * список кейсов, которые сознательно не будут покрываться, но требуют мягкого ограничения; * список кейсов, пригодных для новых regression suites. --- ## 5. Встроить связь между ручной разметкой и дальнейшей работой Codex Codex должен видеть не только сам диалог и оценку, но и управленческое решение по нему. ### Требование При выгрузке данных для дальнейшего анализа и доработок обязательно передавать: * question / dialog trace; * current route / current coverage decision; * 5-балльную оценку; * `manual_case_decision`; * комментарий аналитика; * ссылку на ближайший домен из capabilities registry; * признак: нужно ли брать кейс в маршрутную отработку. ### Ожидаемое поведение Если кейс помечен как: * `candidate_for_implementation` или `needs_routing_extension` — Codex рассматривает его как материал для новой/расширенной маршрутной логики; * `out_of_scope_but_answer_softly` — Codex улучшает не маршруты, а policy-слой ответа; * `needs_capability_registry_update` — Codex актуализирует реестр возможностей; * `unsafe_question_limit_strictly` — Codex усиливает безопасное поведение и ограничения; * `covered_but_bad_answer` — Codex чинит существующий покрываемый сценарий, а не создаёт новый. --- ## 6. Добавить в эталон обязательное правило минимизации технических ответов Это отдельное критичное требование. ### Ассистент не должен * отвечать внутренними техническими терминами; * ссылаться на отсутствие маршрута, домена, интента, пайплайна, классификатора; * создавать ощущение поломки системы. ### Ассистент должен * говорить естественно; * объяснять ограничения человеческим языком; * сохранять полезность даже при отказе; * ориентировать пользователя в доступных соседних возможностях. --- ## 7. Добавить в эталон обязательное правило сегментированного раскрытия возможностей Если пользователь спрашивает: * “что ты умеешь?” * “что можешь по НДС?” * “что можешь по остаткам?” * “что умеешь по деньгам / поставщикам / задолженностям?” ассистент должен отвечать через иерархию: ### Уровень 1 Крупные продуктовые группы: * НДС * Контрагенты * Задолженности * Деньги и остатки * Движение и платежи * Аналитика по периодам * Справочные бухгалтерские вопросы ### Уровень 2 Уточнение по выбранной группе: * что внутри группы реально доступно; * какие ограничения есть; * что можно сделать следующим шагом. ### Уровень 3 Точечный ответ по конкретному запросу. --- ## 8. Критерии приёмки 1. В системе появился отдельный канонический блок эталонного поведения ассистента. 2. Появился отдельный файл/реестр возможностей по маршрутам 1С. 3. В UI автопрогонов добавлена ручная управленческая разметка результата. 4. Ручная разметка сохраняется в логах и участвует в пост-анализе. 5. Система умеет отделять “не покрыто, но стоит реализовать” от “не покрыто и не планируется, но нужно мягко отвечать”. 6. Ассистент перестаёт отвечать внутренним техническим языком на границе покрытия. 7. Ассистент умеет раскрывать свои возможности по группам, а не полным списком. 8. Codex получает достаточно данных, чтобы понимать, что чинить: маршрут, policy, capabilities registry или сам тест-кейс. --- # Что я бы ещё добавил от себя Я бы прямо выделил в ТЗ отдельный артефакт: ## `assistant_canon.md` В нём: * идеал поведения; * анти-паттерны; * примеры хороших ответов; * примеры плохих ответов; * правила раскрытия возможностей; * правила мягкого ограничения; * правила поведения на рискованных вопросах. И отдельно: ## `capabilities_registry.json` или `capabilities_registry.yaml` И ещё: ## `manual_case_decision_schema.json` Чтобы UI и пост-анализ работали по одному словарю значений. --- # Если совсем коротко, в чём суть Тебе сейчас нужен не просто “ещё один контрол в модалке”, а вот такая конструкция: **Эталон ассистента** → задаёт идеальное поведение **Файл возможностей** → задаёт фактическое покрытие **Ручная разметка кейса** → задаёт управленческое решение, что с этим вопросом делать дальше **Codex** → уже понимает, нужно ли: * чинить ответ, * расширять маршрут, * обновлять capabilities, * улучшать мягкий отказ, * или вообще выкинуть тест-кейс. Если хочешь, я следующим сообщением могу собрать это ещё в более прикладной форме: **короткое ТЗ на 30–40 строк для прямой отправки в Codex**, без пояснений и лирики.