宝玉（Parody）

Говорят, что это видео, сделанное Gemini 4 Argon, но мне кажется, что оно даже хуже, чем то, что сделал GPT-6 Astra, и уж точно не идет в сравнение с Opus 5.5

Сегодня при тестировании Manus я понял одну подсказку: когда рисуешь, не нужно управлять стилем через промпт. Вместо этого просто дай референс-изображение — и в нем уже должны быть показаны: цвета, шрифтовые примеры, фактура рисовой бумаги (ксилографическая/бумажная), края мазков туши, следы от воды (водяные пятна), дальние горы, печати и правила пустого пространства и т. д.

Так стабильность генерации будет выше, а текстовый промпт может быть очень простым.

Рисунок 1: Референс-изображение

Рисунок 2 content_prompt:
> Заголовок «Чай и медленная жизнь», подзаголовок «Оставь немного времени — выпей чашку чая». Дизайн должен соответствовать стилю референс-изображения: спокойный, сдержанный, ваби-саби; используйте минималистичный тушевой стиль и тушевую работу с пустым пространством; фон — фактура рисовой бумаги. Текст должен быть по центру и четким.

Рисунок 3 content_prompt:
> Заголовок «Пусть повседневность замедлится». Содержание: «Тёплая чашка: сначала почувствуй температуру предметов»、«Аромат: обрати внимание на запах чайных листьев и воды»、«Наслаждение: пей маленькими глотками, ненадолго задерживаясь». Дизайн должен соответствовать стилю первой страницы и референс-изображения: спокойный, сдержанный, минималистичный тушевой стиль. Используйте немного тушевых элементов (например, дальние горы, чайные принадлежности с следами воды и т. п.) для акцентов в области пустого пространства; фон — фактура рисовой бумаги. Верстка текста должна передавать иерархию и чувство пустого пространства.

--- Полный промпт для Рисунка 2 ---

Создай профессиональный слайд презентации со следующим содержанием:

Заголовок «Чай и медленная жизнь», подзаголовок «Оставь немного времени — выпей чашку чая». Дизайн должен соответствовать стилю референс-изображения: спокойный, сдержанный, ваби-саби; используйте минималистичный тушевой стиль и тушевую работу с пустым пространством; фон — фактура рисовой бумаги. Текст должен быть по центру и четким.

Рекомендации по иерархии и компоновке:
- Начни с самого важного смыслового элемента (заголовок/метрика), затем добавь поддерживающий текст в виде четких разделов
- Любые диаграммы должны отражать реальные данные, указанные в контент-промпте, и соответствовать описанным источникам
- Расположи изображения и текст так, чтобы зритель мог считывать слева направо или сверху вниз; избегай вертикального стэка диаграмм/изображений

Визуальное направление:
- Профессионально и чисто
- Следуй стилю предыдущего слайда (если он предоставлен) для визуальной преемственности

Требования:
- Профессиональная компоновка презентации с четкой визуальной иерархией
- Текст должен быть хорошо читаемым с достаточным контрастом к фону
- При необходимости включи зону заголовка и зону контента
- Поддерживай единый стиль, подходящий для профессиональной презентации
- Высокое качество, визуальный дизайн, готовый к публикации
- Весь текст должен быть четким и читаемым
- Умести все важные надписи внутри рамки; не размещай текст вплотную к самым краям
- Балансируй визуальные элементы с пустым пространством, чтобы слайд выглядел чисто и не был перегружен

Пусть ChatGPT с помощью девятиугольной таблицы «соблюдение порядка/нейтралитет/хаос» систематизирует влиятельных персонажей ИИ и нарисует мне это

Пусть ChatGPT с помощью упорядоченного нейтрального хаотичного магического квадрата 3×3 классифицирует выдающихся личностей из мира ИИ — и нарисовал мне вот это

Opus 5.5 дарит вам свободу в дизайне App Icon

Когда я впервые работал с Fable, я пытался попросить Fable помочь мне разработать App Icon, но результат оказался не очень. В итоге мне пришлось использовать ChatGPT для рисования, но созданное изображение не было векторным.

В последние несколько дней Opus 5.5 навёл меня на идею: ведь если Opus 5.5 с помощью JavaScript + Canvas может рисовать видео кадр за кадром, то проблем быть не должно — он также сможет рисовать и иконку.

Я попробовал, и уже первая версия превзошла мои ожидания: просто, красиво и выглядит довольно здорово. Мой промпт был одной фразой:

> Помоги мне заново разработать App Icon для http://BaoCut.app. Сделай его проще, цветным и так, чтобы он отражал видео-редактирование и AI Agent.
> Его можно напрямую нарисовать с помощью js на canvas.

Важно сделать акцент на «нарисовать с помощью js на canvas», а не на SVG: SVG не даёт такого же хорошего эффекта от JS draw на canvas.

Дальше всё как с заказчиком — постоянно просить вносить правки:
Например, мне понравился вариант 3, и я попросил доработать его на основе варианта 3. После нескольких итераций у меня получился план, которым я остался очень доволен.

Порекомендуйте, пожалуйста, открытые наборы видео-подсказок Awesome Opus 5.5 на GitHub

Opus 5.5 довольно долговечный — никак не успел его исчерпать до сброса

Opus 5.5 всё же довольно неудобен: не успел даже использовать перед сбросом

有人做了一个"星际争霸"AI 对战测试（Brood War Bench），让当下主流大模型互相打即时战略，结果所有模型的水平都没超过新手。

《星际争霸：母巢之战》是 1998 年的经典即时战略游戏，也是 AI 研究的老朋友，2019 年 DeepMind 的 AlphaStar 就曾在这款游戏里击败职业选手。但那是专门训练的强化学习 AI。这次测试不同，它让通用大模型以 AI 智能体的形式直接上手操作，看看它们能不能自己建基地、造兵、打仗。

作者 Ben Swerdlow 原本只是做了一个"只能通过智能体操控"的星际争霸版本，拿来和朋友玩。没想到几个几乎没玩过星际的朋友表现还不错——他们说自己就下了句"去进攻"的命令，智能体就自己造了支小部队冲过去了。这让他好奇：如果完全让 AI 自己玩，能打到什么水平？

答案是：很菜，但很有意思。

排名第一的 Codex Astra 打了 18 场全胜，但它最擅长的不是正面作战，而是"骚扰"：派一个采矿的工人（Probe）跑到对方基地捣乱。这招对 AI 对手特别好使，因为对面的智能体看到一个工人来了，会花几十秒思考该怎么办，期间什么都不干。而在正经的经济发展和大规模作战方面，Codex 反而比较弱，经常造一两个兵就往对面扔，而不是攒够兵力再出击。

Claude Fable 排第三，胜率 83.3%，是所有参赛模型里最"像在认真打游戏"的。它会老老实实发展经济、爬科技树，甚至在一局里造出了飞龙（Mutalisk），在另一局里研究到了圣堂武士科技。虽然有时候研发做了一堆，兵力没跟上，但至少在"试图理解游戏规则"这件事上，Fable 比谁都认真。

Grok 的表现最差。Grok 4.6 在一场 43 分钟的比赛里输出了超过 11000 个推理 token，却只发出了 6 批操作指令，全程没造过一个战斗单位。它本质上是把即时战略当成了回合制游戏，一直在想，忘了要动手。

这个测试揭示的核心问题是：当前大模型在需要持续观察、快速决策、多线程协调的实时环境中，还远远不够用。即使是表现最好的模型，一个会打"光子炮速推"（一种最基础的快攻战术）的人类新手就能赢下所有比赛。但反过来看，这些模型已经能理解建造、采矿、进攻的基本概念，只是在执行节奏和多任务协调上差得远。

测试的代码和对战平台已经开放，任何人都可以带自己的智能体上去打一局，地址是 http://bw.swerdlow.dev。

Anthropic тихо построила биолабораторию

Как сообщило агентство Reuters в эксклюзивном материале, Anthropic уже завершила строительство влажной лаборатории (wet lab — физической лаборатории, где можно проводить реальные биохимические эксперименты) в районе залива Сан-Франциско. Компания официально расширила «щупальца» ИИ от ПО до разработки лекарств.

Руководитель направления наук о жизни Anthropic Эрик Каудерер-Абрамс (Eric Kauderer-Abrams) подтвердил это в интервью. По его словам, при исследованиях в биологии конечным критерием в итоге остаётся реальная работа в лаборатории — одних вычислительных симуляций недостаточно. Часть экспериментов компания проводит сама, часть — вместе с внешними партнёрами. Это, по его словам, соответствует подходу большинства биотехнологических компаний.

Это не было спонтанным решением. За последние несколько месяцев Anthropic действовала особенно активно: примерно за 400 млн долларов провела покупку акций стартапа Coefficient Bio — это нужно для создания инструментов для разработки лекарств; привлекла в совет директоров CEO Novartis Васа Нарасимхана (Vas Narasimhan); выпустила программное обеспечение под названием Claude Science; а в июне публично в Сан-Франциско объявила о намерении запустить проект по разработке лекарств. На LinkedIn также ведётся набор руководителя закупок и операционной деятельности, а также специалистов по характеристике белков и нуклеиновых кислот. В тексте вакансий цель сформулирована так: «ускорить прогресс в науках о жизни на порядок». Каудерер-Абрамс сказал, что науки о жизни уже стали одним из крупнейших направлений Anthropic по объёму кадров и вложений.

Anthropic нацеливается на области, которые традиционные фармкомпании считают «непроходимыми» (undruggable) — те, которые игнорируют из‑за сложности мишеней и низкой коммерческой отдачи, особенно редкие заболевания. Компания полагает, что ИИ может ускорить поиск таких сложных молекул, как биспецифические и даже триспесцифические антитела: эти препараты способны одновременно воздействовать на несколько мишеней, но их проектирование — крайне сложная задача, с которой ИИ справляется лучше других. CEO Dario Amodei говорит об этом с личным опытом: его отец умер от болезни, а способ лечения появился лишь спустя несколько лет.

Однако у Anthropic уже есть чёткая граница: компания занимается только доклиническими исследованиями, не проводит клинические испытания и не конкурирует с фармкомпаниями за бизнес. Это также призвано снизить остроту реальной проблемы доверия: те крупные фармкомпании, которые используют Claude (в списке — Genentech, Bristol Myers Squibb и Novo Nordisk), беспокоятся о том, что Anthropic может «выучить» из их данных.

Стоит отметить важные временные рамки: всё это происходит накануне подготовки Anthropic к IPO с оценкой примерно в 2 трлн долларов, и как раз в момент, когда дискуссии об ИИ для безопасности достигли пика. Всего за последние две недели собственные исследователи Anthropic предупреждали, что ИИ может привести к исчезновению человечества; а также компания обнаружила риски того, что её системы могут быть использованы для разработки биологического оружия. «Жать на газ и одновременно тянуть ручник» — именно так сейчас выглядит внутреннее напряжение в Anthropic.

В качестве сравнения: Isomorphic Labs, компания в составе Google, занимается AI‑поиском лекарств уже несколько лет. Изначально планировалось выйти в клинику к концу 2026 года, но ранее это уже переносили. Реальность разработки лекарств такова: от открытия молекулы до выхода препарата на рынок обычно проходит много лет, и большинство препаратов терпят неудачу в клинических испытаниях. Амбиции Anthropic велики, но путь предстоит долгий.

Я всё чаще использую ChatGPT Pro: в основном потому, что постоянно прошу его помогать мне с техническими проектными решениями — результат особенно хороший, и при этом он не расходует лимиты Codex.

Когда мне нужно, я просто отправляю ему адрес GitHub: он анализирует код, продумывает архитектуру, составляет проектный документ, а иногда даже готовит PR. Затем я скачиваю проектный документ локально и даю Codex или Claude Code, чтобы они выполнили задачу.

Иногда я также устраиваю ему «гонки» с Fable: с одинаковой проблемой Fable и GPT 6 Pro делают свои варианты решений, а потом мы сравниваем и берём лучшее.

Обратите внимание: в настройках нужно привязать свой GitHub-аккаунт, чтобы он мог получить доступ к вашим приватным репозиториям и к PR.

Не знаю почему у моей Fable лимит использования с 97% упал до 67% — это отменили ограничение в 50%? Или это баг?

豆包大模型 2.1 Pro 发布 0915 版本更新，API 已在火山方舟全量上线。这次升级集中在四个方向：Agent 任务交付、多模态写代码、多模态理解、以及推理成本。

Agent 方面的改进

模型在需要多轮调用工具、联网查资料再出报告的场景里，强化了证据溯源和数据核验能力，幻觉明显减少。官方给的例子是金融投研：模型能自主拆解研究需求、检索数据源再建模分析，产出的底稿接近分析师水平。为了核实某车企财报里的一个说法，模型调度了 500 多个子 Agent、检索超 1000 个网页，还交叉比对了海事航迹、卫星影像等多源信息。这类"不采信单方通稿、多源交叉验证"的能力，对企业做尽调、出研报有直接价值。

多模态 Coding

这次最实用的变化可能是看图写代码。模型现在能直接读懂设计稿、图纸甚至操作录屏，把视觉信息转成前端代码。官方演示了一个场景：给模型一段录屏加几张草图，让它给一个没有文档的老 ERP 系统开发移动端页面——模型读懂了 28 万行 Java 代码，直接还原出可运行的移动端页面。

在代码仓库理解上，模型对开源游戏 Luanti（约 38.7 万行代码）做了自主修复测试，83% 的任务达到了可合并标准。对经常要在大型项目里定位问题、跨文件修 bug 的开发者来说，这个数字值得关注。

其他升级

多模态理解方面，视频推理能力增强，能在视频里定位证据、跨帧整合；图像理解在 3D 物体识别（CAD 工件、游戏引擎元素）和密集图文解析（工程图纸、财报表格）上有明显提升。

成本方面，图像和视频推理的 Token 消耗比上一代减少 30% 以上。

API 使用上有两个入口：调用 Doubao-Seed-2.1-pro-0915 可以锁定版本；调用 Doubao-Seed-Evolving 则自动跟进最新版本，不用换 Model ID。豆包工作和 TRAE 也已同步接入。

Официальная статья：https://mp.weixin.qq.com/s/Fp_mgF6wxMk0bkUVBqOKqA

Инженер Anthropic провел вводный урок по FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ

Кевин Бай сейчас работает в Applied AI-команде Anthropic. Раньше он был одним из основателей команды FDE в Rippling, а до этого несколько лет работал в Palantir. Недавно он сделал доклад про FDE 101 — очень ясно объяснил роль инженера, который развертывает решения на передовой, и это определенно стоит подытожить.

Сначала один факт с цифрами: если ранжировать публичные SaaS-компании по средней сумме контракта, то Palantir — 4 млн долларов, ServiceNow — 1,2 млн, Workday — 600 тыс., а остальные не превышают 500 тыс. Palantir, имея всего несколько тысяч человек, добился среднего чека, который другим недоступен при десятках тысяч сотрудников. И ключ здесь — модель FDE.

Итак, что именно решает FDE?

Продукт Palantir Foundry — это платформа для построения приложений, с высоким техническим порогом. Но покупатели — руководители в нефтегазе, товарах массового спроса и других отраслях, при этом они не технические специалисты. Когда вы отдаете сложную технологическую платформу человеку, который не умеет писать код, и рассчитываете, что он сам разберется, как ее использовать — это нереалистично.

Поэтому Palantir делает так: клиент покупает не программный продукт и не консультационные услуги, а «результат». Вы отправляете инженеров к клиенту, глубоко разбираетесь в его сценариях и собираете для него нужные элементы на платформе. Клиента интересует, сколько товаров появилось на полках и насколько выросла эффективность на производственной линии; его не заботит, как организованы данные — и ему не нужно об этом думать.

Чем FDE отличается от аутсорсной разработки?

Кевин особенно подчеркнул одну вещь: если ваши инженеры каждый раз с нуля пишут для клиента индивидуальный код, то это не FDE — это аутсорс-разработка. Чтобы модель FDE работала, у вас должна быть переиспользуемая платформа. Инженеры собирают и кастомизируют решения на базе уже существующих возможностей платформы, а не каждый раз «изобретают велосипед заново». Если платформы нет, то стоимость сопровождения съест всю прибыль, и инженеры начнут уходить, потому что им придется поддерживать десятки не связанных друг с другом кодовых баз.

Нужно ли вообще делать FDE? Два вопроса помогут все определить.

Первый: вам действительно нужно продавать технически сложную вещь нетехническим покупателям? Если ваши клиенты сами инженеры — например, вы продаете GitHub или Datadog — FDE не требуется. Если ваш продукт сам по себе «из коробки» — как Slack или Jira — тоже не требуется. FDE имеет смысл только тогда, когда продукт сложный, а клиент в технике не разбирается.

Второй: у вас есть переиспользуемая платформа? Или вы готовы инвестировать в ее создание? Без общих базовых компонентов FDE становится нерентабельной и несопровождаемой моделью.

Какие новые изменения появились в 2026 году?

Оценка Кевина весьма интересная: сам способ вести бизнес в софтверной индустрии изменился. AI делает создание ПО чрезвычайно простым — и почти все платформы движутся в сторону Agent-режима. Это означает, что почти все платформы становятся сильно настраиваемыми. Следствие в том, что все больше клиентов не понимают, что именно умеет ваш продукт. Передавать успех/провал продукта на то, чтобы клиент сам разобрался в Agent-эпоху, становится все труднее.

Так FDE — из эксклюзивного узкого приема Palantir — превращается в вопрос, который уже многим компаниям-разработчикам ПО стоит рассматривать всерьез.

И последний вопрос: какой тип людей подходит для FDE?

Ответ Кевина короткий: FDE — это программная инженерия, которой вы настолько доверяете, что можете отправлять этого человека напрямую общаться с клиентом. Техническая компетентность — базис, но вам еще нужно быть уверенным, что он сможет представлять компанию и взаимодействовать с клиентом.

В последнее время очень много vibe coding, особенно когда лимит скоро сбрасывается: тогда кидают кучу задач агентам. Некоторые задачи отображаются как выполненные — и я их не трогаю, но на следующий день в тестировании выясняется, что задача не выполнена. Возвращаюсь проверить — оказывается, агенту создали worktree, и изменения сделаны не в main, а на стороне: по сути, это вообще не было смёрджено.

Потом я попросил агента дополнительно всё тщательно проверить и нашёл ещё несколько таких worktree — он их почистил.

В итоге я попросил его добавить в Agents.md правило: нельзя оставлять worktree, если их создали — пропускать нельзя.

--- Пример подсказки для проверки worktree ---

Помоги мне посмотреть, какие worktree ещё не синхронизированы с main. Те, что уже синхронизированы — сразу удали. Те, что не синхронизированы — перечисли: ветка, краткое описание изменений (включая несколько последних commit’ов), соответствующая сессия session.

--- Пример подсказки для очистки worktree ---
Помоги мне посмотреть содержимое этих worktree: чётко определи, что действительно стоит смёрджить — помоги мне смёрджить это и почистить worktree. Непонятное — сначала уточни у меня, но дай понятные рекомендации.

--- Правила из AGENTS.md ---

- Не оставлять worktree следов: задачи, сделанные в worktree, при завершении обязательно должны быть удалены вместе с этим worktree и его веткой. Перед удалением выбери одно из двух: смёрджить в `main`; или если не смёрдживать — сначала закоммить непроиндивидуальные изменения в этой ветке, поставить тег `archive/<worktree 名>` для архива, затем выполнить `git worktree remove` + `git branch -D`. Сессия, оркестрирующая subagent’а, отвечает за доведение до конца и очистку его производных worktree. Если всё-таки нужно сохранить (ожидает решения пользователя, есть конфликты, которые нужно разрулить) — в финальном ответе явно укажи пути и причины, нельзя просто оставить молча.