Współpraca zespołowa

Twój zespół ośmiu inżynierów używa Cursora, ale jakość wyników jest bardzo zróżnicowana. Trasy API jednego dewelopera zawierają prawidłową obsługę błędów, walidację i logowanie. Trasy innego dewelopera w ogóle nie mają obsługi błędów. Trzeci deweloper ciągle dostaje kod używający var zamiast const, ponieważ jego osobiste reguły nadpisują ustawienia projektu. Nie ma wspólnego standardu, jak zespół korzysta z AI, a niespójność tworzy więcej pracy przy przeglądzie kodu, nie mniej.

Skalowanie programowania wspomaganego AI w zespole wymaga wspólnych reguł, skoordynowanych workflow i spójnej konfiguracji. Ten artykuł obejmuje funkcje i praktyki specyficzne dla Cursora, które sprawiają, że zespołowa adopcja AI działa.

Czego się nauczysz

• Strategia budowania i utrzymywania wspólnych .cursor/rules/ w zespole
• Konfiguracja reguł zespołowych dla planów Team i Enterprise
• Niestandardowe polecenia standaryzujące typowe workflow zespołowe
• Praktyki przeglądu kodu dostosowane do kodu generowanego przez AI

Wspólne reguły projektu przez kontrolę wersji

Najważniejszy krok dla spójności zespołu: dodaj katalog .cursor/rules/ do kontroli wersji. Każda reguła w tym katalogu jest dostępna dla każdego dewelopera, który sklonuje repozytorium.

Budowanie wspólnej biblioteki reguł

Zacznij od trzech podstawowych reguł, które powinien mieć każdy zespół:

Wskazówka

Reguły do skopiowania — starter dla spójności zespołu:

Utwórz .cursor/rules/project-standards.mdc:

---
alwaysApply: true
---

Project: [Your project name]
Stack: [Your tech stack]

Code standards:
- TypeScript strict mode, no `any` types
- All public functions must have JSDoc comments
- Error handling: use AppError from @src/lib/errors.ts
- Logging: use logger from @src/lib/logger.ts, never console.log
- Tests: Vitest, test files adjacent to source

When creating new files, check for existing patterns before inventing new ones.
Reference @src/routes/users.ts for API patterns.
Reference @src/components/UserProfile.tsx for component patterns.

Własność reguł i utrzymanie

Traktuj reguły jak kod: wymagają utrzymania. Praktyczne podejście:

• Przegląd reguł w PR-ach: Gdy ktoś dodaje lub modyfikuje regułę, przechodzi ten sam proces przeglądu co kod
• Aktualizacja reguł z błędów: Gdy przegląd kodu wyłapie wzorzec, który agent źle zastosował, zaktualizuj odpowiednią regułę, aby zapobiec powtórzeniu
• Kwartalny audyt reguł: Przejrzyj wszystkie reguły, aby usunąć przestarzałe informacje i dodać nowe wzorce

Wskazówka

Prompt do skopiowania — utrzymanie reguł:

Review the rules in @.cursor/rules/ and identify:
1. Rules that reference files or patterns that no longer exist in the codebase
2. Rules that contradict each other
3. Patterns we use frequently that are not documented in any rule
4. Rules that are too long (over 200 lines) and should be split

Output a summary of recommended changes.

Reguły zespołowe (zarządzane z panelu)

Plany Team i Enterprise Cursora oferują reguły zespołowe, zarządzane centralnie z panelu Cursor. Reguły te stosują się do wszystkich członków zespołu we wszystkich projektach.

Kiedy użyć reguł zespołowych vs. reguł projektu

Przypadek użycia	Reguły zespołowe	Reguły projektu
Standardy kodowania obowiązujące w całej organizacji	Tak	Nie
Wymagania bezpieczeństwa i compliance	Tak	Nie
Wzorce architektury specyficzne dla projektu	Nie	Tak
Konwencje specyficzne dla technologii	Nie	Tak
Preferencje stylu komunikacji	Tak	Nie

Konfiguracja reguł zespołowych

1. Otwórz panel Cursor pod adresem cursor.com/dashboard
2. Przejdź do zakładki zawartości zespołu
3. Kliknij “Add Rule”, aby utworzyć nową regułę zespołową
4. Napisz regułę jako zwykły tekst (reguły zespołowe nie wspierają wzorców glob ani metadanych)
5. Wybierz, czy wymusić regułę (uniemożliwiając członkom zespołu jej wyłączenie)
6. Włącz regułę, aby ją aktywować

Kolejność priorytetów

Reguły zespołowe mają najwyższy priorytet: Reguły zespołowe > Reguły projektu > Reguły użytkownika. Oznacza to, że wymuszona reguła zespołowa nadpisuje wszelkie sprzeczne reguły projektu lub użytkownika. Używaj tego dla standardów, które muszą być spójne, jak praktyki bezpieczeństwa i wzorce obsługi błędów.

Niestandardowe polecenia dla workflow zespołowych

Niestandardowe polecenia slash pozwalają tworzyć wielokrotnego użytku workflow wyzwalane prefiksem /. Przechowuj je w .cursor/commands/, a będą dostępne dla całego zespołu.

Przykład: Polecenie przeglądu kodu zespołu

Utwórz .cursor/commands/review.md:

---
description: Review code changes for quality, security, and consistency
---

Review the current changes (use git diff to see them) and check for:

1. **Security**: SQL injection, XSS, hardcoded secrets, missing auth checks
2. **Error handling**: All async operations have try/catch, errors use AppError format
3. **Testing**: New logic has corresponding tests, edge cases are covered
4. **Patterns**: Code follows existing patterns in the codebase (check similar files)
5. **Performance**: No N+1 queries, no unnecessary re-renders, no blocking operations

For each issue found, provide:
- The file and line number
- What the issue is
- A specific fix

Use only search tools -- do not make any edits.

Deweloperzy wywołują to poleceniem /review w polu czatu.

Przykład: Polecenie opisu PR zespołu

Utwórz .cursor/commands/pr-description.md:

---
description: Generate a PR description from current changes
---

Analyze the current branch changes (compare against main) and generate a PR description with:

1. **Summary**: 2-3 sentence overview of what changed and why
2. **Changes**: Bulleted list of specific changes, organized by area
3. **Testing**: How these changes were tested
4. **Migration notes**: Any database changes, environment variable additions, or breaking changes

Use git diff main...HEAD to see all changes. Do not make any edits.

Praktyki przeglądu kodu generowanego przez AI

Kod generowany przez AI wymaga innej perspektywy przeglądu niż kod pisany ręcznie. Agent jest dobry w przestrzeganiu wzorców, ale może przeoczyć subtelną logikę biznesową, wprowadzić podatności bezpieczeństwa i nadmiernie skomplikować proste rozwiązania.

Na co uważać w PR-ach z kodem AI

• Zmyślone importy: Agent może importować pakiety, których nie ma w twoich zależnościach
• Niespójne wzorce: Agent może zastosować inny wzorzec niż istniejący, szczególnie gdy reguły są niekompletne
• Brakujące przypadki brzegowe: AI zwykle dobrze obsługuje szczęśliwą ścieżkę, ale pomija ścieżki błędów
• Nadmierna inżynieria: Agent może dodać abstrakcje, caching lub obsługę błędów, których funkcja jeszcze nie potrzebuje
• Luki bezpieczeństwa: SQL injection przez konkatenację stringów, brakujące sprawdzenia autoryzacji, zahardkodowane poświadczenia testowe pozostawione w kodzie produkcyjnym

Wskazówka

Prompt do skopiowania — samorecenzja przed złożeniem PR:

Before I submit this PR, review all my changes and check for:

1. Any imports of packages not in package.json
2. Any TODO comments or placeholder values I need to fill in
3. Any console.log statements that should use the logger
4. Any hardcoded URLs, API keys, or test values
5. Any missing error handling on async operations
6. Any new files that are missing test coverage

Run `npm run build` and `npm test` to verify everything passes.

Wdrażanie nowych członków zespołu

Gdy nowy deweloper dołącza do zespołu, jego doświadczenie z Cursorem powinno działać dobrze od pierwszego dnia:

1. Klonuje repozytorium (które zawiera .cursor/rules/ i .cursor/commands/)
2. Reguły zespołowe z panelu stosują się automatycznie
3. Wskaż mu README projektu dla kontekstu architektonicznego
4. Niech przeprowadzi jedno zadanie w trybie Ask, aby najpierw zrozumieć bazę kodu
5. Pracujcie w parze nad pierwszym zadaniem w trybie Agent, aby zademonstrować skuteczne promptowanie

Połączenie wspólnych reguł i poleceń zespołowych sprawia, że nowy deweloper dostaje taką samą jakość AI jak weteran zespołu, bez potrzeby budowania osobistej ekspertyzy w promptowaniu.

Kiedy coś nie działa

Członkowie zespołu nadpisują wspólne reguły osobistymi regułami użytkownika. Reguły użytkownika mają najniższy priorytet, więc nie mogą nadpisać reguł zespołowych ani reguł projektu. Jeśli ktoś dostaje inne wyniki, sprawdź, czy nie ma lokalnych plików reguł, które nie zostały dodane do kontroli wersji.

Reguły stają się przestarzałe w miarę ewolucji bazy kodu. Uczyń aktualizację reguł częścią procesu deweloperskiego. Gdy refaktoryzujesz wzorzec, do którego odwołuje się reguła, zaktualizuj regułę w tym samym PR.

Zbyt wiele reguł spowalnia AI. Reguły zużywają tokeny kontekstu. Jeśli masz ponad 30 reguł z alwaysApply: true, agent zaczyna każdą rozmowę ze znacznym narzutem kontekstowym. Przeprowadź audyt, które reguły naprawdę muszą być zawsze stosowane, a które mogą mieć zakres glob lub decyzję agenta.

Członkowie zespołu nie wiedzą, jakie polecenia są dostępne. Udokumentuj niestandardowe polecenia w README projektu lub przewodniku kontrybuowania. Prefiks / w czacie pokazuje listę dostępnych poleceń, ale nowi członkowie zespołu mogą nie wiedzieć, żeby tam szukać.

Co dalej

• Niestandardowe reguły i szablony — Szczegółowy przewodnik budowania reguł, których potrzebuje twój zespół
• Prywatność i bezpieczeństwo — Wymuszaj praktyki bezpieczeństwa przez reguły zespołowe
• Zarządzanie tokenami — Zarządzaj kosztami w zespole użytkowników Cursora