Zaawansowane techniki Claude Code

Poziom 5 Poradnik Zaktualizowano 2026-10-12

Zaawansowane techniki Claude Code to pięć dźwigni wykraczających poza codzienne promptowanie: poziom effort, który ustala głębię rozumowania, serwery MCP dające agentowi dostęp do GitHuba i baz danych, własne narzędzie MCP dla skryptów zespołu, automatyczna recenzja pull requestów w GitHub Actions oraz git worktree dla izolowanych sesji równoległych. Każda wymaga własnej bramki weryfikacji.

Ta strona jest dla programistów, którzy już codziennie pracują z Claude Code, i dla tech leadów, którzy chcą, żeby te nawyki działały w całym zespole. Sytuacja jest znajoma: agent odpowiada na trudne pytanie projektowe dwoma płytkimi akapitami, .mcp.json skopiowany z bloga nigdy się nie łączy, a cztery niezależne zadania czekają w kolejce, bo uruchamiasz jedną sesję naraz.

Co dają ci zaawansowane techniki Claude Code

Sposób na zwiększenie głębi rozumowania przez /effort i --effort zamiast zgadywania magicznych słów.
.mcp.json z GitHubem, bazą danych tylko do odczytu i przeglądarką, który ładuje się za pierwszym razem, oraz polecenie, które to potwierdza.
Przetestowany własny serwer MCP, który opakowuje jeden z twoich skryptów i waliduje dane wejściowe.
Workflow GitHub Actions, który publikuje recenzję Claude przy każdym pull requeście i odpowiada na wzmianki @claude.
Sposób pracy z worktree dla trzech lub czterech równoległych sesji, które nie mogą nadpisać sobie nawzajem plików.
Bramkę weryfikacji dla każdej techniki, dzięki której sprawdzasz wynik testami i kontrolami, a nie czytaniem każdej linii.

Która zaawansowana technika rozwiązuje który problem?

Objaw	Technika	Szczegółowy przewodnik
Odpowiedzi na trudne problemy są płytkie	Wyższy poziom effort	Głębokie rozumowanie
Ręcznie wklejasz do promptu treść zgłoszeń, schematy lub logi	Serwery MCP	Konfiguracja MCP
Żaden gotowy serwer nie obsługuje twojego skryptu wdrożeniowego ani wewnętrznego API	Własne narzędzie MCP	Tworzenie własnych serwerów MCP
Pull requesty czekają dniami na pierwszą recenzję	Recenzja Claude w GitHub Actions	Automatyzacja code review
Równoległe sesje edytują te same pliki	Jeden git worktree na zadanie	Kontrola wersji

Poniższe sekcje opisują to, czego nie ma w dokumentacji producenta: kolejność kroków, pułapki i sposób weryfikacji wyniku.

Zwiększ głębię rozumowania poziomem effort, a nie sformułowaniem promptu

Claude Code steruje głębią rozumowania poziomem effort: low, medium, high, xhigh lub max (Claude Code v2.1.283). Opus 5.5 jest modelem domyślnym od v2.1.280 i domyślnie działa na poziomie medium, tak samo jak Sonnet 5.5 i Haiku 5.5; Opus 4.7 domyślnie używa xhigh, a większość pozostałych aktualnych modeli high. Domyślne modele dla planów i dostawców znajdziesz w przeglądzie modeli.

Ustaw poziom w sposób, który odpowiada temu, jak długo ma obowiązywać:

# W terminalu: jedna sesja na wybranym poziomie
claude --effort xhigh

# W terminalu: każda sesja z tej powłoki (nadpisuje zapisane ustawienie)
export CLAUDE_CODE_EFFORT_LEVEL=high

# W prompcie Claude Code: zmiana w trakcie sesji (zapisywana osobno dla każdego modelu)
/effort high

W prompcie działają dwa słowa kluczowe. ultrathink prosi o głębsze rozumowanie w tej jednej turze i nie zmienia poziomu effort sesji. /effort ultracode włącza automatyczną orkiestrację workflow na bieżącym poziomie effort sesji (od v2.1.284) w bieżącej sesji; zanim go użyjesz, przeczytaj o dynamicznych workflow, bo może uruchomić wielu agentów. Zwroty w rodzaju „think hard” to zwykły tekst i niczego nie zmieniają.

Trzymaj się reguły, którą stosujemy w całym serwisie: najpierw dostrój effort, dopiero potem zmieniaj model. Dokumentacja konfiguracji modeli Claude Code podaje: „In Anthropic’s testing, Opus 5.5 at medium matches or exceeds Opus 5 at high on coding and knowledge-work evaluations” (twierdzenie samego Anthropic, sprawdzone 2026-09-26), więc zanim sięgniesz po Claude Fable 5.1, spróbuj high lub xhigh na modelu domyślnym. Wyższy effort zużywa więcej tokenów, więc po trudnej części wróć do ustawienia domyślnego; jak to śledzić, pokazuje strona o kontroli kosztów.

Effort ustala, jak długo model rozumuje. Strukturę rozumowania nadaje prompt, a najbardziej użyteczna struktura kończy się sprawdzianem, który możesz uruchomić.

We are choosing between one multi-tenant Postgres database with
row-level security and a database per tenant. Before you recommend one:

1. List the failure modes of each at 10, 100 and 1,000 tenants.
2. Compare them on data isolation, noisy-neighbor risk, migration cost
   and per-tenant backup and restore.
3. Recommend one for a B2B SaaS with about 50 tenants today that expects
   10x growth in two years, and name the single biggest risk.
4. Write three acceptance tests, in plain language, that would prove
   tenant A can never read tenant B's rows under your recommendation.

Do not write code yet. Give me the decision, the reasoning and the tests.

Czwarty krok to bramka weryfikacji: oceniasz trzy testowalne stwierdzenia, a nie dwie strony wywodu.

Podłącz serwery MCP, które ładują się za pierwszym razem

Serwery MCP dają Claude Code ustrukturyzowany dostęp do GitHuba, baz danych i przeglądarek, więc prosisz o wynik, zamiast wklejać kontekst. Większość nieudanych konfiguracji wynika z trzech błędów: złego klucza najwyższego poziomu, polecenia stdio tam, gdzie powinien być adres HTTP, i zarchiwizowanych pakietów referencyjnych.

Dodawaj serwery w zakresie projektu, żeby cały zespół dzielił je przez .mcp.json:

# W terminalu, w katalogu głównym repozytorium
claude mcp add -s project --transport http github https://api.githubcopilot.com/mcp/ \
  -H 'Authorization: Bearer ${GITHUB_PAT}'
claude mcp add -s project playwright -- npx -y @playwright/mcp@latest
claude mcp add -s project dbhub -- npx -y @bytebase/dbhub@latest \
  --transport stdio --dsn '${DATABASE_URL_READONLY}'

Te trzy polecenia zapisują poniższy plik (przetestowane na Claude Code 2.1.283). Apostrofy zostawiają ${GITHUB_PAT} i ${DATABASE_URL_READONLY} dosłownie, więc Claude Code rozwija je ze środowiska każdego programisty i żaden sekret nie trafia do gita:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"],
      "env": {}
    },
    "dbhub": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@bytebase/dbhub@latest", "--transport", "stdio", "--dsn", "${DATABASE_URL_READONLY}"],
      "env": {}
    }
  }
}

Szczegóły, od których zależy, czy to zadziała:

Klucz to mcpServers. Plik z kluczem servers nie przechodzi parsowania. Claude Code 2.1.283 zgłasza w claude mcp list błąd Missing "mcpServers" — found "servers" instead i nie ładuje niczego z tego pliku.
Serwery HTTP wymagają --transport http. Bez tej flagi claude mcp add przyjmuje adres URL jako polecenie stdio, a serwer pada przy łączeniu.
Serwery projektu czekają na akceptację. Każdy programista widzi nowy serwer z .mcp.json jako oczekujący, dopóki nie zatwierdzi go w sesji.
Pomiń zarchiwizowane serwery referencyjne. @modelcontextprotocol/server-postgres i @modelcontextprotocol/server-puppeteer są oznaczone w npm jako „no longer supported” (sprawdzone 2026-09-26). Do baz danych użyj DBHub (@bytebase/dbhub, 1.3.1) albo serwera producenta, a do przeglądarki @playwright/mcp (0.0.82). Przewodnik po MCP dla baz danych porównuje opcje, a strona o GitHub MCP opisuje adresy tylko do odczytu i dla poszczególnych zestawów narzędzi.
Ograniczaj uprawnienia, nie prompty. Niech DATABASE_URL_READONLY wskazuje rolę bazodanową, która może wykonywać tylko SELECT, a token GitHuba obejmuje tylko te repozytoria i uprawnienia, których potrzebuje workflow. Serwer z poświadczeniami tylko do odczytu nie zapisze niczego, cokolwiek powie prompt.

Po każdej zmianie uruchom claude mcp list. Polecenie sprawdza każdy zatwierdzony serwer i wypisuje błędy parsowania z sugerowaną poprawką, co jest najszybszym dowodem, że konfiguracja jest poprawna.

Using the dbhub MCP server, help me understand this database before I
change anything:

1. List every table with its approximate row count.
2. For the orders table, show columns, indexes and foreign keys.
3. Find any query in src/db/queries.ts that would scan a large table
   sequentially, and show the EXPLAIN output that proves it.
4. Propose the index that fixes it and the EXPLAIN you expect afterwards.

Run read-only queries only. If a statement would write, stop and ask.

Każde twierdzenie w odpowiedzi wskazuje wynik EXPLAIN, który możesz porównać, więc sprawdzasz plan zapytania, a nie wierzysz na słowo.

Zbuduj własne narzędzie MCP dla skryptów zespołu

Własny serwer buduj wtedy, gdy żaden opublikowany nie pasuje: skrypt wdrożeniowy, wewnętrzne API, firmowe CLI. Oficjalne SDK dla TypeScriptu to @modelcontextprotocol/sdk (1.30.1 w npm, sprawdzone 2026-09-26). Ten sam projekt publikuje też nowszy, podzielony pakiet @modelcontextprotocol/server (2.1.0); przykład poniżej używa stabilnego API v1. Pełny przewodnik znajdziesz na stronie o tworzeniu własnych serwerów MCP.

Zainstaluj SDK i zod w repozytorium:
Okno terminala
```
npm install @modelcontextprotocol/sdk zod
```

Zapisz serwer jako tools/deploy-mcp-server.mjs. Waliduje nazwę gałęzi, zanim cokolwiek się uruchomi, wywołuje istniejący skrypt bez powłoki i zgłasza błędy przez isError, żeby agent je widział. Wzorzec wymaga na początku znaku słowa, więc wartość taka jak --force nie trafi do skryptu jako opcja:

import { execFile } from 'node:child_process';
import { promisify } from 'node:util';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const run = promisify(execFile);
const server = new McpServer({ name: 'project-tools', version: '1.0.0' });

server.registerTool(
  'deploy_staging',
  {
    description: 'Deploy an existing git branch to staging. Returns the script output.',
    inputSchema: { branch: z.string().regex(/^\w[\w./-]*$/) },
  },
  async ({ branch }) => {
    try {
      const { stdout } = await run('./scripts/deploy-staging.sh', [branch], { timeout: 600_000 });
      return { content: [{ type: 'text', text: stdout }] };
    } catch (err) {
      return { isError: true, content: [{ type: 'text', text: String(err) }] };
    }
  },
);

await server.connect(new StdioServerTransport());

Zarejestruj go dla całego zespołu:

claude mcp add -s project project-tools -- node ./tools/deploy-mcp-server.mjs

Uruchom claude mcp list i potwierdź, że project-tools się łączy, a potem poproś Claude Code: „deploy the current branch to staging”.

Przetestowaliśmy ten serwer z SDK 1.30.1 i zod 4.6.5 26 września 2026 r.: gałąź feat/x zwraca wynik skryptu, a wejścia x; rm -rf / i --force wracają jako isError: true z błędem Input validation error, zanim skrypt się uruchomi. Trzymaj się tego wzorca. Schemat jest pierwszym zabezpieczeniem, execFile bez powłoki drugim, a pytanie o uprawnienie do narzędzia mcp__project-tools__deploy_staging trzecim.

Uruchom recenzję Claude przy każdym pull requeście

GitHub Action anthropics/claude-code-action@v1 uruchamia Claude Code w twoim CI. Potrzebujesz dwóch workflow: jednego, który recenzuje każdy pull request, i drugiego, który odpowiada na wzmianki @claude w komentarzach.

Uruchom instalator w prompcie Claude Code. Instaluje aplikację GitHub, zapisuje sekret ANTHROPIC_API_KEY i tworzy dwa workflow: claude.yml dla wzmianek i claude-code-review.yml dla automatycznych recenzji:
```
/install-github-app
```

Zaostrz wygenerowany workflow recenzji. Zadanie recenzji potrzebuje pull-requests: write i jawnych uprawnień do narzędzi, inaczej kończy się, niczego nie publikując:

name: Claude review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 1
          persist-credentials: false
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}
            Review this PR. Report only defects: security, correctness,
            missing error handling, missing tests for changed behaviour.
            For each finding give file, line, the failing input and a fix.
            Skip style. If you find nothing, say so in one line.
          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Zostaw workflow wzmianek, .github/workflows/claude.yml. Reaguje na zdarzenia issue_comment, pull_request_review_comment, pull_request_review i issues, dzięki czemu działa komentarz taki jak ten:
```
@claude check the migration in this PR for backwards compatibility with the v2 API clients
```

Zostaw domyślne zachowanie akcji, w którym uruchomić ją mogą tylko użytkownicy z prawem zapisu do repozytorium. Nie ustawiaj allowed_non_write_users w zadaniu, które może zapisywać, a w allowed_bots wymieniaj zaufane boty z nazwy zamiast '*'.
Nigdy nie przełączaj workflow recenzji na pull_request_target z checkoutem gałęzi źródłowej pull requesta do katalogu roboczego: kod kontrybutora działałby wtedy obok twoich sekretów. Uwagi o bezpieczeństwie akcji pokazują bezpieczny układ, z kodem z gałęzi pull requesta (head) w podkatalogu przekazanym przez --add-dir.
W pull requestach akcja przywraca .claude/, .mcp.json i CLAUDE.md z gałęzi bazowej, ale package.json, pliki lock i Makefile zostają w wersji z pull requesta. Hook z gałęzi bazowej, który wywołuje npm run … albo make …, wykonuje więc kod dostarczony przez pull request; wywołuj zamiast tego bezpośrednio narzędzia w przypiętej wersji.

Wejścia prompt i claude_args to nazwy z v1; wejścia direct_prompt z wersji v0.x nie ma w action.yml wersji v1 (sprawdzone 2026-09-26). Projektowanie recenzji, koszty i ograniczanie szumu opisuje strona o automatyzacji code review, a to, jak zespół recenzuje pull requesty agentów na podstawie dowodów, strona o recenzji PR-ów agentów.

Recenzja Claude to drugi sygnał, nigdy bramka scalenia. Bramką pozostają wymagane kontrole (testy, sprawdzanie typów, lint), a decyzja o scaleniu należy do człowieka.

Uruchamiaj równoległe zadania w izolowanych git worktree

Daj każdemu niezależnemu zadaniu osobny git worktree, żeby równoległe sesje nigdy nie dzieliły katalogu roboczego. --add-dir tego nie robi: dodaje katalogi do jednej sesji.

# Terminal 1
claude --worktree feature-notifications
# Terminal 2, z własną sesją tmux
claude --worktree hotfix-auth-timeout --tmux

Każdy worktree trafia do .claude/worktrees/<name>/ na nową gałąź o nazwie worktree-<name>. Przed pierwszym uruchomieniem:

Dodaj .claude/worktrees/ do .gitignore.
Utwórz w katalogu głównym repozytorium plik .worktreeinclude w składni .gitignore, z listą plików ignorowanych przez git, których potrzebuje każda świeża kopia, na przykład .env.local (kopiowane są tylko pliki, które pasują do wzorca i są ignorowane przez git).
Uruchom raz zwykłe claude w repozytorium, żeby ustawić zaufanie do przestrzeni roboczej.

Gdy interaktywna sesja w worktree się kończy, Claude Code automatycznie usuwa czysty worktree, a o worktree ze zmianami pyta, czy go zachować, czy usunąć. Uruchomienia bezobsługowe (claude -p --worktree) zostawiają worktree na miejscu i zablokowany; w razie potrzeby uruchom git worktree unlock <ścieżka>, a potem git worktree remove <ścieżka>. Dla konkretnej istniejącej gałęzi użyj gita bezpośrednio: git worktree add ../app-hotfix hotfix/auth-timeout, a potem uruchom w nim claude.

Żeby automatycznie rozdzielić jedną dużą zmianę, użyj wbudowanego skilla /batch: dzieli ją na 5 do 30 części, a każdą wykonuje subagent w tle we własnym worktree. Żeby obserwować kilka sesji naraz, zobacz widok agentów albo tmux dla floty agentów.

This worktree is dedicated to one task: the auth timeout hotfix.

1. Reproduce the timeout with the failing test in tests/auth/ and show
   me the failure output before changing anything.
2. Find the root cause. Do not patch symptoms or raise timeouts.
3. Implement the smallest fix and run the auth tests, then the full suite.
4. Write a conventional commit message that names the root cause.

Do not touch files outside src/auth/ and tests/auth/. If the fix needs
changes elsewhere, stop and tell me why.

Krok z testem, który najpierw nie przechodzi, daje ci zapis „czerwone, potem zielone” do sprawdzenia zamiast diffa.

Jak zweryfikować wynik bez czytania każdej linii?

Każda technika przyspiesza agenta; ta tabela mówi, co dowodzi poprawności wyniku i kto go zatwierdza.

Technika	Bramka weryfikacji	Kto zatwierdza
Wyższy effort	Testy akceptacyjne napisane przed kodem, potem uruchomione	Programista, który odpowiada za zmianę
Serwery MCP	`claude mcp list` bez błędów; poświadczenia tylko do odczytu; wywołania narzędzi widoczne w transkrypcie	Programista; tech lead zatwierdza wspólny `.mcp.json`
Własne narzędzie MCP	Schemat odrzuca złe wejście; `isError` przy błędzie; pytanie o uprawnienie przed każdym wywołaniem	Tech lead recenzuje serwer raz, a nie każde wywołanie
Recenzja w CI	Wymagane kontrole pozostają bramką scalenia; każde znalezisko wskazuje plik, linię i wejście, które psuje kod	Człowiek, który scala
Worktree	Każda gałąź przechodzi CI we własnym pull requeście	Programista, dla każdego pull requesta

Zbierz wyniki w jeden zapis na pull request, tak jak opisuje to pakiet dowodów. Recenzent sprawdza wtedy dowody i czyta kod tylko tam, gdzie dowodu brakuje albo kontrola nie przeszła.

Kiedy zaawansowane techniki Claude Code zawodzą

Odpowiedzi pozostają płytkie na każdym poziomie effort. Uruchom /effort, żeby zobaczyć bieżący poziom; ustawienie organizacji maxEffortLevel może go ograniczać. Jeśli xhigh nadal nie wystarcza, problemem jest zwykle brak kontekstu, a nie głębi: dodaj przez MCP test, który nie przechodzi, logi lub schemat i spróbuj ponownie.

CLAUDE_CODE_EFFORT_LEVEL wydaje się ignorowane. Zmienna nadpisuje zapisany effort tylko w sesjach uruchomionych z tej powłoki. Uruchom echo $CLAUDE_CODE_EFFORT_LEVEL w terminalu, z którego startujesz Claude Code, i pamiętaj, że zmiany przez /effort są zapisywane osobno dla każdego modelu.

Serwer MCP się nie ładuje. Uruchom claude mcp list i przeczytaj diagnostykę. Sprawdź klucz mcpServers, --transport http przy serwerach z adresem URL i to, czy serwer projektu nadal czeka na akceptację. Serwer stdio uruchom samodzielnie przez npx w terminalu; logi startowe zobaczysz po uruchomieniu claude --debug. Resztę przypadków opisuje strona o problemach z połączeniem MCP.

Własne narzędzie nie zwraca nic użytecznego. Sprawdź, czy handler zwraca { content: [...] } i ustawia isError przy błędzie; rzucony wyjątek albo goły obiekt zostawia agenta w domysłach. Najpierw przetestuj skrypt poza MCP.

Zadanie recenzji działa, ale niczego nie publikuje. Dodaj pull-requests: write do permissions oraz narzędzia gh pr comment i komentarzy inline do --allowedTools. Jeśli wzmianki @claude pozostają bez odpowiedzi, brakuje workflow wzmianek, sekretu ANTHROPIC_API_KEY albo autor komentarza nie ma prawa zapisu do repozytorium.

Zadanie recenzji pada w pull requestach z forków. GitHub nie przekazuje sekretów repozytorium do uruchomień pull_request z forków, więc akcja nie ma klucza API. Zostaw to tak, zamiast przechodzić na pull_request_target; opiekun repozytorium może poprosić o recenzję komentarzem @claude po przeczytaniu zmiany.

Równoległe sesje nadal się zderzają. Dzielą katalog. Uruchamiaj każdą z --worktree, a nie z --add-dir, i sprawdź stan przez git worktree list. Jeśli w worktree brakuje plików .env, dodaj je do .worktreeinclude.

Dokąd dalej po zaawansowanych technikach Claude Code

Wymuszaj te bramki automatycznie za pomocą hooków.
Powtarzalne role przekaż własnym subagentom.
Uruchamiaj Claude Code bezobsługowo i według harmonogramu dzięki automatyzacji.
Wdróż tę konfigurację w zespole, korzystając z pracy zespołowej.
Porównaj te same dźwignie w innych narzędziach: zaawansowane techniki Codex i zaawansowane techniki Cursora.