Comments 5
Спасибо, зашло.
Про ADR - вообще задумался, как жил без этого.
Очень классный материал. Но вопрос, а есть что попроще? Я только начал освоение и проект у меня пробный. Так что в конце сессии, прежде чем перейти в новый чат. Я просто прошу Llm написать контекст и роадмап выполненных работ. Затем в новом окне гружу три дока - план запуска, роадмап и контекст
То, что вы описываете - уже рабочая система. По сути те же принципы: контекст персистентный, структурированный и рядом с чатом. Разница только в масштабе.
Для одного проекта ваш подход вполне достаточен. Пара мыслей, что можно добавить без усложнения:
Фиксировать отвергнутые решения - буквально пара строк в контексте: "рассматривали X, не подошло потому что Y". Это те же ADR, но в минимальной форме. Экономит повторные обсуждения.
Хранить доки в репозитории (хоть в
docs/), а не отдельно — тогда git сохраняет историю, и ничего не потеряется.
Workbench из статьи - это то, во что такой подход естественно вырастает, когда проектов становится несколько и контекст перестаёт помещаться в три документа. Но начинать с трёх документов - абсолютно правильно.
отличная статья! спасибо!
у нас очень схожи мнения по многим пунктам. я разрабатываю archcore.ai - платформу для системного контекста и тоже как раз делаю ставку на документацию причин особняком (adr,rfc). Так же интересными красками начинает играть связывание к примеру правил с adr для агента.
Слепое пятно LLM-разработки: контекст за пределами кода