בקצרה: כל הכלים המובילים ממליצים היום על אותו סדר: קודם מפרט, אחר כך קוד. ל-Claude Code יש מצב תכנון שבו הוא רק קורא ומתכנן, ל-Lovable יש מצב Plan שכותב תוכנית לפני שנוגעים בקוד, ול-GitHub יש Spec Kit שמפריד בין מה שהמשתמש צריך לבין איך בונים את זה. מפרט טוב לכלי AI כולל היקף ומה לא נכלל, סיפורי משתמש עם קריטריוני קבלה, מודל נתונים, תפקידים והרשאות, ואיך בודקים שזה עובד. את התפקידים וההרשאות הכלים לא מבקשים, ובדיוק שם נולדות הפרצות.
למה AI צריך אפיון יותר מאדם
מפתח אנושי שלא יודע משהו שואל. כלי AI ממשיך. הוא בוחר את ההנחה הסבירה ביותר, ובונה לפיה מסך, טבלה ו-API. כשמתברר שההנחה שגויה, כבר יש שלוש שכבות שבנויות עליה.
יש גם בעיה הפוכה: הכלי עושה בדיוק את מה שביקשתם. אם בבקשה כתוב "רשימת הזמנות", הוא יבנה רשימת הזמנות. אם לא כתוב שמשתמש לא אמור לראות הזמנות של אחרים, גם זה לא ייבנה.
אפיון לכלי AI הוא לא מסמך ארוך יותר. הוא מסמך מפורש יותר. כל מה שאדם היה מבין מההקשר צריך להיות כתוב.
מה הכלים עצמם ממליצים
| כלי | מה הוא ממליץ לעשות לפני הקוד |
|---|
| Claude Code | מצב תכנון שבו הכלי רק קורא ומתכנן. לפיצ'רים גדולים התיעוד מציע שהכלי יראיין אתכם ויכתוב קובץ SPEC.md, ואת המימוש להריץ בסשן חדש. מפרט טוב לפי התיעוד מציין קבצים וממשקים, מה מחוץ להיקף, ומסתיים בבדיקה מקצה לקצה. |
| Lovable | מצב Plan שכותב תוכנית לפני הקוד: החלטות מפתח, הנחות, רכיבים, מודל נתונים וסדר המימוש. מומלץ לשינויים גדולים ולתכנון מסד הנתונים. |
| Cursor | קובצי כללים בפרויקט שהכלי קורא בכל בקשה: מוסכמות, ארכיטקטורה, מה אסור. |
| GitHub Spec Kit | שרשרת של מפרט, תוכנית ומשימות. המפרט מתאר מה המשתמש צריך ולמה, בלי טכנולוגיה. כל אי בהירות מסומנת, ועד הסוף לא אמור להישאר אף סימון פתוח |
| Kiro | שלושה קבצים: דרישות עם קריטריוני קבלה, תכנון עם ארכיטקטורה וזרימת נתונים, ומשימות שאפשר לעקוב אחריהן |
מה צריך להיות במפרט
- מה המוצר ולמי הוא מיועד. משפט אחד: מי המשתמש, מה הבעיה, ומה הפעולה המרכזית.
- היקף ומה לא נכלל. מה בונים עכשיו, ובאותה מידה מה לא בונים. בלי הרשימה השנייה הכלי ירחיב את ההיקף בעצמו.
- סיפורי משתמש עם קריטריוני קבלה. בצורה שאפשר לבדוק: בהינתן מצב, כאשר המשתמש עושה פעולה, אז המערכת מגיבה כך.
- מודל נתונים. הישויות, השדות החשובים והקשרים ביניהן. זה החלק שהכי יקר לשנות אחר כך.
- תפקידים והרשאות. מי רואה מה, מי משנה מה, ומה קורה כשמישהו מנסה לגשת למה שלא שייך לו.
- אינטגרציות. אילו מערכות חיצוניות, מה עובר ביניהן ומי המקור לכל נתון.
- איך בודקים. לפחות תרחיש מקצה לקצה אחד לכל יכולת, כולל תרחיש של משתמש שמנסה לעשות משהו אסור.
החור שהכלים משאירים
באף אחד מהמדריכים של הכלים התפקידים וההרשאות לא מופיעים כסעיף נפרד במפרט. Lovable מזכיר מצב של משתמש מחובר ולא מחובר, וזה הכי קרוב שיש. זה לא פרט שולי: פגיעות שבה כל משתמש יכול לקרוא נתונים של אחרים היא הבעיה הנפוצה ביותר באפליקציות שנבנו ב-AI.
לכן במפרט שאנחנו כותבים, ההרשאות הן סעיף חובה עם טבלה: תפקיד, מה רואה, מה משנה, ומה אסור. ולכל שורה של "אסור" יש תרחיש בדיקה.
איך זה נראה בעבודה
- שיחת אפיון: מה העסק צריך, מי המשתמשים, אילו נתונים.
- מפרט כתוב בפורמט שהכלי קורא: היקף, סיפורים, נתונים, הרשאות, בדיקות.
- הכלי מתכנן לפי המפרט, ואדם בודק את התוכנית לפני שנכתב קוד.
- המימוש נבדק מול קריטריוני הקבלה, כולל תרחישי האסור.
המפרט נשאר חי: כשמשנים דרישה, משנים אותה קודם במפרט ורק אחר כך בקוד. אחרת, אחרי חודש המפרט כבר יתאר מערכת אחרת.
שאלות נפוצות
צריך אפיון אם עובדים עם Lovable או Claude Code?
כן, ואפילו יותר. כלי AI ממלא כל חור בהנחה ובונה עליה קוד. גם הכלים עצמם ממליצים לתכנן לפני שכותבים קוד: ל-Claude Code יש מצב תכנון, ול-Lovable יש מצב Plan.
מה ההבדל בין אפיון רגיל לאפיון לכלי AI?
אפיון לכלי AI צריך להיות מפורש יותר: כל מה שאדם היה מבין מההקשר, כמו מי רשאי לראות מה, צריך להיות כתוב. הוא גם צריך להיות בפורמט שהכלי קורא, עם קריטריוני קבלה שאפשר לבדוק.
מה החלק החשוב ביותר במפרט?
מודל הנתונים וההרשאות. מודל נתונים שגוי הוא הדבר שהכי יקר לשנות אחר כך, והרשאות שלא נכתבו הן המקור הנפוץ ביותר לפרצות באפליקציות שנבנו ב-AI.
מה זה spec driven development?
גישה שבה כותבים מפרט לפני הקוד, ואחר כך תוכנית ומשימות שנגזרות ממנו. GitHub Spec Kit ו-Kiro בנויים סביב הגישה הזו, ו-Claude Code ו-Lovable תומכים בה דרך מצבי התכנון שלהם.
מי כותב את המפרט, אני או הכלי?
שניכם. הכלי יכול לראיין אתכם ולנסח טיוטה, אבל את ההחלטות, ובמיוחד מי רשאי לעשות מה, צריך לקבל אדם שמכיר את העסק.
מאיפה להתחיל
כתבו במשפט אחד מה המוצר ולמי הוא מיועד, ורשמו את התפקידים במערכת ומה כל אחד מהם רשאי לראות. משתי השורות האלה מתחיל כל מפרט טוב.
דברו איתי
קשור: תהליך אפיון מערכות, פיתוח מערכות ווב, אפיון ופיתוח CRM