Раньше один из пользователей спросил меня, какой у меня процесс разработки ИИ. Как раз на днях я с помощью ИИ реализовал небольшой функционал — его как раз стоит показать в качестве примера, и он может послужить ориентиром.
История началась с того, что пользователь написал мне в GitHub Issues (рис. 1) и спросил, можно ли добавить в приложение для субтитров, транскрипции и перевода BaoCut функцию удалённой транскрипции.
То есть у меня две машины: одна — мощный компьютер A с видеокартой NVIDIA, другая — обычный рабочий компьютер B. Я хочу использовать вычислительную мощность компьютера A, но обычно работаю только на компьютере B. Когда на компьютере B я использую BaoCut для транскрипции, я хочу, чтобы вычислительную работу по транскрибированию выполнял компьютер A.
Мне сразу показалось, что это хороший запрос, но я раньше не делал подобного и не знал, осуществимо ли это.
Поэтому мой первый шаг был не сразу писать код, а сначала провести анализ осуществимости.
I. Анализ осуществимости
Если без анализа сразу начать действовать, можно наделать слишком много ошибок. Я очень часто из‑за этого просто зря тратил время. Кроме того, даже после анализа иногда можно принять неверное решение. Например, несколько дней назад я сделал локальную текстовую модель, чтобы помогать разбивать и выравнивать данные. На этапе анализа осуществимости всё казалось нормальным, но когда я попробовал на практике, оказалось, что результат ужасный. В итоге всё равно пришлось выкинуть — и это заняло несколько дней и съело много токенов, к счастью, только токены.
Анализ осуществимости обычно включает два уровня:
Один — с точки зрения продукта: есть ли ценность для пользователей, соответствует ли это позиционированию приложения.
Второй — с технической точки зрения: реально ли это сделать, контролируемы ли затраты.
Здесь, с продуктовой точки зрения, я считал, что функция пользователям будет полезна и она соответствует концепции продукта, поэтому я сосредоточился только на технической стороне — на анализе осуществимости.
Я отправил исходные требования в Claude Code, чтобы оно, опираясь на текущее состояние проекта, сделало анализ (рис. 2). После анализа оно вынесло вердикт: что это возможно, и предложило несколько вариантов (рис. 3).
Эти варианты легче понять, если иметь чуть больше технического фона. Я после прочтения быстро сформировал своё мнение:
Вариант 0 и вариант C, хотя и не требуют менять код, для пользователя слишком неудобны — человеку нужно самому разбираться и собирать ASR‑сервер.
Вариант A выглядит отлично: достаточно установить приложение и можно будет просто запускать собственный сервис транскрипции.
Вариант B плохо подходит для Windows.
Поэтому я решил идти по варианту A. А вариант 0, хоть и оказался сомнительным, всё же содержит в себе неплохой дополнительный бонус — HTTP API для транскрипции. Его тоже можно было бы подключить “заодно”.
II. Написание дизайн-документа
После того как стало ясно, что это осуществимо, и одновременно мы зафиксировали предварительный технический план, я тоже сразу не начал писать код — сначала составил дизайн‑документ.
Этот дизайн‑документ скорее похож на смесь product design document и технического design proposal. Примерно он должен описывать: сформулированные требования, архитектуру и совмещённое с этим описание UI.
Цель — чтобы ИИ помог структурировать, какие технологии понадобятся для реализации, каково текущее состояние проекта, и зафиксировать всё это в документах. Тогда при внедрении будет хороший ориентир, а в будущем для поддержки и сопровождения это тоже пригодится. Самое важное — человек может подтвердить, что выбранное направление верное (см. рис. 4).
Конечно, признаю: здесь я немного поленился — фактически сразу попросил его написать документацию и после этого приступать к работе. Во многом потому, что я посмотрел на предложенные ранее варианты и они не выглядели проблемными, плюс я в целом доверяю Fable — при возможности лучше всё же проверить детальнее.
III. Прототипирование
Я сначала делаю прототип вместо того, чтобы писать код, потому что прототипирование позволяет недорого проверить потребность и быстро определить дизайн интерфейса и механику взаимодействия. Здесь я уже установил baoyu-design skill (github.com/jimliu/baoyu-design), поэтому достаточно сказать про прототип — и оно автоматически сгенерирует.
У моего приложения есть страница прототипов. Каждый раз, когда я добавляю или меняю функциональность, я сначала обновляю страницу прототипирования.
Имея заранее дизайн‑документ, прототипирование в целом прошло довольно гладко: уже первый вариант (рис. 5) дал неплохой результат. В странице настроек появился новый раздел, где можно включить сервис и увидеть ноды.
Обратите внимание: мой прототип — это по сути высокоточный прототип, объединяющий прототипирование и UI‑дизайн. То есть прототип уже является UI‑дизайном. Это одна из ключевых особенностей Claude Design.
После готовности прототипа его всё равно нужно подправлять. На этом этапе человеку важно дать обратную связь, чтобы агент мог скорректировать, например, в моём случае я многократно вносил правки (см. рис. 6).
Сначала я поменял раскладку на Tab: включение сервиса и доступ к другим нодам разделены, потому что я считал это двумя разными сценариями. Затем добавил отображение иконками состояния сервиса, чтобы по значкам было сразу понятно, сервис запущен или остановлен (см. рис. 7).
Потом я понял, что держать это в настройках неудобно для просмотра состояния, и перенёс всё на главную страницу. В итоге почувствовал, что уже почти готово (рис. 8, рис. 9).
IV. Реализация
Если у вас уже есть дизайн‑документ и готовый прототип (UI), то для текущих агентов написать код с помощью ИИ — это довольно простая задача.
Обычно на этом этапе я вместе с /goal отправляю документацию в Claude Code (Fable 5) для выполнения. Оно реализует шаг за шагом по плану Milestones, описанному в документах, и само делает скриншоты для валидации результата (рис. 10, рис. 11).
V. Тестирование и проверка
Да, агент будет помогать нам проверять, но это не значит, что можно полностью доверять результатам ИИ. Дальше всё равно нужно вручную несколько раз прогнать всё, что нужно, собрать обнаруженные проблемы и передать их агенту, чтобы он их исправил (рис. 12).
После нескольких таких итераций всё стало достаточно рабочим.
Посмотрите на финальный результат (рис. 13, рис. 14).
Если вы спросите, делал ли я Review кода?
Нет. Я относился к себе как к QA и делал только black‑box тестирование. Я всё равно верю в возможности Fable.
История началась с того, что пользователь написал мне в GitHub Issues (рис. 1) и спросил, можно ли добавить в приложение для субтитров, транскрипции и перевода BaoCut функцию удалённой транскрипции.
То есть у меня две машины: одна — мощный компьютер A с видеокартой NVIDIA, другая — обычный рабочий компьютер B. Я хочу использовать вычислительную мощность компьютера A, но обычно работаю только на компьютере B. Когда на компьютере B я использую BaoCut для транскрипции, я хочу, чтобы вычислительную работу по транскрибированию выполнял компьютер A.
Мне сразу показалось, что это хороший запрос, но я раньше не делал подобного и не знал, осуществимо ли это.
Поэтому мой первый шаг был не сразу писать код, а сначала провести анализ осуществимости.
I. Анализ осуществимости
Если без анализа сразу начать действовать, можно наделать слишком много ошибок. Я очень часто из‑за этого просто зря тратил время. Кроме того, даже после анализа иногда можно принять неверное решение. Например, несколько дней назад я сделал локальную текстовую модель, чтобы помогать разбивать и выравнивать данные. На этапе анализа осуществимости всё казалось нормальным, но когда я попробовал на практике, оказалось, что результат ужасный. В итоге всё равно пришлось выкинуть — и это заняло несколько дней и съело много токенов, к счастью, только токены.
Анализ осуществимости обычно включает два уровня:
Один — с точки зрения продукта: есть ли ценность для пользователей, соответствует ли это позиционированию приложения.
Второй — с технической точки зрения: реально ли это сделать, контролируемы ли затраты.
Здесь, с продуктовой точки зрения, я считал, что функция пользователям будет полезна и она соответствует концепции продукта, поэтому я сосредоточился только на технической стороне — на анализе осуществимости.
Я отправил исходные требования в Claude Code, чтобы оно, опираясь на текущее состояние проекта, сделало анализ (рис. 2). После анализа оно вынесло вердикт: что это возможно, и предложило несколько вариантов (рис. 3).
Эти варианты легче понять, если иметь чуть больше технического фона. Я после прочтения быстро сформировал своё мнение:
Вариант 0 и вариант C, хотя и не требуют менять код, для пользователя слишком неудобны — человеку нужно самому разбираться и собирать ASR‑сервер.
Вариант A выглядит отлично: достаточно установить приложение и можно будет просто запускать собственный сервис транскрипции.
Вариант B плохо подходит для Windows.
Поэтому я решил идти по варианту A. А вариант 0, хоть и оказался сомнительным, всё же содержит в себе неплохой дополнительный бонус — HTTP API для транскрипции. Его тоже можно было бы подключить “заодно”.
II. Написание дизайн-документа
После того как стало ясно, что это осуществимо, и одновременно мы зафиксировали предварительный технический план, я тоже сразу не начал писать код — сначала составил дизайн‑документ.
Этот дизайн‑документ скорее похож на смесь product design document и технического design proposal. Примерно он должен описывать: сформулированные требования, архитектуру и совмещённое с этим описание UI.
Цель — чтобы ИИ помог структурировать, какие технологии понадобятся для реализации, каково текущее состояние проекта, и зафиксировать всё это в документах. Тогда при внедрении будет хороший ориентир, а в будущем для поддержки и сопровождения это тоже пригодится. Самое важное — человек может подтвердить, что выбранное направление верное (см. рис. 4).
Конечно, признаю: здесь я немного поленился — фактически сразу попросил его написать документацию и после этого приступать к работе. Во многом потому, что я посмотрел на предложенные ранее варианты и они не выглядели проблемными, плюс я в целом доверяю Fable — при возможности лучше всё же проверить детальнее.
III. Прототипирование
Я сначала делаю прототип вместо того, чтобы писать код, потому что прототипирование позволяет недорого проверить потребность и быстро определить дизайн интерфейса и механику взаимодействия. Здесь я уже установил baoyu-design skill (github.com/jimliu/baoyu-design), поэтому достаточно сказать про прототип — и оно автоматически сгенерирует.
У моего приложения есть страница прототипов. Каждый раз, когда я добавляю или меняю функциональность, я сначала обновляю страницу прототипирования.
Имея заранее дизайн‑документ, прототипирование в целом прошло довольно гладко: уже первый вариант (рис. 5) дал неплохой результат. В странице настроек появился новый раздел, где можно включить сервис и увидеть ноды.
Обратите внимание: мой прототип — это по сути высокоточный прототип, объединяющий прототипирование и UI‑дизайн. То есть прототип уже является UI‑дизайном. Это одна из ключевых особенностей Claude Design.
После готовности прототипа его всё равно нужно подправлять. На этом этапе человеку важно дать обратную связь, чтобы агент мог скорректировать, например, в моём случае я многократно вносил правки (см. рис. 6).
Сначала я поменял раскладку на Tab: включение сервиса и доступ к другим нодам разделены, потому что я считал это двумя разными сценариями. Затем добавил отображение иконками состояния сервиса, чтобы по значкам было сразу понятно, сервис запущен или остановлен (см. рис. 7).
Потом я понял, что держать это в настройках неудобно для просмотра состояния, и перенёс всё на главную страницу. В итоге почувствовал, что уже почти готово (рис. 8, рис. 9).
IV. Реализация
Если у вас уже есть дизайн‑документ и готовый прототип (UI), то для текущих агентов написать код с помощью ИИ — это довольно простая задача.
Обычно на этом этапе я вместе с /goal отправляю документацию в Claude Code (Fable 5) для выполнения. Оно реализует шаг за шагом по плану Milestones, описанному в документах, и само делает скриншоты для валидации результата (рис. 10, рис. 11).
V. Тестирование и проверка
Да, агент будет помогать нам проверять, но это не значит, что можно полностью доверять результатам ИИ. Дальше всё равно нужно вручную несколько раз прогнать всё, что нужно, собрать обнаруженные проблемы и передать их агенту, чтобы он их исправил (рис. 12).
После нескольких таких итераций всё стало достаточно рабочим.
Посмотрите на финальный результат (рис. 13, рис. 14).
Если вы спросите, делал ли я Review кода?
Нет. Я относился к себе как к QA и делал только black‑box тестирование. Я всё равно верю в возможности Fable.