פרומפטים לתכנות עם AI: איך לקבל קוד שעובד

פרומפט לתכנות הוא מפרט. המודל לא ראה את הפרויקט שלכם, לא יודע באיזו גרסה של השפה אתם משתמשים, ולא יכול לשאול מה צריך לקרות כשהקלט ריק. כל מה שהפרומפט משמיט, הוא ממלא בבחירה הנפוצה ביותר מנתוני האימון שלו, והבחירה הנפוצה ביותר היא לעיתים קרובות לא שלכם. הפרומפטים למטה משאירים למודל פחות דברים לנחש.

לכתוב את המפרט לפני הקוד

הבלוק למטה מבקש פונקציית Python קטנה. כל חלק בפרומפט עונה על שאלה שהמודל היה עונה עליה בשבילכם. כבו את החלקים אחד אחד ודמיינו את התשובה בלעדיהם: בלי המגבלות אתם עלולים לקבל ספרייה חיצונית, בלי ההקשר המודל צריך לנחש מה נחשב קלט תקין, בלי הפורמט אולי לא תקבלו בדיקות.

פונקציה לפי מפרט

EditCopy

Fill inversion

PartsRoleTaskContextConstraintsFormat

Role

אתה מפתח Python קפדן שכותב פונקציות קטנות ובדוקות.

Task

כתוב פונקציה `parse_duration(text)` שהופכת מחרוזת של משך זמן למספר שניות.

Context

קלטים תקינים נראים כמו "1h30m", "45m", "2h" ו-"90s": שעות, דקות ושניות, כל אחד אופציונלי, תמיד בסדר הזה. "1h30m" מחזיר 5400. כל דבר אחר, כולל מחרוזת ריקה, לא תקין.

Constraints

Python 3.11, רק הספרייה הסטנדרטית. זרוק ValueError עבור קלט לא תקין, עם הקלט בהודעה. אל תקבל מספרים עשרוניים כמו "1.5h".

Format

תן קודם את הפונקציה, ואז בדיקות pytest שמכסות כל דוגמה למעלה ועוד שלושה קלטים לא תקינים. בלי הסבר מעבר למשפט אחד.

Try it

Example replyReplies vary between models and runs.

הפונקציה מזהה את שלושת החלקים האופציונליים לפי הסדר ודוחה התאמה שבה שלושתם ריקים.

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)

ארבעה פרטים בפרומפט הזה עושים את רוב העבודה:

• דוגמאות עם התשובות שלהן. "1h30m מחזיר 5400" היא בדיקה שהמודל יכול לבדוק מולה את הקוד שלו, והיא מסירה כל ספק לגבי היחידה.
• גרסת השפה והספריות המותרות. בלעדיהן אתם עלולים לקבל ספרייה שלא התקנתם או תחביר חדש יותר מהמפרש שלכם.
• מה נחשב לא תקין, ומה צריך לקרות אז. למודל קל להשמיט טיפול בשגיאות כשאף אחד לא מבקש אותו.
• בדיקות בתשובה. הן הופכות "נראה נכון" למשהו שאפשר להריץ. אם בדיקה נכשלת, מדביקים את הכשל בחזרה, וזו הודעת המשך טובה הרבה יותר מ-"זה לא עובד".

גם הבדיקה any(match.groups()) שווה תשומת לב: התבנית לבדה מתאימה למחרוזת ריקה, כי כל החלקים אופציונליים. השורה בפרומפט על המחרוזת הריקה היא מה שגורם למקרה הזה להופיע בקוד ובבדיקות.

לציין את הגרסה, את ה-stack ואת מה שכבר קיים

מודלים נוטים לסגנון שהיה הכי נפוץ בנתוני האימון שלהם. ב-JavaScript זה יכול להיות require של CommonJS בפרויקט שמשתמש ב-ES modules, ב-Python זה יכול להיות API של ספרייה שמאז השתנה (Pydantic 1 מול 2 הוא מקרה נפוץ), ובכל framework שמתפתח מהר זה יכול להיות הדפוס משתי גרסאות ראשיות אחורה. שורה אחת בדרך כלל מתקנת את זה: "Node 22, ES modules, בלי TypeScript" או "React 19, function components, CSS modules פשוטים".

כשמוסיפים לפרויקט קיים, המודל צריך לראות את החלקים שהקוד החדש ייגע בהם. הדביקו את החתימה של הפונקציה שהוא צריך לקרוא לה, את מבנה הנתונים שהוא יקבל, וקובץ קיים אחד שמראה את המוסכמות שלכם. "השתמש ב-helper db.query(sql, params) מהקובץ למטה" מקבל קוד שמתאים; בלי זה אתם עלולים לקבל חיבור חדש למסד הנתונים שנכתב מאפס. השאירו בחוץ קבצים שאין להם שום קשר לשינוי, כי כל שורה לא קשורה היא משהו שהמודל עלול לנסות לעשות בו שימוש חוזר.

לבקש צעד קטן אחד בכל פעם

הכשל הנפוץ ביותר ב-"vibe coding", בניית אפליקציה על ידי תיאור שלה ל-AI, הוא לבקש את כל האפליקציה בבת אחת. המודל צריך לבחור framework, מסד נתונים, מבנה תיקיות ותריסר פיצ'רים בתשובה אחת, ותשובה אחת מכילה רק לעיתים רחוקות קוד שעובד לכל זה, ולכן מה שחוזר הוא לעיתים קרובות שלד. השוו את שתי הלשוניות.

כל האפליקציה בבת אחתצעד קטן אחד

EditCopy

תבנה לי אפליקציית משימות עם חשבונות משתמש, מסד נתונים, תזכורות ומצב כהה.

Try it

Example replyReplies vary between models and runs.

הנה אפליקציית משימות full stack עם React, Node.js עם Express ו-MongoDB.

מבנה הפרויקט

todo-app/
  client/   (front end ב-React)
  server/   (API ב-Express, אימות, תזכורות)

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

לאימות אפשר להוסיף JWT עם jsonwebtoken, ולתזכורות מתזמן כמו node-cron. תגיד לי אם אתה רוצה שאשלים חלק מהחלקים האלה.

התשובה הראשונה לא שגויה, אבל היא שלד: היא בחרה בשבילכם שלוש טכנולוגיות והשאירה את העבודה האמיתית כהערות. התשובה השנייה קצרה מספיק כדי לקרוא אותה, רצה ברגע שפותחים את הקובץ, ונותנת בסיס עובד לצעד 2 ("עכשיו תשמור את הרשימה ב-localStorage כדי שהיא תשרוד רענון"). כל צעד קטן מספיק כדי שכשמשהו נשבר, תדעו איזה שינוי שבר אותו.

זה prompt chaining שנעשה ידנית: הפלט של בקשה אחת הופך לנקודת ההתחלה של הבאה. הדביקו את הגרסה הנוכחית של הקובץ בכל צעד חדש, כדי שהמודל יערוך את הקוד שבאמת יש לכם ולא את זה שהוא זוכר שכתב.

לבקש תוכנית לפני שינוי גדול

לכל דבר גדול יותר מפונקציה אחת, בקשו קודם את התוכנית ורק אחר כך את הקוד: "פרט את הקבצים שהיית משנה ומה כל שינוי עושה. אל תכתוב קוד בינתיים." תוכנית מהירה לקריאה ומהירה לתיקון. אם היא מציעה תלות חדשה שאתם לא רוצים או מפספסת קובץ שאתם יודעים שמעורב, מתקנים את זה במשפט אחד במקום לגלות את זה בתוך שלוש מאות שורות קוד.

לבדוק את מה שחוזר

קוד שנוצר נכשל בכמה דרכים צפויות, ולכל אחת יש הרגל פרומפט שתופס אותה:

• API מומצאים. מודל יכול לקרוא לפונקציה או לייבא חבילה שלא קיימות, כי השם נשמע סביר. חפשו imports לא מוכרים לפני שאתם מתקינים אותם; הזיות של AI מסביר למה זה קורה.
• מקרי קצה שקטים. קוד שעובד במסלול השמח וקורס על רשימה ריקה. פירוט מקרי הקצה בפרומפט, ובקשה לבדיקות, הם התיקון הזול ביותר.
• שינויים שקטים. כשמבקשים תיקון בקובץ ארוך, המודל עלול גם לשנות שמות או לארגן מחדש קוד שלא ביקשתם. הוסיפו "שנה רק את מה שצריך ופרט כל שינוי שעשית".

כשהקוד רץ אבל מתנהג לא כמו שצריך, עברו לפרומפט דיבוג: פרומפטים לדיבוג מסביר מה להדביק. לפני שממזגים משהו חשוב, סבב שני עם פרומפט ל-code review יכול לתפוס בעיות שהפרומפט לכתיבה לא חשב לשאול עליהן.