שימוש בסקירה מבוססת AI

המדריך הזה מראה לכם איך לתת לסוכני סקירה לסקור בקשת משיכה ואיך לפרסם את התוצאה ב-GitHub.

התחלת סקירת AI

פתחו את ה-PR ועברו ללשונית סקירה כללית
פתחו את תפריט ⋯ בשורת הפעולות ובחרו שאל את ה־AI

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

Control Center מפעיל את הפייפליין המובנה מראש pr_review ופותח את לשונית סקירה של ה-PR כדי שתוכלו לצפות בו. הפייפליין:

פותח את מרחב הסקירה של ה-PR עצמו, שעץ העבודה המבודד שלו מחזיק את ה-PR בצ׳קאאוט ב-head שלו
מפזר את הסוקרים לפי רמת הסקירה של סביבת העבודה — שלושה כברירת מחדל (הסוכנים המובנים מראש qa, architect ו-engineer, במקביל). אין זיהוי שפה או תחום
נותן לסוכן המוביל (CEO) לאחד את הממצאים שלהם לסיור מודרך
מסיים: ממיין את הממצאים לדליי קונצנזוס ומחשב את ההכרעה. כשהשיוך מגיע ל-awaiting approval, מופיע פרסם ב־GitHub בלשונית הסקירה

עומק הסקירה הוא רמת הסקירה של סביבת העבודה — light (סוקר אחד), balanced (שלושה, ברירת המחדל) או thorough (כל החמישה, בתוספת מומחי האבטחה והביצועים) — והיא נקבעת בהגדרות ← סביבת עבודה ← כללי, בכרטיס מדיניות סביבת העבודה. רמה קלה יותר רושמת בדיוק אותו מספר ממצאים; היא רק מדווחת על פחות מהם בחזית.

כל הסוקרים מפרסמים למרחב הסקירה היחיד של ה-PR, וזה מה שהופך את הממצאים שלהם לברי־השוואה. ראו סקירת AI לאיך החלקים מתחברים יחד.

pr_review מגיע עם טריגר ידני בלבד. כדי שהוא יופעל בכל בקשת משיכה שמפורסמת, הוסיפו טריגר בעצמכם — ראו שליחת סוכני סקירה. אפשר גם להתחיל סקירה מ-GitHub עצמו, בלי טריגר לפייפליין: אזכרו את הבוט של השרת בבקשת המשיכה או הוסיפו את התווית ai-review — ראו דיבור עם Control Center מבקשת משיכה ב־GitHub.

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

קריאת הממצאים

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

שדה	תיאור
סוג	`bug`, `suggestion`, `recommendation`, `question` או `ticket`
עדיפות	P0 (קריטי) ← P3 (זוטר)
קטגוריה	`security`, `stability`, `data_integrity`, `correctness`, `performance` או `maintainability`
קובץ ושורה	היכן שהממצא מעוגן
קוד מקורי	הקוד שהממצא עוסק בו
קוד מוצע	התיקון המוצע
ביטחון	עד כמה הסוקר בטוח
סטטוס	`open` ← `consensus-ready` ← `resolved` או `dismissed`

ממצא מגיע לconsensus-ready רק כשסוקר עמית מאשר אותו. סוכן לא יכול לאשר ממצא משלו, כך שהדעה של סוקר בודד לעולם לא מתקדמת בכוחות עצמה.

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

בדיקת פאנל אי־ההסכמות

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

קריאת ההכרעה

כשהסוכן המוביל מסיים, הוא מחשב הכרעה:

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

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

צירי הסקירה מתמזגים לתוכה לאחר מכן, והם יכולים רק להפוך אותה לחמורה יותר. ציר משעור שנכשל כופה Block; ציר משעור שלא הצליח להשלים (partial) או שלא הצליח לרוץ בכלל (unavailable) כופה לפחות Hold. היעדר ראיה לעולם לא פותח שער.

פרסום הסקירה ל-GitHub

הפרסום הוא צעד נפרד, שתלוי במכוון באישור מצד המשתמש. הפייפליין pr_review משאיר את הסקירה ב-Control Center; הוא לא מפרסם אותה ב-GitHub.

בלשונית סקירה, המתינו עד שיופיע פרסם ב־GitHub
לחצו על פרסם ב־GitHub

Control Center שולח סקירת GitHub אחת. ממצאים שכבר נפתרו או נדחו מדולגים. הכפתור כולל כל ממצא פתוח שנותר, וב-Ship הוא שולח APPROVE. (כלי ה-MCP publish_review_to_github עדיין מגיע כברירת מחדל לממצאים שאושרו על ידי עמיתים בלבד, ולא מאשר אלא אם תעבירו approve_on_ship.) ממצאים שנושאים עוגן של קובץ ושורה הופכים להערות מוטבעות; כל השאר נכנס לגוף הסיכום, כל אחד עם כותרת תחתונה “— Control Center AI review” כך שהמקור חד־משמעי. הכרעת Block נשלחת כ-REQUEST_CHANGES; Hold כ-COMMENT; Ship כ-APPROVE מהכפתור הזה. הודעת טוסט לאחר מכן מציגה פורסם. הסקירה מתפרסמת תחת זהות האפליקציה של השרת.

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

פייפליינים מובנים אחרים כן מפרסמים ישירות ל-GitHub: cross_review, pr_triage, ticket_to_pr ו-pre_merge_gate מסתיימים כל אחד בשלב תגובה. רק pr_review משאיר את הפלט שלו ממתין לכם.

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

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