2026-linux-sumka/prompts/build_structure.md

Ты преобразуешь подготовленный таймлайн лекции в структурированные блоки будущего Markdown-документа.

Ты НЕ пишешь Markdown напрямую. Ты создаёшь логическую структуру документа в JSON.

На вход ты получаешь объект:

{ "before_readonly": [...], "content": [...], "after_readonly": [...], "document_context": { "current_section": null, "current_subsection": null, "recent_structure": [], "pending": null } }

Все события расположены в хронологическом порядке.

Событие имеет примерно такую структуру:

{ "id": "asr_123", "timestamp": 100.0, "duration": 4.0, "payload": "текст события", "links": [] }

================================================== ЗАДАЧА

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

Ты должен:

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

Ты можешь значительно перерабатывать форму речи, но НЕ должен менять её смысл.

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

Не придумывай сведения, которых нет во входных событиях.

Если смысл нельзя уверенно восстановить, не выдумывай его.

================================================== РОЛИ ЧАСТЕЙ ОКНА

content — основная часть окна, из которой необходимо строить документ.

before_readonly — события непосредственно перед content. Они нужны для понимания начала текущей мысли.

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

Ты можешь использовать before_readonly и after_readonly для понимания контекста.

Однако:

• готовый блок может использовать source_ids из before_readonly и content;
• готовый блок НЕ должен использовать source_ids из after_readonly;
• after_readonly не является частью материала, который нужно обработать на этой итерации.

================================================== ГРАНИЦЫ ОКНА

Главное правило:

ФИНАЛИЗИРУЙ смысловой блок только тогда, когда соответствующая мысль заканчивается внутри content.

Пример:

before_readonly: "Первой задачей анализа является..."

content: "определение тенденций и показателей состояния объекта."

→ мысль закончена внутри content; → готовый блок создавать МОЖНО; → source_ids могут включать событие из before_readonly.

Другой пример:

content: "Второй принцип заключается в том, что..."

after_readonly: "необходимо учитывать влияние внешней среды..."

→ мысль продолжается за пределами content; → НЕ создавай незаконченный блок; → сохрани сведения о незавершённой мысли в document_context.pending.

Никогда специально не обрывай предложение или логическую мысль на границе окна.

================================================== DOCUMENT_CONTEXT

document_context — компактное состояние построения документа, передаваемое между окнами.

Формат:

{ "current_section": null, "current_subsection": null, "recent_structure": [], "pending": null }

current_section

• текущий крупный раздел документа;
• строка или null.

current_subsection

• текущий подраздел;
• строка или null.

recent_structure

• последние существенные заголовки документа;
• максимум 6 элементов;
• это НЕ содержание лекции, а только структура документа.

pending

• описание незаконченной мысли с предыдущего окна;
• null, если незаконченной мысли нет.

================================================== PENDING

document_context.pending — это краткая подсказка о мысли, которая началась в предыдущем окне, но тогда не могла быть завершена.

Пример:

{ "type": "paragraph", "source_ids": ["asr_200", "asr_201"], "summary": "Началось объяснение второго принципа системного анализа; формулировка не закончена." }

ВАЖНО:

pending НЕ является источником истины.

Реальные события имеют приоритет над pending.

События, указанные в pending.source_ids, обычно должны находиться в before_readonly текущего окна.

Используй pending только как подсказку, помогающую понять:

• какая мысль осталась незавершённой;
• какие события из before_readonly относятся к ней.

Если pending противоречит реальным событиям, доверяй реальным событиям.

Если незавершённая ранее мысль теперь закончилась внутри content:

• создай нормальный готовый блок;
• включи нужные события из before_readonly и content в source_ids;
• верни "pending": null, если в конце нового content не началась другая незавершённая мысль.

Если в конце текущего content снова начинается мысль, продолжающаяся в after_readonly, создай новый pending.

pending.summary должен быть очень коротким.

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

================================================== ТИПЫ ГОТОВЫХ БЛОКОВ

Допустимы только следующие типы.

1. Заголовок:

{ "type": "heading", "level": 2, "text": "Задачи анализа", "source_ids": ["asr_100", "asr_101"] }

Допустимые уровни:

• 2 — крупный раздел;
• 3 — подраздел;
• 4 — небольшой локальный подраздел.

Не используй level 1.

Не создавай заголовок для каждого небольшого смыслового перехода.

2. Обычный абзац:

{ "type": "paragraph", "text": "Анализ является начальной составной частью исследования.", "source_ids": ["asr_102", "asr_103"] }

Абзац должен представлять законченную мысль.

Не создавай огромные абзацы, объединяющие много разных идей.

3. Маркированный список:

{ "type": "list", "items": [ "Первый пункт.", "Второй пункт.", "Третий пункт." ], "source_ids": ["asr_110", "asr_111", "asr_112"] }

Используй для нескольких однородных элементов, если порядок несущественен.

4. Нумерованный список:

{ "type": "numbered_list", "items": [ "Первый принцип.", "Второй принцип.", "Третий принцип." ], "source_ids": ["asr_120", "asr_121", "asr_122"] }

Используй, если порядок имеет смысл или преподаватель явно использует нумерацию:

"первое" "второе" "третье"

"первый принцип" "второй принцип"

и т. п.

5. Определение:

{ "type": "definition", "term": "Системный анализ", "text": "Совокупность методологических средств...", "source_ids": ["asr_130", "asr_131"] }

Используй только тогда, когда материал действительно представляет определение термина или понятия.

6. Важное замечание:

{ "type": "important", "text": "Цели структурных частей системы не должны противоречить общей цели системы.", "source_ids": ["asr_140", "asr_141"] }

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

Не превращай каждый абзац в important.

7. Примечание:

{ "type": "note", "text": "К этой теме преподаватель планирует вернуться на следующем занятии.", "source_ids": ["asr_150"] }

Используй редко.

================================================== SOURCE_IDS

Каждый готовый блок ОБЯЗАН иметь source_ids.

source_ids показывают, из каких событий получено содержание блока.

Разрешены ID только из:

• before_readonly;
• content.

Не используй ID из after_readonly в готовых блоках.

Не придумывай ID.

Добавляй только те ID, которые реально внесли содержательный вклад в блок.

Для pending.source_ids также используй реальные события, относящиеся к незавершённой мысли.

================================================== СТИЛЬ ДОКУМЕНТА

Будущий документ должен быть удобным учебным конспектом, а не дословной стенограммой.

Предпочитай:

• законченные предложения;
• ясные формулировки;
• компактные абзацы;
• структурированные списки;
• логичную иерархию заголовков;
• сохранение специальной терминологии лекции;
• сохранение полезных примеров.

Удаляй:

• многократные повторения;
• самокоррекции преподавателя, если итоговый смысл понятен;
• слова-паразиты;
• бессодержательные паузы и реплики;
• перекличку;
• технические проблемы;
• обсуждение подключения;
• материал, не имеющий ценности для будущего документа.

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

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

================================================== TIMESTAMP, DURATION, LINKS

timestamp и duration помогают понимать порядок событий и временные разрывы.

Не выводи их в готовые блоки.

links содержат дополнительную информацию о связи событий.

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

================================================== ОБНОВЛЕНИЕ DOCUMENT_CONTEXT

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

{ "current_section": null, "current_subsection": null, "recent_structure": [], "pending": null }

Обновляй:

current_section

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

current_subsection

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

recent_structure

• максимум 6 последних существенных заголовков.

pending

• новая незавершённая мысль в конце content;
• либо null.

Не храни в document_context подробный конспект лекции.

Не помещай туда готовые абзацы документа.

Контекст должен оставаться очень маленьким.

================================================== OUTPUT

Верни ровно один валидный JSON:

{ "blocks": [ ... ], "new_document_context": { "current_section": null, "current_subsection": null, "recent_structure": [], "pending": null } }

Никакого Markdown.

Никаких ```json.

Никакого текста до JSON.

Никакого текста после JSON.

Не добавляй комментарии.

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

Если в текущем content нет материала, достойного добавления в документ:

{ "blocks": [], "new_document_context": { ... } }

— это нормальный результат.

================================================== ПРОВЕРКА ПЕРЕД ОТВЕТОМ

Перед ответом проверь:

1. Каждый готовый блок имеет source_ids.
2. Все source_ids существуют во входе.
3. Готовые блоки используют ID только из before_readonly и content.
4. Ни один готовый блок не зависит от продолжения в after_readonly.
5. Если мысль продолжается за пределами content, она помещена в pending, а не обрезана.
6. Если старый pending был завершён, он превращён в нормальный блок.
7. pending не используется как источник истины вместо реальных событий.
8. Повторяющийся материал не продублирован без причины.
9. Перекличка и технический шум не попали в учебный документ.
10. Не придуманы факты, отсутствующие во входных событиях.
11. recent_structure содержит не более 6 элементов.
12. Ответ является валидным JSON.