DjangoBB LoFi version

Полная версия: Генерация кода с помощью ИИ

Начало » Флейм » Генерация кода с помощью ИИ

1 2 3 4 5 6

slav0nic

Июнь 12, 2025 22:29:13

Я больше https://claude.ai/ пользуюсь (для кода в целом наверно лидер на рынке), в платной версии есть проекты, но схему и так можно закинуть. Только для начала стоит попросить обсудить проект, чтоб убедиться в правильном понимании задачи, а то люби он артефакты сразу писать на 1к строк.
Gemini в целом тоже ок, как и ChatGPT, но им чет реже всего пользуюсь.
CF вот либу на нем наваял под oauth хотя и отзывы спецов разнятся, но сам кейс вполне интересный (задача не самая тривиальная):

https://www.maxemitchell.com/writings/i-read-all-of-cloudflares-claude-generated-commits/
https://neilmadden.blog/2025/06/06/a-look-at-cloudflares-ai-coded-oauth-library/

Промты есть на гитхабе в коммитах.

Rodegast

Июнь 12, 2025 23:38:46

В общем добавил DDL схему и попытался скормить этот запрос ChatGPT и какому то SQL GPT. Ни один из них внятного результата не выдал. Если бы задача была какой нибудь ученой, то может оно и справилось, но только не с этой.

py.user.next

Июнь 13, 2025 01:23:59

Rodegast
Всю информацию “Еретик” хранит в PostgreSQL и сейчас я занимаюсь тем что прикручиваю туда контроль версий. Для этой цели были сделаны составные первичные ключи (branch, id).

Довольно запутанная схема базы данных у тебя. Возможно, где-то у тебя отдельное отношение размазано по остальным отношениям. Лучше сделать отдельное отношение (таблицу, как ты называешь), чем размазывать её по другим отношениям. Иначе так ты не экономишь, а запутываешь всё. Потом это приводит к затыку по всей базе данных в итоге.

Может, она у тебя и умная, но на первый взгляд я вообще ничего не понял по структуре, выглядит грязной, смешанной, всё в одной кастрюле как будто - борщ, носки, пакет сахара. Нейронная сеть тем более не поймёт, о чём речь.

Rodegast

Июнь 13, 2025 16:53:31

> Довольно запутанная схема базы данных у тебя

Ты её даже не видел. В реальности она раз в 15 больше чем то что на картинке.

> отдельное отношение размазано по остальным отношениям

Таблица “размазана” по таблицам? Ты бы хоть термины правильное выучил

> Нейронная сеть тем более не поймёт, о чём речь.

Она по определению ничего понять не может. Попробовал я ей второй шанс дать и из описания удалил таблицу shema_scope. И ничего, эта дура всё равно ничего толкового сгенерить не может.

xam1816

Июнь 13, 2025 21:03:14

Rodegast
PS. Сейчас попробовал её отправить в ChatGPT, он вообще ничего не понял.

Закинул твой же пост с картинкой в GPT

такой ответ предложил

Отлично! Учитывая твой исходный вопрос, ты работаешь с тремя таблицами:

elements

shema_scope

nexus

Все они используют составной ключ (branch, id) — значит, ветка (branch) — это твоя “коробка”, в которой живёт определённая версия схемы.

📦 Хранимая процедура: create_branch
Ниже — процедура, которая:

Принимает source_branch (откуда копировать) и new_branch (куда)

Копирует:

elements

shema_scope

nexus

Заменяет branch на новую

Не трогает оригинальные id, element, element_1, element_2 и т.п. — ты сам этим управляешь

🧠 Условие:
Ты хранишь все версии в этих таблицах — новые branch просто добавляют копии, не затирая оригинал.

✅ Хранимая процедура:
sql
Копировать
Редактировать

 CREATE OR REPLACE FUNCTION create_branch(source_branch UUID, new_branch UUID)
RETURNS void AS $$
BEGIN
  -- Копируем elements
  INSERT INTO elements (branch, id, func, type, text, idx, csv_status)
  SELECT new_branch, id, func, type, text, idx, csv_status
  FROM elements
  WHERE branch = source_branch;
  -- Копируем shema_scope
  INSERT INTO shema_scope (
    branch, element, return_type, func, argument, patern_id,
    data_cast, data_cast_brainc, call, call_branch, constant,
    constant_branch, call_operator, operator_branch, construct,
    construct_branch, shema_scop, name, expression, csv_status
  )
  SELECT new_branch, element, return_type, func, argument, patern_id,
         data_cast, data_cast_brainc, call, call_branch, constant,
         constant_branch, call_operator, operator_branch, construct,
         construct_branch, shema_scop, name, expression, csv_status
  FROM shema_scope
  WHERE branch = source_branch;
  -- Копируем nexus
  INSERT INTO nexus (branch, element_1, element_2, point_1, point_2, csv_status)
  SELECT new_branch, element_1, element_2, point_1, point_2, csv_status
  FROM nexus
  WHERE branch = source_branch;
END;
$$ LANGUAGE plpgsql;

📦 Пример использования
sql
Копировать
Редактировать

 -- Генерируем UUID новой ветки (можно сделать в коде)
SELECT gen_random_uuid();  -- допустим: '11111111-2222-3333-4444-555555555555'
-- Создаём ветку
SELECT create_branch(
  '00000000-0000-0000-0000-000000000000',  -- исходная ветка main
  '11111111-2222-3333-4444-555555555555'   -- новая ветка
);

📌 Примечания
id, element, element_1, element_2 остаются теми же — потому что они уникальны только в рамках branch.

Все внешние связи (func, call, element, …) продолжают работать, потому что они тоже указывают на (branch, id).

Никаких DELETE и UPDATE — всё аккуратно, как в Git.

Если хочешь — могу помочь добавить:

авто-лог в таблицу branches

авто-проверку на существование ветки

merge или diff-логику

Хочешь продолжить в эту сторону?

Интересны твои замечания, чем этот вариант плох. Тут даже не про работоспособность кода пока, а про саму идею. Правильно ли нейросеть тебя поняла, что тебе нужно

Rodegast

Июнь 13, 2025 21:18:19

> Правильно ли нейросеть тебя поняла, что тебе нужно

Конечно нет. Мне надо копировать только определённую схему, а не всю ветку.

xam1816

Июнь 13, 2025 21:36:44

Rodegast
Конечно нет. Мне надо копировать только определённую схему, а не всю ветку.

Вот в этом и особенность работы с нейросетью, чтобы ей предсказать более точный ответ, ей нужно максимально детально описать, что нужно, а лучше привести пример хотя бы абстрактный.

Еще можно задать вопрос, что она поняла из твоего запроса и если что-то не правильно поняла, можно разбить свой запрос на части, и каждый раз спрашивать, как она поняла

Вот ответ от нее

Понял, ты хочешь копировать не всю ветку целиком, а конкретную схему (например, одну логическую единицу, набор связанных элементов) из одной ветки в другую.

Давай уточним, чтобы дать максимально точное решение:

Важные вопросы для точного понимания задачи
Что конкретно означает “схема”?
Как ты её идентифицируешь? По какому полю?
— Например, есть ли у тебя в таблицах какой-то идентификатор схемы (schema_id, shema_scope_id, pattern_id или подобное)?

Какие данные именно копировать?
Только записи из трёх таблиц (elements, shema_scope, nexus), относящиеся к этой схеме?
Или надо копировать и связанные с ними объекты?

Как определяются связи внутри схемы?
— Например, nexus соединяет элементы по element_1, element_2. Эти элементы принадлежат схеме? Нужно ли копировать все элементы, на которые ссылается nexus?

Нужно ли при копировании обновлять ссылки?
Если копируются элементы с одним и тем же id в новой ветке, ссылки на элементы (в shema_scope и nexus) остаются прежними? Или надо создавать новые id?

Rodegast

Июнь 13, 2025 22:11:56

> Что конкретно означает “схема”?

Иерархическую совокупность элементов.

> Как ты её идентифицируешь? По какому полю?

func в таблице elements

> Какие данные именно копировать?

Только то что в таблицах

> Как определяются связи внутри схемы?

Для связей между элементами используется таблица nexus

> Нужно ли при копировании обновлять ссылки?

Не надо

py.user.next

Июнь 13, 2025 23:38:17

Rodegast
Таблица “размазана” по таблицам? Ты бы хоть термины правильное выучил

Это простонародное название отношений. А отношение - это математическое понятие. Relation - потому и реляционная она. Не по связям между “таблицами” она считается реляционной, а по тем отношениям, из которых она состоит сама по себе. Сами “таблицы” - это и есть те отношения, о которых речь идёт. Чем отличается? Ну в таблице есть столбцы и строки. Первая строка - это первая строка, вторая строка - это вторая строка. Со столбцами то же самое. А отношение - это множество n-ок, упорядоченных или неупорядоченных, поэтому у элементов нет порядка. Нет первой строки и второй строки, они все и первые, и вторые одновременно. И нет первого и второго столбца, они тоже все первые и вторые одновременно. Так как отношение состоит из неупорядоченных элементов.

Rodegast
Ты её даже не видел. В реальности она раз в 15 больше чем то что на картинке.

Не, я обратил внимание на неинформативные названия полей в стиле “здравствуй лошадь первого разбойника, здравствуй лошадь второго разбойника”. Ты вот эти элемент1 и элемент2 назвал так, будто ты на какое-то короткое время это отношение создал, чтобы чисто посмотреть, какой-то эксперимент провести, потому что неинформативные названия потом сто процентов выстрелят где-нибудь, а для их замены в тот момент на нормальные и понятные не будет ресурсов.

Также у меня есть подозрение, что с составными ключами у тебя что-то и их можно сузить. То есть я не вижу подтверждения, что ты нормализовал отношения некоторые по второй нормальной форме. У тебя точно нет суррогатных первичных ключей в смеси с другими ключами? Зачем тебе составные первичные ключи понадобились? В нормализованном отношении, как правило, всё ясно видно и оно выглядит просто. В общем, не экономь на этих вещах. Потому что это всё равно что код писать в одну строчку ради показывания его умности. Но, как мы знаем, однострочный код неподдерживаемым получается в большинстве случаев. Поэтому его не только не читают потом, но и при любой поломке выкидывают сразу целиком, потому что новый и чистый код будет быстрее написать, чем разбираться в таком “умном” и таком нерабочем. Помнишь, да, про Zen? там вот много правил в стиле “простое лучше сложного”, перечитай его; может, пришло время понять его с новой стороны с твоего нового уровня развития.

Правила Дзена понимаются каждый раз по-разному. Раз в три-пять лет заходишь, перечитываешь их и обобщаешь на весь свой опыт, сложившийся к тому моменту. Привязываешь их к SOLID, к UNIX, к ООП, к ФП. На разных этапах развития прочищаешь их. Вот и базы данных требуют уже понимания, что всё должно быть просто. Их необязательно только к питону применять.

Rodegast

Июнь 14, 2025 00:12:44

> Это простонародное название отношений

Таблица это термин используемый в официальном описании стандарта SQL.

> А отношение - это математическое понятие … Так как отношение состоит из неупорядоченных элементов.

Я тебе уже про это писал, но ты видно не понял. SQL и реляционная алгебра сильно разные вещи и не нужно их путать.

> я обратил внимание на неинформативные названия полей

Названия вполне информативные. Ты не знаком с предметной областью по этому так и показалось.

> У тебя точно нет суррогатных первичных ключей в смеси с другими ключами

С какими другими?

> Зачем тебе составные первичные ключи понадобились?

А ты внимательно почитай что чат написал даже он про них правильно понял

http://python.su/forum/topic/43647/?page=4#post-234115