Редакционный процесс

Зачем мы это публикуем#

Блог IPFS.NINJA существует, чтобы помогать разработчикам принимать обоснованные решения о хранении данных с адресацией по содержимому — какой сервис пиннинга использовать, когда стоит подключать выделенный шлюз, как на самом деле нужно закреплять метаданные NFT, и так далее. Каждое из этих решений имеет реальные последствия с точки зрения затрат и привязки к поставщику. Поэтому мы серьёзно относимся к точности того, что публикуем, и считаем, что вы должны точно знать, как создаётся контент этого блога.

Чем наш контент отличается#

• Проверено на продукте. Каждый пример кода, каждый вызов API и каждая цифра цены проверяются на актуальной платформе IPFS.NINJA на момент написания черновика. Если утверждение невозможно проверить на продакшене, оно не публикуется.
• Написано операторами, а не маркетологами. Человек, проверяющий каждую статью, сам ежедневно управляет платформой, обрабатывает обращения в поддержку и читает операционные сигналы, которые она выдаёт.
• Сравнения честны. Когда мы пишем «IPFS.NINJA vs. Pinata / Filebase / Web3.Storage», мы дословно цитируем их публичную документацию и страницы с ценами. Ничего не искажается в невыгодную для конкурента сторону. Если у них есть то, чего нет у нас, мы так и говорим.
• С помощью ИИ, под ответственностью человека. Каждую статью перед публикацией утверждает конкретный названный человек. ИИ помогает с масштабом; решение о публикации принимает человек.

Как создаётся каждая статья#

1. Создание брифа#

Каждая статья начинается с реального сигнала — паттерна обращений в поддержку, кластера запросов из Search Console или вопроса клиента об интеграции. Бриф фиксирует аудиторию, обещание статьи и поисковое намерение, на которое она нацелена.

2. Исследование и проверка на продукте#

Мы изучаем первоисточники для любого утверждения: спецификацию IPFS, документацию go-ipfs / kubo, актуальные цены и документацию API конкурентов. Каждый фрагмент кода запускается на актуальной платформе IPFS.NINJA. Если что-то работает не так, как задокументировано, мы сначала заводим это как баг продукта, а уже потом публикуем статью.

3. Написание черновика#

Большинство черновиков создаются с помощью ИИ по промпту генерации контента, который содержит бриф статьи, проверенные факты из шага 2 и наш гид по стилю. Черновики попадают в репозиторий как .md-файл с полным фронтматтером, готовый к проверке — без маркетингового шаблона, без отдельной CMS.

4. Проверка человеком#

Названный рецензент читает каждый черновик от начала до конца. Его задача — выявить:

• Любое утверждение, не подтверждённое первоисточниками или не воспроизводимое на актуальном продукте
• Сравнения, которые преувеличивают наши преимущества или искажают текущее предложение конкурента
• Советы, которые обойдутся читателю в реальные деньги, если он им последует, — расчёты стоимости, выбор тарифа, пути миграции
• Текст, который читается как маркетинг, а не как практическая инженерная статья

5. Доработка и финальное чтение#

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

6. Локализация#

Мы переводим каждую готовую к публикации статью ещё на 40 языковых версий. Каждый перевод сохраняет техническую точность оригинала — примеры кода не переписываются, локализуется только текст. Английская статья всегда является канонической; если переведённый вариант расходится с английским, приоритет у английского.

7. Публикация и раскрытие информации об ИИ#

Каждая опубликованная статья содержит видимое уведомление о ИИ-контенте (внизу каждой публикации), объясняющее, что статья создана с помощью ИИ и проверена человеком. Это сигнал для руководства Google по полезному контенту и обещание читателю, что происхождение того, что вы читаете, не скрывается.

Поддержание актуальности контента#

IPFS и его экосистема быстро развиваются. Цены меняются. API устаревают. Лучшие практики эволюционируют. Контент, который был точным на момент публикации, может стать вводящим в заблуждение через год.

Мы еженедельно запускаем автоматизированный трекер SEO и актуальности по всему корпусу статей. Он собирает сигналы Search Console, проводит пооптимизационный аудит каждой страницы и выявляет статьи, которые ранжируются по устаревшим запросам или ссылаются на устаревшие API. Результатом становится список конкретных правок — в основном механических (исправить устаревшую цену, заменить устаревший эндпоинт), некоторые требуют решения человека (нужна ли статье существенная переработка или её стоит снять с публикации).

Каждая публикация содержит дату «Обновлено:» в шапке, отдельную от даты первоначальной публикации, чтобы вы знали, насколько свеж контент перед вами.

Наши редакционные принципы#

Точность продукта важнее скорости#

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

Все статьи проверяют конкретные названные люди#

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

Локализация уважает первоисточник#

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

Сравнения ссылаются на первоисточники#

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

Практичность важнее эффектности#

Мы оптимизируем статьи с точки зрения того, помогают ли они реальному разработчику принять реальное решение, а не с точки зрения того, насколько эффектна подача или оригинальна идея.

Прозрачность в отношении ИИ#

Каждая созданная с помощью ИИ статья сообщает об этом внизу, на каждой языковой версии, при каждой публикации. Без оговорок, без маркетинговой подачи.

Наши обязательства#

Если вы найдёте в этом блоге что-то фактически неверное, устаревшее или искажающее продукт конкурента, мы хотим об этом знать. Напишите нам на hello@ipfs.ninja. Мы открыто исправляем статьи — каждая существенная правка обновляет дату «Обновлено:» и сохраняет журнал изменений в истории Git.

Доверие — это вся суть того, зачем вообще писать о хранении данных с адресацией по содержимому. Мы придерживаемся тех же стандартов сами.