Przejdź do głównej zawartości

Współpraca zespołowa: Wskazówki 106-112

Twój zespół ma pięciu programistów używających Cursora. Każdy ma różne reguły globalne, różne preferencje modelu, różne style promptowania. Agent jednego programisty generuje kod ze średnikami; innego generuje kod bez. Jeden używa wszędzie typów any; inny pisze ścisły TypeScript. Kod generowany przez AI wygląda, jakby został napisany przez pięć różnych osób — ponieważ został skonfigurowany przez pięć różnych osób. Te 7 wskazówek przekształca indywidualne konfiguracje Cursora w skoordynowany przepływ pracy zespołowej.

  • Zacommitowany katalog .cursor/rules/, który sprawia, że kod generowany przez AI jest spójny w całym zespole
  • Listę kontrolną onboardingu, która sprawia, że nowi członkowie zespołu są produktywni z Cursorem w jeden dzień
  • Proces recenzji kodu wspomaganej przez AI, który wychwytuje problemy, zanim recenzenci-ludzie poświęcą na nie czas
  • Wspólne szablony promptów, które kodują najlepsze praktyki zespołu w wielokrotnie używane pliki
  • Politykę bezpieczeństwa, która równoważy produktywność z wymogami zgodności

Wskazówka 106: Zacommituj swoje reguły Cursora do kontroli wersji

Dział zatytułowany „Wskazówka 106: Zacommituj swoje reguły Cursora do kontroli wersji”

To najważniejsza wskazówka zespołowa. Reguły projektu należą do kontroli wersji, a nie do indywidualnych ustawień programistów. Gdy reguły są zacommitowane, każdy programista i każda konwersacja agenta używa tych samych ograniczeń.

Utwórz katalog reguł i zacommituj go:

Okno terminala
mkdir -p .cursor/rules

Jako minimum utwórz te pliki:

.cursor/rules/code-style.md
## Styl kodu
- TypeScript strict mode. Bez typów 'any' z wyjątkiem miejsc, gdzie jest to wyraźnie udokumentowane.
- Tylko named exports. Bez default exports.
- Komponenty funkcyjne z hookami dla React.
- camelCase dla zmiennych i funkcji. PascalCase dla typów, interfejsów i komponentów.
- Używaj async/await. Nigdy nie używaj łańcuchów .then().
- Wszystkie funkcje async muszą mieć obsługę błędów try-catch.
- Preferuj fetch zamiast axios do żądań HTTP.
- Używaj pnpm do wszystkich poleceń menedżera pakietów.
.cursor/rules/testing.md
## Konwencje testowania
- Używaj vitest do wszystkich testów jednostkowych i integracyjnych.
- Pliki testowe znajdują się obok kodu, który testują: src/services/__tests__/user.test.ts
- Używaj opisowych nazw testów, które wyjaśniają scenariusz: "should return 404 when user does not exist"
- Mockuj zależności zewnętrzne (baza danych, API), ale nie moduły wewnętrzne.
- Cel to 80% pokrycia kodu dla nowego kodu.
- Zawsze testuj przypadki błędów, nie tylko happy paths.
.cursor/rules/architecture.md
## Zasady architektury
- Trasy API w src/api/ obsługują tylko kwestie HTTP (parsowanie, walidacja, formatowanie odpowiedzi).
- Logika biznesowa trafia do src/services/. Serwisy nigdy nie importują z src/api/.
- Operacje bazodanowe trafiają do src/repositories/. Serwisy używają repozytoriów, nigdy surowych zapytań.
- Współdzielone typy trafiają do src/types/. Typy to jedyna rzecz, którą każda warstwa może importować.
- Nie twórz zależności cyklicznych. Jeśli serwis A potrzebuje serwisu B, wstrzyknij go jako parametr.

Wskazówka 107: Standaryzuj konfigurację serwerów MCP

Dział zatytułowany „Wskazówka 107: Standaryzuj konfigurację serwerów MCP”

Jeśli Twój zespół używa serwerów MCP (baza danych, GitHub, Jira), zacommituj konfigurację, aby każdy programista miał to samo ustawienie:

.cursor/mcp.json
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": { "DATABASE_URL": "${DATABASE_URL}" }
}
}
}

Udokumentuj wymagane zmienne środowiskowe w README projektu lub przewodniku onboardingu. Każdy programista ustawia własne tokeny, ale konfiguracja serwera MCP jest współdzielona.

Zapisz często używane prompty jako pliki w repozytorium, aby każdy członek zespołu mógł się do nich odwoływać:

Okno terminala
mkdir -p .cursor/prompts
.cursor/prompts/new-endpoint.md
Utwórz nowy endpoint API zgodnie z tymi konwencjami projektu:
1. Handler trasy w src/api/[resource]/route.ts używając wzorca z @src/api/users/route.ts
2. Warstwa serwisowa w src/services/[resource].ts używając wzorca z @src/services/user.ts
3. Definicje typów w src/types/[resource].ts
4. Testy Vitest w src/services/__tests__/[resource].test.ts
5. Schemat walidacji Zod dla body żądania
6. Odpowiednia obsługa błędów używając naszej klasy AppError z @src/lib/errors.ts
Uruchom pnpm test po implementacji, aby zweryfikować, że wszystko przechodzi.
.cursor/prompts/pre-pr.md
Przejrzyj i napraw wszystkie problemy przed gotowością tego PR:
1. pnpm run typecheck -- napraw błędy TypeScript
2. pnpm run lint -- napraw problemy lintingu
3. pnpm run test -- napraw nieudane testy (nie modyfikuj asercji)
4. Usuń wszystkie instrukcje console.log/debug
5. Zweryfikuj, że wszystkie nowe eksporty są dodane do plików index
6. Sprawdź, że żadne wrażliwe dane (klucze API, hasła) nie są zacommitowane
Podsumuj wszystkie dokonane zmiany.

Członkowie zespołu odwołują się do nich za pomocą @.cursor/prompts/new-endpoint.md w dowolnej konwersacji agenta. Prompty kodują najlepsze praktyki zespołu, dzięki czemu nawet najnowszy członek zespołu produkuje spójny output.

Wskazówka 109: Utwórz listę kontrolną onboardingu Cursora dla nowych członków zespołu

Dział zatytułowany „Wskazówka 109: Utwórz listę kontrolną onboardingu Cursora dla nowych członków zespołu”

Gdy nowy programista dołącza do zespołu, powinien być produktywny z Cursorem w ciągu dnia. Utwórz dokument onboardingu:

Wskazówka 110: Przeprowadzaj cotygodniowe “Wskazówki Cursora” podczas standupu

Dział zatytułowany „Wskazówka 110: Przeprowadzaj cotygodniowe “Wskazówki Cursora” podczas standupu”

Poświęć 5 minut jednego cotygodniowego standupu na wskazówki dotyczące Cursora. Co tydzień jeden członek zespołu dzieli się:

  • Promptem, który działał szczególnie dobrze
  • Przepływem pracy, który odkrył
  • Problemem, którego nie mógł rozwiązać za pomocą Cursora (zespół może mieć rozwiązanie)
  • Sugestią nowej reguły projektu

To tworzy pętlę zwrotną, w której zespół nieustannie poprawia swoje użycie Cursora. Najlepsze prompty i przepływy pracy są dodawane do .cursor/prompts/ dla wszystkich.

Wskazówka 111: Wdróż przed-recenzję wspomaganą przez AI

Dział zatytułowany „Wskazówka 111: Wdróż przed-recenzję wspomaganą przez AI”

Przed poproszeniem o recenzję kodu przez człowieka każdy członek zespołu przeprowadza recenzję AI:

  1. Programista kończy swoją funkcję
  2. Programista uruchamia @.cursor/prompts/pre-pr.md, aby naprawić linting, typy i testy
  3. Programista uruchamia Bug Finder (Cmd+Shift+P > “Bug Finder”)
  4. Programista uruchamia prompt recenzji kodu AI poniżej
  5. Programista naprawia problemy znalezione w krokach 2-4
  6. Programista otwiera PR do recenzji przez człowieka

Ta przed-recenzja wychwytuje 60-70% problemów, które recenzent-człowiek by oznaczył. Recenzenci-ludzie mogą wtedy skupić się na decyzjach architektonicznych, poprawności logiki biznesowej i kompromisach projektowych — rzeczach, w których AI jest najgorszy.

Wskazówka 112: Ustanów zespołową politykę bezpieczeństwa dla narzędzi AI

Dział zatytułowany „Wskazówka 112: Ustanów zespołową politykę bezpieczeństwa dla narzędzi AI”

Utwórz politykę bezpieczeństwa, która równoważy produktywność z zgodnością:

.cursor/rules/security.md
## Polityka bezpieczeństwa AI
### Do czego AI może mieć dostęp
- Cały kod źródłowy w repozytorium
- Bazy danych deweloperskie i stagingowe przez MCP (nigdy produkcyjne)
- Publiczna dokumentacja i API
- Logi CI/CD i artefakty build
### Czego AI nie może robić
- Dostęp do baz danych lub serwerów produkcyjnych
- Commitowanie lub pushowanie kodu bez recenzji przez człowieka
- Przechowywanie kluczy API, haseł lub sekretów w kodzie
- Wyłączanie middleware bezpieczeństwa lub kontroli uwierzytelniania
- Modyfikowanie plików .env lub konfiguracji wdrożenia
### Wymagania prywatności
- Włącz tryb prywatności dla całego kodu własnościowego
- Nie wklejaj danych klientów do konwersacji agenta
- Nie odwołuj się do wewnętrznych dokumentów firmowych przez URL
- Przejrzyj cały kod generowany przez AI pod kątem przypadkowo ujawnionych danych uwierzytelniających
### Ograniczenia trybu YOLO
Zezwalaj: polecenia testowe, polecenia build, linting, tworzenie plików
Odmawiaj: rm -rf, sudo, ssh, curl do zewnętrznych URL, git push, npm publish, polecenia deploy

Zacommituj to do swojego repozytorium i przejrzyj podczas onboardingu. Aktualizuj w miarę ewolucji wymagań bezpieczeństwa zespołu.

Członkowie zespołu nadpisują reguły projektu osobistymi ustawieniami: Globalne reguły użytkownika mają pierwszeństwo przed regułami projektu dla niektórych ustawień. Upewnij się, że dokument reguł projektu nie koliduje z powszechnymi osobistymi preferencjami. Jeśli pojawiają się konflikty, przeprowadź dyskusję zespołową, aby standaryzować konwencję i zaktualizować reguły projektu.

Lista kontrolna onboardingu staje się przestarzała: Przypisz jednemu członkowi zespołu aktualizację listy kontrolnej onboardingu, gdy Cursor wypuści znaczącą aktualizację lub zespół zmieni przepływ pracy. Przeglądaj ją co najmniej kwartalnie.

Recenzja kodu AI jest zbyt hałaśliwa: Jeśli prompt recenzji AI generuje zbyt wiele fałszywych alarmów, dopracuj go. Dodaj wyjątki dla znanych wzorców: “Nasz projekt celowo używa typów ‘any’ w warstwie resolverów GraphQL — nie oznaczaj ich.” Im bardziej konkretny prompt, tym mniej fałszywych alarmów.

Tokeny serwera MCP wygasają: Ustaw przypomnienia kalendarzowe dla odnowienia tokenów. Udokumentuj proces rotacji tokenów w przewodniku onboardingu. Rozważ użycie krótkotrwałych tokenów z systemu zarządzania sekretami organizacji.

Ukończyłeś pełną kolekcję 112 wskazówek. Twój indywidualny przepływ pracy jest zoptymalizowany, Twój zespół jest skonfigurowany dla spójności i masz zaawansowane techniki do radzenia sobie z każdym wyzwaniem programistycznym.

Aby kontynuować rozwój: