Transcription
Привет, друзья. Я очень надеялся, что смогу приехать на Всемирную выставку инженеров ИИ, но семейные обстоятельства вмешались, и я не могу этого сделать. Однако я не оставлю вас с пустыми руками. Я собираюсь дать вам доклад, который я бы прочитал в Сан-Франциско. Этот доклад называется "Утерянное руководство". Как писать отличные навыки. И я думаю, что способность отличать хорошие навыки от плохих становится все более важной. Как разработчики, мы, кажется, довольно талантливы в поиске различных форм ада для себя. Несколько лет назад у нас был ад учебных пособий, когда вы проходили кучу учебных пособий, пытаясь что-то выучить, не могли собрать это воедино и просто попадали в этот цикл, из которого не могли выбраться. У нас был ад фреймворков, где каждые 10 минут анонсировался новый JavaScript-фреймворк, и вам приходилось постоянно изучать что-то новое. И теперь, я думаю, у нас есть еще одна версия ада, которая называется ад навыков. Ад навыков — это когда у вас есть все эти свободно доступные навыки, которые вы можете скачать, в которые можете внести свой вклад, которые можете понять самостоятельно, но вы не знаете, как все эти части работают вместе. Вы не можете отличить хороший навык от плохого. И это означает, что люди пытаются собрать эти фреймворки, пытаются попробовать все, что есть, одновременно. И они как бы не могут, или, вернее, не получают результатов, которые обещают сами навыки. Это верно на индивидуальном уровне, но также верно и на организационном уровне. У организаций нет способа или понимания того, как создавать хорошие навыки. Как превратить их операционные процедуры в то, что может делать агент. И если вы этого не сделаете, то будет трудно получить выгоду, которую могут предложить навыки. Просто еще один навык, бро. Похоже, мы это говорим. И я чувствую некоторую вину и здесь, потому что у нас есть навыки Matt PCO, которые являются моим репозиторием навыков, одним из самых популярных наборов инженерных навыков. И поэтому я чувствую, что хочу помочь людям, которые используют мои навыки, выбраться из ада навыков. Так как же нам это сделать? Как нам выбраться из этого? Ну, что здесь на самом деле отсутствует? Ну, на мой взгляд, то, чего нам не хватает, это то, что мы не знаем, что делает навык великим. Мы пока не можем посмотреть на навык и сказать: "Хорошо, этот навык делает эти хорошие вещи и эти плохие вещи". Нет общего критерия, нет структуры для рассмотрения навыка и его улучшения. И вот что я вам дам в этом докладе. Я дам вам чек-лист навыков. Чек-лист вещей, на которые вы можете посмотреть внутри навыка, чтобы убедиться, что он делает то, что говорит, и способы, которыми вы можете его улучшить, способы, которыми вы можете писать навыки. Этот чек-лист выглядит так. Мы начинаем с триггера навыка. Как вызывается навык и какие решения вам нужно принять. Затем внутренняя структура навыка, как навык фактически составлен и организован внутри. Затем номер три — как вы фактически управляете, используя навык? Как вы заставляете навык говорить агенту, что делать? И затем четыре, как сделать навык как можно меньше? Потому что, как только у нас появится рабочий навык, нам нужно будет его максимизировать. Удалить все лишнее, удалить все бесполезные операции. Есть одно удобное преимущество того, что меня нет в комнате с вами, а именно то, что вы можете немедленно попробовать это, потому что я закодировал все это в новый навык в моем репозитории под названием "Написание отличных навыков". Так что, если у вас есть немедленный сценарий использования для этого, просто зайдите в мой репозиторий навыков. Знаете, просто закройте этот браузер, уйдите отсюда и используйте этот навык, чтобы улучшить свои навыки или написать новые отличные. Но давайте начнем с чек-листа. Затем у нас есть номер один, триггер, способ вызова навыка. И чтобы поговорить об этом, я на самом деле проведу небольшое сравнение, а именно то, что мои навыки часто сравнивают с другим набором чрезвычайно популярных инженерных навыков под названием "суперсилы". И меня часто спрашивают: "Как ваши навыки сравниваются с суперсилами? В чем разница между ними?" Чтобы понять это, нам нужно понять разницу между навыками, вызываемыми пользователем, и навыками, вызываемыми моделью. В любое время, когда у вас есть навык, вы всегда можете вызвать его вручную. Таким образом, навык находится на вашей файловой системе. Агент сможет просто открыть навык и понять, что в нем содержится. И вы всегда можете сделать это, сообщив об этом агенту. Это не всегда выглядит как этот слэш, в зависимости от оболочки, но вы всегда можете вызвать свои навыки пользователем. Другой способ вызова навыков — это сам агент. Это называется навыками, вызываемыми моделью, или навыками, вызываемыми моделью. Вы можете взять описание. Таким образом, описание навыка всегда попадает в контекст агента, и агент может посмотреть на него и сказать: "Хорошо, основываясь на этом описании, я вызову навык, и я прочитаю файл skill.md, который является сутью навыка, в свое окно контекста". Вот как вызывается навык. Вот что происходит, когда вызывается навык. Таким образом, это описание служит своего рода указателем контекста. Оно находится в контексте агента, указывая на другой файл, куда агент может перейти, если ему нужен дополнительный контекст для этого указателя контекста. Вам не нужно помещать его в контекст агента. Он может быть просто невидимым для агента. И это то, что мы называем навыком, вызываемым пользователем. Таким образом, некоторые навыки могут быть вызваны только пользователем, потому что у них нет этого указателя контекста. Это необязательно. Например, мы можем увидеть в моем дизайне кодовой базы, что это навык, вызываемый моделью. У него есть описание, которое попадает в окно контекста агента. Но если мы посмотрим на мой навык "grill me" вместо этого, мы увидим, что у него есть disable model invocation true. Это означает, что это маленькое описание будет видно только пользователю. Оно не будет видно агенту. Итак, это совет номер один. Решите, вызывается ли ваш навык пользователем или моделью. Теперь вы можете подумать, что навыки, вызываемые моделью, лучше, верно? Потому что либо модель может вызвать его сама, либо пользователь может вызвать его. Это более гибко. Но каждый раз, когда вы добавляете навык, вызываемый моделью, в среду вашего агента, это увеличивает то, что я буду называть нагрузкой на контекст этого агента, добавляет новое описание, которое стоит вам токенов при каждом запросе, но также добавляет еще одну вещь, о которой агент должен думать. Так что, если у вас есть 100 навыков, вызываемых моделью, это будет 100 описаний в контексте вашего агента. Поэтому кажется разумным либо уменьшить количество навыков, вызываемых моделью, либо просто использовать все навыки, вызываемые пользователем. Но навыки, вызываемые пользователем, имеют другую нагрузку, а именно: чем больше навыков, вызываемых пользователем, тем выше когнитивная нагрузка на пользователя. Другими словами, чем больше вещей пользователю нужно держать в голове, тем больше навыков требуется от пилота. И поэтому, если мы сравним навыки Matt Pot с суперсилами, суперсилы — это в основном навыки, вызываемые моделью. Дает агенту суперсилы. В то время как мои навыки, я предпочитаю полный контроль. Это означает, что я могу свести нагрузку на контекст агента к минимуму, но это накладывает на меня большую когнитивную нагрузку. Поэтому мне нужно глубоко понимать навыки, чтобы получить от них максимальную пользу. Так почему я это сделал? Почему я предпочел навыки, вызываемые пользователем? Ну, каждый раз, когда у вас есть навык, вызываемый моделью, вы получаете стоимость в непредсказуемости, потому что каждый раз, когда есть указатель контекста, указывающий с одного ресурса на другой, модель может просто не следовать ему. Знаете, даже если это идеально подходит для задачи, она может просто не вызвать навык. Я предпочитаю устранить этот уровень непредсказуемости, наложив на пользователя немного большую когнитивную нагрузку. И то, что вы получаете, это просто вы устраняете класс проблем, даже не делая их проблемой, потому что эта непредсказуемость заставляет людей оценивать свои навыки, чтобы убедиться, что они вызываются в нужное время, что действительно неприятно, и это проблема, которую я предпочитаю избегать. Но я надеюсь показать вам здесь, что навыки, вызываемые моделью, и навыки, вызываемые пользователем, имеют одинаковые затраты. Так что это не легкое решение, какой из них выбрать. Итак, это триггер, как вызывается навык. Теперь давайте поговорим о структуре. Внутренняя организация навыка. Я думаю, что в большинстве навыков есть две основные единицы, которые вам нужно поместить. Эти две единицы — это шаги и ссылка. Шаги — это пошаговая процедура, через которую будет проходить навык. А ссылка — это любая вспомогательная информация, которая помогает ему пройти эти шаги. У вас могут быть навыки без шагов, только со ссылкой. И у вас могут быть навыки без ссылки, только набор простых шагов для выполнения. Но если вы начнете рассматривать навыки как состоящие из этих двух единиц, это действительно поможет разбить их гораздо больше. Если мы посмотрим на пример, один из моих навыков под названием "two PRD" создает документ с требованиями к продукту из текущего окна контекста. В нем три шага. Он находит соответствующий контекст. Он подтверждает тестовые швы с пользователем. Так что есть небольшой человеческий контроль, чтобы убедиться, что мы не делаем ничего странного с тестированием, что я считаю очень важным. И затем мы пишем документ с требованиями к продукту, чтобы обработать эти три шага. У нас есть два фрагмента справочного материала. У нас есть немного справочной информации о том, что такое тестовый шов. И затем у нас есть шаблон документа с требованиями к продукту. Так что это просто буквальный шаблон markdown, который используется для написания PRD. Так что это отличный способ написать навык с нуля. Вы выясняете, нужны ли вам какие-то шаги. Затем вы пишете эти шаги и выясняете, какой справочный материал нужен этим шагам, и помещаете его в отдельное небольшое место в навыке, которое предназначено для справочного материала. Однако есть действительно важное ограничение, о котором нам нужно подумать, а именно совет номер три. Мы хотим сделать основной файл skill.md как можно меньше. Каждый навык состоит из его описания, а затем файла skill.md, а затем любого справочного материала, который ответвляется от него. И этот файл skill.md, если мы сделаем его маленьким, мы сэкономим по-разному. Меньшие навыки просто легче поддерживать, легче проверять, меньше слов для обдумывания. И каждый раз, когда вы убираете слово, это токен, который вы убираете. Множественное сокращение токенов из стоимости ваших навыков. Поэтому я считаю, что маленькие навыки очень важны как для сопровождающих, так и для пользователей. Один действительно полезный способ сделать ваш навык меньше — это подумать о различных ветвях навыка, различных способах использования навыка. Потому что, если у вас есть справочный материал, который используется только в одной ветви, то это кандидат на удаление из основного skill.md. Например, если мы посмотрим на мой "two PRD", у нас есть два элемента справочного материала. Что такое тестовый шов и шаблон PRD. Ну, нам нужен шаблон PRD каждый раз, потому что мы всегда создаем PRD. И нам, вероятно, также нужна информация "что такое тестовый шов" каждый раз, потому что мы всегда спрашиваем о тестовых швах. Так что в 2P есть только одна ветвь, и весь справочный материал принадлежит этой ветви. Так что, вероятно, он также принадлежит файлу skill.md. Однако, если мы посмотрим на другой мой навык, который называется "моделирование предметной области", моделирование предметной области делает две вещи. Он обновляет локальный глоссарий под названием context.md, а затем также создает записи о архитектурных решениях. Другими словами, он делает две разные вещи. Или он может выбрать не делать ни того, ни другого, в этом случае ему не нужен шаблон, и ему не нужен шаблон ADR. Другими словами, моделирование предметной области имеет две или, возможно, три ветви. И это означает, что нам не нужно включать шаблон ADR или шаблон context.md в основной навык. Их можно переместить в отдельные зоны. Способ сделать это — иметь файл skill.md. Затем поместить его за указатель контекста и направить шаблон контекста на отдельный файл markdown в папке навыков. Этот указатель контекста буквально говорит: если вам нужен шаблон или если вам нужно обновить файл context.md, перейдите к этому файлу. И я называю это внешним справочным материалом. Это справочный материал, который находится вне skill.md, на который вы можете легко ссылаться. Агент может легко получить его, потому что он упакован вместе с навыком. Так что это техника, которую вы можете использовать для того, чтобы сделать skill.md как можно меньше, что имеет так много преимуществ. Скрывайте ветвящийся справочный материал за указателями контекста. Другими словами, если вы чувствуете, что ваш навык будет использоваться по-разному, то возьмите справочный материал, который относится к этим ветвям, и спрячьте его за указателями контекста. Итак, это структура. Нам нужно подумать о том, чтобы сделать skill.md супер-пупер маленьким. Нам нужно подумать о ветвях в нашем навыке, перемещая материал за указатели контекста. И нам нужно подумать о шагах и справочном материале, которые являются двумя основными единицами внутри навыка. Давайте перейдем к управлению, фактическим способам заставить агента делать то, что мы хотим. И для меня управление сводится к одной действительно классной технике, которая является основной вещью, которую я хочу, чтобы вы получили из этого доклада. Эта техника решает эту проблему: агент не делает того, что я хочу. Другими словами, я указываю что-то в навыке. Я думаю, что я был ясен, а затем он просто не делает этого. Теперь я думаю, что основная причина этого в том, что вы не используете технику, называемую ведущими словами. Идея ведущих слов или, если хотите, литературной теории, я полагаю, заключается в том, что существуют определенные слова, которые несут в себе много смысла в очень маленьком пространстве. Эти ведущие слова действительно мощны с агентами, потому что вы помещаете ведущее слово в сам навык, в текст, а затем агент будет повторять это ведущее слово себе как часть своих операций, как часть своих мыслительных токенов и как часть своего вывода вам. И затем, поскольку он вновь подчеркивает это слово, и это слово, надеюсь, описывает то, что вы хотите от агента, это затем меняет его поведение. Давайте сделаем это более конкретным на примере. Давайте представим, что у нас есть проблема, которая является классической проблемой с агентами, а именно то, что они кодируют слой за слоем. Другими словами, если вы дадите им большой объем работы, они, как правило, будут кодировать весь слой базы данных, затем все схемы, затем все конечные точки API, затем весь фронтенд. они не делают типичную человеческую вещь — искать обратную связь на раннем этапе, добиваться работы чего-то маленького, а затем расширяться оттуда. Теперь мы можем попытаться побудить агента делать это, просто сказав: "Не кодируйте слой за слоем". Убедитесь, что вы сначала создаете небольшой срез, а затем двигаетесь дальше. Но что, если вместо этого мы использовали ведущее слово? Мы сказали, что "вертикальный срез" — это наше ведущее слово. Мы хотим нарезать работу вместо горизонтальных срезов на вертикальные срезы. Вертикальный срез — это довольно известная терминология в разработке. И поэтому это, надеюсь, вызовет предыдущий опыт агента, и он поймет, что мы имеем в виду. Нам не обязательно иметь навык из двух слов, который просто говорит "вертикальный срез". Что мы делаем, так это упаковываем много смысла в относительно короткую фразу, которую мы затем повторяем во всем навыке. Крутость этой техники в том, что вы можете узнать, сработала ли она, потому что вы говорите "вертикальный срез" в своем навыке, а затем вы заметите в трассировках рассуждений, что он говорит: "Хорошо, мы сделаем это как тонкий вертикальный срез". Тогда вы должны получить лучшие планы реализации. Все, кому я объяснил эту технику, как бы говорят: "О, да, я делаю это уже давно. Я использую эти маленькие фразы, чтобы попытаться побудить агента делать то, что я хочу". Все, о чем я вас сейчас прошу, это использовать их последовательно в ваших навыках и наблюдать в трассировках мышления, как агент принимает ваш способ делать это. Так часто, если агент не делает того, что вы хотите, вам нужно сделать ваши ведущие слова более последовательными, более мощными и искать другие, потому что, знаете ли, английский язык — это довольно широкий API с точки зрения различных функций, которые вы можете вызывать, различных вещей, с которыми вы можете экспериментировать, и существует множество кандидатов на ведущие слова, и агенты на самом деле довольно хороши в том, чтобы помочь вам думать о них. Еще один маленький рычаг, который вы можете использовать с агентами, — это иногда агент просто не делает достаточно работы. Что я имею в виду под этим, так это то, что хорошо, мы находимся на шаге, скажем, и, возможно, шаг — задавать уточняющие вопросы или исследовать кодовую базу, а агент просто не делает этого достаточно. Он не прилагает достаточно усилий к этому конкретному шагу. Классический случай этого и то, что я нашел почти везде, где он существует, — это режим планирования. Потому что в режиме планирования у нас есть два шага. У нас есть "задать уточняющие вопросы", а затем "создать план". И то, что я обнаружил в каждой реализации режима планирования, которую я пробовал, это то, что "задать уточняющие вопросы" просто, знаете ли, никогда не делает достаточно работы. Он видит, что его конечная цель — создать план. И поэтому он просто делает небольшое количество работы с "задать уточняющие вопросы", задает вам пару вопросов, а затем с энтузиазмом создает план. Так каким было мое решение здесь? Вместо того, чтобы использовать режим планирования, я вместо этого имею навык под названием "grill with docs", который является своего рода моей фазой "задать уточняющие вопросы". А затем я разделил это на отдельный навык. Таким образом, я разделил планирование на свой собственный навык. Таким образом, "grill with docs" теперь является отдельным навыком, где агент видит только эту часть процесса. А затем, после завершения "grill with docs", мы переходим к "two PRD". Другими словами, у нас есть шаг один и шаг два, но агент видит только один шаг за раз. Так что это действительно классная техника для увеличения объема работы на шаге, который вы выполняете, скрывая будущую цель, скрывая будущие шаги. Не всегда необходимо разбивать навыки на отдельные шаги, но в частности, когда вам действительно нужен дополнительный объем работы. Действительно нет никакой другой техники, подобной ей. Она работает очень, очень хорошо. Итак, это управление. Использование ведущих слов для захвата того, что вы хотите, в небольшие многоразовые токены, а затем обеспечение того, чтобы он выполнял правильный объем работы на каждом шаге. Давайте теперь перейдем к обрезке. Обрезка — это на самом деле просто быстрая серия сбоев, различных вещей, которые вы можете сделать неправильно. И первое довольно очевидно: мы не хотим массивных навыков. Массивные навыки обычно являются своего рода симптомом чего-то другого, что идет не так. Так что это симптом одного из этих других сбоев. И первое довольно простое: не повторяйтесь. Вам нужно убедиться, что вы следите за дублированием. И в целом, я люблю, чтобы каждая часть навыка имела единственный источник истины. Другими словами, если у вас есть фрагмент справочного материала, такой как шаблон PRD, скажем, или что-то еще более мелкое, такое как "что такое тестовый шов", вы убеждаетесь, что вы не повторяете это в нескольких местах или не охватываете несколько шагов в нескольких местах. Просто убедитесь, что каждая часть имеет единственный источник истины, и вы не повторяетесь даже в справочном материале. Следующий способ, которым навыки становятся большими, — это отложения. И отложения — это просто классическая вещь, когда люди работают над одним и тем же набором документов, а именно: каждый начинает вносить свой вклад в общий файл markdown. Люди добавляют свое. Они не чувствуют себя достаточно смелыми, чтобы удалять и изменять что-то чужое. И поэтому у вас просто получается огромное количество отложений, часто с нерелевантным материалом для навыка, особенно с тем, что не было должным образом оформлено. При наличии навыка с большим количеством отложений вам действительно нужно посмотреть на структуру. Это первое, что вам нужно сделать. Вам нужно убедиться, что добавленный материал актуален для всех ветвей. Если нет, то переместите его в соответствующие ветви. Или, если он просто совершенно нерелевантен, возможно, просто удалите его или уничтожьте. Или, возможно, там есть что-то совершенно устаревшее, в этом случае вам просто нужно уничтожить это. Следующий сбой очень распространен, когда агент пишет ваши навыки, а именно бесполезные операции. Так что это вещи внутри навыка, которые, кажется, что-то делают, но на самом деле не влияют на поведение агента в контексте навыка. Давайте представим, что у нас есть навык реализации, и у нас есть целый абзац навыка, который говорит агенту написать длинное подробное сообщение коммита. Что произойдет, если вы просто удалите этот абзац? Ну, агент, вероятно, все равно напишет приличное, длинное сообщение коммита. Люди часто спрашивают меня, как мне удается делать мои навыки такими маленькими, и это просто использование этих техник, использование тестов на удаление, использование убеждения, что я сжимаю вещи в ведущие слова, у меня нет ничего лишнего, и у меня нет отложений. И это наконец приводит нас к полному обзору всего. Номер один, мы проверяем триггер. Мы убеждаемся, что он срабатывает в нужное время. Мы проверяем, накладываем ли мы нагрузку на контекст или когнитивную нагрузку. Со структурой мы думаем о ветвях. Мы думаем о структурировании вещей в шаги и ссылки, и мы убеждаемся, что материал, который актуален только для одной ветви, находится вне основного skill.mmd. Для управления мы думаем о сжатии текста в ведущие слова и наблюдении за тем, как эти ведущие слова появляются в трассировках рассуждений. И мы также думаем о работе. Следует ли нам разбить этот навык дальше, чтобы увеличить его фокусировку на текущей фазе, скрыв от него будущую фазу? И при обрезке мы проводим финальный проход по всему навыку, следя за отложениями, следя за хламом и особенно следя за бесполезными операциями. Теперь, все это, лучший способ начать работать с этой структурой — это внутри этого навыка, внутри навыка "написание отличных навыков". Вы можете скачать его из map. Got skills, скачать его, использовать его для улучшения своих собственных навыков и, возможно, даже использовать его для проверки некоторых навыков, написанных сообществом, чтобы вы могли проверить, хороши ли навыки, которые вы на самом деле используете. Если вы хотите следить за моими материалами, то у меня есть рассылка на aihero.dev. И мои планы на ближайшие несколько месяцев — выпустить интенсивный курс по ИИ-кодированию, который является введением во многие вещи, о которых я говорил, и о том, как начать работать с инженерией и ИИ. Я надеюсь, что того, что я вам дал, будет достаточно, чтобы помочь вам выбраться из ада навыков, или, по крайней мере, попытаться сделать горькое путешествие оттуда. Мне очень жаль, что я не могу присутствовать лично, но спасибо за просмотр. Увидимся очень скоро.