Итоги и практика
Ключевые выводы
- Давайте контекст до задачи: укажите стек, соглашения и существующие части для переиспользования — или вставьте реальную сигнатуру, под которую код должен встать.
- Определяйте границы: входы, выходы и граничные случаи. Самое интересное поведение софта живёт на его краях, так что туда и тратьте слова.
- Работайте маленькими проверяемыми шагами и просите план до кода; исправить план куда дешевле, чем .
- Итерируйте точечными диффами, а не полными переписываниями, и пришпиливайте конкретными примерами (в идеале — тестами) всё, что слова оставляют размытым.
- Управляйте окном контекста как ресурсом и говорите, чего делать не нужно, — явные негативные ограничения держат вывод собранным.
Попробуйте
Возьмите расплывчатый однострочный запрос, который вы обычно набираете («добавь поиск в список»), и, прежде чем что-либо отправлять, перепишите его как промпт инженера. Добавьте контекст (стек, файл, который затрагивается), входы/выходы, два-три граничных случая, один пример желаемого результата и одно негативное ограничение (что не трогать). Отправьте переписанную версию и сравните с тем, что выдала бы ленивая. Сделайте так для трёх реальных запросов — и это улучшение станет автоматическим.
Промпт главы
Context: <язык + фреймворк + версия>, работаю в <файл/модуль>.
We already <релевантный существующий паттерн или библиотека для переиспользования>.
Task: <одна ясная вещь для постройки>.
Inputs / outputs: <типы и формы>.
Edge cases to handle: <перечисли те, что важны>.
Example: <один конкретный вход -> ожидаемый выход>.
Constraints:
- No new dependencies — use <то, что у нас уже есть>.
- Touch only <этот файл>; don't refactor anything else.
- Keep existing names and signatures unchanged.
Before coding, give me a 3-4 line plan and wait for my "go".