Transcription
Несколько месяцев назад я написал несколько предложений, около четырех предложений, которые оказались самыми влиятельными четырьмя предложениями, которые я когда-либо писал. Я упаковал эти четыре предложения в навык "Grill me" (Расспроси меня), который представляет собой навык, который вы можете использовать, чтобы заставить LLM неустанно вас опрашивать. Он опрашивает вас до тех пор, пока вы не достигнете общего понимания, проходя по каждой ветви дерева проектирования, разрешая зависимости между решениями одно за другим. Я знаю, что этот навык влиятелен, потому что каждый день я получаю около пяти сообщений от людей, говорящих, что они попробовали его и им он очень нравится. Этот навык — абсолютный прорыв. Какие ваши любимые навыки? "Grill me" — это здорово. Я работаю над проектом. Бла-бла-бла. Навык "Grill me" задает мне вопросы о неоднозначностях. Фантастика. Навык "Grill me" — это топ. Сначала я чувствовал, что он замедляет меня из-за всех вопросов, но после некоторого использования я, честно говоря, думаю, что он может сэкономить время. Вы просто делаете все в один заход после того, как собрали весь контекст, и вы протестировали навык под названием "Grill me", и бла-бла-бла-бла-бла. Это замечательно, замечательно, замечательно, замечательно. И после всей этой похвалы вы можете подумать: "Ну, мне, вероятно, следует придерживаться этого навыка, не так ли? Этот навык звучит довольно хорошо". И оказывается, я на самом деле создал лучший. Я никогда не бываю очень доволен, когда почиваю на лаврах. Я всегда чувствую, что есть возможности для улучшения на каждом этапе моего процесса. И теперь "Grill me" был заменен новым навыком. Давайте откроем сессию, чтобы я мог немного подробнее объяснить, где "Grill me" ошибается. Я собираюсь вставить сюда подсказку, которую я уже добавил. И эта подсказка — идея для новой функции. Я только что продиктовал это. Так что вы будете избавлены от деталей. Но, по сути, я хочу создать новую сущность в моей базе данных и новую сущность, с которой будет работать мое приложение. В настоящее время это приложение работает с курсами, уроками, видео и, знаете ли, разделами и несколькими другими вещами. И я хочу добавить концепцию питчей. Есть такой аксиома в стиле Мистера Биста, где вы должны думать об упаковке для вашего видео, прежде чем фактически прорабатывать, что будет в видео. И это то, что такое питч в такой установке. Питч — это, по сути, просто упаковка для видео, название, описание, как я собираюсь представить его людям. И я создаю кучу этих питчей, а затем выбираю лучшие и превращаю их в видео. Теперь, что вы здесь заметите, когда я общаюсь с агентом, мы действительно фокусируемся на языке, верно? Мы действительно фокусируемся на том, что такое питч. Мне просто пришлось сообщить это вам, чтобы вы могли следить за ходом, и агенту тоже нужно будет извлечь эту информацию из меня. Но здесь также есть некоторый дополнительный жаргон, который агент еще не знает. Например, я говорю о самостоятельных видео. Что означает самостоятельное видео? О, конечно, это означает видео, которое не связано с уроком или курсом. Теперь, конечно, я это знаю. Это своего рода термин, используемый для всего этого набора, но агент этого еще не знает. У него нет никакого понятия о том, что это такое. Поэтому во время сессии расспросов ему придется спросить меня, что такое самостоятельное видео, или попытаться выяснить это из кода. Поэтому, чем больше и больше я использовал "Grill me", я начал замечать моменты, когда агент был очень, очень многословным, и мне приходилось напоминать ему: "Нет, для этого уже есть термин". И часто, хотя термина не было, или я сам думал о вещах очень многословно, и это не оспаривалось агентом, или мы действительно приходили к какому-то очень хорошему общему языку, а затем это нигде не документировалось. Поэтому я начал чувствовать неудовлетворенность "Grill me", потому что из головоломки отсутствовал этот элемент: мы могли довольно эффективно общаться о коде, но мне приходилось заново объяснять все неочевидные вещи о кодовой базе и о предметной области, которую мы решали, прежде чем мы могли сделать что-либо продуктивное. Поэтому я начал думать про себя, какой самый тонкий слой документации я могу использовать, чтобы просто дать ИИ немного больше преимуществ. Так я придумал этот навык, навык "Ubiquitous language" (Единый язык). "Ubiquitous language" — это идея, которая исходит из объектно-ориентированного проектирования (domain driven design). Это большая синяя книга Эрика Эванса, о которой все говорят. И что она делает, это, по сути, вы пытаетесь создать документ, который является языком, используемым кодовой базой, который используется разработчиками, и который используется экспертами предметной области. Другими словами, людьми, которые знают о том, что вы строите, но не как вы это строите. Все эти три группы должны использовать общий язык, потому что это означает, что эксперт предметной области может сказать: "Хорошо, с этим конкретным разделом приложения что-то не так". Разработчик знает, о чем они говорят, и код также отражает это. Поэтому я делал так: в середине сессии расспросов, когда я замечал, что нам нужно уточнить какой-то язык, я использовал навык "Ubiquitous language" и вызывал его с, знаете ли, "ubiquitous language" и пытался создать "ubiquitous language.mmd" по ходу дела. Итак, у меня был "Grill me" и у меня был "Ubiquitous language", и я использовал их оба одновременно. И я понял, разве не здорово было бы, если бы я просто объединил эти два навыка в новый? И вот этот новый навык. Это "Grill with Docs" (Расспроси с документами). Он имеет точно такой же текст, как и "Grill me" вверху, но имеет пару дополнительных частей. Первое, что у него есть, — это возможность искать файл "context.md". И этот файл "context.md" будет документировать весь общий язык, который находится внутри этого контекста. Теперь "context" (контекст) перегружен. Так что я немного неловко, но, возможно, нормально с этим. По сути, это ограниченный контекст в DDD — это часть приложения, в которой вы говорите на общем языке. Так что, если у вас есть огромный монорепозиторий, вы можете иметь здесь карту контекстов и иметь много разных контекстов внутри. Так вы масштабируете это до огромного репозитория. Но все же, если у вас есть один довольно большой репозиторий, где все приложение говорит на одном языке, и эксперты предметной области говорят на одном языке, тогда вы можете просто использовать один "context.md" здесь. Таким образом, он инструктирован искать эту существующую документацию, чтобы извлечь этот общий язык, а затем во время сессии у него есть некоторые дополнительные дополнения здесь, чтобы проверить использование языка против существующего глоссария, чтобы уточнить нечеткий язык, обсудить конкретные сценарии, перекрестно ссылаться с кодом и обновлять его по ходу дела. Таким образом, это, по сути, помогает вам действительно отточить свой язык, когда вы используете навык "Grill with Docs", и это окупается по мере продвижения. Я спрашивал некоторых людей о обратной связи по этому поводу, и я получил несколько очень хороших цитат. Так, этот парень использовал его весь день, и в начале он попросил его определить много терминов. По некоторым терминам было трудно договориться, и те, которые он определенно забыл бы, но через четыре или пять сессий он начал замечать, что Клод улавливал контекст во время сессии расспросов, и это волшебным образом совпало с мыслями, которые у меня были до того, как слова вышли из их мозга. Вот что вы получаете от этого. Документируя неочевидные вещи, соглашаясь на общий язык, вы действительно можете точно определить и достичь магического выравнивания между вами и ИИ, где вам нужно использовать гораздо меньше слов, чтобы передать то, что вы имеете в виду. Например, вот тот, который у меня есть в моем репозитории. У нас есть небольшое описание того, что такое репозиторий. Затем у нас есть курс и репозиторий курса, и у нас есть все сущности внутри, включая версии курса, потому что у меня есть несколько версий. И если мы посмотрим на тот, который мы рассматривали раньше, который является самостоятельным видео, он находится прямо здесь. Итак, у нас есть точная спецификация того, что означает самостоятельное видео. Теперь, теперь навык "Grill with Docs" знает, где искать это. Но я также добавляю указатель контекста не внутри этого "claw.MD", а внутри локального "claw.MD" здесь. Итак, у нас есть просто эти "domain docs", одна компоновка контекста, "context.md" в корне репозитория. И вы видите этот дополнительный маленький кусочек документации для получения дополнительной информации о том, где находятся эти вещи. Последнее, что делает "Grill with Docs", — это то, что есть некоторые вещи, которые помогут уточнить нечеткий язык, но есть и некоторые вещи, которые не помогут. И поэтому я хотел слой, который объяснял бы все неочевидные решения, которые не могли быть зафиксированы в "context.md". И для этого я выбрал запись архитектурного решения (architectural decision record). Эти ADR здесь — это действительно простые файлы Markdown, которые находятся в вашем репозитории и, по сути, документируют все неочевидные решения. Вы хотите создать ADR только тогда, когда решение трудно отменить, потому что если это просто: "О, мы используем эту библиотеку вместо этой библиотеки, и они взаимозаменяемы", то вы всегда можете просто поменять их позже. Это было бы неожиданно без контекста, и множество решений в репозитории неожиданны без контекста, особенно более сложные, и результат реального компромисса. Другими словами, это решение имеет последствия в будущем. И у меня есть формат ADR внутри здесь, который использует LLM при создании этих ADR. Итак, теперь мы понимаем все части. Давайте вернемся сюда. Давайте заменим "Grill me" на "Grill with Docs". И давайте действительно начнем эту сессию расспросов, чтобы увидеть ее в действии. Хорошо. Итак, первое, что он сделал, это сказал, что "context.md" богат. "Standalone video" (самостоятельное видео) уже определено как "lesson" (урок), видео с "lesson ID" = null. И он говорит: "Прежде чем идти дальше, я хочу привлечь внимание к глоссарию". Это то, что вы часто найдете с "Grill with Docs": он действительно фокусируется на языке, прежде чем вы начнете говорить о деталях реализации. Он говорит, что есть кардинальность между "pitch" (питч) и "standalone video". Он спрашивает, содержит ли один питч много самостоятельных видео или один питч соответствует ровно одному самостоятельному видео. Я думаю, что имеет смысл последовать его рекомендации и согласиться: у нас есть отношение один ко многим. Так что я просто скажу "корректно". Очень хорошо. Далее, он замечает, что есть терминологическое столкновение с "standalone video". Так что он говорит, что у вас есть "standalone video", которые либо полностью самостоятельны, либо могут быть связаны с питчами. Так что, я думаю, он, по сути, спрашивает, сохраняем ли мы "standalone video" как любой питч или непитч урока, или мы переопределяем его, чтобы он означал конкретно непитч, не прослушанный видео. Теперь то, как мы ответим на этот вопрос, повлияет на все последующее. Это повлияет на то, будет ли у самостоятельных видео свой раздел в пользовательском интерфейсе, или у нас будут самостоятельные видео и видео с питчами, смешанные вместе, потому что язык, который мы определяем здесь, — это также язык, который пользователь будет видеть на странице, когда он будет перемещаться по этому. И я думаю, я согласен. На самом деле, я собирался с мыслью, что мы, вероятно, будем иметь отдельный раздел для питч-видео, но я думаю, да, я согласен, имеет смысл сохранить питчинг как просто метаданные на самом самостоятельном видео. Это, кстати, "whisper flow". То, что я использую для диктовки. Это работает. Хорошо. Я не уверен, что рекомендую это, но это нормально. Теперь он говорит: "Хорошо, нам нужна некоторая семантика статуса". Так что каждый питч может быть "idle" (бездействующий), "scheduled" (запланированный) или "shipped" (отправленный). Я думаю, я просто хочу разрешить, я думаю, я хочу разрешить свободные переходы. Так что я не очень забочусь о том, чтобы это было автоматизировано. Мы всегда можем добавить автоматизацию позже, знаете ли, когда вы нажимаете "отправить на YouTube" или что-то в этом роде, он переходит в новый статус. Но пока я готов просто переключать его сам. Это нормально. Теперь он спрашивает: может ли питч существовать без видео? Абсолютно, питч может существовать без видео. Суть в том, что мы генерируем идеи для видео. Знаете, это вещь Мистера Биста. Мы пытаемся сначала подготовить упаковку. И это отношение, этот язык также входит в такие конкретные вещи, как каскадные удаления. Так что, я думаю, я скажу "ondelete restrict" (при удалении ограничить). Это в основном потому, что я просто люблю ограничительные удаления, и в основном я архивирую, а не удаляю, когда я на самом деле делаю это. Теперь мы переходим к более деталям реализации. Так что, я думаю, вместо того, чтобы просто скучать вам, на самом деле реализуя сессию расспросов здесь, я просто скажу: "Не могли бы вы сохранить то, что у нас есть, в context.md до сих пор?" Если есть что-то, что мы не выяснили, расспроси меня об этом, прежде чем внести коррективы. И посмотрим, что получится. И хорошо, он внес кучу обновлений в контекст. В частности, он добавил кучу информации о питчах. Итак, у нас есть "pitch", сама сущность. У нас есть "pitch status" (статус питча), статус, в котором может находиться питч. "Pitched standalone video" (питч самостоятельного видео) — это немного неловко. Я, возможно, захочу расспросить его об этом. А затем "unattached standalone video" (неприсоединенное самостоятельное видео). Это тоже как бы, это, по сути, говорит "самостоятельное самостоятельное видео". Имейте в виду, я, возможно, кажусь довольно придирчивым к этому языку. Это может показаться вам просто мелочностью, но это повлияет на каждую часть генерируемого кода. Все имена переменных, все имена файлов будут основаны на этих документах "context.md" здесь. И поэтому правильное определение этого абсолютно критично для ощущения согласованности с ИИ. Теперь, конечно, мы не хотим бесконечно спорить о мелочах. Так что я назову это сейчас. Я скажу, что этого достаточно. Давайте выпустим это. Мы всегда можем изменить и рефакторить на новый язык позже. Итак, давайте быстро поговорим о преимуществах. Что вы на самом деле получаете от прохождения этой церемонии. Первое, что вы получаете, — это лаконичные ответы. ИИ может использовать меньше токенов для общения с вами, потому что у вас есть этот общий язык, и ему не нужно многословно повторять все или переописывать все. Он просто говорит: "Хорошо, самостоятельные видео меняются. Нам нужно было внести изменения в питчи и то, как отображаются питчи". Эта лаконичность также отражается в его собственных следах мышления, потому что, конечно, ИИ использует язык для мышления, и поэтому он может быть гораздо более согласован с вашим намерением и фактически использовать меньше токенов, когда он думает. Это то, что я наблюдал, и это довольно приятно. И, наконец, поскольку планировочные документы, поскольку способ, которым вы говорите с ИИ, также согласован с тем, как выглядит код, тогда вы получаете более легкий для навигации код, потому что вы можете просто: "Хорошо, мне нужно найти всю информацию о питчах. Давайте просто поищем ее". И, конечно, это имеет смысл, потому что это все те же преимущества, описанные в самом объектно-ориентированном проектировании. Так что те же методы, которые работают с людьми, как оказалось, работают и с ИИ. Вы, вероятно, думаете: "Умер ли 'Grill Me'?" Неужели я только что убил "Grill Me"? Неужели его создатель пришел и ударил его ножом в спину? Абсолютно нет. Я думаю, что "Grill Me" — это отличный, отличный навык, но "Grill with Docs" лучше, когда у вас есть кодовая база. В моих навыках я переместил "GrillMe" в область продуктивности здесь. Так что это для общих случаев использования, для случаев использования, когда у вас нет кодовой базы. У меня был кто-то, это самая удивительная история, кто сказал, что они писали некролог для своей мамы, и они использовали "GrillMe", чтобы заставить ИИ расспросить их о их маме и извлечь все эти удивительные истории. И поэтому "Grill Me" имеет невероятные варианты использования за пределами инженерии. И, конечно, если вы находитесь на очень ранней стадии проекта, на самом деле на очень ранней стадии проекта, я бы все равно, вероятно, рекомендовал использовать "Grill with Docs", потому что вы получаете гораздо больше от этого общего языка. И часто в начале проекта вы пытаетесь установить этот общий язык. Так что, по сути, правило такое: когда у вас есть кодовая база, используйте "Grill with Docs". Когда у вас нет кодовой базы, используйте "Grill Me". Я обновляю эти навыки очень, очень регулярно, и я часто думаю о новых идеях относительно навыков или даже о том, как лучше всего их использовать, не меняя сами навыки. Так что я держу всех в курсе этого с помощью моей рассылки "AI skills for real engineers" (Навыки ИИ для настоящих инженеров). Это просто дополнение к уже хорошей рассылке, которая у меня есть, которая дает вам несколько дополнительных обновлений навыков или, возможно, одно в неделю, когда они происходят. Я действительно чертовски ненавижу спам по электронной почте, поэтому я не буду вас спамить, но эта маленькая страница поможет вам оставаться в курсе всех журналов изменений навыков и иметь несколько приятных дополнительных дополнений, которые вы можете просто посмотреть и научиться лучше использовать навыки. В остальном, спасибо за просмотр, и я увижу вас в следующем. Большое вам спасибо за то, что следили за мной. Я очень, очень ценю это. И если вам понравился этот навык, пожалуйста, дайте мне знать в комментариях, как у вас дела, что вы заметили, и поднимите проблему в самом репозитории навыков, если вы думаете, что есть что-то, что я мог бы улучшить.