6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
חלק ד׳ · מאת פלג דרור

6 פיצ'רים בקודקס שלא הכרתם

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

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

שער הקרוסלה

מה תדעו לעשות

1. Caveman: תשובה קצרה שעדיין אפשר לעבוד איתה2. I Have ADHD: להבין מה עושים עכשיו3. Ponytail: להשתמש במה שכבר עובד4. RTK: פחות רעש בפלט של פקודות5. Headroom: לבדוק דחיסה בלי לאבד את התשובה6. QMD: למצוא החלטה גם כשהניסוח השתנה
בחרו פרק שפותר לכם בעיה עכשיו. בכל פרק יש הסבר, תרגיל, בקשה להעתקה ובדיקת הצלחה. אין צורך להפעיל את כל הכלים יחד.
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
פרק 1 · שקופית 2

Caveman: תשובה קצרה שעדיין אפשר לעבוד איתה

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

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

איך מנסים את זה

  1. פתחו את המאגר ואת INSTALL.md. בחרו במסלול skill שמתאים לקודקס. אל תבחרו אוטומטית במסלול Proxy רק כי הוא מופיע באותו עמוד. בקשו מהסוכן לציין מה יתווסף ולאיזו תיקייה לפני ההתקנה.
  2. אחרי התקנת הסקיל, פתחו שיחה חדשה ובקשו במפורש להשתמש ב-Caveman. בממשקים שמציעים בוחר סקילים בחרו בו שם. לא חייבים להסתמך על כך שפקודת סלאש תעבוד בכל ממשק.
  3. בחרו שאלה אמיתית שכבר קיבלתם עליה תשובה ארוכה. נסו אותה במצב הקצר, ובדקו אם עדיין מופיעים המסקנה, ההוכחה והמידע הדרוש לביצוע. ספירת מילים לבדה לא מספיקה.
  4. נסו גם בקשה לתוצר ארוך, למשל מדריך בן שישה פרקים. הגדירו במפורש שקיצור חל על עדכוני השיחה. אם התוצר נפגע, כבו את המצב באמצעות stop caveman או בקשו normal mode.

בקשה מוכנה להעתקה

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

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

Caveman: המאגר והמסלוליםהוראות התקנה לפי סביבת עבודה
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
פרק 2 · שקופית 3

I Have ADHD: להבין מה עושים עכשיו

זה סקיל חיצוני שמסדר תשובות סביב הפעולה הבאה ושלבים ברורים. הוא יכול להתאים גם למי שפשוט מאבד את החוט בתשובות ארוכות. אין צורך לתאר את עצמכם כבעלי אבחנה כלשהי כדי להשתמש בו. ב-Codex ההתקנה וההפעלה נפרדות: לפי INSTALL.md, מפעילים במפורש עם $i-have-adhd.

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

איך מנסים את זה

  1. בהתקנת Codex CLI, הוראות היוצר מציגות שתי פקודות נפרדות: codex plugin marketplace add ayghri/i-have-adhd --ref main ואחריה codex plugin add i-have-adhd@i-have-adhd. בדקו את סעיף Codex בקישור לפני הרצה, כי פקודות תוספים עשויות להשתנות.
  2. בדקו שההתקנה מופיעה באמצעות codex plugin list. פתחו שיחה חדשה והפעילו $i-have-adhd. הופעה ברשימת התוספים מוכיחה התקנה, לא שהסגנון כבר פעיל.
  3. תנו משימה עם כמה שלבים וקבעו מה הסוכן מבצע ומה אתם עושים. בקשו שיציג קודם את הפעולה הנוכחית, ואז רק את ההקשר הדרוש להבנתה.
  4. בדקו אם הפורמט עוזר לכם להמשיך בלי לקרוא שוב את כל השיחה. אם כבר מופעל Caveman, בדקו כל אחד בנפרד לפני שילוב. אחרת קשה לדעת מי שינה את התוצאה.

בקשה מוכנה להעתקה

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

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

I Have ADHD: מה הסקיל משנהINSTALL.md: סעיף Codex והפעלה
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
פרק 3 · שקופית 4

Ponytail: להשתמש במה שכבר עובד

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

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

איך מנסים את זה

  1. לפי README, מתקינים בטרמינל באמצעות codex plugin marketplace add DietrichGebert/ponytail ואז codex plugin add ponytail@ponytail. קראו את סעיף Codex העדכני לפני ההתקנה.
  2. היוצר מנחה לפתוח Codex CLI, לעבור על שני ה-hooks דרך /hooks ולאשר אותם לאחר בדיקה. נדרשת זמינות Node.js ב-PATH להפעלה האוטומטית. לאחר מכן מתחילים שיחה חדשה; בדסקטופ מפעילים מחדש את האפליקציה.
  3. בחרו שינוי קטן בפרויקט מוכר. בקשו קודם לזהות רכיב, פונקציה או תבנית קיימים שיכולים לפתור אותו, ולציין את הקובץ שבו הם נמצאים. אפשר לבדוק כך שהכלי עובד על הפרויקט ולא רק מצהיר על פילוסופיה.
  4. אחרי השינוי, בדקו את ההתנהגות שביקשתם ואת הבדיקות הרלוונטיות. אם הוחלט בכל זאת להוסיף רכיב, בקשו הסבר קצר למה הקיים לא הספיק.

בקשה מוכנה להעתקה

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

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

Ponytail: התקנה ל-Codex ופקודות
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
פרק 4 · שקופית 5

RTK: פחות רעש בפלט של פקודות

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

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

איך מנסים את זה

  1. התקינו את RTK דרך מסלול מערכת ההפעלה שמופיע במאגר. לאחר שהפקודה זמינה, החיבור המתועד לקודקס הוא rtk init -g --codex. הסימון -g מתייחס להגדרה גלובלית; קראו מה משתנה בה לפני הרצה.
  2. התחילו בהשוואה ידנית בין git status לבין rtk git status. שמרו לעצמכם מהו המידע שחשוב לכם לראות: קבצים שהשתנו, קבצים חדשים ומצב העבודה.
  3. בדקו שהסוכן משתמש בפועל בפקודות המסוננות לאחר הפעלה מחדש. עצם התקנת הכלי אינה מוכיחה שכל כלי קריאה בקודקס עובר דרכו.
  4. הריצו rtk gain כדי לראות את נתוני הכלי. השוו גם אם הסוכן פתר את המשימה במספר דומה של סבבים. כשצריך פלט מקורי אפשר להשתמש ב-rtk proxy עם הפקודה המתאימה, לפי התיעוד.

בקשה מוכנה להעתקה

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

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

RTK: התקנה, Codex ופקודות מדידה
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
פרק 5 · שקופית 6

Headroom: לבדוק דחיסה בלי לאבד את התשובה

Headroom הוא פרויקט חיצוני מתקדם עם ספרייה, Proxy, עטיפה לסוכנים וכלי MCP. במאגר מתועדת עטיפה ל-Codex וגם כלים בשם headroom_compress, headroom_retrieve ו-headroom_stats. זו תוספת לתשתית העבודה, ולכן כדאי להגיע אליה אחרי שזיהיתם תוכן ארוך שחוזר על עצמו.

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

איך מנסים את זה

  1. פתחו את README ובחרו מסלול אחד לבדיקה. לפי התיעוד, ה-CLI מגיע מחבילת Python בשם headroom-ai; חבילת npm היא ספריית TypeScript ואינה מספקת את פקודת headroom.
  2. בקשו מהסוכן להסביר את מסלול Codex המתאים לסביבה שלכם, את השינוי בניתוב ואת דרך החזרה. README מציג headroom wrap codex ו-headroom unwrap codex. אל תניחו שעיטוף CLI משנה אוטומטית כל שיחה באפליקציית הדסקטופ.
  3. אחרי הגדרה מאושרת, בדקו ניתוב באמצעות headroom doctor. בתיעוד מצוין שהעטיפה עשויה להוסיף גם Serena; בדקו אם זה נדרש לניסוי שלכם. אין צורך להוסיף שכבות שלא בודקים.
  4. בצעו את ניסוי שלוש השאלות. אם משתמשים במסלול MCP, בדקו גם שליפה של המקור דרך headroom_retrieve. רשמו תוצאה שגויה או פרט שנעלם, גם כאשר נתוני הדחיסה נראים מצוינים.

בקשה מוכנה להעתקה

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

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

Headroom: מסלולי התקנה ותאימות לסוכנים
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
פרק 6 · שקופית 7

QMD: למצוא החלטה גם כשהניסוח השתנה

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

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

איך מנסים את זה

  1. ההתקנה המתועדת היא npm install -g @tobilu/qmd, עם חלופה דרך Bun. לאחר ההתקנה בחרו תיקיית Markdown מצומצמת. אין צורך לאנדקס קבצים שאינם שייכים לתהליך שבודקים.
  2. הגדירו אוסף באמצעות qmd collection add עם הנתיב האמיתי ועם --name. לאחר מכן qmd embed מכין את החיפוש הסמנטי. בדקו שההכנה הושלמה לפני שמסיקים שחיפוש סמנטי אינו עובד.
  3. התחילו ב-qmd search עם מילה ידועה. לאחר מכן נסו qmd vsearch בניסוח אחר לאותו רעיון, ולבסוף qmd query לחיפוש משולב. אפשר להגביל לאוסף באמצעות -c ושמו.
  4. פתחו תוצאה עם qmd get לפי הנתיב או המזהה שהוחזר. רק אחרי שבדקתם את המקור בקשו מקודקס לנסח מסקנה. חיבור MCP אפשרי, אבל שימוש דרך ה-CLI מספיק לניסוי הראשון.

בקשה מוכנה להעתקה

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

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

QMD: התקנה, אינדוקס, חיפוש ו-MCP
6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
לצאת עם משהו שעובד

התרגיל שלכם והקבצים להמשך

בחרו כלי אחד לשבוע עבודה: Caveman אם הדיווחים ארוכים, I Have ADHD אם קשה להבין מה עושים עכשיו, Ponytail אם משימות קטנות מתנפחות, RTK אם פלט הפקודות עמוס, Headroom אם זיהיתם צורך בדחיסה רחבה יותר, או QMD אם הבעיה היא למצוא ידע קיים. שמרו דוגמת לפני ואחרי, תעדו מה השתנה והחליטו אם להשאיר. אל תחברו את כל השישה יחד בניסוי הראשון. אפשר לשלב כלים בהמשך, לאחר שיודעים איזה מהם עוזר ולמה. לפני הוספת שירות בתשלום, השוו את העלות הכוללת ואת איכות התוצאה במשימה מייצגת. מעבר לחיוב אצל ספק אחר אינו מוכיח שהעבודה תהיה זולה יותר. בנספח תמצאו תרגיל להשוואה כזאת.

דף ניסוי לכלי חיצוני

פתיחת הקובץ

כל קובצי העזר בחבילה אחת

כל קישורי ההורדה מובילים לקבצים באתר שלי. אפשר לפתוח אותם ישירות גם מתוך ה-PDF.

מקורות והרחבה

6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
בונוס · בחירת ספק תמונות

שירות תמונות נוסף: איך בודקים אם המעבר כדאי

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

לפני חיבור, אוספים את הנתונים

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

ניסוי שאפשר לשפוט

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

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

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

6 פיצ'רים בקודקס שלא הכרתם · חלק ד׳@peleg.auto
השלב הבא שלכם

לנסות על משימה שכבר מחכה לכם

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

לפני שסוגרים את המדריך:

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

המדריך וקובצי העזר, גם באינטרנט

לקריאת המדריך באתר
להורדת התבניות והסקילים

פלג דרור

הגיע הזמן לעשות Shift.

ללמוד להשתמש ב-AI כדי לחסוך זמן, לבנות דברים משלכם ולפתח מקורות הכנסה.

בואו להכיר את Shift

פלג דרור