«Проводник» v2 — аудит первой версии и переработанный проект онлайн-сервиса

Версия 1 (provodnik-project.md) предлагала локальный набор инструкций для Claude Code / Codex участника. Это противоречит цели владельца: методология — актив, из которого вырастает платный сервис по внедрению ИИ в бизнес, а группа — первый тест этого продукта. Ниже — разбор, почему v1 ошибочна, и проект v2: веб-сервис, в который участники заходят, плюс Telegram-бот как второй канал. Методология, вопросы, критерии, шаблоны, правила гейтов, калькуляторы и промпты живут только на сервере.

Часть 1. Критический аудит версии 1

1.1. Корневая ошибка: агент живёт у участника

Цепочка «почему»:

1. Почему v1 отдала методологию в файлы на машине участника? — Потому что агент был спроектирован как локальный набор инструкций для Claude Code / Codex.
2. Почему агент локальный? — Потому что я взял требование программы «нужен платный Claude Code или Codex» за требование к продукту.
3. Почему требование текущей программы стало требованием продукта? — Потому что я не отделил ограничения ручной программы, написанной до появления сервиса, от ограничений сервиса.
4. Почему не отделил? — Потому что оптимизировал техническую простоту и локальность данных, а не то, чей актив создаётся.
5. Почему не учёл актив? — Потому что не назвал владельца продукта как главного стейкхолдера: сервис проектировался «для участников», а не «для владельца методологии, которую участники тестируют».
6. Почему владелец выпал? — Потому что фраза «сервис, на который они зайдут» была прочитана как расплывчатая формулировка, а не как прямое требование о хостинге и контроле.
7. Почему прямое требование было переопределено? — Потому что решение принималось по инженерным критериям без критерия «кто владеет кодом, промптами и данными после программы».
8. Почему такого критерия не было? — Потому что в v1 нет раздела «продуктовая рамка»: что продаём, кому, что защищаем, куда растём.
9. Почему нет продуктовой рамки? — Потому что я начал с архитектуры, а не с бизнес-модели.
10. Корень: архитектура выбиралась раньше, чем была зафиксирована модель владения активом. Любое решение, принятое до ответа на вопрос «что является активом и где он живёт», будет случайным.

Исправление на корне: в v2 первым идёт раздел «Актив и что защищаем». Всё, что составляет методологию, — данные на сервере, управляемые владельцем через админ-панель. Клиент видит только отрисованный текущий шаг.

1.2. Остальные находки

Часть 2. Проект v2 — онлайн-сервис «Проводник»

2.1. Продуктовая рамка

Что продаём. Проведение бизнеса от «хотим ИИ» до проверенного решения о внедрении одного процесса, а затем — исполнение внедрённого процесса на платформе.

Кому. Сейчас — участникам закрытой группы (7–8 собственников и руководителей) под руководством ведущего. Дальше — компаниям напрямую, где роль ведущего выполняет внутренний AI-лидер или эксперт владельца платформы.

Три режима платформы, одна кодовая база:

Первая группа — тест режима «Когорта» и заготовка режима «Исполнение».

2.2. Актив: что защищаем и где оно живёт

Реестр методологии как контента. Всё это хранится на сервере, версионируется и редактируется владельцем в админ-панели:

1. Банк вопросов интервью по каждому этапу с правилами ветвления.
2. Шаблоны девяти артефактов с обязательными полями и критериями заполненности.
3. Критерии четырёх гейтов и пяти уровней.
4. Стандарт evidence-first: какие утверждения обязательны к регистрации на каждом этапе.
5. Таксономия вмешательств для журнала недели 4.
6. Каталог архитектур и правила выбора для недели 6.
7. Модель экономики и её входы.
8. Правила формирования решения недели 8.
9. Системные промпты, инструкции инструментов, оценщики качества артефактов.
10. Примеры обезличенных проектов и типовые процессы.

Что видит участник: текущий шаг, вопросы этого шага, свои артефакты, свои доказательства, свой статус. Он никогда не получает файл методологии, полный банк вопросов, критерии гейтов в исходном виде или промпты.

2.3. Защита от извлечения — честная граница

Что утекает в любом сервисе: сами вопросы, которые пользователь увидел, структура его артефактов, общая логика этапов. Это неизбежно и не является активом: программа уже опубликована на сайте. Актив — движок: полный банк вопросов и ветвления, критерии, оценщики, промпты, каталог с правилами, калькуляторы, накопленные примеры.

Меры: - Промпты и правила не покидают сервер; клиент получает только отрисованный ответ и структурированные данные текущего шага. - Инструкция модели запрещает раскрывать системные инструкции; выходной фильтр отбрасывает ответы, содержащие маркеры служебных инструкций. Это снижает, а не исключает риск, поэтому основной барьер — то, что критерии и ветвления вычисляются кодом на сервере, а не лежат целиком в промпте. - Экспорт участнику — только его артефакты в его форматах (md, docx, pdf), без служебных полей. - Условия использования: запрет копирования методологии и обратной разработки; для группы — соглашение о неразглашении в правилах участия.

2.4. Роли и объекты

Роли: - Владелец платформы — управляет методологией, когортами, видит всё. - Ведущий когорты — консоль когорты, решения по гейтам, повестка, разборы. В первой группе совпадает с владельцем. - Участник — владелец проекта, работает с Проводником. - Гость проекта — владелец процесса, заказчик результата, исполнитель, технический специалист. Доступ по приглашению к конкретным действиям: ответить на вопросы интервью, подтвердить карту, подтвердить приёмку результата. Не видит чужие проекты и методологию.

Объекты данных:

Организация (компания участника)
  └─ Пользователи и гости
Когорта (группа) → версия методологии, расписание встреч, ведущий
  └─ Проект (один процесс участника)
       ├─ Этапы 1–8: состояние, критерии, блокеры
       ├─ Артефакты: паспорт, контракт, карта, пакет контекста, набор проверок,
       │   рабочая версия, экономика, решение, план 30 дней — структурированные, версионируемые
       ├─ Файлы: класс данных, кто загрузил, срок хранения
       ├─ Утверждения (claims) и Основания (evidence)
       ├─ Прогоны (runs) и записи Журнала вмешательств
       ├─ Процесс-агент: шаги, правила, точки подтверждения, контекст-пакет
       ├─ Тест-кейсы: обучающие и отложенные, результаты
       ├─ Гейты 1–4: пакет, решение ведущего, дата
       ├─ Сессии Проводника (диалоги) с привязкой к этапу
       └─ Приёмка: подтверждение заказчика (действие гостя)
Встреча когорты → повестка, транскрипт, флаг «не записывать» по проекту
Событие продукта (аналитика) → пользователь, проект, этап, действие, длительность

2.5. Путь участника и экраны

1. Заявка. В Telegram-боте или на странице заявки: семь вопросов из раздела «Перед началом», голосом или текстом. Транскрипция, структурирование, запрос запасного процесса. Ведущий видит карточку и принимает гейт «До старта».
2. Вход. Ссылка входа по почте, привязка Telegram по коду. Подтверждение правил конфиденциальности и права использовать данные процесса в пилоте.
3. Рабочее место проекта — один экран, три зоны: - слева — маршрут: восемь этапов, текущий, что закрыто, что блокирует, дата следующей встречи; - в центре — Проводник: диалог по текущему шагу, загрузка файлов, голосовой ввод, кнопки действий шага; - справа — артефакт этапа: заполняется по ходу диалога, поля с индикаторами «пусто / черновик / подтверждено», рядом панель утверждений и оснований.
4. Гость. Приглашение по ссылке: заказчик результата открывает одну страницу с результатом и кнопкой «Подтверждаю приёмку» или «Не принимаю, потому что…». Владелец процесса — страницу карты с «Подтверждаю» и правками.
5. Гейт. Когда критерии закрыты, участник отправляет пакет на решение; ведущий в консоли подтверждает, возвращает с комментарием или переводит на «сузить / заменить процесс».
6. Подготовка к встрече. Одна кнопка: сводка на страницу — что сделано, барьеры, вопрос к группе. Уходит ведущему и по желанию в закрытый чат.
7. Финал. Решение, план на 30 дней, демонстрация цепочки «вывод → основание → данные», экспорт пакета, чек-лист закрытия доступов. При решении «запускать» — проект переходит в режим «Исполнение».

2.6. Проводник — движок

Оркестрация — код, диалог — модель. Машина состояний этапов, критерии заполненности, гейты, экономика и выбор архитектуры вычисляются кодом на сервере из данных методологии. Модель ведёт разговор, извлекает структуру из ответов и файлов, пишет черновики, находит противоречия и объясняет. Это одновременно и защита актива (правила не в промпте), и защита от «уговорил модель пропустить этап».

Инструменты модели (серверные): - read_step — текущий шаг, его вопросы и незакрытые поля (модель получает только то, что нужно сейчас); - write_artifact_field — записать поле артефакта как черновик; - propose_claim — зарегистрировать утверждение с предлагаемым статусом и основанием; - read_file — прочитать разобранный сервером файл (таблицы, документы, транскрипты); - run_calculator — экономика, сравнение прогонов, статистика тестов; - log_intervention — запись в журнал вмешательств во время прогона; - execute_process_step — выполнить шаг процесс-агента на данных проекта; - search_methodology — ответ на вопрос «как правильно» из методички: модель получает только релевантный фрагмент, отрисованный для пользователя, не исходник.

Модель. claude-opus-5 для диалога и черновиков; claude-haiku-4-5 для массовых извлечений из файлов и транскрипций. Стабильный префикс (инструкции, описание инструментов, данные шага) кэшируется; переменная часть — реплики. Включён серверный fallback на отказ модели. Диалог ведётся потоково.

Правила тона зафиксированы в методологии, а не в коде: один вопрос за раз, без лекций, теория по запросу, «данных недостаточно» — остановка и вопрос человеку.

2.7. Методология как контент — админ-панель владельца

• Редактор этапов: вопросы, ветвления, поля артефактов, критерии заполненности, критерии гейтов, тексты подсказок.
• Версии методологии: когорта закрепляется за версией; правки по ходу группы — либо горячее исправление текста, либо новая версия для следующей группы.
• Каталог архитектур и правила выбора — таблица, а не код.
• Модель экономики — формулы и обязательные входы.
• Библиотека примеров: обезличенные артефакты завершённых проектов, помечаются владельцем как «можно показывать».
• Просмотр диалогов участников с их согласия для улучшения вопросов — источник роста методологии.

2.8. Evidence-двигатель

• Утверждение — объект: текст, этап, поле артефакта, предложенный статус, основание, что осталось неизвестным.
• Основание — объект: файл и локатор (лист, строка, страница, фрагмент), запись журнала, ответ гостя, ссылка на внешний источник, правило из контекст-пакета.
• Статусы: «предположение» и «данных недостаточно» модель ставит сама. «Проверено» ставит только человек: открыл основание в интерфейсе, нажал «Подтверждаю, что основание подтверждает вывод». Модель не может выставить «проверено» ни при каких условиях.
• Обязательные утверждения по этапам заданы в методологии: числа паспорта, критерии контракта, правила развилок, выводы прогонов, входы экономики, рекомендация решения. Гейт не принимает пакет, пока обязательные утверждения не имеют статуса, а критичные — статуса «проверено».
• Трассировка — от любого поля артефакта до утверждения, от утверждения до основания, от основания до строки файла. Это же и демонстрация на финальной встрече.
• Правило остановки: «данных недостаточно» на развилке останавливает прогон и создаёт задачу человеку.
• Никаких процентов уверенности от модели: только три статуса.

2.9. Маршрут по неделям — что меняется относительно v1

Содержание этапов остаётся как в v1 (главный вопрос, входы, работа агента и человека, артефакт, критерий готовности). Меняется механика:

2.10. Прогоны и процесс-агент: два контура исполнения

Контур A — в сервисе. Участник загружает данные кейса с классом «внутренние» или «конфиденциальные», сервис хранит их изолированно, модель выполняет шаги, результат и журнал остаются в проекте. Основной путь для первой группы.

Контур B — конфиденциальный. Данные класса «запрещённые к передаче внешним моделям» в сервис не загружаются. Сервис выдаёт задание на шаг: что сделать, с какими входами, в каком формате результат. Участник выполняет шаг у себя — руками, в своём Claude Code или во внутренней системе — и вносит в сервис результат, обезличенный пример и запись журнала. Задание на шаг — производная от проекта участника, не методология.

Процесс-агент v1 — минимальный набор типов шагов: 1. Вход: файл, текст, ответ человека. 2. LLM-шаг с контекст-пакетом и шаблоном результата. 3. Проверка: правило или чек-лист, результат «прошло / не прошло / нужен человек». 4. Развилка: правило из карты или «решает человек». 5. Подтверждение человека — обязательный тип для всего, что уходит наружу или меняет данные. 6. Выход: артефакт по шаблону контракта.

Коннекторы во внешние системы (почта, CRM, таблицы, мессенджеры) в v1 отсутствуют. Поэтому необратимых действий платформа совершить не может по построению. Коннекторы добавляются в режиме «Исполнение» только вместе с шагом «подтверждение человека» и полями «остановка, откат, ответственный за инцидент».

Обратная совместимость с «передать в разработку». Любой процесс-агент экспортируется как спецификация: шаги, правила, контекст, тест-кейсы, критерии приёмки. Это путь для процессов, которым нужны код и интеграции в корпоративные системы.

2.11. Проверки и экономика

• Кейсы делятся при создании: «обучающий» (использовался при настройке) и «отложенный» (не использовался). Метрики недели 7 считаются только по отложенным.
• Метрики: доля результатов, принятых по контракту; доля кейсов с вмешательством; время на кейс; критические ошибки.
• Экономика: текущая стоимость (частота × время × стоимость часа + ошибки), новая стоимость (токены и платформа на кейс × частота + время подтверждений × стоимость часа + поддержка), эффект по деньгам, времени и качеству, окупаемость. Каждый вход — утверждение с основанием; при отсутствии данных — два сценария, а не среднее по рынку.
• Стоимость токенов берётся из реальных счётчиков прогонов проекта, а не из допущений.

2.12. Консоль ведущего и когорты

• Таблица: участник × этап × уровень × дата последней активности × открытые блокеры × гейты.
• Флаги риска: нет активности больше пяти дней; к встрече не закрыт критерий этапа; к неделе 4 меньше трёх прогонов; заказчик не подтвердил контракт к гейту 1.
• Карточка проекта: артефакты, утверждения, журнал, сводка к встрече. Ведущий видит содержимое проектов своей когорты — это условие участия, зафиксированное в правилах.
• Гейты: пакет, кнопки «подтвердить / вернуть / сузить / заменить процесс», комментарий.
• Повестка встречи: 2–3 проекта, стоящих на гейте или с барьерами, формируется автоматически, правится вручную.
• Дайджест когорты раз в неделю: в консоль, на почту, в Telegram.
• Встречи: транскрипт в библиотеку когорты; флаг «не записывать» на проекте отключает включение его фрагмента.

2.13. Данные и безопасность

2.14. Продуктовый тест на первой группе

Группа — тест продукта, значит нужны гипотезы, измерение и петли обратной связи.

Гипотезы: 1. Участник без технического опыта проходит этапы 1–3 самостоятельно, тратя на вопросы ведущему не больше заданного порога часов. 2. Evidence-двигатель используется: доля обязательных утверждений с основанием к неделе 8 выше порога, и участники считают его полезным, а не бюрократией. 3. Конструктора процесс-агента v1 хватает для большинства процессов группы без кода. 4. Ведущий тратит на группу меньше часов, чем в ручном формате.

Инструментирование: событие на каждое действие (открыл шаг, ответил, загрузил, подтвердил поле, подтвердил утверждение, застрял — нет активности на шаге дольше порога, обратился к ведущему); длительность шага; число реплик на артефакт; число возвратов с гейта.

Петли обратной связи: короткий вопрос в конце каждого этапа «что мешало»; журнал трения ведущего после каждой встречи; разбор диалогов застрявших участников с их согласия; правки методологии в админ-панели между неделями.

Критерий успеха теста: порог по каждой гипотезе задаётся владельцем до старта и фиксируется в админ-панели, а не подбирается после.

2.15. Технические требования и стек

Требования к нагрузке, из которых выбирается стек: - долгие потоковые LLM-сессии с вызовами инструментов, десятки минут на прогон; - разбор файлов: таблицы, документы, pdf, аудио → текст; - изоляция арендаторов, шифрование, журнал аудита; - фоновые задачи: прогоны отложенных кейсов, дайджесты, транскрипция; - админ-панель с версионированием контента.

Рекомендуемый стек по этим требованиям:

2.16. Стоимость LLM — формула и как её измерить

Стоимость участника за программу = Σ по сессиям (входные токены × цена входа + кэшированные токены × цена кэша + выходные токены × цена выхода).

Цены провайдера на момент написания (справка из документации API): claude-opus-5 — 5 $ за миллион входных, 25 $ за миллион выходных токенов; claude-haiku-4-5 — 1 $ и 5 $ соответственно.

Пример при допущениях, которые нужно заменить измерением в первой группе: 8 недель × 4 часа работы × 20 обменов в час × (6 000 входных, из них 5 000 из кэша, и 800 выходных токенов) — это 640 обменов, около 3,8 млн входных, 3,2 млн из них кэшированных, и 0,5 млн выходных. По ценам выше без учёта скидки за кэш это меньше 35 $ на участника за программу; кэш снижает входную часть дальше. Реальную цифру даёт счётчик токенов, встроенный в сервис с первого дня, — это одна из метрик теста.

2.17. План MVP и дорожная карта

Ко дню старта первой группы (обязательно): - вход, организация, проект, Telegram-привязка; - заявка через бот и через веб; - рабочее место с тремя зонами, диалог Проводника с инструментами шага; - этапы 1–3 полностью: вопросы, артефакты, критерии, гейт 1, гостевые подтверждения контракта и карты; - загрузка файлов с классом данных и разбором таблиц, документов, транскриптов; - утверждения и основания с человеческим подтверждением; - консоль ведущего: таблица, флаги, гейт, повестка, сводка к встрече; - админ-панель: редактирование вопросов, полей, критериев этапов 1–3; - события аналитики и счётчик токенов.

По ходу недель 1–3 (к неделе 4): прогоны с журналом, таксономия вмешательств, гейт 2, контур B с заданиями на шаг.

К неделе 5–6: сопоставление журнала с контекст-пакетом, конструктор процесс-агента с шестью типами шагов, каталог архитектур, экспорт спецификации.

К неделе 7–8: разделение кейсов, прогон отложенных, метрики, калькулятор экономики, гостевая приёмка, гейт 3, решение, план на 30 дней, трассировка, экспорт пакета, чек-лист закрытия.

После первой группы: режим «Компания» (самостоятельное прохождение, платные экспертные разборы), режим «Исполнение» (процесс-агент работает на постоянной основе, первые коннекторы с подтверждением человека), библиотека типовых процессов, тарифы.

2.18. Риски v2 и решения за владельцем

1. Объём MVP ко дню старта. Этапы 1–3 с консолью и админ-панелью — это полноценное приложение. Если сроки жёсткие, минимальный срез: этап 1 и 2 в полном виде, этап 3 — вопросы и артефакт без гостевого подтверждения; консоль — таблица и гейт. Решение о дате старта группы принимается после оценки объёма командой разработки.
2. Требование «платный Claude Code или Codex» на странице программы. В v2 агент встроен в сервис. Варианты: убрать требование; оставить как рекомендацию для контура B. Решение владельца, страницу нужно синхронизировать.
3. Согласие на просмотр диалогов ведущим. Это условие участия и источник улучшения методологии. Должно быть в правилах до старта.
4. Юрисдикция и провайдер модели. Влияет на выбор хостинга и на то, какие компании смогут участвовать. Решить до разработки.
5. Извлечение методологии через диалог. Снижено переносом правил в код и фильтрами, но не исключено. Принять как остаточный риск или ограничить круг участников соглашением.
6. Качество русскоязычного диалога и транскрипции — измерять в первой группе, не предполагать.
7. Конкуренция за внимание участника между веб и Telegram. Telegram — только заявка, уведомления и короткие вопросы. Вся работа — в веб; иначе логика расползётся на два канала.

2.19. Итог

v1 отдавала актив в руки участников и не имела пути к платному продукту. v2 — онлайн-сервис, где методология живёт как версионируемый контент на сервере, правила этапов и гейтов исполняет код, модель ведёт диалог и пишет черновики, «проверено» ставит только человек, а рабочая версия процесса собирается и остаётся на платформе. Первая группа проходит программу в этом сервисе и одновременно измеряется как продуктовый тест по заранее заданным гипотезам.