Точно понимай, что ты отправляешь, чего юридически стоит сгенерированный код и как предвзятость моделей направляет твои технические решения.
Открыть этот урок в KodokonКаждый промпт - это передача данных третьей стороне. Прежде чем использовать ассистента в рабочем контексте, на три вопроса должен быть задокументированный ответ. Хранение: сколько времени поставщик хранит твои разговоры и кто имеет к ним доступ (поддержка, безопасность, судебный запрос)? Обучение: используются ли твои данные для обучения будущих моделей и включён ли отказ от этого в твоём аккаунте - потребительские и корпоративные тарифы почти всегда различаются в этом пункте? Договор: разрешают ли работодатель или клиенты передавать этот код, с учётом того, что подписанные тобой условия о конфиденциальности распространяются и на промпт? Фрагмент кода может выглядеть безобидным; но вместе с внутренними доменными именами, структурами таблиц и сообщениями об ошибках с полными путями он описывает твою информационную систему.
Хорошая практика - минимизация: отправлять только то, что строго необходимо для рассуждения. Это отдельный навык - собрать минимальный воспроизводимый пример с обезличенными именами, - и у него есть неожиданная педагогическая польза: чтобы изолировать проблему и описать её отвлечённо, ты вынужден её понять. Следующий промпт превращает это требование конфиденциальности в диагностическое упражнение.
Context: I'm working on proprietary code that I cannot share. I'll describe my problem abstractly, with generic names and without pasting the real code.
Description: [PSEUDO-CODE of the relevant structure, ERROR MESSAGE with paths and identifiers masked, VERSIONS of the libraries involved].
Your mission:
1. If my description is too vague to reason on, tell me exactly what information you're missing and why - I'll decide whether I can provide it in anonymized form.
2. Reason only on my description: never ask me to paste the full file.
3. Propose hypotheses for the cause, ranked by probability, and for each one a precise test I can run locally to confirm or rule it out.
Format: a table of hypothesis / probability / verification test. I'll come back with the test results.Вторая тема: лицензирование сгенерированного кода. Право здесь ещё не устоялось и различается по юрисдикциям, но три факта установлены. Первый: модели обучаются на коде под самыми разными лицензиями, включая копилефт вроде GPL, и могут воспроизводить фрагменты, очень близкие к исходнику, особенно для известных алгоритмов или многократно продублированных кусков. Второй: в ряде юрисдикций чисто механический результат без творческого вклада человека трудно защитить авторским правом, что подрывает твои притязания на код, принятый как есть. Третий: некоторые поставщики предлагают договорную компенсацию на случай иска о нарушении прав, а также фильтры, блокирующие выдачу, слишком близкую к корпусу, - проверь, что эти гарантии есть в твоём тарифе, а не только в рекламном буклете. На практике: чем длиннее, специфичнее и менее отредактирован сгенерированный фрагмент, тем выше юридический риск.
Третья тема: предвзятость. Модель воспроизводит статистические закономерности своего корпуса, и три вида предвзятости прямо влияют на твои технические решения. Предвзятость популярности: решения, перепредставленные в данных (доминирующие фреймворки, паттерны, модные два года назад), рекомендуются по умолчанию, даже когда твой контекст требует другого, - корпус всегда на шаг отстаёт от переднего края. Предвзятость угодливости: модели оптимизированы нравиться пользователю и склонны подтверждать твою посылку; спроси «почему мой подход с микросервисами правильный?» - и получишь подтверждения, а не возражения. Перевёрнутая предвзятость авторитета: гладкость тона создаёт впечатление уверенности, никак не связанное с надёжностью. Противоядие процедурное: принудительно вызвать возражение.
You just recommended [SOLUTION OR TECHNOLOGY] to me. Before I decide, switch stance: you are now an experienced engineer tasked with arguing AGAINST this recommendation.
1. Give the 3 best arguments against your own answer, each illustrated by a concrete scenario where it fails.
2. Cite at least one serious alternative you hadn't mentioned, and explain honestly why it was absent from your first answer.
3. Assess how much your initial recommendation owes to the popularity of this solution in your training data, rather than to my specific context, which I'll remind you of: [YOUR CONTEXT: team size, constraints, existing setup].
Format: two columns For / Against, then your revised recommendation in one sentence, with your confidence level and what could change it.