Рабочая среда.
Один раз настроить — и перестать объяснять контекст заново.

01 · Что это

Помощник, который работает с файлами в разрешённых границах

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

Терминал — окно для текстовых команд компьютеру. Многие задачи можно описывать обычным языком, но базовые навыки всё равно нужны: видеть текущую папку, различать чтение и изменение, понимать запрос разрешения, проверять список изменённых файлов и останавливать опасную команду. Сложные операции передают специалисту.

Учебный пример не маскируется под настоящую компанию

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

Что проверить перед нажатием «Разрешить»

1. Прочитайте точную команду или простое описание действия. Непонятное действие не подтверждают «потому что так обычно делают».
2. Проверьте цель: какой наблюдаемый результат должен появиться.
3. Проверьте точный объект: файл, папку, сервис, учётную запись или адрес. Особая осторожность нужна для удаления, замены, публикации и передачи данных.
4. Проверьте последствия: что изменится, кому станет видно, можно ли отменить и где лежит резервная копия.
5. Проверьте права и данные: не выдаётся ли доступ шире задачи и не уходят ли персональные, клиентские или секретные сведения.
6. Если объяснение неполное, нажмите отказ и попросите безопасный вариант или помощь специалиста. Отказ от непонятного действия — нормальная часть работы.

02 · Рабочее место

Терминал слева, файлы справа

Это выглядит как мелочь оформления, но это первое, что отделяет работу от игры с чатом. Пока ты не видишь файлы, которые создаются, ты не можешь их принимать.

Шаги

1. Создать отдельную папку проекта. Один клиент или одно направление — одна папка. Не общая свалка.
2. Открыть папку в редакторе, который показывает дерево файлов и обычные текстовые файлы с разметкой .md. Подойдёт VS Code, Obsidian или аналог.
3. Запустить ИИ-инструмент в этой же папке.
4. Разложить окна: терминал на левую половину экрана, редактор на правую. На Windows — потянуть окно к краю, система предложит половину. На Mac — зажать зелёную кнопку окна.
5. Проверить связку: попросить создать тестовый файл и убедиться, что он появился в редакторе в реальном времени.

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

03 · Структура

Отделить проверенное от черновиков

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

Здесь не создаётся отдельная «структура для ИИ». Используется та же папка проекта, что и во всём маршруте. На странице маршрута можно скопировать каждое название. Ниже показано, какой раздел выполняет какую роль.

Структура нужна, чтобы отвечать на вопрос о статусе за секунды

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

Разделение по стадии готовности отвечает на этот вопрос расположением файла. Это и есть смысл нумерованных разделов: место говорит о статусе до открытия.

Раскладка по типу файла вместо стадии — частая и дорогая ошибка

Папки «Тексты», «Таблицы», «Картинки» кажутся естественными и не различают главного: черновик и утверждённое лежат рядом. Через месяц отличить их можно только по памяти.

Тип файла вообще редко определяет работу с ним. Определяют стадия и происхождение — кто дал, кто проверил, можно ли менять.

Исходник заказчика не переписывают никогда

Правка полученной выгрузки «чтобы было удобнее» уничтожает единственную точку опоры. Через месяц не с чем сверить расчёт, и восстановить исходное состояние невозможно.

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

Архив ценнее, чем кажется, но только с причиной переноса

Отменённые версии удаляют, чтобы не мешали, и теряют вместе с ними историю решений. Через полгода компания повторяет отвергнутый вариант, потому что причина отказа нигде не записана.

Архив с одной строкой причины и датой стоит ничего. Опасен он в одном случае — когда из него берут материалы как действующие, поэтому пометка о недействительности обязательна.

Название файла — часть структуры, а не украшение

Файлы «финал», «финал2», «финал_правки» появляются в любом проекте и делают папку нечитаемой. Определить актуальную версию по такому имени нельзя.

Дата в начале имени и короткое описание содержания решают задачу почти полностью: файлы сортируются сами, а последний оказывается сверху. Слова о готовности в имени лучше не использовать вовсе — за готовность отвечает папка.

Структура принимается всеми или не существует

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

Поэтому структуру обсуждают до начала работы и проверяют не наличие папок, а способность второго человека найти в них нужное без подсказок. Это же проверка перед передачей проекта.

Главное правило структуры: факт не редактируется как черновик. Если факт устарел, меняется первичный документ — с датой, источником и историей изменения. Иначе через месяц никто не сможет ответить, откуда взялось число в отчёте.

04 · Файл контекста

Короткий файл устойчивого контекста проекта

Он хранит сведения и правила, которые нужны во многих задачах. Автоматическое чтение зависит от настройки инструмента, поэтому подключение проверяют в начале новой сессии.

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

Файл контекста нужен решениям, а не описанию компании

Соблазн описать проект целиком приводит к документу, который никто не читает и который расходится с реальностью через месяц. Объём здесь работает против назначения.

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

Проверяют не наличие файла, а его влияние на ответ

Файл может лежать в правильном месте и не участвовать в работе: подключение зависит от инструмента, настройки и того, откуда запущена сессия. Обнаруживается это обычно на важной задаче.

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

Утверждение без даты стареет молча

Запись не подаёт признаков устаревания: она выглядит одинаково убедительно и через неделю, и через год. Ошибки из-за этого обнаруживаются в момент, когда на устаревшее уже сослались перед клиентом.

Дата, на которую утверждение верно, и событие пересмотра решают это простым способом. Записи без даты стоит считать предположениями независимо от того, насколько они кажутся очевидными.

Разделять устойчивое и меняющееся дешевле, чем потом их растаскивать

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

Граница проходит по частоте изменения: то, что меняется по решению, — здесь; то, что меняется само, — в отчёте со ссылкой отсюда. Смешивать удобнее ровно до первого расхождения.

Формулировка «не знаю» должна быть разрешена явно

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

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

У файла должен быть владелец, иначе он умирает тихо

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

Имя владельца и ближайшее событие пересмотра стоят двух строк. Пересмотр удобнее привязывать не к календарю, а к событиям — смене продукта, цен, команды или правил, — потому что именно они делают файл неверным.

Порядок доверия источникам решает споры заранее

Когда два места в проекте говорят разное, вопрос «какому верить» обсуждается каждый раз заново и обычно решается в пользу того, что нашли первым.

Названная заранее старшинство — утверждённое решение выше пересказа, датированный первичный материал выше старого резюме — снимает этот спор целиком. Правило же говорит, что делать при неразрешимом расхождении: остановиться и спросить владельца, а не выбрать удобное.

Описание аудитории через наблюдаемую ситуацию, а не через признаки

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

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

Секретам, ключам и персональным данным здесь не место

Файл контекста по назначению копируется, пересылается, попадает в резервные копии и открывается на чужих экранах. Любой секрет в нём расходится тем же путём.

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

Приоритеты хранят с датой пересмотра, иначе они накапливаются

Направления добавляются легко и почти никогда не убираются. Через квартал список «текущих приоритетов» насчитывает семь пунктов и перестаёт что-либо приоритизировать.

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

Право решать называют поимённо, а не должностями

Формулировка через роль не отвечает на вопрос, у кого спрашивать сейчас. Из-за этого согласование зависает, а исполнитель принимает решение сам — не по злому умыслу, а потому что спросить некого.

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

Каждое изменение файла записывают коротко и сразу

Без истории правок невозможно понять, почему формулировка стала такой, и через месяц её меняют обратно. Цикл повторяется, пока кто-нибудь не запишет причину.

Одной строки с датой, сутью и основанием достаточно. Полезнее всего она в неочевидных местах — там, где текущая формулировка выглядит странно и на самом деле выстрадана.

У каждого факта должен быть хозяин и срок жизни

Одна строка «у нас 210 клиентов» быстро превращает память проекта в источник ошибок. Непонятно, откуда взялось число, на какую дату оно верно и можно ли уже использовать его в предложении клиенту. Поэтому устойчивое описание и меняющиеся данные ведут раздельно.

Описание пользователя тоже не становится фактом только потому, что ему дали имя и фотографию. Для каждой роли укажите: кто покупает, кто ежедневно пользуется, кто согласует, кто может заблокировать решение; какую работу человек выполняет; каким наблюдением это подтверждено; как часто возникает ситуация; какой показатель меняется. Вымышленные цитаты помечайте как учебный пример или удаляйте.

Как проверить, что он работает

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

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

05 · Ролевые инструкции

Текстовый файл с ролью — ещё не самостоятельный агент

Ролевая инструкция задаёт источники, порядок работы, формат и границы. Агентом обычно называют систему, которая ещё умеет планировать шаги и вызывать инструменты в пределах прав.

Файл инструкции можно хранить в папке проекта и подключать к задаче. Его изменение не является «переобучением» модели: меняются только указания для следующих запусков. Способ автоматического подключения зависит от рабочего инструмента и должен быть проверен.

Четыре начальные роли — только примеры

Инструкция описывает порядок работы, а не характер исполнителя

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

Работает то, что можно нарушить и заметить: какие источники разрешены, в каком порядке отвечать, что запрещено утверждать, что делать при нехватке данных. Всё прочее — украшение.

Разные названия ролей не создают независимых мнений

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

Независимость даёт разный вход: разные источники, разные критерии, разные периоды. Без этого разделение по ролям остаётся оформлением, полезным для структуры и бесполезным для проверки.

Раздел запретов важнее раздела задач

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

Запреты формулируют конкретно: не придумывать свойств продукта, не называть предположение выводом, не выдавать память об устройстве площадки за действующее правило. Общее «будь аккуратен» не работает.

Проверяют на задаче, ответ на которую известен заранее

Оценка по впечатлению от нового ответа не даёт ничего: убедительный текст выглядит убедительно независимо от верности.

Уже выполненная руками работа — единственный доступный эталон. Сравнивают не красоту, а совпадение фактов, соблюдение формата и честность про нехватку данных.

Конфликтующие критерии разводят по разным шагам

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

Разделение на два прохода сохраняет противоречие до человеческого решения. Это медленнее и единственный способ не потерять именно то, ради чего проверка затевалась.

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

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

Проверять это нужно не один раз, а при смене инструмента, версии и способа запуска. Самый надёжный признак — ответ, который без инструкции получиться не мог.

Не смешивайте конфликтующие критерии в одну команду. Один и тот же текст нужно отдельно проверить на доказанность и отредактировать на ясность. Разделение этапов помогает сохранить противоречие до человеческого решения; разные названия ролей сами по себе независимости не создают.

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

Роль руководителя по маркетингу проверяет решение, а не изображает авторитет

Фраза «у тебя двадцать лет опыта» не даёт модели ни опыта, ни доступа к рынку. Такая роль полезна как последовательность вопросов. Она не становится независимым заключением и не подтверждает собственные догадки.

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

Как тестировать ролевую инструкцию

1. Взять реальную задачу, которую ты уже делала руками и знаешь хороший ответ.
2. Выполнить её с подключённой ролевой инструкцией.
3. Сравнить не по «понравилось», а по формату: соблюдена ли структура ответа, названы ли ограничения, отделены ли факты от гипотез.
4. Поправить общий файл инструкции и повторить контрольный пример. Не считать файл постоянным: он действует только там, где действительно подключён.

Если процедура создаёт презентацию, таблицу, документ или файл для печати

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

1. Зафиксируйте исходник и назначение. Для кого файл, какое решение поддерживает, какая версия материалов использована, кто владеет данными и утверждает результат.
2. Проверьте содержание. У каждого числа, цитаты, сравнения и обещания есть источник и дата; неизвестное не заполнено догадкой; конфиденциальные сведения разрешены для этого адресата.
3. Проверьте структуру. Заголовки отражают выводы, порядок ведёт к решению, обязательные разделы есть, повторов и пустых декоративных страниц нет.
4. Проверьте формат по типу файла. В презентации — переполнение, размер текста, контраст, изображения, заметки докладчика и время выступления. В таблице — формулы, единицы, итоги, пустые и ошибочные входы, скрытые листы, фильтры и защита вводимых полей. В текстовом документе — стили заголовков, оглавление, таблицы, ссылки, подписи и разрывы страниц. В файле для печати — поиск и копирование текста, встроенные шрифты, поля, ссылки и читаемость каждой страницы.
5. Откройте результат другим способом. Используйте хотя бы одну независимую программу или просмотрщик, экспортируйте в конечный формат и визуально пройдите все страницы или листы. Проверка исходного кода генератора этого не заменяет.
6. Проведите контрольные примеры. Обычный, граничный и ошибочный вход должны давать ожидаемый результат или ясную остановку. Для таблицы вручную пересчитайте несколько строк.
7. Запишите приёмку. Версия, проверяющий, найденные проблемы, исправления, неустранённые ограничения, утверждение владельца данных и ссылка на исходники.

06 · Повторяемые процедуры

Роль задаёт точку зрения, процедура — порядок действий

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

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

Процедуру пишут после того, как работа сделана руками несколько раз

Записанная заранее последовательность описывает представление о работе, а не саму работу. Расхождение обнаруживается при первом нестандартном входе.

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

Граница применения важнее самих шагов

Процедура, у которой не назван неподходящий случай, применяется ко всему и даёт уверенный неверный результат. Формально она отработала правильно.

Раздел «когда не использовать» пишут одновременно с шагами и наполняют по мере накопления ошибок. Он же подсказывает, когда пора завести вторую процедуру вместо усложнения первой.

Контрольные примеры нужны, потому что правки ломают незаметно

Уточнение одного шага регулярно портит поведение на другом входе, и заметить это без проверки нельзя: результат по-прежнему выглядит правдоподобно.

Три сохранённых примера — обычный, пограничный и заведомо ошибочный — дают проверку за несколько минут. Пример с ошибкой важнее остальных: он показывает, останавливается процедура или заполняет пробел выдумкой.

Формат результата описывают точно, иначе экономии не будет

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

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

Одна процедура решает одну задачу

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

Признак — невозможность назвать один критерий годности результата. В этот момент процедуру делят, даже если запускать придётся две.

Процедура — документ со сроком жизни, а не разовая находка

Сохранённая и забытая инструкция продолжает применяться после того, как изменились данные, продукт или правила. Ошибки после этого воспроизводятся стабильно, что хуже случайных.

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

Нельзя выбирать форму по желанию «сделать умнее». Если одна задача зависит от результата другой, работа идёт последовательно. Если критерий нужен один раз, постоянная роль лишняя. Если процедура ещё не прошла обычный, пустой и ошибочный вход, ставить её на расписание рано.

Пример: разбор материала конкурента

Процедура, которая повторяется у любого маркетолога и почти всегда делается каждый раз заново:

1. Начало. Что привлекает внимание в первых строках или кадрах: вопрос, цифра, проблема или обещание.
2. Целевая группа. На кого направлено и какую задачу адресует.
3. Формат и объём. Что использовано и оправдан ли объём.
4. Что работает. Сильные стороны и что должно давать вовлечение.
5. Что слабо. Упущенные возможности.
6. Как адаптировать. Конкретная идея под свой голос и свой сегмент — механика, а не текст.
7. Вывод в одну строку. Стоит ли адаптировать формат и почему.

07 · Свои команды

Процедура под свою реальную задачу — не учебную

Самая полезная команда — не из примеров, а та, которую ты делаешь каждую неделю и каждый раз про себя думаешь «опять это».

Три вопроса перед созданием

1. Что на входе? Что именно ты даёшь: текст, выгрузку, ссылку, описание ситуации.
2. Что происходит? Какие шаги, в каком порядке, какая структура разбора.
3. Что на выходе? В каком формате нужен результат, чтобы им можно было пользоваться дальше без переделки.

Если на любой вопрос нет чёткого ответа, задача ещё не готова к автоматизации. Сначала выполните её вручную на нескольких отличающихся случаях и запишите, где требуется человеческое решение.

Кандидаты, которые есть почти у всех

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

Вести реестр всего рабочего набора

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

1. Занесите каждый артефакт отдельно: роль, процедура, расписание, подключение, файл контекста, шаблон или рабочее решение.
2. Запишите наблюдаемую задачу, входные данные, результат и точное место хранения. Название инструмента само по себе не объясняет пользу.
3. Назначьте состояние: черновик, проверяется, проверено, временно приостановлено или устарело. Неиспытанный файл нельзя считать частью действующего процесса.
4. Укажите владельца, версию, дату последней проверки и событие внепланового пересмотра: изменение продукта, данных, закона, площадки, тарифа или состава команды.
5. Приложите контрольный пример: вход, ожидаемый результат, фактический результат, ручные исправления и решение о пригодности.
6. Для расписания и подключения добавьте права, разрешённые данные, журнал ошибок, стоимость, способ остановки и порядок ручной работы при сбое.
7. Старую версию не удаляйте молча. Перенесите её в архив, запишите причину замены и укажите действующую версию.

08 · Сессия

Прервать, сохранить состояние, начать заново

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

Три признака, что пора зафиксировать состояние

1. Ответы стали менее точными, появляются повторы уже решённого.
2. Инструмент «не помнит» договорённость, которая была в начале работы.
3. Ты сама уже не помнишь, что обсуждалось в первой трети сессии.

Замедление ответа само по себе ничего не доказывает: причиной может быть размер файла, сеть, очередь сервиса или сложность действия. Ориентируйтесь на явное предупреждение программы, потерю уже данного контекста и собственную способность восстановить ход работы. Названия команд и клавиш зависят от инструмента и версии; перед использованием сверяйте встроенную справку. Устойчивый порядок не меняется: остановить → проверить частичные изменения → записать состояние → сохранить рабочие материалы → открыть новую сессию → передать резюме → проверить контекст.

Переключение между задачами

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

1. Попросить зафиксировать, где вы остановились.
2. Сохранить это резюме в файл, а не в буфер обмена.
3. Переключиться на срочное.
4. Вернувшись, начать с этого резюме, а не с «продолжим».

09 · Передача дел

Закрыть окно — не значит закончить

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

Запись состояния делают в конце работы, а не в начале следующей

Через сутки от контекста остаётся ощущение, а не структура: помнится вывод и забываются причины, по которым он получился. Восстановление задним числом даёт правдоподобный, но неточный текст.

Несколько минут в конце сессии, пока всё ещё очевидно, окупаются полностью. Ощущение избыточности этой записи — обычное и обманчивое.

Пишут для человека, который в работе не участвовал

Записка для себя опирается на невысказанное и через месяц непонятна собственному автору. Проверить это заранее невозможно, потому что при написании всё кажется ясным.

Установка «читать будет посторонний» делает запись пригодной и для себя тоже. Заодно она снимает вопрос, что делать при передаче работы другому исполнителю.

Причины решений важнее самих решений

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

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

Один следующий шаг вместо списка намерений

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

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

Отдельно фиксируют то, что нельзя додумывать

Открытые вопросы, требующие ответа заказчика или руководителя, при передаче теряются первыми. Дальше их заполняют разумным предположением, и ошибка обнаруживается на приёмке.

Явный список вопросов с именем того, кто на них отвечает, защищает следующего исполнителя. Он же показывает, что работа не остановилась по лени, а ждёт решения.

Незавершённое состояние описывают честно

Формулировка «почти готово» не сообщает ничего: она одинаково описывает и последнюю правку, и половину работы. Принимающий обнаруживает разницу, когда уже пообещал срок.

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

Новая сессия открывается с этой записи, а не с расплывчатого «продолжи». Иначе половина времени уходит на восстановление контекста, а вторая — на исправление того, что было восстановлено неверно.

10 · Параллельная работа

Параллелить можно только независимые задачи

Если результат шага Б зависит от смысла, выбора или проверки шага А — их нельзя раздать одновременно. Никакая мощность инструмента этого не меняет.

Тест перед запуском

1. Можно ли разделить задачу на части без обмена промежуточными решениями?
2. Для каждой части одинаково ли понятно, что считать результатом?
3. Есть ли один человек, который сравнит результаты и примет итоговое решение?
4. Не создаст ли параллельный поиск дубли, противоречия или риск разглашения данных?

«Нет» на любой из первых трёх — веди задачу последовательно.

До ускорения согласуйте срочность и границы работы

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

После возврата веток обязательны три шага: проверка источников, сведение в одну матрицу, устранение противоречий. Несколько отчётов без синтеза управленческой ценности не создают. Хорошая параллельность оставляет после себя не пачку файлов, а единый проверяемый вход для решения.

Если ветки изучают разных конкурентов

1. Дайте всем один вопрос решения, одинаковый период наблюдения, дату отсечения и единую форму результата.
2. Сохраните поисковый запрос, но не выдавайте поисковую выдачу за доказательство. Для частоты публикаций открывайте первичную страницу за выбранный период; для рекламы — официальную библиотеку объявлений, если она доступна; для цены и условий — актуальную страницу предложения.
3. Для каждого наблюдения сохраняйте адрес, дату, снимок, вид источника и точное место. Помечайте: увидено непосредственно; заявлено самой компанией; пересказано третьей стороной; рассчитано; предположено.
4. Не заполняйте пробел красивым выводом. Частота публикаций, вовлечённость и наличие платной рекламы остаются неизвестными, если их нельзя подтвердить в сопоставимом периоде.
5. После возврата веток перепроверьте самые важные опоры вручную и сведите расхождения. «Исправить плохой результат» означает вернуться к источнику или ослабить вывод, а не переписать текст увереннее.
6. Завершите ответом на исходный вопрос: какие наблюдения меняют наше решение, что ещё неизвестно, что проверить на собственном продукте и чего не копировать.

Если в пачке есть заявки или другие данные людей

1. До разделения назовите допустимую цель обработки и удалите поля, которые для неё не нужны. Передавайте обезличенные идентификаторы вместо имён, телефонов, адресов и свободных заметок, если они не требуются.
2. Согласуйте разрешённые критерии. Нельзя ранжировать людей или менять сообщение по чувствительным и не относящимся к услуге признакам только потому, что они есть в исходнике.
3. Разделяйте строки один раз по устойчивому ключу и после возврата проверяйте пропуски и дубли между ветками. Число входных строк должно сходиться с обработанными, исключёнными и ошибочными.
4. Используйте одну таксономию и одинаковые правила разметки. Проверьте случайную выборку каждой ветки человеком, а спорные и низкоуверенные случаи вынесите отдельно.
5. Персонализированное письмо не отправляется автоматически после генерации. Человек проверяет основание контакта, адресата, факты, тон, обязательные уведомления и возможность отказаться.
6. Сохраните журнал: источник, цель, версия правил, обработанные идентификаторы, исключения, проверяющий, исправления и факт отправки. Удалите промежуточные данные по утверждённому сроку.

Как свести разные точки зрения в одно решение

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

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

11 · Подключения

Прямой доступ к сервисам: когда оправдан и когда лишний

Инструмент можно подключить к таблицам, базе знаний, аналитике и системе задач. Это уменьшает ручные выгрузки, но создаёт постоянный доступ, который нужно ограничивать, наблюдать и отзывать.

Карточка до подключения

Правило «сначала самый маленький доступ»

1. Начать с одного инструмента и одной полезной задачи.
2. Дать чтение только нужной папки или таблицы.
3. Запретить необратимые действия без подтверждения: публикацию, отправку, удаление, изменение прав, финансовые операции.
4. Не хранить ключи в файлах проекта, документах, скриншотах и переписке — только в защищённом хранилище или переменных окружения.
5. Проверить, кто ещё видит этот секрет, как отозвать доступ и сколько это реально занимает.

Полный порядок безопасного подключения

1. Сначала задача. Назовите повторяющуюся работу, решение и то, почему обычной выгрузки недостаточно.
2. Проверьте поставщика. Используйте официальный сервер или проверенный проект; изучите владельца, исходный код или описание, дату обновления, зависимости, лицензию и известные риски. Для устанавливаемого пакета закрепите проверенную версию, а не скачивайте неизвестную свежую версию при каждом запуске.
3. Определите класс данных. Запишите, будут ли доступны личные данные, договоры, финансы, переписки, исходный код или иные сведения ограниченного доступа. Получите разрешение владельца данных.
4. Выдайте минимальные права. Начните с чтения одного проекта или папки. Разрешение читать не означает разрешение создавать, отправлять, удалять или менять права.
5. Передайте секрет безопасно. Предпочтительны вход через страницу самого сервиса или ссылка на переменную окружения. Никогда не вставляйте токен в чат, снимок экрана, документ, исходный код или общий файл настроек.
6. Ограничьте инструменты. Разрешите только нужные операции; для записывающих и необратимых действий оставьте обязательное подтверждение человеком.
7. Проведите сухую проверку. Сначала запросите один заведомо известный объект только на чтение, сравните с источником и проверьте журнал. Затем испытайте отказ в запрещённом действии.
8. Назначьте эксплуатацию. В карточке должны быть владелец, дата пересмотра, журнал обращений, срок смены секрета, способ отключения, резервная выгрузка и действие при инциденте.
9. Проверьте отключение. Отзовите тестовый доступ и убедитесь, что старый секрет действительно больше не работает. Без этой проверки порядок отзыва существует только на бумаге.

Подключение оправдано, если задача регулярная, доступ законен и соответствует роли, а польза выше стоимости и риска. Для разовой задачи сначала рассмотрите минимальную обезличенную выгрузку; она не автоматически безопасна, но уменьшает постоянную поверхность доступа.

В старых учебных материалах встречается совет прислать токен помощнику, извлечь уже действующий ключ командой и записать секрет прямо в файл настроек. Так делать нельзя: секрет останется в истории диалога, журнале, резервной копии или записи экрана. Не считайте окно подтверждения гарантией безопасности: оно лишь показывает запрашиваемое действие, но не проверяет честность пакета и не исправляет чрезмерные права.

12 · Команда

Приказ «теперь все работают через ИИ» не сработает

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

Короткий цикл внедрения

1. Выбрать одну реальную боль команды. Не самую большую — самую заметную и повторяющуюся.
2. Показать результат «до и после» на своей собственной задаче, включая ограничения и то, что пришлось проверять руками.
3. Дать готовый маленький шаблон или команду — не обучение, а работающий файл.
4. Собрать обратную связь после нескольких применений.
5. Исправить шаблон, назначить владельца — и только потом расширять практику.

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

Первый пилот: задача, обучение и право сообщить о проблеме

1. Объясните причину изменения. Назовите повторяющуюся работу, что в ней мешает сотруднику или клиенту и почему выбран именно ограниченный пилот. Не начинайте с угрозы замены человека или требования пользоваться инструментом ради отчётности.
2. Выберите одну безопасную задачу. Она должна повторяться, иметь известный хороший результат и допускать ручную проверку. Не берите в первый пилот платежи, чувствительные данные, кадровые решения или необратимые внешние действия.
3. Покажите полный пример. Продемонстрируйте вход, формулировку задания, созданный результат, ошибки модели, ручную проверку и окончательную версию. Сотрудник должен видеть не только красивое «после».
4. Зафиксируйте период обучения. Заранее скажите, какие первые попытки не используются для оценки производительности. Ошибку, вопрос и отказ от неподходящего результата в этот период считают данными для улучшения процедуры.
5. Назначьте помощь. Укажите человека, время для вопросов, место инструкции и отдельный канал сообщения об ошибке, утечке данных, несправедливом результате или непонятном требовании.
6. Определите успех до начала. Сравните качество, время полного процесса с проверкой, число исправлений, риск, удобство сотрудника и результат для клиента. Число запусков инструмента само по себе не является успехом.
7. Проведите несколько циклов. После каждого применения сохраните вход, результат, ручные исправления и обратную связь. Процедуру меняет владелец, а утверждённая версия хранится в общем месте под контролем организации.
8. Примите отдельное решение. Расширить, изменить, оставить для узкой задачи или остановить. Обязательное использование допускается только с прозрачными правилами, необходимым обучением, безопасностью, поддержкой и понятными последствиями.

Что хранится общим, а что личным

Общий контекст хранится отдельно от ролевых инструкций. Иначе исправление одного факта о бизнесе потребует менять несколько файлов.

Общая процедура должна иметь владельца и срок жизни

Папка с удачными командами ещё не является командной системой. Каждый общий способ работы принимается как управляемый документ: команда знает, для какой задачи он годится, какие данные ему разрешены, как проверить результат и когда прекратить использование.

1. Перед общим доступом другой сотрудник выполняет процедуру без подсказок автора и проходит все проверочные примеры.
2. Обучение показывает не только команду запуска, но и исходники, типовые ошибки, ручную проверку, запрещённые случаи и место сообщения о проблеме.
3. Роли доступа разделяются: читать утверждённую версию могут исполнители; менять — владелец; разрешать новые данные, сервисы и внешние действия — назначенные ответственные.
4. После каждой ошибки фиксируются вход, версия, последствие, исправление и необходимость повторно проверить прошлые результаты.
5. Устаревшую версию помечают недействующей, убирают из общего доступа, находят личные копии и сообщают, с какого момента её нельзя использовать.

Еженедельная гигиена

• Проверить, что контекст проекта не противоречит последним решениям.
• Взять одну процедуру, которую команда реально использовала, и улучшить по фактическим ошибкам.
• Пересмотреть доступы и убрать ненужные подключения.
• Зафиксировать, где сэкономлено время, а где вывод пришлось отклонить.
• Не измерять успех числом подключённых сервисов. Измерять качеством и скоростью конкретной работы.

13 · План недели

Что сделать по дням, чтобы это не осталось теорией

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

Порядок шагов важнее скорости их прохождения

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

Каждый следующий шаг здесь опирается на рабочий результат предыдущего. Пропуск экономит час и стоит дня, потому что обнаруживается не сразу.

Настройка без применения не считается сделанной

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

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

Начинают с задачи, которая раздражает чаще других

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

Частая и скучная работа — лучший первый случай. Она даёт быстрые повторы, на которых видно, где процедура неточна, и не требует высокой цены ошибки.

Время измеряют целиком, вместе с проверкой

Сравнение по времени генерации всегда даёт выигрыш и ничего не значит. Настоящая стоимость включает подготовку входных данных, проверку и исправления.

Полный замер иногда показывает, что стало дольше. Это полезный результат: он говорит, что задача выбрана неудачно или процедура ещё сырая, — и его нужно сохранить, а не спрятать.

Записывают не только то, что получилось

Отклонённые результаты и ручные исправления — самая ценная часть первого периода: именно из них выводятся правила и границы применения.

Без такой записи через месяц останется общее впечатление «работает» или «не работает», по которому ничего нельзя улучшить. С ней — список конкретных мест, где нужна человеческая проверка.

Расширение — отдельное решение, принимаемое после пробы

Успех на одной задаче легко воспринять как разрешение перевести на новый порядок всё сразу. Дальше несколько незрелых процедур ломаются одновременно, и вывод делается о подходе в целом.

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

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