דיבור: לבדוק בקשה קולית לפני שסוכן הקוד מתחיל

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

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

מודל התמלול הוא חלק מהמוצר

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

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

הכתבה מקומית ושליחת משימה הן שתי פעולות

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

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

קוראים את הבקשה לפני שמפעילים אותה

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

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

בקשה קטנה שאפשר לבדוק בסיום

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

אחרי הריצה, השווה את הקבצים שהשתנו לבקשה והרץ את הבדיקה המתאימה. האם היא באמת בודקת את המקרה שביקשת? האם השתנו גם קבצים שלא היו חלק מהמשימה? הודעת ״סיימתי״ של הסוכן לא מוכיחה שהבדיקה עברה. אישור להתחיל ובדיקה בסיום הם שני שלבים שונים.

איך בודקים תהליך כזה במוצר שלך

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

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

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

דיבור: המוצר וההכתבה המקומית

מדריך דיבור למק: בדיקת בקשה והפעלת סוכן

ליישם את זה ברעיון שלך

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

פיתוח מוצר עם דניאל גולדמן