1. מבוא
סוכני קידוד הופכים לחלק בלתי נפרד מפיתוח תוכנה יומיומי, ולכן בין אם אתם מהנדסים מנוסים או מפתחים מתחילים שרוצים להשיק את האפליקציה הראשונה שלהם, הדרך שבה אתם מפתחים ומה שאתם מפתחים משתנים באופן מהותי. כשמתחילים להשתמש בסוכני קידוד, בדרך כלל מתחילים עם הנחיות מסוג zero-shot – הוראה אחת שכתובה בשפה טבעית ומתארת בקצרה את מה שרוצים. אבל מהר מאוד מתחילות בעיות:
- הטיה של רצון לרצות: מודלים מקבלים לעיתים קרובות אילוצים או הנחות פגומים, במטרה להשלים את הבקשה שלכם במהירות האפשרית, ולא בודקים אם מה שהם יוצרים אכן עושה את מה שהתכוונתם.
- פער באימות: סוכנים, גם כשהם כותבים בדיקות, בדרך כלל לא בודקים את העבודה שלהם כדי לוודא שהיא פועלת. כשמנסים להשתמש באתרים בדפדפן פעיל, אפשר לגלות באגים נסתרים, פריסות שבורות ופקדים שלא נגישים.
- חוב טכני: בגלל האופן שבו המודלים מאומנים ועובדים, הקוד שהם כותבים נוטה להיות מבוסס על דפוסים ישנים ולא עדכניים. כך נוצר חוב טכני שדורש יותר טוקנים, יותר זמן ומאמץ מצד בני אדם ומכונות כדי לנהל אותו. חוב טכני יכול אפילו להשפיע לרעה על חוויית המשתמש.
תוכנית הפעולה בת 4 השלבים
כדי לעזור לסוכני התכנות ליצור קוד טוב יותר שמתאים יותר לדרישות שלכם, כדאי לפעול לפי מחזור החיים של פיתוח מוצרים בן 4 שלבים:
- תכנון ועיצוב: כותבים יחד עם הסוכן מסמכי דרישות מוצר (PRD), ומבקשים ממנו ליצור אב טיפוס ולעצב את מסמכי הדרישות בדפדפן לפני שמתחילים בהטמעה של הייצור. לאחר מכן, יוצרים טיוטה של מסמכי עיצוב ארכיטקטוני (מפרטים) ממסמכי הדרישות והעיצובים לפני שמתחילים לכתוב קוד.
- תכנות ובנייה: במקום להשתמש בפרומפט zero-shot, אפשר להנחות את הסוכנים לבנות לפי מסמכי ה-PRD, העיצובים והמפרטים, ולגרום לסוכן אחר לבדוק את העבודה.
- חוזרים על הפעולה: חוזרים על שלבים 1 ו-2 לכל תכונה חדשה שרוצים להוסיף.
- פריסה: משלוח לסביבת הייצור.
במסמך הזה מוסבר איך להשתמש בסוכני AI כשותפים פעילים לשיתוף פעולה, עם שיטות שמטרתן לעזור לכם לצמצם את החוב הטכני ולשפר את איכות קוד הפלט. אתם משתמשים ב-Antigravity בשילוב עם Modern Web Guidance ו-DevTools for Agents כדי ליצור משחק מילים פשוט ולשפר אותו באמצעות יכולות AI. אחר כך תוכלו לפרוס אותו ב-Google Cloud באמצעות Firebase ולשתף אותו עם חברים ובני משפחה.
מה תלמדו
- איך להתייחס למשימות תכנות באמצעות AI כאל מחזורי חיים מינימליים של פיתוח מוצרים.
- למה כדאי להפריד בין דרישות המוצר לבין מפרטים ארכיטקטוניים.
- איך לתזמן תהליכי עבודה של כמה סוכנים כדי ליצור אב טיפוס ישירות בדפדפן ולבדוק את הקוד.
- איך להשתמש בכישורים ובכלים של צד שלישי כדי לשפר את תהליך הפיתוח ואת חוויית המשתמש.
- איך פורסים אפליקציות אינטרנט ישירות בסביבת הייצור באמצעות Firebase MCP.
דרישות מוקדמות
- חשבון Google אישי ופרויקט ב-Google Cloud או ב-Firebase (הוראות מופיעות במאמר בנושא הגדרת פרויקט)
- היכרות מסוימת עם HTML, CSS ו-JavaScript.
- דפדפן אינטרנט כמו Chrome.
- Node.js מותקן (מומלץ להשתמש ב-LTS).
2. הגדרת הפרויקט
חשבון Google
אם עדיין אין לכם חשבון Google אישי, אתם יכולים ליצור חשבון Google.
כניסה למסוף Google Cloud
נכנסים למסוף Google Cloud באמצעות חשבון Google אישי.
הפעלת החיוב
כדי להגדיר חשבון לחיוב לשימוש אישי, עוברים להפעלת החיוב במסוף Cloud.
יצירת פרויקט Firebase
- עוברים אל מסוף Firebase ונכנסים באמצעות חשבון Google אישי.
- לוחצים על הוספת פרויקט (או על יצירת פרויקט).
- באשף ליצירת פרויקטים:
- מזינים שם לפרויקט (למשל,
wordup-web-app) או משתמשים מחדש בפרויקט בענן של Google שהגדרתם במהלך הגדרת הפרויקט.
- מזינים שם לפרויקט (למשל,
- קישור החשבון לחיוב
- בסרגל הצד במסוף Firebase, מאתרים את תג התוכנית בתחתית (התג הוא Spark). לוחצים על שדרוג.
- בוחרים בתוכנית שלם תוך כדי.
- בוחרים את החשבון לחיוב שהגדרתם בשלב הגדרת הפרויקט.
- מאשרים את הבחירה כדי לצרף את החשבון לחיוב לפרויקט. (אירוח ב-Firebase מספק תוכנית נדיבה בחינם. בדרך כלל, השלמת ההדרכה הזו לא כרוכה בתשלום).
התקנת כלים
- Antigravity 2.0: רתמת התכנות האג'נטית העיקרית שאתם עובדים איתה, בשילוב עם מודל Gemini Flash העדכני ביותר לתכנות מהיר ברמה גבוהה.
- Modern Web Guidance: סקיל לסוכני תכנות שיעזור להם לכתוב קוד CSS, HTML ו-JavaScript מודרני. התקנה דרך Antigravity Settings > Customization > Build With Google Plugins > Modern Web Guidance.
- כלי פיתוח לסוכני AI: מאפשרים לסוכני AI להפעיל את Chrome, לבדוק DOM פעיל, לבדוק פריסה ולבצע ניפוי באגים בזמן ריצה. התקנה דרך Antigravity Settings > Customization > Build With Google Plugins > כלי פיתוח ל-Chrome ו-Antigravity Settings > Customization > Add MCP Servers > כלי פיתוח ל-Chrome לסוכני AI.
- שרת ה-MCP של Firebase: להגדרת פרויקט חלקה ולפריסות בהנחיה אחת. התקנה דרך Antigravity הגדרות > התאמה אישית > Build With Google Plugins > Firebase and Antigravity Settings > התאמה אישית > Add MCP Servers > Firebase.
3. מתחילים עם תוכנית
כשמשתמשים בסוכני קוד, יש פיתוי נפוץ לשלוח הנחיה ללא דוגמאות ("תבנה לי משחק מילים") ולקוות לטוב. כמעט תמיד זה גורם לדילוג על מקרים קיצוניים, לבסיסי קוד נפוחים ולמחזורים אינסופיים של תיקון באגים.
במקום זאת, כדאי להתייחס לכל משימה כאל מחזור חיים קצר של פיתוח מוצר. לאגנטים של כתיבת קוד יש כלים למחקר ולהסקת מסקנות, שמאפשרים להם לשמש כשותפים לשיתוף פעולה ולעזור לכם להבהיר את הרעיונות שלכם לפני שכותבים קוד. הפעולה של דיבור על הרעיון עוזרת לכם למצוא ולענות על שאלות לפני שהן הופכות לבעיות – בהנדסת תוכנה זה נקרא ניפוי באגים באמצעות ברווז גומי. אתם יכולים להשתמש בסוכני הקידוד שלכם כבובות גומי כדי לתכנן את הפרויקטים והתכונות שלכם.
אתם מפתחים משחק מילים קליל. מנחים את הסוכן לעזור לכם לעצב את המשחק שאתם רוצים.
I want to make a casual word guessing game. Go do deep research on those kinds
of games, then ask me questions to help me write a PRD for the game's features.
זו הצורה הבסיסית של ההנחיה – אתם יכולים לשנות אותה בהתאם לצרכים שלכם. העיקר הוא לבקש ממנו לבצע מחקר מעמיק ולשאול אתכם שאלות על סמך המחקר הזה, כדי לעזור לכם לתכנן את העבודה.
כדאי להתחיל עם ההנחיה הזו כי עבודה עם סוכני קידוד כוללת הרבה בדיקות. פירוק של תוכנית הטמעה מלאה לחלקים קטנים וממוקדים מקל מאוד על הבדיקה, מאפשר לזהות מקרים חריגים בשלב מוקדם, יכול להוסיף ידע שלא נכלל בנתוני האימון של הסוכן, ובעיקר מאפשר לכם לקחת יותר הפסקות בין הבדיקות.
- הפרדה בין 'מה' ל'איך': הגדרת חוויית המשתמש והיקף המוצר במסמך רשמי של דרישות המוצר (PRD) מפרידה בין מה שרוצים שיקרה לבין איך זה מיושם, ומאפשרת להתמקד בהיבט אחד של פיתוח המוצר בכל פעם במקום בהכול בבת אחת.
- זיהוי מוקדם של מקרים חריגים: מפגש אינטראקטיבי של שאלות ותשובות מאלץ אתכם להבהיר את הדרישות לפני שמתחילים בתכנון או בהטמעה.
- מחקר פעיל של סוכן: מכיוון שהאימון של הסוכן מוגבל לתאריך מסוים והמידע בו מסוכם מאוד, שליפת מידע ממחקר פעיל יכולה לספק מידע חדש שהסוכן לא היה מקבל אחרת.
תרגיל 1
עכשיו תורך. מגדירים את הפרויקט ויוצרים את מסמך דרישות המוצר (PRD).
- מוסיפים הוראה לקובץ
AGENTS.mdכדי לשמור את הפלט ב-docs/plans/{{YYYY-MM-DD}}-{{description}}.md. - מריצים את הנחיית המחקר הקודמת, עם כל השינויים שרוצים, כדי ליצור את מסמך דרישות המוצר.
- [יעד שאפתני] מעדכנים את קובץ ה-
AGENTS.mdעם פעולות שהסוכן מבצע ולא מוצאות חן בעיניכם, ומריצים שוב את ההנחיה.
4. עיצוב בדפדפן
עיצוב ממשק משתמש סטטי מסתמך על מוקאפים שלרוב נראים מדהימים, אבל לא תמיד לוקחים בחשבון מקרים חריגים, מגבלות ואינטראקציות בפועל של משתמשים. בדומה לקוד, אם תבקשו מסוכן AI "לעצב" את אפליקציית האתר שלכם, תקבלו עיצובים גנריים (לרוב סגולים).
באפליקציות אינטרנט, אפשר להשתמש ביכולת של הסוכן לשלוט בדפדפן אינטרנט באמצעות כלי הפיתוח לסוכנים כדי לעצב בדפדפן. בין אם אתם מעצבים שרוצים לשפר את איכות העיצובים, מתכנתים או בונים שרוצים לשפר את ממשק המשתמש ואת חוויית המשתמש של הפרויקט, או שאתם עובדים ביחד, עבודה במדיום שבו אתם בונים את הפרויקט תניב תוצאות טובות יותר.
עיצוב בדפדפן מאפשר גם לתאם בין כמה סוכנים שעובדים יחד כדי ליצור פלט אחד. סוכנים משנה הם סוכנים עם אישיות ומטרות ספציפיות שאפשר לתאם ביניהם כדי להפיק תוצאות טובות יותר מאשר סוכן יחיד שעובד לבד. בעזרת עיצוב, אתם יכולים לבקש מסוכן לעיצוב חזותי, מסוכן לחוויית משתמש ומסוכן לנגישות לעבוד יחד כדי לעזור לכם בעיצוב, ולהציג לכם את העיצוב ישירות בדפדפן.
מפעילים חלונית של סוכני עיצוב שיעזרו לכם לבחור עיצוב על סמך מסמך דרישות המוצר (PRD).
Using the PRD, start a panel of expert agents: one UX design, one web
accessibility, and one for visual design, and have them work together to design
3 different UI mockups and show them to me in-browser.
כשמעצבים במדיום שבו בונים את האתר, במקרה הזה האינטרנט, במקום במדיום סטטי, אפשר לזהות מקרים חריגים ומגבלות שקשה לנהל בדרך אחרת, ולקבל משוב חזותי מיידי שמשקף את המצב בפועל.
תרגיל 2
עכשיו תורך. מעצבים את הפרויקט.
- מריצים את הנחיית העיצוב הקודמת, עם כל השינויים שרוצים, כדי ליצור את העיצוב. כדאי לכלול רעיונות לסגנונות עיצוב שונים שאתם רוצים לראות (למשל: מודרני, משעשע, מציאותי וכו').
- בוחרים עיצוב שמוצא חן בעיניכם ומשפרים אותו בעזרת הסוכן.
- מבקשים מהנציג לעדכן את מסמך דרישות המוצר כך שיפנה לעיצוב המוסכם.
- יעד מתקדם: מריצים בדיקות נגישות ובדיקות עיצוב רספונסיבי לעיצוב שבחרתם, ומשנים את העיצוב על סמך תוצאות הבדיקות.
5. כתיבת מפרט
אחרי שאישרתם את מסמך דרישות המוצר ('מה לבנות') ובחרתם עיצוב חזותי ('איך זה ייראה'), צריך להגדיר את הארכיטקטורה ('איך לבנות את זה').
מסמך תכנון טכני או מפרט – מפרט בקיצור – מפרט את מבני הקבצים, ניהול המצב, ממשקי הרכיבים, צינורות האירועים והתלות. יצירת מפרט לפני כתיבת קוד מאפשרת לזהות חוסר התאמה ודפוסי קידוד לא רצויים בשלב מוקדם, לפני שהם הופכים לקוד שקשה יותר להבין ולשכתב.
Write a detailed technical design document on how to implement the game with
the chosen design.
למה אתם עושים את זה
- בהירות ארכיטקטונית: הגדרה של היררכיית הרכיבים וזרימת מעבר המצבים (למשל,
Idle←InGame←EvaluatingGuess←GameOver) מונעת תנאי מירוץ וקוד ספגטי שביר. - התאמה לתקנים מודרניים: כשהאפשרות Modern Web Guidance מופעלת, הסוכן מתייחס לתקנים מודרניים (לדוגמה, שאילתות CSS
@container, רכיבימובנים לחלונות קופצים או לשכבות-על של עזרה, ומודולים של ES מודולריים) במקום לשלוף ספריות כבדות מדור קודם. - ביקורות בשלבים: הפרדה בין הביקורת על מסמך PRD פונקציונלי לבין הביקורת על מסמך עיצוב טכני מאפשרת להעריך את הארכיטקטורה בנפרד מחוויית המשתמש.
תרגיל 3
- מנחים את
AGENTS.mdלשמור את הפלט בתיקייה הנוכחית:PRDs should _always_ be written to the current project's root in `docs/plans/{{YYYY-MM-DD}}-{{description}}.md` format - מריצים את ההנחיה ליצירת מסמך תכנון ובודקים אותו כדי לוודא שהוא כולל היבטים כמו מבנה הספריות, טיפול באירועים ואחסון.
- יעד שאפתני: אם אפשר, כדאי להוסיף תרשימי Mermaid כדי להסביר את זרימת המצב באפליקציה.
6. לבסוף, יוצרים את האפליקציה
אחרי שיוצרים את מסמך ה-PRD, את המוקאפ של ממשק המשתמש ואת מסמך העיצוב, הגיע הזמן להתחיל לבנות. שלושת הפריטים האלה הם ההנחיות הברורות והחד-משמעיות שהסוכנים צריכים כדי לדעת מה הם צריכים ליצור.
הנה עוד הזדמנות טובה להשתמש בסוכני משנה. אפשר להריץ אותן אחרי בניית הקוד כדי לבדוק עד כמה מה שנבנה תואם לעיצובים המקדימים שלכם, ועוד אחת כדי לבדוק את איכות הקוד של מה שנבנה.
Use the PRD, design doc, and mockup to implement the site, then send out 2
agents, one to check how closely you followed the requirements, and one to
review the code.
למה אתם עושים את זה
פיתוח מבוסס-מפרט עם בודקים ראשוניים מספק לסוכן שלכם דרישות ברורות שנבדקו מראש, שמהן הוא יכול להתחיל לבנות, וגם מאפשר לעוד מישהו לבדוק שהוא פעל לפי התוכנית לפני שהיא מגיעה אליכם. כך משפרים את האיכות והדיוק.
- דרישות שנבדקו: הנציג לא צריך לנחש מה אתם רוצים. כבר בדקתם את הכול חוץ מההטמעה לפני שנכתב קוד כלשהו.
- מבט רענן: סוכן ביקורת שנוצר בהקשר חדש לא מוטה בגלל בניית בסיס הקוד, ולכן הוא יעיל באיתור מקרים קיצוניים שלא טופלו, דרישות הטמעה חסרות ופרטים אחרים בקוד או במוצר שלא נבדקו.
תרגיל 4
- מריצים את ההנחיה לבנייה ומציינים את הקבצים שרוצים ש-Gemini יבדוק.
- צופים בפלט בזמן ההרצה. תוכלו לראות את התהליך שבו הוא מנסה להבין את הדרישות שלכם ולבנות את התוצאה. אם נראה שמשהו משתבש, אפשר לעצור אותו ולתקן אותו.
- מריצים את שרת הפיתוח כדי לראות את האתר הסופי ולבדוק את העבודה.
- יעד מאתגר: מריצים את התהליך הזה שוב כדי להוסיף בדיקות אוטומטיות.
- יעד מאתגר: בחרו מסגרת ספציפית או סטאק תוכנות שבהן תרצו שה-AI יבנה את האתר – אם מסמך דרישות המוצר, ההדמיה ומסמך העיצוב מופרדים, יהיה קל להתאים אותם למסגרות או לסטאקים שונים.
7. פריסה בסביבת הייצור
תכננתם, עיצבתם וכתבתם קוד. מה נשאר? פריסה בסביבת הייצור.
Deploy this site to my Firebase project [YOUR_PROJECT_ID] using Firebase
Hosting.
תרגיל 5
- מריצים את הנחיית הפריסה ומחליפים את מזהה הפרויקט.
- מעתיקים את כתובת ה-URL של האירוח בשידור חי שקיבלתם מהנציג.
- פותחים את כתובת ה-URL הפעילה כדי לוודא שהיא הוטמעה ופועלת.
- יעד שאפתני: שימוש בכלי הפיתוח של סוכנים כדי להריץ בדיקה של Lighthouse באתר הייצור, לבצע שינויים כדי לשפר את הציון של Lighthouse ולפרסם את העדכונים.
8. [Optional] שיפורים באמצעות AI
משחק המילים שלך פועל עכשיו באופן מלא באמצעות מילון סטטי. כדי לשנות את המילון הסטטי למילה דינמית, אפשר במקום זאת להשתמש במודל שפה מקומי קטן מ-Prompt API כדי ליצור הנחיה בכל פעם.
האפשרות הזו לא זמינה בכל המכשירים, ולכן צריך להשתמש בשיפור הדרגתי כדי לבדוק אם ה-API והמודל זמינים. אם כן, משתמשים בהם. אם לא, חוזרים לרשימה הסטטית.
תרגיל 6
זה הזמן ליישם את כל מה שלמדתם.
- כדאי לעבוד עם נציג התמיכה כדי לכתוב מסמך PRD לשימוש ב-Prompt API כדי ליצור מילה נסתרת תקינה.
- עיצוב סרגל ההתקדמות של ההורדה וממשק המשתמש של שילוב ה-AI בדפדפן.
- כתיבת מפרט להטמעה. (הערה: כדאי להריץ סוכן כדי לוודא שנעשה שימוש בתחביר הנכון של ה-API).
- מפתחים את התכונה החדשה.
- פורסים אותו בסביבת הייצור.
9. סגירת קצוות
מעולה. יצרתם, שיפרתם, שכללתם ופרסתם בהצלחה אפליקציית אינטרנט מודרנית, נגישה ומתקדמת מבוססת-AI, תוך שימוש בשיטות מומלצות לכתיבת קוד באמצעות סוכנים.
מה למדתם
- תהליכי עבודה של סוכני AI שמבוססים על מוצרים: איך התייחסות למשימות כאל מחזורי חיים של מוצרים קטנים (PRD → Design → Spec → Build) מפחיתה את החוב, את העלויות של בדיקות ואת החיכוך שנוצר כתוצאה מהתקשורת הלוך ושוב.
- פאנלים של מומחים עם כמה סוכני AI: איך הפעלה של כמה סוכני משנה של AI יכולה לעזור לשפר את האיכות והדיוק של העבודה.
- PRD לעומת מסמך עיצוב: למה הפרדה בין היקף הפונקציונליות (התוכנית) לבין הארכיטקטורה הטכנית (המפרט) היא תהליך מדויק יותר וקל יותר להרחבה מאשר הנחיה ליצירת תכונה ללא דוגמאות.
- פריסה חלקה: איך משתמשים בשרתי MCP (כמו Firebase MCP) כדי לייעל את הגישה למערכות צד שלישי, כמו פריסת האתר.