В апреле 2020 я сделал два программных поста:
– мышление письмом/моделированием, Мышление письмом/моделированием: ailev — ЖЖ. Этот пост оказался удивительно популярным, и это “мышление письмом” широко практикуется у нас в мастерской инженеров-менеджеров.
– Мышление кодированием в IDE, мышление письмом в IWE, Мышление кодированием в IDE, мышление письмом в IWE : ailev — ЖЖ. Этот пост оказался менее популярным, вывод был в том, что в 2020 году ещё не было Obsidian как основы для собственного zettelkasten/wiki. Инструментальная часть текстописания с поддержкой zettelkasten обозначилась словом “экзокортекс”, и лениво обсуждается в одноимённом чате Telegram: View @exocortexssm (сейчас там чуть больше пятисот человек, “Группа для обсуждения инструментария усиления мышления для личного и рабочего использования”).
За пять лет изменилось более чем всё:
– у нас появились AI-агенты, которые мыслят за вас кодированием в IDE, моделированием в самых разных моделерах (скажем, в coda.io или даже Excel) и письмом в появляющихся IWE, а ещё появились исследовательские агенты, где главное – search. Этих агентов много!
– и у них всех, поскольку они стали “мыслить в S1” ну ровно как мы с вами, появилась проблема: искажения при редактировании, то есть искажения при agile процессе познания. Выдвижение гипотез, обоснование доказательствами и экспериментом, доработка гипотез, и т.д. А S2 у них нету, оно “внешнее”, в обвязке. Все эти агенты суть одно и тоже: поддержка agile работы со знаниями (моделями, теориями, текстами, алгоритмами, доказательствами и т.д.).
Интересно, что проблемы одни и те же, решаются они примерно одинаково, но поскольку инструменты разные и аудитории разные, то собрать материал об этом очень тяжело. Ну, я собрал некоторое количество материала про деградацию текстов (на естественном языке, на языках программирования и т.д.) в самом разном инструментарии (Cursor тут только один из и хорошо поддерживает отнюдь не все потребные workflow со знаниями). Я с поддержкой группы нежити сделал некоторый обзорчик, за верность которого не ручаюсь ни разу, но зато он дал пищу размышлениям (полный текст на русском – https://chatgpt.com/s/dr_686008d7d68c819191b2e66776f5e122):
Инструменты для коллективного редактирования точных текстовТекст этот я получил следующим образом:Аннотация.
В техническом писательстве LLM-редактор полезен только тогда, когда гарантирует «без-усадочную» правку: ни одна неизменяемая строка не исчезает, каждая модификация снабжена объяснением и проходит верификацию. Мы сопоставляем «чистые» чаты (GPT-4o, Gemini 2, Claude 4) с системами, обёрнутыми инструментальной логикой (FineEdit, InkSync, Aider, Cursor, Continue) на четырёх открытых бенчмарках — InstrEditBench-25, Can-It-Edit-24, Laziness и Compression-ED. Переход к минимальному diff-формату, двухмодельному циклу Propose → Verify → Merge и CI-diff-тестам повышает точность сохранения текста примерно с 75 % до ≥ 95 % и вдвое сокращает время ручного ревью. Статья излагает пятислойную архитектуру защит (от constrained decoding до чек-сумм), показывает, как её реализуют современные IDE и плагины, и предлагает чек-лист по внедрению в корпоративные стандарты и регламенты.ЧАСТЬ I. Недопустимость “усадки текста” и как её можно измерить
– Сценарии, в которых «усадка» текста недопустима
– Типовые сбои «чистой» LLM-редакции, когда модель работает без дифф-обвязки, без проверки вторым агентом и без пост-тестов
– Как измеряют «съём» и точность LLM-правок
– – 1 · Корпус с эталонным min-diff
– – 2 · Lazy / Missing-patch измеряют отдельно
– – 3 · «Сколько править руками» — Compression ED
– – 4 · Полевой UX-замер
– – 5 · Проверка инвариантов через Assertions
– Практический рецепт измерения в своей команде
– Кейсы-сравнения «чистая LLM» vs LLM + обвязка
– Стоимость ошибок, порождаемых «усадкой» и неконтролируемыми правками LLMЧАСТЬ II. Методы решения на уровне архитектурных паттернов
– Аналогия «S1 / S2 мозга ⇔ LLM / обвязка»: то же самое, но полностью наоборот
– Слой 1. Контролируемое порождение
– Слой 2. Mask-and-infill («редактировать по месту»)
– Слой 3. UI- и «физические» блокировки
– Слой 4. Программные гарантии и самопроверка
– Слой 5. Диалоговые протоколы и ревью-циклы
– – 5.1. Minimal-diff как lingua franca
– – 5.2. Двухмодельный цикл Propose → Critique → Merge
– Слой 6. Управление длинными контекстами
– Сводка по слоям защиты от деградации текста
ЧАСТЬ III Инструментальный ландшафт и практические рецепты
– Редакторы «новой волны»
– IDE-экосистема (VS Code / JetBrains)
– Почему нельзя просто поставить Cursor IDE и считать задачу решённой
– Obsidian-стек
– CI/CD и терминал
– Матрица: паттерн → инструмент
– Результаты на практике
– Практический чек-лист внедренияЧАСТЬ IV Что ещё осталось сделать — лакуны на конец 2025 г.
– Куда движется рынок
– Чего не хватает во всех обсуждённых “надёжных” инструментов из тех инструментов, которые есть в браузерном UI “чистой LLM”
– – 1 - Он-лайн-поиск и «глубокое» веб-grounding
– – 2 - Постоянная память и персональный контекст
– – 3 - Мультимодальные входы: изображения, голос, файлы
– – 4 - Расширяемость через плагины и Custom GPT-ы
– – 5 - Шаринг и коллективная работа «по ссылке»
– – 6 - Голосовой ввод и аудиовывод
– – 7 - «One-click» deep research и Canvas-выводы
– – 8 - Лёгкая мультиязычность и автоперевод
– – 9 - Функции «плейграунда» и экспериментов
– – 10 - Интеграция с внешними приложениями (Zapier-стиль)
– Почему так сложилосьЗаключение
Минимальный diff и проверяемые патчи меняют парадигму: вместо «генерируй-всё-заново» LLM становится предсказуемым соавтором, чьи правки точны, объяснимы и ревизуемы. Практика доказывает, что переход к стеку diff + двухуровневое ревью + assert/CI повышает сохранность текста c ≈ 75 % до ≥ 95 % и почти на 40 % сокращает трудозатраты редактора.
– позанимался пару дней экспериментами с разными промптами редактирования текстов (это я выполнял программу исследований, которую заявил в “Моих планах на лето”, Мои AI-планы на лето: ailev — ЖЖ – там я говорил, что начну с исследования инструментария, вот и начал). Эксперименты показали, что без внешнего по отношению к LLM контуру обработки текста – никак, LLM всегда обманет.
– далее проделал немаленькую работу, пытаясь разузнать у LLM в чате ответы на мои многочисленные вопросы (я уже знал, что спрашивал). Появился чат, в котором было обсуждено много чего разного.
– далее я предложил сетке сделать аутлайн White Paper и написать отдельные куски по этому аутлайну.
– далее я смотрел на этот аутлайн и задавал вопросы, они приводили к появлению дополнительных кусков текста.
Вот шаги процесса (их собрала o3 по всему чату):
- Формулировка проблемы. Обсудили «усадку» текста, сложности diff-правок, критичные домены (регламенты, код). Первичный список болей LLM-редактирования
- Сбор сценариев, где риск максимален. Перечислили 7 сфер (eCTD, контракты, код, инженерные wiki, научные статьи, SOC-логи, локализация). Таблица «Сценарии → риск»
- Инвентаризация типичных сбоев «чистой LLM». Усадка, ленивые ответы, переписывание файла, галлюцинации, формат-loss, обрыв контекста, спуриозность. Таблица «Сбой → описание → источник»
- Определение метрик и бенчмарков. Разобрали InstrEditBench, Can-It-Edit, Laziness, Compression-ED, UX-Warn/Verify, DSPy Assertions. Таблица классов метрик
- Квантификация стоимости ошибок. Привели долларовые оценки FDA R2F, исков BigLaw, CISQ, IBM breach, UX-стоимость. Таблица рисков/стоимости
- Проработали архитектурные решения. 6 слоёв: constrained decoding → mask-infill → UI-lock → assert → diff-протокол → контекст-mgmt. Слоёвая матрица «приём → защита → примеры»
- Собрали инструментальный ландшафт. FineEdit, InkSync, Cursor, Continue, Windsurf, Cline, Aider, InlineAI + Obsidian, CI-hooks. Таблицы «Редакторы новой волны», «IDE-экосистема», «Obsidian-стек»
- Составили расширенный аутлайн (20 k зн.). Выстроили структуру: постановка проблемы → методы → инструменты → лакуны → выводы. 20-пунктовый план
- Заполнили ключевые разделы. Написали: аннотацию, сценарии, сбои, метрики, стоимость, часть II (методы), часть III (инструменты), часть IV (гепы), заключение. Черновой текст разделов
- Сделали верификационный чек. Сравнили черновик с аутлайном; обнаружили отсутствие «живых» кейсов. Таблица соответствия, отметка пробела
- Добавили живые примеры. 3 кейса: ГОСТ-абзац, SQL-миграция, Markdown-формула — clean LLM vs LLM+обвязка. Подраздел 4 с цифрами выигрыша
- Уточнили когнитивную аналогию S1/S2. Перестроили таблицу на 5 колонок (S1, S2, LLM, обвязка) + инверсия эффективности. Новая таблица аналогий
- Критически оценили Cursor-only подход. Составили список 7 ограничений Cursor (баги на больших файлах, отсутствие факт-чека…). Подраздел «Почему Cursor недостаточен»
- Выявили, чего нет в “надёжных” IDE, но есть в браузерных LLM-чатах. Поиск/Browse, Memory, мультимодальность, GPT-Store, sharing, voice и т.д.. Таблица недостающих функций
- Собрали финальную статью. Объединили все разделы, добавили недостающие кейсы, ссылки, оформленные таблицы. Итоговый черновик ≈ 20 k знаков
- Финальный вывод / рецепт внедрения. 3-пунктовый чек-лист: требовать diff → Reviewer+assert → git-история. Заключение статьи
После этого:
– я взял Obsidian и получил там черновик White Paper, просто собрав руками через cut/paste полный текст, но в нём не было литературы.
– я попросил сделать по этому черновику deep research, и o3 поблагодарила меня за предоставленный подробный черновик – и почти ничего в нём не тронула, зато что-то там поправила и добавила литературу.
Вот этот результат я даю я этим постом: release early, release often. Там по факту гибрид: большое количество моих идей (скажем, про S1 и S2 это я просил написать, про “почему нельзя просто поставить Cursor IDE и считать задачу решённой” - тоже я. Но LLM наполнила это всё текстом (конечно, с неизбежными галлюцинациями и искажениями) и привела ссылки на тексты, которые можно почитать по проблеме.
– на этом я оборвал процесс: дальше там нужно делать проверки и правки по итогам проверок. Но сам отчёт показывает, что с инструментами для этого более чем туго (хотя они уже есть).
По итогам я долго думал – и пришёл к выводу, что:
– нужно разобраться с тезисом “Моделирование/программирование/онтологизирование/документирование-в-большом: лаптем или coda.io” (Моделирование/программирование/онтологизирование/документирование-в-большом: лаптем или coda.io?: ailev — ЖЖ, 2021), перед эти был заход на курс вычислительного мышления как работу с описаниями (программы это физические устройства по обработке информации согласно алгоритму, constructors распространяют эту идею на физический мир), это 2020 " Курс вычислительного мышления: надо делать!" Курс вычислительного мышления: надо делать!: ailev — ЖЖ, до этого – “О предмете курса вычислительного мышления”, О предмете курса вычислительного мышления: ailev — ЖЖ, до этого древний текст 2012 года про информатику как работу агентов (людей и компьютеров) с текстами и кодами, Информатика: ailev — ЖЖ. Всё это, конечно, нашло отражение в тексте “Интеллект-стек”.
– но новая волна AI-инструментария показывает, что кроме локальных представлений есть ещё и распределённые представления, и они с обработкой информации с одной стороны справляются, а с другой – нет. И ещё понятно, что всё там происходящее это часть общего agile процесса разработки описаний, где “всё есть текст”, только этот текст разного уровня формальности и мы ему ещё и не очень верим (ибо по пути там на каждом шаге могут быть ошибки).
– чтобы решить проблему с инструментарием обработки чего-то найденного (данных, AI-research agents), неформальных текстов художественных книг, формальных текстов регламентов и договоров, формальных текстов кодов и т.д., надо опять вспомнить, что алгоритмы, доказательства, теории – это одно и то же, а предметом обсуждения является познание, всё для него. То есть разбираться надо не больше и не меньше, чем с эпистемологией. Для которой нет никакого продвинутого фреймворка, хотя довольно много интересных наблюдений, которые собраны в наших руководствах.
Так что я сделал паузу в работе над проблемой инструментария – и пошёл разбираться в эпистемологии, ибо мне нужно чётко понимать, что там за процесс получения какого-то знания, который поддерживают все эти виды удивительно похожих друг на друга, но таких разных AI-агентов. Нужен язык, позволяющий как-то компактно описывать важное в предметной области обработки информации, язык эпистемологии. Нужна какая-то верхнеуровневая онтология эпистемологии, а если уж совсем обобщать, то гносеологии (кроме научного познания надо же учесть ещё и художественное, религиозное, мифологическое племенное и всякое другое познание).
И я занялся эпистемологией, по которой за пару дней в паре с LLM накатал прототип фреймворка на 270Кзнаков в Markdown, да ещё и сразу на английском. И шагов процесса там втрое больше. Там строятся вполне себе безбашенные эпистемологические Нью-Васюки, но рассказ про этот эпистемологический фреймворк уже совсем другая история.
