Cursor AI - Prompt Engineering dla full-stack developerów

Produktywność z edytorem Cursor

Artykuł, który właśnie czytasz, to dodatek do filmów opublikowanych na kanale Przeprogramowani.

Zanim przejdziesz do kolejnej części artykułu, zachęcam do obejrzenia dwóch klipów. W pierwszym opisujemy główne założenia Cursora i jego przewagi względem VS Code, a w drugim budujemy prototyp aplikacji full-stackowej. To właśnie w tym klipie wykorzystałem polecenia, które opisuję poniżej.

Poniżej znajdziesz zestaw promptów, które wykorzystaliśmy do sterowania zachowaniem AI. Całość opiera się o możliwości modelu Claude 3.5 Sonnet, który jest dostępny w edytorze Cursor, usłudze Claude.AI oraz poprzez Anthropic API.

Zaznaczam, że nie musi to być ostateczny kształt poleceń, ale pewien “snapshot”, który powinien ewoluować wraz z kolejnymi etapami realizowanego projektu.

Reguły Cursora (.cursorrules)

Pierwszy plik, który warto wprowadzić na poziomie całego projektu, to plik .cursorrules.

Określa on ogólne zasady współpracy z AI, szczegóły projektu oraz twoje oczekiwania względem generowanego kodu.

Na potrzeby filmu zdecydowałem się wprowadzić następujące reguły:

You are an experienced full stack developer and helpful pair programmer.

When working together, we are using the following tech stack:

- TypeScript
- Astro
- Svelte (without SvelteKit)
- Tailwind
- Node.js
- OpenAI library and DALL-E 3 model (https://github.com/openai/openai-node)
- ...

When introducing 3rd party libraries, always ask for confirmation or alternative solutions.

Założenia są naprawdę proste - jeśli pracujemy w Astro, to nie chcemy kodu z Nexta. Jeśli pracujemy z TypeScriptem, to chcemy typów i interfejsów, a nie JavaScriptu. Jeśli lista zależności ma być zamknięta, to jasno takie oczekiwanie stawiamy. To podstawa współpracy z AI.

Odpowiednikiem pliku .cursorrules w świecie ChataGPT są tzw. Custom Instructions oraz prompty systemowe, które wykorzystujemy w integracjach technicznych.

Specyfikacja API - Rick and Morty

Aby budowane aplikacje były jak najbardziej realistyczne, warto eksperymentować z otwartymi API. W moim przypadku jest to API oparte na serialu Rick and Morty.

Znajdziesz go na stronie Ricky and Morty API - najważniejsze informacje (np. jako OpenAPI Specification) umieszczam w pliku Markdown i udostępniam edytorowi Cursor poprzez narzędzie Composer (pokazane na filmie).

Scenariusz - krok po kroku

Pracując nad aplikacją, którą prezentuję w swoim filmie, zdecydowałem się wprowadzić sztywny scenariusz kroków, który zarówno mi, jak i modelowi AI pozwala wracać na właściwy tor.

W moim przypadku zaczyna się to od poznania i opisania dostępnych endpointów (poszerzenie kontekstu rozmowy), następnie wygenerowania pomysłów (do mojej decyzji), przejścia do planowania projektu (milestones), a następnie do implementacji rozbitej na warstwy backendu i frontendu.

Please act accordingly to the following workflow:

000-api-scan.txt
001-ideation.txt
002-project-plan.txt
003-architecture.txt
004-api-client-openai.txt
004-api-client-rickmorty.txt
005-view-layer-astro.txt
005-view-layer-svelte.txt
006-quality-check.txt

Tego typu plan stanowi dla mnie ramę całej konwersacji i pozwala o kilka dodatkowych procent zminimalizować efekt halucynacji, który pojawia się w dłuższych konwersacjach.

Prompty do wykorzystania w projektach webowych

Na tym etapie przechodzę do precyzowania kolejnych kroków, które powinny być realizowane w ramach projektu.

Zaczynamy od przeglądu dostępnych endpointów w API Rick and Morty.

Please review content of "rick-and-morty.md".

We'll be building a web app that uses available endpoints.

List all available endpoints and describe what they do.

Then proceed to ideation stage.

Po wygenerowaniu opisu, model zapyta nas o przejście do następnego kroku (całość widać na filmie).

Możemy zgodzić się na przejście do następnego kroku, albo poprosić o doprecyzowanie lub korektę dostępnych endpointów. To ważny krok, który może zadecydować o jakości wygenerowanego kodu, szczególnie klientów backendowych.

W kolejnym kroku rozpoczynamy generowanie pomysłów na aplikację. Żeby przetestować jakość promptów, na filmie zdecydowałem się na utworzenie listy 10 pomysłów na aplikacje webowe oparte o API Rick and Morty oraz model DALL-E 3.

Let's enter the ideation stage. The idea is to combine Rick and Morty API with OpenAI DALL-E 3 model to create engaging web application.

List 10 ideas for web apps that we may build.

Think about engaging scenarios and user journeys, going beyond exact endpoints. You can mix and match endpoints to create engaging user journeys.

Your goal is to create a web app that will be engaging and fun to use.

It's my turn to pick one of the ideas.

W tym momencie decydujemy się na jeden z projektów i przechodzimy do planowania MVP. Zwróć uwagę, że moje oczekiwanie względem tego, kto decyduje o wyborze projektu (ja), jest również zawarte w prompcie - to ostatnie zdanie. Bez jasno określonych oczekiwań może się zdarzyć, że model sam zadecyduje o wyborze aplikacji, a tego przecież nie chcemy (prawda ;) ?).

Kolejny prompt to opis stanu repozytorium, a także kolejna próba poszerzenia kontekstu całej rozmowy. Z mojego doświadczenia wynika, że im później zdecydujemy się na generowanie kodu, tym lepsze wyniki możemy uzyskać od modelu AI.

We're going to build a full stack web app using tools I provided in the .cursorrules file.

We already have an empty template created with Astro CLI.

As a first step, please prepare a list of milestones to rapidly prototype a functional MVP. Let's focus on the core functionality, with a focus on the user experience.

Keep in mind that we'll be using OpenAI DALL-E 3 model to generate illustrations for our app.

Teraz przechodzimy do części praktycznej. Na podstawie dostępnych endpointów a także wybranego przez nas projektu, możemy rozpocząć projektowanie doświadczeń użytkownika. Kolejne zadanie skupia się właśnie na tym:

Having the project plan defined, please create information architecture for the app.

It should be simple yet engaging project that we can build and run locally.

Please provide a list of pages and components that you think are necessary for the MVP.

The information architecture should be based on the API that we've discovered in the previous step.

Focus on core functionality - features such as authentication, user management, etc. should be excluded.

You may want to use storage based on local storage or JSON files.

Na tym etapie zwracam szczególną uwagę na to, co jest niezbędne, a co opcjonalne. Na przykład - na potrzeby prototypu uruchamianego lokalnie, nie chcemy budować mechanizmów administracyjnych, a nawet logowania czy rejestracji użytkowników. W razie potrzeby mogę odpowiednio skorygować architekturę informacji i pozbyć się elementów, które wychodzą poza zakres MVP.

W kolejnym kroku przechodzę do implementacji samej aplikacji. Zaczynam od backendu, który dla interfejsu użytkownika będzie wyznaczał ramy do działania aplikacji. Rozbijam generowanie backendu na dwa etapy - upewniam się, że wygenerowany kod jest poprawny i korzysta z najnowszych endpointów:

Having the project plan defined, please build backend client for OpenAI DALL-E 3 model. Use the newest OpenAI SDK (openai) library. It's already added to the project.

There's a global variable OPENAI_API_KEY that is set to the API key.

If you are implementing any Astro functions, please make sure that they are uppercased.

W drugim kroku generuję klienta, przez którego będzie się odbywać komunikacja z API Rick and Morty:

Having the project plan defined, please build backend client that will be used to fetch data from the Rick and MortyAPI.

Do not use any external libraries for data fetching.

If you are implementing any Astro functions, please make sure that they are uppercased.

Backend layer may include business logic and more complex endpoints that will allow you to execute the project plan.

Następnie przechodzimy do implementacji frontendu. Zaczynam od statycznyj nawigacji, która ma być zbudowana zgodnie z planem projektu, z wykorzystaniem kodu server-side w Astro. Ponownie rozbijam tę operację na dwa kroki - być może to przesadna ostrożność, a być może dopasowanie mojej taktyki do ograniczeń obecnej generacji modeli. Co by nie mówić - właśnie taki sposób komunikacji przynosił dla mnie najlepsze efekty:

Please implement view layer for the app that will be based on the project plan and available API client.

Focus on server-side pages and layouts in Astro. Do not implement any client-side components yet. Main navigation from the information architecture should be implemented.

Stick to the tech stack defined in the .cursorrules file.

As a result, I would like to navigate through all the pages in my browser.

Do statycznej nawigacji dochodzi teraz kod client-side w Svelte. Warstwa po warstwie aplikacja staje się coraz bardziej realistyczna:

Now, extend main navigation with Svelte components, making the app engaging and interactive.

Follow the project plan and use the API client to fetch and display data.

Stick to the tech stack defined in the .cursorrules file.

As a result, I would like to see a fully functional Svelte app.

Na tym etapie zdarzało się, że prototyp aplikacji działał zgodnie z oczekiwaniami, ale w pewnych sytuacjach Cursor pomijał lub błędnie interpretował moje polecenia. Dlatego też zdecydowałem się na ostatni krok, czyli dedykowaną weryfikację kodu i ocenę jakości całego kontekstu rozmowy.

Weryfikacja kodu i ocena jakości

Podobnie jak wcześniej - na podstawie obserwacji i analizy zachowań modelu - dodałem do swojego scenariusza ostatni krok, który jest wygładzeniem otrzymywanych niedociągnięć. To lista, która zmieniała się kilkukrotnie i u ciebie również nie powinna być statyczna:

Conduct the following quality checks:

- Check if all the imports point to existing files. If not, implement the missing parts.
- Check if imports to CSS files are correct - if files are missing and needed, add them.
- Verify component cross-references - if files are missing and needed, add them.
- Check if information architecture matches the requirements. If not, change the architecture.
- Check if the API is properly utilized. If not, you are free to change business logic.
- Check if the tech stack configuration is correct. If not, change the configuration.
- Make sure both server-side and client-side code passes the quality checks.
- If you are implementing any Astro functions, please make sure that they are uppercased.

Skuteczna współpraca programisty z AI

Powyższe prompty to efekt zrozumienia architektury modeli AI i sposobu, w jaki można się z nimi komunikować. Praktyka i realizacja kolejnych projektów we współpracy z AI pozwoliła mi poznać realne możliwości tej technologii, a także ograniczenia, dzięki którym unikam niepotrzebnych błędów.

Jeśli chcesz pogłębić swoją wiedzę o edytorze Cursor oraz o tym, jak AI może wspomagać programistów w realizacji codziennych zadań, to zachęcam do skorzystania z kursu Przeprogramowanych.

Kliknij w ten link, aby poznać szczegóły.