Transcription
Привет, друзья. Я очень надеялся, что смогу приехать на Всемирную выставку инженеров ИИ, но семейные обстоятельства вмешались, и я не могу этого сделать. Однако я не оставлю вас с пустыми руками. Я собираюсь дать вам доклад, который я бы прочитал в Сан-Франциско. Этот доклад называется "Утерянное руководство". Как писать отличные навыки. И я думаю, что способность отличать хорошие навыки от плохих становится только важнее. Как разработчики, мы, кажется, довольно талантливы в поиске различных форм ада, куда мы можем отправиться. Несколько лет назад у нас был ад туториалов, когда вы проходили кучу туториалов, пытаясь что-то выучить, не могли собрать это воедино и просто попадали в цикл, из которого не могли выбраться. У нас был ад фреймворков, когда каждые 10 минут анонсировался новый JavaScript-фреймворк, и вам приходилось постоянно изучать что-то новое. И теперь, я думаю, у нас есть еще одна версия ада, которая называется ад навыков. Ад навыков — это когда у вас есть все эти навыки, свободно доступные, которые вы можете скачать, в которые можете внести свой вклад, которые можете понять самостоятельно, но вы на самом деле не знаете, как все эти части работают вместе. Вы не можете отличить хороший навык от плохого. И это означает, что люди пытаются собрать эти фреймворки, пытаются попробовать все, что есть, одновременно. И у них это не получается, или, вернее, они не получают результатов, которые обещают сами навыки. Это верно на индивидуальном уровне, но также верно и на организационном уровне. Организации не знают, как создавать хорошие навыки. Как превратить свои операционные процедуры в то, что может делать агент. И если вы этого не сделаете, то будет трудно получить ту выгоду, которую могут предложить навыки. Просто еще один навык, братан. Это как будто мы говорим. И я чувствую здесь некоторую вину, потому что у нас есть навыки Мэтта Пико, которые являются моим репозиторием навыков, одним из самых популярных наборов инженерных навыков. И поэтому я чувствую, что хочу помочь людям, которые используют мои навыки, выбраться из ада навыков. Так как же нам это сделать? Как нам выбраться из этого? Ну, что здесь на самом деле отсутствует? Ну, на мой взгляд, то, чего нам не хватает, это то, что мы не знаем, что делает навык великим. Мы пока не можем посмотреть на навык и сказать: "Хорошо, этот навык делает эти хорошие вещи и эти плохие вещи". Нет общего критерия, нет структуры для рассмотрения навыка и его улучшения. И именно это я собираюсь вам дать в этом докладе. Я дам вам чек-лист навыков. Чек-лист вещей, на которые вы можете посмотреть внутри навыка, чтобы убедиться, что он делает то, что заявлено, и способы, которыми вы можете его улучшить, способы, которыми вы можете писать навыки. Этот чек-лист выглядит так. Мы начинаем с триггера навыка. Как навык вызывается и какие решения вам нужно там разработать. Затем внутренняя структура навыка, как навык фактически составлен и организован внутри. Затем номер три — как вы фактически управляете, используя навык? Как вы заставляете навык говорить агенту, что делать? И затем четыре — как сделать навык как можно меньше? Потому что, как только у нас появится работающий навык, нам нужно будет его максимизировать. Удалить все лишнее, удалить все бездействующие операции. Есть одно удобное преимущество того, что меня нет в комнате с вами, а именно то, что вы можете немедленно попробовать это, потому что я закодировал все это в новый навык в моем репозитории под названием "Написание отличных навыков". Так что, если у вас есть немедленный сценарий использования для этого, просто зайдите в мой репозиторий навыков. Знаете, просто закройте этот браузер, уйдите отсюда и используйте этот навык, чтобы либо улучшить свои навыки, либо написать отличные новые. Но давайте начнем с чек-листа. Затем у нас есть номер один, триггер, способ вызова навыка. И чтобы поговорить об этом, я на самом деле сделаю небольшое сравнение, а именно то, что мои навыки часто сравнивают с другим набором чрезвычайно популярных инженерных навыков под названием "суперсилы". И меня часто спрашивают: "Как ваши навыки соотносятся с суперсилами? В чем разница между ними?" Чтобы понять это, нам нужно понять разницу между навыками, вызываемыми пользователем, и навыками, вызываемыми моделью. В любое время, когда у вас есть навык, вы всегда можете вызвать его вручную. Таким образом, навык находится на вашей файловой системе. Агент сможет просто открыть навык и понять, что в нем содержится. И вы всегда можете сделать это, сообщив об этом агенту. Это не всегда выглядит как этот слэш, в зависимости от оболочки, но вы всегда можете вызвать свои навыки пользователем. Другой способ вызова навыков — самим агентом. Это называется навыками, вызываемыми моделью, или навыками, вызываемыми моделью. Вы можете взять описание. Таким образом, описание навыка всегда попадает в контекст агента, и агент может посмотреть на него и сказать: "Хорошо, на основе этого описания я вызову навык, и я прочитаю файл skill.md, который является сутью навыка, в мое контекстное окно". Вот как вызывается навык. Вот что происходит, когда навык вызывается. Таким образом, это описание служит своего рода указателем контекста. Оно находится в контексте агента, указывая на другой файл, куда агент может перейти, если ему нужен дополнительный контекст для этого указателя контекста. Вам не нужно помещать его в контекст агента. Он может быть просто невидимым для агента. И это то, что мы называем навыком, вызываемым пользователем. Таким образом, некоторые навыки могут быть вызваны только пользователем, потому что у них нет этого указателя контекста. Это необязательно. Например, мы можем увидеть в дизайне моей кодовой базы, что это навык, вызываемый моделью. У него есть описание, которое попадает в контекстное окно агента. Но если мы посмотрим на мой навык "Grill me" вместо этого, мы увидим, что у него есть disable model invocation true. Это означает, что это маленькое описание будет видно только пользователю. Оно не будет видно агенту. Итак, это совет номер один. Решите, вызывается ли ваш навык пользователем или моделью. Теперь вы можете подумать, что навыки, вызываемые моделью, лучше, верно? Потому что либо модель может вызвать его сама, либо пользователь может вызвать его. Это более гибко. Но каждый раз, когда вы добавляете навык, вызываемый моделью, в среду вашего агента, это увеличивает то, что я буду называть нагрузкой на контекст этого агента, добавляет новое описание, которое стоит вам токенов при каждом запросе, но также добавляет еще одну вещь, о которой агент должен думать. Так что, если у вас есть 100 навыков, вызываемых моделью, это будет 100 описаний в контексте вашего агента. Поэтому кажется разумным либо уменьшить количество навыков, вызываемых моделью, либо просто использовать все навыки, вызываемые пользователем. Но навыки, вызываемые пользователем, имеют другую нагрузку, которая заключается в том, что чем больше навыков, вызываемых пользователем, тем выше когнитивная нагрузка на пользователя. Другими словами, чем больше вещей пользователю нужно держать в голове, тем больше... навыка требуется от пилота. И поэтому, если мы сравним навыки Мэтта Пот с суперсилами, суперсилы — это в основном навыки, вызываемые моделью. Дает агенту суперсилы. В то время как мои навыки, я предпочитаю полный контроль. Это означает, что я могу свести нагрузку на контекст агента к минимуму, но это накладывает на меня большую когнитивную нагрузку. Так что мне нужно глубоко понимать навыки, чтобы получить от них максимальную пользу. Так почему я это сделал? Почему я предпочел навыки, вызываемые пользователем? Ну, каждый раз, когда у вас есть навык, вызываемый моделью, вы получаете стоимость в непредсказуемости, потому что каждый раз, когда есть указатель контекста, указывающий с одного ресурса на другой, модель может просто решить не следовать ему. Знаете, даже если это идеально подходит для задачи, она может просто решить не вызывать навык. Я гораздо больше предпочитаю устранять этот уровень непредсказуемости, накладывая немного больше когнитивной нагрузки на пользователя. И то, что вы получаете, это просто... вы устраняете класс проблем, даже не делая их проблемой, потому что эта непредсказуемость заставляет людей оценивать свои навыки, чтобы убедиться, что они вызываются в нужное время, что действительно неприятно, и это проблема, которую я предпочитаю избегать. Но я надеюсь показать вам здесь, что навыки, вызываемые моделью, и навыки, вызываемые пользователем, имеют одинаковую стоимость. Так что это не легкое решение, какой из них выбрать. Итак, это триггер, как вызывается навык. Теперь давайте поговорим о структуре. Внутренняя организация навыка. Я думаю, что в большинстве навыков есть два основных блока, которые вам нужно поместить. Эти два блока — это шаги и ссылка. Шаги — это пошаговая процедура, которую навык будет выполнять. А ссылка — это любая вспомогательная информация, которая помогает ему выполнять эти шаги. У вас могут быть навыки без шагов, только со ссылкой. И у вас могут быть навыки без ссылки, только набор простых шагов для выполнения. Но если вы начнете рассматривать навыки как состоящие из этих двух блоков, это действительно поможет разбить их гораздо больше. Если мы посмотрим на пример, один из моих навыков под названием "два PRD" создает документ с требованиями к продукту из текущего контекстного окна. В нем три шага. Таким образом, он находит соответствующий контекст. Он подтверждает тестовые швы с пользователем. Так что есть небольшой человеческий контроль, чтобы убедиться, что мы не делаем ничего странного с тестированием, что я считаю очень важным. И затем мы пишем документ с требованиями к продукту, чтобы обработать эти три шага. У нас есть два фрагмента справочного материала. У нас есть немного справочной информации о том, что такое тестовый шов. И затем у нас есть шаблон документа с требованиями к продукту. Так что это просто буквальный шаблон markdown, который используется для написания PRD. Так что это отличный способ написать навык с нуля. Вы выясняете, нужны ли вам какие-либо шаги. Затем вы пишете эти шаги и выясняете, какой справочный материал нужен этим шагам, и помещаете его в отдельное небольшое место в навыке, которое предназначено для справочного материала. Однако есть действительно важное ограничение, о котором нам нужно подумать, а именно совет номер три. Мы хотим сделать основной файл skill.md как можно меньше. Каждый навык состоит из его описания, а затем файла skill.md, а затем любого справочного материала, который отходит от него. И этот файл skill.md, если мы сделаем его маленьким, мы сэкономим разными способами. Меньшие навыки просто легче поддерживать, легче проверять, меньше слов для обдумывания. И каждый раз, когда вы убираете слово, это токен, который вы убираете. Множество убранных токенов из стоимости ваших навыков. Поэтому я считаю, что маленькие навыки очень важны как для сопровождающих, так и для пользователей. Один действительно полезный способ сделать ваш навык меньше — это подумать о различных ветвях навыка, различных способах использования навыка. Потому что, если у вас есть справочный материал, который используется только в одной ветви, то это кандидат на удаление из основного skill.md. Например, если мы посмотрим на мои "два PRD", у нас есть два фрагмента справочного материала. Что такое тестовый шов и шаблон PRD. Ну, нам нужен шаблон PRD каждый раз, потому что мы всегда создаем PRD. И нам, вероятно, также нужна информация "что такое тестовый шов" каждый раз, потому что мы всегда спрашиваем о тестовых швах. Так что в "два PRD" есть только одна ветвь, и весь справочный материал относится к этой ветви. Так что, вероятно, он также должен быть в файле 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", мы переходим к "два PRD". Другими словами, у нас есть шаг один и шаг два, но агент видит только один шаг за раз. Так что это действительно классная техника для увеличения объема работы на шаге, который вы выполняете, скрывая будущую цель, скрывая будущие шаги. Не всегда необходимо разбивать навыки на отдельные шаги, но в конкретных случаях, когда вам действительно нужен дополнительный объем работы. Действительно, нет ничего подобного. Это работает очень, очень хорошо. Итак, это управление. Использование ведущих слов для захвата того, что вы хотите, в маленькие многоразовые токены, а затем обеспечение того, чтобы он выполнял правильный объем работы за шаг. Давайте теперь перейдем к обрезке. Обрезка — это на самом деле просто быстрая серия сбоев, различных вещей, которые вы можете сделать неправильно. И первое довольно очевидно: мы не хотим массивных навыков. Массивные навыки обычно являются своего рода симптомом чего-то другого, что идет не так. Так что это симптом одного из этих других сбоев. И первое довольно простое: не повторяйтесь. Вам нужно убедиться, что вы следите за дублированием. И в целом, я люблю, чтобы каждая часть навыка имела единственный источник истины. Другими словами, если у вас есть фрагмент справочного материала, такой как шаблон PRD, скажем, или что-то еще меньше, такое как "что такое тестовый шов", вы убедитесь, что вы не повторяете это в нескольких местах или не охватываете несколько шагов в нескольких местах. Просто убедитесь, что каждая часть имеет единственный источник истины, и вы не повторяетесь даже в справочном материале. Следующий способ, которым навыки становятся большими, — это отложения. И отложения — это просто классическая вещь, когда люди работают над одним и тем же набором документов, а именно: каждый начинает вносить свой вклад в общий файл markdown. Люди добавляют свое. Они не чувствуют себя достаточно смелыми, чтобы удалять или изменять чужое. И поэтому у вас просто получается огромное количество отложений, часто с нерелевантным материалом для навыка, особенно с тем, что не было должным образом изложено. При наличии навыка с большим количеством отложений вам действительно нужно посмотреть на структуру. Это первое, что вам нужно сделать. Вам нужно убедиться, что добавленный материал актуален для всех ветвей. Если нет, то переместите его в соответствующие ветви. Или, если он просто совершенно нерелевантен, возможно, просто удалите его или уничтожьте. Или, возможно, там есть что-то совершенно устаревшее, в этом случае вам просто нужно уничтожить это. Следующий сбой очень распространен, когда агент пишет ваши навыки, а именно бездействующие операции. То есть вещи внутри навыка, которые, кажется, что-то делают, но на самом деле не влияют на поведение агента в контексте навыка. Давайте представим, что у нас есть навык реализации, и у нас есть целый абзац навыка, который говорит агенту написать длинное подробное сообщение коммита. Что произойдет, если вы просто удалите этот абзац? Ну, агент, вероятно, все равно напишет приличное, длинное сообщение коммита. Люди часто спрашивают меня, как мне удается делать мои навыки такими маленькими, и это просто использование этих техник, использование тестов на удаление, использование... убедитесь, что я сжимаю вещи в ведущие слова, у меня нет ничего лишнего, и у меня нет отложений. И это наконец приводит нас к полному обзору всего. Номер один, мы проверяем триггер. Мы убеждаемся, что он срабатывает в нужное время. Мы проверяем, накладываем ли мы нагрузку на контекст или когнитивную нагрузку. Со структурой мы думаем о ветвях. Мы думаем о... структурировании вещей на шаги и справочный материал, и мы убеждаемся, что... материал, который актуален только для одной ветви, находится вне основного skill.mmd. Для управления мы думаем о сжатии текста в ведущие слова и наблюдении за тем, как эти ведущие слова появляются в трассировках рассуждений. И мы также думаем о объеме работы. Следует ли нам разбить этот навык дальше, чтобы увеличить его фокусировку на текущей фазе, скрыв от него будущую фазу? И при обрезке мы проводим финальный проход по всему навыку, следя за отложениями, следя за хламом и особенно следя за бездействующими операциями. Теперь, все это, лучший способ начать работать с этой структурой — это внутри этого навыка, внутри навыка "написание отличных навыков". Вы можете проверить его из map.got skills, скачать его, использовать его для улучшения своих собственных навыков и, возможно, даже использовать его для проверки некоторых навыков, написанных сообществом, чтобы вы могли проверить, хороши ли навыки, которые вы фактически используете. Если вы хотите следить за моими материалами, у меня есть рассылка на aihero.dev. И мои планы на ближайшие несколько месяцев — выпустить интенсивный курс по программированию с ИИ, который является введением во многие вещи, о которых я говорил, и о том, как начать работать с инженерией и ИИ. Я надеюсь, что того, что я вам дал, будет достаточно, чтобы помочь вам выбраться из ада навыков, или, по крайней мере, попытаться сделать горькое путешествие оттуда. Мне очень жаль, что я не смог присутствовать лично, но спасибо за просмотр. Увидимся очень скоро.