סקילים: להפוך תהליך שעבד פעם אחת לכלי קבוע

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

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

---

1. מה זה סקיל, בפועל

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

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

בראש קובץ ההוראות יש כמה שורות שמכילות שם ותיאור קצר של הסקיל. השורות האלה קטנות ולא נראות חשובות, והן החלק הכי חשוב בקובץ.

2. למה מאות סקילים לא עולים כלום

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

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

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

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

3. איך שומרים, ומתי

יש שני מסלולים, ושניהם לא דורשים מכם לכתוב שורה אחת.

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

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

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

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

4. מה חייב להיכנס פנימה

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

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

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

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

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

5. בלוק הסביבה שמתקן את עצמו

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

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

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

6. גלובלי מול מקומי

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

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

7. שיתוף במשרד: מכלי אישי לתשתית

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

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

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

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

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

8. להתקין סקיל של מישהו אחר

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

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

9. בטיחות: סקיל הוא קובץ הוראות

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

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

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

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

10. המלכודות

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

תיאור מעורפל, ולכן סקיל שלא נפתח לעולם

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

נשמר מוקדם מדי

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

הוא מתאר איך במקום מה

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

בלוק סביבה שהתיישן

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

עותקים מקומיים שהתפצלו

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

סקיל שמניח שהמחשב שלכם הוא כל העולם

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

סקיל מהאינטרנט בלי בדיקה

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

---

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

---

שאלות ותשובות