Коды для проекта: нейросеть Claude и проверка правки
Разбираю, как поставить Claude небольшую задачу по коду, получить понятную правку и проверить её на конкретных входных данных перед переносом в проект.
М
Марина
Контент-маркетолог LibraChat
6 мин чтения
В выгрузке рассылки одна кампания называлась «SEO», другая — «seo», третья — « SEO ». Для отчёта это три строки, хотя команда имела в виду одну метку. Я хотела быстро попросить Claude написать код, который всё исправит. Первая формулировка у меня получилась опасно широкой: «Почини обработку тегов и наведи порядок в отчёте». По ней можно переписать половину проекта и всё равно не решить мою задачу.
Если искать «коды для нейросеть Claude», легко принять готовый фрагмент за готовое решение. Но код полезен только рядом с конкретным входом, ожидаемым выходом и способом проверки. Для своего случая я бы сначала описала маленькую функцию обработки меток. Отчёт, загрузку файлов и интерфейс пока оставила бы за рамками задачи. Так можно увидеть, где именно изменилось поведение.
Что было не так с просьбой «напиши код»
Сначала я сформулировала просьбу без условий. В ней не было сказано, что делать с пустыми строками, регистром букв и порядком меток. Ответ мог бы выглядеть убедительно и при этом заменить «SEO» на «seo», отсортировать значения по алфавиту или удалить повтор, который в другой задаче нужен. Ошибка не в инструменте. Я не задала правила.
Перед запросом я собрала четыре строки. Их достаточно, чтобы увидеть спорные места, но недостаточно, чтобы выдавать пример за универсальную очистку данных.
Вопрос · Моё правило для примера · Что проверить после правки
Пробелы по краям — Убрать — « SEO » становится «SEO»
Повтор с другим регистром — Оставить первое написание — «SEO», затем «seo» дают одну метку «SEO»
Пустая строка — Пропустить — Пробелы не превращаются в отдельную метку
Порядок — Сохранить первое появление — Результат не сортируется сам собой
Это почти техническое задание. Его можно понять и без знакомства с Python. Если правило спорное, его лучше согласовать до того, как модель изменит файл. Например, команда может считать «Seo» и «SEO» разными обозначениями. Тогда мой вариант уже не подходит.
Коды для проекта: что нейросеть Claude должна уточнить
В обычном чате Claude можно вставить обезличенный фрагмент и попросить предложить функцию с тестовыми случаями. Если работа идёт в Claude Code, официальная документация Anthropic описывает другой сценарий: инструмент может читать файлы проекта, редактировать их и запускать команды. Поэтому в запросе для проекта я отдельно ограничила бы область правки и попросила показать, что было проверено. Доступ к файлам и командам зависит от выбранного режима разрешений.
Вот постановка, которую я подготовила бы для функции, а не для всего отчёта:
В проекте на Python есть обработка списка меток кампаний. Нужна функция `normalize_tags(tags: list[str]) -> list[str]`. Убирай пробелы по краям, пропускай пустые значения, считай метки одинаковыми без учёта регистра, сохраняй написание и порядок первого появления. Сначала найди место, где формируется список, и кратко объясни предлагаемую правку. Меняй только относящиеся к функции файлы. Добавь проверки для пустого списка и повторов; отдельно проверь строки из одних пробелов. Покажи diff и команды проверки с их результатами. Если данных о текущем контракте функции не хватает, задай вопрос до изменения кода.
Последняя фраза важнее красивого синтаксиса. В настоящем проекте функция может принимать не строки, а словари; где-то пустая метка означает «без категории». Если модель не видит такого контекста, уверенный ответ будет всего лишь гипотезой. Я также не стала бы передавать в чат файл с клиентскими адресами или токенами ради одного примера. Пары искусственных меток достаточно, чтобы сформулировать правило.
Мой короткий порядок перед отправкой запроса:
Назвать один участок поведения, который нужно изменить.
Привести вход и ожидаемый выход, включая неудобный случай.
Указать границу файлов и действий: что разрешено менять и запускать.
Попросить отдельно показать правку и проверки, затем нерешённые вопросы.
Если задача звучит как «сделай всё приложение лучше», я возвращаюсь к первому пункту. Нужна одна наблюдаемая перемена. Остальное можно поручать следующими шагами.
Код из ответа — начало проверки, а не конец работы
Для такой постановки один из возможных вариантов на Python выглядит так. Это авторский пример для иллюстрации правила, а не ответ, фактически полученный от Claude:
```python
def normalize_tags(tags: list[str]) -> list[str]:
result = []
seen = set()
for raw in tags:
tag = raw.strip()
key = tag.casefold()
if tag and key not in seen:
seen.add(key)
result.append(tag)
return result
```
Проверка начинается с оговорённых случаев. Для входа `[' SEO ', 'seo', '', ' email ']` ожидаю `['SEO', 'email']`. Для пустого списка — пустой список. Для `['План', 'план']` останется «План». Код сохраняет порядок, потому что добавляет метку в результат при первом появлении. Он также предполагает, что каждый элемент — строка. Если в реальной выгрузке встречается `None`, понадобится отдельное решение, а не молчаливое допущение.
Я проверила этот маленький фрагмент локально на трёх оговорённых входах. В первом метка «SEO» встречается 2 раза, а в результате остаётся одно написание. Для проекта я бы попросила модель добавить те же случаи в тесты. Затем посмотрела бы не только на зелёный результат, но и на сам diff: не изменила ли она чтение CSV, имена колонок или соседнюю логику. Зелёный тест на новых случаях не доказывает, что старые сценарии сохранились. Для общей функции нужны и прежние проверки проекта. При просмотре ответа полезно разделять три разных факта:
код выглядит осмысленно при чтении;
конкретные входы дают ожидаемые значения;
изменение совместимо с остальным проектом.
Первый факт можно оценить глазами. Второй подтверждается запуском тестов. Третий зависит от контекста проекта и повторной проверки человеком. Модель может предложить тест, который повторяет её собственную ошибку; совпадение кода и такого теста ещё не делает правило верным.
Что я сделала бы после первого ответа
Если предложенная правка затронула слишком много файлов, я вернула бы задачу к исходной границе: «Оставь только функцию и её тесты, объясни остальные изменения отдельно». Если тест падает, передала бы текст ошибки без секретов и попросила разобрать причину. Если модель утверждает, что всё прошло, а результата запуска нет, я запускала бы команду сама или проверяла журнал в среде, где работаю. Так слово «проверено» получает наблюдаемое содержание.
Для моей истории с метками итогом стала бы не пачка «кодов для Claude», а маленький контракт: что функция принимает, что возвращает и какие случаи покрыты. Такой контракт можно показать разработчику и обсудить без спора о вкусе модели. Следующая задача — например, как обрабатывать пропущенные значения в исходном CSV — будет отдельной. Я бы не подмешивала её в уже понятную правку.
Если тебе нужен чат для формулировки такой задачи, попробуй прямо сейчас открыть LibraChat и начни с выдуманного входа и ожидаемого выхода. Перед работой можно посмотреть тарифы. А в материале о работе с кодом есть другие способы разбирать программные задачи. Начни с одного поведения, которое сможешь проверить собственными глазами.
Claudeкодпрограммированиепроверка кодарабочие задачи
