May 17, 2026, 11:40 PM
This commit is contained in:
Paweł Domański
@@ -0,0 +1,605 @@
|
||||
Jak to ogarnąć w PaperClip
|
||||
Najkrótsza rekomendacja: jedna firma / workspace w PaperClip, osobny projekt per blog, wspólna biblioteka promptów i szablonów. Personalny blog traktuj jako główny authority hub, a blogi niszowe jako osobne projekty produkcyjne podpięte do tej samej tożsamości autora, taksonomii i pipeline’u.
|
||||
|
||||
Decyzja: jedna firma czy wiele?
|
||||
Wariant rekomendowany
|
||||
Ustaw:
|
||||
|
||||
1 firma / workspace: np. DexterTeam / PaperClip Media Lab
|
||||
|
||||
1 projekt główny: Personal Authority Hub
|
||||
|
||||
1 projekt per blog niszowy:
|
||||
|
||||
AI Agents / OpenClaw
|
||||
|
||||
Self-hosted DevOps
|
||||
|
||||
Databases / DBA
|
||||
|
||||
CMS / WordPress / Ghost
|
||||
|
||||
Paper Models / Papermodels
|
||||
|
||||
To daje najlepszy balans między kontrolą, SEO, promptami i automatyzacją.
|
||||
|
||||
Kiedy jedna firma?
|
||||
Użyj jednej firmy, jeżeli:
|
||||
|
||||
wszystkie blogi są Twoje,
|
||||
|
||||
korzystają z tej samej tożsamości autora,
|
||||
|
||||
mają wspólne zasady E-E-A-T,
|
||||
|
||||
chcesz współdzielić szablony, promptbook, checklisty i workflow,
|
||||
|
||||
chcesz łatwo robić cross-linking między blogami,
|
||||
|
||||
chcesz mieć jedno centrum zarządzania produkcją treści.
|
||||
|
||||
To jest Twój przypadek.
|
||||
|
||||
Kiedy wiele firm?
|
||||
Wiele firm w PaperClip ma sens tylko wtedy, gdy:
|
||||
|
||||
blogi należą do różnych klientów,
|
||||
|
||||
mają różne zespoły, brandy, faktury, dostępy i polityki,
|
||||
|
||||
nie chcesz mieszać danych, promptów ani historii publikacji,
|
||||
|
||||
jeden blog ma działać jako zupełnie niezależny biznes.
|
||||
|
||||
Dla Twojego systemu multi-blogowego wiele firm raczej wprowadzi chaos.
|
||||
|
||||
Czy projekt per blog?
|
||||
Tak. Projekt per blog to najlepszy układ.
|
||||
|
||||
Nie robiłbym jednego wielkiego projektu dla wszystkich blogów, bo po czasie zrobi się bałagan w:
|
||||
|
||||
intencjach SEO,
|
||||
|
||||
tonie głosu,
|
||||
|
||||
promptach,
|
||||
|
||||
linkowaniu,
|
||||
|
||||
kalendarzu publikacji,
|
||||
|
||||
topical authority,
|
||||
|
||||
danych analitycznych,
|
||||
|
||||
checklistach jakości.
|
||||
|
||||
Lepszy układ:
|
||||
|
||||
text
|
||||
Firma: DexterTeam / PaperClip Media Lab
|
||||
|
||||
Projekt 1: Personal Authority Hub
|
||||
Cel: autor, reputacja, portfolio, metodologia, linkowanie do nisz
|
||||
|
||||
Projekt 2: OpenClaw / AI Agents Blog
|
||||
Cel: AI agents, prompt engineering, automatyzacje, OpenClaw
|
||||
|
||||
Projekt 3: Self-hosted DevOps Blog
|
||||
Cel: Docker, VPS, Linux, reverse proxy, monitoring
|
||||
|
||||
Projekt 4: DBA / Database Architecture Blog
|
||||
Cel: Oracle, SQL Server, PostgreSQL, backup, HA, troubleshooting
|
||||
|
||||
Projekt 5: CMS / WordPress / Ghost Blog
|
||||
Cel: CMS, SEO, publikowanie, architektura contentowa
|
||||
|
||||
Projekt 6: Paper Models / Hobby Blog
|
||||
Cel: modele kartonowe, niszowy content hobbystyczny
|
||||
Jak to ustawić krok po kroku
|
||||
Krok 1: Zdefiniuj firmę jako centrum operacyjne
|
||||
W PaperClip utwórz jedną firmę, np.:
|
||||
|
||||
text
|
||||
company:
|
||||
name: DexterTeam Content Network
|
||||
owner_entity: "Twoje imię / marka osobista"
|
||||
main_domain: "personalny-blog.pl"
|
||||
content_model: "hub-and-spoke multi-blog"
|
||||
language: "pl"
|
||||
secondary_language: "en"
|
||||
Firma nie oznacza jednego bloga. Firma oznacza centrum kontroli.
|
||||
|
||||
W firmie trzymaj:
|
||||
|
||||
globalne zasady E-E-A-T,
|
||||
|
||||
główną tożsamość autora,
|
||||
|
||||
politykę AI disclosure,
|
||||
|
||||
listę domen,
|
||||
|
||||
wspólną bibliotekę promptów,
|
||||
|
||||
wspólne szablony frontmatter,
|
||||
|
||||
wspólne style pisania,
|
||||
|
||||
wspólną checklistę publikacji.
|
||||
|
||||
Krok 2: Utwórz projekt główny dla personalnego hubu
|
||||
Projekt:
|
||||
|
||||
text
|
||||
project:
|
||||
name: Personal Authority Hub
|
||||
role: authority_hub
|
||||
domain: "twojadomena.pl"
|
||||
purpose: "Budowa zaufania, reputacji, author entity i centralnej mapy tematów"
|
||||
Ten blog nie powinien być zwykłym blogiem z przypadkowymi wpisami. On ma być warstwą autorytetu.
|
||||
|
||||
Publikuj tam:
|
||||
|
||||
stronę About,
|
||||
|
||||
stronę Uses,
|
||||
|
||||
stronę Projects,
|
||||
|
||||
stronę Now,
|
||||
|
||||
portfolio,
|
||||
|
||||
mapę wszystkich blogów,
|
||||
|
||||
case studies,
|
||||
|
||||
metodologię pracy,
|
||||
|
||||
artykuły opiniotwórcze,
|
||||
|
||||
podsumowania eksperckie,
|
||||
|
||||
linki do blogów niszowych.
|
||||
|
||||
Krok 3: Utwórz osobny projekt dla każdego bloga niszowego
|
||||
Każdy blog powinien mieć własny projekt, np.:
|
||||
|
||||
text
|
||||
project:
|
||||
name: Self-hosted DevOps Blog
|
||||
role: niche_spoke
|
||||
parent_hub: Personal Authority Hub
|
||||
domain: "devops.twojadomena.pl"
|
||||
topical_scope:
|
||||
- Docker
|
||||
- Linux
|
||||
- VPS
|
||||
- Nginx Proxy Manager
|
||||
- monitoring
|
||||
- backups
|
||||
Dla każdego projektu ustaw osobno:
|
||||
|
||||
grupę keywordów,
|
||||
|
||||
topical map,
|
||||
|
||||
tone of voice,
|
||||
|
||||
szablony artykułów,
|
||||
|
||||
częstotliwość publikacji,
|
||||
|
||||
linki do hubu,
|
||||
|
||||
linki do siostrzanych blogów,
|
||||
|
||||
checklistę jakości.
|
||||
|
||||
Krok 4: Nie mieszaj topical authority
|
||||
Największy błąd przy multi-blogu to wrzucanie wszystkiego wszędzie.
|
||||
|
||||
Zasada:
|
||||
|
||||
text
|
||||
Personal hub odpowiada na pytanie: kim jestem i dlaczego warto mi ufać?
|
||||
|
||||
Blog niszowy odpowiada na pytanie: jak rozwiązać konkretny problem w danej dziedzinie?
|
||||
Przykład:
|
||||
|
||||
Artykuł Jak projektuję agentów OpenClaw - personal hub albo AI Agents Blog.
|
||||
|
||||
Artykuł Docker Compose dla n8n, Directus i Listmonk - Self-hosted DevOps Blog.
|
||||
|
||||
Artykuł Backup strategia dla Oracle RMAN i NetWorker - DBA Blog.
|
||||
|
||||
Artykuł Jak skonfigurować Ghost CMS pod multi-author SEO - CMS Blog.
|
||||
|
||||
Krok 5: Zrób wspólną bibliotekę promptów
|
||||
W PaperClip trzymaj jedną globalną bibliotekę promptów, ale podzieloną na warstwy.
|
||||
|
||||
Struktura:
|
||||
|
||||
text
|
||||
/prompts
|
||||
/global
|
||||
00-author-entity.md
|
||||
01-eeat-policy.md
|
||||
02-ai-disclosure.md
|
||||
03-source-verification.md
|
||||
04-internal-linking.md
|
||||
|
||||
/hub
|
||||
hub-positioning-article.md
|
||||
personal-case-study.md
|
||||
project-retrospective.md
|
||||
authority-page.md
|
||||
|
||||
/niche
|
||||
how-to-technical.md
|
||||
comparison-article.md
|
||||
troubleshooting-guide.md
|
||||
listicle-seo.md
|
||||
glossary-entry.md
|
||||
pillar-page.md
|
||||
spoke-article.md
|
||||
|
||||
/quality
|
||||
eeat-review.md
|
||||
geo-review.md
|
||||
seo-review.md
|
||||
schema-review.md
|
||||
final-editorial-check.md
|
||||
Dzięki temu każdy projekt korzysta z tych samych zasad, ale ma własny kontekst.
|
||||
|
||||
Krok 6: Ustal standardowy pipeline dla każdego posta
|
||||
Najlepszy pipeline:
|
||||
|
||||
text
|
||||
1. Topic selection
|
||||
2. Keyword + intent mapping
|
||||
3. Brief generation
|
||||
4. Source research
|
||||
5. Outline
|
||||
6. Draft
|
||||
7. E-E-A-T enrichment
|
||||
8. GEO enrichment
|
||||
9. SEO optimization
|
||||
10. Internal linking
|
||||
11. Schema/frontmatter
|
||||
12. Human review
|
||||
13. Publish
|
||||
14. Measure
|
||||
15. Update prompt memory
|
||||
W PaperClip możesz to rozbić na automaty:
|
||||
|
||||
text
|
||||
pipeline:
|
||||
- topic_research
|
||||
- seo_brief
|
||||
- article_outline
|
||||
- first_draft
|
||||
- eeat_enrichment
|
||||
- geo_blocks
|
||||
- internal_links
|
||||
- metadata_schema
|
||||
- qa_review
|
||||
- publish_ready_export
|
||||
Jakich modeli użyć?
|
||||
Moja rekomendacja: nie jeden model do wszystkiego. Zrób pipeline wielomodelowy.
|
||||
|
||||
Najlepszy podział modeli
|
||||
Strategia, architektura, ważne decyzje
|
||||
Używaj:
|
||||
|
||||
Claude Opus 4.7 - najlepszy do strategii, architektury contentowej, dużych dokumentów, planów, złożonych promptbooków.
|
||||
|
||||
GPT-5.4 - dobry do twardego rozumowania, walidacji logiki, checklist, struktury danych i technicznych decyzji.
|
||||
|
||||
Użycie:
|
||||
|
||||
text
|
||||
content strategy
|
||||
site architecture
|
||||
hub-and-spoke design
|
||||
prompt system design
|
||||
taxonomy design
|
||||
cross-blog linking rules
|
||||
Codzienna produkcja artykułów
|
||||
Używaj:
|
||||
|
||||
Claude Sonnet 4.6 - główny model roboczy do pisania, redakcji, rozbudowy artykułów.
|
||||
|
||||
Gemini 3.1 Pro - dobry jako tańszy model do researchu, streszczeń, wariantów tematów i prostszych briefów.
|
||||
|
||||
Użycie:
|
||||
|
||||
text
|
||||
draft articles
|
||||
rewrite
|
||||
tone adaptation
|
||||
SEO intro
|
||||
FAQ
|
||||
meta descriptions
|
||||
social snippets
|
||||
newsletter summaries
|
||||
Research i źródła
|
||||
Używaj:
|
||||
|
||||
Claude Sonnet 4.6 - gdy research wymaga selekcji i syntezy.
|
||||
|
||||
Gemini 3.1 Pro - gdy robisz dużo szybkich researchy na wiele tematów.
|
||||
|
||||
GPT-5.4 - gdy trzeba sprawdzić spójność argumentów, tabel, zależności i kryteriów.
|
||||
|
||||
Użycie:
|
||||
|
||||
text
|
||||
keyword research
|
||||
source extraction
|
||||
competitor analysis
|
||||
SERP intent analysis
|
||||
GEO source mapping
|
||||
QA, E-E-A-T i GEO review
|
||||
Używaj:
|
||||
|
||||
GPT-5.4 - jako reviewer logiczny i krytyczny.
|
||||
|
||||
Claude Sonnet 4.6 - jako reviewer redakcyjny.
|
||||
|
||||
Claude Opus 4.7 - do okresowego audytu całego systemu.
|
||||
|
||||
Użycie:
|
||||
|
||||
text
|
||||
fact-check checklist
|
||||
E-E-A-T scoring
|
||||
GEO scoring
|
||||
schema validation
|
||||
duplicate intent detection
|
||||
cannibalization review
|
||||
Proponowany stack modeli w PaperClip
|
||||
Ustaw tak:
|
||||
|
||||
text
|
||||
models:
|
||||
strategy_model: Claude Opus 4.7
|
||||
reasoning_review_model: GPT-5.4
|
||||
production_writer_model: Claude Sonnet 4.6
|
||||
research_model: Gemini 3.1 Pro
|
||||
seo_editor_model: Claude Sonnet 4.6
|
||||
qa_model: GPT-5.4
|
||||
Jeżeli chcesz taniej:
|
||||
|
||||
text
|
||||
models_budget:
|
||||
strategy_model: Claude Sonnet 4.6
|
||||
research_model: Gemini 3.1 Pro
|
||||
writer_model: Claude Sonnet 4.6
|
||||
qa_model: Gemini 3.1 Pro
|
||||
Jeżeli chcesz najlepszą jakość:
|
||||
|
||||
text
|
||||
models_quality:
|
||||
strategy_model: Claude Opus 4.7
|
||||
writer_model: Claude Opus 4.7
|
||||
research_model: Claude Sonnet 4.6
|
||||
qa_model: GPT-5.4
|
||||
Jak ustawić projekty w praktyce
|
||||
Minimalny układ na start
|
||||
Nie zaczynaj od 10 blogów. Zacznij od 3 poziomów:
|
||||
|
||||
text
|
||||
1. Personal Authority Hub
|
||||
2. Najważniejszy blog techniczny
|
||||
3. Drugi blog niszowy
|
||||
Dla Ciebie zacząłbym tak:
|
||||
|
||||
text
|
||||
Projekt 1: Personal Authority Hub
|
||||
Projekt 2: OpenClaw / AI Agents
|
||||
Projekt 3: Self-hosted DevOps
|
||||
Dopiero po 4-6 tygodniach dodaj:
|
||||
|
||||
text
|
||||
Projekt 4: Databases / DBA
|
||||
Projekt 5: CMS / WordPress / Ghost
|
||||
Projekt 6: Paper Models
|
||||
Krok 7: Każdy projekt powinien mieć własny plik konfiguracyjny
|
||||
Przykład:
|
||||
|
||||
text
|
||||
project_id: openclaw_ai_agents
|
||||
project_type: niche_blog
|
||||
parent_hub: personal_authority_hub
|
||||
|
||||
domain:
|
||||
production: "ai.twojadomena.pl"
|
||||
staging: "staging-ai.twojadomena.pl"
|
||||
|
||||
content:
|
||||
language: "pl"
|
||||
tone: "techniczny, praktyczny, ekspercki, bez lania wody"
|
||||
audience:
|
||||
- developerzy
|
||||
- DevOps
|
||||
- twórcy agentów AI
|
||||
- osoby self-hostujące automatyzacje
|
||||
|
||||
seo:
|
||||
primary_topics:
|
||||
- OpenClaw
|
||||
- AI agents
|
||||
- prompt engineering
|
||||
- automatyzacja LLM
|
||||
- self-hosted AI
|
||||
excluded_topics:
|
||||
- ogólne newsy AI bez praktyki
|
||||
- recenzje bez testów
|
||||
- clickbait
|
||||
|
||||
eeat:
|
||||
author_entity: "main_author"
|
||||
requires_first_hand_experience: true
|
||||
requires_disclosure: true
|
||||
requires_sources: true
|
||||
|
||||
geo:
|
||||
requires_summary_box: true
|
||||
requires_faq: true
|
||||
requires_definitions: true
|
||||
requires_comparison_table: true
|
||||
requires_evidence_pack: true
|
||||
Krok 8: Zrób globalny author entity
|
||||
To powinno być wspólne dla wszystkich projektów.
|
||||
|
||||
text
|
||||
author_entity:
|
||||
id: main_author
|
||||
name: "Twoje imię i nazwisko / marka"
|
||||
role:
|
||||
- Full-stack developer
|
||||
- DevOps engineer
|
||||
- Database administrator
|
||||
- CMS specialist
|
||||
- AI automation builder
|
||||
experience:
|
||||
- "25+ lat Oracle i SQL Server"
|
||||
- "WordPress, Ghost, CMS"
|
||||
- "Docker, VPS, Linux"
|
||||
- "OpenClaw, PaperClip, agent systems"
|
||||
same_as:
|
||||
- "GitHub"
|
||||
- "LinkedIn"
|
||||
- "personal blog"
|
||||
- "project pages"
|
||||
Każdy blog niszowy powinien linkować do tego samego author entity.
|
||||
|
||||
Krok 9: Zrób reguły linkowania
|
||||
Przykład:
|
||||
|
||||
text
|
||||
linking_rules:
|
||||
personal_hub_to_niche:
|
||||
allowed:
|
||||
- pillar pages
|
||||
- best guides
|
||||
- project pages
|
||||
- case studies
|
||||
avoid:
|
||||
- linking to every generated post
|
||||
- sitewide footer spam
|
||||
|
||||
niche_to_personal_hub:
|
||||
allowed:
|
||||
- author bio
|
||||
- methodology
|
||||
- about
|
||||
- disclosure
|
||||
- related case study
|
||||
|
||||
niche_to_niche:
|
||||
allowed:
|
||||
- only when contextually useful
|
||||
- only with descriptive anchor
|
||||
- max 1-3 links per article
|
||||
To jest ważne, bo multi-blog może łatwo wyglądać jak sieć sztucznego linkowania. Chcesz, żeby wyglądało jak logiczny system ekspercki.
|
||||
|
||||
Krok 10: Ustal typy treści dla każdego bloga
|
||||
Dla każdego projektu zrób katalog typów wpisów.
|
||||
|
||||
Przykład dla bloga DevOps:
|
||||
|
||||
text
|
||||
content_types:
|
||||
- troubleshooting_guide
|
||||
- docker_compose_walkthrough
|
||||
- architecture_note
|
||||
- migration_case_study
|
||||
- tool_comparison
|
||||
- checklist
|
||||
- glossary_entry
|
||||
Przykład dla bloga AI Agents:
|
||||
|
||||
text
|
||||
content_types:
|
||||
- agent_design_note
|
||||
- prompt_pattern
|
||||
- openclaw_plugin_walkthrough
|
||||
- model_comparison
|
||||
- automation_pipeline
|
||||
- failure_analysis
|
||||
Przykład dla personalnego hubu:
|
||||
|
||||
text
|
||||
content_types:
|
||||
- personal_case_study
|
||||
- project_retrospective
|
||||
- expert_position
|
||||
- portfolio_update
|
||||
- methodology_note
|
||||
- monthly_build_log
|
||||
Moja docelowa architektura dla Ciebie
|
||||
Zrobiłbym tak:
|
||||
|
||||
text
|
||||
Firma:
|
||||
DexterTeam Content Network
|
||||
|
||||
Shared layer:
|
||||
author entity
|
||||
AI disclosure policy
|
||||
E-E-A-T checklist
|
||||
GEO checklist
|
||||
prompt library
|
||||
schema templates
|
||||
link policy
|
||||
source policy
|
||||
|
||||
Projects:
|
||||
1. Personal Authority Hub
|
||||
2. OpenClaw / AI Agents
|
||||
3. Self-hosted DevOps
|
||||
4. Database Engineering
|
||||
5. CMS / WordPress / Ghost
|
||||
6. Paper Models
|
||||
Najważniejsza zasada
|
||||
Nie traktuj blogów jako oddzielnych silosów. Traktuj je jako jeden system wiedzy z osobnymi frontami tematycznymi.
|
||||
|
||||
Czyli:
|
||||
|
||||
text
|
||||
Jedna firma.
|
||||
Jedna tożsamość autora.
|
||||
Wiele projektów.
|
||||
Jeden wspólny promptbook.
|
||||
Osobne topical maps.
|
||||
Osobne pipeline’y publikacji.
|
||||
Wspólne QA i E-E-A-T.
|
||||
Co bym zrobił jako następny krok
|
||||
Najpierw zbudowałbym Ci plik:
|
||||
|
||||
text
|
||||
paperclip-multiblog-architecture.md
|
||||
Zawartość:
|
||||
|
||||
struktura firmy,
|
||||
|
||||
lista projektów,
|
||||
|
||||
konfiguracja YAML per blog,
|
||||
|
||||
globalny author entity,
|
||||
|
||||
prompt routing,
|
||||
|
||||
model routing,
|
||||
|
||||
pipeline publikacji,
|
||||
|
||||
reguły linkowania,
|
||||
|
||||
checklisty E-E-A-T i GEO.
|
||||
|
||||
Chcesz, żebym od razu przygotował taki gotowy plik .md do wklejenia do PaperClip jako blueprint?
|
||||
Reference in New Issue
Block a user