Комментарии 6
Интересные способы организации файлов спецификаций, передачи контекста между сессиями и между задачами, сборки контекста под задачу.
Спасибо, интересно, попробую.
Мои основные задачи заключаются в анализе данных и обучении нейронных сетей (не LLM, поменьше), т.е. data science.
Хотелось бы примеров из этой области. Но все руководства, что мне встречались, ограничены задачами типа "добавить кнопку likeина сайт".
Про трекинг ml-кода и экспериментов ни слова
Спасибо! HDD для ML-работы отлично подходит. Разве что трекинг самих экспериментов продоложать через MLflow/W&B/DVC, тут HDD не поможет. HDD он для меты над ними: «что мы хотели, что получилось, что мы из этого поняли и что решили». Тогда трек - это серия экспериментов под гипотезу. Handoff трека — это lab notebook: что прогнали, что осталось, какие направления закрыты, как тупиковые. as-built = текущий пайплайн данных: препроцессинг, фичи, сплиты — как оно реально в коде. log/ADR = «почему такая метрика», «почему такой сплит» — решения, которые через полгода иначе восстанавливаются археологией, а она в ML очень тяжёлая.
Да-да-да. В последнее время я агента терзаю одним и тем же промптом, даже в команду его оформил.
"Посмотри результаты тестов в .csv, код в .py, гиперпараметры возьми из mlflow через подключенный mcp. Сопоставь гиперы и метрики, найди, что оказало наибольшее влияние и предложи варианты улучшения метоик"
Нужно ли specs объединить с docs/specs которые генерируются brainstorming скилом?
С одной стороны как хотите, система спецификаций гибкая и адаптивная. Но с другой стороны, можно этот /docs/specs объявить подпроектом, положить туда spec-brainstorm.md, дать ссылку на этот документ в корневую спеку и сказать, что там живёт brainstorm. Можно делать треки по этому подпроекту brainstorm. Только надо учесть, что спеки brainstorm генерируются и надо сказать Опусу, чтобы тот обновлят трек и спеку после генерации

Handoff-driven development