Организация рабочего пространства

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

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

Что в ней держать

Одна папка, открытая в VS Code как рабочая:

work\
├── AGENTS.md      что ассистент должен знать каждый раз
├── posts\         постпроцессоры, с которыми вы работаете
├── projects\      тестовые проекты CAM и эталонные УП
├── docs\          копия этой документации
└── notes\         ваши практики и разобранные случаи
    └── skills\    ваши собственные навыки — инструкции для ассистента

Имена не важны, важно разделение: исходники отдельно от тестовых данных, ваши знания отдельно от официальной документации.

AGENTS.md — короткая постоянная памятка

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

  • станки и системы ЧПУ, с которыми вы работаете, и какой постпроцессор какой из них обслуживает;
  • соглашения, действующие всегда: нумерация кадров, формат чисел, комментарии, имена файлов;
  • где что лежит: тестовые проекты, эталонные УП, ваши заметки;
  • правила работы — читать фактический CLData до правки кода, запускать постпроцессор и сравнивать с эталоном до любого доклада о готовности, не менять производственный постпроцессор без разрешения;
  • ограничения, которые вы уже однажды сформулировали, — записанные так, как вы их сказали. Ассистент читает их как инструкцию; иначе через месяц он снова предложит идею, которую вы обоснованно отвергли.

Попросите ассистента составить черновик и поправьте его — это быстрее, чем начинать с пустого файла.

notes — где накапливается ваш опыт

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

Полезными эти записи делают две привычки:

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

Когда порядок работы начинает повторяться — одна и та же проверка, одна и та же последовательность для семейства станков, — запишите его как свой навык в notes\skills\ и укажите ассистенту. Публикуемые skills — обычные Markdown-файлы; ваши выглядят так же.

А если такой skill оказался полезен не только у вас, им можно поделиться. Отправка идёт через CAM Agent: откройте его чат и попросите отправить этот skill в общую базу знаний. Он попадёт не сразу в публикуемый набор, а в очередь на рассмотрение, и после того как ревьюер его примет, он станет доступен всем, кто пользуется этими инструментами. Отправляйте только то, что готовы опубликовать: skill, в котором названы заказчики, номера деталей или особенности именно ваших станков, место которому — notes\, и больше нигде.

Задача завершена не тогда, когда постпроцессор заработал, а когда то, что вы выяснили, лежит в notes\.

Документация рядом с исходниками

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

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

Актуальные руководства доступны через центр документации СПРУТКАМ. Для работы ассистента используйте сервер знаний или передайте ему ссылку на нужную статью. Для работы без сети сохраните нужные материалы локально и отметьте их версию и дату.

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

Если описанная в документации деталь противоречит установленному продукту, прав продукт — а заметка об этом идёт в notes\: ровно для такого живая половина и нужна.

Два способа хранить историю

Способ 1. Папки и копии — историю ведёте вы сами

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

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

Способ 2. Git — историю ведёт инструмент

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

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

Что это даёт в этой работе:

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

Учить git для этого не нужно. Просите словами, а делает ассистент:

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

Если git не установлен, попросите ассистента его установить — официальная загрузка на https://git-scm.com/downloads. Попросите заодно подготовить рабочую папку: одна папка под контролем версий, со сформированными УП и временными файлами, исключёнными из неё.

Когда открытой папкой должна быть папка постпроцессора

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

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

  • Укажите памятку один раз в настройках клиента. Чат-расширения читают постоянную памятку в той папке, которую им открыли, и выше не поднимаются, — но её можно назвать явно. В Kilo Code для этого есть глобальная настройка instructions в файле kilo.jsonc (обычно ~/.config/kilo/kilo.jsonc): в ней перечисляются пути к дополнительным файлам инструкций, и они действуют во всех проектах. Пропишите там полный путь к вашему work\AGENTS.md — и он будет прочитан, какую бы папку вы ни открыли.

    Если ваш клиент так не умеет, положите в папку постпроцессора короткий AGENTS.md из двух строк: правила — в ..\..\AGENTS.md, заметки — в ..\..\notes\.

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

Для SPPX ничего этого не требуется: work\ открывается как есть.

Чего в ней быть не должно

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