שיטות מומלצות

הסוכן ב-Android Studio הוא שותף לתכנות שמאיץ את תהליך העבודה של הפיתוח. הוא יכול ליצור קוד, לסכם נושאים מורכבים, למצוא משאבים ספציפיים ועוד. המפתח למיצוי הפוטנציאל של הסוכן הוא תקשורת יעילה.

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

חשוב לספק תשובה מפורטת

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

הטמעת פונקציונליות חדשה:

מה מומלץ לעשות

איך לקבל תמיכה במצלמה לאפליקציה באמצעות CameraX? חשוב לכלול את כל התלות וההרשאות שדרושות כדי להשתמש בספרייה.

מה אסור לעשות

איך מוסיפים תמיכה במצלמה לאפליקציה?

יצירת קוד:

מה מומלץ לעשות

כתוב פונקציית השהיה ב-Kotlin שמשתמשת בספריית Coil כדי להוריד תמונה ממחרוזת נתונה של כתובת URL.

הפונקציה צריכה להיקרא fetchImageAsBitmap. הפונקציה צריכה לקבל כארגומנטים את Context ואת כתובת ה-URL של String, ולהחזיר Bitmap שניתן להגדיר כ-null. אם יש שגיאה ברשת או בפענוח, היא אמורה ללכוד את החריגה, לרשום אותה ביומן ולהחזיר null.

מה אסור לעשות

לכתוב פונקציה להורדת תמונה.

להסביר את הקונספט:

מה מומלץ לעשות

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

מהן האפשרויות שלי להמשיך להפעיל את האפליקציה בזמן שהמשתמש עושה דברים אחרים במכשיר? מהן הדרישות לגבי רמת ה-API ומהן ההשלכות על חיי הסוללה בכל אחת מהגישות?

מה אסור לעשות

הסבר על שירותי Android.

תארו את מבנה התשובה

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

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

מבנה התשובה:

מה מומלץ לעשות

יוצרים ישות של חדר לפרופיל משתמש. הוא צריך להכיל את השדות id,‏ userName,‏ email ו-memberSince. השדה id אמור להיווצר באופן אוטומטי. השדה memberSince צריך לייצג חותמת זמן.

מה אסור לעשות

יוצרים ישות של חדר לפרופיל משתמש.

אם אתם שואלים שאלה פתוחה, בקשו מספר מסוים של אפשרויות.

הגבלת התשובה:

מה מומלץ לעשות

אילו כלים זמינים לאופטימיזציה של ביצועי האפליקציה? תן לי רשימה של שלושת המובילים.

מה אסור לעשות

אילו כלים זמינים לאופטימיזציה של ביצועי האפליקציה?

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

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

שימוש בהנחיות ברצף:

מה מומלץ לעשות

פרומפט 1: מודל הנתונים
קודם כל, תיצור מחלקת נתונים ב-Kotlin בשם User. היא צריכה לכלול שלושה מאפיינים: id (מספר שלם), name (מחרוזת) ו-email (מחרוזת).

פרומפט 2: שכבת הרשת
עכשיו, צור ממשק API של Retrofit בשם ApiService. היא צריכה לכלול suspend fun יחיד בשם getUsers() שמחזיר List<User>.

פרומפט 3: ניהול מצב
בשלב הבא, תכתוב UsersViewModel שיש לו תלות ב-ApiService. ‫UsersViewModel צריך לחשוף StateFlow של מחלקה UiState אטומה שיכולה לייצג מצבי Loading, Success(users: List) ו-Error(message: String). צור פונקציה ב-ViewModel כדי לאחזר את המשתמשים ולעדכן את המצב. כתוב בדיקות יחידה עבור הפונקציות החדשות.

פרומפט 4: שכבת ממשק המשתמש
לבסוף, כתוב פונקציית Jetpack Compose בשם UserListScreen שמקבלת את UiState כפרמטר. השתמש במצב when כדי להציג CircularProgressIndicator למצב הטעינה, LazyColumn של שמות משתמשים למצב ההצלחה ורכיב Text עם הודעת השגיאה למצב השגיאה. הוסף בדיקות לאימות הפונקציונליות החדשה.

מה אסור לעשות

צור מסך Jetpack Compose שמביא רשימה של משתמשים מ-JSON API ומציג אותם ברשימה. האפליקציה צריכה לכלול ViewModel שמשתמש ב-Retrofit ובקורוטינות, מאגר לטיפול בלוגיקת הנתונים, מחלקת נתונים User, והיא צריכה להציג מצבי טעינה ושגיאה.

הגדרת ההקשר

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

  • לצרף תמונות כדי להמחיש את ממשק המשתמש שאתם רוצים ליצור או את ארכיטקטורת האפליקציה שאתם מנסים להבין.
  • לצרף קבצים כדי להדגיש חלקים רלוונטיים בבסיס הקוד.
  • אתם יכולים להשתמש בקובצי .aiexclude כדי שהסוכן יתעלם מחלקים מסוימים בבסיס הקוד.
  • אתם יכולים להשתמש בקובצי AGENTS.md כדי לתת הוראות ספציפיות לפרויקט ולשתף אותן עם הצוות. כשמשתמשים בקובצי AGENTS.md, כדאי להשתמש בכותרות ובפורמט של Markdown כדי שההוראות יהיו ברורות.
  • כשמשתמשים במצב סוכן, מגדירים שרתי MCP כדי להרחיב את הידע והיכולות של הסוכן באמצעות הסביבה החיצונית.

תבקשו הסברים

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

חידוד ההוראות

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