Комментарии 59
Claude Design тратит недельный лимит в подписке за 20$ примерно за 1-3 запроса. На этом обсуждение его преимуществ для задачи вывода информации можно закрыть
Claude design упоминается в статье только в "почему не claude design". К чему ваш комментарий?
Ну допустим упоминается дважды. Да, мой косяк, в статье предлагается в Claude Code выводить дизайнерский html. Причем на Opus 4.7 с 1М контекста. В этом режиме и Claude Code скушает всю подписку за пару запросов.
Можно claude code запустить через --model "claude-opus-4-7" (без добавления [1m]) должен ограничить 262к контекста, как у легаси моделей, по крайней мере так работало в день релиза опуса 4.7
Если не сработает можно поковырять переменные окружения - процентаж, если что, лучше оставлять на 80, а вот само контекстное окно можно поменять - поставить 350 тысяч например. Ставится в ~/.claude/settings.json
Клод за 20 это так у них, вроде демки.
С таким подходом можно писать статью почему секретарь лучше чем markdown. Потому что секретарю можно дать задание и он создаст презентацию которая будет красивее чем markdown.
Чтобы понять что html даёт больше возможностей чем markdown достаточно знать что markdown трансформируется в html.
<зануда мод>
Нет, так можно лишь понять что html дает не меньше возможностей чем маркдаун =)
</зануда мод>
Ну давайте тогда записывать всё на ассемблере или в машинных кодах.
Markdown используется по той простой причине, что html неудобно читать и редактировать. Точка.
Согласен, что html не нужен хватает связки markdown и mermaid. Mermaid - инструмент специально предназначенный для рисования диаграмм, а гипертекст поддерживает и markdown.
Сколько уязвимостей можно доставить через html и сколько через markdown?
Кажется вопрос почему markdown закрыт
А зачем ИИ доставлять своему же (тем более платящему) клиенту уязвимости? 🤔
Потому что ИИ ошибся и сделал это нечаянно. А ещё потому, что существуют атаки типа промпт-инъекция и supply chain attack, ведущие к тому, что "ваш" ИИ начинает выполнять инструкции атакующего.
Так. И какие же риски добавляет локальный html, который я открываю в локальном браузере по сравнению с md, учитывая что в обоих случаях у меня агент, который имеет доступ к консоли?
Если у агента есть доступ к выполнению команд - никаких.
Но доступ к консоли для генерации html не обязателен. И тут разница уже появляется, потому что в маркдаун проблематично засунуть выполняемый код, особенно незаметно - в отличие от html.
А вообще я отвечал на конкретный комментарий, никак не связанный с дилеммой mardkown/html.
В контексте создания временных HTML "на посмотреть" это все не актуально - промпт-иньекции и sca неоткуда взяться.
В контексте промпт-инъекций абсолютно не важно, что создаёт агент - важно какими источниками он при этом пользуется. Если разрешить ИИ использовать поиск в инете или что-то скачивать из инета - появляется возможность и для промпт-инъекций/sca. И даже без прямого доступа в инет, если пользователь сам где-то скачал недоверенные данные (получил по почте PDF, например, или склонировал локально сторонний репо) и потом передал их ИИ - тоже возникает возможность промпт-инъекции.
При создании HTML-файла с размышлениями модели промпт-иньекции взяться неоткуда. Если она у вас уже прошла, то там совершенно не до формата документов: у вас уже все что надо уведут, вам не надо для этого никаких документов создавать и даже открывать.
При создании HTML-файла с размышлениями модели промпт-иньекции взяться неоткуда.
Если при создании модели доступен поиск в инете или Вы сами передали ей данные полученные из недоверенного источника - то есть откуда.
Если она у вас уже прошла, то там совершенно не до формата документов: у вас уже все что надо уведут,
Если у модели есть доступ к соответствующим инструментам - да.
Но если у модели нет доступа к запуску команд, и либо нет доступа к изменению локальных файлов либо этот доступ ограничен каталогом текущего проекта (т.е. сделать инъекцию в ~/.bashrc модель не может), то ей остаётся отдавать Вам файлы с кодом (либо создавать их в каталоге проекта и надеяться что Вы сами их выполните, либо отдавать содержимое файла прямо в чате - вроде обсуждаемого html - и надеяться что Вы его откроете в приложении которое выполнит код). И вот в этих ситуациях md определённо безопаснее html.
Спасибо за статью, пришла вовремя! Как раз этого пазла не хватало для создания своей базы знаний
Еще cloude code хорошо умеет банить аккаунты
Типичная проблема кожаного мешка, раздутая в чёрти что. Вместо того, чтобы создать простой сервис визуализации md в HTML будем заниматься дуростью, прелестно. Сначала потратим токены на генерацию, потом ещё на повторное изучение документации для внесения изменений. Время дешёвых подписок заканчивается, не надо к ним привыкать.
Для начала надо учиться выявлять истинную причину и лечить её, а не забивать гвозди микроскопом. Иначе в роли микроскопа уже сама нейросеть. "Дай дураку член стеклянный..." писали много лет назад бородатые дядьки на одном прогерском форуме, подстёбывая молодёжь. В принципе, ничего особо не поменялось)))
Да, да меня стало неожиданностью, что, например, в md нет переноса строки внутри ячейки и впендюривается тег <br>. Но это ещё не повод усложнять.
Графика, схемы? Есть языки для отрисовки схем на основе простого описания текстом логики связей.
Зато я знатно поплевался с документации апишки МангоТелеком в PDF, которую хотел дать нейронке. Я конвертировал в docx, HTML, пробовал разные сервисы, в итоге получалось говнище размером 15-20 мегабайт, ещё и искарёженное. Вот где адЪ и матЪ.
Надо отдать должное Битриксу - у них теперь портал документации в гите. Есть mcp, но и без него можно скачать конкретную статью или дать агенту ссылку на файл без вёрстки.
А для "мешков" с браузерами эти md прекрасно рендерятся в обычный сайтик. Вот где разумность.
Я конвертировал в docx, HTML, пробовал разные сервисы, в итоге получалось говнище размером 15-20 мегабайт, ещё и искарёженное. Вот где адЪ и матЪ
Я просто попросил написать мне конвертилку из PDF в docx и далее в HTLM в VisualBasic (собственно, у меня была структура каталогов PDF, так-то для одного файла это быстрее ручками сделать).
Сложно ошибиться, как по мне. Возможно, форматирование в исходном PDF было через одно место уже изначально.
Да, да меня стало неожиданностью, что, например, в md нет переноса строки внутри ячейки и впендюривается тег <br>. Но это ещё не повод усложнять.
Это Вы, так сказать, лишь слегка коснулись проблемы крылом - в md почти невозможна даже двухуровневая структура "таблица в таблице", а в стандартах PDF встречаются и более экзотические варианты, с картинками внутри второго уровня, например. И распространенные md viewers даже одноуровневые таблицы искажают до нечитаемости, перебрав 6 штук, я попросил нейронку написать свою, она меня устроила.
md занимает мало токенов, html со стилями и жс скриптами съест кучу токенов. Будет и дороже и контекст забьется этим хтмл. Поэтому мд тут выигрывает
На бесплатных акках - да. Но на платных это либо незаметно, либо, если стандарт под 2000 страниц (в интеловских даташитах такое сплошь и рядом) можно втянуть перед уходом с работы. Да и не надо целиком документы по 2000 страниц читать, можно перед этим головой подумать и указать, что именно нужно.
А контекст - миллион токенов забить не так просто, впрочем, если сайты тяжелые целиком на уязвимости пробивать...
почему HTML лучше Markdown
А ничего что MD допускает вставлять HTML там где надо И при этом обеспечивает интуитивно понятное форматирование даже в текстовых редакторах которые не умеют форматирование вообще?
По-моему, надмножество всегда лучше чем подмножество (с условиями когда нет конфликтов и костылей для обхода)
Но тем не менее, кому не нравится MD - просто не используйте его.
P.S. и да, HTML полон и слишком полон, в смысле всяких доп. возможностей которые ведут к уязвимостям там, где эти возможности не нужны.
md легче парсить, дешевле, ближе к «языку» модели. Хотите красивостей - попросите mermaid внутри - это лучше чем на каждый ответ пилить SPA
В статье исключительно примеры про визуализацию и тут понятно, что html это обрисовывает как надо. Но по сути нет ничего реально показывающего преимущества над мд. По хорошему бОльшая часть промптов как раз на технические вопросы и про написание кода, и тут я не вижу ни одной причины юзать html.
А на счёт длинных md файлов, то тут ещё проще. Надо сначала создать подробный план (не 1-2 пункта) и на каждый этап завести свою задачу в отдельном файле. И это помогает потом, когда приходится возвращаться к какому-то пункту. Говоришь на каком этапе и что надо бы изменить (читает описание этапа, смотрит коммиты и сразу понимает что делать). Отсюда и прямая экономия токенов, не надо перелопачивать весь контекст или перечитывать весь код каждый раз.
Ну ок, читать. А писать как? В WYSIWYG? :-) Удивлён, что автору ок открывать html для чтения в браузере, и при том будто бы редактор/ide автора не умеет в рендеринг md -> html... А спеки в html - они не только токены жрут, так ещё и зашумляют контекст, т.о. повышают вероятность возникновения галлюцинаций. Однако для отдельных задач, где нужна именно сложная визуализация, колонки, таблицы - html это хорошо. Но для остального - лучше org-mode/markdown.
Кажется автор не правильно подобрал название и вступление.
К агенту это представление информации в виде HMTL5 не имеет никакого отношения. Просто личное предпочтение автора и не более. Так же как кому-то нравится терминальный интерфейс, кому-то графический, а кому-то голосовой.
таблицы для табличных данных
можно подумать что md не поддерживает таблицы. может быть сложные таблицы, но обычные - вполне
HTML вставки для переноса строк внутри ячейки - это не “вполне” а барахло. Так как идея MD против HTML это “почти визивиг в блокноте”. И длиннющая строка разделенная <br> в это не укладывается. Даже точнее пусть предопределенные переносы будут <BR>, но
|Название|Очень|
| | длинное|
| |описание|
должно распознаваться как одна строка, не знаю как. Пусть придумают. До этих пор таблиц в маркдауне нет.
Есть. То что оно не отвечает вашим требованиям это не проблема markdown
Оно не отвечает идеологии МД, значит нет. Ну а то нечто лайт что есть - не достойно называться таблицами.
Docusaurus не рассматривали? Он ещё и поиск внутри документации вам организует. Как я понимаю, весьма популярен.
В моем случае я использую mdoc, который позволяет не просто запихнуть сниппеты кода в документ, но и проверить, как они работают - если код изменился, ломая обратную совместимость, документация при сборке плюнет ошибкой. То есть, поддержка актуальности докунтации становится проще. Вероятно, для ваших питонов тоже найдется похожий инструмент. А потом уже можно применить HTML-генератор вроде Docusaurus (хотя в моем нишевом случае я предпочел Laika, которую при желании можно настроить на создание ещё и pdf). И потом CI, который заливает документы на github pages. Вместо рассылки файлов просто отправляете ссылку.
Как выше написали, если не хватает возможностей md, можно включать в документ html, и это сработает. Плюс есть расширения md типа mdx. Или формат rst, например.
Писать документацию на голом html в наше время - это отдельная статья мазохизма.
Я не понял, судя по картинке из параграфа "Читаемость", автор не умеет открывать маркдауны на превью чтоли?
Все там норм с читаемостью, включая диаграммы, если движок поддерживает, а он, как правило, поддерживает.
То есть вопрос только в красоте и нежелании коллег читать лонгриды?
А теперь вспомним, что md можно читать и править любым текстовым редактором а-ля Блокнот, и что Клод читает и пишет в md без всяких дополнительных переподвывертов. Ну а для ленивых коллег можно преобразовать md в pdf. Собственно, этот формат для этих целей и придумали.
Короче, "вам шашечки или ехать?" (с)
А интерактив и прочие свистелки... Как помне, создание презентаций это отдельная тема.
я крайний HTML-максималист
вот и ответ почему. MD используют за простоту и человекочитаемость без свистоперделок, html - за семантичность. разные цели
МД читать почти невозможно человеку. Особенно когда таблички. Я имею в виду в чистом виде
но простым скриптом на питоне конвертируется в html
То, что у автора - красивее, тут ж вопросы не просто замена мд на хтмл, а повышение читаемости, понятливости. И очень зря "понятность" недооценивать, уйма людей (да хоть те же биай-аналитики) занимаются тем, чтобы сложные данные изобразить так, чтоб это было понятно
Настройте свой редактор на автоформатирование табличек, чтобы столбцы были выровнены под одинаковую ширину, и читабельность таблиц в md улучшится кардинально (по крайней мере пока они помещаются на экран).
Не надо конвертировать в HTML, в нем таблицы тем более невозможно читать. А вот отрендерить можно что МД, что HTML с одинаковым успехом.
в смысле невозможно, хтмл читает любой браузер (и Ворд)
Ну и в любом редакторе маркдаун есть кнопка превью. А если редакторов не использовать, а сидеть в голом блокноте, то HTML менее читабелен, чем MD
Если в обществе нет цветовой дифференциации штанов, значит нет цели. Ага.
Claude Code может проиндексировать всю кодовую базу
Есть какие-то подтверждения этому? Насколько я вижу, Claude Code, как и большинство агентов без глубокой интеграции с IDE при поиске просто grep-ает файлы, а так называемая индексация требует использования сторонних решений
grep - это тоже индекс. Просто не очень эффективный. То ли дело rg… :)
А если серьёзно, то "индексация кодовой базы" раньше подразумевала использование RAG. Этот подход был жизненно необходим когда у моделей был очень небольшой размер контекста, но это уже в прошлом. А сегодня RAG создаёт больше проблем, чем решает (конкретно в случае работы с кодом): индексация может отставать от изменения файлов и возвращать устаревшие данные, RAG обычно базируется на семантическом поиске но при поиске в коде grep предположительно работает намного точнее.
Поэтому сегодня фраза "проиндексировать всю кодовую базу" часто означает только то, что модель имеет возможность анализировать всю кодовую базу, не важно каким способом.
Точно, попроси его сгенерировать html, а потом получи в ответ от коллег -а почему то и то не работает. И тестируй за клаудом то, что он сделал - очень удобное решение, спасибо
Пришёл к тому же самостоятельно, только с другого конца. Начал с того, что попросил Claude Code сделать обложку для статьи, сначала пробовал через markdown с ASCII, выглядело ужасно. Переключился на HTML/CSS плюс SVG, Claude за один заход сделал то, на что у меня ушло бы полдня в Figma. Теперь весь визуал через HTML, схемы архитектуры, DDD-контексты, презентации для команды. Особенно хорошо зашли SVG-диаграммы когда надо показать bounded contexts и их взаимодействие, Claude рисует их точнее чем любой ASCII. Единственный минус который нашёл, это diff в git. Markdown меняется на пару строк, HTML превращает правку заголовка в портянку. Для личных артефактов не критично, для командных спеков немного неудобно.
Похоже, что вы не слышали, что маркдаун - это надстройка над HTML.
Всё, что вы пишете в HTML - можно писать в маркдауне. Можно взять html файл, переименовать его в md и жить-не-тужить.
HTML же, в отличие от md не поддерживает, например, конструкции вида
```tikz
```И другие подобные, вы не можете написать
$e = m c^2$В HTML нет хеш-тегов и многого другого, что есть в md.
С чего вдруг вас волнуют эта тема? И как мы можем применять HTML для базы данных… Короче, привет Мир ✌️
Если со стороны визуала возможно html со стороны экономии токенов md но все есть более интересное решение и гибкое в своём виде - RAG я использую lightRaG. Есть опенсурс крути под себя как хочешь делай для себя любой визуально , ну и экономия токенов по сравнению с html и md и да чтобы уменьшить вероятность бана claude можно рассмотреть warp от cloudflare и ipv6 (antropic сама использует cloudflare а ipv6 еще не сильно загрязнены )

Claude Code: почему HTML лучше Markdown