Помощнику дают фразу «поправь обработку ключа», получают аккуратный фрагмент и быстро принимают его, потому что он похож на нужный. Симптом проявляется позже: рядом с локальной правкой оказывается новый default, лишний файл или изменённая граница доступа. Цена не в одном лишнем комментарии. Команда тратит время reviewer на поиск того, что задача не назвала, а владелец контракта получает изменение, за которое никто явно не взял ответственность.
Проблема начинается до первого ответа. Prompt без постановки задачи не задаёт ни допустимый контекст, ни границу diff, ни отрицательные условия. Он просит правдоподобный текст, а не проверяемое изменение. Для помощника это естественно: GitHub в документации на январь 2025 рекомендует держать запрос в рамке coding-задачи и использовать инструмент как дополнение к работе инженера. Для команды из этого следует более узкое правило: сначала записать контракт задачи, затем принять только ограниченный diff, который можно сверить с этим контрактом.
Симптом → причина → проверка → действие
- Симптом. В review появился полезный хук, но вместе с ним меняется файл или поведение, о котором задача не говорила.
- Причина. Запрос содержит желаемый результат, но не содержит scope, отрицательных ограничений, owner и вида доказательства.
- Проверка. До генерации заполните prompt-card: задача, разрешённый контекст, запреты, владелец и ожидаемые evidence.
- Действие. Рассматривайте ответ только как candidate diff. Сначала сверяйте его границу, затем контракт и тест, а не красоту объяснения.
Prompt-card: короткий контракт до черновика
Prompt-card не является шаблоном, который делает помощник точнее по волшебству. Это карточка для инженера и reviewer. Она отделяет то, что разрешено изменить, от того, что кажется связанным. В ней важно назвать owner — человека или роль, которые отвечают за смысл результата. Если owner не назван, assistant не может стать владельцем вместо команды; значит, спорный diff надо остановить до merge, а не маскировать более подробной формулировкой.
| Поле | Что записать | Как это проверяется | Чего поле не обещает |
|---|---|---|---|
| Задача | Один observable result: нормализовать fixed synthetic key в parser. | Есть одна входная и одна ожидаемая выходная строка. | Не доказывает совместимость всех потребителей. |
| Допустимый контекст | Функция, её fixed input-output table и один тест. | Каждый path diff попадает в названную область. | Не даёт доступа к реальному codebase или customer code. |
| Отрицательные ограничения | Не менять authorization, public labels, dependencies и defaults. | В diff нет запрещённого пути или поведения. | Не заменяет security review. |
| Owner | synthetic-parser-owner в учебном примере. | Есть тот, кто принимает scope expansion. | Не переносит решение на модель. |
| Evidence | bounded diff, contract cases, review и focused test. | Каждый evidence отвечает на свой вопрос. | Не является общей гарантией correctness или security. |
Допустимый контекст — это не «всё, что есть рядом»
Контекст полезен, когда он отвечает на конкретный вопрос. Для parser это сигнатура функции, таблица ожидаемых входов и выходов, запрещённые ветки и тест, который наблюдает результат. Контекст вреден, когда в него без необходимости попадают customer code, секреты, история repository или реальные обращения пользователей. Тогда увеличивается и риск раскрытия данных, и стоимость review: reader уже не может понять, какие строки действительно были нужны для решения.
В учебной карточке ниже имена и значения зафиксированы прямо в коде. Это не prompt к реальному инструменту и не конфигурация проекта. Его можно повторить только как проверку формы решения: один parser, одна граница поведения, один запрещённый переход в authorization. Такой пример намеренно не получает файлов, сети, Git, CI, модели, метрик или результатов evaluation.
const promptCard = {
task: 'normalize a fixed synthetic invoice key in one parser',
allowedContext: ['parseInvoiceKey signature', 'fixed input-output rows'],
negativeConstraints: ['no authorization edits', 'no public label change'],
owner: 'synthetic-parser-owner',
expectedEvidence: ['bounded diff', 'focused contract cases', 'human review'],
};
// Candidate output may change only:
// src/synthetic/parseInvoiceKey.js
// Any access-policy change stops the review instead of expanding the task.Ключевое слово здесь — ограниченный diff, или bounded diff. Он не означает «маленький любой ценой»: иногда правильная правка требует двух файлов. Ограничение означает другое: у каждого изменённого path есть связь с задачей, контрактом и owner. Если в ходе работы выясняется, что нужна новая область, это отдельное решение. В таком случае карточку обновляют, называют новый риск и снова получают review; нельзя задним числом объявить широкий diff частью исходной мелкой задачи.
Порядок review: сначала scope, потом смысл, затем доказательство
Сначала reviewer читает список изменённых файлов и запреты карточки. Это дешёвая проверка: лишний файл виден до погружения в детали. Затем сравнивают изменённую ветку с input-output контрактом. Только после этого имеет смысл обсуждать naming, style и структуру. Такой порядок уменьшает ложную уверенность от чистого кода: код может быть понятным и при этом возвращать другой result для invalid input.
Документация GitHub о pull request review описывает работу с commits, files и diff по файлам, а также явные исходы comment, approve и request changes. В этом цикле удобно использовать тот же смысл, но не выдавать интерфейс за гарантию: review — место, где фиксируют вопрос и решение, а не автоматический сертификат качества. Approve допустим после того, как owner или reviewer смогли связать каждый риск с evidence.
| Порядок | Вопрос | Минимальный evidence | Стоп-условие |
|---|---|---|---|
| 1. Scope | Все ли paths и действия названы в карточке? | Список files и negative constraints. | В diff есть лишний файл или новая ответственность. |
| 2. Contract | Сохраняются ли допустимые и запрещённые результаты? | Fixed input-output table. | Изменился public label, default или invalid result. |
| 3. Review | Кто принимает расширение или residual risk? | Комментарий owner и human reviewer. | Никто не владеет спорным решением. |
| 4. Test | Проверяет ли тест именно changed branch? | Focused expected и negative case. | Есть только соседний happy path. |
Тест закрывает ровно свой вопрос
Тест полезен не потому, что его зелёный статус можно приложить к задаче. Он полезен, когда в нём названы input, expected result и forbidden side effect. Для parser это может быть unknown key, который остаётся invalid. Для command — duplicate key, при котором write helper не вызван. Линтер, unit test и reviewer evidence нужно держать раздельно: линтер проверяет часть формы, тест — выбранный сценарий, reviewer — связь diff с контрактом. Ни один из них отдельно не обещает correctness или security.
NIST SSDF полезен здесь не как список галочек для помощника, а как напоминание встроить практики безопасной разработки в свой жизненный цикл. Если задача затрагивает authentication, данные или внешний контракт, карточка должна стать уже, а evidence — сильнее. Это может означать отказ от генерации в данном scope. Стоимость такой остановки меньше стоимости неясного изменения, которое потом нужно расследовать в более дорогом контексте.
Ограничения и следующий проверяемый шаг
Эта статья не предлагает настоящие prompts, не оценивает модели и не показывает customer code, repository, secrets, метрики или реальные результаты evaluation. Fixed synthetic card демонстрирует только форму проверяемого запроса. Он не заменяет policy данных, threat model, domain owner, полноценный test plan или security review. GitHub предупреждает, что assistant может не увидеть более крупную архитектурную проблему; короткий prompt-card не отменяет это ограничение.
Следующий шаг: возьмите одну небольшую инженерную задачу и до черновика заполните пять строк из таблицы. Затем покажите reviewer только bounded diff и спросите в строгом порядке: scope, contract, owner, test. Ожидаемый результат — не «идеальный prompt», а явное решение: принять маленькую проверяемую правку, запросить новую карточку или остановить merge до появления недостающего evidence.
Историческая граница января 2025
Для ограничений помощника использован immutable snapshot GitHub Docs от 31 января 2025: он говорит о context limit, возможном расхождении кода с intent и необходимости review и тестов. Для механики pull request использован snapshot той же даты, а для secure-development vocabulary — NIST SP 800-218 Version 1.1 от 3 февраля 2022. Текст не приписывает январю 2025 модели, режимы или практики позднее этой даты. Все prompts, diffs, owners и outcomes здесь — fixed synthetic in-memory literals.
Проверяемые источники
- GitHub Docs snapshot: Copilot Chat limitations (immutable GitHub Docs commit 6a92295d, 31 January 2025) — Документация ограничивает область помощника контекстом и прямо предупреждает: код может выглядеть валидным, но не соответствовать намерению разработчика; для чувствительного к безопасности кода нужны review и тестирование. Граница: Это описание ограничений конкретного продукта и интерфейса. Оно не измеряет качество любого помощника, не доказывает корректность конкретного diff и не задаёт процесс merge.
- GitHub Docs snapshot: improving Copilot Chat performance (immutable GitHub Docs commit 6a92295d, 31 January 2025) — Документация рекомендует держать запрос в рамке задачи, использовать помощник как инструмент, а не замену инженера, и проверять сгенерированный код через secure coding и code review. Граница: Рекомендация не означает, что хороший prompt, линтер или один тест дают гарантию correctness, security или совместимости с конкретным репозиторием.
- GitHub Docs snapshot: reviewing proposed pull-request changes (immutable GitHub Docs commit 6a92295d, 31 January 2025) — Pull request review рассматривает commits, files и diff, позволяет оставить комментарии, approve или request changes; diff удобно просматривать по файлам. Граница: Документация описывает механизм review в GitHub. Она не утверждает, что просмотренный diff или approval сам по себе доказывает отсутствие дефектов.
- NIST SP 800-218: Secure Software Development Framework Version 1.1 (final publication, 3 February 2022) — SSDF задаёт набор практик безопасной разработки, которые можно встраивать в конкретный SDLC, чтобы снижать число уязвимостей и влияние невыявленных проблем. Граница: SSDF — высокоуровневая рамка. Он не заменяет знания предметного контракта, тестовые данные, human review или решение владельца об acceptable risk.