Узнайте шаблон «не менять», чтобы внести одно небольшое обновление, зафиксировав ключевые UI-потоки, бизнес-правила и критическое поведение так, чтобы ничего лишнего не сдвинулось.
«Небольшое» изменение редко остаётся маленьким. Вы просите подправить подпись кнопки, и вдруг сдвигается вёрстка страницы, форма перестаёт валидироваться или шаг оплаты ведёт себя иначе. Приложения — это связанные системы. UI, логика, данные и интеграции опираются друг на друга.
Частая причина — неясные границы. Если в запросе пишут «сделать регистрацию проще», исполнителю (человеку или ИИ) придётся догадываться, что значит «проще». Догадки ведут к дополнительным правкам: удалению полей, изменению шагов, корректировке копии или переписыванию валидации. Ещё одна причина — скрытые зависимости. Небольшое изменение UI может затронуть компонент, который используется на пяти других экранах.
Безопасная итерация значит: вы получаете одно ожидаемое улучшение, а всё остальное остаётся практически идентичным. Для нетехнической команды это означает, что рабочий процесс по-прежнему воспринимается пользователями одинаково, скрипты поддержки всё ещё соответствуют продукту, а отчётность не нарушена. Для технической команды это значит отсутствие неожиданных изменений маршрутов, формата данных, контрактов API или поведения в пограничных случаях.
Чтобы это стало возможным, нужно заморозить то, что нельзя менять. На практике это обычно включает критические потоки (точные шаги пользователей), детали UI/UX (вёрстка, отступы, поведение взаимодействия), бизнес-правила (ценообразование, права, валидация), поведение данных (что и когда сохраняется) и интеграции (события аналитики, письма, платежи, внешние API).
Этот шаблон «не менять» снижает риск, убирая догадки и сужая масштаб изменения. Это не гарантия — дрейф всё ещё возможен, если исходное поведение плохо описано, изменение трогает общие компоненты или вы не проверяете результат. Цель — меньше сюрпризов и быстрее утверждения.
Шаблон «не менять» — простой способ попросить одно конкретное обновление, при этом явно зафиксировав всё остальное. Вы называете одно изменение, которое нужно внести, затем пишете короткий список заморозки частей, которые должны остаться идентичными после правки.
Это важно, потому что модели часто «стараются помочь», рефакторя, переименовывая, перестраивая файлы или «очищая» логику при внесении правок. Даже если результат по-прежнему работает, такие дополнительные изменения могут ввести баги, поменять поведение или усложнить ревью.
Сравните два запроса:
«Сделайте страницу настроек лучше.» Это приглашает дизайнерские изменения, новую копию, сдвиги в вёрстке и правки логики.
«Измените только текст метки с 'Phone' на 'Mobile phone'. Не меняйте вёрстку, валидацию или поведение сохранения.» Это узко, проверяемо и безопаснее.
Хороший список заморозки обычно охватывает три области:
Когда вы используете этот шаблон в инструменте на основе чата вроде Koder.ai, итерации идут быстрее, потому что модель фокусируется на одном изменении, а не делает массовые «улучшения» без запроса.
Этот шаблон работает лучше всего, когда ваш запрос читается как маленький контракт: одна ясная цель, список того, что заморожено, и пара проверок для подтверждения результата.
Скопируйте этот шаблон и заполните скобки. Держите его коротким, но конкретным.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Конкретный пример: если вы хотите поменять цвет кнопки оформления заказа, ваша цель — «Обновить основной цвет кнопки оформления на #1A73E8.» В DO NOT CHANGE вы должны заморозить полный поток оформления, текст кнопки и расчёт цены.
Если вы используете Koder.ai, такой формат ускоряет ревью: вы можете сравнить acceptance checks с превью и сводкой изменений перед подтверждением.
Когда вы просите небольшое изменение, не говорите просто «ничего не ломайте». Назовите точные пользовательские сценарии, которые должны работать одинаково, от первого клика до финального результата. Вы не замораживаете всё приложение, вы замораживаете те части, где регрессии вредят.
Начните с перечисления критических потоков простым языком: вход (включая сброс пароля), онбординг, checkout, настройки. Для каждого потока укажите, как выглядит «готово». Пример: «Пользователь может войти по email + паролю, попадает на Dashboard и остаётся залогинен после обновления страницы.»
Затем зафиксируйте пограничные случаи, которые часто забывают. Поведение кнопки «назад» — классический источник дрейфа: «Назад из Checkout возвращает в Cart (не на Home), и элементы в корзине сохраняются.» Обозначьте состояния ошибок («неверный пароль показывает то же сообщение»), пустые состояния («нет проектов показывает ту же копию пустого экрана») и загрузки («спиннер появляется в течение 200ms, без сдвигов вёрстки»).
Если важны производительность и безопасность, заморозьте и их. Если вы не упомянете их, модель может «улучшить» поведение, добавив лишние запросы, логирование или поменяв проверки аутентификации.
Короткий способ это задать без длинного специфа:
Будьте конкретны по потокам данных в одном предложении на пункт. Например: «Адрес сохраняется только после нажатия Save, хранится в записи профиля пользователя и должен сохраняться после выхода/повторного входа.» Такой уровень детализации предотвращает автосейв, новые поля или изменения тайминга, которые ломают реальных пользователей.
Дрейф UI обычно происходит потому, что модель «помогает», очищая стили, отступы или структуру компонентов. Решение такое же, как для бизнес-логики: назовите, что должно оставаться идентичным, и укажите одну вещь, которую можно менять.
Закрепите видимую структуру. Укажите вёрстку (колонки/строки, расположение шапки и подвала), правила отступов (padding, gaps, выравнивание) и поведение компонентов (hover, disabled, спиннеры, сообщения об ошибках). Если компонент имеет специфическое ощущение, скажите это прямо: «Размер кнопки, радиус и цвет должны оставаться точь-в-точь такие же.»
Адаптивность требует явных правил. Если не упомянуть мобильную версию, инструменты могут «улучшить» её. Укажите брейкпоинты и поведение для каждого: порядок стэкинга, скрытые элементы, фиксированные панели и размеры тап-зон.
Также зафиксируйте слова. Скажите модели, что весь текст, подписи, placeholder'ы и подсказки не менять, кроме одной строки, которую редактируете. Это предотвращает молчаливые переписывания, которые меняют смысл.
Короткая подсказка для запроса изменений:
Если возможно, попросите скриншоты до/после. Если скриншотов нет, запросите короткое «UI-diff» описание (что сдвинулось, что изменило размер, что поменяло цвет), чтобы вы могли утвердить с уверенностью.
Бизнес-правила — одно из самых лёгких мест, где маленькое UI-правка может создать тихую регрессию. Обновление метки может случайно изменить расчёт, переход статуса или кто видит запись. Обращайтесь с правилами и данными как с контрактами.
Начните с перечисления тех правил, которые хуже всего пострадают от дрейфа. Пишите их как тесты: входы, выходы и кто может что делать.
Вместо «сохранить цены такими же», зафиксируйте:
Добавьте один числовой пример, чтобы убрать интерпретации. Например: «Промежуточная сумма заказа $120, скидка 10% (применяется до налога), налог 8.25% от суммы после скидки. Ожидаемый итог = (120 - 12) * 1.0825 = $116.91. Округлять до 2 знаков только в итоговой сумме.»
Укажите видимость по ролям, а не только действия. Пример: «Служба поддержки видит статус заказа и email клиента, но не должна видеть полные данные карты. Только админы могут делать возвраты.»
Если важна валидация — заморозьте её явно. Укажите точный триггер и сообщение пользователю: «Если дата начала после даты окончания — блокировать сохранение и показывать: ‘End date must be after start date.’ Не менять эту формулировку.»
Не забудьте о побочных эффектах за пределами приложения. Если вы отправляете письма, вебхуки или вызываете внешние API — заморозьте то, что должно оставаться таким же: названия событий, поля в payload, тайминг (немедленно или с задержкой) и идемпотентность (нет дублирующих отправок при повторе).
Относитесь к небольшому обновлению как к мини-контракту. Шаблон лучше всего работает, когда изменение узкое, а всё остальное явно заморожено.
Опишите изменение одним проверяемым предложением. «На странице настроек добавить переключатель для тёмной темы» — проверяемо. «Улучшить UI настроек» — нет. Если вы не можете проверить за 30 секунд, это всё ещё слишком широкая задача.
Напишите список заморозки для тех частей, которые повредят при дрейфе: пользовательский поток, ключевые элементы UI, бизнес-правила, поведение данных и любые API или таблицы в БД, которые должны остаться такими же.
Добавьте acceptance checks и короткий тест-план. Это предотвращает «работает у меня» сюрпризы. Включите проверки вроде: новый переключатель виден, существующие настройки по-прежнему сохраняются, и ничего больше на странице не сдвинулось.
Прежде чем начать редактирование, попросите ассистента повторить ваши ограничения. Пусть подтвердит, что будет изменено и что останется идентичным. Если резюме неверно, исправьте подсказку прежде чем позволить правки.
Попросите минимально возможную реализацию: без рефакторов, без переименований, без форматирования за пределами затронутых строк. Вы покупаете одно изменение, а не косметический ремонт.
Короткий чеклист для ревью:
Это особенно удобно в Koder.ai: вставьте список заморозки в Planning Mode, попросите ассистента повторить ограничения, а затем сгенерируйте минимальный патч.
Большинство «маленьких» правок ломаются по одной и той же причине: запрос защищает цель, но не поведение. Модель может достичь цели новым способом, тихо изменив экраны, логику или данные.
Одна типичная ловушка — заморозка результата («сделать онбординг проще») вместо точного описания шагов пользователя. Другая — фраза «оставьте всё как есть» и уверенность, что система поймёт, что это значит.
Ошибки, которые чаще всего приводят к дрейфу:
Небольшой пример: вы просите «сделать кнопку более заметной» и замораживаете цвет, но забываете заморозить состояние disabled. Обновление может сделать кнопку всегда доступной, изменив поведение, которое вы заметите только позже.
Что помогает — конкретика о том, что нельзя менять. Перед принятием обновления выполните быстрый регрессионный прогон:
Если что-то отличается, значит запрос не включал нужную деталь в список заморозки, а не «плохой код».
Частая безопасная итерация — мелкая полировка UI, где рабочий процесс не может поменяться.
Сценарий: у основателя простой экран регистрации с короткой формой (Name, Email, Company size) и основной кнопкой, которая сабмитит форму и переводит пользователя на Dashboard.
Точное задание (одно предложение): «Переименовать основную кнопку с 'Create account' в 'Continue' и заменить поле 'Company size' с текстового поля на выпадающий список.»
Теперь примените шаблон и заморозьте, что нельзя менять:
Acceptance checks, которые можно выполнить за минуты:
Хороший ответ ассистента должен повторить замороженные пункты, уточнить любую неясность (например, какие опции должны быть в dropdown и какое значение сохраняется) и затем сделать только минимальное изменение в коде/UI. Он должен также отметить, что специально не трогал (маршрутизацию, логику валидации, форму полезной нагрузки).
Перед тем как принять «маленькое изменение», сделайте быструю проверку, чтобы найти молчаливый дрейф. Цель не полное QA — цель подтвердить, что приложение по-прежнему ведёт себя в тех частях, где вы сказали «не менять», кроме единственного ожидаемого изменения.
Выполняйте их в одном и том же порядке. Это сохраняет спокойствие при ревью и облегчает поиск регрессий.
Откатывайте, если хоть один замороженный пункт изменился, даже если приложение «всё ещё работает». Изменённая подпись, новое поле или слегка иная логика — признак того, что модель сделала лишние изменения.
Повторите запрос с более жёсткими ограничениями: кратко повторите одно изменение в одном предложении, перечислите замороженные потоки и экраны по именам и добавьте «без изменений схемы, без изменений эндпоинтов, без изменения поведения за пределами X». Если вы используете Koder.ai, снимок до теста делает откат одним шагом, когда что-то смещается.
Если вы работаете в Koder.ai, шаблон «не менять» лучше всего взять за привычку: одно маленькое изменение, всё остальное заблокировано и чёткий путь назад при дрейфе.
Перед тем как просить изменение, переключитесь в Planning Mode и попросите ассистента кратко повторить вашу область на простом языке. Попросите его повторить две вещи: (1) точное изменение и (2) ясный список заморозки (потоки, UI детали и бизнес-правила, которые не должны двигаться).
Рабочая подсказка для планирования: «Повторите мой запрос. Затем перечислите, что нельзя менять. Если что-то неясно — задайте вопросы до начала редактирования.»
Относитесь к каждому запросу на изменение как к контрольной точке. Создайте снимок до правки, затем ещё один после верификации. Если что-то сломалось, откат быстрее, чем попытка исправить плохое изменение.
Например, вы меняете подпись кнопки в React-экране. Изменение выглядит крошечным, но всё равно может сдвинуть отступы, вызвать повторный рендер или сломать автоматические тесты. Снимок позволяет сравнить поведение и быстро откатиться.
Простой рабочий процесс:
Koder.ai может генерировать веб (React), бэкенд (Go + PostgreSQL) и мобильное (Flutter). Шаблон остаётся тем же, хоть код и меняется. Замораживайте части, которые определяют поведение, а не только файлы.
Если вы правите бэкенд-эндпоинт — заморозьте форму запроса/ответа, правила валидации и записи данных. Если вы правите мобильный экран — заморозьте порядок навигации, значения полей по умолчанию и сообщения об ошибках. Если вы меняете логику в БД — заморозьте смысл существующих строк и делайте безопасные миграции.
Скопируйте шаблон, выполните одно маленькое изменение сегодня и проверьте его чеклистом прежде чем принять. Храните шаблон и подставляйте новый запрос по одному за раз.
Используйте этот шаблон, когда вам нужен один конкретный изменение и важно, чтобы всё остальное осталось таким же. Особенно полезно для checkout, аутентификации, биллинга и любых потоков, где небольшое смещение может навредить пользователям.
Потому что части приложения используют общие компоненты, данные и правила. Небольшое правка UI может затронуть переиспользуемый компонент, изменить вёрстку в других местах, повлиять на валидацию или поменять форму API-полей — и вы обнаружите это позже.
Напишите одну чёткую цель, затем перечислите, что должно остаться идентичным после изменения. Ключ в том, чтобы заморозить поведение (потоки, правила, данные, интеграции) и видимые детали UI, а не просто сказать «ничего не ломать».
Коротко, но конкретно: критические потоки, детали UI/UX которые нельзя менять, бизнес-правила, поведение данных и интеграции. Если вы не можете назвать, что должно остаться неизменным, модель будет догадываться, а догадки приводят к дрейфу.
Ограничьте область до минимально необходимой, которая при этом защищает вас. Например, заморозьте поток checkout и общие компоненты, но не весь продукт, если вы меняете только подпись на одном экране.
Перечислите шаги пользовательских сценариев и определите, что значит «сделано». Добавьте типичные пограничные случаи: поведение кнопки «назад», сообщения об ошибках, пустые состояния, поведение при обновлении — чтобы потоки оставались идентичными в важных местах.
Явно заморозьте структуру вёрстки, отступы, состояния компонентов (hover/disabled/loading) и весь текст, кроме той единственной строки, которую редактируете. Иначе модель может «очистить» стили или переписать текст так, что изменится смысл или вёрстка.
Заморозьте контракты: формы запросов/ответов, правила валидации, разрешения, расчёты и то, что сохраняется и когда. Для чувствительных правил, например ценообразования, добавьте один числовой пример, чтобы исключить интерпретации при реализации.
Попросите проверяемые шаги и краткое diff-подобное описание того, что изменено и где. Затем прогоните замороженные потоки от начала до конца, вызовите хотя бы одно ошибочное и одно пустое состояние и подтвердите, что данные и интеграции не изменились.
Сделайте снимок перед изменением, выполните планирование с повторением области и списка заморозки, затем примените минимальный патч. После проверки — снимок «после», чтобы откат был в один шаг при проблеме.