📕 OpenAI выкатила гайд по написания промптов в задачах программирования для GPT-5.

Вот 6 главных правил:

1️⃣ Хватит «лить воду». GPT-5 стала в разы лучше следовать инструкциям. Обратная сторона: любая расплывчатость или конфликт в промпте будут ухудшать качество.

2️⃣ Правильно выбирайте «усилие». У модели теперь есть уровни «глубины мышления» (reasoning effort). Для сложных задач включаем high, для простых — low или medium. Иначе она начнёт овер-инжинирить калькулятор и писать для него микросервисную архитектуру.

3️⃣ Говорите на языке XML. Чтобы модель не запуталась в контексте, ей нужно его структурировать. Оборачивайте правила, гайдлайны и примеры в XML-подобные теги (<code_editing_rules>, <persistence>).

4️⃣ Не будьте слишком настойчивы. Команды в стиле «Будь МАКСИМАЛЬНО тщательным!» или «Убедись, что у тебя ПОЛНАЯ картина!» теперь вредят. Модель и так стремится к дотошности, и такие приказы заставляют её уходить в параноидальный режим сбора контекста.

5️⃣ Дайте ей «подумать». Для реально сложных задач (типа «напиши мне приложение с нуля») нужно давать инструкции для саморефлексии. Буквально заставлять её сначала продумать план и критерии успеха (<self_reflection>), а потом уже писать код.

6️⃣ Держите агента на поводке. По умолчанию GPT-5 рвётся в бой и пытается сделать всё и сразу. Её «рвение» нужно контролировать: задавать бюджет на использование инструментов и чётко прописывать, когда можно действовать самостоятельно, а когда — спрашивать человека.

А вы как пишите промпты? 👇🏻

Помните, недавно щупали Matrix-Game 2.0 — нейронку, которая строит мир по нажатию клавиш? Так вот, забудьте. На ринг вышел тяжеловес 🥊

Tencent (да, те самые, что делают PUBG) выкатили Hunyuan-GameCraft — опенсорсный фреймворк на Python для генерации интерактивных игровых миров.

- Память как у слона: Модель помнит сцену и не разваливается после пары поворотов, в отличие от многих предшественников.
- Обучена на AAA-играх: Ее натаскали на миллионе геймплейных роликов из 100+ топовых игр. Она знает, что такое "красиво" и "динамично".
- Ускоренная версия: Есть дистиллированная модель, которая генерит кадры в разы быстрее, приближаясь к реальному времени.

Вот вам статейка с инструкцией по запуску и кратким анализом архитектуры: Hunyuan-GameCraft: Запускаем процедурный игровой мир от Tencent 🔙🔙

Как думаете, сколько лет осталось до игр с полностью генерируемыми мирами, в которые можно будет полноценно играть? Год? Три? Пять? 👇

#щупаем_сорцы

Из забавного: изучал по каким запросам выводятся статьи на моем сайте.

Есть перлы, конечно 😅

Сколько боли в этом запросе 👨‍💻

#хих

🧑‍💻 Сегодня в роли патологоанатома. На операционном столе — репозиторий с 14 играми на Python.

Наткнулся на GitHub-сборник классики: Pacman, Tetris, Flappy Bird... всё на Python. С одной стороны — респект автору, всё работает. С другой — это идеальный пример, набитый классическими «болячками», на которых можно учиться.

Давайте препарируем пару самых интересных случаев. Не для критики, а для образовательных целей. Чем работающий код отличается от хорошего?

Пациент №1: Шашки и порочный круг импортов.

В коде есть классы Piece, Pawn и King. Пешка (Pawn) может стать королем (King). Оба наследуются от Piece. И чтобы превратить пешку в короля, автор делает вот так внутри метода класса Piece:

# Checkers/Piece.py
def _move(self, tile):
    # ...
    if self.notation == 'p':
        if self.y == 0 or self.y == 7:
            from King import King # <--- АТАС!
            tile.occupying_piece = King(...)

Диагноз: Импорт внутри метода! Так автор обошел циклическую зависимость (Piece импортирует King, а King импортирует Piece). Это симптом больной архитектуры. Фигура не должна знать о правилах своей "прокачки".

Лечение: Делегировать! Класс Board (доска) должен управлять правилами. Метод _move просто возвращает True, а уже Board проверяет, не пора ли пешке стать королем, и создает новый объект King. Так мы разрываем порочную связь.

Пациент №2: Flappy Bird и суп из глобальных переменных 🐤

# Flappy Bird/game.py
window_width = 600
#...
pipeVelX = -4
bird_velocity_y = -9
birdAccY = 1

Диагноз: Классика. Глобальные переменные и «магические числа». Что такое -4? Что такое 1? Через неделю сам автор забудет. Менять баланс игры — адская боль, нужно выискивать эти цифры по всему коду.

Лечение:
1. Все константы — в отдельный класс GameConfig.
2. Всю логику и состояние (score, bird_velocity_y) — внутрь класса FlappyBirdGame и его атрибутов (self.score).

И вот так работающий код превращается в хороший. Разница — в архитектуре и подходе.

Разобрал еще 4 типовые ошибки из этого репо (управление ресурсами, смешение логики и отображения и др.) в статье с примерами.

👉 Читать про 6 ошибок новичка

А какие «костыли» из этого списка вы сами городили в начале пути? Признавайтесь 👇🏻

💡 Разбор задачи про прыжки квантовой блохи

1️⃣ Хорошее решение: инженерный подход (DP + кэш)

Решение через динамическое программирование с мемоизацией — очень хороший вариант. Выглядит он примерно так:

from functools import cache

def count_dp(start_pos, end_pos, k):
    @cache
    def dp(p, s):
        # Базовый случай: шаги кончились
        if s == 0:
            return 1 if p == end_pos else 0
        
        # Рекурсивный шаг: прыгаем влево и вправо
        return dp(p - 1, s - 1) + dp(p + 1, s - 1)

    return dp(start_pos, k)

Мы рекурсивно исследуем все пути, а декоратор @cache спасает нас от повторных вычислений для одних и тех же состояний (позиция, оставшиеся шаги). Классика, которая точно сработает на собеседовании. Но можно ли лучше?

Спойлер: можно.

2️⃣ Идеальное решение: комбинаторика

А что, если я скажу, что эту задачу можно решить одной формулой, без всяких рекурсий и DP? 😏

Вся магия кроется в комбинаторике. Давайте рассуждать:
- Пусть R — количество шагов вправо, а L — количество шагов влево.
- Очевидно, что общее число шагов R + L = k.
- Итоговая позиция: start_pos + R - L = end_pos, откуда R - L = end_pos - start_pos.

У нас есть система из двух линейных уравнений. Решив её, мы легко найдем, что R = (k + end_pos - start_pos) / 2.

И тут всё превращается в классическую задачу из комбинаторики:

Сколькими способами можно выбрать R шагов "вправо" из k общих шагов?

А это — биномиальный коэффициент, или C(k, R). В Python 3.8+ для этого есть готовая функция math.comb.

Сначала пара проверок на адекватность:
1. Разница в позициях abs(start_pos - end_pos) не может быть больше k.
2. Чётность должна совпадать: (k - abs(start_pos - end_pos)) % 2 == 0. Если разница нечётная, то и шагов должно быть нечётное кол-во (и наоборот).

Итоговый код:

import math

def count_math(start_pos, end_pos, k):
    dist = end_pos - start_pos

    if abs(dist) > k or (k - dist) % 2 != 0:
        return 0

    # Находим число шагов вправо
    r = (k + dist) // 2
    
    # Считаем C(k, r)
    return math.comb(k, r)

Итог: вместо потенциально медленного DP со сложностью O(k * dist) мы получаем решение за O(1) (если считать math.comb быстрым для разумных k).

Вот она, сила математики! 🧠

#алгособес