‏بازی‌ای که GPT و Claude خودشون بازیش می‌کنن

نویسنده تعریف می‌کنه که با Lovable، یه ابزار ساخت اپ با پرامپت، یه بازی شبیه‌سازی بقا ساخته که توش یه سکونتگاه باید هفت روز دووم بیاره. نکتهٔ اصلی اینه که مدل‌های زبانی به‌جای حرف زدن دربارهٔ بازی، واقعاً بازیش می‌کنن: از راه MCP، یعنی همون پروتکلی که به مدل اجازه می‌ده ابزارهای بیرونی رو صدا بزنه، وضعیت بازی رو می‌خونن و تصمیم روزانه‌شون رو ثبت می‌کنن.

به گفتهٔ نویسنده، مهم‌ترین کارش این بوده که به‌جای یه پرامپت غول‌پیکر، کار رو فاز به فاز جلو برده. اول یه مدل بیرونی (GPT 5.6) یه پلن کامل با ساختار پوشه‌ها، طراحی دیتابیس و یه لیست acceptance criteria، یعنی چک‌لیستی که می‌گه کار کِی درست انجام شده، درآورده. اون پلن رفته تو plan mode خود Lovable تا معلوم شه ابزار درست فهمیده، قبل از اینکه حتی یه فایل ساخته شه.

سطح MCP هم عمداً کوچیک مونده: فقط چهار تا ابزار، دیدن وضعیت سکونتگاه، دیدن جزئیات هر ساکن، ثبت تصمیم روزانه و خوندن گزارش پایانی. همهٔ انتخاب‌های یه روز، از جیره‌بندی و تعمیر گرفته تا اعزام گروه و تقسیم دارو، تو همون یه فراخوانی «ثبت تصمیم» جمع می‌شه. نویسنده می‌گه کم بودن تعداد ابزار، احتمال اینکه مدل ابزار اشتباه رو صدا بزنه یا بین گزینه‌های هم‌پوشان گیج شه رو میاره پایین.

فازها به ترتیب رفتن جلو: اول یه پوستهٔ بصری ساده برای یه روز بازی، بعد کامل شدن منطق شبیه‌سازی برای کل هفت روز، بعد وصل شدن به Lovable Cloud برای ذخیرهٔ ران‌ها، و آخر سر قرارداد MCP به شکل یه فایل مارک‌داون. جالب اینه که پالیش بصری، که آخرین مرحله بود، از همهٔ فازهای خودکار بیشتر طول کشید و چند روز تست دستی برد.

حرف اصلی مقاله اینه که همین ساختار، فارغ از بازی، برای هر پروژه‌ای که بخوای مدل با یه سیستم حالت‌دار کار کنه جواب می‌ده: یه ست ابزار کوچیک و مستند، معیار پذیرش مشخص قبل از ساخت، و تأیید مرحله‌به‌مرحله. همینم بود که مقایسه رو ممکن کرد؛ GPT 5.6 و Claude Opus 5 با seed و منابع اولیهٔ یکسان همون بحران رو مدیریت کردن و از نظر تعداد بازمانده، مدیریت منابع و انتخاب‌های اخلاقی نتیجه‌هاشون واقعاً فرق داشت.

نکات کلیدی:

• سطح MCP فقط چهار ابزار داشت: بررسی سکونتگاه، بررسی ساکن‌ها، ثبت تصمیم روزانه و خوندن گزارش نهایی.
• پلن اولیه با GPT 5.6 و همراه با acceptance criteria نوشته شد و بعد رفت تو plan mode خود Lovable.
• معماری سه تیکه بود: لایهٔ بازی تو مرورگر، Lovable Cloud برای دادهٔ کاربر و تاریخچهٔ ران‌ها، و قالب‌های سناریو برای استفادهٔ دوباره.
• هر ران یه run ID جدا داشت، با seed و منابع اولیهٔ یکسان، تا مقایسهٔ دو مدل منصفانه باشه.
• پالیش بصری آخرین فاز بود و چند روز تست دستی وقت برد، بیشتر از فازهای خودکار.