Transcription
Большинство людей используют инструменты для написания кода с помощью ИИ неправильно или наоборот. Они открывают Codeex, Cloud Code, Cursor, Lovable или другой ИИ-конструктор и говорят: «Собери мне приложение». А потом удивляются, почему результат получается слишком запутанным. Проблема не всегда в ИИ. Проблема в структуре и передаче. Поэтому, если вы дадите ИИ-конструктору расплывчатую идею, разрозненные заметки, запутанную переписку, ему придется угадывать бизнес-правила, рабочий процесс, крайние случаи, и что означает «готово»? Как выглядит успех? Так не создают настоящее серьезное программное обеспечение. Так оно не создается. В этом видео я покажу вам систему, которую я использовал за последние 18 месяцев и которую я усовершенствовал здесь, на 12x.ai. Я называю ее методом «архитектор-строитель», где я использую большую языковую модель, такую как ChatGPT или Claude, в качестве уровня архитектора. Большая языковая модель становится моим мозговым штурмом. Она помогает мне оставаться в рамках проекта. Это требует некоторой настройки, которую я покажу вам в этом видео. Как вы можете это сделать, используя эти инструменты. А затем уровень строителя — это инструмент кодирования, такой как Codeex, Cloud Code или Cursor. Итак, архитектор — это ваша большая языковая модель ChatGPT или Claude, а затем строитель становится Codeex или Claude Code, и тогда источником истины является не история чатов как таковая. Нет, источником истины является папка проекта или система папок, которую я собираюсь вам показать, которая становится мозгом и своего рода источником истины для всего проекта. Так что это актуально для вас, если вы владелец, оператор в бизнесе, консультант, руководитель, кто-то, кто уже знает, как пользоваться основами технологий. Вы можете использовать такие инструменты, как Excel. Вы можете создавать сводные таблицы. Вы видите общую картину, какой бы ни была ваша роль. Вы понимаете рабочие процессы. Вы понимаете входы, выходы, правила, утверждения, отчетность. Если вы такой человек, у вас есть сырьевой материал, встроенный в вас, чтобы стать эффективным в создании программных решений в вашей организации, а не покупать какое-то дорогое SaaS-решение или нанимать целую команду разработчиков. Вы можете сделать это сами. Я научил многих генеральных директоров делать это самостоятельно с помощью инструментов, которые у нас есть в нашем распоряжении. Вам не нужно учиться, чтобы стать разработчиком на полную ставку. Это помогает. Но самое главное — вам нужно научиться превращать эти операционные знания, эти, в некоторых случаях, племенные знания в инструкции, готовые для строителя, чтобы решить ваши сложные болевые точки и проблемы в вашей организации. Вы можете сделать это внутри компании. Вы можете настроить и адаптировать под то, как вы ведете бизнес сегодня. Сначала архитектор, потом строитель. Доверяйте системе папок. Верно? Так почему же «вайб-кодинг» ломается и почему он отстой? Почему у него такая плохая репутация? Ну, потому что обычно, когда происходит «вайб-кодинг», вы берете эти мощные инструменты, такие как Claude Code или Codeex. Вы начинаете с идеи. И даже некоторые разработчики этих инструментов, таких как Lovable и Replit, говорят: «Просто зайдите в инструмент и начните объяснять свою идею, и вы сможете что-то создать». И обычно это возможно. Иногда это может создать довольно мощный MVP, мощное демо. ИИ создаст несколько файлов. Вы будете его исправлять. Вы будете обмениваться информацией. Вы измените что-то еще. Вы покажете это кому-нибудь. Они скажут: «Эй, было бы здорово, если бы ты сделал это». В итоге вы добавляете, вы делаете, вы добавляете новое бизнес-правило. И тогда вы понимаете, что он неправильно понял рабочий процесс, возможно, три промпта назад. Тогда вам придется искать в чате. Теперь, возможно, реальные знания проекта разбросаны по всему чату. Знаете, возможно, решение зарыто где-то в сообщении 12 трехдневной давности. А ключевое исключение зарыто в сообщении 27. Критерии приемки вообще не существуют, потому что вы просто «вайбите» по этому поводу. И когда вы «вайбите» по этому поводу, ну, строитель, инструмент, хочет работать хорошо. Он начнет импровизировать. Так работают модели ИИ. Но я не хочу, чтобы Codeex или Claude Code угадывали мою бизнес-модель. Я не хочу, чтобы эти инструменты изобретали разрешения. И я не хочу, чтобы эти инструменты решали, что означает «готово». Они попытаются сказать вам это при отсутствии вашего ввода. Я хочу, чтобы строитель Codeex и Claude Code строил по утвержденным планам. И вот здесь у вас, как у оператора или владельца бизнеса или кого-то, кто увлечен этим, есть преимущество. Если вы встроены в свой бизнес и вы ближе всего к рабочему процессу, ну, вы обычно знаете реальные правила лучше, чем кто-либо другой. Вы знаете, какая колонка в электронной таблице всегда ломается. Вы знаете, какой шаг утверждения пропускается. Вы знаете, какой отчет владелец на самом деле смотрит. Так что эти знания, которые у вас есть, ценны, но они должны быть структурированы. И эти инструменты могут вам помочь. Это уровень архитектора. Этот уровень архитектора может стать очень мощным, показывая вам и помогая вам создать очень организованную систему и процесс для разработки практически всего, что вы можете себе представить, и вы можете приложить к этому свои усилия. Но строитель, ваш строитель, эти Codeex и Claude Code, не должны угадывать бизнес-правила. И давайте немного подробнее рассмотрим эту аналогию «архитектор-строитель». Представьте, что вы строите дом своей мечты. И, возможно, некоторые из вас строили дом. Знаете, вы бы не пошли к фактическому строителю, фактическому генеральному подрядчику, возможно, или к бригаде по каркасу, это лучший пример, и дали бы набросок на салфетке и сказали: «Построй мне что-нибудь современное с тремя спальнями и хорошей кухней». И разобрались бы. Ну, но вы не получите того, что хотите, верно? Если вы собираетесь сделать это правильно, вы должны донести свое видение до человека, которому платят за это, чтобы извлечь его из вас. И это архитектор, верно? Вы бы встретились с архитектором. Вы бы сообщили о своем видении и мечтах. Он бы задал вам кучу вопросов, и он бы, по сути, создал набор подробных планов, которые он мог бы передать строителю. Программное обеспечение должно работать так же. Архитектор определяет цели, бизнес-цели, пользователей, рабочий процесс, требования, чертежи, риски, решения, планы проверки, критерии приемки и передачу. Строитель будет преуспевать, когда у него будет вся эта письменная подробная дисциплинированная структура. Он будет работать удивительно хорошо. И мой опыт сформировал этот подход. У меня есть степень по информатике 1991 года, но я ею не особо пользовался, потому что 35 лет был профессиональным авиатором в Корпусе морской пехоты и American Airlines. Но степень по информатике 1991 года научила меня планировать перед строительством. На самом деле, наши профессора всегда говорили, когда мы создавали код, они говорили: «Если вы тратите более 10% на компьютере, это должно быть 5% или меньше, но если вы тратите более 10% на компьютере, это хакер». Профессиональный программист будет тратить большую часть своего времени на проектирование и детализацию на бумаге, прежде чем начнет кодировать. И это правда. Когда вы тратите все это время на это, когда вы фактически пишете код, он работает как часы. То же самое происходит и здесь. Вы тратите большую часть своего времени на общение с архитектором, настройку этих подробных планов, структуру файлов, и произойдет то, что ваш архитектор составит набор подробных планов для передачи строителю. Информатика научила меня планировать перед строительством. Авиация научила меня использовать контрольные списки, процедуры, управление рисками и четкую передачу. Вы не брифингуете полет, говоря: «Давайте просто импровизируем, верно? Вы планируете это». И вы не должны создавать программное обеспечение, просто говоря: «Эй, давайте «вайбим» с ИИ, пока это не будет выглядеть правильно. Вы получите беспорядок». Итак, четкий план полета лучше импровизации. Итак, давайте поговорим о том, почему папка является передачей, и давайте рассмотрим эту структуру папок, чтобы дать вам представление о том, как я строю вещи. Это папка под названием 12x, которую я получил на своем рабочем столе. И мы посмотрим на структуру папок, то, что я называю каркасом 120x. Теперь я буду использовать что-то под названием Obsidian, чтобы посмотреть на это, но я просто хотел сначала показать вам, что это просто обычная структура файлов, которая у меня есть, и у меня есть файлы здесь, и я расскажу об этом. Но есть инструмент, который я использую, который читает то же самое, называется Obsidian. Вам не обязательно его использовать. Он просто помогает мне читать файлы markdown. Хорошо? И поэтому, мы используем этот инструмент. Я хочу и расскажу об этом. Итак, мы находимся в этом каркасе 120x. Это шаблон, где я покажу вам, как организовать ваш проект, прежде чем мы фактически начнем кодировать. Так что, пожалуйста, потерпите меня. Важно, чтобы вы поняли, как это работает, потому что так, как я раньше делал проекты, у меня не было столько деталей. Это действительно появилось за последние 7-8 месяцев, когда вначале я все еще управлял контекстом. У меня была похожая структура папок, но она была немного более... в ней было меньше деталей. На самом деле я помещал все в файл под названием «claude markdown». Эти файлы не имеют расширения MD, но это файлы markdown, которые просто являются текстовыми файлами. Это файл markdown. Это просто текстовый файл. Он просто делает его универсальным. Его легко читать. Его легко редактировать, и он своего рода универсален. Так что мы используем markdown MD, это файлы markdown. И поэтому, даже если у него нет расширения MD, все эти, которые написаны заглавными буквами, это файлы markdown. И тогда я использую этот Obsidian, потому что я могу читать содержимое рядом с ним, и оно красиво отформатировано. Его очень легко читать. И поэтому, когда вы смотрите на это, передача, вся структура файлов, каждый проект будет иметь эту похожую структуру проекта. И причина, по которой я настроил это таким образом, заключается в том, что ваши чаты становятся запутанными в Claude Code и в Codeex, и контекстное окно, когда вы продолжаете чат, чем больше вы его используете, тем хуже он становится, верно? Потому что вы поглощаете эту память и этот контекст. И поэтому, когда вы работаете над большим проектом, вам нужно разбить его на части. Теперь я раньше помещал все в папку claw.md, и она просто росла. Я бы поместил туда правила кодирования, бизнес-правила, заметки о спринтах, старые решения, открытые вопросы, случайные заметки, напоминания о проверке, все. Это начало бы расти. И проблема в том, что в конечном итоге эта папка, единственная, которую я использовал в дополнение к моему исходному коду и всему остальному, становилась настолько запутанной. Это было просто слишком шумно. Решением был не больший контекст. Решением был более чистый контекст. И именно поэтому я создал эту более подробную структуру. Каждый проект, который я делаю, который я создаю, вы создаете папку на своем рабочем столе и называете проект чем-то, а затем у вас должна быть структура файлов, и в конечном итоге весь ваш код будет помещен в эту папку src. Но я расскажу об этих других папках, которые я создал с этими документами markdown, если хотите, и объясню некоторую логику, и, надеюсь, это будет иметь смысл. Хорошо. Итак, вместо того, чтобы иметь одну большую папку clawed MD, которая просто растет и раздувается, я разбил все на части. Так что это немного больше, все более усваиваемо, и тогда любой может прочитать, и особенно Claude Code или Codeex, когда я начинаю новый спринт, о котором я расскажу здесь через минуту, он может легко узнать, где он находится, пока мы будем поддерживать все это в актуальном состоянии. И я покажу вам, как мы это делаем. И поэтому способ взглянуть на эту структуру файлов — это не бюрократия, и хотя хорошо быть организованным и легко подхватывать, настоящая вещь вокруг этого — это инженерия контекста. Помните, как я сказал, контекст — это король. Он предоставит строителю Codeex или Claude Code правильную информацию в нужное время, организовав ее таким образом. И поэтому, опять же, помните, что решением является не больший контекст. Решением является более чистый контекст. Итак, давайте поговорим обо всем этом. Что это? Давайте пройдемся по каждому из этих файлов. Опять же, когда проект небольшой, вы, вероятно, сможете обойтись, просто поместив все в папку claw.md или папку codeex.md. Но давайте предположим, что вы хотите создать что-то несколько сложное. Хорошо построить это таким образом. Итак, давайте начнем с первого файла, agents.md markdown. Что это? Ну, это основной маршрутизатор. Это своего рода основная папка или, если хотите, файл. И это первый файл, который должен прочитать каждый ИИ-агент или человек-строитель. Вы читаете это, вы получите весь контекст об операционной модели, какие файлы читать первыми, какие правила должен соблюдать строитель, рабочий процесс, который мы делаем, и все остальное. Claude MD и Codeex — это своего рода одно и то же, в зависимости от того, какой инструмент вы используете. Если вы используете Claude Code, я ссылаюсь на Claude MD Codeex. Если вы используете Chat GPT и Codeex, я буду ссылаться на эту папку, но они, по сути, делают одно и то же. Это тонкие адаптеры для используемого вами инструмента, но это не должно становиться всем мозгом проекта. Это небольшая часть мозга, и она растет, и я покажу вам несколько примеров, когда мы начнем строить проект, но это как мини-часть мозга, которая работает с агентом, и она находится на корневом уровне, верно? Итак, это находится на корневом уровне. А затем readme — это просто человеческий обзор, верно? И если кто-то откроет эту папку «холодной», она должна рассказать ему, что такое проект и куда смотреть дальше, верно? И что содержат все эти другие вещи, другие файлы или папки. Хорошо. Затем я возвращаюсь сюда, у меня есть папка docs. Итак, в папке docs это для долговечной технической документации, верно? Поэтому, если мы посмотрим здесь, если я посмотрю на архитектуру, например, это карта системы. И опять же, это шаблоны. Я покажу вам, когда она будет заполнена здесь через некоторое время. Она объясняет основные части приложения, как они сочетаются друг с другом. Модель данных объясняет основные сущности, поля, отношения. Если у вас есть проект, сильно зависящий от электронных таблиц или баз данных, это много, верно? И если я смотрю на API, если у вас много соединителей или конечных точек, контрактов, входов, выходов и правил интеграции для других инструментов, таких как я, подключенный к Intac, Sage Intac для чего-либо, вся ваша информация об API будет здесь. Permissions определяет роли и доступы и кто к чему имеет доступ. И по мере того, как мы создаем вещи, часто у нас есть разные типы правил доступа пользователей. Так что хорошо иметь это задокументированным. А затем validation объясняет, как мы доказываем, что система правильная. Например, для бизнес-систем здесь мы определяем, как выходы связаны с исходными данными. Так что это важно определить. Итак, вы видите, если бы у меня была вся эта информация в одном документе markdown, он был бы просто огромным, и вещи терялись бы. И поэтому вы разбиваете его на мелкие части, чтобы сделать его немного более дисциплинированным, верно? И затем у меня есть папка planning. Итак, если я зайду сюда и посмотрю в папку planning, у меня есть место для встреч. Опять же, это место, куда я помещаю заметки о встречах. Если я записываю разговор с моим клиентом, все автозаписи, транскрипты пойдут сюда. И поэтому, это хорошо. И тогда, если я посмотрю на корневые файлы markdown, которые здесь есть, этот важен — state. Это текущий момент, верно? Где мы находимся? В каком спринте мы находимся? Что только что произошло? Что дальше? Что заблокировано? Это очень важный момент. Он обновляется по мере того, как мы пишем больше кода и принимаем больше решений по спринтам. decisions важен. Я считаю, что это критически важно. правила дома — то, что мы решаем, когда что-то важно, и мы будем постоянно принимать решения на протяжении всего проекта, особенно в начале. Мы будем принимать решения, и когда мы принимаем решения, мы документируем их, и особенно так, чтобы они попали сюда, чтобы мы не пересматривали их через три спринта или не пытались вспомнить, что мы сделали. domain — это мир клиента. Это не ваша область. Ваша область — это, например, какой бизнес у вашего клиента или ваш собственный бизнес, терминология, рабочий процесс, пользователи, люди, бизнес-правила, операционная реальность. Мы помещаем сюда вещи, просто чтобы сохранить их для контекста. risks — очень важный момент. Это список известных ловушек. Он делает хрупкие предположения и риски проекта видимыми. И then questions, очень хорошо, особенно для информирования клиента. Если у вас есть открытые вопросы, вам требуется ввод от архитектора или заинтересованной стороны, и у нас нет ответов на них, мы поместим их сюда. И как только они получат ответы, мы закроем их. Это очень полезно иметь это в структуре файлов. И then file inventory отслеживает исходные материалы, такие как PDF, электронные таблицы, экспорт, снимки экрана, заметки репозитория. Все, что является своего рода сборником, я помещаю в file inventory. Особенно если у клиента есть документы, на которые я могу захотеть сослаться и использовать, такие как выходные документы, PDF-файлы, все это может попасть сюда, на что мы можем ссылаться, верно? И then uh я говорил о заметках о встречах. Здесь все заметки о встречах, потому что они могут быть запутанными. И иногда решения, и если решения вытекают из встречи, я перемещаю их в decisions. И then there's the planning, the sprints. Это своего рода сердце всего. Когда вы начинаете работать в роли, скажем, ваш общий план состоит из 15 спринтов, верно? И он разбит на части. И каждый из спринтов делает определенную вещь. У него есть конечное начало и конечное окончание, где мы определяем успех. И вот так вы строите план. Вы атакуете его по частям. И для каждого спринта есть четыре файла. Для каждого спринта, что произойдет? Ваш архитектор разобьет план на определенное количество спринтов. И когда вы работаете над любым спринтом, вы скажете архитектору ChatGPT или Claude Chat: «Собери мне пакет архитектора, который я могу дать моему строителю». И что это сделает, так это то, что пакет архитектора определит четыре документа для каждого спринта. Он составит документ с требованиями, который снова говорит, что мы строим и почему. А затем он также составит чертеж, который говорит, как мы планируем это построить. Итак, опять же, это ваш архитектор, который составляет требования и чертежи, планы, чтобы дать вашему строителю, чтобы он мог выполнить работу без каких-либо вопросов. И пара бонусных документов, которые я добавил недавно, и это действительно помогает, это критерии приемки для этого спринта, например, как выглядит успех, это очень важно, по сути, что означает «готово» для этого спринта, а затем запрос на передачу, который мы получим от вашего архитектора, но мы также документируем его здесь, и мы всегда можем вернуться. Это запрос на передачу для этого спринта, который я дам строителю, чтобы он прочитал документы и начал строить и планировать, и я покажу вам это здесь через минуту. Так что эта четырехспринтовая архитектура — это действительно сердце рабочего процесса. Это то, где все действительно происходит, и все остальные папки и файлы действительно поддерживают все, что происходит в этих спринтах. Так что ссылки и остальное для остальной части этих, опять же, это просто документы readme, чтобы сказать вам, что хранить и где. И опять же, они необязательны, но они только для меня. Например, я помещаю сюда образцы данных, но я помещаю файл readme, чтобы люди могли знать, что мы помещаем куда. Возможно, некоторые люди считают это излишним, но я думаю, что это отличный способ сохранить порядок, особенно для больших проектов. И этот SRC — это место, где ваш исходный код будет разрабатываться и отправляться, а затем в конечном итоге отправляться на GitHub, что будет в другом видео. Но это все. Это каркас или своего рода детали для системы папок, которая становится мозгом вашей операционной системы при создании кода. И поэтому для каждого проекта, который вы создаете, вы будете создавать этот каркас со всеми этими документами, которые будут заполняться. Ну, это может показаться немного подавляющим. Так что я построил инструмент. Вы можете сделать это вручную, вводя запросы и создавая вещи, и они обязательно построят их. Но я построил инструмент, который помогает, особенно в самом начале, помочь создать эти проекты. И поэтому я покажу вам это сейчас. Итак, когда вы собираетесь начать проект, вам нужно будет начать разговор с вашей большой языковой моделью, архитектором. Помните, архитектор — это Claude, или это ChatGPT. Вы можете использовать любой из них. И что вы собираетесь сделать, если вы собираетесь использовать Claude или вы собираетесь использовать ChatGPT, вы захотите использовать вещи в... вы хотите создать проект для решения, которое вы пытаетесь создать, или приложения, которое вы пытаетесь создать. И поэтому вы замечаете здесь, в Claude, у меня есть все эти проекты, верно? Приложения, которые я построил, и вещи, которые я сделал. И я поместил их в проекты. И причина, по которой мы помещаем их в проекты, заключается в том, что каждый из проектов не только получает гораздо больше контекста и памяти, чтобы помочь вам с проектом, вы также можете установить пользовательские инструкции, чтобы помочь определить, как проект должен реагировать. Опять же, вы можете научиться создавать проекты здесь, но я буду демонстрировать в ChatGPT сегодня, просто потому что 5.5 действительно впечатляет, и используя Codeex. Я просто хочу показать вам, что вы можете сделать это по порядку. Я большой поклонник Claude. Я большой поклонник Codeex от Chat GPT. Так что я попробую Codeex здесь. Но, по сути, когда вы собираетесь начать, вы захотите создать новую папку проекта. И мы создадим ее в папке на нашем рабочем столе. Но мы также хотим создать проект в большой языковой модели. И поэтому мы назовем это новым проектом здесь. Мы просто назовем его demo project 3. И мы создадим проект. Теперь, как и в любом другом проекте, у вас есть место для источников. И мы будем заполнять все, что у нас есть здесь, что, по нашему мнению, будет применимо ко всем многочисленным чатам, которые у нас будут в нашем проекте. В этом случае я хочу дать ему некоторый контекст о моей философии. Так что, если я посмотрю на мою папку 120X, есть пара в моей последней философии. Опять же, это просто моя. У меня есть несколько файлов mark, которые говорят о моей философии, верно? Вот моя философия о моей архитектуре 120x, и даже если ChatGPT знает об этом, я хочу, чтобы этот проект убедился, что нет никаких сомнений, что они знают, о чем мы говорим. Так что я добавляю этот файл туда. У меня также есть метод быстрого старта, как начать проект. Он дает пошаговое руководство. И поэтому я хочу, чтобы он знал и это. И я помещу инструкции по каркасу, даже если мы знаем, что это так. Я не хочу, чтобы у него были сомнения в этом. И тогда у меня есть пара других вещей. Может быть, этот пакет рабочего процесса архитектора, чтобы он знал, и шаблон для пакета архитектора, даже если, как правило, он должен знать, что это такое, но не повредит иметь его здесь. Теперь, какие еще файлы я могу сюда поместить? Ну, если у меня есть файлы Excel или PDF-документы, я помещу их в свою структуру файлов, которая у меня есть. Но я также хочу, чтобы они были для моего архитектора. Так что это своего рода, даже если у меня есть эти файлы, существующие у меня дома, если я собираюсь встретиться с архитектором, мне нужно взять свои файлы с собой в офис. И вот что я делаю здесь. Другое, что я хочу сделать, это настроить, как я хочу, чтобы этот проект реагировал. Так что я отредактирую некоторые инструкции. И поэтому вы буквально можете сказать ему быть кем угодно. Вам не обязательно это делать, но, черт возьми, это действительно выделяет его и может действительно конкретизировать, как вы хотите заниматься разработкой программного обеспечения. Как вы хотите обрабатывать ситуации. Я скопирую это из другого проекта, который у меня есть для моего запускающего проекта 120X, который я сделал. Я скопирую эти инструкции, которые появляются здесь. И, по сути, это просто усиливает мои проекты архитектор-строитель, что должен делать уровень архитектора, как использовать методологию, важные границы. Это внутренние инструменты, а не клиентское приложение. При создании планов реализации разделите это от этого. Здесь много всего, и что мы должны делать, но я не хочу никаких сомнений в том, кем я хочу, чтобы был архитектор. Теперь вы можете сказать: «Ну, как я это создал?» Ну, я использовал большие языковые модели ChatGPT и Claude, чтобы помочь мне составить этот набор пользовательских инструкций. Конечно, разработка этой философии заняла около года, но в конечном итоге я попросил большую языковую модель помочь мне составить эти инструкции. Так что я скопирую эти инструкции из этого проекта здесь. Мы перейдем к нашему демонстрационному проекту, и я отредактирую инструкции и помещу их сюда. Хорошо. Итак, теперь мой архитектор готов к работе, чтобы я мог начать общаться с ним. Ну, у меня были некоторые инструкции, некоторые архитектурные запросы, чтобы начать, но я построил инструмент, который становится частью моей когорты. Вы можете использовать этот инструмент бесплатно, но он помогает начать разговор с архитектором. Он создает структуру папок для проекта. И вот как это выглядит. Это инструмент, который я построил, используя ту же методологию, верно, чтобы построить это микро-приложение, если хотите. И поэтому я начну новый проект. И, по сути, когда мы начнем, он проведет меня через пять шагов. И когда я начну проект, мы назовем его demo project 3, и он для моей компании. И идентификатор проекта slug, мы просто назовем его demo project 3, и это внутренний инструмент для меня. Одно предложение описания. Я просто придумаю это здесь. Я хотел бы создать приложение, которое берет несколько разрозненных электронных таблиц Excel и PDF для генерального директора и объединяет их, анализирует их все и генерирует еженедельную рассылку и ежемесячную HTML-панель для совещания совета директоров на основе финансовых данных из электронных таблиц. Целевая родительская папка — это где я хочу, чтобы это было построено. Я хочу, чтобы это было построено на моем рабочем столе 12x.builds. Я могу выбрать папку здесь. Путь к репозиторию реализации. Это если я настрою его в GitHub, это для другого. Я оставлю его пустым. То же самое с технологическим стеком репозитория GitHub. Я мог бы определить его здесь, но я оставлю его пустым. И тогда я продолжу к приему. И опять же, здесь вы хотите потратить некоторое время. Мы можем сделать это в нашем чате с архитектором, но если мы можем сделать большую часть этого заранее здесь, вы можете так же хорошо это сделать. Я оставлю многие из этих пунктов намеренно пустыми, просто чтобы показать вам, что запрос, который генерируется из этого, который является конечной целью этого инструмента, первоначальный запрос для начала вашего разговора с архитектором. Знаете, какую бизнес-проблему мы решаем? Проблема в том, чтобы взять разрозненную информацию из нескольких электронных таблиц, входных источников, PDF и т. д. и превратить ее в быстрый способ для генерального директора генерировать еженедельную рассылку и ежемесячный обзорный отчет для совета директоров в формате HTML. Кто основные пользователи? Я скажу, что основной пользователь — это генеральный директор, владельцы бизнеса и финансовый директор. Болевые точки. На подготовку и сбор всех разрозненных данных уходит почти три-четыре часа в неделю, и составление еженедельной рассылки. Мы хотим сократить это до менее чем 30 минут. И тогда я мог бы продиктовать рабочий процесс здесь, целевой рабочий процесс. Я оставлю эти поля пустыми. Но если бы вы могли потратить время и уделить время тому, чтобы действительно подумать об этом, провести мозговой штурм, поговорить об этом, заполнить это, вы будете в гораздо лучшем положении. Теперь мы просматриваем проект. Он как бы охватывает все, что мы собираемся построить, и где все эти TBD нуждаются. Discovery означает, что я не ответил на них, и я покажу вам почему через секунду. И тогда мы создадим проект. И поэтому он сделал пару вещей прямо здесь, но главное, что он сделал, это дал мне хороший запрос архитектора. И опять же, этот запрос довольно подробный, но он помогает вам начать разговор с архитектором в правильном ключе. И поэтому я начинаю как 12x архитектор. Вот метаданные проекта, название, все остальное, текущий статус. Эта папка была создана здесь. Вот контекст методологии. Вот необязательные ссылки на источники. Вот исходный материал. Вот контекст приема проекта. Убедитесь, что он задает вопросы по вещам, которые являются TBD, верно? И поэтому это довольно подробный запрос, и то, что он выдает. Но я также хотел показать вам структуру файлов, которая была создана. И поэтому мы назвали этот проект demo 3, верно? Так что в моей папке builds, и я иду сюда, в мои builds. Вот demo project 3. Так что он создал это и заполнил это в том месте, где я хотел, чтобы это было, предоставив все шаблоны и все документы. Он начал заполнять некоторые вещи, но они будут заполняться еще больше, когда мы пройдем через наш разговор. Он выдает Codeex MD, Claude, опять же, просто базовое заполнение, и в планировании наш первый спринт мы готовимся создать, мы создадим пакет архитектора. Так что в любом случае, все настроено и готово к работе в нужном месте. Это было самое важное, что я хотел сделать. В прошлом я бы как бы вручную копировал и вставлял, а затем помещал вещи сюда. Теперь это делается просто через этот один, используя этот проект здесь. Так что теперь я скопирую этот запрос. И опять же, это стартовый запрос архитектора, который я собираюсь поделиться со своим архитектором. В данном случае это будет ChatGPT. И поэтому я перехожу к нашему demo project 3, который я сейчас нахожусь. У нас есть файлы источников, которые там есть. У нас есть пользовательские инструкции. И мы просто вставляем запрос и начинаем разговор. И поэтому то, что я должен увидеть здесь, потому что я не ответил на все вопросы в моем стартовом инструменте. Он сгенерирует разговор и задаст мне целый ряд вопросов. Хорошо. Итак, это заняло около 3 минут. Но посмотрите, насколько это мощно, что он сделал. Итак, он говорит: «Я применяю первые ворота обнаружения, первые ворота обнаружения. Обратите внимание, он сказал «ворота обнаружения». Мы еще не готовы к первому пакету архитектора. Не генерируйте пакет пока. Эта идея полезна, но нам еще предстоит много мозгового штурма», — говорит он, верно? Он сказал: «Вот что он рекомендует для первой полезной версии MVP, минимально жизнеспособного продукта. Вот три возможных направления проекта. Вариант один, вариант два, вариант три». Итак, вы видите, что я делаю? Это как будто у нас первая встреча, и мы вместе проводим мозговой штурм. Он дает мне рекомендацию. Мы начнем с этого. А затем первый спринт после планирования будет таким. Вот вопросы для обнаружения. Ответьте на них в виде грубых заметок. Несовершенные ответы — это нормально. Он все еще задает мне все эти вопросы. Он спрашивает, каков текущий рабочий процесс. Где сжигается 3-4 часа? Пользователи. Так что он уже задает мне много вопросов. Так что у меня еще много работы, но это хорошая работа, верно? Это то, где вы можете определить это. Это то, что вы действительно сделали бы с архитектором в любом случае. Вы бы определили свое видение. Вы бы обменивались информацией. И хорошая новость в том, что архитектор отлично справляется с тем, чтобы задавать вам вопросы о том, как это должно выглядеть. Но вот что я хотел вам показать, что вы настраиваете это, и теперь вы начинаете вести эти разговоры, и это взаимный итеративный разговор, пока вы не получите ответы на все, а затем он создаст этот первый пакет архитектора. Ради демонстрации, посмотрите на все это. Это просто прекрасно, что он делает. И он говорит: «Вот наши самые большие риски. Вот мое сильное действие по умолчанию для пакета архитектора 2. Я буду структурировать его таким образом. Что мне нужно от вас дальше, это это. Ответьте грубыми ответами только на эти пять». И так далее. После этого я создам пакет архитектора. Когда вы скажете «сгенерировать пакет», ради демонстрации, я скажу ему: «Эй, я делаю демо. Можешь ли ты заполнить пробелы своим лучшим предположением?» В реальности вы бы заполнили все эти вопросы, верно? Но ради времени, ради этой демонстрации, можешь ли ты заполнить незаполненные вопросы своим лучшим предположением? Это только для демонстрационных целей. Я пытаюсь сэкономить время. Так что, если вы можете заполнить свои незаполненные вопросы тем, что, по вашему мнению, лучше всего, и я соглашусь с любыми вашими рекомендациями, и вы можете сгенерировать пакет с этого момента, ребята. Я делаю это только для ускорения времени демонстрации. Я поставлю это на паузу. Я позволю ему построить и сгенерировать, и я вернусь к вам, когда все будет готово. Хорошо, это заняло 2 минуты и 28 секунд, но, по сути, то, что он сделал, что сделал архитектор для меня, это сгенерировал пакет архитектора, который мы в конечном итоге дадим строителю прочитать. Мы посмотрим, что внутри этого здесь через секунду. А затем он также дал нам запрос Codeex для применения и проверки пакета. Так что мы вернемся к этому. Итак, давайте приступим. Я скачаю этот пакет архитектора 001 в наш проект. И поэтому я перейду к нашему проекту demo 3, который находится прямо здесь. И я скачаю этот пакет архитектора discovery на корневом уровне нашего проекта. И я сохраню его. Теперь я зайду в Obsidian, чтобы просмотреть это. Так что я перехожу к demo project 3 прямо здесь. Позвольте мне свернуть некоторые из них, чтобы вы могли это увидеть. Вы можете видеть, что на корневом уровне у меня есть architect pack 001 discovery. Теперь посмотрите на все, что здесь есть. Что было создано? Он дал нам состояние проекта. Он дал нам текущий статус того, что мы пытаемся сделать. Это демонстрационный продукт. Это направление проекта. Создание внутреннего прототипа отчетности. Активный спринт будет этим. Рекомендуемый следующий спринт — этот. Недавно завершенные следующие действия, файл и все, что нужно поместить в эти markdown, верно? Журнал решений, решения, которые мы уже приняли, предположения для демонстрации, принятые для планирования, что входит в домен, все эти вещи. Так что вы видите, как это становится этим пакетом архитектора, который ваш архитектор сделал блестяще, он начинает заполнять ваши файлы здесь, чтобы помочь Codeex, так что это просто удивительный объем работы и деталей. Все наши риски, которые здесь есть, вопросы, которые у нас есть, открытые вопросы, которые у нас есть, ответы на вопросы, предоставленные демонстрацией. Это просто удивительные вещи. Я имею в виду, вы получаете все это созданное, эти детали. Итак, это то, что содержится в этом первом пакете архитектора. Хорошо. Итак, архитектор выполнил свою работу. Мы в его офисе, он дал нам некоторые результаты, которые нам теперь нужно отнести нашему строителю и посмотреть, насколько хорошо мы справимся. И поэтому, если я вернусь к своему чату с архитектором, он дал мне запрос для Codeex. Вы — строитель. Сначала примените этот пакет архитектора, который мы только что рассмотрели. Запустите его для пробного прогона. Если пробный прогон выглядит безопасно, запустите его. И после применения пакета не пишите код, а прочитайте эти файлы. Затем обобщите, что мы строим, что V1 не является, какие предположения сделаны. И вот так выглядит первый спринт. Мы не создаем код как таковой, но мы заставляем Codeex определить для нас, что он будет строить. А затем мы проверим это с нашим архитектором, чтобы увидеть, на правильном ли мы пути. Имеет ли это смысл? Еще одна вещь, прежде чем я это сделаю, я всегда люблю знать, сколько спринтов нам понадобится для успеха. И это просто дает мне общую картину. Я могу посмотреть, но я люблю спрашивать своего архитектора напрямую, знаете ли вы, сколько спринтов нам понадобится для этого проекта? Верно? И поэтому, о, где он сказал? Да. Он говорит: «Demo three, я планирую пять-шесть спринтов всего. Вот как они выглядят, и они определены». Так что мы просто знаем, что у меня около шести спринтов. И реальная точка успеха будет такой. И, вероятно, достижима в четвертом или пятом спринте. Мой вывод таков. Так что, в любом случае, очень хорошо. Итак, в любом случае, давайте вернемся и скопируем этот запрос. И теперь мы отправимся в офис нашего строителя, поедем через город, и мы постучим в дверь проекта нашего строителя, и мы начнем новый проект Codeex. Так что нам понадобится новый чат. И поэтому, когда я начну новый чат, мне нужно указать на структуру файлов, которую мы создали. Так что в данном случае я добавлю новый проект, и он даст мне окно для навигации. И поэтому, в данном случае, я перейду к 120X. Я перейду к моим сборкам, и в моих сборках я перейду к demo project 3, и я открою его там, и именно там я хочу, чтобы Codeex искал файлы. Хорошо. И тогда у нас есть этот приятный запрос от нашего архитектора, и давайте дадим ему попробовать. Хорошо. Это работало минуту и 23 секунды, и, по сути, то, что он выдал, это то, что он успешно применил пакет архитектора discovery после безопасного пробного прогона, и вот сводка: мы делаем, что такое V1 и что это не так, предположения для демонстрации, приемка спринта 01, пробелы, противоречия и рекомендуемый спринт 02, а затем одно экологическое примечание, и он создал для нас папку markdown для просмотра. Он создал это состояние проекта, где мы находимся. И поэтому опять же, я бы рассмотрел это, и ради демонстрации я собираюсь скопировать это. Я вернусь к своему архитектору и скажу ему: «Эй, Codeex закончил. Вот его сводка». И я вставлю то, что дал мне Codeex. Так что вы видите, как я использую архитектора для проверки работы, которую сделал строитель. И поэтому, очевидно, вы захотите сами это проверить. Вы поймаете вещи, но затем вы также хотите вернуться к своему архитектору и сказать: «Как мы здесь справились?» Потому что ваш архитектор, безусловно, увидит общую картину и поймает вещи. Я всегда обмениваюсь информацией, и люди говорят: «О, ну, вы, знаете ли, тратите много времени и используете все эти токены для этого». Но опять же, у меня меньше ошибок на стороне бэкенда. Если я сделаю это таким образом, я могу почти построить что-то с минимальными ошибками или логическими ошибками. Обычно это работает довольно хорошо, и это уже организовано. Так что я поставлю это на паузу, пока мы ждем, пока архитектор посмотрит и предложит другие рекомендации. О, и пока это готовится, я думаю, что могу показать вам, если я вернусь к структуре файлов для нашего demo project 3, если я перейду к планированию и перейду к спринтам, вот спринт один, обнаружение архитектуры, и обратите внимание, как этот документ был обновлен, верно? Вот все критерии приемки. Вот чертеж, который прочитал Codeex, что довольно мощно, верно? Посмотрите, сколько деталей больше. Вот запрос на передачу, который мы ему дали. Здесь просто еще одна копия, которую мы дали Codeex. Вот требования снова, на которых Codeex основывает этот первый спринт. Я также хотел бы переименовать в Codeex этот спринт. Например, здесь мы находимся в demo project 3. Вот первый чат, в котором мы находимся. Я могу переименовать эти чаты, и мы назовем его sprint 001. И вы можете назвать его как угодно, что применимо, discovery и architecture. И тогда, когда вы здесь, каждый раз, когда вы делаете новую функцию, новый спринт, я начинаю новый чат под проектом. И поэтому, например, если вы посмотрите на этот 120 project launcher, у меня 15 спринтов. Вы можете видеть все спринты и что я сделал и как они назывались, верно? Просто держит его аккуратным и организованным, и вы можете видеть, что вы сделали, когда. И поэтому это был первый спринт, который мы сделали на Codeex. Так что давайте вернемся. Как там наш архитектор? Он завершил? Да, он завершил. Что он рекомендовал здесь? Он сказал, что Codeex сделал правильно. Проверил его. Не начал кодировать. Я рассматриваю заметку Codeex о устаревшем readme как часть очистки. Сводка Codeex чиста. Я создал следующий пакет архитектора. Так что теперь мы на пакете архитектора два. И что сделает спринт два. Это первая реализация. Он говорит Codeex построить эту важную область вызова. Я намеренно сделал это безопасным для терминации и демонстрации. И вот приятный запрос, который он дал мне, чтобы дать Codeex. И мы можем просто вернуться к строителю. О, прежде чем мы это сделаем, нам нужно взять наш пакет архитектора 002, верно? И нам нужно сохранить его в корне нашего demo project 3. Он ляжет прямо рядом с другим пакетом архитектора. Так что мы сохраним его там. Позвольте мне заглянуть в структуру файлов и показать вам, где он находится. Так что demo project three, и если вы посмотрите на корневой уровень, вы увидите architect pack 2 sample boundary parcel newsletter, и вот как это выглядит внутри всего. Вы, конечно, могли бы изучить это, но ради демонстрации я предполагаю, что все это хорошо, но, конечно, в реальной жизни я бы просматривал все это, чтобы убедиться, что это делается так, как мы сказали, что мы собираемся делать. Затем вернемся к архитектору, и мы поместили пакет в нужное место. Теперь мы скопируем запрос, который мы поместим в Codeex. И поэтому там мой строитель и Codeex. Я собираюсь начать новый чат, потому что мы сделали спринт один. Так что я собираюсь перейти к demo project, новый чат. Мы все еще находимся в том же demo project 3. Я собираюсь вставить это. И тогда я скопирую это, чтобы это имело смысл здесь. И тогда я переименую этот спринт. И тогда я скопировал этот 002 sample bund parser newsletter. Сохранить. Верно. И вы видите, как я это организовал? Я просто переименовал это, чтобы я знал, что это текущий спринт, в котором я нахожусь. И поэтому я получаю свежий контекст каждый раз. И поэтому мы знаем, что такое спринт. И тогда я вернусь к вам, когда это будет сделано. Хорошо. Минута и 10 секунд. И что мы получили здесь? Он применил пакет архитектора. Что строит спринт 2. Опять же, это применил его после безопасного пробного прогона. Так что он сделал пробный прогон, сказал, что это нормально, и тогда он еще не начал реализацию. Итак, вот основная команда, явно вне сферы. Я бы рассмотрел это, но ради времени я просто просматриваю это. Вот план реализации. Это файлы, которые я ожидаю создать и изменить. Риски, двусмысленности. Выглядит хорошо для меня. Я скопирую это. Я вернусь к своему архитектору и скажу: «Вот сводка спринта 2». И поэтому наш архитектор говорит: «Эй, хорошо. Codeex правильно понял спринт и остановился на контрольной точке. Мое чтение говорит, что это готово к реализации. Единственная реальная точка принятия решения — это зависимость от Excel. Использование этого разумно для этой демонстрации. Это лучше, чем притворяться демонстрацией. Я бы одобрил это. Хорошо, хорошо. Я согласен с этим. И посмотрите, он дает мне еще один запрос, чтобы перейти к строителю. Мой архитектор делает тяжелую работу за меня. И это то, что я люблю в этом. Вот почему эти инструменты так хороши. Одна заметка, он говорит, что файл без фактов не находится в репозитории git. И это нормально, потому что я делаю демо. Я покажу это в другом видео. Но как только мы начнем получать больше, нам в конечном итоге придется зафиксировать эти вещи в GitHub, верно? Но это другое видео. Так что после завершения спринта 2 я хочу, чтобы Codeex показал нам это. И это круто. И поэтому я скопирую это, а затем вернусь к нашему строителю. И в том же спринте, потому что мы не начинали новый, верно? Я продолжу со своим спринтом 2, чтобы продолжить и сделать то, что просил нас архитектор. и посмотрим, как он справится. Хорошо, это заняло 5 минут и 25 секунд, но наш строитель, похоже, сделал довольно хорошую работу. Это все, что он создал с точки зрения исходного кода, изменил эти документы, выполнил эти командные запуски, дал мне эти результаты тестов, дал мне кое-что посмотреть из HTML, на что мы посмотрим здесь через секунду, некоторые известные ограничения. Так что я возьму это, проведу аудит с нашим архитектором, чтобы посмотреть, как они справились. Скажите, вот результат спринта 2 от Codeex. И пока он готовится, я посмотрю на структуру файлов, чтобы показать вам. Смотрите, для вывода
Есть спринт два, а затем для демонстрации результатов еженедельно он дал мне два HTML. Итак, вот как выглядит ежемесячная панель мониторинга. Опять же, это всего лишь концепция в спринте 2. Мы хотели придумать некоторые концепции. И тогда, если я также посмотрю на другой HTML, еженедельный информационный бюллетень, он выглядит так. Итак, опять же, это очень базовая информация, но она показывает вам в спринте 2. Это дало нам некоторые идеи о том, как могут выглядеть наши результаты для нашего приложения. Так что это хорошо. Давайте посмотрим, как продвигается архитектор. Он все еще думает, поэтому я приостановлюсь и вернусь, когда он будет готов. И вот здесь это заняло минуту и 26 секунд. Спринт 2 был успешным. Спринт 2 приземлился именно там, где должен был. Важно то, что у нас теперь есть работающее программное обеспечение, а не просто документы по планированию и синтетические отчетные пакеты. А затем он продолжил и создал пакет архитектора 003 для полировки результатов для руководителей. Кодек остался в рамках. Основная проблема теперь заключается в том, чтобы сделать его демо-качества. Прямо сейчас нам нужно создать сгенерированный информационный бюллетень. Направление спринта три таково. Следует сосредоточиться на этом. И снова, я знаю, что я прохожу через это быстро, потому что я просто пытаюсь сэкономить время, но это просто показывает вам, насколько хорош архитектор, когда вы его настраиваете. Насколько мощным он может быть при настройке. Итак, давайте загрузим пакет архитектора 3. Затем мы остановим демонстрацию здесь. Но я просто показываю вам сейчас для моего третьего. Я бы поместил его на корневой уровень в моем демонстрационном проекте, а затем я бы скопировал запрос, чтобы дать моему сборщику кодексы. Я бы зашел в кодек, начал новый чат в моем демонстрационном проекте 3. Вставил бы это туда. Я собираюсь скопировать это для названия моего спринта, а затем позволить сборщику приступить к работе. И я собираюсь переименовать этот спринт 003, и это полировка результатов для руководителей. Мы сохраним это и будем двигаться дальше. Так что вы понимаете, верно? Итак, мы идем вперед и назад. Мы просто даем кодексу сборщику конкретные планы для выполнения в определенное время и для определенных вещей. Вы держите все в порядке, а затем, когда это будет сделано, он обновляет структуру папок, чтобы контекст никогда не терялся. И, по-моему, я просто думаю, что это один из самых мощных способов создания проектов. Я построил, как я уже сказал, 35 проектов, особенно за последние 12 месяцев, я построил некоторые действительно интенсивные корпоративные проекты, и я не смог бы сделать это без такого уровня организации. Теперь вы смотрите на рабочие процессы, которые мы пытаемся решить. Вы можете научиться делать это, а затем я могу научить вас учиться. У вас есть люди в штате прямо сейчас, которые могут сделать это для вас. Если не вы сами, я гарантирую, что у вас есть пара упорных трудяг, которые могут разобраться в этом. И ключ в том, что это здорово, если вы немного разбираетесь в разработке программного обеспечения и инженерии, но главное — можете ли вы понять общую картину? Если вы можете видеть общую картину, можете ли вы организовать вещи? Это ключ к созданию качественного программного обеспечения и использованию этих инструментов ИИ, верно? И поэтому это отличное место для начала. И, конечно, я могу сделать это для вас, но я думаю, что было бы важнее и интереснее, если бы вы научились делать это сами для небольших проектов, для небольших задач, которые у вас есть в организации. Итак, главное, с чем я хочу, чтобы вы ушли, это то, что вам не нужно становиться полноценным инженером-программистом, чтобы начать мыслить таким образом. Но вам нужно научиться определять рабочие процессы, определять свои правила, свои данные, свой риск, свои критерии приемки, и достаточно четко, чтобы сборщик ИИ мог их выполнить. Правильно? Итак, главная идея, с которой я хочу, чтобы вы ушли из этого видео, заключается в том, что не просите сборщика ИИ строить из расплывчатой идеи, верно? Вы должны использовать своего архитектора. И если вы владелец, оператор, консультант, вы умеете не программировать, возможность заключается не в том, чтобы научиться программировать. Вот как решать реальные бизнес-задачи, реальные узкие места в вашей организации внутри компании. Вы можете научиться проектировать эти рабочие процессы и использовать эти инструменты, используя этот метод. Ничто не мешает вам, кроме того, что кто-то покажет вам, как это сделать. Вы создаете требования, вы создаете чертеж, вы создаете критерии приемки, риск, решения, валидацию, подсказку для передачи. Все это может быть сделано с вашим архитектором, использующим большую языковую модель. Затем позвольте кодексу или облачному коду или другому сборщику выполнить это. Работайте управляемыми частями. Держите это в дисциплинированном потоке. Передача — это не чат. Передача — это файловая система папок, которая будет держать все в порядке для вас. Я могу научить вас, я могу определенно построить это для вас внутри компании, но я также хотел бы научить людей ловить рыбу. И вот что мы делаем здесь. Я запускаю когорту сборщиков для 10 человек. Это сейчас в бета-программе, но я собираюсь научить этому методу практически, чтобы показать вам. Вы приносите рабочий процесс. У нас будет 10 владельцев-операторов, генеральных директоров, операторов, руководителей отделов, людей в организациях, 10 человек из разных организаций. Мы возьмем любой рабочий процесс, который у вас есть, и мы построим для вас здесь реальные рабочие микроприложения. Я хотел бы, чтобы вы были частью этого. Вы можете перейти на 12x.ai и посмотреть когорту сборщиков. Опять же, это на четыре недели, 10 человек, пару раз в неделю. Не должно занимать больше, я бы сказал, семи-восьми часов в неделю. Я могу привести вас туда за короткое время и научить этому навыку, который может полностью трансформировать вашу организацию. Если вы хотите узнать больше, нажмите на ссылки внизу или ссылки в заметках и с нетерпением жду встречи с вами в этой когорте сборщиков.