איך לתת לסוכן קידוד מבוסס-AI ידע אמין על התחום

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

1. הפרידו בין כללי הפרויקט לבין נהלים תחומיים

התחילו בשתי שכבות. הראשונה היא חוזה מאגר קצר: מהו הפרויקט, איך הוא בנוי, אילו פקודות בונות ובודקות אותו, אילו קבצים אסור לשנות ומה פירוש “הושלם”. התיעוד של JetBrains על התנהגות סוכנים מתאר קבצי הוראות כמו AGENTS.md ו-CLAUDE.md כהנחיות שנעות עם המאגר וניתנות לשיתוף בין כלים.

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

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

2. כתבו skill סביב פער ידע

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

דוגמה ל-skill קטן של פרויקט:

---
name: navigation-upgrade
description: Use when changing the app's Navigation 3 setup or upgrading its related APIs.
---

Before editing:
1. Inspect the current dependency versions and existing navigation tests.
2. Read the project's navigation conventions.
3. Confirm the target API in the approved platform documentation.

While editing:
- Make the smallest vertical change that satisfies the requested behavior.
- Do not replace the navigation architecture without approval.
- Preserve existing deep-link and back-stack behavior unless the task says otherwise.

Done means:
- The focused tests pass.
- The relevant build or lint command passes.
- The response names changed files, checks run, and unresolved risks.

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

3. גרמו לסוכן לבדוק לפני שהוא פועל

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

לבקשה מעשית יש ארבעה חלקים:

1. הקשר: ציינו את התכונה, התיקיות הרלוונטיות והאילוצים.
2. תוכנית: בקשו רשימת קבצים ובדיקות לפני עריכה.
3. שינוי: בקשו את המימוש הקטן ביותר שעומד בקריטריוני הקבלה.
4. ראיות: דרשו את הבדיקות, ה-lint, הבנייה או האימות הידני שתומכים בתוצאה.

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

4. תנו לסוכן לולאת משוב קצרה

הנחיה תחומית מסבירה איך הפרויקט עובד, אבל בדיקות ניתנות להרצה מראות אם השינוי עובד. מדריך ה-TDD העדכני של VS Code מפריד בין שלב red שכותב בדיקה נכשלת, שלב green שמממש את המינימום, ושלב refactor שמשפר מבנה תוך שמירה על בדיקות ירוקות.

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

5. בדקו ועדכנו את ההנחיות

התייחסו ל-skill כתשתית הנדסית עם גרסאות. בדקו אותו כשה-framework משתנה, כשהסוכן חוזר על טעות, או כשבדיקה נעשית רועשת. הנחיות Android Skills מציגות skills כמועמדים ל-deprecation: מודלים משתפרים והוראות מסוימות נעשות מיותרות, בעוד APIs חדשים יוצרים פערים חדשים.

לולאת תחזוקה קלה:

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

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