Prompty do programowania: jak dostać działający kod

Prompt do programowania to specyfikacja. Model nie widział twojego projektu, nie wie, jakiej wersji języka używasz, i nie może zapytać, co ma się stać, gdy wejście jest puste. Wszystko, co prompt pomija, uzupełnia najczęstszym wyborem z danych treningowych, a najczęstszy wybór często nie jest twoim. Poniższe prompty zostawiają modelowi mniej do zgadywania.

Napisz specyfikację przed kodem

Poniższy blok prosi o małą funkcję w Pythonie. Każda część promptu odpowiada na pytanie, na które model w przeciwnym razie odpowiedziałby za ciebie. Wyłączaj części po jednej i wyobraź sobie odpowiedź bez nich: bez ograniczeń możesz dostać zewnętrzną bibliotekę, bez kontekstu model musi zgadywać, co jest poprawnym wejściem, a bez formatu możesz nie dostać testów.

Funkcja według specyfikacji

EditCopy

Fill inversion

PartsRoleTaskContextConstraintsFormat

Role

Jesteś starannym programistą Pythona, który pisze małe, przetestowane funkcje.

Task

Napisz funkcję `parse_duration(text)`, która zamienia napis z czasem trwania na liczbę sekund.

Context

Poprawne wejścia wyglądają jak "1h30m", "45m", "2h" i "90s": godziny, minuty i sekundy, każda część opcjonalna, zawsze w tej kolejności. "1h30m" zwraca 5400. Wszystko inne, łącznie z pustym stringiem, jest niepoprawne.

Constraints

Python 3.11, tylko biblioteka standardowa. Przy niepoprawnym wejściu zgłaszaj ValueError z wejściem w komunikacie. Nie akceptuj ułamków w rodzaju "1.5h".

Format

Najpierw podaj funkcję, potem testy w pytest obejmujące każdy powyższy przykład oraz trzy niepoprawne wejścia. Bez wyjaśnień poza jednym zdaniem.

Try it

Example replyReplies vary between models and runs.

Funkcja dopasowuje po kolei trzy opcjonalne części i odrzuca dopasowanie, w którym wszystkie trzy są puste.

import re

_PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")

def parse_duration(text: str) -> int:
    match = _PATTERN.fullmatch(text)
    if not match or not any(match.groups()):
        raise ValueError(f"invalid duration: {text!r}")
    hours, minutes, seconds = (int(g) if g else 0 for g in match.groups())
    return hours * 3600 + minutes * 60 + seconds

import pytest
from duration import parse_duration

@pytest.mark.parametrize("text, expected", [
    ("1h30m", 5400), ("45m", 2700), ("2h", 7200), ("90s", 90),
])
def test_valid(text, expected):
    assert parse_duration(text) == expected

@pytest.mark.parametrize("text", ["", "1m1h", "1.5h"])
def test_invalid(text):
    with pytest.raises(ValueError):
        parse_duration(text)

Większość pracy wykonują w tym prompcie cztery szczegóły:

• Przykłady z odpowiedziami. "1h30m zwraca 5400" to test, z którym model może porównać własny kod, a przy tym usuwa wątpliwości co do jednostki.
• Wersja języka i dozwolone biblioteki. Bez nich możesz dostać bibliotekę, której nie masz zainstalowanej, albo składnię nowszą niż twój interpreter.
• Co jest niepoprawne i co ma się wtedy stać. Obsługę błędów model łatwo pomija, gdy nikt o nią nie prosi.
• Testy w odpowiedzi. Zamieniają "wygląda dobrze" w coś, co da się uruchomić. Jeśli test nie przejdzie, wklejasz błąd z powrotem, a to znacznie lepsza kontynuacja niż "nie działa".

Warto też zwrócić uwagę na sprawdzenie any(match.groups()): sam wzorzec pasuje do pustego stringa, bo każda część jest opcjonalna. To linia promptu o pustym stringu sprawia, że ten przypadek pojawia się w kodzie i w testach.

Podaj wersję, stos technologiczny i to, co już istnieje

Modele skłaniają się ku stylowi, który był najczęstszy w ich danych treningowych. W JavaScripcie może to oznaczać require z CommonJS w projekcie, który używa modułów ES, w Pythonie API biblioteki, które od tego czasu się zmieniło (Pydantic 1 a 2 to częsty przypadek), a w każdym szybko rozwijającym się frameworku wzorzec sprzed dwóch głównych wersji. Zwykle naprawia to jedna linia: "Node 22, moduły ES, bez TypeScriptu" albo "React 19, komponenty funkcyjne, zwykłe moduły CSS".

Gdy dodajesz coś do istniejącego projektu, model musi zobaczyć części, których dotknie nowy kod. Wklej sygnaturę funkcji, którą ma wywołać, kształt danych, które dostanie, i jeden istniejący plik pokazujący twoje konwencje. "Użyj helpera db.query(sql, params) z poniższego pliku" daje kod, który pasuje; bez tego możesz dostać nowe połączenie z bazą napisane od zera. Pomijaj pliki niezwiązane ze zmianą, bo każda niezwiązana linia to coś, czego model może spróbować użyć ponownie.

Proś o jeden mały krok naraz

Najczęstsza porażka "vibe codingu", czyli budowania aplikacji przez opisywanie jej AI, to prośba o całą aplikację naraz. Model musi w jednej odpowiedzi wybrać framework, bazę danych, strukturę folderów i kilkanaście funkcji, a pojedyncza odpowiedź rzadko mieści działający kod dla wszystkiego, więc często wraca zarys. Porównaj dwie zakładki.

Cała aplikacja narazJeden mały krok

EditCopy

Zbuduj mi aplikację z listą zadań, z kontami użytkowników, bazą danych, przypomnieniami i trybem ciemnym.

Try it

Example replyReplies vary between models and runs.

Oto aplikacja full stack z listą zadań oparta na React, Node.js z Express i MongoDB.

Struktura projektu

todo-app/
  client/   (front end w React)
  server/   (API w Express, uwierzytelnianie, przypomnienia)

server/index.js

const express = require("express");
const mongoose = require("mongoose");
const app = express();
app.use(express.json());
// ... auth routes, todo routes and the reminder scheduler go here

Do uwierzytelniania możesz dodać JWT z jsonwebtoken, a do przypomnień harmonogram w rodzaju node-cron. Daj znać, czy mam uzupełnić którąś z tych części.

Pierwsza odpowiedź nie jest błędna, ale to szkielet: wybrała za ciebie trzy technologie, a prawdziwą pracę zostawiła w komentarzach. Druga odpowiedź jest na tyle krótka, że da się ją przeczytać, działa od razu po otwarciu pliku i daje działającą bazę dla kroku 2 ("teraz zapisuj listę w localStorage, żeby przetrwała przeładowanie"). Każdy krok jest na tyle mały, że gdy coś się zepsuje, wiesz, która zmiana to zepsuła.

To prompt chaining robiony ręcznie: wynik jednej prośby staje się punktem wyjścia następnej. Wklejaj aktualną wersję pliku do każdego nowego kroku, żeby model edytował kod, który faktycznie masz, a nie ten, który pamięta.

Poproś o plan przed dużą zmianą

Przy wszystkim, co jest większe niż jedna funkcja, poproś najpierw o plan, a dopiero potem o kod: "Wypisz pliki do zmiany i to, co robi każda zmiana. Nie pisz jeszcze kodu." Plan szybko się czyta i szybko poprawia. Jeśli proponuje nową zależność, której nie chcesz, albo pomija plik, o którym wiesz, że jest zaangażowany, poprawiasz to jednym zdaniem, zamiast odkrywać to w trzystu liniach kodu.

Sprawdź, co wraca

Wygenerowany kod zawodzi na kilka przewidywalnych sposobów, a każdy z nich wyłapuje jakiś nawyk w promptach:

• Wymyślone API. Model może wywołać funkcję albo zaimportować pakiet, który nie istnieje, bo nazwa brzmi wiarygodnie. Sprawdzaj nieznane importy, zanim je zainstalujesz; dlaczego tak się dzieje, wyjaśniają halucynacje AI.
• Ciche przypadki brzegowe. Kod, który działa na szczęśliwej ścieżce i wysypuje się na pustej liście. Najtańsza poprawka to wypisanie przypadków brzegowych w prompcie i prośba o testy.
• Ciche zmiany. Gdy prosisz o poprawkę w długim pliku, model może też zmienić nazwy albo przeorganizować kod, o który nie pytasz. Dodaj "zmień tylko to, co konieczne, i wypisz każdą wprowadzoną zmianę".

Gdy kod działa, ale zachowuje się źle, przejdź na prompt do debugowania: co wkleić, opisują prompty do debugowania. Zanim scalisz cokolwiek ważnego, drugi przebieg z promptem do code review może wyłapać problemy, o które prompt piszący kod nie pomyślał zapytać.