Обновить
32K+
16

Пользователь

81,3
Рейтинг
3
Подписчики
Отправить сообщение

У них нейронка головного мозга.

Спасибо, огромное, за поддержку 🙏 да, минусанули мне карму(

В этом плане все было сложно, мне даже объяснительную пришлось написать, потому что никто не «вкуривал» что вообще происходит. Они думали, что вина всему моя некомпетентность.

Не знаю, как у других, но мне премию вечно выгрызать приходится. 10к дал один директор, 8к другой, и я из принципа выбил ее лишь потому, что они трепали мне нервы в ходе работы.

ЗП по рынку маленькая. Дело в том, что это два моих старейших клиента и я их не бросаю буквально из вежливости. Хоть и часто думаю над этим) Сам уже давно своими проектами занимаюсь.

Капец тут у вас душная обстановочка 🤣, стоит начать отвечать шаблонными фразами, как все сразу напрягаются) честное слово – статью писал я. На комменты тоже отвечаю я, ну хватит уже) теперь я буду придерживаться неформального стиля, чтобы вы точно не решили, что я не робот!

Кажется, у нас тут недопонимание. Нет, это не прикол, я действительно учту, что нельзя использовать ИИ даже для редактирования текста.

Спасибо, ну как говорят – первый блин комом. Самое главное, что я умею слышать обратную связь и учусь на ошибках.

Вы правы и я все это понимаю, претензия к Таймвебу, что они держат всех за дураков и умалчивают проблемы.

Вы словно читаете между строк или додумываете, я ведь прямо написал, что модель лишь РЕДАКТИРОВАЛА мною написанное!!! Вам что, заняться нечем? Ладно бы я рекламировал что-то, но ведь просто опытом поделился. Всегда появится пару токсиков, которое смешает все с 💩

Какая ваша цель? Чего вы добиваетесь? Хотите вершить правосудие или показать себя правым? Вам этого в жизни не хватает и вы решили тут испортить мне настроение?

Да, для меня это стоило + пару седых волос и бессонных ночей, а для компаний несколько миллионов оборотных средств. Безответственный подход у ведомства.

Спасибо за конструктивную критику, обещаю, что если еще раз решусь, то укажу это в статье более явно!

Нейронка может лишь налить много воды. Я писал очень кратко, вычленяя каждое слово, как Высоцкий. А она сказала, что такой текст очень сложный для чтения и лишь оптимизировала его как редактор. Затем уже я правил за ней вычерпывая лишнюю воду.

Касаемо этого куска, то там я полагал, что в настройках есть какой-то чекбокс, который включает POST, но его не оказалось и после общения с поддержкой и чтения документации выяснилось, что Яндекс – это Яндекс)

Честно говоря, я вообще не верил, что статью опубликуют, всей семьей комменты читаем, жена меня хвалит 😂

При написании статьи мне действительно помогала нейронка, я не главный редактор или журналист, я обычный технарь, который всю жизнь читал Хабр без регистрации.

У меня это первая статья на Хабре и потому это весьма волнительный шаг, не хотелось прилюдно обделаться. Потому я накидал основной костяк статьи, а затем правил его в нейронке.

Я не пытаюсь тут корчить из себя супер профи, просто хотел обсудить важную для всех тему и поделиться ее решением.

Сервер находится в Москве.

Согласен, для чистой смены IP хватит и iptables - и source IP при DNAT даже сохранится. Но L3 не даёт трёх вещей: пробросить /.well-known/acme-challenge/ (на этом уровне нет путей, а сертификаты выпускаются по HTTP-01), кэшировать статику и главное - влиять на TLS-хендшейк. При L3-пробросе DPI видит оригинальный Client Hello бэкенда со всеми отпечатками, меняется только адрес. С терминацией на прокси хендшейк новый, и можно крутить версии TLS и HTTP/2 - что, судя по соседнему комментарию, как раз и решает проблему. Ресурсов nginx ест копейки.

Спасибо. Дело в том, что вся эта ситуация приключилась 2 месяца назад и тогда еще не было «народных» методов, а придать этому огласку я решил из-за действий хостера. Обязательно опробую этот метод.

Критические проблемы не раскрыты:


1. Огромная разница между исследованиями и кремами:
- Сильные эффекты получены при инъекциях или на открытых ранах
- Крем на здоровой коже — совсем другая история
- Проникновение через роговой слой кожи крайне ограничено

2. Маленькая доказательная база для косметики:
- Клинические испытания на людях: малые группы (20-50 человек), короткий срок (8-12 недель)
- Нет крупных рандомизированных контролируемых исследований
- Долгосрочная безопасность не изучена

3. Проблема стабильности в реальных продуктах:
- в статье упоминают это, но смягчают: на практике большинство кремов с GHK-Cu содержат деградировавший или неактивный комплекс
- Липосомальные формы дороги и редки

4.Избирательная подача:
- Не сравнивается с проверенными ингредиентами (ретиноиды эффективнее для anti-age, витамин C для синтеза коллагена)
- Не упоминаются неудачные или противоречивые исследования

Статья хочет являться научно обоснованным маркетингом.

Аналогия в финале про “прораба” хорошая, но неполная: прораб пришёл, показал чертежи, но стройматериалы (медь) не прошли через забор (кожный барьер), и бригада осталась без инструментов 😊

Стоит ли покупать кремы с GHK-Cu? Как вспомогательное средство — можно попробовать (особенно для заживления после процедур). Как основное anti-age — ретиноиды надёжнее и дешевле.​​​​​​​​​​​​​​​​

@mshogin Спасибо за статью! Хоть я и не пишу на Go, для меня все равно было очень полезно ознакомиться с теорией!

Я понимаю и не спорю с вами, а лишь пытаюсь хоть как-то сгладить проблему. Сам думал обо всем этом, и тут вы всё очень ясно изложили.

Я скормил все вышеизложенные правила Opus 4.1 и он составил системный промпт, который можно использовать в проектах, может коллективно подумать над ним и предложить корректировки:

ОБЯЗАТЕЛЬНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ (НАРУШЕНИЕ = ОТКАЗ)

ШАГ 0: АНАЛИЗ ЗАПРОСА

Перед началом работы ВЫВЕДИ:

ОБЛАСТЬ ЗАДАЧИ: [веб/данные/алгоритмы/…]

РАЗМЕР КОНТЕКСТА: [малый <100 строк / средний <1000 / большой >1000]

ЗНАКОМАЯ ОБЛАСТЬ: [да - есть в типовых паттернах / нет - специфичная]

РИСК ГАЛЛЮЦИНАЦИИ: [низкий/средний/высокий]

ШАГ 1: ФОРМАЛЬНАЯ СПЕЦИФИКАЦИЯ (ДО КОДА!)

ВХОДНЫЕ ДАННЫЕ:

- Тип:

- Диапазон значений:

- Граничные случаи:

ВЫХОДНЫЕ ДАННЫЕ:

- Тип:

- Формат:

- Возможные ошибки:

ИНВАРИАНТЫ (НЕРУШИМЫЕ ПРАВИЛА):

1. [что ДОЛЖНО оставаться истинным всегда]

1. […]

ЗАВИСИМОСТИ:

- Внешние модули:

- Глобальные переменные:

- Побочные эффекты:

ОГРАНИЧЕНИЯ:

- Время: O(?)

- Память: O(?)

- Специфичные требования:

ШАГ 2: ВЫБОР АЛГОРИТМА (ЯВНОЕ ОБОСНОВАНИЕ)

РАССМОТРЕННЫЕ ВАРИАНТЫ:

1. [алгоритм А]: O(…), причина отклонения: […]

1. [алгоритм Б]: O(…), ВЫБРАН, потому что: […]

ГРАНИЧНЫЕ СЛУЧАИ:

- Пустой вход: [поведение]

- Максимальный размер: [поведение]

- Некорректные данные: [поведение]

ШАГ 3: ПСЕВДОКОД (ПРОВЕРКА ЛОГИКИ БЕЗ СИНТАКСИСА)

ШАГ ЗА ШАГОМ на человеческом языке:

1. …

1. …

ПРОВЕРКА ИНВАРИАНТОВ:

После шага N проверяется: [какой инвариант]

ШАГ 4: РЕАЛИЗАЦИЯ С КОММЕНТАРИЯМИ

ИНВАРИАНТ: [что сохраняется]

def function():

    Вход: [повтор спецификации]

    Выход: [повтор спецификации]

    Проверка предусловия

    assert ..., "Нарушен инвариант: ..."

    [код с комментариями на каждом критичном месте]  

    Проверка постусловия

    assert ..., "Нарушен инвариант: ..."

ШАГ 5: САМОКРИТИКА (ОТДЕЛЬНЫМ БЛОКОМ!)

КРИТИЧЕСКИЙ АНАЛИЗ:

1. Где я мог соскользнуть на знакомый паттерн вместо оптимального?

2. Все ли инварианты проверены?

3. Есть ли зависимости, которые я мог пропустить?

4. Сложность действительно O(...), а не O(...)?

ПОТЕНЦИАЛЬНЫЕ ОШИБКИ:

- [что может сломаться]

- [какие граничные случаи опасны]

ШАГ 6: ТЕСТЫ (МИНИМУМ 3 КАТЕГОРИИ)

1. БАЗОВЫЙ СЛУЧАЙ

assert function(normal_input) == expected_output

2. ГРАНИЧНЫЙ СЛУЧАЙ  

assert function(edge_case) == expected_edge_output

3. ПРОВЕРКА ИНВАРИАНТА

[property-based тест или проверка через assert]

ПРАВИЛА МОДИФИКАЦИИ СУЩЕСТВУЮЩЕГО КОДА

ЕСЛИ ЗАДАЧА: “Исправь/измени/доработай код”

СТРОГО ЗАПРЕЩЕНО:

  • Переписывать код полностью

  • Вводить новые переменные без явного обоснования

  • Менять структуру без необходимости

    ОБЯЗАТЕЛЬНО:

ШАГ 1: Анализ существующего кода

  - Какие модули затронуты

  - Какие зависимости существуют

  - Какие инварианты должны сохраниться

ШАГ 2: Определение минимальной области изменений

  ИЗМЕНЯЮТСЯ ТОЛЬКО СТРОКИ: [номера]

  ВСЁ ОСТАЛЬНОЕ ОСТАЁТСЯ: идентично

ШАГ 3: Список переменных вне зоны изменений

  Эти переменные НЕЛЬЗЯ переименовывать/удалять:

  - [список]

ШАГ 4: Diff-формат изменений

  БЫЛО (строки X-Y):

  [старый код]

  СТАЛО (строки X-Y):

  [новый код]

  ОБОСНОВАНИЕ: [почему именно так]

АНТИПАТТЕРНЫ (ЗАПРЕЩЁННЫЕ ДЕЙСТВИЯ)

НЕ ПРАВИЛЬНО: "Я напишу код, который решит задачу"

ПРАВИЛЬНО: "Я опишу спецификацию, выберу алгоритм, затем реализую"

НЕ ПРАВИЛЬНО: Использовать первый пришедший в голову алгоритм

ПРАВИЛЬНО: Рассмотреть минимум 2 варианта с явным обоснованием

НЕ ПРАВИЛЬНО: "Вот полный рефакторинг всего модуля"

ПРАВИЛЬНО: "Вот изменения в строках 45-67, остальное без изменений"

НЕ ПРАВИЛЬНО: Вводить переменные final_result, final_final_result

ПРАВИЛЬНО: Использовать семантически значимые имена из спецификации

НЕ ПРАВИЛЬНО: "Это должно работать" / "Вероятно корректно"

ПРАВИЛЬНО: "Инвариант X проверяется assert'ом в строке Y"

СИГНАЛЫ ОПАСНОСТИ (когда остановиться)

ОСТАНОВИСЬ, если:

- Не можешь формализовать инвариант

- Не уверен в сложности алгоритма  

- Задача требует знаний узкоспециализированной области

- Контекст превышает ~500 строк кода

- Появляется желание "переписать красиво"

ВМЕСТО ЭТОГО:

1. Признай ограничение

2. Запроси у пользователя: тесты/примеры/спецификацию

3. Предложи декомпозицию на подзадачи

РЕЖИМ “ДЛИННЫЙ КОНТЕКСТ” (>500 строк)

СТРАТЕГИЯ ДЕКОМПОЗИЦИИ:

1. "Я вижу [N] строк кода. Это превышает мою зону надёжности."

2. "Предлагаю разбить на модули: [список]"

3. "Работаем с каждым модулем отдельно"

4. "После каждого модуля - ваша верификация"

НЕ ПЫТАЙСЯ:

- Держать весь контекст в "голове"

- Гарантировать целостность при одном проходе

- Модифицировать глобальную архитектуру без явного разрешения

ФИНАЛЬНАЯ ПРОВЕРКА (перед выдачей кода)

  • Спецификация написана до кода

  • Минимум 2 алгоритма рассмотрено  

  • Инварианты явно указаны и проверены

  • Сложность O() обоснована

  • Граничные случаи описаны

  • Тесты написаны

  • Самокритика проведена

  • Если модификация - diff показан, а не весь код

Спасибо за Камилу за поднятие вопроса, у меня вопрос – возможно как-то управлять траекторией нарратива так, чтобы правдоподобное совпадало с правильным?

1. Принудительная декомпозиция (против декогеренции)

Не давать модели весь код сразу. Разбивать задачу на этапы:

Этап 1: Проанализируй архитектуру. Перечисли все модули и их инварианты.

Этап 2: Для модуля X определи входы, выходы, зависимости.

Этап 3: ТОЛЬКО ТЕПЕРЬ модифицируй функцию Y, сохраняя все зависимости из этапа 2.

Каждый этап — это отдельный запрос. Между ними — ваша верификация. Да, это медленнее, но вы разбиваете большой нарратив на управляемые фрагменты.

2. Имитация ретроспекции через явный анализ

Модель не может вернуться назад, но вы можете заставить её “думать вперёд”:

Перед тем как написать код:

1. Опиши алгоритм словами

2. Укажи сложность O()

3. Перечисли граничные случаи

4. Только после этого напиши реализацию

Это не настоящая ретроспекция, но создаёт “якоря” в нарративе, снижая вероятность соскальзывания на неправильную траекторию.

3. Явная спецификация инвариантов (против нарративности)

Поскольку модель не понимает инварианты как абсолюты, вы должны их буквально прописывать:

ИНВАРИАНТЫ (НАРУШЕНИЕ = ОШИБКА):

- Баланс до = Баланс после + сумма транзакции

- Переменная user_id не изменяется внутри функции

- Список dependencies из requirements.txt сохраняется полностью
После написания кода проверь каждый инвариант явно.

Делая инварианты частью нарратива, вы повышаете их вес в паттерн-матчинге модели.

4. Ограничение области изменений (против регенерации всего)

КРИТИЧНО: Ты должен изменить ТОЛЬКО строки 45-67.

Всё остальное должно остаться ИДЕНТИЧНО, байт в байт.

Перед изменением выпиши переменные, которые используются ВНЕ этого фрагмента.

Явно блокируйте тенденцию модели переписывать всё. Просите показать diff, а не весь код.

5. Многопроходная верификация (компенсация отсутствия логики)

Проход 1: Напиши код

Проход 2: Найди в нём ошибки как критик (новый промпт, отдельный запрос!)

Проход 3: Исправь найденные ошибки

Разные “роли” в разных запросах создают независимые траектории. Иногда “критик” видит то, что “программист” пропустил.

6. Привязка к формальным спецификациям

Вместо: "Напиши функцию сортировки"

Используй: "Напиши функцию, удовлетворяющую:

- Вход: List[int], длина до 10^6

- Выход: List[int], отсортирован по возрастанию

- Сложность: O(n log n) максимум

- Память: O(1) дополнительной

Какой алгоритм подходит? ЗАТЕМ напиши код."

7. Противодействие “пузырьковому резонансу”

Когда боитесь, что модель выберет знакомый, но неподходящий паттерн:

ЗАПРЕЩЕНО использовать: bubble sort, naive approach

ОБЯЗАТЕЛЬНО учесть: dataset size = 1M records

ОБЯЗАТЕЛЬНО оценить: time complexity перед выбором алгоритма

Явно заглушайте нежелательные резонансы.

8. Использование внешней верификации

Модель не может сама проверить корректность. Но вы можете:

После генерации кода:

1. Напиши 10 unit-тестов, покрывающих граничные случаи

2. Напиши property-based тест (hypothesis/quickcheck стиль)

3. Я запущу их и вернусь с результатом

Затем реально запускаете. Это замыкает петлю обратной связи, которой у модели нет.

Информация

В рейтинге
81-й
Зарегистрирован
Активность