Освой три рефлекса практика - сверка с официальной документацией, собственный тест, охота за признаками галлюцинаций - прежде чем что-то интегрировать.
Открыть этот урок в KodokonГаллюцинация - это не абсурдный ответ, а ответ правдоподобный и неверный: метод, который должен был бы существовать, но не существует; опция, переименованная две версии назад; поведение по умолчанию, вывернутое наизнанку. Именно это делает уязвимыми уверенных разработчиков: галлюцинированный код идиоматичен, хорошо назван, согласован с экосистемой. Он выглядит правильным. Три рефлекса, о которых не торгуются, прежде чем что-то интегрировать: сверить с официальной документацией твоей версии, протестировать код самому в минимальном окружении и отдать ответ на аудит - в том числе самой модели.
Take your previous answer and audit it as if it came from someone else.
1. List every verifiable technical claim: API or function name, described behavior, default value, version number.
2. For each, give your confidence level: certain / likely / to verify.
3. For each "to verify," state exactly what to look up in the official documentation: the name of the page, function, or module concerned.
4. Flag anything that might depend on the version or platform, specifying from which version it holds if you know.
Be harder on yourself than I would be: a claim over-rated as "certain" costs me more than one under-rated.Этот самоаудит ничего не доказывает - модель может быть уверенной и неправой, - но он превращает гладкую прозу в список проверяемых утверждений, у каждого из которых есть точка входа в документацию. Проверяешь ты; ИИ лишь подготовил почву. Научись замечать и тревожные признаки: API, скроенный точно под твою потребность (слишком хорошо, чтобы быть правдой); смесь договорённостей из разных версий в одном фрагменте; идеально ровная уверенность - настоящая экспертиза говорит «это зависит», галлюцинация так не говорит никогда; и отсутствие любого упоминания ограничения или крайнего случая. Ни один признак сам по себе не доказательство, но каждый должен запускать проверку.
You just claimed that [precise claim to verify].
1. Help me design the shortest possible test to verify it myself: the minimal file to create, the exact command to run, the precise result I should observe if you're right - and what I'll observe instead if you're wrong.
2. Then play devil's advocate: in which cases would your claim be false? Version, platform, configuration, strict mode or not - go through it all.
I'll run the test myself: don't ask me to take your word for it, give me the means to contradict you.Этот промпт переносит научный принцип в повседневную работу: утверждение чего-то стоит, если оно опровержимо - если ты знаешь, что увидел бы, окажись оно ложным. Десять строк в черновом файле и один запуск бьют любой заявленный уровень уверенности. Для сверки с документацией - три привычки: проверять в документации своей версии (модели бодро смешивают эпохи одного API), смотреть changelog, когда поведение будто бы изменилось, и всегда держать открытыми REPL или черновой файл: цена проверки должна быть настолько низкой, чтобы у тебя не было оправданий пропустить этот шаг.