Artifact הוא דף עובד ש-Claude בונה לצד השיחה - מחשבון, צ'קליסט, טופס קטן - שמשתמשים בו מיד ומשנים אותו בבקשה. הגבול חד: זה כלי, לא מערכת, ואין בו נתונים משותפים.
עיקרי הדברים
- משנים אותו בבקשה, לא בעריכת קוד. זה כל העניין - לולאת השיפור היא משפט, וזו הסיבה שמי שלא מתכנת באמת מסיים משהו.
- המועמדים הנכונים הם חישובים וצ'קליסטים שחיים בראש של מישהו או בגיליון שאף אחד אחר לא יכול להשתמש בו בבטחה.
- זה כלי, לא מערכת. כל דבר שדורש נתונים משותפים, רשומות שנשמרות לכולם, או חיבור למערכות העסק - הוא אפליקציה אמיתית.
- לאמת את הלוגיקה לפני שמישהו נשען עליה. מחשבון שנראה מקצועי ומחשב לא נכון גרוע מאין מחשבון, כי אנשים מפסיקים לבדוק.
Artifact הוא דף עובד ש-Claude בונה לצד השיחה - מחשבון, צ'קליסט, טופס קטן - שמשתמשים בו מיד. ומה שהופך אותו לשימושי למי שלא מתכנת: משנים אותו בבקשה, לא בעריכת קוד. "תוסיף שדה", "תשנה את החישוב", "תעשה את זה בעברית".
למה זה עובד למי שלא מתכנת
הבעיה עם "תבנה לעצמך כלי" הייתה אף פעם לא הכתיבה הראשונה - היא הייתה השינוי השני. מקבלים קוד, משהו לא נכון, ואז נתקעים, כי לתקן קוד צריך להבין קוד.
כאן לולאת השיפור היא משפט. רואים את הדף, אומרים מה לא בסדר, מקבלים גרסה מתוקנת. זו הסיבה שאנשים באמת מסיימים משהו במקום לצבור טיוטות.
מה שווה לבנות
הקריטריון: משהו שחוזר על עצמו, שהלוגיקה שלו קבועה, ושהיום חי בראש של מישהו או בגיליון שרק הוא יודע להפעיל.
מחשבונים
תמחור לפי פרמטרים, חישוב עלות משלוח, המרת יחידות בתחום שלך, חישוב שעות לחיוב. המקרה החזק ביותר - כי חישוב שגוי בגיליון של מישהו אחד הוא סיכון אמיתי.
צ'קליסטים תפעוליים
קליטת לקוח חדש, בדיקה לפני מסירה, סגירת חודש. הערך אינו ברשימה - הוא בכך שאותה רשימה מגיעה לכולם, במקום שכל אחד יזכור מה שהוא זוכר.
מחוללי טקסט
ממלאים כמה שדות ומקבלים ניסוח מוכן - אישור הזמנה, הודעת עדכון, תיאור לפריט. אחידות בלי תלות במי שכותב.
טבלאות החלטה
"איזה מסלול מתאים ללקוח כזה", "מה הזמן המשוער לסוג עבודה כזה". ידע שהיום נמצא אצל אדם אחד.
תצוגה של נתונים
להדביק נתונים ולראות גרף או פילוח. לניתוח חד-פעמי עדיף גיליון; artifact מתאים כשרוצים משהו שחוזרים אליו.
מה לא לבנות
זו הרשימה החשובה יותר, כי כאן מבזבזים זמן.
| הבקשה | למה לא |
|---|---|
| "מערכת ניהול לקוחות" | דורשת נתונים משותפים שנשמרים - זו אפליקציה |
| "טופס שהלקוחות ימלאו" | התשובות צריכות להגיע למקום מרכזי |
| "שיתחבר למערכת שלנו" | דורש אינטגרציה אמיתית |
| "שיזכור מה הזנתי אתמול" | דורש אחסון מרכזי |
| "שירוץ כל בוקר לבד" | אין מי שיפעיל - זו אוטומציה |
ההבחנה בשורה אחת: אם משהו צריך להישמר ולהיות זמין לאדם אחר או מחר, זו כבר מערכת.
וזו הבחנה שעולה כסף להתעלם ממנה. פרויקטים כושלים מתחילים ב"בניתי משהו קטן וזה עבד", ואז מנסים להרחיב אותו למשהו שהוא לא.
הסכנה: כלי שנראה מקצועי ומחשב לא נכון
זו הבעיה האמיתית, לא היכולת הטכנית.
דף מעוצב עם שדות וכפתור משדר סמכות. אנשים מזינים ומקבלים מספר, ואחרי כמה פעמים מפסיקים לבדוק. אם החישוב שגוי, השגיאה תתפשט בשקט לכל מי שמשתמש.
מה לעשות לפני שמישהו נשען על זה:
- לבדוק מול מקרה שאתה יודע את התשובה שלו. להזין נתונים אמיתיים מחודש שעבר ולוודא שהמספר תואם.
- לבדוק את הקצוות. אפס, ערך גדול מאוד, שדה ריק. שם נשברים דברים.
- לבדוק מקרה חריג אחד. הלקוח עם ההנחה המיוחדת, ההזמנה שחורגת מהכלל.
ואם הכלי מגיע לאנשים אחרים - לומר להם מה הוא לא מכסה. משפט אחד בראש הדף חוסך טעות.
נתונים
שתי נקודות שכדאי להחליט מראש:
- מה שמדביקים לתוך השיחה כדי לבנות את הכלי - יוצא מהמחשב. אם בונים מחשבון תמחור, אין צורך למסור את רשימת הלקוחות. לתאר את הלוגיקה, לא את הנתונים.
- מה שמזינים לכלי אחר כך נשאר בדפדפן של מי שמשתמש. כלי שאמור להחזיק מידע רגיש הוא בדיוק המקרה שבו צריך מערכת ולא artifact.
עברית
ממשק בעברית עובד, ושווה לבקש אותו במפורש - אחרת מקבלים אנגלית.
שתי נקודות לבדוק בפועל, לא להניח:
- כיווניות - שדות, תוויות וכפתורים בסדר הנכון, במיוחד כשיש מספרים לצד טקסט עברי.
- פורמט תאריך - יום/חודש ולא חודש/יום. זו טעות שנראית תקינה בכל יום מה-1 עד ה-12, ולכן היא נמצאת מאוחר.
מתי לעבור לבנייה אמיתית
שלושה סימנים שהגעת לגבול:
- אתה מדביק את אותם נתונים שוב ושוב. הכלי צריך לקרוא אותם, וזה אומר חיבור.
- יותר מאדם אחד צריך לראות את אותו מצב.
- התוצאה צריכה להיכנס למערכת. אם מישהו מעתיק מהכלי לתוך ה-ERP, נשארה עבודה ידנית.
אז זו כבר שאלת אוטומציה עם עלות ידועה - וכדאי לגשת אליה ככזו במקום להמשיך למתוח כלי קטן.
וזה בסדר גמור. Artifact שהוכיח שהרעיון עובד לפני שהשקעת בפיתוח הוא בדיוק מה שהוא אמור להיות: הדרך הזולה לגלות אם שווה לבנות.
שאלות נפוצות
מה זה Artifact של Claude במונחים מעשיים?
דף עובד שנבנה לצד השיחה - מחשבון, צ'קליסט, טופס קטן - שמשתמשים בו מיד ומשנים אותו בבקשה ולא בעריכת קוד. החלק האחרון הוא מה שהופך אותו לשמיש למי שלא מתכנת: לולאת השיפור היא משפט, ולכן אנשים מסיימים משהו במקום להיתקע בשינוי השני.
מה לא כדאי לנסות לבנות כ-Artifact?
כל דבר שדורש נתונים משותפים שנשמרים: מערכת ניהול לקוחות, טופס שהתשובות בו צריכות להגיע למקום מרכזי, כלי שזוכר מה הוזן אתמול, או כזה שמתחבר למערכות העסק או רץ לפי לוח זמנים. ההבחנה בשורה אחת - אם משהו צריך להישמר ולהיות זמין לאדם אחר או מחר, זו כבר מערכת.
מה הסיכון הגדול ביותר במחשבון שבניתי בעצמי?
שהוא נראה מקצועי ומחשב לא נכון - אנשים מזינים, מקבלים מספר, ואחרי כמה פעמים מפסיקים לבדוק, ולכן השגיאה מתפשטת בשקט. לפני שמישהו נשען עליו, לבדוק מול מקרה שאתה יודע את התשובה שלו, לבדוק את הקצוות (אפס, ערך גדול מאוד, שדה ריק), ולבדוק מקרה חריג אחד כמו הלקוח עם ההנחה המיוחדת.
האם צריך להעלות נתוני חברה כדי לבנות כלי?
לרוב לא - לתאר את הלוגיקה ולא את הנתונים. כדי לבנות מחשבון תמחור צריך את כללי התמחור, לא את רשימת הלקוחות, ומה שמדביקים לשיחה יוצא מהמחשב. מה שאנשים מזינים לכלי אחר כך נשאר בדפדפן שלהם, ולכן כלי שאמור להחזיק מידע רגיש הוא בדיוק המקרה שדורש מערכת אמיתית.
מתי כדאי לעבור מ-Artifact לפיתוח אמיתי?
שלושה סימנים: אתה מדביק את אותם נתונים שוב ושוב ולכן הכלי צריך לקרוא אותם, יותר מאדם אחד צריך לראות את אותו מצב, או שהתוצאה צריכה להיכנס למערכת ומישהו מעתיק אותה ידנית. בנקודה הזו זו שאלת אוטומציה עם עלות ידועה - ו-artifact שהוכיח את הרעיון קודם הוא בדיוק הדרך הזולה לגלות אם שווה לבנות.
להמשך קריאה
שירות רלוונטי
מערכות בהתאמה אישית
המערכת הפנימית שמחליפה את הגיליון שגדלתם ממנו.
על הכותב
יהונתן סעדיה
מהנדס פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מהנדס בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.