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

Защо публикуваме това#

Блогът на IPFS.NINJA съществува, за да помага на разработчиците да вземат обосновани решения за съхранение с адресиране по съдържание — коя услуга за пинване да използват, кога специализиран шлюз си заслужава, как всъщност трябва да се пинват метаданните на NFT и т.н. Всяко от тези решения има реални последствия за разходите и обвързването с доставчик (lock-in). Затова приемаме точността на публикуваното сериозно и смятаме, че трябва да знаете точно как се създава съдържанието в този блог.

Какво отличава нашето съдържание#

• Проверено спрямо продукта. Всеки примерен код, API извикване и ценова стойност се проверяват спрямо живата платформа на IPFS.NINJA в момента на изготвяне. Ако дадено твърдение не може да бъде тествано спрямо продукцията, то не се публикува.
• Написано от оператори, не от маркетолози. Човекът, който преглежда всяка публикация, самият управлява платформата ежедневно, обработва тикетите за поддръжка и чете оперативните сигнали, които тя генерира.
• Сравненията са честни. Когато пишем „IPFS.NINJA срещу Pinata / Filebase / Web3.Storage“, цитираме дословно техните публични документации и страници с цени. Нищо не е представено изкривено. Ако те са пуснали нещо, което ние все още нямаме, го казваме.
• С помощта на ИИ, собственост на хора. Конкретен, назован човек одобрява всяка статия преди публикуване. ИИ помага с мащаба; човешката преценка е контролната бариера за публикуване.

Как се създава всяка статия#

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

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

2. Проучване и проверка спрямо продукта#

Четем първичните източници за всяко твърдение: спецификацията на IPFS, документацията на go-ipfs / kubo, актуалните цени и API документации на конкурентите. Всеки код фрагмент се изпълнява спрямо живата платформа на IPFS.NINJA. Ако нещо не работи както е документирано, го регистрираме като бъг в продукта, преди да публикуваме статията.

3. Изготвяне на чернова#

Повечето чернови се изготвят с помощта на ИИ, чрез промпт за генериране на съдържание, който съдържа брифа на статията, проверените факти от стъпка 2 и нашето ръководство за тон на гласа. Черновите попадат в хранилището като .md файл с пълен frontmatter, готов за преглед — без маркетингов шаблон, без отделна CMS.

4. Човешки преглед#

Конкретен, назован рецензент чете всяка чернова от край до край. Неговата задача е да улови:

• Всяко твърдение, което не е подкрепено от първичните източници или не се възпроизвежда спрямо живия продукт
• Сравнения, които преувеличават нашата позиция или представят погрешно текущото предложение на конкурент
• Съвети, които биха стрували на читателя реални пари, ако бъдат последвани — ценова математика, избор на план, пътища за миграция
• Текст, който звучи като маркетинг, а не като практическо инженерство

5. Прецизиране и финален преглед#

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

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

Превеждаме всяка готова за публикуване статия на 40 допълнителни локала. Всеки превод запазва техническата точност на оригинала — примерният код не се пренаписва, локализира се само текстът. Английската статия винаги е каноничната версия; ако преведен вариант противоречи на английския, английският има превес.

7. Публикуване и разкриване на ИИ#

Всяка публикувана статия носи видимо разкриване за ИИ съдържание (в долната част на всяка публикация), обясняващо, че статията е изготвена с помощта на ИИ и прегледана от човек. Това е сигнал за полезно съдържание съгласно Google и обещание към читателя, че произходът на това, което четете, не е скрит.

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

IPFS и екосистемата около него се развиват бързо. Цените се променят. API-та остаряват. Добрите практики се развиват. Съдържание, което е било точно при публикуването си, може да стане подвеждащо година по-късно.

Всяка седмица пускаме автоматизиран тракер за SEO и актуалност върху целия корпус от съдържание. Той извлича сигнали от Search Console, прави одит на страница по страница и идентифицира публикации, които се класират по остарели заявки или се позовават на остарели API-та. Резултатът се превръща в списък с конкретни редакции — предимно механични (поправяне на остаряла цена, замяна на остаряла крайна точка), някои преценени от човек (дали дадена статия се нуждае от съществено пренаписване или от изтегляне от публикуване).

Всяка публикация носи дата Updated: в началния блок, различна от оригиналната дата на публикуване, за да знаете колко актуално е реално съдържанието пред вас.

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

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

Предпочитаме да публикуваме по една точна, проверена статия седмично, отколкото четири статии, които само докосват темата повърхностно. Ако дадено твърдение не може да бъде подкрепено спрямо живия продукт, то не се публикува. Точка.

Конкретни, назовани хора преглеждат всичко#

Редакционният преглед на всяка статия се извършва от конкретен, назован човек — вижте подписа на всяка публикация. Не публикуваме анонимно и не се крием зад институционален глас.

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

Преводите запазват техническите факти на английския оригинал. Текстът, пунктуацията и идиоматиката се адаптират спрямо съответния локал; залегналите твърдения — не.

Сравненията цитират първични източници#

Всяко твърдение за конкурент съдържа връзка към собствената му актуална документация или страница с цени. Ако предложението на конкурент се е променило, откакто сме писали за него, коригираме статията — не оставяме остарели сравнения.

Практичност пред остроумие#

Оптимизираме за това дали статията помага на реален разработчик да вземе реално решение — не за това колко остроумна е формулировката или колко нов е погледът.

Прозрачност относно ИИ#

Всяка статия, изготвена с помощта на ИИ, го посочва в долната част, на всеки локал, при всяка публикация. Без заобикалки, без маркетингова формулировка.

Нашият ангажимент#

Ако откриете нещо в този блог, което е фактически невярно, остаряло или представя погрешно продукт на конкурент, искаме да знаем. Свържете се с нас на hello@ipfs.ninja. Коригираме статиите открито — всяка съществена редакция обновява датата Updated: и запазва одитна следа в историята на Git.

Доверието е самата причина да пишем за съхранение с адресиране по съдържание. Държим се на същия стандарт.