Podejście oparte na specyfikacji
Definiuj wymagania przed napisaniem kodu.
Lekka specyfikacja do budowania i zarządzania projektami asystentów AI.
Witaj. To jest miejsce dla wszystkiego, co związane z OpenSpec.
OpenSpec pomaga Tobie i Twojemu asystentowi kodowania AI uzgodnić, co zbudować, zanim jakikolwiek kod zostanie napisany. Opisujesz zmianę, AI przygotowuje krótką specyfikację i listę zadań, obaj patrzycie na ten sam plan, a następnie zaczyna się praca. Koniec z odkrywaniem w połowie drogi, że AI zbudowało coś złego.
Jeśli nie przeczytasz nic innego, przeczytaj te dwie strony:
/opsx:propose (podpowiedź: w czacie AI, nie w terminalu). To dezorientuje prawie każdego chociaż raz.Ta druga strona jest ważniejsza, niż się wydaje. OpenSpec składa się z dwóch części: narzędzia wiersza polecenia, które uruchamiasz w terminalu, oraz poleceń z ukośnikiem (slash commands), które przekazujesz swojemu asystentowi AI. Znajomość tego, które jest które, chroni Cię przed najczęstszym momentem dezorientacji.
Najlepszy nawyk na początek: gdy nie jesteś pewien, co zbudować, zacznij od
/opsx:explore. To bezpieczny partner do myślenia, który czyta Twój kod, rozważa opcje i doprecyzowuje mglistą ideę w konkretny plan, zanim jakikolwiek artefakt lub kod powstanie. Przewodnik Eksploracja najpierw wyjaśnia dlaczego.
Jestem zupełnie nowy. Zacznij od Rozpoczęcia, potem przejrzyj Koncepcje główne w skrócie. Gdy coś wydaje się tajemnicze, FAQ i Słownik są pod ręką.
Mam problem, ale nie mam planu. To częsty przypadek i ma dedykowaną odpowiedź: Eksploracja najpierw. Użyj /opsx:explore, aby przemyśleć to z AI przed podjęciem jakichkolwiek zobowiązań.
Mam dużą, istniejącą bazę kodu. Nie dokumentujesz jej całej. Używanie OpenSpec w istniejącym projekcie pokazuje, jak zacząć od rzeczywistego, istniejącego kodu (brownfield) bez robienia z igły widła.
Chcę tylko, żeby to działało. Zainstaluj, uruchom openspec init, potem przeczytaj Jak działają polecenia, aby Twoje pierwsze polecenie z ukośnikiem trafiło we właściwe miejsce.
Uczę się na przykładach. Strona Przykłady i przepisy przeprowadzi Cię przez rzeczywiste zmiany od początku do końca: małą funkcję, poprawkę błędu, refaktoryzację, eksplorację.
AI właśnie przygotowało plan — co teraz? Przeczytaj go. Przeglądanie zmiany pokazuje dwuminutowe przeglądnięcie, które wyłapuje błędny zakręt, gdy jest to jeszcze tanie, a Pisanie dobrych specyfikacji opisuje, z czego składa się plan warty zatwierdzenia.
Pracujesz w zespole. OpenSpec w zespole pokazuje, jak zmiana mapuje się na gałąź i pull request, oraz jak członkowie zespołu przeglądają plan przed kodem.
Przechodzę ze starego przepływu pracy. Przewodnik migracji wyjaśnia, co się zmieniło i dlaczego, oraz obiecuje, że Twoja istniejąca praca jest bezpieczna.
Chcę dostosować go do procesu mojego zespołu. Dostosowywanie opisuje konfigurację projektu, niestandardowe schematy i współdzielony kontekst.
Coś jest zepsute. Rozwiązywanie problemów zbiera awarie, które faktycznie spotykają ludzi, wraz z poprawkami.
| Dokument | Co Ci daje |
|---|---|
| Rozpoczęcie | Instalacja, inicjalizacja i przeprowadzenie Twojej pierwszej zmiany od początku do końca |
| Eksploracja najpierw | Użyj /opsx:explore, aby przemyśleć ideę przed podjęciem zobowiązania |
| Jak działają polecenia | Gdzie uruchamiane są polecenia z ukośnikiem, co oznacza "tryb interaktywny", terminal kontra czat |
| Koncepcje główne w skrócie | Cały model mentalny na jednej stronie: specyfikacje, zmiany, delty, archiwum |
| Instalacja | npm, pnpm, yarn, bun, Nix i jak sprawdzić, czy zadziałało |
| Dokument | Co Ci daje |
|---|---|
| Przepływy pracy | Typowe wzorce i kiedy sięgać po każde polecenie |
| Przykłady i przepisy | Pełne przewodniki po rzeczywistych zmianach, gotowe do skopiowania i wklejenia |
| Pisanie dobrych specyfikacji | Jak wygląda silne wymaganie i scenariusz, oraz jak dopasować rozmiar zmiany |
| Przeglądanie zmiany | Dwuminutowe przeglądnięcie przygotowanego planu przed napisaniem jakiegokolwiek kodu |
| OpenSpec w zespole | Jak zmiany pasują do gałęzi, pull requestów i przeglądów |
| Używanie OpenSpec w istniejącym projekcie | Wdrażanie OpenSpec na dużej bazie kodu brownfield |
| Edytowanie i iterowanie zmiany | Aktualizuj artefakty, wróć, uzgodnij ręczne edycje |
| Polecenia | Dokumentacja dla każdego polecenia z ukośnikiem /opsx:* |
| CLI | Dokumentacja dla każdego polecenia terminala openspec |
| Dokument | Co Ci daje |
|---|---|
| Koncepcje | Wyjaśnienie w długiej formie specyfikacji, zmian, artefaktów, schematów i archiwum |
| Przepływ pracy OPSX | Dlaczego przepływ jest płynny zamiast zablokowany na fazach, plus głębokie zanurzenie w architekturę |
| Słownik | Każdy termin zdefiniowany w jednym miejscu |
| Dokument | Co Ci daje |
|---|---|
| Dostosowywanie | Konfiguracja projektu, niestandardowe schematy, współdzielony kontekst |
| Wielojęzyczność | Generuj artefakty w językach innych niż angielski |
| Obsługiwane narzędzia | Ponad 25 narzędzi AI, z którymi integruje się OpenSpec, i gdzie lądują pliki |
| Dokument | Co Ci daje |
|---|---|
| FAQ | Szybkie odpowiedzi na pytania, które ludzie zadają najczęściej |
| Rozwiązywanie problemów | Konkretne poprawki dla konkretnych awarii |
| Przewodnik migracji | Przechodzenie ze starszego przepływu pracy na OPSX |
| Dokument | Co Ci daje |
|---|---|
| Magazyny: Przewodnik użytkownika | Planuj we własnym repozytorium, gdy Twoja praca obejmuje repozytoria lub zespoły |
| Kontrakt agenta | Czytelne maszynowo CLI, którymi sterują agenci |
1. Instalacja npm install -g @fission-ai/openspec@latest
2. Inicjalizacja cd your-project && openspec init
3. Eksploracja (w czacie AI) /opsx:explore ← opcjonalne, ale świetny nawyk
4. Propozycja (w czacie AI) /opsx:propose add-dark-mode
5. Budowanie (w czacie AI) /opsx:apply
6. Archiwizacja (w czacie AI) /opsx:archiveKroki 1 i 2 odbywają się w Twoim terminalu. Reszta dzieje się w czacie Twojego asystenta AI. Ten podział to jedna rzecz, którą warto zapamiętać, a Jak działają polecenia dokładnie wyjaśnia dlaczego. Krok 3 jest opcjonalny, ale rozpoczynanie od /opsx:explore, gdy nie jesteś pewien, to nawyk, który najbardziej warto wypracować.
openspec feedback "twoja wiadomość" wysyła opinię bezpośrednio z Twojego terminala (otwiera GitHub issue).Znalazłeś coś w tej dokumentacji, co jest błędne, nieaktualne lub mylące? To błąd. Otwórz issue lub PR. Ulepszenia dokumentacji to jeden z najcenniejszych wkładów, jakie możesz wnieść.