В одному абзаці
Невелика редакція в компанії, що випускає програми для звичайних користувачів, веде три справи, які раніше з’їдали більшу частину тижня. Треба підготувати маркетинговий бриф, з яким стаття вийде в топ пошуку; перетворити цей бриф на вичищену англомовну статтю в Google Docs; і написати за технічного директора компанії авторські колонки для сторонніх видань. Редакційна майстерня робить усе це на одній спільній основі з чіткими правилами. Бриф, на який ішло півдня SEO-копирсання, тепер готовий за лічені хвилини. Шлях від брифу до опублікованого документа, що забирав майже весь робочий день, займає близько 20 хвилин: здебільшого працює машина, а людина лише коротко шліфує текст. А колонка приходить уже написаною голосом техдиректора, з фірмовими графіками, які лишається тільки вставити. Кожен етап зберігає файл, який оператор може відкрити, виправити й перезапустити з нього роботу, – це прозорі перетворення на Python, а не промпт, що працює як чорна скринька. Над майстернею 3 місяці працювала одна людина; тепер нею щодня користуються двоє авторів, і вже 17 статей пройшли весь шлях до публікації.
Проблема мовою бізнесу
Скільки текстів випустить невелика редакція, залежить від годин авторів, а не від ціни слова. Найдорожче – чорнова робота з обох боків від самого письма. Перед ним треба зібрати бриф, з яким стаття справді вийде в топ: справжні внутрішні посилання, надійні джерела, питання, які люди вводять у пошук, конкурентів, яких треба обійти. Після нього – оформити й вичитати чернетку так, щоб вона стала опублікованим матеріалом у чужому фірмовому стилі. Саме письмо – найменший шматок роботи; дослідження перед ним і риштування після нього з’їдають день, а експертні колонки техдиректора, які команда з двох людей рідко може дозволити собі починати з нуля, відкладаються на місяці.
- Готувати кожен бриф уручну: вишукувати внутрішні посилання, перевіряти зовнішні джерела, читати пошукову видачу, виписувати питання, на які треба відповісти.
- Читати бриф російською чи українською і подумки відділяти маркетингові побажання від технічної правди.
- Оформлювати вручну в Docs: рівні заголовків, розділові знаки в списках, регістр у виносках, зміст, скріншоти – по одному.
- Колонки для сторонніх видань: щоразу заново вивчати стиль сайту й голос техдиректора, будувати кожен графік уручну.
- Кожен новий переклад – ще одне коло тим самим маршрутом.
- Дати агентові тему – він сам досліджує її у трьох напрямках і заповнює розділи 1–2, а кожне посилання перевіряє наживо.
- Покласти бриф у `inbox/` і запустити одну команду; технічна правда за правилом переважує маркетингові побажання.
- Оформлений Google Doc з'являється в потрібній теці Drive, скріншоти вже на місці, фірмовий стиль стережуть автоматичні перевірки.
- Колонки пишуться голосом техдиректора й у стилі видання, з фірмовими графіками, готовими до вставки.
- Підготовка перекладу – одна команда на мову, за спільними глосаріями.
Чим це відрізняється від «одного великого промпту»
Майстерня – це ланцюжок етапів, що йдуть один за одним, і кожен зберігає справжній файл, який оператор може відкрити. Коли автоматичне визначення типу статті приймає покрокову інструкцію за порівняння, виправити це просто: змінити одне поле в нормалізованому JSON і перезапустити з етапу validate, а не переписувати промпт для всього конвеєра й сподіватися на краще. Фірмовий стиль живе в автоматичних перевірках між етапами, а не в довгому промпті, від якого чекають, що він усе втримає: рівні заголовків, розділові знаки в списках, регістр виносок, будова змісту – будь-яка помилка тут зупиняє конвеєр ще до того, як скрипт публікації звернеться до Drive. Укладач брифів проводить таку саму тверду межу з іншого боку: він заповнює маркетингові й SEO-розділи, але ніколи не пише в розділ 3 – там власні практичні тести автора, і конвеєр статей вважає їх головним джерелом правди. Кожна задача точно знає, якої частини документа їй торкатися не можна.
Голос автора зберігається як дані: невеликий JSON-профіль на кожного автора містить ознаки тону й улюблені звороти. Тож двоє авторів працюють з одним генератором статей, і кожен отримує чернетки, що звучать саме як він сам. Той самий механізм вмикає голос техдиректора, коли треба написати гостьову колонку для стороннього сайту. Два шляхи публікації розведено на рівні архітектури: внутрішній скрипт публікації не може навісити на текст оформлення зовнішньої статті, а завантажувач для сторонніх видань не протягне в гостьовий матеріал каркас сайту компанії. Кожен із трьох типів статей має власний генератор замість одного промпту на всі випадки. Коду через це більше, зате каркас порівняльної таблиці ніколи не просочиться з добірки в інструкцію.
| критерій | Один величезний промпт на всі типи статей | Три генератори за типами статей на спільному ядрі обрано | Вільний генератор із доведенням стилю наприкінці |
|---|---|---|---|
| Дотримується правил будови кожного типу | частково | так | ні |
| Справляється з картками добірок і порівняльними таблицями | змішує | так | змішує |
| Легко додати четвертий тип статті | ні | так | так |
| Легко знайти, де зламалося | ні | так | частково |
| Уживається з автоматичними перевірками стилю | частково | так | ні |
Калькулятор економії на перекладах
Підставте свій редакційний ритм: скільки статей на місяць, скільки часу йде на ручний переклад, на скільки мов, яка погодинна ставка автора. Нижче – скільки часу на місяць заощадить зв'язка «генератор + глосарії» лише на тому, щоб розвести одну статтю на кілька мов.
працює у вашому браузері · 0 мережевих запитів · щоразу той самий результат
Як це виглядає в роботі
Три розмови з агентом – по одній на кожну задачу майстерні, одна за одною.
Агент з’ясовує, вирішує, виконує й перевіряє; кожен сценарій закінчується
рядком success. Вступ праворуч лишається на місці, поки ви гортаєте
сторінку, а кожна сцена нижче підхоплює наступну задачу, щойно дійде до
середини екрана.
Перед початком роботи
Майстерня бере одну з трьох задач і доводить її до готового результату: дослідженого брифу, опублікованої статті або колонки голосом техдиректора. Кожна сесія починається з двох файлів: CLAUDE.md описує, як усе влаштовано (як читати брифи, як визначати тип статті, куди класти готові документи), а SKILL.md перелічує редакційні правила, яких дотримується кожен генератор.
Далі – три розмови, по одній на кожну задачу: звичайний прогін конвеєра без пригод, який перетворює бриф на оформлений документ; укладач брифів, що з самої лише теми досліджує й заповнює бриф; і автор-тінь, який пише колонку для стороннього сайту з графіками, зробленими під скріншот.
Кожен сценарій закінчується рядком success: агент вирішує,
виконує, перевіряє й звітує. Правило «спершу спитай, а вже тоді роби щось
незворотне» діє на рівні всього каталогу; у межах однієї задачі агент
доводить справу до кінця сам.
Уся увага зазвичай дістається генераторові. Але залишати систему працювати без нагляду можна завдяки перевіркам і межі «розділ 3 не чіпати ніколи» – саме на них пішла більша частина трьох місяців.
Усе працює локально: брифи, скріншоти й чернетки техдиректора лишаються в Drive компанії, а назовні йдуть лише пошук в інтернеті та запити до моделі, що пише чернетки. Саме тому цей кейс і можна оприлюднити: архітектуру вдається описати, бо дорогою вона не випускає назовні жодного матеріалу компанії.
Задача перша – на вході бриф, на виході Google Doc
Бриф із маркетинговою й технічною частинами потрапляє в inputs/briefs/inbox/, оператор запускає одну команду – і хвилин за 20 у потрібній теці Drive уже лежить оформлений Google Doc зі вставленими скріншотами та змістом, зібраним засобами самого Docs. Прогін іде так: normalise → validate → render → validate-format → publish, і кожен етап зберігає файл, який оператор може відкрити.
Нормалізований JSON показує, як розібрано бриф і який блок переміг там, де маркетингові побажання розійшлися з технічною правдою. Звіт перевірки показує, які мінімальні вимоги стилю виконано: внутрішні посилання, зовнішні посилання, запитання для FAQ, описи скріншотів. Тут усе на виду, і в кожному кроці можна докопатися до причини.
За фірмовим стилем стежать перевірки між етапами, тож сподіватися, що довгий промпт усе втримає, не доводиться. Чернетка втомленого понеділка й чернетка бадьорого вівторка проходять ті самі правила – тому двоє авторів і можуть працювати з одним генератором, а їхні тексти не розходяться за стилем.
Перед кожною публікацією – пробний прогін: скрипт спершу доводить, що звернення до Drive спрацює, і лише тоді його виконує. Цей запобіжник коштує 10 секунд і окупається вже першого разу, коли ідентифікатор теки виявиться хибним. Тут на все пішло 18 хвилин, і в автора попереду ще 6 годин робочого дня.
Задача друга – з голої теми виростає бриф для топу пошуку
Це та сама чорнова робота, що раніше обступала письмо з обох боків: перш ніж сісти за чернетку, треба зібрати бриф, з яким стаття справді вийде в топ. Агент бере саму лише тему й досліджує її одночасно в трьох напрямках: власні статті компанії – для внутрішніх посилань, надійні сторонні джерела – для цитат, жива пошукова видача – для заголовків, питань і конкурентів, яких матеріал має обійти.
Головне тут – перевірка. Кожне посилання агент відкриває й переконується, що воно живе, перш ніж додати його в бриф, а поняття й терміни, які бриф радить ужити, бере з текстів, що справді стоять у топі, а не вигадує навмання. Бриф, повний правдоподібних, але мертвих посилань, гірший, ніж жодного; цей спирається лише на те, що відкривається.
Межа важить не менше за дослідження. Укладач заповнює маркетингові й SEO-розділи і ніколи не пише в розділ 3 – там власні практичні тести автора, і конвеєр далі вважає їх правдою, що переважує все інше. Машина робить те, що їй вдається, а те, що може зробити лише автор, лишає авторові.
Без заминки не обійшлося – з форматуванням. Docs API мовчки відкидає сірий колір зі значенням рівно 0.4, тож після першого заповнення стиль злітає. Як це виправити, відомо, і рішення вже записане в коді: писати 0.405, надсилати по одному полю стилю за раз і перечитувати документ, доки він не віддасть остаточну версію. За весь цей клас дивацтв заплачено один раз, у коді, і більше не доводиться платити щоразу, коли заповнюють бриф. Та сама арифметика і з джерелами: одне мертве посилання забирає більше довіри, ніж додають десять добрих, тому кожне посилання агент відкриває, перш ніж вставити, – хоч так і повільніше.
Задача третя – колонка техдиректора для стороннього видання
Експертних текстів під іменем керівника виходить мало, але кожен багато важить: він має звучати як сама людина, пасувати виданню й ніколи не скидатися на рекламу. Агент відтворює голос техдиректора з кількох його опорних текстів, а стиль видання – зі швидкого дослідження, і пише чернетку там, де вони перетинаються.
Довіру дають цифри. Агент шукає справжні дані під аргумент – тут це вартість терабайта, яка росте з кожною доплатою за більший накопичувач, – і вбудовує їх у фірмові HTML-графіки, з яких знімають скріншоти, чіткі навіть на retina-екранах. Читабельні дані найбільше впливають на те, чи потрапить такий текст на видне місце: аргумент із картинками доходить до читача там, де суцільна стіна тексту відлякує.
Вірність голосу тримається на правилах: почати з поширеного переконання й розвінчати його, прив’язати кожне твердження до числа чи шляху до файлу, казати «я», коли йдеться про власне спостереження, і «ми», коли про підхід компанії, і завершувати принципом, а не закликом до дії. Перш ніж чернетка потрапить у документ, її звіряють із правилами письма: жодних порожніх заперечень, жодних тверджень про те, чого не можна знати.
Доставка йде двома кроками, саме під них і будували цей шлях: спершу створити документ у теці зовнішніх статей, тоді завантажити текст із простим оформленням – міжрядковий інтервал 1,5, відступ після кожного абзацу, – як і чекає редактор видання. Техдиректор отримує готову чернетку з графіками, які лишається тільки вставити, а не порожню сторінку з терміном здачі.
Що вже працює
- ● 01Укладач брифівшукає внутрішні посилання · надійні сторонні джерела · пошукову видачу, блок «Люди також запитують», конкурентів · заповнює розділи брифу 1–2, розділ 3 лишає авторові
- ● 02Конвеєр статейnormalise → validate → render → validate-format → publish · власний скрипт публікації з підготовкою скріншотів + пробний прогін
- ● 03Автор-тінь для колоноквідтворює голос техдиректора + стиль видання · фірмові графіки HTML→PNG · завантаження в Docs із простим оформленням
- ● 01Шаблон загального посібникакроки по черзі · що робити, коли не працює · блок FAQ
- ● 02Шаблон добіркикартка на кожен інструмент · транспонована порівняльна таблиця · розділ про методику
- ● 03Шаблон порівняннятаблиці можливостей · абзаци з висновком · таблицю не будує, якщо джерело недоступне
- ● 01Німецький глосарійфірмові терміни · правила великої літери · звороти, звичні для мови
- ● 02Іспанський глосарій
- ● 03Російський глосарій
- ● 04Український глосарій
- ● 05Контрольний список із 8 пунктівспрацьовує раніше, ніж перекладена чернетка потрапить до редактора-людини
16 чистих публікацій із 17 у двох авторів. Єдиний раз із попередженням стався, коли автоматика помилилася з типом статті й відправила інструкцію, у плані якої випадково трапилося «vs.», до генератора порівнянь. Перевірка формату впіймала це ще до Drive, виправлення забрало 15 хвилин, а тест не дасть цьому повторитися (commit 6fe500b). Перевірки для того й існують, щоб прогін, де щось пішло не так, обходився дешево.
Три задачі – одні межі
Час справді скоротився, і так воно й лишається: досліджений бриф – за хвилини, від брифу до документа – за 20, колонка голосом техдиректора – з графіками, які лишається вставити. Та найкраще з часом проявляє себе однаковість: три різні задачі, двоє авторів, одні межі – і ніщо ні з чим не змішується. Внутрішнє оформлення не потрапляє в гостьову колонку, а укладач брифів не переписує технічну правду автора. Майстерня завершена в тому сенсі, що нової будови для неї вже не планують; подальші зміни лише уточнюють, як розпізнавати тип статті, і поповнюють глосарії.
Три місяці. Один розробник. Три редакційні задачі, три генератори, два шляхи публікації, переклад чотирма мовами. Бриф за хвилини, опублікований документ за 20, колонка, готова до відправлення, – і так стабільно на 17 статтях двох авторів.
Цей кейс про архітектуру та підходи. Компанію, її техдиректора, сторонні видання й конкретні назви продуктів навмисно знеособлено; тут важить будова системи – три задачі на одній спільній основі, – а не те, чий логотип стоїть на результатах.