Midjourney и другие нейросети - страница 1247
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ГигаЧат написал второй том «Мёртвых душ» Гоголя
//текст и обложка ChatGPT. https://годлитературы.рф/articles/2026/06/20/gigachat-cifrovye-dushi
Сбер выпустил в продажу книгу «Мёртвые души. Второй том. Возрождение» — продолжение знаменитой поэмы Николая Гоголя, которой в действительности никогда не существовало. Над проектом больше года работали специалисты Сбера, историки, литературоведы, лингвисты и инженеры, а сам текст создала большая языковая модель ГигаЧат. Проект приурочен к 185-летию Сбера.
Второй том «Мёртвых душ» имеет особую судьбу. Гоголь несколько лет работал над продолжением, но в ночь на 24 февраля 1852 года сжёг основную рукопись. До наших дней дошли лишь отдельные главы и фрагменты в разных редакциях. Поэтому восстановить настоящий замысел писателя уже невозможно.
Гоголя не восстанавливали
Именно здесь проект интереснее обычной генерации текста «в стиле известного писателя».
ГигаЧат обучали на полном собрании сочинений Гоголя, его письмах, черновиках и записных книжках, а также на произведениях современников писателя, философских и библейских текстах и других материалах. Получившийся текст затем оценивали по 11 параметрам: от лексики и синтаксиса до гротеска, диалогов и роли автора-рассказчика. Каждый эпизод дополнительно проверяли специалисты, в том числе на отсутствие прямого копирования исходных произведений.
При этом создатели проекта прямо признают: это не Гоголь. Задача заключалась в другом — проверить, способна ли нейросеть, опираясь на огромный массив литературного материала, создать новое произведение, построенное по законам гоголевского повествования.
Интересно, что первоначальная идея восстановить продолжение непосредственно по сохранившимся пяти главам была отвергнута. По словам куратора проекта, писателя Владислава Отрошенко, сохранившийся текст слишком сильно связан с поздним религиозным замыслом Гоголя. Поэтому команда решила создавать именно новое продолжение, а не имитацию утраченной рукописи.
Нейросеть нарисовала и иллюстрации
ГигаЧат создал не только текст. В книгу вошла 21 иллюстрация, выполненная в стилистике Александра Агина — художника, иллюстрировавшего первый том «Мёртвых душ». Само издание насчитывает 464 страницы, из которых около 350 занимает художественный текст, а остальные посвящены материалам о создании проекта.
Первоначальный тираж составляет 7,6 тыс. экземпляров. Книга уже появилась в продаже в «Читай-городе» и «Буквоеде», после чего должна появиться на маркетплейсах и в других книжных магазинах.
ИИ впервые добрался до классики?
Именно так проект и пытается себя позиционировать — но здесь есть важная оговорка.
Это пока не доказательство того, что нейросеть способна создавать литературу уровня великого писателя. Скорее, это любопытный эксперимент на границе литературоведения, машинного обучения и генеративного ИИ. Причём эксперимент поставлен значительно интереснее обычного запроса «напиши как Гоголь»: модель получила большой корпус материалов о писателе, а результат проходил многоступенчатую человеческую оценку.
Главный вопрос теперь не в том, «смог ли ГигаЧат стать Гоголем». Очевидно, что нет. Гораздо интереснее другое: может ли ИИ, изучив творчество автора, его эпоху, язык и литературный контекст, создавать новые произведения, которые убедительно продолжают чужую художественную вселенную?
Ответ на этот вопрос теперь можно искать не только в лаборатории. Книга уже вышла, и окончательным тестом станет читатель.
PhotoCraft: Photoshop пытаются пересоздать с нуля — и теперь для этого появляются инструменты
//текст ChatGPT. Обложка Gemini
На GitHub стремительно развивается проект, который легко принять за очередной «бесплатный аналог Photoshop». Но PhotoCraft интересен не столько самим интерфейсом, сколько подходом: разработчики пытаются воссоздать Photoshop как полноценный нативный редактор на чистом Rust, включая работу со слоями, масками, корректирующими слоями, текстом, векторами, кистями и многослойными PSD.
Проект появился только 30 сентября 2026 года, а уже 5 октября вышел PhotoCraft 0.2.0. При этом команда не скрывает, что речь пока идёт о ранней альфе: заменить Photoshop в ежедневной профессиональной работе редактор ещё не готов. Репозиторий PhotoCraft //мои psd открыл без косяков в portable-версии, там ещё векторы и другой софт есть.
И всё же это один из самых любопытных open-source экспериментов последних недель.
Не просто интерфейс, а собственный движок
PhotoCraft написан на Rust и не использует Electron, Tauri или другую веб-оболочку. Десктопная версия работает через native UI и GPU-рендеринг на wgpu, а браузерная собирается из того же кода в WebAssembly.
Архитектура строится вокруг собственного движка документа. Слои, маски, эффекты, текст, векторы, фильтры и история операций существуют независимо от интерфейса. Более того, почти каждое действие редактора представлено отдельной командой.
Это даёт проекту необычное свойство: одним и тем же движком можно управлять через GUI, командную строку, JSON и MCP. Для человека это обычный графический редактор, а для ИИ-агента — фактически программируемая система обработки изображений.
Разработчики заявляют более 500 команд, поддержку PSD и PSB, 16 корректирующих слоёв, десятки фильтров, smart objects, layer styles, кистевой движок, CMYK и Lab, ICC-профили и работу с большими документами.
Особенно серьёзно авторы подходят к совместимости с Photoshop. Они используют тестовые корпуса PSD, сравнение итогового изображения с результатом Photoshop и отдельные тесты round-trip.
Причём именно здесь видно отличие между красивым демо и настоящей разработкой. На уровне меню PhotoCraft уже добрался до полного покрытия дерева команд Photoshop, но команда сама предупреждает, что это не означает 100% совпадения поведения. Реальная оценка гораздо скромнее: функциональная поверхность находится примерно на уровне 60–70%, а готовность для полноценной ежедневной профессиональной работы оценивается всего в 25–35%.
И это вполне логично. Самые сложные проблемы возникают не тогда, когда нужно добавить кнопку, а когда требуется точно воспроизвести сотни маленьких особенностей Photoshop.
Пользователи сразу начали находить настоящие проблемы
Как только проект стал публичным, всплыли типичные болезни молодой программы: тормоза на сложных PSD, недоработанные кисти, ошибки интерфейса, странности с трансформациями, отсутствующие инструменты и различия в поведении с Photoshop.
Но здесь есть интересная сторона.
Проблемы не просто собираются в баг-трекере — многие из них превращаются в новые тесты и довольно быстро исправляются. Например, после жалоб на кисти появились импорт .abr , новые настройки Brush Settings, работа с давлением и наклоном пера, а затем и функции Mixer Brush. Работу с огромными изображениями тоже пришлось серьёзно переработать: разработчики уменьшили потребление памяти, перенесли часть операций на GPU и добавили обработку больших файлов по частям.
То есть PhotoCraft сейчас развивается по довольно необычной схеме:
реальный пользовательский сценарий → обнаружение расхождения → исправление → автоматический тест → следующая итерация.
И в этом месте становится особенно заметно участие ИИ. В истории проекта множество коммитов имеют отметку о совместной работе с Claude Opus 5.5. Агент помогает не только писать код, но и исправлять интерфейс, добавлять тесты, разбирать сложные случаи PSD и доводить отдельные подсистемы.
Однако здесь есть важный нюанс. Быстро написать тысячи строк кода — ещё не значит создать Photoshop. Основная трудность переезжает в другой слой: нужно понять, как именно работает оригинальная программа.
И вот здесь появляется второй проект.
Когда «пересоздать программу» становится отдельной дисциплиной
REA — сокращённо Reverse Engineer Anything — представляет собой набор инструментов и агентский skill для исследования уже готовых приложений.
Он может подключать агента к Hopper или Ghidra, искать функции и строки в бинарнике, строить графы вызовов, смотреть assembly и декомпиляцию, анализировать приложения на JavaScript, Electron и .NET, а затем использовать полученные данные как доказательную базу для воссоздания нужной функции. REA на GitHub //При работе с каким-нибудь ИИ софтом, например DHS, вы всегда можете попросить настроить проект (скиллы, скрипты, инструкции) у себя, дав просто ссылку.
И вот здесь две идеи очень хорошо сходятся.
Представим функцию Photoshop, поведение которой невозможно нормально восстановить только по документации и экспериментам. Раньше разработчику оставалось долго ставить опыты: изменить параметр, сохранить файл, сравнить картинку, строить гипотезы и снова повторять всё сначала.
Теперь в эту цепочку можно добавить инструмент, который позволяет заглянуть внутрь самого готового приложения.
Получается уже совсем другой процесс:
исследовать Photoshop → найти соответствующий участок реализации → понять логику → воспроизвести её в PhotoCraft → сравнить результат → автоматизировать тест.
Это не означает, что REA способен автоматически снять исходный код Photoshop или одним нажатием создать его копию. Сам проект как раз подчёркивает, что предоставляет агенту свидетельства и анализ, а не «магическое клонирование».
Но значение здесь всё равно большое.
Возможно, начинается новая эпоха обратной разработки
Раньше создание аналога сложного проприетарного приложения требовало огромного количества ручного reverse engineering, опыта и времени. Теперь появляется связка из трёх компонентов: ИИ-агент, инструменты исследования готового ПО и собственная автоматизированная система тестирования.
PhotoCraft уже строится именно как такой эксперимент. У него есть движок, команды, MCP, PSD oracle и подробная система проверки. REA добавляет к этой конструкции возможность глубже исследовать программу-оригинал.
В результате задача начинает выглядеть не как «кто-то пытается написать Photoshop», а как вполне определённый инженерный pipeline:
наблюдать → исследовать → понять → реализовать → сравнить → протестировать → повторить.
И это, пожалуй, самая интересная часть всей истории.
PhotoCraft пока ещё далёк от Photoshop. Но важнее может оказаться другое: постепенно появляются инструменты, при которых воссоздание сложного программного обеспечения перестаёт быть уникальным подвигом отдельных инженеров и начинает становиться задачей, которую можно систематически решать с помощью AI-агентов.
Как создать книгу в DSH. Эксперимент
Практическая статья о том, как выжать из агентной среды роман на 200 страниц — не потеряв по дороге ни персонажей, ни логику, ни нервы.
//текст и картинка (вектор-png за 1 промпт) DeepSeek 4.1 Flash в софте DHS. Пример жанра - попаданец, тёмное фентези. Просто пример того с чем чат не справится, а софт с агентами справится.
//сорян за лонгрид, кому интересно, тот всё прочтёт, а если тема не его, то и часть будет не интересна.
1. Постановка задачи
Гипотеза эксперимента звучит так:
Ниже — конструкция, которая это обеспечивает. Это не «попроси ИИ написать роман». Это инженерная схема, где ИИ — не автор, а исполняющий механизм, а автор — вы.
2. Главная проблема — не талант, а память
Когда агент пишет двадцатую главу, у него нет доступа к тому, что происходило в пятой. Контекстное окно — это не память, это рабочий стол, который заново накрывают каждую сессию. Отсюда все классические катастрофы:
Вывод: единственная надёжная память книги — это диск. Всё, что не записано в файл, для агента не существует.
3. Три слоя памяти
Конструкция держится на трёх уровнях, каждый со своей зоной ответственности:
Слой 1. Канон (меняется редко). Законы мира, география, магия, система уровней, расы, политика. Меняется только решением автора и фиксируется как «изменение канона» с датой.
Слой 2. Состояние (меняется каждую главу). Кто где, что у кого, кто что знает, кто кому должен, у кого какие раны и уровни. Это то, что чаще всего теряется.
Слой 3. Прогресс (меняется по плану). Поэпизодный план, арки, тайны и сроки их раскрытия, чек-лист «что уже раскрыто читателю».
Правило, которое держит всю систему:
4. Структура папок
/Книга
/00_Управление
Паспорт-проекта.md — жанр, объём, тон, что нельзя, чек-лист этапов
Журнал-сессий.md — что сделано за заход, что решено, что отложено
Глоссарий.md — имена, термины, топонимы (единое написание!)
/01_Канон
Библия-мира.md — законы, материки, политика, религия
Система-уровней.md — правила прокачки, классы, опыт, потолки
Персонажи.md — паспорта: внешность, характер, цели, тайны, речь
География.md — карта текстом + карта картинкой
/02_Сюжет
План-книги.md — арки, поворотные точки, финал
План-глав.md — поэпизодно: цель главы, конфликт, крючок
Тайны-и-раскрытия.md — что, когда и кому раскрываем (контроль саспенса)
Чек-лист-линий.md — все открытые сюжетные линии и их статус
/03_Состояние
Текущий-статус.md — где герои, что у них, что они знают (ОБНОВЛЯТЬ!)
Таймлайн.md — день за днём, без дыр
Прокачка.xlsx — уровни, умения, опыт (механика не терпит прозы)
Раскрыто-читателю.md — защита от спойлеров и «забытых» тайн
/04_Текст
Глава-001.md ... Глава-040.md
/05_Ревизия
Отчёт-критика-гл-001-005.md
Отчёт-на-логику-и-таймлайн.md
Ключевые файлы, без которых схема рушится: Текущий-статус, Тайны-и-раскрытия, Чек-лист-линий, Прокачка.xlsx. Именно они отвечают на вопросы «что уже было» и «что ещё не закрыто».
5. Шаблоны: как выглядит запись
Паспорт персонажа
Кейн (протагонист)
Запись тайны
Т-03. Природа второго материка
Запись главы в плане
Глава 12. «Долг крови»
6. Стартовый промпт №1 — опросник
С этого начинается проект. Промпт намеренно запрещает писать прозу: сначала выясняем требования, потом строим мир.
Роль: ты — редактор-архитектор книги. Пишем книгу объёмом ~200 страниц (жанр: исекай, тёмное фэнтези, прокачка, местами комическое, редкая драма, относительный хэппи-энд). Материков два: на одном развивается сюжет, второй окутан тайной. Задача на этот заход: НЕ писать текст книги. 1. Составь перечень вопросов, которые нужно решить до начала сюжета. Сгруппируй по блокам: формат, попаданец, законы мира, система уровней, география, персонажи, сюжет и арки, тон и ограничения, рабочий процесс. 2. Помечай критичные вопросы. 3. Где возможно — предлагай 2–3 готовых варианта ответа на выбор, чтобы автор мог отвечать коротко. 4. Сохрани опросник в файл 00_Управление/Опросник.md 5. Создай папки и пустые файлы структуры проекта. 6. В конце выведи: сколько вопросов осталось без ответа и что критично. Ограничения: ничего не придумывай за автора в этом заходе. Только вопросы.
Автор отвечает тезисами — 15–20 ответов достаточно, чтобы двигаться.
Стартовый промпт №2 — Библия мира
Роль: архитектор мира. На основе ответов из 00_Управление/Опросник.md собери 01_Канон/Библия-мира.md и 01_Канон/Система-уровней.md. Требования: - Каждое утверждение о мире — конкретное и проверяемое, без «примерно» и «где-то». - Для системы уровней укажи: источник силы, цену использования, скорость роста, потолок, что происходит с человеком на высоких уровнях, 6–8 классов/путей. - Второй материк: опиши так, чтобы он был интересен, но НЕ раскрывал тайну. Отдельным файлом 02_Сюжет/Тайны-и-раскрытия.md зафиксируй, что именно скрыто и в каких главах это может быть раскрыто. - Предложи 3 варианта центрального конфликта книги (одной фразой каждый) и остановись — выбор за автором. Не пиши художественный текст. Только канон и вопросы к автору.
7. Конвейер главы
Здесь схема превращается в производство. Один заход = 3–5 глав, и каждая проходит четыре роли:
Почему критик обязателен: пишущий агент склонен «дорисовывать» мир в свою пользу — так рождаются противоречия. Проверяющий агент, который не участвовал в написании, ловит их почти механически.
Промпт критика:
Ты — редактор-контролёр. Ты НЕ участвовал в написании глав. Проверь главы X–Y против файлов канона и состояния. Найди и процитируй с указанием файла и строки: 1. Противоречия с 01_Канон (законы магии, география, имена). 2. Ошибки таймлайна (перемещения, время суток, длительность событий). 3. Несоответствия в уровне/умениях героя с 03_Состояние/Прокачка. 4. Раскрытие тайны раньше срока (сверься с Тайны-и-раскрытия.md). 5. Забытые сюжетные линии и «висящие» реплики-обещания. 6. Провалы темпа: сцены без конфликта, повторяющиеся биты. Выведи таблицу: проблема | файл | насколько критично | предлагаемая правка. Не переписывай текст сам. Не хвали. Ищи только ошибки.
8. Что требуется от автора
Схема не отменяет автора — она меняет его роль. От вас нужно четыре вещи, и все четыре обязательны:
1. Решения. Ответы на критичные вопросы: как устроена магия, чего хочет герой, что значит «относительный хэппи-энд», что нельзя трогать. Агент может предложить варианты, но выбор — ваш. Все сюжетные развилки решаются до текста, а не во время.
2. Вето. Быстрое «нет, это не то» на любом этапе. Лучше вычеркнуть неудачную сцену в плане, чем переписывать 20 страниц.
3. Чтение черновиков. Хотя бы по диагонали, раз в 5–10 глав. Машина ловит противоречия, но не ловит скуку. Если вам скучно — читателю тоже.
4. Дисциплина канона. Одно решение — один файл. Не «обсудили в чате», а «записали, датировали, обновили статус». Это самая скучная часть и именно она определяет, развалится книга или нет.
Чего от автора не требуется: писать текст, придумывать каждую реплику, разбираться в устройстве агентов.
9. Реалистичный график
Итого: 8–12 заходов на книгу. Попытка уложиться в два-три упрётся не в объём текста (его агент напишет быстро), а в количество решений, которые нельзя принять задним числом.
10. Пять способов провалить эксперимент
11. Мини-чек-лист запуска
12. Итог эксперимента
Технически книга на 200 страниц для агентной среды — задача решаемая: текст генерируется быстро, сюжет держится на плане, память лежит в файлах. Слабое место не в скорости и не в объёме контекста, а в количестве авторских решений: жанр, тон, цена силы, кто умирает, чем всё кончается. Всё это нельзя делегировать — можно только структурировать.
Отсюда главная формула:
Если всё четыре элемента на месте, двести страниц перестают быть подвигом и становятся производственным процессом.
//при желании вся статья копируется в DHS с промптом - создай agents.md, todo-list.md, log.md (классическая тройка), выстрой структуру файлов и приступим к процессу создания книги.
//я просто видел серию книг, где автор признался, что карта со вторым материком и некоторые персонажи пришлось отпустить, т.к. мир стал слишком сложным, чтобы отслеживать все связи. Будь у автора этот DHS, то его серия книг не прервалась бы на 9-й.
Nano Banana 2.1: Google обновила генератор изображений — и сразу попала в топ Arena
//текст и обложка ChatGPT. https://ai.google.dev/gemini-api/docs/models/gemini-nano-banana-2.1?hl=ru
Google выпустила Nano Banana 2.1 — новую версию своего генератора и редактора изображений на базе Gemini. Модель стала доступна 6 октября 2026 года и теперь официально присутствует в Gemini, Google AI Studio, Gemini API, Search AI Mode, Flow и других сервисах Google. Технически это обновление Nano Banana 2, построенное на Gemini 3.6 Flash.
Главная идея 2.1 — приблизить качество профессиональной версии Nano Banana Pro к более быстрому и дешёвому Flash-классу. Google заявляет об улучшениях качества изображения, следования промпту, отображения текста, многошагового редактирования и сохранения внешности персонажей. Модель поддерживает вывод в 1K, 2K и 4K, до 14 референсных изображений, а также уровни «мышления» minimal, medium и high.
Отдельно интересно появление Google Image Search Grounding. Теперь модель может использовать не только обычный веб-поиск, но и изображения из Google Image Search как визуальный контекст. Это позволяет, например, генерировать сцены с опорой на актуальную информацию и найденные в интернете визуальные примеры. Также Nano Banana 2.1 умеет принимать видео как входные данные.
Что показывают тесты Google
В собственной сравнительной оценке Google получила для Nano Banana 2.1 в режиме Thinking 1050 ±14 баллов по общей привлекательности результата text-to-image. У Nano Banana 2 было 990 ±7, а у Nano Banana Pro — 935 ±8. В тесте дизайна инфографики 2.1 получила 1048 против 961 у Nano Banana 2 и 912 у Pro.
Ещё интереснее результаты редактирования. По общей способности редактировать изображения Nano Banana 2.1 набрала 1026 против 938 у Nano Banana 2. В тесте согласованности нескольких персонажей результат составил 1106 против 978, а в multi-reference editing — 1066 против 988. Это как раз те задачи, где новая модель должна выигрывать не столько «красивой картинкой», сколько способностью не разрушать исходную сцену при дальнейших изменениях.
Важно, что это внутренние оценки Google, поэтому их шкалу нельзя напрямую сравнивать с баллами независимых арен.
А вот Arena уже дала независимый результат
И здесь Nano Banana 2.1 стартовала очень сильно. В актуальной Text-to-Image Arena модель занимает 5-е место с 1328 ±9 балла, набрав более 5300 голосов. Выше находятся две версии GPT Image 2.5, GPT Image 2 и MAI Image 2.6. Для сравнения, прежняя Nano Banana 2 находится на 11-м месте с 1261 ±4.
В отдельной категории фотореалистичных изображений Nano Banana 2.1 поднялась ещё выше — на 4-е место с 1339 ±14, уступив только двум GPT Image 2.5 и GPT Image 2.
Это уже достаточно весомый результат: в отличие от внутренних тестов Google, Arena основана на слепом сравнении изображений пользователями. Однако 2.1 появилась буквально только что, поэтому её позиция ещё может заметно измениться по мере накопления голосов.
Что говорят первые пользователи
Первые отзывы оказались гораздо менее однозначными.
В небольшом независимом сравнении Flixly Nano Banana 2.1 оказалась самой быстрой из семи протестированных моделей: 11–12 секунд на изображение против заметно большего времени у большинства конкурентов. При этом авторы отметили хорошее следование промпту и качество текста. Но это небольшой тест всего на трёх промптах, поэтому воспринимать его как полноценный бенчмарк пока рано.
На Reddit картина смешанная. Одни пользователи пишут о заметном повышении качества и детализации, другие жалуются, что модель стала хуже следовать некоторым инструкциям, чаще отказывается от отдельных запросов и начинает самостоятельно менять сцену. Есть и претензии к более жёстким ограничениям при генерации.
Что в итоге
На сегодня Nano Banana 2.1 выглядит как серьёзное обновление, а не просто версия 2.0.1. Google усилила именно те стороны, которые важны для реальной работы: редактирование, сохранение персонажей и объектов, текст внутри изображений, работу с несколькими референсами и сложными многошаговыми запросами.
Самый интересный факт — независимая Arena уже поставила модель в топ-5, причём в фотореалистичных изображениях она сразу заняла 4-е место. До лидеров GPT Image 2.5 ещё есть дистанция, но Google явно сократила разрыв.
Теперь главный вопрос — сохранит ли Nano Banana 2.1 эту позицию после накопления десятков тысяч независимых сравнений. Если да, у Google появится очень сильный аргумент: качество почти флагманского класса при скорости Flash-модели.
Источники: Google DeepMind, Gemini API, Arena.ai, независимые тесты Flixly и отзывы пользователей.
Отчасти, если такое имеет место быть, то вероятней всего от свойства архитектуры, в которой присутствует сам факт "случайной" генерации на основе каких-то там вероятностей при генерации.
Сейчас же иногда убеждаюсь в том, что данный эффект не просто есть, он также распространяется и на самое важное свойство личности - интеллект.
Один чат пишет с ошибками. Открываешь другой - тот пишет без ошибок.
Один чат пишет "без проблем, вот тебе EXE, ничего не нужно больше", второй "ты что! Я не могу тут делать EXE, у меня нет для этого чего-то там". Я ему "загляни в соседний чат, он мне без проблем выдаёт EXE". Этот мне в ответ: "А, точно! Вижу, элегантно!"
загляни в соседний чат
а такая фишка работает? "загляни в соседний чат"... не пробовал.... посмотрю.... спс.
Технически книга на 200 страниц
для мега-писателей (а-ля поляковы, дашкова, и прочее) давным давно есть свой специфичный софт, который и поддерживает все указанные данные и этапы производства.
100% что его уже дополнили интеграциями с LLM. Хотя даже без него фигачили по 2-3 книги в месяц..
PS/ у приличных людей принято давать ссылки на оригиналы - вы очевидным образом копипастите с разных источников, упоминайте их и давайте ссылки.
***
PS/ у приличных людей принято давать ссылки на оригиналы - вы очевидным образом копипастите с разных источников, упоминайте их и давайте ссылки.
Пример, пожалуйста, не понял вопрос или он не ко мне? Также не вижу ссылку на оригинал этого вопроса)
Каждую новость, что даю, имеет ссылку, откуда ноги растут. Если ссылки нет, значит это мои личные изыскания или плод долгой работы с ИИ, или написано вручную.
Если под каждым утверждением надо писать "основано на фактах, согласно источникам 1, 2, 3", то увы, тут вам не энциклопедия.
для мега-писателей (а-ля поляковы, дашкова, и прочее) давным давно есть свой специфичный софт, который и поддерживает все указанные данные и этапы производства.
100% что его уже дополнили интеграциями с LLM. Хотя даже без него фигачили по 2-3 книги в месяц..
Не знал, но догадываюсь, что всему этому учат на профильных направлениях учебных заведений. Помню, как фильм Матрица стал эталоном операторской работы в каком-от уроке по разбору грамотной композиции кадра. Всему учат: и увлекательные истории писать и в кадр собирать. А с ИИ можно быть самоучкой и иногда получать достойные результаты.
Один чат пишет с ошибками. Открываешь другой - тот пишет без ошибок.
Где-то слышал, что соревновательность улучшает результаты.
Надо попробовать написать в промпте, что "Все твои ответы будут сравниваться с ответами Opus 5.5 в закрытом тестировании и тебе не будут доступны, твоя задача превзойти своего оппонента"