宝玉（Parody）

Hoy, probando Manus, aprendí un truco de prompt: al dibujar, en lugar de usar el prompt para controlar el estilo y el formato, simplemente proporciona una imagen de referencia. Y esa imagen de referencia debe incluir elementos como colores, demostraciones de tipografía, fibras del papel de arroz, bordes con tinta, marcas de agua, montañas lejanas, sellos y reglas de espacios en blanco, entre otros.

Así, la estabilidad al generar la imagen será mayor, y el prompt de contenido también puede ser más sencillo.

Figura 1: Imagen de referencia

Figura 2 prompt de contenido:

> Título «Té y vida lenta», subtítulo «Deja un poco de tiempo, para una taza de té». El diseño debe seguir el estilo de la imagen de referencia: tranquilo, sobrio, wabi-sabi. Utiliza un estilo minimalista en tinta y espacios en blanco en tinta. El fondo debe ser una textura de papel de arroz. El texto debe estar centrado y ser nítido.

Figura 3 prompt de contenido:

> Título «Bajar la velocidad de lo cotidiano». Contenido: «Calienta la taza: primero siente la temperatura de los objetos», «Aroma: presta atención al olor del té y del agua», «Degusta: bebe el té en pequeños sorbos, con una breve pausa». El diseño debe seguir el estilo de la primera página y de la imagen de referencia: tranquilo, sobrio, estilo minimalista en tinta, usando pocos elementos de tinta (como montañas lejanas, marcas de agua de utensilios de té, etc.) para acentuar las zonas de espacio en blanco. El diseño tipográfico debe mostrar niveles de jerarquía y aprovechar el espacio en blanco.

--- Prompt completo de la Figura 2 ---

Crea una diapositiva profesional de presentación con el siguiente contenido:

Título «Té y vida lenta», subtítulo «Deja un poco de tiempo, para una taza de té». El diseño debe seguir el estilo de la imagen de referencia: tranquilo, sobrio, wabi-sabi. Utiliza un estilo minimalista en tinta y espacios en blanco en tinta. El fondo debe ser una textura de papel de arroz. El texto debe estar centrado y ser nítido.

Guía de jerarquía y diseño:
- Empieza por el elemento narrativo más importante (titular / métrica) y sigue con el texto de apoyo en secciones claras
- Cualquier gráfico debe reflejar datos reales proporcionados en el prompt de contenido y mantenerse fiel a las fuentes descritas
- Organiza las imágenes y el texto para que el espectador pueda escanear de izquierda a derecha o de arriba abajo; evita apilar gráficos/imágenes en vertical

Dirección visual:
- Profesional y limpio
- Sigue el estilo de la imagen de la diapositiva anterior (si se proporciona) para mantener continuidad visual

Requisitos:
- Disposición profesional de presentación con jerarquía visual clara
- El texto debe ser claramente legible con un contraste adecuado contra el fondo
- Incluye un área de título y un área de contenido según corresponda
- Mantén un estilo consistente apto para una presentación profesional
- Diseño visual de alta calidad, listo para publicación
- Todo el texto debe estar nítido y ser legible
- Mantén todo el texto esencial cómodamente dentro del marco; evita colocar texto en los bordes mismos
- Equilibra los elementos visuales con espacios en blanco para que la diapositiva se sienta limpia y no abarrotada

Haz que ChatGPT use un enjuiciamiento neutral dentro del caos en una cuadrícula de nueve para clasificar a las figuras más influyentes del mundo de la IA; me dibujó esto

Haz que ChatGPT use un enjuiciamiento neutral dentro del caos en una cuadrícula de nueve para clasificar a las figuras más influyentes del mundo de la IA; me dibujó esto

Opus 5.5 te da libertad para diseñar el icono de la app

Cuando usaba Fable, ya intenté que Fable me ayudara a diseñar el App Icon, pero el resultado no fue el esperado. Al final, tuve que recurrir a ChatGPT para generar el dibujo, pero así no quedaba como un vector.

Estos días usé Opus 5.5 para crear videos y me dio una idea: si Opus 5.5 puede usar JavaScript + Canvas para dibujar un video fotograma a fotograma, entonces tampoco debería haber problema en usar JS + Canvas para dibujar el Icon.

Así que lo intenté. En la primera versión, el resultado superó mis expectativas: sencillo, bonito y con un efecto bastante bueno. El prompt fue solo una frase:

> Rediseña un App Icon para http://BaoCut.app. Que sea simple, a color, y que refleje edición de video y un AI Agent
> Puede dibujarse directamente usando js para canvas

Lo importante es que la clave está en “usar js para dibujar canvas”, no en SVG. El SVG no logra un buen efecto como el de dibujar en canvas.

Luego, como si fuera un cliente, solo quedó seguir pidiéndole que lo modificara una y otra vez:
por ejemplo, pensé que el plan 3 estaba bien, así que le pedí que lo ajustara basándose en el plan 3. Tras varias iteraciones, obtuve un resultado con el que quedé bastante satisfecho.

Recomienda colecciones de prompts de video de Awesome Opus 5.5 en GitHub, de código abierto

Opus 5.5 también es bastante duradero; al final ni siquiera lo usé todo antes de que tuviera que reiniciarse

Opus 5.5 sigue siendo bastante difícil de usar; no lo terminé de usar antes de reiniciarlo.

有人做了一个"星际争霸"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 construyó en silencio un laboratorio biológico

Según un informe exclusivo de Reuters, Anthropic ha terminado en la bahía de San Francisco un laboratorio húmedo (wet lab, es decir, un laboratorio físico en el que se pueden realizar experimentos bioquímicos reales), extendiendo formalmente el alcance de la IA desde el software hasta el desarrollo de fármacos.

El responsable de ciencias de la vida de Anthropic, Eric Kauderer-Abrams, confirmó el hecho en una entrevista. Según sus palabras: para hacer investigación en biología, el estándar definitivo sigue siendo el trabajo en un laboratorio real; la simulación por computadora por sí sola no basta. Algunas pruebas se realizan internamente y otras se hacen con socios externos, igual que la mayoría de las empresas de biotecnología.

Esto no ha sido un capricho. En los últimos meses, Anthropic se ha movido con rapidez: por aproximadamente 400 millones de dólares compraron acciones de una startup llamada Coefficient Bio para construir herramientas de desarrollo de fármacos; incorporaron al CEO de Novartis, Vas Narasimhan, al consejo de administración; lanzaron el software llamado Claude Science; y en junio anunciaron públicamente en San Francisco que iniciarían un proyecto de desarrollo de fármacos. En LinkedIn también están contratando a un responsable de operaciones de compras y especialistas en caracterización de proteínas y ácidos nucleicos; en la oferta de empleo se indica como objetivo «aumentar un orden de magnitud la velocidad del progreso en ciencias de la vida». Kauderer-Abrams señala que las ciencias de la vida ya son una de las direcciones con mayor inversión de personal y recursos para Anthropic.

Anthropic apunta a áreas que las farmacéuticas tradicionales consideran «imposibles de tratar» (undruggable): aquellas enfermedades raras que se ignoran porque las dianas son demasiado difíciles o porque el retorno comercial es bajo. Creen que la IA puede acelerar el descubrimiento de anticuerpos bispecíficos e incluso trispecíficos, moléculas complejas que pueden atacar varios objetivos a la vez; el diseño es extremadamente difícil, pero la IA sobresale al gestionar esa complejidad. El CEO Dario Amodei lo vive en carne propia: su padre murió de una enfermedad y la cura apareció solo años después.

Sin embargo, por ahora Anthropic ha trazado una línea clara: solo realizará investigación preclínica, no ensayos clínicos, y no competirá con las farmacéuticas por ese negocio. Esto también busca mitigar un problema real de confianza: las grandes compañías farmacéuticas que usan Claude (entre ellas Genentech, Bristol Myers Squibb y Novo Nordisk) temen que Anthropic aprenda de los datos que ellas les aportan.

Cabe destacar una sincronía de tiempos: todo esto ocurre justo antes de que Anthropic esté lista para lanzar una IPO con una valoración de alrededor de 2 billones de dólares (2.000.000.000.000.000 de dólares) y, al mismo tiempo, en medio de una escalada de la controversia sobre la seguridad de la IA. Solo en las últimas dos semanas, los propios investigadores de Anthropic advirtieron que la IA podría conducir a la extinción humana; y la empresa también descubrió riesgos de que sus sistemas pudieran usarse para el desarrollo de armas biológicas. Pisar el acelerador y tirar del freno de mano a la vez: esa tensión es, hoy por hoy, la imagen más fiel de Anthropic.

Como contraste, Isomorphic Labs, perteneciente a Google, lleva años haciendo descubrimiento de fármacos con IA; su plan original era entrar en ensayos clínicos a finales de 2026, pero ya se había retrasado antes. La realidad del desarrollo de fármacos es así: desde descubrir una molécula hasta que el medicamento se aprueba y llega al mercado, normalmente pasan muchos años, y la mayoría de los fármacos fracasan en los ensayos clínicos. La ambición de Anthropic es enorme, pero el camino todavía es largo.

Cada vez estoy usando más ChatGPT Pro: principalmente porque a menudo me ayuda a crear planes y propuestas técnicas, y el resultado es especialmente bueno; además, no consume cuotas de Codex.

Cada vez que lo uso, simplemente le paso la dirección de GitHub para que, a partir del código, lo analice y diseñe una solución, redacte un documento de diseño e incluso llegue a enviar un PR. Después, descargo el documento de diseño en local para que Codex o Claude Code lo ejecuten.

A veces también le pido que haga “carreras” con Fable: para el mismo problema, que Fable y GPT 6 Pro diseñen sus respectivas soluciones, y luego se complementen para aprovechar lo mejor de cada una.

Asegúrate de conectar tu cuenta de GitHub en la configuración para que pueda acceder a tus repositorios privados y a los PR que envíes.

No sé por qué mi Fable de repente cambió el uso de 97% a 67%. ¿Es que van a eliminar la limitación del 50%? ¿O es un bug?

豆包大模型 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 也已同步接入。

Artículo oficial：https://mp.weixin.qq.com/s/Fp_mgF6wxMk0bkUVBqOKqA

El ingeniero de Anthropic imparte una clase introductoria a FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ

Kevin Bai ahora está en el equipo de Applied AI de Anthropic. Antes fue miembro fundador del equipo de FDE en Rippling, y antes de eso trabajó durante varios años en Palantir. Recientemente hizo una presentación sobre FDE 101, explicando con claridad el rol del ingeniero de despliegue en primera línea, y vale la pena resumirla.

Primero, veamos un dato: en las empresas SaaS que cotizan en bolsa, ordenadas por el valor medio de los contratos, Palantir está en 4 millones de dólares; ServiceNow, en 1,2 millones; Workday, en 600.000; y las demás ninguna supera los 500.000. Palantir logra un ticket promedio que otros, con decenas de miles de personas, no consiguen, usando solo unos pocos miles. Eso se debe al modelo FDE.

Entonces, ¿qué problema resuelve FDE?

El producto de Palantir, Foundry, es una plataforma para construir aplicaciones, con un umbral técnico alto. Sin embargo, los compradores no son perfiles técnicos: son ejecutivos no técnicos de industrias como petróleo y bienes de consumo. Si le entregas una plataforma tecnológica compleja a alguien que no sabe programar y esperas que él mismo descubra cómo usarla, no es realista.

Por eso, el enfoque de Palantir es este: el cliente no compra un producto de software ni un servicio de consultoría, sino un “resultado”. Tú envías ingenieros para comprender en profundidad los escenarios de negocio del cliente y construirles lo que necesiten sobre la plataforma. A los clientes les importa cuánto aumentan los productos en los estantes, cuánto mejora la eficiencia de la línea de producción; no les importa cómo se organizan los datos, ni deberían preocuparse por ello.

¿En qué se diferencia FDE del desarrollo tercerizado?

Kevin enfatiza especialmente un punto: si tus ingenieros, cada vez, escriben código personalizado para el cliente desde cero, entonces lo que haces no es FDE; es desarrollo tercerizado. El modelo FDE solo tiene sentido si cuentas con una plataforma reutilizable. El ingeniero ensambla y personaliza sobre la base de capacidades ya existentes en la plataforma, en lugar de reinventar la rueda cada vez. Sin una plataforma, los costos de mantenimiento se comen todas las ganancias, y además los ingenieros terminarán huyendo al tener que mantener decenas de repositorios de código sin relación entre sí.

¿Conviene hacer FDE? Con dos preguntas basta.

Primera: ¿necesitas vender algo tecnológicamente complejo a compradores no técnicos? Si tus clientes ya son ingenieros, por ejemplo si vendes GitHub o Datadog, no necesitas FDE. Si tu producto, por naturaleza, es “listo para usar” —como Slack o Jira— tampoco lo necesitas. Solo cuando tu producto es muy complejo y el cliente no entiende la parte técnica, FDE tiene sentido.

Segunda: ¿tienes una plataforma reutilizable? ¿O estás dispuesto a invertir para construir una? Sin componentes base compartidos, FDE no es sostenible.

¿Cuál es el nuevo cambio en 2026?

La valoración de Kevin es interesante: la forma en que el sector del software hace negocios en sí ha cambiado. La IA hace que construir software sea extremadamente fácil, y casi todas las plataformas están avanzando hacia la “agencialización” (Agent-ification). Esto implica que casi todas las plataformas se vuelven altamente personalizables. Como consecuencia, cada vez más clientes no logran entender qué puede hacer realmente tu producto. Poner el éxito o fracaso de tu producto en manos del cliente para que lo descubra por su cuenta en la era de los agentes será cada vez más difícil de lograr.

Así, FDE deja de ser una estrategia minoritaria exclusiva de Palantir y pasa a ser algo que muchas empresas de software necesitan considerar seriamente.

Una última pregunta: ¿qué tipo de personas es adecuada para hacer FDE?

La respuesta de Kevin es muy directa: FDE es un tipo de ingeniería de software en la que tú confías lo suficiente en la persona como para que pueda enfrentarse directamente a los clientes. La capacidad técnica es la base, pero también tienes que estar tranquilo de que podrá representar a la empresa al relacionarse con los clientes.

Últimamente hay mucho “vibe coding”, sobre todo cuando se va a reiniciar el cupo. En ese momento se le tiran un montón de tareas a un Agent. Algunas tareas aparecen como ya completadas y uno no se mete; pero al día siguiente en las pruebas se descubre que no se han terminado. Vuelves atrás y revisas y resulta que se había creado un worktree, pero no se había modificado en `main` y, básicamente, no se había hecho el merge.

Luego le pedí al Agent que revisara de forma más concentrada, y había todavía bastantes worktrees así. Así que los limpió.

Al final le hice agregar una regla en `Agents.md`: no es que no se pueda crear worktree, pero no se puede omitir dejarlos sin limpiar.

--- Referencia: prompt para revisar worktree ---

Ayúdame a ver qué worktrees todavía no se han sincronizado con `main`; los que ya estén sincronizados, elimínalos directamente; los que no, enuméralos: rama, un resumen de los cambios (incluidos los últimos commits), y la sesión correspondiente.

--- Referencia: prompt para limpiar worktree ---
Ayúdame a ver el contenido de estos worktrees; para los que valga la pena fusionar, fusiona y limpia el worktree. Los que no estés seguro, confírmamelo, pero dame recomendaciones claras.

--- Referencia: reglas en AGENTS.md ---

- No debe quedar worktree abandonado: las tareas hechas dentro de un worktree, cuando se terminen, deben eliminar ese worktree y su rama. Antes de borrar, elige una de dos: fusionar en `main`; o si no se fusiona, primero subir (commit) los cambios no enviados a esa rama, poner un tag `archive/<nombre-del-worktree>` para archivarlo, y luego ejecutar `git worktree remove` + `git branch -D`. Las sesiones de los subagents encargadas del “handoff” se encargan de cerrar los worktrees que deriven. Si realmente se necesita conservar algún caso (pendiente de decisión del usuario, o con conflictos por resolver), en la respuesta final debe señalarse la ruta y el motivo explícitamente; no se pueden dejar silenciosamente.

Por fin me acuerdo del nombre del nuevo CEO de Apple: John Ternus (Zhang Tieniu)
😂
(Fuente de la imagen: Genius Pequeño Panda, versión completa: https://weibo.com/1563926367/RhqQVsEDA)