Article Structure Review

# Структурный review статьи

## Когда применять

Между завершением черновика и финальным текстовым аудитом. Порядок:

1. `jtbd-content` - ПЕРЕД написанием (job statement, target state)
2. `draft-narrative-purity` - во время (код/деревья в technical-examples)
3. **`article-structure-review`** - ПОСЛЕ первого черновика ← этот skill
4. `infostyle-audit` - после структуры (усилители, zero-info)
5. `humanize-russian` / `humanize-english` - финал (LLM-маркеры)
6. `{platform}-guide` - подгонка под платформу

## 1. Thesis/Proof Balance (главная проверка)

**Правило:** каждый значимый тезис должен сопровождаться одним из:
- Конкретный пример из личного опыта
- Цифра с контекстом (число, процент, длительность, стоимость)
- Case study: ситуация → что пробовали → результат
- Код-сниппет (один, короткий, в тему)
- Ссылка на источник с указанием *в чём именно* согласны

**Антипаттерн:** 3+ тезиса подряд без ни одного proof-элемента.

### Механический тест

Взять каждую H2-секцию. Пройтись по абзацам. Для каждого:
- Сколько тезисов (утверждений про свойство/преимущество/правило)?
- Сколько proof-элементов (из списка выше)?

Если отношение тезис/proof выше 2:1 в секции - пересобрать.

### Примеры правки

| Плохо (тезис без доказательства) | Хорошо (тезис + доказательство) |
|---|---|
| "Правила помогают избежать катастроф" | "Правило 'не менять localhost-адреса без контекста' появилось после того, как агент заменил SNI-proxy на реальный IP и сломал upload" |
| "Векторный поиск хуже графа" | "Эмбеддинги для карточек по 500-2000 токенов - lossy-сжатие: похожие на вектор карточки могут быть про разные домены, а operationally-adjacent карточки (Kafka + Python profiling) семантически далеки" |
| "Структура помогает" | "После ввода handoff между сессиями за 4 дня накопилось 27 переходов - ни один тупик не повторился" |

## 2. Жанровая чистота

Статья обслуживает **один основной жанр**. Выбирается ДО написания:

| Жанр | Характер | Пример заголовка |
|---|---|---|
| **Story** | Хронология, от лица автора, с неудачами | "Как я сломала прод и что нашла" |
| **Reference** | Факты, таблицы, паттерны | "Checklist: развёртывание K8s cluster" |
| **Analysis** | Данные → вывод, сравнения | "3 метода context compaction: бенчмарк" |
| **Rant/Opinion** | Точка зрения, аргументы | "Почему RAG - это regression" |
| **Tutorial** | Пошаговая инструкция | "Fine-tune модели за 4 часа" |

**Смешение жанров допустимо**, если явно обозначить:
> "Часть 1 - история как я столкнулась с проблемой. Часть 2 - разбор архитектуры."

Не обозначить = читатель теряется: "зачем это здесь? где закончилась одна тема и началась другая?"

### Симптомы жанрового сбоя

- Читатель (или feedback-читатель) спрашивает "зачем этот блок?"
- Середина статьи визуально тяжёлая (перегруз другого жанра)
- Заголовок обещает одно, тело даёт другое
- Нет сквозной линии "зачем я это читаю"

### Тест

Прочитать ТОЛЬКО первые абзацы каждой H2-секции. Читаются как одна последовательная мысль или как разрозненные блоки? Если блоки - определить где жанр сменился, обозначить явно или переписать в один жанр.

## 3. Блок ограничений (ОБЯЗАТЕЛЬНЫЙ)

Секция "Что НЕ решено / Чего не знаю / Где сломается" - **обязательна** в конце любой технической статьи про собственный инструмент / подход / систему.

### Что туда писать

- Границы масштабирования: "при 10K+ записей это сломается, потому что..."
- Непроверенные гипотезы: "Не уверена что принцип X работает вне моего use case"
- Tradeoffs: "Это стоит N - если у вас меньше бюджет, смотрите на ..."
- Известные дыры: "Семантическое протухание не ловится автоматически"
- Пределы личного опыта: "Не тестировала на production scale"

### Что туда НЕ писать

- Ложная скромность ("я не профи, но...") - не информативно
- Внешние проблемы не под твоим контролем ("LLM иногда тупят")
- Преодолимые ограничения без оценки сложности

### Почему обязательна

- Читатель доверяет больше, когда видит границы явно
- Антидот к "рекламному тону" - ограничения показывают, что автор думал, а не хайпил
- Коммуникация уровня зрелости: "готов к критике по этим пунктам"
- Удерживает от publishing "половины решения" как "готовой системы"

## 4. Paragraph Variety

**Правило:** длины абзацев должны скакать. 1-sentence абзац ок, 5-sentence ок, но не три 3-sentence подряд.

### Антипаттерн ИИ

Три абзаца одинаковой длины ~3 предложения каждый, каждый начинается с глагола или "Moreover/Также/Кроме того", каждый содержит ровно один тезис + пол-доказательства. Характерный ритм "тыры-пыры" - LLM-generated.

### Тест

Взять статью, посчитать длины абзацев в основной части. Стандартное отклонение должно быть > среднего. Если "все абзацы по 3-4 предложения" - ручная пересборка: часть объединить, часть разбить, одно предложение вынести в отдельный абзац для акцента.

## 5. Middle-Section Overload

**Симптом:** в середине статьи один блок перегружен тезисами/концепциями - сложнее читать, чем начало и конец.

**Причина:** автор вырос в понимании темы за время написания, в середину положил самые интересные/глубокие мысли, а уровень контекста читателя не вырос.

### Тест

Посчитать количество тезисов по секциям. Если середина содержит > 40% всех тезисов при 33% веса - разгружать:
- Вынести часть в `technical-examples.md` или в отдельную статью
- Добавить visual aid (схема, таблица, график)
- Разбить одну большую секцию на две

## 6. Visual vs Prose Check

**Правило:** если объясняешь **структуру данных, архитектуру, связи** - покажи визуал, не проза.

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

Визуалом лучше:
- Связи между сущностями (граф, диаграмма)
- Распределение по категориям (таблица, pie chart)
- Иерархия (tree)
- Временная последовательность (timeline, swim-lane)
- Сравнение (side-by-side таблица)
- Архитектура (block diagram)

### Тест

Каждую секцию которая описывает **структуру** - спросить "можно ли это одной картинкой показать яснее, чем абзацами?". Если да - заменить.

## Чеклист перед сдачей в infostyle/humanize

- [