פרומפטים לקלוד לתכנות: דיבוג, ריפקטור וסקירות ארכיטקטורה

ארבעת האילוצים שגורמים לכל פרומפט למטה לעבוד

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

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

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

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

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

דיבוג

1. השערות מסודרות לפי סבירות

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

2. הבאג שמתקן לפעמים

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

3. זה עובד אצלי בלוקאלי

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

4. הסבירו את התיקון לפני שאני מיישם אותו

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

סקירת קוד

5. סקירת diff

סקרו את ה-diff הזה כסוקר תובעני. קטגוריות בסדר עדיפות: באגים בנכונות, בעיות אבטחה, דפוסי כשל שלא טופלו, מצבי race condition, ואז סטייל. לכל ממצא תנו חמורות, את השורה הספציפית, ולמה זה חשוב בקודבייס הזה ולא באופן כללי. אל תתייחסו לפורמטינג. אם ה-diff תקין, אמרו את זה בלי ליצור ממצאים. קונבנציות: [תיאור]. Diff: [הדבקה].

6. סבב האבטחה

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

7. ביקורת דפוסי כשל

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

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

ריפקטור וארכיטקטורה

8. תוכנית ריפקטור

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

9. טענו את הצד השני

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

10. הבינו מה קיבלתם בירושה

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

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

בדיקות

11. הבדיקות שלא הייתם כותבים

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

12. בדקו את חבילת הבדיקות

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

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

דפוס חוות הדעת השנייה

ההרגל בעל התועלת הגבוהה ביותר באוסף הזה כולו, וזה שדורש יותר ממודל אחד.

קבלו תשובה ממודל אחד. אחר כך עברו והעבירו את זה:

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

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

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

על מה לשים עין

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

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

התפשטות היקף שקטה. בשביל זה קיים האילוץ השני.

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

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