מועצת מודלי השפה

מדריך מעשי · פרומפט אחד, בלי התקנה. מהרעיון של אנדריי קרפאתי — לפרומפט אחד פשוט.

LLM Council · פרומפט מוכן בעברית ובאנגלית · דוגמה מלאה מהחיים · מבוסס על מחקר סטנפורד על חנופת מודלים.

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

מבוא

הרעיון המרכזי

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

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

מה קרפאתי פיתח

קרפאתי בנה אפליקציית ווב מקומית קטנה בשם llm-council (זמינה כקוד פתוח בגיט). האפליקציה נראית כמו צ'אט רגיל, אבל מאחורי הקלעים היא שולחת את השאלה שלכם דרך OpenRouter לכמה מודלים במקביל, מבקשת מהם לבקר ולדרג זה את עבודתו של זה, ואז מודל יושב ראש מפיק את התשובה הסופית.

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

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

איך פישטתי את זה

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

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

אנדריי קרפאתי — מי הוא?

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

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

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

49% המודלים מאשרים ומחמיאים למשתמש ("סיקופנטיות") בממוצע כ-49% יותר מבני אדם — גם כשהתיאור של המשתמש כלל התנהגות מזיקה, לא הוגנת או אפילו לא חוקית.

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

הקשר בין המחקר למועצה

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

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

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

הפרומפט

השימוש פשוט מאוד — אין צורך בשום התקנה.

בחרו שפה: העתיקו את הפרומפט בעברית או באנגלית (למטה).
החליפו את השאלה: בטקסט הפרומפט מופיעה שאלת דוגמה. מחקו אותה והכניסו את השאלה האמיתית שלכם במקומה.
הדביקו לצ'אט: הדביקו את כל הפרומפט לתוך Claude או ChatGPT ושלחו.
קראו את שלושת השלבים: המודל ייצר את חמש התשובות, את סקירת העמיתים והדירוג, ואת הכרעת יושב הראש — הכל בתשובה אחת.

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

הפרומפט בעברית

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

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

חמשת היועצים (כל אחד הוא פרסונה מובחנת — הישאר לחלוטין בדמות, אל תיתן להם להסכים כברירת מחדל):
- יועץ 1 — השלילי: מסתכל אך ורק על מה שיכשל. מציף סיכונים, תרחישי כשל וסיבות מדוע הדבר ישתבש.
- יועץ 2 — החושב מעקרונות ראשוניים: מפרק לחתיכות כל הנחת יסוד המובנית בשאלה ובונה אותה מחדש מהיסוד.
- יועץ 3 — מרחיב האופקים: מוצא את הפוטנציאל, את ההזדמנות הגדולה יותר ואת האפשרויות שאני מפספס.
- יועץ 4 — האאוטסיידר: אינו יודע דבר על התעשייה שלי; מסיק מסקנות מתוך היגיון בריא ושאלות נאיביות, תוך התעלמות מז'רגון מקצועי ומ"איך שתמיד עושים דברים".
- יועץ 5 — המבצע: אכפת לו אך ורק ממה שאני באמת הולך לעשות ביום שני בבוקר. פרקטי, סדרתי וקונקרטי.

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

=== שלב 2: סקירת עמיתים אנונימית ===
כעת, תייג מחדש את חמש התשובות משלב 1 כ-"תגובה א', ב', ג', ד', ה'" בסדר אקראי (אל תחשוף איזה יועץ כתב איזו תגובה עד הסוף ממש). לאחר מכן, פעל בתור כל יועץ לפי התור, ובקש מהם לבקר את כל חמש התגובות האנונימיות — כולל, מבלי לדעת זאת, את התגובה של עצמם. עבור כל מבקר:
1. הערך בקצרות כל תגובה (מה היא עושה טוב, מה היא עושה פחות טוב).
2. סיים עם הדירוג שלהם בפורמט הזה בדיוק:
דירוג סופי:
1. תגובה X
2. תגובה X
3. תגובה X
4. תגובה X
5. תגובה X
עשה זאת עבור כל חמשת המבקרים.

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

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

Prompt in English

You are going to run an "LLM Council" deliberation on my question, entirely on your own, by simulating five independent advisors and a chairman. Follow the three stages exactly and show your work for each stage under clear headers.

MY QUESTION:
[WRITE YOUR QUESTION HERE]

THE FIVE ADVISORS (each is a distinct persona — stay fully in character, do not let them agree by default):
- Advisor 1 — The Contrarian: only looks at what will fail. Surfaces risks, failure modes, and reasons this goes wrong.
- Advisor 2 — The First-Principles Thinker: rips apart every assumption baked into the question and rebuilds from the ground up.
- Advisor 3 — The Expansionist: finds the upside, the bigger opportunity, and the option I'm not seeing.
- Advisor 4 — The Outsider: knows nothing about my industry; reasons from common sense and naive questions, ignoring jargon and "how it's always done."
- Advisor 5 — The Executor: only cares about what I will actually DO on Monday morning. Concrete, sequenced, practical.

=== STAGE 1: INDEPENDENT ANSWERS ===
Each of the five advisors answers MY QUESTION independently and in their own voice. They must NOT reference each other. Write all five answers in full. Label them "Advisor 1 — The Contrarian", etc.

=== STAGE 2: ANONYMIZED PEER REVIEW ===
Now relabel the five Stage 1 answers as "Response A, B, C, D, E" in a RANDOM order (do not reveal which advisor wrote which until the very end). Then, acting as each advisor in turn, have them review all five ANONYMIZED responses — including, unknowingly, their own. For each reviewer:
1. Briefly evaluate each response (what it does well, what it does poorly).
2. End with their ranking in EXACTLY this format:
   FINAL RANKING:
   1. Response X
   2. Response X
   3. Response X
   4. Response X
   5. Response X
Do this for all five reviewers.

Then compute an AGGREGATE RANKING: for each response, average its rank position across all five reviewers (lower = better), sort best to worst, and present it as a table with columns: Response, Avg Rank, then reveal which Advisor it was.

=== STAGE 3: CHAIRMAN'S FINAL CALL ===
Now act as the Chairman. Using all five answers AND the peer rankings (pay special attention to the responses that ranked highest, and to any disagreement between advisors), synthesize ONE final answer to MY QUESTION. Then end with:
- THE CALL: your single clearest recommendation.
- MONDAY MORNING: 3–5 concrete next steps I should actually take.

דוגמה אמיתית

כך נראית הרצה אמיתית של הפרומפט. השאלה ששימשה: "אני שוקל/ת להתחיל פרויקט צדדי של פיתוח אפליקציה, במקביל למשרה המלאה. האם כדאי?"

שלב 1 — חמש התשובות העצמאיות

כל יועץ עונה במלואו ובקולו הייחודי — שימו לב איך הן סותרות זו את זו במכוון.

יועץ 1 — השלילי (קונטראריאן)

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

הסיכונים המרכזיים:

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

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

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

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

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

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

יועץ 2 — החושב מעקרונות ראשוניים (First-principles)

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

יש כאן כמה הנחות חבויות:

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

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

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

לכן השאלה הנכונה אינה "האם לבנות מוצר צדדי?", אלא: האם יש בעיה ספציפית שאני מבינה טוב יותר מאנשים אחרים, עבור קהל שאני יכולה להגיע אליו, ושאפשר לבדוק אותה תוך 2–6 שבועות בלי להקריב את העבודה והחיים? אם כן — כדאי להיכנס, אבל רק במבנה ניסויי.

המסגרת שלי:

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

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

יועץ 3 — מרחיב האופקים (Expansionist)

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

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

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

אבל אל תחשבי קטן מדי. גם מוצר קטן יכול להיות התחלה של משהו גדול:

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

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

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

יועץ 4 — האאוטסיידר (Outsider)

אני לא יודע כלום על התעשייה שלך, אז אני אשאל את זה פשוט.

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

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

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

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

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

ההיגיון הפשוט שלי:

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

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

יועץ 5 — המבצע (Executor)

כן, אבל רק אם זה נכנס ללוח זמנים אמיתי. בלי זה — לא.

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

הדרך הנכונה:

שבוע 1: בחירת רעיון אחד בלבד. לא שלושה. לא "נראה". רעיון אחד. לכתוב במשפט: "אני עוזר/ת ל-X לעשות Y בלי Z".

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

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

שבוע 4: לתת ל-3 אנשים להשתמש. לראות אם הם חוזרים לבד. אם צריך לרדוף אחריהם — זה סימן.

שבוע 5: להחליט: ממשיכים, משנים כיוון, או הורגים.

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

מדדי הצלחה:

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

שלב 2 — סקירת עמיתים אנונימית ודירוג

התשובות מקבלות שמות אנונימיים (תגובה א'–ה'), כל יועץ מבקר ומדרג את כולן — כולל, בלי לדעת, את התגובה של עצמו.

מבקר: יועץ 1 — הקונטראריאן

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

דירוג סופי:

תגובה ב'
תגובה ג'
תגובה ד'
תגובה ה'
תגובה א'

מבקר: יועץ 2 — עקרונות ראשוניים

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

דירוג סופי:

תגובה ד'
תגובה ג'
תגובה ב'
תגובה א'
תגובה ה'

מבקר: יועץ 3 — מרחיב האופקים

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

דירוג סופי:

תגובה א'
תגובה ג'
תגובה ד'
תגובה ה'
תגובה ב'

מבקר: יועץ 4 — האאוטסיידר

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

דירוג סופי:

תגובה ה'
תגובה ג'
תגובה ד'
תגובה ב'
תגובה א'

מבקר: יועץ 5 — המבצע

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

דירוג סופי:

תגובה ג'
תגובה ד'
תגובה ב'
תגובה ה'
תגובה א'

דירוג משוקלל — התוצאה הסופית

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

תגובה	דירוג ממוצע	היועץ שמאחורי התגובה
תגובה ג'	1.8	יועץ 5 — המבצע
תגובה ד'	2.4	יועץ 2 — עקרונות ראשוניים
תגובה ב'	3.2	יועץ 1 — השלילי
תגובה ה'	3.6	יועץ 4 — האאוטסיידר
תגובה א'	4.0	יועץ 3 — מרחיב האופקים

שלב 3 — הכרעת יושב הראש

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

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

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

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

הקונטראריאן צודק בכך שהמחיר האמיתי הוא אנרגיה. במשרה מלאה אין באמת "עוד כמה שעות בערב" בלי מחיר — לכן צריך להגדיר גבול קשיח מראש.

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

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

ההחלטה

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

מחר על הבוקר

כתבו משפט אחד של הרעיון, בפורמט: "אני עוזר/ת ל-___ לעשות ___ בלי ___". לדוגמה: "אני עוזרת לעצמאים להבין חשבונות והוצאות בלי להסתבך באקסלים".
קבעו גבול זמן קשיח ביומן — 5 שעות בשבוע בלבד למשך 6 שבועות. למשל: שני ורביעי 20:00–22:00 ועוד חצי שעה בסוף השבוע לסיכום. בלי זה — לא מתחילים.
פתחו רשימה של 20 אנשים/משתמשים פוטנציאליים — לא חברים שיגידו "רעיון מהמם", אלא אנשים שבאמת חווים את הבעיה. המטרה: להגיע ל-10 שיחות קצרות.
בנו שאלון שיחה של 6 שאלות — לא "היית משתמש בזה?" אלא: מה את עושה היום כשזה קורה? מה הכי מעצבן בזה? כמה זמן/כסף זה עולה לך? ניסית לפתור את זה? מה לא עבד? מתי בפעם האחרונה זה קרה?
הגדירו תנאי המשך ותנאי עצירה — ממשיכים רק אם תוך 6 שבועות יש לפחות 10 שיחות, 3 אנשים שמוכנים לנסות פתרון ראשוני, ואדם אחד שמביע נכונות לשלם או להשתמש שוב.

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

בונוס למתקדמים — הרצת הפרויקט המקורי

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

למה זה מורכב? עניין של מפתחות API

בגרסת הפרומפט, מודל אחד מדמה את כל היועצים — ולכן זה "חינם" (כלול במנוי). בגרסה המקורית, כל יועץ הוא מודל אמיתי ונפרד (GPT, Gemini, Claude, Grok). כדי לגשת לכל המודלים האלה צריך מפתחות API בתשלום.

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

הוראות התקנה והרצה (לפי ה-README)

הפרויקט משתמש ב-uv לניהול Python וב-npm ל-JavaScript. יש להתקין אותם מראש.

1. שכפול הפרויקט והתקנת התלויות:

git clone https://github.com/karpathy/llm-council.git
cd llm-council
uv sync
cd frontend
npm install
cd ..

2. הגדרת מפתח ה-API: צרו קובץ בשם .env בתיקיית הפרויקט, והכניסו לתוכו את השורה הבאה עם המפתח שקיבלתם מ-OpenRouter (משיגים אותו באתר openrouter.ai; חשוב לרכוש שם קרדיט, אחרת הבקשות ייכשלו):

OPENROUTER_API_KEY=sk-or-v1-...

3. בחירת המודלים (אופציונלי): אפשר לערוך את הקובץ backend/config.py כדי להחליט אילו מודלים ישבו במועצה ומי יהיה יושב הראש:

COUNCIL_MODELS = [
    "openai/gpt-5.1",
    "google/gemini-3-pro-preview",
    "anthropic/claude-sonnet-4.5",
    "x-ai/grok-4",
]
CHAIRMAN_MODEL = "google/gemini-3-pro-preview"

4. הרצת האפליקציה: האפשרות הפשוטה — סקריפט ההפעלה:

./start.sh

לחלופין, הרצה ידנית בשני חלונות טרמינל נפרדים:

# טרמינל 1 (Backend)
uv run python -m backend.main

# טרמינל 2 (Frontend)
cd frontend
npm run dev

לאחר מכן פתחו בדפדפן את הכתובת http://localhost:5173 — וזהו, המועצה שלכם פועלת עם מודלים אמיתיים.

קישורים

הפרויקט של קרפאתי ב-GitHub: github.com/karpathy/llm-council
מאמר סטנפורד (Stanford Report): news.stanford.edu
המחקר בכתב העת Science: science.org

סיכום

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

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

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

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

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

אהבתם? תעקבו אחריי לעוד טיפים ומדריכים :) יש לכם שאלות? בקשות? טיפים? תשלחו לי הודעה, אני תמיד עונה! @dalia__ai