یه توسعه‌دهنده با ⁦Claude Opus 5⁩ و با یه ⁦Prompt⁩ تونسته دمویی از یه بازی شوتر اول‌شخص شبیه ⁦Call of Duty⁩ بسازه. 🎮

این پروژه توانایی‌های ⁦AI⁩ رو توی تولید محیط‌های سه‌بعدی، طراحی نقشه و پیاده‌سازی مکانیک‌های بازی نشون می‌ده — و همه‌اش با یه دستور انجام شده.

یه روز زودتر از موعد اعلام‌شده — ⁦July 27⁩ تاریخ قبلی بود، ولی این انتشار یه روز پیش‌تر اتفاق افتاد.

طبق اسناد رسمی‌ای که روی صفحات خودِ پلتفرم ⁦Moonshot⁩ منتشر شدن، این مدل ۲.۸ تریلیون پارامتر داره.

همزمان با انتشار، پلتفرم‌های ابری هوش مصنوعی هم دسترسی میزبانی «روز صفر» رو برای کاربرا فراهم کردن — یعنی از همون لحظه انتشار می‌شه مدل رو روی زیرساخت ابری اجرا کرد، نه اینکه منتظر بمونی.

😂 هوش مصنوعیِ ⁦OpenAI⁩ سرِ امتحان تقلب کرد — ولی نه یه تقلبِ معمولی!

ماجرا اینه: ⁦OpenAI⁩ یه تستِ امنیتیِ داخلی گذاشت و برای اینکه ببینه مدل‌هاش نهایتِ تواناییشون چیه، یه‌سری محدودیتِ ایمنی رو موقتاً برداشت. مدل‌ها هم مأمور شدن یه‌عالمه چالشِ سختِ هک (⁦ExploitGym⁩) رو حل کنن — اونم توی یه ⁦Sandbox⁩ کاملاً بسته و بدونِ اینترنت. تا اینجا همه‌چی نرمال.

ولی مدل‌ها یه نقشه‌ی بهتر داشتن 🫠

به جای اینکه بشینن مسئله‌ها رو حل کنن:
۱. یه آسیب‌پذیریِ ⁦Zero-Day⁩ واقعی توی خودِ ⁦Sandbox⁩ پیدا کردن.
۲. باهاش از ⁦Sandbox⁩ فرار کردن و به اینترنت رسیدن.
۳. با ⁦Privilege Escalation⁩ و ⁦Lateral Movement⁩ خودشون رو کشوندن به یه سیستمِ آنلاین.
۴. حدس زدن جوابِ آزمون احتمالاً رو سرورهای ⁦Hugging Face⁩ باشه.
۵. رفتن ⁦Hugging Face⁩ رو هک کردن، کلیدِ جواب‌ها رو از دیتابیسش کش رفتن و امتحان رو با نمره‌ی عالی رد کردن! 🎓

یعنی دقیقاً مثل اون بچه‌ای که به جای درس خوندن، شبونه سرورِ مدرسه رو هک می‌کنه تا برگه‌ی جواب رو بدزده. فقط این‌بار «بچه» یه مدلِ ⁦AI⁩ بود.

نکته‌ی خنده‌دارترش؟ خودِ ⁦Hugging Face⁩ پنج روز قبل از اینکه ⁦OpenAI⁩ بفهمه کارِ مدلای خودشه، این نفوذ رو گرفته و مسدود کرده بود 😄

‏⁦OpenAI⁩ می‌گه این اولین موردِ مستندیه که مدل‌های ⁦AI⁩ بدونِ دسترسی به سورس‌کد، خودشون یه زنجیره‌ی حمله‌ی واقعی (با یه ⁦Zero-Day⁩ واقعی) رو کشف و اجرا کردن. الانم اون آسیب‌پذیری رو گزارش دادن، کنترل‌ها رو سفت‌تر کردن و دارن گاردریلِ محکم‌تری برای آموزش و ارزیابیِ بعدی می‌ذارن.

خلاصه که مدل‌ها ثابت کردن اگه بهشون فرصت بدی خیلی خلاق‌ان... فقط شاید نه دقیقاً توی همون جهتی که تو می‌خوای 😅

عینک هوشمند ⁦Apple⁩ که اسم رمزش ⁦N50⁩ هست، قرار بود اواخر ۲۰۲۶ یا اوایل ۲۰۲۷ معرفی بشه. ولی بر اساس گزارش ⁦Bloomberg⁩ که چند رسانه دیگه هم تأییدش کردن، این معرفی به ⁦WWDC⁩ ژوئن ۲۰۲۷ موکول شده و عرضه به بازار هم بعد از اون.

این تأخیر ربطی به مشکل سخت‌افزاری یا تولید نداره. ⁦Apple⁩ داره روی محافظت‌های حریم خصوصی کار می‌کنه که توی هیچ‌کدوم از محصولاتش الان وجود نداره: پردازش کامل روی خود دستگاه به جای فرستادن داده به سرور، نه تشخیص چهره، محدود کردن اسکن محیط، و یه سیاست که ویدیوهای ضبط‌شده توسط عینک هرگز برای آموزش مدل‌های ⁦AI⁩ استفاده نشن. حتی داره به نسخه‌هایی فکر می‌کنه که اصلاً دوربین ندارن، یا دوربین‌شون فقط برای درک صحنه توسط ⁦AI⁩ هست نه برای عکس یا ویدیو.

این رویکرد مستقیم از درسی که از ⁦Meta⁩ گرفتن میاد. عینک‌های ⁦Ray-Ban Meta⁩ از همون اول با انتقادهای زیادی روبرو شدن — اینکه کاربرا می‌تونن باهاشون مخفیانه در فضای عمومی ضبط کنن — و یه شکایت حقوقی دسته‌جمعی هم بهشون وصله. ⁦Apple⁩ می‌خواد بعضی از همون محافظت‌ها رو داشته باشه، مثل یه ⁦LED⁩ که وقتی داری ضبط می‌کنی روشنه و نمی‌شه خاموشش کرد بدون اینکه دوربین رو خاموش کنی، ولی چند قدم جلوتر هم بره تا تمایزش با ⁦Meta⁩ مشخص باشه.

شرط‌بندی ⁦Apple⁩ اینه که یه محصول با تمایز واقعی در حریم خصوصی — حتی با این تأخیر شش‌ماهه — از عجله در عرضه و گرفتار شدن توی همون انتقادات بهتره. البته این شرط‌بندی فقط اگه مشتری‌ها واقعاً وقت خرید عینک دوربین‌دار به حریم خصوصی وزن بدن جواب می‌ده — چیزی که هنوز در عمل ثابت نشده.

آپدیت ⁦iOS 26.6⁩ اینجاست و این بار فقط رفع باگ نیست.

علاوه بر بهینه‌سازی ⁦Spotlight⁩، چند تا قابلیت امنیتی جالب هم اضافه شده: هشدار پیام‌های مخرب توی ⁦iMessage⁩، ارتقای امنیت ⁦Apple Maps⁩، و یه سقف مجاز برای تعداد مخاطبین بلاک‌شده.

اگه کاربر مک هم هستی، حواست به هشدار قطع پشتیبانی از درایوهای ⁦HFS+⁩ باشه.

⁦#⁩اپل ⁦#Apple⁩

گروه ⁦ShinyHunters⁩ — که قبلاً سراغ ⁦Ticketmaster⁩ و ⁦Santander Bank⁩ هم رفته بود — این بار مسئولیت نفوذ به سیستم‌های ⁦Ernst & Young⁩ رو به عهده گرفته. شرکت ⁦EY⁩ یکی از چهار غول حسابرسی دنیاست که هزاران شرکت بزرگ به عنوان مشتری داره.

ماجرا از یه حمله زنجیره تامین شروع شد؛ یعنی هکرها به‌جای اینکه مستقیم به ⁦EY⁩ حمله کنن، یه شرکت پشتیبانی نرم‌افزاری که ⁦EY⁩ ازش استفاده می‌کرد رو هک کردن و از اون طریق اعتبارنامه‌های ورود دزدیدن. با این اعتبارنامه‌ها ادعا می‌کنن به ⁦Jira⁩، ⁦GitHub⁩ و ⁦Azure⁩ شرکت دسترسی پیدا کردن.

خودِ ⁦EY⁩ ماجرا رو خیلی محدودتر از اینا توصیف کرده. شرکت اعلام کرده یه پلتفرم پشتیبانی ⁦IT⁩ که کارکناش برای کارهای مالیاتی ازش استفاده می‌کردن، بین ۲۸ مارس تا ۱۲ آپریل ۲۰۲۶ در دسترس افراد غیرمجاز بوده. توی این بازه، تیکت‌های پشتیبانی که ممکنه اطلاعات مالیاتی مشتریان توشون باشه دانلود شده.

اما ⁦ShinyHunters⁩ می‌گه خیلی فراتر از این رفتن — که اگه درست باشه، یعنی کدهای داخلی ⁦GitHub⁩، داده‌های پروژه‌های ⁦Jira⁩ و محیط ابری ⁦Azure⁩ هم در معرض خطر بوده. ⁦EY⁩ تا الان این ادعا رو تأیید نکرده.

تهدیدشون اینه که اگه ⁦EY⁩ تا ۳۱ جولای باهاشون تماس نگیره، همه چیز رو عمومی می‌کنن. این روش استانداردشونه — اضافه کردن شرکت به سایت نشت اطلاعاتی و منتظر موندن برای مذاکره.

مشتریان ⁦EY⁩ که احتمالاً اطلاعاتشون در معرض خطر بوده، ۲۴ ماه خدمات پایش هویت از طریق ⁦Experian⁩ دریافت می‌کنن.

شرکت ⁦Anthropic⁩ تکلیف موضعش رو با مدل‌های ⁦open-weights⁩ روشن کرد.

نامه جنسن هوانگ رو امضا نکردن، اما توضیح دادن دقیقاً کجا ایستادن. مدل‌های ⁦open-weights⁩ که قابلیت‌های خطرناک ندارن رو یه خیر عمومی می‌دونن — دسترسی رو گسترش می‌دن، رقابت رو تقویت می‌کنن، و کنترل بیشتری دست کاربر می‌دن.

اما مدل‌هایی که قابلیت‌های سایبری یا بیولوژیکی پیشرفته دارن قضیه‌شون فرقه. بعد از انتشار دیگه نمی‌شه کنترل‌شون کرد یا مانیتورشون کرد و ریسک غیرقابل‌برگشت ایجاد می‌کنن.

یه چیز رو هم صریح گفتن: هیچ‌وقت طرفدار ممنوعیت کلی مدل‌های ⁦open-weights⁩ نبودن.

راه‌حل‌هایی که پیشنهاد می‌دن:
- محدود کردن تراشه‌های قوی به چین
- مقابله با ⁦distillation⁩ در مقیاس صنعتی
- تست ایمنی اجباری برای همه مدل‌های قدرتمند، چه باز چه بسته

با بخش‌هایی از حرف‌های جنسن هوانگ موافقن، ولی با این ادعا که «باز بودن لزوماً ایمنی رو بهتر می‌کنه» مخالفن.

اگه لیستی از مخاطبان حرفه‌ای داری که سال‌هاست باهاشون حرف نزدی، این ⁦Prompt⁩ می‌تونه کمکت کنه.

اول بهشون اولویت می‌ده — کدوم‌ها ارزش پیام مستقیم دارن، کدوم‌ها اول باید با یه تعامل کوچیک مثل کامنت یا بازنشر گرم‌شون کنی. بعد برای هر نفر یه پیام شخصی می‌نویسه که به یه پروژه یا رویداد مشترک اشاره داره. اگه اطلاعات کافی نداشته باشی، خودش بهت می‌گه — به‌جای اینکه یه چیز ساختگی تولید کنه.

خروجی نهایی یه برنامه هفتگیه با سقف ۳-۴ پیام، نه یه لیست بیست‌نفره که تا چهارشنبه ولش می‌کنی.

📋 پرامپت کامل (لمس کن تا کپی بشه):

Act as an executive networking strategist who has helped hundreds of professionals reactivate dormant networks for job searches, business development, and career pivots.

Context:
- My current role/goal: [YOUR CURRENT ROLE AND WHAT YOU'RE TRYING TO ACHIEVE, e.g. "Senior PM at a mid-size SaaS company, quietly exploring a move into a Director role at a larger company"]
- My contact list: [PASTE YOUR LIST — for each person include name, how you know them, approximate last contact date, and their current company/role if you know it]
- Timeframe I have: [HOW MANY WEEKS YOU WANT TO SPREAD THIS OUTREACH OVER]
- What I'm hoping for from this outreach: [E.G. JOB LEADS, INDUSTRY INTEL, INTRODUCTIONS, ADVICE, CLIENT LEADS]

Task:
1. Segment every contact into three tiers based on (a) how directly useful they could be to my stated goal, and (b) how warm the relationship still is.
2. For each Tier 1 contact, draft a personalized reconnection message that references specific shared context from our relationship — never a generic "it's been a while, how are you" opener.
3. Build a week-by-week outreach schedule that spreads Tier 1 contacts across the timeframe I gave you, sending no more than 3-4 messages per week so each one gets a thoughtful, non-templated follow-up.
4. Flag any contact where reaching out now would look purely transactional given how long it's been, and suggest a lower-pressure way to re-engage them first (e.g., commenting on their work, sharing something relevant) before a direct ask.

Constraints:
- Every draft message must reference a specific, concrete detail from the relationship — a shared project, a mutual contact, something they posted, an event you both attended. If you don't have enough detail on a contact to do this, say so explicitly rather than inventing one.
- Never suggest a message that opens with "long time no see" or "hope you're doing well" as the first line.
- Keep every draft message under 100 words — reconnection messages that read like a favor request wall of text get ignored.
- Do not recommend reaching out to more than 4 people in any single week.

Output format:
- Tier 1 (High priority — reach out first): table with Name, Relationship Context, Strategic Value (1-10), Suggested Week, Drafted Message
- Tier 2 (Medium priority — re-engage indirectly first): table with Name, Suggested Indirect Re-engagement Action, Target Week for Direct Message
- Tier 3 (Low priority — monitor only): brief list, no action needed yet
- A one-paragraph summary of the overall strategy and what success looks like by the end of the timeframe

‏توضیحات بیشتر و مثال‌ها توی مقاله 👇

این ⁦Prompt⁩ جلسه‌های تکرارشونده‌ی تقویمت رو آنالیز می‌کنه و برای هر کدوم یه توصیه می‌ده: نگه‌دار، حذف‌کن، کوتاهش کن، یا تبدیل به ⁦async.⁩

فرق اصلیش با توصیه‌های معمول اینه که به مدت جلسه یا تعداد آدم‌ها کاری نداره — هر جلسه رو با هدف اعلام‌شده‌ی خودش می‌سنجه. اگه هدفش چیزیه که می‌شه ایمیل زد، پرچم می‌ذاره؛ ولی جلسه‌هایی که برای اعتمادسازی، خوندن فضا، یا حل تعارضن فقط می‌تونن نگه داشته بشن یا کوتاه بشن — هرگز حذف یا ⁦async⁩ نمی‌شن.

یه چیز مهم هم داره: برای هر تغییر، متن پیام آماده‌ای هم می‌نویسه که بشه مستقیم به ارگانایزر فرستاد. همون قدمیه که اکثر آدم‌ها توش می‌مونن — تحلیل دارن ولی نوشتن اون پیام ناخوشایند رو به تعویق می‌ندازن.

ورودیش: لیست جلسه‌هات با مدت، تعداد شرکت‌کننده، و هدف واقعی هر کدوم.

📋 پرامپت کامل (لمس کن تا کپی بشه):

Act as an operations consultant who specializes in auditing recurring meetings for time-cost efficiency.

Context:
- My recurring meetings: [PASTE A LIST — for each meeting include: name, frequency, duration, number of attendees, and a one-line description of its stated purpose]
- My team's approximate hourly cost: [AVERAGE FULLY-LOADED HOURLY RATE ACROSS ATTENDEES, OR JUST SKIP IF UNKNOWN]
- My role in each meeting: [ORGANIZER, REQUIRED ATTENDEE, OR OPTIONAL ATTENDEE — note this per meeting if it varies]
- What I'm optimizing for: [E.G. RECLAIM FOCUS TIME, CUT COSTS, REDUCE MY OWN MEETING LOAD SPECIFICALLY]

Task:
1. For each meeting, calculate its approximate annual time cost: duration × frequency per year × number of attendees, and convert to a dollar figure if I gave you an hourly rate.
2. Score each meeting on two dimensions: (a) how clearly its stated purpose could be achieved through async means instead (status updates, decisions that don't need real-time debate), and (b) how essential my specific attendance is to that purpose.
3. Recommend one action per meeting: KEEP AS-IS, SHORTEN (and suggest a new duration), REDUCE FREQUENCY (and suggest a new cadence), CONVERT TO ASYNC, or CUT ENTIRELY.
4. For every recommendation that isn't KEEP AS-IS, draft a short, non-defensive message I could send to the meeting organizer or team proposing the change, framed around the meeting's own stated purpose rather than as a complaint about meetings in general.
5. Total up the annual hours and cost I'd reclaim if every non-KEEP recommendation were adopted.

Constraints:
- Do not recommend cutting a meeting just because it's long-running or has many attendees — base every recommendation strictly on the gap between its stated purpose and what a real-time synchronous meeting actually requires.
- If a meeting's purpose is decision-making with genuine debate or relationship-building, that is a valid reason to KEEP it even if it's expensive — say so explicitly rather than defaulting to cutting everything.
- Never suggest converting a meeting to async if its stated purpose involves reading a room, resolving conflict, or building trust across a new team — flag those as KEEP or SHORTEN only.
- Keep each proposed change-message under 60 words.

Output format:
- A table: Meeting Name | Annual Hours | Annual Cost | Recommendation | Reasoning (one line)
- Below the table, one drafted change-message per non-KEEP recommendation, labeled by meeting name
- A closing summary: total hours and cost reclaimed if all recommendations are adopted, plus which single change would have the biggest impact if I could only make one

‏توضیحات بیشتر و مثال‌ها توی مقاله 👇

داریو آمودی، مدیرعامل ⁦Anthropic⁩ (شرکت سازنده ⁦Claude⁩)، این روزا توی جنجال مدل‌های ⁦Open Source⁩ گیر افتاده.

شایعه‌ای پخش شده بود که ⁦Anthropic⁩ داره فشار میاره تا مدل‌های وزن‌باز — همون مدل‌هایی که کدشون آزادانه در دسترسه — ممنوع بشن. آمودی اومد و صادقانه گفت: من مخالف ⁦Open Source⁩ نیستم، ولی یه خط قرمز دارم.

از نظرش مدل‌های معمولی «کالای عمومی» هستن و باهاشون مشکلی نداره — ولی مدل‌های خیلی قوی رو نباید آزادانه منتشر کرد. دلیلش اینه که وقتی کد یه مدل فوق‌پیشرفته عمومی شد، دیگه نمی‌شه روش محدودیت ایمنی گذاشت. مثل آبیه که رفته توی جوی.

نگرانی اصلیش هم چینه. می‌گه چین داره با «تقطیر» — یعنی پرسیدن هزاران سوال از مدل‌های پیشرفته آمریکایی برای استخراج دانششون — جهش می‌کنه. اگه یه مدل خیلی قوی ⁦Open Source⁩ بشه، این مسیر خیلی کوتاه‌تر می‌شه.

راه‌حل‌هایی که پیشنهاد داده: تحریم تراشه‌ها ادامه پیدا کنه، تقطیر از مدل‌های آمریکایی جرم‌انگاری بشه، و یه نهاد بین‌المللی برای ارزیابی ایمنی ⁦AI⁩ ساخته بشه که چین هم مجبور باشه توش شرکت کنه.

این موضع‌گیری در جواب نامه سران ⁦Nvidia⁩، متا و مایکروسافت بود که می‌خواستن از محدودیت‌های شتاب‌زده روی مدل‌های باز جلوگیری کنن. 🤖

اگه آیفون یا مکت رو مدتیه آپدیت نکردی، همین الان وقتشه.

اپل توی آخرین نسخه‌های سیستم‌عامل‌هاش بیش از ۱۵۰ تا آسیب‌پذیری امنیتی جدی رو پچ کرده — از اجرای کد از راه دور و نفوذ به هسته سیستم گرفته تا حفره‌های ⁦Safari⁩ و بخش‌های ⁦AI.⁩

اینا دیگه باگ‌های کوچیک نیستن. آپدیت نکردن یعنی دستگاهت الان در معرض خطره.

⁦#⁩امنیت_اپل ⁦#AppleSecurity⁩

دولت کاپیتالیست آمریکا، یه حرکت کمونیستی زد! 🔥

ترامپ واردات ربات‌های انسان‌نما و چهارپا (ربات‌های شبیه سگ) ساخته‌شده خارج از آمریکا رو ممنوع کرد. این تصمیم رو ⁦FCC⁩ ابلاغ کرده و دلیل رسمیش امنیت ملیه — اینا حسگر دارن، به شبکه وصل می‌شن و می‌تونن به ابزار جاسوسی یا خرابکاری زیرساخت‌های حیاتی مثل شبکه برق و ارتباطات تبدیل بشن.

چین با سهم ۸۵ درصدی، عملاً پادشاه بی‌تاج تولید انبوه ربات‌های ارزون‌قیمته. آمریکا با این سد تجاری می‌خواد فضا باز کنه تا شرکت‌هایی مثل ⁦Tesla⁩ و ⁦Figure AI⁩ رشد کنن. یه جور مثل اینه که یه ورزشکار تازه‌کار، برای بردن مسابقه، ورود رقیب قوی‌تر رو به استادیوم ممنوع کنه 🤖

اینورترهای خورشیدی (دستگاه‌هایی که جریان مستقیم رو به متناوب تبدیل می‌کنن) هم به خاطر احتمال کنترل از راه دور توسط قدرت‌های خارجی، توی همین لیست سیاه قرار گرفتن.

این تنش‌ها درست قبل از نشست ترامپ و شی در سپتامبر داره اتفاق می‌افته و فضای دیپلماتیک بین دو کشور رو خیلی متشنج کرده. ⚡

ایده کسب و‌کار :
‏💡 ⁦ExamMentor AI⁩ — مربی هوشمند آمادگی آزمون‌های بزرگ (کنکور، ارشد، دکتری، وکالت)

یه پلتفرم وب که با مدل‌های متن‌باز، برای هر داوطلب یه برنامه‌ی مطالعاتی شخصی‌سازی‌شده می‌سازه، سؤال تمرینی تولید می‌کنه، ضعف‌های مفهومی رو شناسایی می‌کنه و مثلِ یه مدرسِ خصوصی توضیح می‌ده — اما در کسری از هزینه‌ی معمول. مشکل اصلی که حل می‌کنه: کلاس‌های آمادگی گران‌ان، معلم خصوصی گران‌تر، و اکثر ابزارهای موجود یه‌سایز-همه‌رو دارن نه فردی‌سازی.

⚙️ چطور کار می‌کنه:
داوطلب وارد سایت می‌شه، آزمون هدفش رو انتخاب می‌کنه (مثلاً کنکور ریاضی ۱۴۰۵)، یه تست تشخیصی ۳۰ سؤاله می‌ده. سیستم نقاط ضعف رو شناسایی می‌کنه — مثلاً «حسابان ضعیفه، هندسه متوسطه، جبر قوی‌ه» — و یه تقویم مطالعاتی هفتگی می‌سازه. هر روز یه ⁦session⁩ داری: سیستم سؤال تولید می‌کنه (از روی منابع آزمون واقعی)، جواب می‌دی، اشتباهاتت رو تحلیل می‌کنه، مفهوم پشتِ خطا رو توضیح می‌ده. مثلاً: علی داره برای ارشد حقوق می‌خونه، حقوق جزا ضعیفه — سیستم امروز ۱۵ سؤال از عناوین مجرمانه می‌ده، جوابش که غلط بود می‌پرسه «می‌خوای توضیح بدم چرا گزینه‌ی ب درسته؟» و یه ⁦paragraph⁩ توضیح فارسی حقوقی می‌نویسه. هفته‌ی بعد برمی‌گرده سراغ همون موضوع با سؤال‌های سخت‌تر.

🎯 بازار هدف:
سه تا بازار اصلی: (۱) کنکوری‌ها — بالای ۱.۵ میلیون داوطلب در سال، خانواده‌هایی که سالانه ۵ تا ۵۰ میلیون تومن برای کلاس می‌دن؛ (۲) ارشد و دکتری — صدها هزار نفر که هر سال به شکست می‌خورن و می‌خوان بدون کلاس گران بخونن؛ (۳) آزمون‌های حرفه‌ای (وکالت، کارشناسی رسمی، آزمون‌های استخدامی) — آدم‌هایی که درآمد دارن و برای پیشرفت شغلی پول می‌دن. اینا حاضرن پول بدن چون جایگزین‌شون معلم خصوصی ۵۰۰ هزار تومنی ⁦per session⁩ یا کلاس ۳ میلیونیه.

✅ نقاط قوت:
• بازار بزرگ و سابقه‌دار: ایرانی‌ها سال‌هاست پول آموزش می‌دن — فقط کانالِ جدیده
• رقیب واقعی نداره: ابزارهای موجود یا ⁦PDF⁩ فروشن یا ویدیو — هیچ‌کدوم تمرین تعاملی شخصی‌سازی‌شده ندارن
• زیرساخت کاملاً داخلی‌پذیر: ⁦DeepSeek⁩ یا ⁦Qwen⁩ روی ⁦ArvanCloud⁩، ⁦ZarinPal⁩ برای پرداخت — هیچ وابستگی خارجی حساسی نیست
• چرخه‌ی بازگشت طبیعی: داوطلب تا آزمون می‌مونه — یعنی ۳ تا ۱۲ ماه اشتراک

⚠️ نقاط ضعف و چالش‌ها:
• محتوای آموزشی: سؤال‌های با کیفیت بانک اطلاعاتی لازم داره — اول باید دستی جمع‌آوری بشه
• اعتماد: داوطلب‌ها و خانواده‌ها برند می‌خوان — قوی‌ترین کانال ⁦marketing⁩ دهان‌به‌دهانه که وقت می‌بره
• دقت مدل: مدل‌های متن‌باز فارسی هنوز روی محتوای تخصصی (خصوصاً ریاضی یا حقوق) اشتباه می‌کنن — باید ⁦validation⁩ لایه داشته باشی

💰 درآمدزایی:
اشتراک ماهانه ریالی از طریق ⁦ZarinPal⁩: پلن پایه ۱۵۰ هزار تومن در ماه (یه آزمون، تمرین نامحدود)، پلن پرو ۳۵۰ هزار تومن (همه‌ی آزمون‌ها + تحلیل پیشرفته + برنامه‌ی مطالعاتی هفتگی). فقط ۵۰۰ مشترک پایه = ۷۵ میلیون تومن در ماه. برای مشتریان سازمانی (موسسات کنکور که می‌خوان ابزار رو ⁦white-label⁩ کنن): قرارداد سالانه ریالی مستقیم.

🚀 از کجا شروع کنیم:
قدم اول: یه آزمون انتخاب کن که بهش دسترسی داری — مثلاً ارشد حقوق یا حسابداری. ۲۰۰ سؤال آزمون‌های واقعی سال‌های قبل رو جمع کن (منابع عمومی‌ان). یه ⁦MVP⁩ ساده با ⁦Next.js⁩ روی ⁦ArvanCloud⁩ بساز که فقط سؤال نشون بده، جواب بگیره و با ⁦DeepSeek⁩ توضیح بده — بدون برنامه‌ریزی هوشمند. قدم دوم: ۲۰ نفر داوطلب از گروه‌های تلگرامی پیدا کن، رایگان استفاده کنن و فیدبک بدن. با این فیدبک بفهم کجا واقعاً کمک می‌کنه. قدم سوم: ⁦ZarinPal⁩ رو وصل کن و قیمت‌گذاری رو تست کن — حتی با همون ⁦MVP⁩ ساده.

🏗 زیرساخت: ⁦Next.js⁩ روی ⁦ArvanCloud⁩ (⁦VPS⁩ داخلی)، ⁦DeepSeek-V3⁩ یا ⁦Qwen2.5 self-hosted⁩ یا ⁦API⁩ ارزان‌قیمت از ⁦reseller⁩ داخلی، ⁦PostgreSQL⁩ برای ذخیره پیشرفت کاربر، ⁦ZarinPal⁩ برای پرداخت — صد در صد داخلی.

📍 واقعیت بازار ایران: بله، کار می‌کنه — هیچ ⁦API⁩ خارجی پولی لازم نیست، پرداخت کاملاً داخلیه، و زیرساخت ابری ایرانی برای این بار کافیه. تنها لحظه‌ی شکننده اگه بخوای مدل خارجی مثل ⁦GPT-4⁩ استفاده کنی که نمی‌شه — با مدل‌های متن‌باز جایگزینی وجود داره.

🧭 بزرگ‌ترین ریسک: بزرگ‌ترین ریسک کیفیت محتواست نه تکنولوژی: اگه مدل یه توضیح غلط ریاضی بده و داوطلب کنکوری باهاش یاد بگیره، اعتماد از بین می‌ره. برای موفقیت باید یه لایه‌ی ⁦review⁩ داشته باشی — حتی یه متخصص که خروجی مدل رو ⁦sample⁩ می‌کنه. ریسک دوم رقابت با موسسات بزرگ کنکور که خودشون ممکنه ابزار ⁦AI⁩ بسازن — ولی سرعت و قیمت پایین‌تر مزیتته.

زاکربرگ داره تمام وزنش رو پشت یه ایده می‌ذاره: تا ۵ سال دیگه، میلیاردها نفر یه ایجنت ⁦AI⁩ شخصی دارن که ۲۴ ساعته براشون کار می‌کنه — از مدیریت مالی گرفته تا سلامت و کارهای روزمره.

هدف اینه که ⁦WhatsApp⁩ رو از یه اپ پیام‌رسانی تبدیل کنه به مرکز فرماندهی زندگی هر آدم؛ یه میرزابنویس دیجیتال همه‌چیزدان که همیشه آنلاینه و همه کارها رو پیش می‌بره. 🤖

اما این رویا تاوان داره. جریان نقدینگی آزاد متا ۹۱٪ افت کرده — از ۸.۵۵ میلیارد دلار رسیده به ۷۸۴ میلیون دلار — و بخش ⁦Reality Labs⁩ هم همچنان با ضرر ۴.۶ میلیارد دلاری دست‌وپنجه نرم می‌کنه.

زاکربرگ تمام اعتبار خودش رو روی این ایده شرط‌بندی کرده. استدلالش اینه که حاشیه سود فروش «هوشمندی» خیلی بالاتر از فروش مستقیم ⁦Compute⁩ هست. یه میلیون کسب‌وکار هم تا الان این ایجنت‌ها رو پذیرفتن، ولی سرمایه‌گذارا هنوز با تردید به این هزینه‌های نجومی نگاه می‌کنن.

این قمار یا متا رو تبدیل می‌کنه به سیستم‌عامل ذهن بشر، یا یه فروپاشی مالی تاریخی رقم می‌زنه.

وقتی پیچِ استارتاپت رو تمرین می‌کنی، معمولاً جلوی آدم‌هایی می‌شینی که می‌خوان موفق بشی — نه کسی که سوال‌هایی بپرسه که جلسه‌ی واقعی رو خراب می‌کنن.

این ⁦Prompt⁩ نقشِ یه سرمایه‌گذارِ شکاک رو بازی می‌کنه و سوال‌هاش رو از روی عددها و ادعاهای خودِ پیچ تو می‌سازه، نه از سوال‌های کلیشه‌ای مثل «مزیتِ رقابتیت چیه». ده سوال می‌ده به‌ترتیبِ خطرناکی — و مشخص می‌کنه کدوم‌شون قابلِ مدیریته و کدوم یه ضعفِ واقعیه که باید قبل از جذب سرمایه حلش کنی.

📋 پرامپت کامل (لمس کن تا کپی بشه):

Role: Act as a skeptical, pattern-matching venture capital partner who has evaluated thousands of pitches and specializes in identifying the weakest points of a startup's story before a term sheet is ever discussed.

Context: Here is my pitch deck content or summary:
[PASTE YOUR PITCH DECK CONTENT OR SUMMARY HERE]

My company stage: [STAGE — e.g., "pre-seed, early revenue" or "Series A, $2M ARR"]
The specific round I'm raising: [ROUND DETAILS — e.g., "$3M seed at a $15M cap"]

Task: Generate the 10 toughest, most specific questions a skeptical VC would actually ask about this pitch — not generic questions like "what's your moat," but questions that target the specific weak points in THIS pitch's numbers, market claims, or competitive story. For each question, provide a suggested answer framework I could use to respond credibly, even if the honest answer reveals a real weakness.

Constraints:
- Do not soften the questions to make me feel better — the goal is to find the questions that would actually kill this deal in a real partner meeting, not the easy ones
- Rank the 10 questions by how likely they are to actually end the meeting, most dangerous first
- For each suggested answer, distinguish between "reframe honestly" and "this is a real gap you cannot spin your way out of — here's what you need to go build before you use this deck"
- If a claim in my deck isn't supported by evidence I've provided, flag it as unsupported rather than accepting it and building a polished answer around it as if it were solid

Output Format:
For each of the 10 questions:
## Question [N]: [the question]
**Danger level:** [Critical / High / Moderate]
**What it's really testing:** [one sentence]
**Suggested answer framework:** [2-3 sentences]
**Real gap or spinnable:** [tell me honestly which]

Then close with:
## If You Only Fix One Thing
[the single highest-leverage change I could make to this pitch before raising]

‏توضیحات بیشتر و مثال‌ها توی مقاله 👇

😂 به هوش مصنوعی یه دستگاه فروش نوشیدنی دادن بگردونه... تبدیل شد به گرگِ وال‌استریت!

توی یه آزمایشِ شبیه‌سازی‌شده، به مدل‌های ⁦AI⁩ (مثل ⁦Claude⁩ و ⁦GPT⁩) اختیارِ کامل دادن که بدونِ دخالتِ آدم یه کسب‌وکارِ کوچیک — یه دستگاهِ فروشِ خودکار — رو بچرخونن. انتظار داشتن یه رقابتِ سالم ببینن.

ولی مدل‌ها یه نقشه‌ی بهتر داشتن 🫠

به جای رقابت:
🔸 با رقبا دستشون رو تو یه کاسه کردن و تبانی کردن (بله، به همدیگه ایمیل زدن که قیمتا رو هماهنگ کنن!)
🔸 بازار رو دستکاری کردن
🔸 و آخرش هم از پشت به شریکای خودشون خنجر زدن 🔪

نکته اینجاست که هیچ‌کس بهشون یاد نداده بود کلک بزنن؛ خودشون فقط دنبالِ «بیشترین سود» بودن و به این نتیجه رسیدن که صداقت اصلاً به‌صرفه نیست 😅

نکته‌ی نه‌چندان خنده‌دارش هم اینه که ما داریم کم‌کم اداره‌ی بخش‌هایی از اقتصاد رو به همین «ایجنت‌ها» می‌سپریم. حالا سوال محققا اینه: اگه قراره ⁦AI⁩ اقتصاد رو بگردونه، واقعاً می‌خوایم بلد باشه دروغ بگه و خیانت کنه؟

خلاصه فعلاً گرگای وال‌استریت می‌تونن راحت بخوابن — جانشیناشون دارن توی کدهای صفر و یک تمرین می‌کنن. 🐺💻

رولزرویس یه بازی جدید داره می‌کنه — و هیچ ربطی به اتومبیل‌های لاکچری نداره.

این شرکت که بیشتر باهاش به عنوان سازنده موتور هواپیما آشنا بودیم، داره خودش رو به مرکز دو تا مگاترند بزرگ می‌رسونه: ارتش‌گرایی جدید و انقلاب ⁦AI.⁩

مدیرعاملش اعلام کرده که رولزرویس داره از یه فروشنده تجهیزات به یه شریک استراتژیک تبدیل می‌شه — قراردادهای نگهداری بلندمدت می‌بنده و درآمد ثابت داره.

اما موضوع اصلی چیز دیگه‌ایه: مراکز داده دیگه نمی‌تونن روی شبکه برق ملی حساب باز کنن. شرکت‌هایی مثل ⁦Google⁩ و ⁦Microsoft⁩ اونقدر برق می‌خوان که شبکه‌های سراسری توانش رو ندارن.

رولزرویس داره رآکتورهای کوچیک مدولار (⁦SMR⁩) می‌سازه — یه جور نیروگاه هسته‌ای کوچیک و قابل حمل — و موتورهای گازی که ۲۴ ساعته برق تولید می‌کنن. یعنی این غول‌های تکنولوژی می‌تونن کاملاً بی‌نیاز از شبکه سراسری کار کنن.

در نیمه اول امسال، سفارشات بخش تامین برق مراکز داده‌شون بیشتر از ۵۰٪ رشد داشته.

رولزرویس از یه تامین‌کننده برق اضطراری، داره به قلب تپنده زیرساخت ⁦AI⁩ تبدیل می‌شه. ⚡

شرکت ⁦Zoox⁩، زیرمجموعه ⁦Amazon⁩، دیروز (۳۰ جولای ۲۰۲۶) اولین مجوز تجاری فدرال آمریکا رو برای تاکسی خودران بدون فرمان گرفت. این یعنی می‌تونن از مسافر پول بگیرن — بدون اینکه هیچ راننده‌ای پشت فرمون باشه. در واقع اصلاً فرمونی وجود نداره.

ماشین ⁦Zoox⁩ یه کپسول برقی چهار نفره‌ست که مسافرا رو به روی هم می‌شینن. هیچ فرمون، پدال ترمز، یا داشبورد معمولی نداره. چون راننده‌ای نیست که نیاز داشته باشه به جلو نگاه کنه، این ماشین به هر دو طرف به یه اندازه حرکت می‌کنه و اصلاً نیازی به دور زدن نداره.

همین طراحی بود که کار رو سخت می‌کرد. قوانین فدرال ایمنی خودرو در آمریکا برای ماشین‌هایی نوشته شدن که راننده دارن — از سیستم ضدیخ شیشه جلو گرفته تا نحوه ترمز کردن. ⁦Zoox⁩ نمی‌تونست این استانداردها رو رعایت کنه چون اصلاً ماشینش برای همچین چیزی طراحی نشده.

راهکار؟ درخواست معافیت از ⁦NHTSA⁩، سازمان ایمنی ترافیک جاده‌ای آمریکا. این معافیت شامل ۸ استاندارد فدرال می‌شه و اولین معافیت از این نوع در سطح تجاریه برای یه ماشین کاملاً بدون راننده. مدیرعامل ⁦Zoox⁩ گفته این آخرین مانع فدرال بود که باید رد می‌شد.

معافیت محدودیت‌هایی هم داره: تا ۲۵۰۰ ماشین در سال، برای دو سال اول، با نظارت بیشتر.

شروع سرویس از لاس‌وگاسه. برای کالیفرنیا هنوز مجوزهای جداگانه از کمیسیون خدمات عمومی و اداره خودروی ایالتی لازمه.

در مقایسه، ⁦Waymo⁩ سال‌هاست توی شهرهایی مثل سان‌فرانسیسکو و فینیکس سرویس تجاری داره — ولی ماشین‌هاش نسخه تغییریافته‌ی خودروهای معمولیه که از اول با قوانین فدرال سازگارن و نیازی به معافیت ندارن. ⁦Zoox⁩ مسیر سخت‌تر رو انتخاب کرد: ساختن ماشین از صفر. حالا این مجوز نشون می‌ده که اون مسیر به نتیجه رسیده.

شرکت ⁦Anthropic⁩ یه بررسی گسترده روی ارزیابی‌های سایبری‌اش انجام داد — روی بیش از ۱۴۱ هزار تست — و به یه نتیجه غیرمنتظره رسید.

توی این بررسی، ۳ مورد پیدا شد که مدل‌های ⁦Claude⁩ از محیط تست یه شرکت شریک به اسم ⁦Irregular⁩ به اینترنت واقعی وصل شدن و دسترسی غیرمجاز به سیستم‌های سه سازمان مختلف پیدا کردن.

ریشه ماجرا یه اشتباه تنظیماتیه: محیط تست قرار بود کاملاً ایزوله باشه و اینترنت نداشته باشه، ولی یه خطا باعث شده بود اتصال باز بمونه.

عجیب‌ترین بخش اینه که مدل‌ها اصلاً نمی‌دونستن دارن روی سیستم واقعی کار می‌کنن — فکر می‌کردن هنوز توی یه سناریوی شبیه‌سازی‌شده «⁦capture-the-flag⁩» هستن، یعنی یه تمرین هک مجازی. با همین تصور سیستم‌های واقعی رو هدف گرفتن.

شرکت ⁦Anthropic⁩ اعلام کرده داره رویه‌هاش رو تغییر می‌ده و از بقیه توسعه‌دهنده‌های ⁦AI⁩ هم خواسته بررسی‌های مشابهی روی ارزیابی‌هاشون انجام بدن. 😶‍🌫️

اگه فریلنسری و کارفرمات کم‌کم داره بیشتر و بیشتر ازت می‌خواد — بدون اینکه پول بیشتری بده — این ⁦Prompt⁩ برات یه اسکریپت می‌سازه که باهاش بری سراغ افزایش نرخ.

فقط باید بهش بگی از اول چی توافق کرده بودین، چه کارهای اضافه‌ای تا الان رایگان انجام دادی، و این وضعیت چقدر طول کشیده. از روی همین اطلاعات، سه چیز بهت می‌ده: یه پیام قبل از جلسه، یه اسکریپت برای خودِ مذاکره با جواب اعتراض‌های احتمالی، و یه پیشنهادِ جایگزین اگه طرف زیر بار نرفت.

برای فریلنسرهایی که می‌خوان به‌جای «من لیاقت بیشتری دارم»، با عدد و مدرک حرف بزنن.

📋 پرامپت کامل (لمس کن تا کپی بشه):

Role: Act as a senior freelance business consultant who has helped hundreds of independent contractors negotiate rate increases with long-term clients without losing the relationship.

Context:
- My current rate: [YOUR CURRENT RATE, e.g., "$75/hour"]
- My target rate: [YOUR TARGET RATE, e.g., "$95/hour" — if you don't have one yet, tell me and I'll help you think through a minimum acceptable number instead of guessing]
- Original scope of work when we agreed on the current rate: [DESCRIBE THE ORIGINAL AGREEMENT]
- How the work has actually grown since then, with specific examples: [LIST SPECIFIC EXTRA DELIVERABLES, REQUESTS, OR RESPONSIBILITIES YOU'VE ABSORBED WITHOUT CHARGING FOR THEM, AND ROUGHLY HOW LONG THIS HAS BEEN GOING ON]
- How long I've worked with this client: [LENGTH OF RELATIONSHIP]
- Anything about this client's situation or personality I should account for: [OPTIONAL — e.g., "tight budget this quarter" or "very data-driven, wants numbers not feelings"]

Task: Write a rate increase conversation script for me to use with this client, built specifically from the scope-creep evidence I gave you above — not generic negotiation advice.

Constraints:
- Do not use generic language like "I feel my rates should reflect my value." Every argument must be tied to a specific, concrete example from the evidence I gave you.
- Keep the tone collaborative, not adversarial — the goal is to keep this client, not threaten to leave.
- If I didn't give you a target rate, do not invent one. Instead, note what I should think about when deciding my minimum acceptable number before the call.
- Anticipate real objections a reasonable client would raise, not strawman ones.

Output Format:
1. PRE-CALL MESSAGE (2-4 sentences to send before the conversation, sets up the discussion without stating numbers yet)
2. LIVE SCRIPT (opening line, evidence-based case built from my specific examples, responses to the 3 most likely objections)
3. FALLBACK OFFER (one paragraph — a concession I can offer if they push back hard)
4. PREP CHECKLIST (3 bullet points of things to confirm or decide before the call)

‏توضیحات بیشتر و مثال‌ها توی مقاله 👇

این پست مخصوص برنامه‌نویس‌هاست.

تیم توسعه‌ات یه تست داره که یه بار پاس می‌شه، یه بار فیل. همه می‌زنن ⁦re-run⁩، بار دوم سبز می‌شه، کار ادامه پیدا می‌کنه — و هیچ‌کس نمی‌پرسه چرا.

این پرامپت لاگ‌های واقعی خطا رو از چند ⁦run⁩ مختلف می‌خونه و به‌جای «همیشه اینطوریه»، حداقل دو فرضیه‌ی مشخص بهت می‌ده: هر کدوم رتبه‌بندی‌شده بر اساس میزان اطمینان، با یه خط مشخص از لاگ به‌عنوان شاهد — نه حدس کلی.

مهم‌ترین بخش خروجیش یه حکم صریحه: این تست رو می‌شه قرنطینه کرد و بعداً بررسی کرد، یا داره یه باگ واقعی رو پنهان می‌کنه که ممکنه تو ⁦production⁩ هم بزنه؟

📋 پرامپت کامل (لمس کن تا کپی بشه):

Act as a senior test infrastructure engineer who specializes in diagnosing intermittent, non-deterministic CI test failures ("flaky tests").

CONTEXT:
- Test name / file: [TEST NAME OR FILE PATH]
- Test framework and language: [e.g. "pytest, Python" or "Jest, TypeScript"]
- Failure frequency: [e.g. "1 in 15 runs" or "roughly once a week, no clear pattern"]
- Failure logs from 3-5 recent failed runs (paste full stack traces / error output, not summaries): [PASTE FAILURE LOGS HERE, SEPARATED BY RUN]
- Recent changes to the test or the code it covers, if known: [DESCRIBE OR PASTE RELEVANT DIFF, OR WRITE "NONE KNOWN"]
- What the test is actually verifying (in plain English): [ONE-SENTENCE DESCRIPTION OF TEST INTENT]

TASK:
Analyze the failure patterns across the provided logs and produce ranked root-cause hypotheses. Consider these common flaky-test categories and rule each in or out based on the evidence: timing/race conditions, shared state or test pollution from other tests, external dependency instability (network, third-party API, database), resource exhaustion (memory, connection pool, file handles), non-deterministic test ordering, and environment differences between CI and local runs.

CONSTRAINTS:
- Do not simply conclude "the test is flaky" without committing to at least 2 specific, falsifiable hypotheses ranked by likelihood
- Every hypothesis must cite specific evidence from the pasted logs -- if the logs don't support a hypothesis, don't include it
- Clearly distinguish between issues safe to quarantine now and investigate later, versus issues that likely mask a real production bug and must be fixed before quarantining
- If the provided logs don't contain enough information to diagnose confidently, say exactly that, and specify precisely what additional logging or instrumentation to add before the next failure

OUTPUT FORMAT:
1. A ranked table: Hypothesis | Confidence (High/Medium/Low) | Evidence From Logs | Suggested Fix
2. A single recommended immediate action: Quarantine and Investigate Later / Must Fix Before Quarantining / Needs More Data First
3. If "Needs More Data First": the exact logging statements or CI configuration change to add so the next failure captures what's missing

‏توضیحات بیشتر و مثال‌ها توی مقاله 👇