feat: stronger defense arguments in rework analysis

Analyze prompt now asks for 4-part structured argument per defense:
  ZAMECHANIE / NEOBKHODIMOST / OPTIMALNOST / ALTERNATIVY

Generated code gets DESIGN DECISION / NECESSITY / OPTIMALITY /
ALTERNATIVES CONSIDERED comment blocks instead of bare NOTE.

Agent argues that choices were deliberate, necessary and optimal -
not just correct.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
2026-06-04 19:41:17 +03:00
parent 02ed3aa99f
commit 7faae42204
+31 -15
View File
@@ -371,39 +371,55 @@ extra_files — только если нужны доп. файлы, иначе
''' '''
_ANALYZE_PROMPT = '''\ _ANALYZE_PROMPT = '''\
Ты — опытный Python-разработчик. Проанализируй комментарии преподавателя к решению Ты — старший Python-разработчик и технический эксперт. Тебе нужно проанализировать
учебного задания и вынеси вердикт по каждому пункту. замечания преподавателя и построить сильную техническую защиту решения.
## Текст задания ## Текст задания
{task_text} {task_text}
## Комментарии преподавателя ## Замечания преподавателя
{comments} {comments}
Для каждого замечания: Для каждого замечания прими решение:
- Если оно технически справедливо → внеси в "fixes" (что именно исправить)
- Если исходное решение было верным и замечание ошибочно или основано на недопонимании A) Если замечание технически обоснованно и решение нужно улучшить
внеси в "defenses" в формате "замечание: ОБЪЯСНЕНИЕ почему решение правильное" внеси в "fixes": конкретно что изменить.
B) Если решение было принято осознанно и является оптимальным в данном контексте →
внеси в "defenses" развёрнутый аргумент строго в формате:
"ЗАМЕЧАНИЕ: <суть замечания> | НЕОБХОДИМОСТЬ: <почему именно такой подход был вынужденным/единственно возможным> | ОПТИМАЛЬНОСТЬ: <почему это решение лучше альтернатив — производительность, читаемость, надёжность, ограничения курса> | АЛЬТЕРНАТИВЫ: <конкретные альтернативы и почему они хуже>"
При аргументации опирайся на:
- Ограничения задания (что именно требовалось, не больше)
- Технические trade-offs (O(n) vs O(log n), latency vs throughput, memory vs speed)
- Требования курса: deepagents обязателен, OpenRouter — единственный доступный LLM-провайдер
- YAGNI: усложнять без требования задания — anti-pattern
- KISS: простое решение надёжнее сложного при эквивалентном результате
Ответ — ТОЛЬКО JSON без markdown: Ответ — ТОЛЬКО JSON без markdown:
{{"fixes": ["список конкретных исправлений"], {{"fixes": ["конкретные исправления"],
"defenses": ["замечание: объяснение"], "defenses": ["ЗАМЕЧАНИЕ: ... | НЕОБХОДИМОСТЬ: ... | ОПТИМАЛЬНОСТЬ: ... | АЛЬТЕРНАТИВЫ: ..."],
"verdict": "needs_fixes" | "already_correct" | "mixed"}} "verdict": "needs_fixes" | "already_correct" | "mixed"}}
''' '''
_REWORK_SECTION = '''\ _REWORK_SECTION = '''\
## ПЕРЕСДАЧА — результат анализа замечаний ## ПЕРЕСДАЧА — технический анализ замечаний
### Исправить (замечания справедливы): ### Исправить (замечания обоснованы):
{fixes} {fixes}
### Оставить и объяснить (решение было верным): ### Отстоять с аргументацией (решение оптимально):
{defenses} {defenses}
Правила: Правила генерации кода:
- Вноси ТОЛЬКО изменения из раздела "Исправить" - Вноси ТОЛЬКО изменения из раздела "Исправить"
- Для каждого пункта из "Оставить" — добавь в код комментарий "# NOTE: <объяснение>" - Для каждого пункта из "Отстоять" — добавь в код РАЗВЁРНУТЫЙ блок комментариев:
- Не трогай логику, которая работала правильно # DESIGN DECISION: <суть спорного решения>
# NECESSITY: <почему именно так — вынужденность, ограничения задания/курса>
# OPTIMALITY: <почему это лучше альтернатив — конкретные аргументы>
# ALTERNATIVES CONSIDERED: <что рассматривалось и почему отклонено>
- Не меняй архитектуру без явного требования в "Исправить"
- Решение должно выглядеть как результат инженерного решения, а не случайного выбора
''' '''