Репост из: .NET Разработчик
День 2796. #ЗаметкиНаПолях #AI
Рабочий процесс с Copilot для .NET. Продолжение
Начало
Три «S» в составлении промптов
Лучшие промпты обладают тремя характеристиками:
- Simple (простые) - одна задача за раз;
- Specific (конкретные) - явно указаны фреймворк, версия, паттерн и ограничения;
- Short (краткие) - достаточно лаконичные, чтобы полезная информация не терялась в «шуме».
Антипаттерн — «мега-промпты», пытающиеся решить всё за один раз. Например: «Создай сервис управления заказами с интеграцией Service Bus, EF Core, механизмом повторных попыток Polly, структурированным логированием и полным набором тестов».
Такой промпт выдаст результат, который технически охватывает все эти области, но в большинстве из них будет содержать ошибки.
Разбейте задачу на части: «Создай интерфейс IOrderService с методами для создания, получения и отмены заказов. Используй асинхронность повсеместно. Возвращай Result — не выбрасывай исключения при передаче данных между компонентами». Это даст результат, который действительно можно использовать.
Ошибка, которая сводит всё на нет, — расплывчатый контекст. Если Copilot не знает, что вы используете .NET 10, он может предложить паттерны для .NET 6. Если он не в курсе, что у вас Polly v8, то предложит синтаксис версии 7. Конкретика в промпте ничего не стоит, а вот исправление неверных версий SDK — да.
Контекстные переменные
Здесь кроется реальный разрыв в продуктивности между разработчиками, которые уделили время правильному изучению Copilot, и всеми остальными.
- #file: позволяет указать Copilot конкретные файлы, вместо того чтобы надеяться, что он сам догадается о контексте на основе открытого в редакторе файла. Добавление в промпт ссылки на copilot-instructions.md (о нём позже) сильно меняет дело. Copilot генерирует код, соответствующий вашим текущим паттернам, а не придумывает новые.
- #terminal используется редко, хотя очень полезна. Если сборка завершается ошибкой, передайте вывод терминала прямо в запрос, вместо того чтобы пересказывать суть ошибки своими словами. Copilot видит реальный вывод компилятора и предлагает точечные исправления, а не общие рекомендации.
- @workspace открывает Copilot доступ ко всей структуре проекта, а не только к открытому файлу: «Учитывая контекст @workspace, где ещё в этой кодовой базе используется похожий паттерн, который стоит проверить на согласованность?»
- /explain — для объяснения любого легаси кода, к работе с которым собираетесь приступить;
- /tests — для создания каркаса (заглушек) тестов NUnit для готового метода;
- /fix — когда тест падает и нужна отправная точка для анализа проблемы.
copilot-instructions.md — то, что принесёт наибольшую пользу
Если вы решите внедрить что-то одно, пусть это будет данный файл. Добавьте .github/copilot-instructions.md в каждый репозиторий.
У каждого разработчика в команде свои привычки и подходы. Если оставить выбор промптов на их усмотрение, один попросит сгенерировать асинхронный код с токенами отмены, а другой об этом даже не подумает. Один знает, что вы используете FluentValidation, а другой попросит Copilot написать валидацию вручную. Один запросит обработку ошибок через Result, а другой позволит Copilot генерировать исключения, пересекающие границы сервисов.
Файл copilot-instructions.md приводит подходы всех разработчиков к единому стандарту на самом раннем этапе. Он определяет ваш стек технологий, стандарты и ограничения, благодаря чему Copilot по умолчанию генерирует код, идиоматичный именно для вашей кодовой базы, а не для абстрактного проекта на .NET из обучающей выборки GitHub. Минимальная версия конфигурации для команды, работающей с Azure и .NET:
## Stack
- ASP.NET Core 8, C# 12, .NET 8
- Azure PaaS: App Service, Azure Functions, Service Bus, Blob Storage
- EF Core 8 with Azure SQL
- xUnit for testing, Moq for mocking
- Polly v8 for resilience, Serilog for structured logging
## Async Rules
- All I/O is async. No .Result, .Wait(), or Task.Run wrappers.
- CancellationToken is the last parameter on every public async method.
- Propagate tokens down the chain. Never discard them.
## Error Handling
- Never throw exceptions across service boundaries.
- Return Result for operation outcomes.
- Use Polly retry + circuit breaker for all transient failures.
## Security
- No hardcoded secrets. Azure Key Vault only.
- Managed Identity for all Azure service auth. No connection string keys.
- Validate all external inputs at the API boundary. OWASP Top 10.
Будьте кратки. Copilot лучше справляется с лаконичными и конкретными инструкциями, чем с огромными массивами документации. Вот пример полноценного рабочего файла.
Окончание следует…
Источник: https://levelup.gitconnected.com/a-production-ready-copilot-workflow-for-net-0ad2e7183018
Рабочий процесс с Copilot для .NET. Продолжение
Начало
Три «S» в составлении промптов
Лучшие промпты обладают тремя характеристиками:
- Simple (простые) - одна задача за раз;
- Specific (конкретные) - явно указаны фреймворк, версия, паттерн и ограничения;
- Short (краткие) - достаточно лаконичные, чтобы полезная информация не терялась в «шуме».
Антипаттерн — «мега-промпты», пытающиеся решить всё за один раз. Например: «Создай сервис управления заказами с интеграцией Service Bus, EF Core, механизмом повторных попыток Polly, структурированным логированием и полным набором тестов».
Такой промпт выдаст результат, который технически охватывает все эти области, но в большинстве из них будет содержать ошибки.
Разбейте задачу на части: «Создай интерфейс IOrderService с методами для создания, получения и отмены заказов. Используй асинхронность повсеместно. Возвращай Result — не выбрасывай исключения при передаче данных между компонентами». Это даст результат, который действительно можно использовать.
Ошибка, которая сводит всё на нет, — расплывчатый контекст. Если Copilot не знает, что вы используете .NET 10, он может предложить паттерны для .NET 6. Если он не в курсе, что у вас Polly v8, то предложит синтаксис версии 7. Конкретика в промпте ничего не стоит, а вот исправление неверных версий SDK — да.
Контекстные переменные
Здесь кроется реальный разрыв в продуктивности между разработчиками, которые уделили время правильному изучению Copilot, и всеми остальными.
- #file: позволяет указать Copilot конкретные файлы, вместо того чтобы надеяться, что он сам догадается о контексте на основе открытого в редакторе файла. Добавление в промпт ссылки на copilot-instructions.md (о нём позже) сильно меняет дело. Copilot генерирует код, соответствующий вашим текущим паттернам, а не придумывает новые.
- #terminal используется редко, хотя очень полезна. Если сборка завершается ошибкой, передайте вывод терминала прямо в запрос, вместо того чтобы пересказывать суть ошибки своими словами. Copilot видит реальный вывод компилятора и предлагает точечные исправления, а не общие рекомендации.
- @workspace открывает Copilot доступ ко всей структуре проекта, а не только к открытому файлу: «Учитывая контекст @workspace, где ещё в этой кодовой базе используется похожий паттерн, который стоит проверить на согласованность?»
- /explain — для объяснения любого легаси кода, к работе с которым собираетесь приступить;
- /tests — для создания каркаса (заглушек) тестов NUnit для готового метода;
- /fix — когда тест падает и нужна отправная точка для анализа проблемы.
copilot-instructions.md — то, что принесёт наибольшую пользу
Если вы решите внедрить что-то одно, пусть это будет данный файл. Добавьте .github/copilot-instructions.md в каждый репозиторий.
У каждого разработчика в команде свои привычки и подходы. Если оставить выбор промптов на их усмотрение, один попросит сгенерировать асинхронный код с токенами отмены, а другой об этом даже не подумает. Один знает, что вы используете FluentValidation, а другой попросит Copilot написать валидацию вручную. Один запросит обработку ошибок через Result, а другой позволит Copilot генерировать исключения, пересекающие границы сервисов.
Файл copilot-instructions.md приводит подходы всех разработчиков к единому стандарту на самом раннем этапе. Он определяет ваш стек технологий, стандарты и ограничения, благодаря чему Copilot по умолчанию генерирует код, идиоматичный именно для вашей кодовой базы, а не для абстрактного проекта на .NET из обучающей выборки GitHub. Минимальная версия конфигурации для команды, работающей с Azure и .NET:
## Stack
- ASP.NET Core 8, C# 12, .NET 8
- Azure PaaS: App Service, Azure Functions, Service Bus, Blob Storage
- EF Core 8 with Azure SQL
- xUnit for testing, Moq for mocking
- Polly v8 for resilience, Serilog for structured logging
## Async Rules
- All I/O is async. No .Result, .Wait(), or Task.Run wrappers.
- CancellationToken is the last parameter on every public async method.
- Propagate tokens down the chain. Never discard them.
## Error Handling
- Never throw exceptions across service boundaries.
- Return Result for operation outcomes.
- Use Polly retry + circuit breaker for all transient failures.
## Security
- No hardcoded secrets. Azure Key Vault only.
- Managed Identity for all Azure service auth. No connection string keys.
- Validate all external inputs at the API boundary. OWASP Top 10.
Будьте кратки. Copilot лучше справляется с лаконичными и конкретными инструкциями, чем с огромными массивами документации. Вот пример полноценного рабочего файла.
Окончание следует…
Источник: https://levelup.gitconnected.com/a-production-ready-copilot-workflow-for-net-0ad2e7183018