620 lines
26 KiB
Markdown
620 lines
26 KiB
Markdown
Да, давай сделаем следующий прогон уже **не “на каноничных вопросиках”**, а на более злой, предметной и местами провокационной выборке — ближе к тому, как человек реально разговаривает с бухгалтерским ассистентом. И да, архитектуру отчёта тоже сразу зафиксируем, чтобы на выходе был **один читаемый MD-файл**, который одновременно:
|
||
|
||
* удобно читать человеку,
|
||
* удобно парсить машине,
|
||
* удобно сравнивать между прогонами.
|
||
Опираюсь на выжимку из разговора с главбухом: ядро ценности — не ввод первички, а контроль, сверка, поиск расхождений, анализ счетов, предзакрытие периода и вопросно-ответный интерфейс поверх нормализованной модели 1С.
|
||
|
||
---
|
||
|
||
# Что предлагаю сделать
|
||
|
||
Новый прогон собрать как **Benchmark v2 / Creative Stress Run**, где вопросы будут:
|
||
|
||
* более длинные;
|
||
* более “человеческие”;
|
||
* с доменной неоднозначностью;
|
||
* с причинно-следственными цепочками;
|
||
* с несколькими сущностями сразу;
|
||
* с формулировками не “из теста”, а ближе к живому главбуху.
|
||
|
||
И на выходе генерировать **один отчёт `.md`** следующего типа:
|
||
|
||
---
|
||
|
||
# Архитектура итогового отчёта
|
||
|
||
## Имя файла
|
||
|
||
`benchmark_creative_stress_run_accounting_assistant_YYYY-MM-DD.md`
|
||
|
||
---
|
||
|
||
## Структура файла
|
||
|
||
### 1. Паспорт прогона
|
||
|
||
Короткий верхний блок:
|
||
|
||
```md
|
||
# Creative Stress Benchmark Run — Accounting Assistant
|
||
|
||
## Паспорт
|
||
- run_id: creative_stress_run_2026-03-23
|
||
- dataset_version: semantic_v2 + router_fix
|
||
- questions_total: 40
|
||
- benchmark_profile: creative_hard_human_like
|
||
- generated_from: accounting_automation_structured_notes
|
||
- mode: validation / stress / pilot-readiness
|
||
- executor: <pipeline or person>
|
||
- overall_status: pass / pass_with_notes / fail
|
||
```
|
||
|
||
### 2. Executive summary
|
||
|
||
Коротко по-человечески:
|
||
|
||
* что проверяли;
|
||
* что в целом показал прогон;
|
||
* где система сильна;
|
||
* где ещё спотыкается;
|
||
* готовность к следующему этапу.
|
||
|
||
### 3. Сводные метрики
|
||
|
||
Машиночитаемо и читаемо одновременно:
|
||
|
||
```md
|
||
## Сводные метрики
|
||
- route_mismatch_count:
|
||
- degraded_answers_count:
|
||
- batch_route_count:
|
||
- live_mcp_drilldown_count:
|
||
- hybrid_store_plus_live_count:
|
||
- store_canonical_count:
|
||
- store_feature_risk_count:
|
||
- avg_latency_ms:
|
||
- p95_latency_ms:
|
||
- pass_rate:
|
||
- strongest_zone:
|
||
- weakest_zone:
|
||
```
|
||
|
||
### 4. Сводка по классам вопросов
|
||
|
||
Разбивка:
|
||
|
||
* heavy_analytical
|
||
* cross_entity
|
||
* drilldown_explain
|
||
* period_close_risk
|
||
* document_reconciliation
|
||
* rule_based_account_control
|
||
* anomaly_probe
|
||
* ambiguous_human_query
|
||
|
||
### 5. Детальный блок Q/A
|
||
|
||
И вот это главный кусок. Для каждого вопроса — отдельный кейс в одном и том же формате.
|
||
|
||
---
|
||
|
||
# Формат одного кейса в отчёте
|
||
|
||
Вот рекомендованный шаблон.
|
||
|
||
```md
|
||
---
|
||
question_id: QH-01
|
||
question_class: cross_entity
|
||
difficulty: hard
|
||
domain_tags: [60, 62, сверка, документы, проводки, period_close]
|
||
expected_route: hybrid_store_plus_live
|
||
actual_route:
|
||
route_match:
|
||
latency_ms:
|
||
decision_flags:
|
||
needs_exact_object_trace:
|
||
needs_causal_chain:
|
||
needs_cross_entity_join:
|
||
needs_full_period_aggregation:
|
||
needs_ranking:
|
||
needs_anomaly_summary:
|
||
needs_runtime_truth:
|
||
freshness_sensitive:
|
||
ambiguous_object_scope:
|
||
store_sufficiency_confident:
|
||
precomputed_aggregate_available:
|
||
store_sufficiency:
|
||
canonical_sufficient:
|
||
feature_sufficient:
|
||
risk_sufficient:
|
||
freshness_ok:
|
||
aggregate_level_ok:
|
||
ranking_ready:
|
||
explanation_ready:
|
||
reason_codes: []
|
||
answer_quality:
|
||
status: pass / partial / fail
|
||
confidence: high / medium / low
|
||
degraded: false
|
||
---
|
||
|
||
## QH-01. [Короткое название кейса]
|
||
|
||
**Вопрос:**
|
||
Покажи, по каким покупателям у нас на конец июня висят отгрузки без оплаты, и сразу свяжи это с реализациями, договорами и проводками, чтобы было видно, где именно хвост и чем он подтверждается.
|
||
|
||
**Что хотел проверить этот вопрос:**
|
||
Проверка связки 62 ↔ 90 ↔ документы реализации ↔ оплаты ↔ договоры ↔ проводки, то есть не плоский факт, а причинная цепочка.
|
||
|
||
**Почему вопрос сложный:**
|
||
Требует одновременно:
|
||
- cross-entity join,
|
||
- causal stitching,
|
||
- period-end cut,
|
||
- объяснимую цепочку источников.
|
||
|
||
**Как система должна была это понять:**
|
||
Это не simple factual и не чистый trend.
|
||
Это causal cross-entity scenario → ожидается `hybrid_store_plus_live`.
|
||
|
||
**Куда ожидали маршрут:**
|
||
`hybrid_store_plus_live`
|
||
|
||
**Куда реально пошёл маршрут:**
|
||
`...`
|
||
|
||
**Почему это корректно / некорректно:**
|
||
Короткий человеческий комментарий.
|
||
|
||
**Краткий ход решения системы:**
|
||
1. Определила периодный срез.
|
||
2. Определила сущности: покупатель, реализация, оплата, договор, проводка.
|
||
3. Проверила sufficiency canonical store.
|
||
4. Поняла, что нужен causal join.
|
||
5. Пошла в hybrid.
|
||
|
||
**Что ожидали увидеть в ответе:**
|
||
- список покупателей;
|
||
- сумма хвоста;
|
||
- документы реализации;
|
||
- отсутствие / наличие оплат;
|
||
- связка с договором;
|
||
- подтверждающие проводки;
|
||
- указание проблемного периода.
|
||
|
||
**Что реально получили:**
|
||
Короткий summary ответа.
|
||
|
||
**Вердикт по кейсу:**
|
||
pass / partial / fail
|
||
|
||
**Замечания:**
|
||
Что докрутить, если что.
|
||
```
|
||
|
||
---
|
||
|
||
# Почему такой формат хороший
|
||
|
||
Он одновременно:
|
||
|
||
* удобен для ручного чтения;
|
||
* достаточно структурирован для diff между прогонами;
|
||
* хранит route-логику рядом с человеческим комментарием;
|
||
* позволяет потом быстро делать выжимку по классам ошибок;
|
||
* пригоден как для внутреннего техотчёта, так и для демонстрации зрелости системы.
|
||
|
||
---
|
||
|
||
# Новый набор вопросов для Creative Stress Run
|
||
|
||
Ниже даю **40 вопросов**, уже заметно более жёстких и ближе к реальному бухгалтерам-режиму. Они построены из тех болей, что были в выжимке: 01/02, 97, 41, 51, 60, 62, 90, 10, сверки, незакрытые хвосты, предзакрытие периода, ошибки дат, отсутствие документов, причинная цепочка.
|
||
|
||
---
|
||
|
||
## Блок A. Предзакрытие периода
|
||
|
||
### QH-01
|
||
|
||
Собери мне предзакрытие июня по-человечески: какие счета сейчас выглядят самыми проблемными, где хвосты, где незакрытые куски и что надо проверить в первую очередь, если период закрывать сегодня.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-02
|
||
|
||
Покажи не просто проблемные счета за июнь, а объясни, почему именно они попали в риск-зону: чем это вызвано, какими документами и какими типовыми ошибками это может быть связано.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-03
|
||
|
||
Сделай рейтинг самых опасных хвостов на конец июня, чтобы было видно, какие из них могут реально аукнуться при сдаче отчётности, а какие просто технический шум.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-04
|
||
|
||
Есть ли у нас на конец июня такие расхождения, которые визуально небольшие, но по природе похожи на системную ошибку, а не на разовый косяк?
|
||
|
||
**Класс:** heavy_analytical / anomaly_probe
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-05
|
||
|
||
Если бы ты был главбухом и у тебя было полчаса перед закрытием периода, какие пять зон ты бы открыл первыми и почему?
|
||
|
||
**Класс:** heavy_analytical + explain
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
---
|
||
|
||
## Блок B. 60 / 62 / сверки / хвосты
|
||
|
||
### QH-06
|
||
|
||
Покажи, по каким поставщикам у нас не бьются взаиморасчёты, и разложи это не только по суммам, а по конкретным документам, оплатам и отсутствующим закрывающим.
|
||
|
||
**Класс:** cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-07
|
||
|
||
По каким покупателям у нас есть отгрузка, но нет оплаты или нормального закрытия, и как это выглядит в цепочке документ → проводка → взаиморасчёт?
|
||
|
||
**Класс:** cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-08
|
||
|
||
Где по 60 и 62 счётам у нас не просто долг висит, а есть ощущение, что отсутствует какой-то первичный документ, из-за чего цепочка развалилась?
|
||
|
||
**Класс:** cross_entity / explain
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-09
|
||
|
||
Покажи мне контрагентов, по которым расхождение выглядит подозрительно: то есть не обычная задержка, а именно такая история, где документы, оплаты и сальдо друг другу не соответствуют.
|
||
|
||
**Класс:** cross_entity / anomaly_probe
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-10
|
||
|
||
Сделай список контрагентов, по которым акт сверки явно напрашивается в первую очередь, и покажи, из каких документов и хвостов это складывается.
|
||
|
||
**Класс:** cross_entity / period_close_risk
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
---
|
||
|
||
## Блок C. 41 / товары / приход / реализация
|
||
|
||
### QH-11
|
||
|
||
Где товар уже ушёл в реализацию, а нормального прихода под него в учёте не видно, и как эта проблема выглядит по датам, документам и поставщикам?
|
||
|
||
**Класс:** cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-12
|
||
|
||
Найди мне такие продажи, где себестоимость или приход выглядят подозрительно, как будто накладная запоздала, документ не дошёл или дата заведена криво.
|
||
|
||
**Класс:** cross_entity / anomaly_probe
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-13
|
||
|
||
Покажи отрицательные или аномальные остатки по товарам не просто списком, а с объяснением, какая цепочка событий к этому привела.
|
||
|
||
**Класс:** drilldown_explain / cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-14
|
||
|
||
Есть ли такие товарные позиции, где проблема тянется не один раз, а повторяется по схожему паттерну: продажа раньше прихода, странный разрыв по датам, неподложенные документы?
|
||
|
||
**Класс:** heavy_analytical / anomaly_probe
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-15
|
||
|
||
Покажи, какие складские или товарные хвосты на конец июня больше всего искажают картину периода.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
---
|
||
|
||
## Блок D. 97 / расходы будущих периодов
|
||
|
||
### QH-16
|
||
|
||
По каким расходам будущих периодов у нас задан срок так, что списание либо идёт криво, либо вообще не должно было так выглядеть?
|
||
|
||
**Класс:** rule_based_account_control
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-17
|
||
|
||
Покажи мне расходы будущих периодов, где ошибка, скорее всего, сидит в дате начала, окончания или вообще в неверно указанном годе.
|
||
|
||
**Класс:** rule_based_account_control / anomaly_probe
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-18
|
||
|
||
Есть ли такие записи на 97 счёте, которые вроде заведены, но по ним нет нормального ежемесячного списания, и с какими исходными документами это связано?
|
||
|
||
**Класс:** cross_entity / explain
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-19
|
||
|
||
Покажи банковские гарантии, лицензии и похожие истории, которые сидят на 97, но выглядят так, будто срок действия и срок списания друг другу противоречат.
|
||
|
||
**Класс:** rule_based_account_control / cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-20
|
||
|
||
Сделай мне обзор по 97 счёту: что там сейчас выглядит как реальный риск периода, а что просто требует внимания, но не горит.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
---
|
||
|
||
## Блок E. 01 / 02 / ОС / амортизация
|
||
|
||
### QH-21
|
||
|
||
Какие основные средства выглядят заведёнными так, будто амортизационная группа или срок амортизации выбраны сомнительно?
|
||
|
||
**Класс:** rule_based_account_control
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-22
|
||
|
||
Покажи карточки ОС, где параметры похожи на ручную ошибку: группа одна, срок другой, логика начисления не бьётся.
|
||
|
||
**Класс:** rule_based_account_control / anomaly_probe
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-23
|
||
|
||
Есть ли у нас объекты, по которым амортизация должна была идти, но не идёт, и чем это подтверждается в карточке и движениях?
|
||
|
||
**Класс:** cross_entity / explain
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-24
|
||
|
||
Покажи самые подозрительные случаи по ОС, которые потенциально опасны не потому, что сумма большая, а потому что логика учёта объекта выглядит криво.
|
||
|
||
**Класс:** heavy_analytical / explain
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-25
|
||
|
||
Есть ли системный паттерн ошибок в заведении основных средств, а не просто единичные косяки?
|
||
|
||
**Класс:** heavy_analytical / anomaly_probe
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
---
|
||
|
||
## Блок F. 51 / банк / выписки / отражение в учёте
|
||
|
||
### QH-26
|
||
|
||
Покажи движения по банку, где есть ощущение, что выписка, документ и проводка не собрались в нормальную цепочку.
|
||
|
||
**Класс:** cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-27
|
||
|
||
Есть ли у нас банковские движения, которые визуально выглядят нормально, но по логике счёта 51 оставляют некорректный хвост или ломают инвариант счёта?
|
||
|
||
**Класс:** rule_based_account_control / anomaly_probe
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-28
|
||
|
||
Найди операции по банку, где, скорее всего, проблема не в сумме, а в том, что что-то не было проведено или не туда легло.
|
||
|
||
**Класс:** drilldown_explain / cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-29
|
||
|
||
Сделай мне список самых подозрительных банковских кейсов июня с коротким объяснением по каждому: в чём суть риска и что бы ты проверил руками первым.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-30
|
||
|
||
Покажи, где движение по банку есть, а нормального отражения в учёте не видно, либо наоборот — в учёте что-то есть, а банковской логики под этим не хватает.
|
||
|
||
**Класс:** cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
---
|
||
|
||
## Блок G. 90 / 62 / реализация и неоплата
|
||
|
||
### QH-31
|
||
|
||
Какие реализации на конец июня зависли без оплаты и уже выглядят не как нормальная отсрочка, а как потенциально проблемный хвост?
|
||
|
||
**Класс:** heavy_analytical / cross_entity
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-32
|
||
|
||
Покажи связку реализация → оплата → договор → проводки по самым крупным незакрытым отгрузкам.
|
||
|
||
**Класс:** cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-33
|
||
|
||
Где по реализации хвост образовался не из-за отсутствия денег как таковых, а из-за разрыва документов, дат или отражения?
|
||
|
||
**Класс:** cross_entity / explain
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
### QH-34
|
||
|
||
Сделай рейтинг самых неприятных незакрытых реализаций: чтобы было видно и сумму, и возраст хвоста, и признаки, что это именно проблема учёта, а не обычная операционка.
|
||
|
||
**Класс:** heavy_analytical
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-35
|
||
|
||
Покажи мне такие кейсы по 90/62, где всё выглядит почти нормально, но если копнуть глубже, видно, что период закрывается на кривой связке.
|
||
|
||
**Класс:** anomaly_probe / cross_entity
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
---
|
||
|
||
## Блок H. 10 / материалы / списание
|
||
|
||
### QH-36
|
||
|
||
Что сейчас лежит на 10 счёте так, будто это уже давно просится в списание или хотя бы в ручную проверку?
|
||
|
||
**Класс:** rule_based_account_control
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-37
|
||
|
||
Покажи материалы, по которым можно заподозрить нелогичный остаток: они висят, но движения и хозяйственная логика вокруг них выглядят странно.
|
||
|
||
**Класс:** rule_based_account_control / anomaly_probe
|
||
**Ожидаемый route:** `store_feature_risk`
|
||
|
||
### QH-38
|
||
|
||
Свяжи по нескольким подозрительным материалам остаток, документы, движения и возможный сценарий, почему они зависли.
|
||
|
||
**Класс:** cross_entity / explain
|
||
**Ожидаемый route:** `hybrid_store_plus_live`
|
||
|
||
---
|
||
|
||
## Блок I. Специально неоднозначные человеческие вопросы
|
||
|
||
### QH-39
|
||
|
||
Где у нас вообще “пахнет ручной ошибкой”, а не нормальной хозяйственной жизнью? Не по одному счёту, а в целом по июню.
|
||
|
||
**Класс:** heavy_analytical / anomaly_probe / ambiguous_human_query
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
### QH-40
|
||
|
||
Что сейчас в июне выглядит как история, которую бухгалтер потом будет долго и нервно распутывать, если не проверить заранее?
|
||
|
||
**Класс:** heavy_analytical / period_close_risk / ambiguous_human_query
|
||
**Ожидаемый route:** `batch_refresh_then_store`
|
||
|
||
---
|
||
|
||
# Как я предлагаю оформить ответы в прогоне
|
||
|
||
Не просто “вопрос — route — pass/fail”, а именно **гибридный стиль**:
|
||
|
||
## Для человека
|
||
|
||
* нормальный текст вопроса;
|
||
* короткое объяснение, что этот вопрос вообще проверяет;
|
||
* почему он сложный;
|
||
* короткий человеческий вердикт по кейсу.
|
||
|
||
## Для машины
|
||
|
||
* `question_id`
|
||
* `question_class`
|
||
* `expected_route`
|
||
* `actual_route`
|
||
* `route_match`
|
||
* `decision_flags`
|
||
* `store_sufficiency`
|
||
* `latency_ms`
|
||
* `answer_quality.status`
|
||
* `degraded`
|
||
* `reason_codes`
|
||
|
||
Это как раз даст вам отчёт, который можно:
|
||
|
||
* читать глазами,
|
||
* diff’ать между версиями,
|
||
* позже использовать как validation corpus.
|
||
|
||
---
|
||
|
||
# Очень важная рекомендация
|
||
|
||
Я бы в этот новый прогон добавил **ещё одно поле**, которого раньше, скорее всего, не хватало:
|
||
|
||
```md
|
||
**Проверяемая бухгалтерская гипотеза:**
|
||
Какую именно предметную гипотезу должен был подтвердить или опровергнуть ассистент.
|
||
```
|
||
|
||
Пример:
|
||
|
||
* “по 97 счёту ошибка сидит в дате начала/окончания”;
|
||
* “по 41 счёту продажа опередила приход”;
|
||
* “по 60/62 счёту хвост образован отсутствием документа, а не просто неоплатой”.
|
||
|
||
Это сильно улучшит читаемость именно для предметников.
|
||
|
||
---
|
||
|
||
# Мой практический совет по следующему прогону
|
||
|
||
Сделайте следующий прогон не на всех 40 сразу, а в два прохода:
|
||
|
||
**Проход 1 — 15 вопросов**
|
||
|
||
* QH-01, 03, 06, 07, 11, 16, 18, 21, 23, 26, 29, 31, 33, 39, 40
|
||
|
||
Это даст:
|
||
|
||
* heavy,
|
||
* cross-entity,
|
||
* anomaly,
|
||
* rule-based,
|
||
* ambiguous human questions.
|
||
|
||
**Проход 2 — все 40**
|
||
После того как увидите, где он ещё хромает на творческих и длинных формулировках.
|
||
|
||
---
|
||
|
||
# Короткий вывод
|
||
|
||
Да, следующий benchmark надо делать уже не “академическим”, а **человекообразным и предметно-злым**.
|
||
И лучший формат отчёта для этого — **один MD-файл с карточками кейсов**, где рядом живут:
|
||
|
||
* вопрос,
|
||
* предметный смысл,
|
||
* ожидаемый маршрут,
|
||
* фактический маршрут,
|
||
* краткий ход рассуждения системы,
|
||
* и итоговый вердикт по качеству ответа.
|
||
Вся эта логика напрямую вытекает из разговора с главбухом: ваша ценность — это контрольный и аналитический слой по реальным бухгалтерским болям, а не игрушечные вопросы “найди документ номер N”.
|
||
|
||
Если хочешь, следующим сообщением я сразу превращу это в **готовую болванку отчёта в markdown**, уже целиком, чтобы вы просто вставили туда результаты прогона.
|