Я не просто так написал. Я очень хреновый программист - ллмки слелали жизнь легче.
Выгрузку данных из кабинета яндекса по апи в битрикс24 делал пару лет назад, без ллм - умудохался знатно.
Да и с ллм приходится сильно помучатся - в основном проверкой "то ли я получил, что хотел" и вот эта часть не работает без понимания, как оно тут появилось и если вы не уверены, что получили, что надо и ограничения при этом возникающие - вы не можете доверять данным и от этого они даже не бессмысленны, а даже вредны.
Именно в этом ключевая проблема использования нейронок в целом, они дают буст в местах, которые ты и сам мог бы сделать т.к. только в этом случае ты видишь косяки.
Поэтому если вы от "руками" перешли к автоматизации через клешню, вы пропустили шаг просто автоматизации в котором должно наступить понимание - мое личное мнение, основанное на десятках мелких автоматизашек через апи. в которых чего только не встречалось.
Кривая документация, ошибки в самих апи или том, что их дергает - при этом данные выглядели "валидно". Не столкнувшись с этим ваши автоматизторы не попросят делать кросс-чеки.
В этом проблема ноукод, зерокод, ллмкод, вайбкод и просто клешня безкод - оно как-то решает все более похоже на правду, но без экспертизы минимальной хотя бы "что должно быть внутри" подучается "наукообразная фигня".
вопрос не в инструментарии, вопрос в том почему у вас не было до сих пор ввгрузки из кабинетов метрек, если это ваша основная деятельность.
какой-то опять я токсичный - но нет, со всей душой. занимаюсь местами тем же ;)
но расстраиваюсь, что все равно потом приходется лезть руками в код.
Я прочел мы дергаем 5 апи питоном и складываем в гуглотабличку - ок я тоже так делаю и ничего против не имею "набросать все это" llmкой
Еще мы юзаем плэйрайт, чтобы собрать из dom все тем же питоном. таак и это тоже зачем в компании нужен был "автоматизатор" или немножко программист.
Где тут необходимость в переплате за токены для опенкло я не вижу.
Почему у вас сотрудники, если вы открылись не осенью хотя бы нокод какими-то штуками не автоматизировали свою рутину - вопрос к управленьческим решениям.
Я тут звучу "токсично" что ли. Но, как старый дед в своё оправдание скажу, что каждые полгода вижу восторги новой штукой, с которой все носятся. А по факту в 90% случаев "неофиты открыли, что в экселе есть формулы" ;).
я уж совсем злобным побуду, вдруг про conditional formating в эксельках еще кто-то не знает - это же чудо, как без всякого ии и дашбордов со свистоперделками можно данные визуально выделять ;)
Короче тема не раскрыта, как будто llm тут закодить помогло, не самым оптимальным способом. ну ок.
Исследование пользовательского опыта часть моей работы. В специфических проектах, когда точка 0 - не было автоматизации, точка 1 - есть автоматизация, мало кто пиняет на интерфейс :) Не мне вам рассказывать скриптики "для себя" обходятся вовсе без него годами.
Делать сразу чуть лучше и учитывать базовое помогает насмотренность и прочесть что-то по проектированию интерфейсов - условно "как не надо делать" уже даёт хорошее понимание.
Есть базовые вещи:
вёрстка табличных данных
иерархия объектов
групировка объектов
цветовое кодирование и подсветка
как наш взгляд сканирует интерфейсы
К сожалению прям конкретные материалы не вспоминаются. Если вспомню - напишу.
Вопрос не в мощности железа, а в том какие задачи решаешь, и насколько тебя интересует "налог на эффективность" в виде обязательных но не ключевых действий. Я несколько лет работал в фотолаборатории во времена, когда люди еще приходили распечатать 200 фоток и таких в августе было десятки в день. Скорость работы с файлами - это ключевой параметр эффективности в приеме заказов, учитывая, что клиенты просто приносили компакт диск или флешку, естественно в не отсортированном виде.
Сейчас ничего не изменилось. Как только есть необходимость работы с десятками или сотнями файлов (я не беру кейсы работы с серверами) человек с мышкой выигрывает только у человека с айфонов, и оба крайне удивляются, что задачу - разгребсти сотни файлов 1. можно решить 2. можно решить крайне быстро
Статья отличная. NC VC DN в сердце. TC - до сих пор пользуюсь :)
Перевод и генерация текста. Плюс категоризатор. На глаз 10к+ запросов уже никаких проблем с json не было. Его формат и инструкция "отдавай только json в конце промпта"
2/3 этих запросов это текст с html вёрсткой ограниченной определённым набором тегов, и я ожидал, что могут возникнуть проблемы, но пока не было.
Гуглинг, реверс-инженирнг чужик поделок, просмотр доков на другие языки. :)
Кто подбирал нужную версию .dll с компакт дисков пиратских почитав предварительно .inf файлы тот на такой фигне не пасуют. Интернеты есть, llm есть (не редко врёт, но и на мысли может натолкнуть :)
Не касаемо Битрикс апи, а в целом: Про структуру запроса - обычно подобные косяки с добавлением информации по API POST/PUT и т.д. - Если не получилось с копипэйста из документации, как правило имеет смысл GET и уже по полученной структуре разгребать. - не редко всё настолько непонятно, что приходится заполнить все поля в UI сначала данными типа field_name и цифрами/датами остальное :))
- бывает нужна магия, например в Zoho CRM был глюк один их методов работал только со строчной переменной, хотя и в документации и в том, что приходило по GET был массив. Как я догадался? естественно случайно :) - с другой стороны это то почему я не верю в скорую победу ИИ над кожанными мешками :)
Расстраивает, что в нашей части мира (не претендую на объектиность) реже на это обращают внимание. Справедливости ради, плохая документация много у кого, и если сейчас появились объективные причины (весь мир не дружит с нами и риски по opensource), то почему раньше не использовался софт для представления документации в приличном и удобном виде - не понятно.
Для меня критерий простой, возможность очень быстро набросать на python/powershell тестовые запросы и понять, что надо на вход и что получаем на выходе.
Я когда-то был приятно поражен документацие stripe с тех пор видел массу примеров западных сервисов ничуть не хуже.
Наличие песочниц (понятно, что это мега дорого) это вообще какая-то запредельная технология - видел только у Яндекса из РУ сегмента.
Гугл документацию по API тоже не назовешь удобной, не врёт но пользоваться ей - боль.
Столкновение с 1с всегда боль. Зашел посмотреть "а вдруг!". а вдруг например апи какое приличное, с понятной документацей
нет. нифига. ;) .
всегда когда можно 1с не касаться - очень стараюсь делать так.
вот в очередной раз, нужен банальный флоу - взяли номенклатуру, добавили переводом с помощью ллм. запихали в тильду и обратно в 1с. тут дальше кроме матов нельзя описать процесс. тупо проще выгружать в таличку/бд и в ней все сделать и хранить. и быстрен. и вероятно надежнее. и да "бог 1с" быстро сделал мега метод "брать айди номенклатуры и показывать в отчете", ведь сука по нему синхронизируются остатки потом с сайтом, но блять почему это так через жопу?... не знаю можно ли матами ругаться тут. но похер. тупо убита куча времени. и так вот чего не коснись. а оно ещё и тупит а товаров всего 2к..
хотя недавно вот заглянул в документацию битрикс24 по апи - наконец-то стало возможно пользоваться без крови из глаз. может давно. прошлый подход заставил страдать, хотя есть вопросики "а почему бы питон еще не добавить в примеры", но к счастью llm'ки для быстро переводят с curl.
нет кейса когда мне помог бот, и еще со времен телефонных автоответчиков всё это раздражало ;)
тут на хабре большинстао включая меня, не являемся теми, кто стучится в поддержку не проверив возможности других интерфейсов. поэтому мы можем быть нерелевантны для оценки полезности ;)
хуже ботов, операторы поддержки работающие по скрипту - сталкивался с таким в Британии очень давно. Без матов не описать ;)
вы затронули прекрасный вопрос, который не затронут в обзоре. Это возможности и улобство api.
Нагуглить 100 акрвисов проблемы нет и все это парсится каким-то перпоексити. А когда действительно ищешь решение для конкретной команды смтришь, как оно встанет с другими штуками, какие у тебя уже есть или будут. Поэтому api и интеграции это очень важный элемент.
И да, по моему небольшому опыту с api и документациями к нему в Ру нетете очень так себе, пока не имею опыта, который записал бы, как положительный. Прежде всего из-за отсутствия стандарта документации с примерами на нескольких языках и возможностью протестировать прямо в документации простые запросы, что очень радует в глобальных вервисах, хоть и не всех.
Дело всё в то, что концентрированная мудрость не работает. Она становится "фразой великих" Омара Хаяма, Чехова и т.п. , которую себе повесят "на стену в вк".
Некоторое количество воды, иногда большое и повторение мысли с разных сторон позволяют её "примерить на себя". Разные ракурсы позволяют подобрать фасон для большего количества услышавших.
У например продажников которых вы имеете ввиду понятные метрики и их влияние на деньги. 100 звонков или 20 лидов или 2 сделки. (упрощаю, как и вы) Причем, как правило с весьма погнозируемыми конверсиями.
У программистов и многих других профессий результаты сильно растянуты во времени, сложно оценимый вклад конкретного человека для него же самого. Не понятное влияние на конечный результат.
Звучит интересно, но хочется больше деталей.
Что за модели? Тех стек реализации?
Если детали по тому чем занимается компания секретный секрет, то хотя бы b2b или b2c (вроде второе).
по процессам претензии на маркетплейсах, почта, форма на сайте?
А то - мы молодцы! на 300 тонн удоев чугуна больше в два раза быстрее, чем у лучших сабоководов.
Я не просто так написал. Я очень хреновый программист - ллмки слелали жизнь легче.
Выгрузку данных из кабинета яндекса по апи в битрикс24 делал пару лет назад, без ллм - умудохался знатно.
Да и с ллм приходится сильно помучатся - в основном проверкой "то ли я получил, что хотел" и вот эта часть не работает без понимания, как оно тут появилось и если вы не уверены, что получили, что надо и ограничения при этом возникающие - вы не можете доверять данным и от этого они даже не бессмысленны, а даже вредны.
Именно в этом ключевая проблема использования нейронок в целом, они дают буст в местах, которые ты и сам мог бы сделать т.к. только в этом случае ты видишь косяки.
Поэтому если вы от "руками" перешли к автоматизации через клешню, вы пропустили шаг просто автоматизации в котором должно наступить понимание - мое личное мнение, основанное на десятках мелких автоматизашек через апи. в которых чего только не встречалось.
Кривая документация, ошибки в самих апи или том, что их дергает - при этом данные выглядели "валидно". Не столкнувшись с этим ваши автоматизторы не попросят делать кросс-чеки.
В этом проблема ноукод, зерокод, ллмкод, вайбкод и просто клешня безкод - оно как-то решает все более похоже на правду, но без экспертизы минимальной хотя бы "что должно быть внутри" подучается "наукообразная фигня".
вопрос не в инструментарии, вопрос в том почему у вас не было до сих пор ввгрузки из кабинетов метрек, если это ваша основная деятельность.
какой-то опять я токсичный - но нет, со всей душой. занимаюсь местами тем же ;)
но расстраиваюсь, что все равно потом приходется лезть руками в код.
Из вашего кейса не понятно за чем вам "клешня".
Я прочел мы дергаем 5 апи питоном и складываем в гуглотабличку - ок я тоже так делаю и ничего против не имею "набросать все это" llmкой
Еще мы юзаем плэйрайт, чтобы собрать из dom все тем же питоном. таак и это тоже зачем в компании нужен был "автоматизатор" или немножко программист.
Где тут необходимость в переплате за токены для опенкло я не вижу.
Почему у вас сотрудники, если вы открылись не осенью хотя бы нокод какими-то штуками не автоматизировали свою рутину - вопрос к управленьческим решениям.
Я тут звучу "токсично" что ли. Но, как старый дед в своё оправдание скажу, что каждые полгода вижу восторги новой штукой, с которой все носятся. А по факту в 90% случаев "неофиты открыли, что в экселе есть формулы" ;).
я уж совсем злобным побуду, вдруг про conditional formating в эксельках еще кто-то не знает - это же чудо, как без всякого ии и дашбордов со свистоперделками можно данные визуально выделять ;)
Короче тема не раскрыта, как будто llm тут закодить помогло, не самым оптимальным способом. ну ок.
Исследование пользовательского опыта часть моей работы. В специфических проектах, когда точка 0 - не было автоматизации, точка 1 - есть автоматизация, мало кто пиняет на интерфейс :)
Не мне вам рассказывать скриптики "для себя" обходятся вовсе без него годами.
Делать сразу чуть лучше и учитывать базовое помогает насмотренность и прочесть что-то по проектированию интерфейсов - условно "как не надо делать" уже даёт хорошее понимание.
Есть базовые вещи:
вёрстка табличных данных
иерархия объектов
групировка объектов
цветовое кодирование и подсветка
как наш взгляд сканирует интерфейсы
К сожалению прям конкретные материалы не вспоминаются. Если вспомню - напишу.
Вопрос не в мощности железа, а в том какие задачи решаешь, и насколько тебя интересует "налог на эффективность" в виде обязательных но не ключевых действий.
Я несколько лет работал в фотолаборатории во времена, когда люди еще приходили распечатать 200 фоток и таких в августе было десятки в день. Скорость работы с файлами - это ключевой параметр эффективности в приеме заказов, учитывая, что клиенты просто приносили компакт диск или флешку, естественно в не отсортированном виде.
Сейчас ничего не изменилось. Как только есть необходимость работы с десятками или сотнями файлов (я не беру кейсы работы с серверами) человек с мышкой выигрывает только у человека с айфонов, и оба крайне удивляются, что задачу - разгребсти сотни файлов
1. можно решить
2. можно решить крайне быстро
Статья отличная. NC VC DN в сердце.
TC - до сих пор пользуюсь :)
И в метрическую систему переход..
Использую deepseek по api, дергаю питоном.
Перевод и генерация текста. Плюс категоризатор. На глаз 10к+ запросов уже никаких проблем с json не было. Его формат и инструкция "отдавай только json в конце промпта"
2/3 этих запросов это текст с html вёрсткой ограниченной определённым набором тегов, и я ожидал, что могут возникнуть проблемы, но пока не было.
Решение подобных задач это круто.
Но как интерфейс это очень плохо, прежде всего тем, что очень большая когнитивная нагрузках в попытках считать:
из-за отсутсвия вёрстки, хотя бы банального выравнивания элементов цифр, независимость его от -/+ значений
красные рамки частично прилипают к именованиям объектов, отчего те не читаемы до конца
плохо просматривается или отсутствует иерархия объектов и их значений
на примере со слайдером не понятен ни шаг, ни границы значений
Про то, что утилитарное не должно быть уродливым, упомяну, но в отличии от вышеописанного, согласен обозвать вкусовщиной.
Средней руки дизайнер, пожелавший вникнуть в проблему способен очень сильно улучшить функциональность вашего продукта.
Даже чисто текстовыми средствами достигнуть можно шикарнейших результатов.
Гуглинг, реверс-инженирнг чужик поделок, просмотр доков на другие языки. :)
Кто подбирал нужную версию .dll с компакт дисков пиратских почитав предварительно .inf файлы тот на такой фигне не пасуют. Интернеты есть, llm есть (не редко врёт, но и на мысли может натолкнуть :)
Не касаемо Битрикс апи, а в целом:
Про структуру запроса - обычно подобные косяки с добавлением информации по API POST/PUT и т.д.
- Если не получилось с копипэйста из документации, как правило имеет смысл GET и уже по полученной структуре разгребать.
- не редко всё настолько непонятно, что приходится заполнить все поля в UI сначала данными типа field_name и цифрами/датами остальное :))
- бывает нужна магия, например в Zoho CRM был глюк один их методов работал только со строчной переменной, хотя и в документации и в том, что приходило по GET был массив. Как я догадался? естественно случайно :)
- с другой стороны это то почему я не верю в скорую победу ИИ над кожанными мешками :)
Спасибо.
Вопросы и по документации и по песочницам..
Расстраивает, что в нашей части мира (не претендую на объектиность) реже на это обращают внимание.
Справедливости ради, плохая документация много у кого, и если сейчас появились объективные причины (весь мир не дружит с нами и риски по opensource), то почему раньше не использовался софт для представления документации в приличном и удобном виде - не понятно.
Для меня критерий простой, возможность очень быстро набросать на python/powershell тестовые запросы и понять, что надо на вход и что получаем на выходе.
Я когда-то был приятно поражен документацие stripe с тех пор видел массу примеров западных сервисов ничуть не хуже.
Наличие песочниц (понятно, что это мега дорого) это вообще какая-то запредельная технология - видел только у Яндекса из РУ сегмента.
Гугл документацию по API тоже не назовешь удобной, не врёт но пользоваться ей - боль.
Столкновение с 1с всегда боль. Зашел посмотреть "а вдруг!". а вдруг например апи какое приличное, с понятной документацей
нет. нифига. ;) .
всегда когда можно 1с не касаться - очень стараюсь делать так.
вот в очередной раз, нужен банальный флоу - взяли номенклатуру, добавили переводом с помощью ллм. запихали в тильду и обратно в 1с. тут дальше кроме матов нельзя описать процесс. тупо проще выгружать в таличку/бд и в ней все сделать и хранить. и быстрен. и вероятно надежнее. и да "бог 1с" быстро сделал мега метод "брать айди номенклатуры и показывать в отчете", ведь сука по нему синхронизируются остатки потом с сайтом, но блять почему это так через жопу?... не знаю можно ли матами ругаться тут. но похер. тупо убита куча времени. и так вот чего не коснись. а оно ещё и тупит а товаров всего 2к..
хотя недавно вот заглянул в документацию битрикс24 по апи - наконец-то стало возможно пользоваться без крови из глаз. может давно. прошлый подход заставил страдать, хотя есть вопросики "а почему бы питон еще не добавить в примеры", но к счастью llm'ки для быстро переводят с curl.
TL:DR конечно и слог черезчур одухотворённый и пафосный, но суть местами докидала элементов в мой пазл о LLM. Спасибо.
Два момента:
нет кейса когда мне помог бот, и еще со времен телефонных автоответчиков всё это раздражало ;)
тут на хабре большинстао включая меня, не являемся теми, кто стучится в поддержку не проверив возможности других интерфейсов. поэтому мы можем быть нерелевантны для оценки полезности ;)
хуже ботов, операторы поддержки работающие по скрипту - сталкивался с таким в Британии очень давно. Без матов не описать ;)
вы затронули прекрасный вопрос, который не затронут в обзоре. Это возможности и улобство api.
Нагуглить 100 акрвисов проблемы нет и все это парсится каким-то перпоексити. А когда действительно ищешь решение для конкретной команды смтришь, как оно встанет с другими штуками, какие у тебя уже есть или будут. Поэтому api и интеграции это очень важный элемент.
И да, по моему небольшому опыту с api и документациями к нему в Ру нетете очень так себе, пока не имею опыта, который записал бы, как положительный. Прежде всего из-за отсутствия стандарта документации с примерами на нескольких языках и возможностью протестировать прямо в документации простые запросы, что очень радует в глобальных вервисах, хоть и не всех.
Слышал у аналитиков "какую бы крутую талзу вы не испольовали" все равно на каком-то шаге есть эксель ;)
Спасибо за инструмент, поиграюсь.
уставшесть тех, кто читает твитер, как и хабр это ежедневные неправильные действия, в большинстве случаев.
Дело всё в то, что концентрированная мудрость не работает. Она становится "фразой великих" Омара Хаяма, Чехова и т.п. , которую себе повесят "на стену в вк".
Некоторое количество воды, иногда большое и повторение мысли с разных сторон позволяют её "примерить на себя". Разные ракурсы позволяют подобрать фасон для большего количества услышавших.
Написано цепляюще даже в переводе ;)
У например продажников которых вы имеете ввиду понятные метрики и их влияние на деньги. 100 звонков или 20 лидов или 2 сделки. (упрощаю, как и вы) Причем, как правило с весьма погнозируемыми конверсиями.
У программистов и многих других профессий результаты сильно растянуты во времени, сложно оценимый вклад конкретного человека для него же самого. Не понятное влияние на конечный результат.
Если месяц выдержите в системе "складывать нужное на место" вы заметите ощутимое высвобождение времени и уменьшение суеты.
Сложно первые пару недель т.к. напряг будет перевешивать выхлоп.
Через месяца два-три - уже сложно возвращаться "к бардаку" ;)
Единственный стоит учесть - любая система постепенно будет менятся и усложнятся.