Kodokon kodokon.com

Разбор упражнений без выдачи ответа

Настрой ИИ так, чтобы он оценивал твою работу подсказками и по шкале критериев, ни разу не переписав твой код.

8 мин · 3 вопросов

Открыть этот урок в Kodokon

Ты доделал упражнение и хочешь понять, насколько оно хорошо. Естественный рефлекс - вставить свой код со словами «исправь мне это» - стратегическая ошибка: ИИ перепишет твоё решение лучше, ты прочитаешь, покиваешь… и ничему не научишься. Полезный разбор говорит, где ты ошибся, и оставляет тебе починить самому. Именно этого и надо требовать.

PROMPT
You are a programming exercise grader. Here's the exercise statement, then my solution.

Statement: [paste the exercise statement here]

My solution: [paste your code here]

Grading rules, absolute:
1. NEVER rewrite my code, neither in full nor in fragments. No corrected version, even if I ask for it.
2. First tell me whether my solution is correct, partially correct, or incorrect.
3. For each problem: point to the line concerned and ask me a question that steers me, without giving the fix.
4. Rank the problems by severity: real bug, then forgotten edge case, then style.
5. When I submit a version I've corrected myself, re-evaluate it under the same rules.

If there's no problem at all, say so clearly and offer me an additional constraint to make the exercise harder.
Проверяющий на подсказках: он находит место, задаёт вопрос и никогда не переписывает.

Иерархия из правила 4 - привычка, привезённая прямо из профессионального мира: на код-ревью всегда различают то, что ломает (баг), то, что сломает (крайний случай: пустой массив, отрицательное значение, текст вместо числа), и то, что мешает (стиль, именование). Умение сортировать замечания по серьёзности готовит тебя к настоящим код-ревью в команде.

Чтобы пойти дальше простого «верно или неверно», попроси шкалу оценки. Балл, разложенный по критериям, превращает смутное впечатление в точный диагноз: ты сразу видишь, где твоё слабое место - функциональная корректность, обработка крайних случаев или читаемость, - а значит, и над чем работать в первую очередь.

PROMPT
Evaluate my solution with the following grading scale, out of 20 points:

- Functional correctness (8 pts): does the code produce the expected result in the general case?
- Edge cases (4 pts): empty input, extreme values, unexpected types.
- Readability (4 pts): clear variable names, logical structure, no needless complexity.
- Language best practices (4 pts): appropriate idioms, no redundant code.

For each criterion: the score, a justification of two sentences maximum, and - if points are missing - a hint to improve WITHOUT giving me the fix.

End with the priority area to work on for my next attempt.
Шкала оценки: балл, который превращается в план занятий.

Полный рабочий цикл, который стоит запомнить как профессиональную рутину: ты решаешь сам, отправляешь с промптом проверяющего, получаешь локализованные подсказки, чинишь сам, отправляешь снова - и только когда твоя версия держится, можно спросить: «Теперь, когда моё решение верно, покажи, как написал бы опытный разработчик, и объясни каждое отличие». На этом этапе сравнение уже не подменяет твоё обучение: оно его венчает.

Проверка знаний

Убедись, что запомнил ключевые моменты этого урока.

  1. Почему «исправь мне это» - плохой промпт для обучения?
    • Потому что ИИ отказывается от таких запросов
    • Потому что ИИ переписывает решение за тебя и лишает тебя починки, а именно в этот момент ты учишься
    • Потому что разбор будет слишком длинным для чтения
  2. В каком порядке хороший проверяющий сортирует проблемы?
    • В порядке появления в файле
    • Сначала стиль, потом баги
    • Настоящий баг, затем забытый крайний случай, затем стиль
    • Случайно, все проблемы равны
  3. Когда законно попросить у ИИ решение опытного разработчика?
    • Как только застрял больше чем на пять минут
    • Никогда, это всегда запрещено
    • Когда твоё собственное решение уже верно - чтобы сравнить и понять отличия
    • Перед началом, чтобы понимать, куда идти