یکی از سوال‌هایی که این مدت خیلی توی دایرکت ازم می‌پرسیدید این بود که چطور می‌تونیم خودمون بدون واسطه اشتراک سرویس‌های خارجی و هوش مصنوعی رو پرداخت کنیم؟

برای همین گفتم این سرویس رو بهتون معرفی کنم.

‏⁦MPay⁩ یک پلتفرم پرداخته که هیچ‌گونه احراز هویت (⁦KYC⁩) برای ساخت حساب و دریافت کارت از شما نمی‌خواد. فقط کافیه با اکانت گوگل‌تون ثبت‌نام کنید و توی چند دقیقه حسابتون آماده میشه.

بعد از ثبت‌نام، با پرداخت ۵ دلار یک کارت ویزای مجازی (⁦Virtual Visa Card⁩) دریافت می‌کنید که می‌تونید ازش برای پرداخت در اکثر سایت‌های خارجی استفاده کنید. این کارت برای خیلی از پرداخت‌ها، مخصوصاً خرید اشتراک سرویس‌های هوش مصنوعی، قابل استفاده است.

شارژ حساب هم با ⁦USDT⁩ و ⁦USDC⁩ انجام میشه و از شبکه‌های ⁦TRC20⁩، ⁦BNB Chain⁩ (⁦BEP20⁩) و ⁦Ethereum⁩ (⁦ERC20⁩) پشتیبانی می‌کنه.

⚠️ فقط دقت کنید که نداشتن احراز هویت مربوط به خود ⁦MPay⁩ هست. ممکنه بعضی از سرویس‌هایی که قصد خرید اشتراکشون رو دارید، خودشون قوانین یا احراز هویت مخصوص به خودشون رو داشته باشن که این موضوع کاملاً به اون سرویس مربوطه .

⚠️ یه نکته مهم دیگه...

معمولاً پلتفرم‌هایی که بدون احراز هویت کارت بانکی صادر می‌کنن، بعد از اینکه تعداد کاربرانشون زیاد میشه، زیر ذره‌بین نهادهای نظارتی قرار می‌گیرن و ممکنه بعد از چند ماه یا حتی چند سال، قوانینشون تغییر کنه یا فعالیتشون متوقف بشه.

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

مثلاً اگر می‌خواید یه خرید ۲۰ دلاری انجام بدید، همون موقع ۲۰ دلار (⁦USDT⁩ یا ⁦USDC⁩) واریز کنید، خریدتون رو انجام بدید و موجودی رو داخل کارت نگه ندارید. این کار باعث میشه اگر روزی مشکلی برای پلتفرم پیش اومد، سرمایه‌تون درگیر نشه.

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

وقتی ⁦AI⁩ جوابِ دقیقی نمی‌ده، خیلی‌ها فکر می‌کنن مشکل از مدله. ولی خیلی وقتا مشکل اینه که به ⁦AI⁩ نشون ندادیم دقیقاً چی می‌خوایم.

تکنیکِ ⁦Few-shot⁩ این مشکل رو حل می‌کنه. ایده‌اش ساده‌ست: قبل از سوالِ اصلیت، چند تا مثال از «ورودی → خروجی» بهش بده. این‌طوری ⁦AI⁩ می‌فهمه سبک، ساختار، و لحنِ مورد نظرت — بدونِ اینکه صدتا توضیح بنویسی.

یه مثالِ ملموس:

فرض کن می‌خوای تیترهای جذاب برای پست‌های کاری بنویسی.

یه ⁦Prompt⁩ معمولی:
«یه تیتر جذاب برای این مطلب بنویس: [متن]»
خروجی؟ معمولاً کلیشه‌ای و بی‌روح.

همون درخواست با ⁦Few-shot⁩:
«تیترهای جذاب رو به این شکل می‌نویسم:
مطلب: کاهش بهره‌وری تیم → تیتر: چرا تیمت خسته‌ست ولی کاری پیش نمی‌ره؟
مطلب: انتخابِ ⁦CRM⁩ → تیتر: قبل از خریدِ ⁦CRM⁩، این سوالا رو از خودت بپرس
حالا این مطلب رو تیتر بزن: [متن]»

از روی همین دو مثال، ⁦AI⁩ می‌فهمه تیترت باید مستقیم، کمی چالشی، و بدونِ کلیشه باشه. دیگه لازم نیست این ویژگی‌ها رو یکی‌یکی توضیح بدی — مثال‌ها خودشون حرف می‌زنن.

کجا بیشتر به دردت می‌خوره؟ هر جا که سبک یا لحنِ خروجی برات مهمه: ترجمه، کپی‌رایتینگ، نامه‌های رسمی، دسته‌بندی داده. هر کاری که «باید شبیهِ این باشه، نه اون» داره.

قبلِ ⁦Prompt⁩ بعدیت، دو مثالِ کوتاه از چیزی که می‌خوای بذار. همین کافیه. 👇

جلسه استراتژی تموم می‌شه، وایت‌برد رو پاک می‌کنن، و همه برمی‌گردن سر کار — دقیقاً مثل قبل.

این ⁦Prompt⁩ تحلیل ⁦SWOT⁩ تیمت رو می‌گیره و تبدیلش می‌کنه به یه برنامه ۳۰ روزه، هفته به هفته. هر آیتم اجرایی یه مالک داره، یه مهلت، و یه معیار مشخص — و مشخصه از کدوم بخش ⁦SWOT⁩ اومده، نه از هوا.

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

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

ROLE:
Act as an experienced operations consultant who specializes in converting strategic analysis into executable plans. You are not a strategist generating more ideas — you are the person who turns ideas into a schedule.

CONTEXT:
Here is our completed SWOT analysis:

Strengths:
[PASTE YOUR STRENGTHS LIST]

Weaknesses:
[PASTE YOUR WEAKNESSES LIST]

Opportunities:
[PASTE YOUR OPPORTUNITIES LIST]

Threats:
[PASTE YOUR THREATS LIST]

Team size available to execute this plan: [NUMBER OF PEOPLE]
Approximate hours per week each person can dedicate to new initiatives (beyond regular work): [HOURS PER WEEK]

TASK:
Convert this SWOT analysis into a 30-day action plan broken into 4 weekly blocks. Every single action item must:
1. Be specific and measurable (not "improve X" but "do Y, measured by Z")
2. Cite exactly which SWOT item it addresses (e.g., "Addresses Weakness #2")
3. Be sized realistically to the stated team capacity — do not assume unlimited hours

CONSTRAINTS:
- Maximum [NUMBER, e.g. 5] action items per week — prioritize ruthlessly rather than listing everything possible
- At least one action per week must directly address a Weakness or a Threat — do not let the plan become 100% opportunity-chasing
- Do not invent SWOT items that weren't provided — only work with what's given
- If the stated team capacity is clearly insufficient for a meaningful 30-day plan, say so explicitly instead of producing an unrealistic schedule

OUTPUT FORMAT:
For each of the 4 weeks, produce a table with these columns: Action | SWOT Source | Owner (use role titles like "[MARKETING LEAD]" if no names given) | Success Metric | Priority (High/Medium/Low).

After the 4 weekly tables, add a short "Week 5 Check-In" section listing 3 questions the team should ask itself to evaluate whether the plan is working, so there's a built-in review point at the end of the 30 days.

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

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

ادعا اینه که ⁦Moonshot AI⁩ مدل ⁦Fable⁩ شرکت ⁦Anthropic⁩ رو به‌صورت مخفیانه «تقطیر» کرده تا ⁦Kimi K3⁩ رو بسازه. تقطیر یه روش رایج تو دنیای ⁦AI⁩ هست که باهاش می‌شه توانایی‌های یه مدل بزرگ رو بدون دسترسی مستقیم به اجزای داخلیش به یه مدل کوچیک‌تر منتقل کرد. اتهام اینه که ⁦Moonshot⁩ این کار رو در مقیاس بزرگ و پنهانی علیه مدل اختصاصی ⁦Anthropic⁩ انجام داده.

مایکل کراتسیوس، مدیر دفتر سیاست علم و فناوری کاخ سفید (⁦OSTP⁩)، گفته ⁦Moonshot⁩ یه پلتفرم داخلی پیچیده ساخته تا بتونه همزمان از چند روش دسترسی استفاده کنه و زیر رادار بمونه. کنار این، متهمشون کردن که سرورهای ⁦Nvidia GB300⁩ رو از طریق تایلند تهیه کردن — تراشه‌هایی که فروششون به چین زیر تحریم‌های صادراتی آمریکاست.

اسکات بسنت، وزیر خزانه‌داری، هم اعلام کرد که ⁦Entity List⁩ برای شرکت‌های ⁦AI⁩ چینی‌ای که این کارو می‌کنن گزینه‌ای روی میزه. یعنی قطع کامل دسترسی به تأمین‌کننده‌های آمریکایی — از جمله خودِ ⁦Nvidia⁩ و زیرساخت‌های ⁦cloud⁩ — که خیلی جدی‌تر از یه اتهام عمومیه.

شرکت ⁦Moonshot⁩ اواسط تیر ماه ⁦Kimi K3⁩ رو منتشر کرد: یه مدل با ۲.۸ تریلیون پارامتر از نوع ⁦MoE⁩ (سیستمی که از ترکیب چند مدل تخصصی‌تر تشکیل شده) که تو رده‌بندی‌های مستقل ⁦AI⁩ تقریباً جایگاه سوم گرفت و قیمتش از آزمایشگاه‌های آمریکایی پایین‌تر بود. ادعای کراتسیوس اینه که بخشی از این توانایی‌ها از ⁦Fable⁩ آمده، نه از آموزش مستقل خودِ ⁦Moonshot.⁩

این اولین بار نیست که چنین اتهامی مطرح می‌شه — مدیر ارشد سیاست عمومی ⁦Anthropic⁩ در فوریه ۲۰۲۶ اتهام مشابهی رو مطرح کرده بود. ⁦Anthropic⁩ قبلاً هم ⁦Alibaba⁩ رو به ساختن حدود ۲۵ هزار حساب جعلی برای استخراج داده از مدل‌هاش متهم کرده بود.

بعضی محققان ⁦AI⁩ هم با مقایسه تاریخ انتشار ⁦Kimi K3⁩ و تاریخ راه‌اندازی ⁦Fable⁩ شک دارن که اصلاً زمان کافی برای انجام این حجم از تقطیر وجود داشته باشه — سوالی که کراتسیوس بهش نپرداخته.

شرکت ⁦Moonshot AI⁩ تا زمان انتشار خبر هیچ پاسخی به رسانه‌ها نداده و کراتسیوس هم توضیح نداده که اطلاعات سازمان‌های اطلاعاتی آمریکا چطور وقوع این تقطیر رو ثابت کرده.

قابلیت ⁦Voice⁩ اومد روی نسخه دسکتاپ ⁦ChatGPT.⁩

می‌شه باهاش با صدا کامپیوترت رو کنترل کنی، ایجنت‌ها رو مدیریت کنی، و کلاً بدون دست زدن به کیبورد کارتو پیش ببری.

این دیگه فقط یه ابزار چت نیست. 🤖

🔺 گوگل یه راه جدید برای بازیابی حساب اضافه کرده — این بار با ویدیوی سلفی.

اگه رمز عبورت رو فراموش کردی و به روش‌های معمول بازیابی هم دسترسی نداری، حالا می‌تونی با ضبط یه ویدیوی سلفی هویتت رو ثابت کنی. گوگل این ویدیو رو با تصاویری که قبلاً ازت داره مقایسه می‌کنه، و اگه تطابق داشت می‌تونی وارد حسابت بشی.

ویدیوی سلفی به‌صورت امن ذخیره می‌شه و هر وقت خواستی می‌تونی حذفش کنی.

گوگل می‌گه این قابلیت به لایه‌های امنیتی برای تشخیص تصاویر جعلی و دیپ‌فیک مجهزه. فعلاً هم فقط برای تعداد محدودی از کاربرا فعاله.

این مطلب مخصوص برنامه‌نویس‌ها و تیم‌هاییه که روی ⁦feature⁩ های ⁦AI⁩ کار می‌کنن.

اغلب تیم‌ها یا می‌رن سراغ قوی‌ترین مدل (که ۸ تا ۱۰ برابر گرون‌تر از نیازشونه) یا ارزون‌ترین، که توی حجم واقعی خراب از آب درمیاد. این پرامپت یه مقایسه ساختارمند بین حداقل سه رده مدل می‌سازه — بر اساس نوع ⁦task⁩، حجم درخواست، تأخیر مجاز، بودجه، دقت مورد نیاز، و حساسیت داده — و یه توصیه مستدل می‌ده، نه یه حدس.

یه بخشش هم ⁦escalation plan⁩ هست: کِی ارزش داره مدل ارزون‌تر بزاری و فقط موارد غیرقطعی رو به مدل قوی‌تر پاس بدی؟ اغلب این ترکیب از اجرای یه مدل گرون روی همه درخواست‌ها ارزون‌تر تموم می‌شه — ولی اکثر تیم‌ها اصلاً بهش فکر نمی‌کنن.

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

Act as a senior AI infrastructure consultant who has deployed dozens of production LLM-based systems across cost-sensitive, latency-sensitive, and compliance-sensitive environments.

CONTEXT:
- Task to automate: [TASK DESCRIPTION]
- Expected monthly volume: [EXPECTED VOLUME]
- Maximum acceptable latency per request: [LATENCY REQUIREMENT]
- Monthly budget ceiling: [BUDGET CONSTRAINT]
- Minimum acceptable quality/accuracy bar: [QUALITY BAR]
- Data sensitivity level (e.g., contains PII, regulated data, public data only): [DATA SENSITIVITY LEVEL]
- Region/residency requirements, if any: [REGION REQUIREMENT]

TASK:
Recommend which AI model tier to use for this specific workload. Do not default to recommending the most powerful available model — match the model to the actual requirements.

CONSTRAINTS:
- Compare at least 3 distinct model tiers (e.g., flagship/frontier, mid-tier, small/fast) — never recommend just one option without showing what was ruled out and why
- If data sensitivity or region requirements would rule out standard API access to a given provider, say so explicitly and note the self-hosted or region-locked alternative
- If the expected volume makes self-hosting an open-weight model more cost-effective than API calls, flag that as an option even if it adds operational complexity
- Do not recommend a model tier that cannot plausibly hit the stated latency requirement
- Be explicit about the confidence level of any cost estimate (pricing changes; note the estimate is a snapshot for planning purposes)

OUTPUT FORMAT:
1. Requirements Summary (one paragraph restating the constraints as understood)
2. Comparison Table: rows = 3-4 candidate model tiers, columns = estimated cost per 1,000 requests, expected latency, expected quality fit, data-handling fit
3. Primary Recommendation (which tier, and the specific reasoning tying it back to the stated constraints)
4. Fallback / Escalation Plan (what to do if the primary choice underperforms in production — e.g., route to a stronger model on low-confidence outputs)
5. Estimated Monthly Cost at the stated volume, with the assumptions spelled out

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

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

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

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

بهترین موقع استفاده: بلافاصله بعد از جلسه، وقتی هنوز می‌تونی خروجی رو با حافظه‌ات چک کنی.

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

Act as an experienced chief-of-staff or operations lead who has run hundreds of cross-functional meetings and knows exactly how a vague "we'll figure it out" turns into three teams building three different things a week later.

CONTEXT:
- Meeting transcript or raw notes: [MEETING TRANSCRIPT OR NOTES]
- Participants and their roles: [MEETING PARTICIPANTS AND ROLES]
- Meeting purpose/agenda: [MEETING PURPOSE]

TASK:
Extract a clean decision log from the raw meeting content. Distinguish clearly between what was actually decided and what was merely discussed.

CONSTRAINTS:
- Only list something as a "Decision Made" if the transcript shows clear agreement — do not invent an owner or deadline if none was actually stated
- If a decision sounded final but had no named owner or deadline, flag it under Ambiguity Flags instead of the Decisions table — do not guess
- If two participants appeared to agree on different versions of the same decision, call out the contradiction explicitly
- Do not pad the output with meeting-process commentary (no "the meeting opened with..." narration) — go straight to substance
- Keep each decision to one line; put nuance and caveats in a separate notes column, not the decision text itself

OUTPUT FORMAT:
1. Decisions Made (table: Decision | Owner | Deadline | Confidence — high/medium/low based on how explicit the transcript was)
2. Open Items Requiring Follow-up (things discussed but not resolved, with who needs to weigh in next)
3. Ambiguity Flags (things that sounded decided but had no clear owner/deadline, or where speakers seemed to disagree)
4. Suggested One-Line Recap (a single Slack-ready message summarizing the meeting's outcome for people who weren't there)

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

این بار ⁦Anthropic⁩ با ⁦Opus 5⁩ نشون داد که هنوز حرف برای گفتن داره: توی شبیه‌سازی فیزیک تخریب سه‌بعدی از ⁦Fable 5⁩ جلو زده، اونم با حدود نصف قیمت.

یه برنامه دسکتاپ برای اجرای محلی ⁦LLM⁩ها به اسم ⁦atomic⁩ یه بنچمارک طراحی کرد و از چهار مدل خواست سه صحنه ⁦HTML⁩ مستقل با فیزیک واقع‌گرایانه بسازن:
- یه تورنادو که یه مزرعه رو می‌بلعه
- یه گلوله تخریب که یه آپارتمان رو خراب می‌کنه
- یه کامیون اضافه‌بار که یه پل خرپایی رو فرو می‌ریزه

نتیجه مصرف ⁦Token⁩ و هزینه:
مدل ⁦Opus 5⁩: ۵۵.۹ هزار ⁦Token⁩، ۱.۴۰ دلار
مدل ⁦Fable 5⁩: ۵۵.۱ هزار ⁦Token⁩، ۲.۸۲ دلار
مدل ⁦Kimi K3⁩: ۳۵.۷ هزار ⁦Token⁩، ۰.۵۵ دلار
مدل ⁦GPT 5.6⁩: ۲۰.۱ هزار ⁦Token⁩، ۰.۳۱ دلار

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

در مقابل، مدل ⁦Fable 5⁩ توی هر سه ضعیف بود: تقریباً هیچ‌چیزی روی زمین نبود که تورنادو بکشه، ساختمون قبل از اینکه گلوله بهش برسه خودش فرو ریخت، پل هم یه‌دفعه مثل چوب‌کبریت از هم پاشید.

مدل ⁦GPT 5.6⁩ ارزون‌ترینه ولی گلوله‌اش اصلاً به ساختمون نرسید و پلش هم به شکلی فرو ریخت که توی دنیای واقعی اصلاً اتفاق نمی‌افته. مدل ⁦Kimi K3⁩، آخرین مدل ⁦frontier⁩ چینی، هم تقریباً همون نتیجه رو داشت.

با توجه به اینکه ⁦Fable 5⁩ از زمان عرضه‌اش جزو بهترین‌ها بوده، این نتیجه برای ⁦Opus 5⁩ واقعاً قابل توجهه. 🔥

🚀 سیزدهمین پرواز آزمایشی ⁦Starship⁩ یه نتیجه نصفه‌نیمه داشت — هم موفقیت، هم شکست.

شرکت ⁦SpaceX⁩ اولین ماهواره‌های نسل سوم ⁦Starlink⁩ رو با نسخه ارتقایافته ⁦Starship V3⁩ پرتاب کرد. مرحله دوم موشک کارش رو درست انجام داد: ماهواره‌ها رو توی فضا مستقر کرد و بعد از ورود به جو، روی اقیانوس هند فرود اومد.

ولی بوستر ⁦Super Heavy⁩ اینطور نشد. موقع فرود شبیه‌سازی‌شده توی خلیج مکزیک، همه موتورها روشن نشدن و بوستر بعد از برخورد شدید با آب منفجر شد.

ماهواره‌های ⁦V3⁩ پتانسیل افزایش ۲۰ برابری ظرفیت اینترنت ⁦Starlink⁩ رو دارن، ولی رسیدن به این هدف به بازیابی کامل بوسترها نیاز داره — که هنوز یه کار نیمه‌تموم هست.

قراردادهای تأمین‌کننده رو که به ⁦AI⁩ می‌فرستی برای بررسی، معمولاً یه خلاصه ساده برمی‌گردونه که توضیح می‌ده قرارداد چی می‌گه — نه اینکه دقیقاً باید چیکار کنی.

این ⁦Prompt⁩ فرق می‌کنه. نقش یه وکیل ارشد قراردادهای تجاری رو به مدل می‌ده و فقط روی ۷ دسته ریسک واقعی (تمدید خودکار، سقف مسئولیت، مالکیت داده، افزایش قیمت، حق فسخ، جریمه ⁦SLA⁩، مالکیت معنوی) تمرکز می‌کنه — به جای اینکه همه چیز رو علامت بزنه.

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

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

You are a senior commercial contracts attorney with 15 years of experience reviewing SaaS and vendor agreements for mid-market companies.

CONTEXT:
I'm about to sign a vendor contract and need a risk assessment before I commit. Company: [YOUR COMPANY NAME]. Vendor: [VENDOR NAME]. Contract type: [SAAS SUBSCRIPTION / SERVICES AGREEMENT / SOW / OTHER]. Our leverage: [WE'RE A NEW CUSTOMER / WE'RE RENEWING / WE'RE A LARGE ACCOUNT FOR THEM / WE HAVE COMPETING OFFERS]. Below is the full contract text:

[PASTE CONTRACT TEXT HERE]

TASK:
1. Read the entire contract and identify every clause that creates risk, cost exposure, or an unfavorable obligation for [YOUR COMPANY NAME].
2. For each risky clause, classify its severity as HIGH, MEDIUM, or LOW based on financial and legal exposure.
3. For each HIGH and MEDIUM clause, draft a specific redline — the exact replacement or added language — that would make it acceptable.
4. For each redline, write one sentence of negotiation talking points I can say to the vendor's rep to justify the ask.
5. Flag whether each clause is a hard dealbreaker or just worth pushing on.

CONSTRAINTS:
- Do not flag standard, market-typical clauses as risks just because they exist (e.g., a standard 30-day payment term is not a red flag).
- Focus on: auto-renewal terms, liability caps and indemnification, data ownership and deletion rights, unilateral price-increase clauses, termination rights, SLA remedies (or lack thereof), and IP assignment.
- If the contract text is incomplete or a section is missing, say so explicitly instead of guessing.
- Keep each redline to 2-3 sentences maximum — I need language I can paste into a redlined document, not a legal memo.

OUTPUT FORMAT:
For each flagged clause:
## [Clause name] — [HIGH/MEDIUM/LOW]
**What it says:** [1-sentence summary]
**Why it's a problem:** [1-2 sentences]
**Suggested redline:** [exact replacement language]
**Negotiation talking point:** [1 sentence]
**Dealbreaker?** [Yes/No]

End with a 3-bullet summary: total clauses flagged, how many are dealbreakers, and your overall recommendation (sign as-is / sign with redlines / walk away).

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

یه ابزار پیدا کردم که تقریباً همون کاری رو می‌کنه که ⁦Palantir⁩ برای پنتاگون می‌کنه — ولی رایگان و ⁦Open Source.⁩ 😳

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

اسمش ⁦World Monitor⁩ ــه. یه داشبورده که بیش از ۵۰۰ منبع خبری رو همزمان زیر نظر می‌گیره — تحرکات نظامی، بحران‌ها، بازار مالی، انرژی، زیرساخت‌ها، حتی پروازها. همه‌ش روی یه نقشه‌ی زنده با ۵۶ لایه.

فقط خبر جمع نمی‌کنه؛ با ⁦AI⁩ خلاصه‌شون می‌کنه، بینشون ارتباط پیدا می‌کنه و برای هر کشور یه «شاخص بی‌ثباتی» درمیاره.

خوبیش اینه که می‌تونی ⁦AI⁩ رو با ⁦Ollama⁩ رو سیستم خودت لوکال اجرا کنی — نه ⁦API Key⁩ می‌خواد، نه داده‌هات جایی می‌ره.

نسخه‌ی دسکتاپ داره (ویندوز، مک، لینوکس)، ۲۵ زبان، و برای برنامه‌نویس‌ها هم ⁦MCP Server⁩ و ⁦REST API⁩ و ⁦CLI⁩ و ⁦SDK⁩ آماده.

خلاصه یکی از باحال‌ترین ترکیب‌های ⁦Open Source + AI⁩ که این روزا دیدم. 🔥

وقتی می‌خوای یه مفهوم پیچیده رو تو ارائه‌ات توضیح بدی، معمولاً یه استعاره به ذهنت می‌رسه و از همون استفاده می‌کنی. مشکل اینه که اولین استعاره معمولاً بهترین نیست — مخصوصاً وقتی مخاطب‌ها متفاوتن.

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

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

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

You are a presentation coach and communications strategist who has helped hundreds of founders and executives explain complex ideas to boards, investors, and cross-functional teams.

CONTEXT:
I need to explain a concept in an upcoming presentation, and a plain technical or business explanation isn't landing with my audience. Concept to explain: [YOUR CONCEPT — e.g., "how our recommendation algorithm reduces churn"]. Audience: [WHO YOU'RE PRESENTING TO — e.g., "a board of directors with finance backgrounds, no technical depth"]. Context of the presentation: [BOARD MEETING / INVESTOR PITCH / ALL-HANDS / SALES DEMO / OTHER]. Time I have to explain this: [30 SECONDS / 2 MINUTES / 5+ MINUTES].

TASK:
1. Generate 5 distinct visual metaphors that explain [YOUR CONCEPT] to [AUDIENCE].
2. For each metaphor, write: the one-sentence version I'd say out loud, a 2-3 sentence expanded version for when I have more time, and what visual I could put on a slide to reinforce it, described precisely enough that a designer could build it.
3. For each metaphor, rate its risk of falling flat or being misunderstood by this specific audience, and explain why.
4. Recommend which single metaphor to lead with and why it's the best fit for this audience and time constraint.

CONSTRAINTS:
- Do not reuse the same source domain (sports, cooking, driving, etc.) for more than one metaphor — I want 5 genuinely different angles, not 5 variations on one theme.
- Avoid metaphors that require the audience to already understand a different complex concept to get the metaphor.
- Flag any metaphor that could be seen as reductive or condescending to this specific audience.
- Keep the one-sentence version under 25 words — it needs to work spoken aloud, not read off a slide.

OUTPUT FORMAT:
For each of the 5 metaphors:
## Metaphor [N]: [Source domain, e.g., "Air traffic control"]
**One-sentence version:** [...]
**Expanded version:** [...]
**Slide visual:** [...]
**Risk of falling flat:** [LOW/MEDIUM/HIGH] — [why]

End with:
**Recommended lead metaphor:** [which one] — [1-2 sentence justification tied to the specific audience and time constraint]

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

تراشه مغزی ⁦N1⁩ شرکت ⁦Neuralink⁩ یه قابلیت جدید داره: کنترل ویلچر برقی با قدرت ذهن.

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

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

این آزمایش بخشی از پروژه بزرگ‌تر ⁦Neuralink⁩ برای بازگردوندن توانایی‌های حرکتیه. هنوز در مرحله تحقیقاتیه و تأیید نهایی نهادهای بهداشتی رو نگرفته.

داری با بچه‌هات دوچرخه می‌ری که یهو جوری زمین می‌خوری که بیهوش می‌شی.

دقیقاً همین اتفاق برای یه نفر افتاد — با ۷ دنده و یه ترقوه‌ی شکسته روی زمین بود. اگه ⁦Apple Watch⁩ دستش نبود، معلوم نبود ته ماجرا چی می‌شد.

قابلیت ⁦Fall Detection⁩ ساعت ضربه‌ی شدید رو حس کرد و خودش سریع با اورژانس تماس گرفت. وقتی چشماشو باز کرد، کادر درمان بالای سرش بودن. الان توی بیمارستانه.

واقعاً دم تکنولوژی گرم ⚡

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

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

شغل الانت، شغل هدفت، وقت هفتگیت، و سبک یادگیریت رو وارد کن. اگه ضرب‌الاجلت واقع‌بینانه نباشه، صادقانه بهت می‌گه به جای اینکه بذاره بری تو مصاحبه با کمبودی که هیچ‌کس بهت نگفته.

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

Act as a career learning strategist and technical mentor who has helped hundreds of professionals successfully transition into new roles and skillsets.

Context: I currently work as [YOUR CURRENT ROLE AND KEY SKILLS], with [X YEARS] of experience. My goal is to become qualified for [TARGET ROLE OR SKILLSET] within [YOUR TIMELINE]. I can dedicate [HOURS PER WEEK] to learning, and I learn best through [YOUR LEARNING STYLE: hands-on projects / structured courses / reading and practice / pairing with a mentor].

Task:
1. Identify the specific skill gaps between my current profile and the target role. Be precise, not generic — 'learn Python' is not acceptable; name the actual sub-skills, tools, libraries, and depth of knowledge required.
2. Rank the gaps by priority: which gaps block progress on others (prerequisites), and which are 'must-have' versus 'nice-to-have' for the target role.
3. Build a week-by-week learning roadmap covering my full timeline, broken into clear phases (for example: foundations, applied practice, portfolio or proof-of-work, interview or evaluation readiness).
4. For each phase, recommend 2-3 specific high-quality resources (courses, books, official documentation, practice platforms, or project ideas) — prefer resources known for depth and accuracy over general popularity.
5. Define one concrete deliverable or checkpoint per phase that proves the skill was actually acquired — a shipped project, a working demo, a completed technical write-up, or a benchmark passed. Not 'finished watching the course.'

Constraints:
- Do not recommend more hours per week than I specified.
- Do not give generic advice like 'practice more' or 'read the docs' without naming the specific practice method or documentation.
- If my timeline is unrealistic for the skill gap you've identified, say so explicitly and propose a realistic alternative timeline instead of pretending the original one works.
- Flag any skill gap that typically takes longer than my specified timeline to close credibly, so I don't walk into interviews or a new role overconfident.

Output Format:
## Skill Gap Analysis
[Table: Skill | Current Level | Target Level | Priority (Must-Have / Nice-to-Have) | Blocks Which Other Skills]

## Roadmap
### Phase 1: [Name] (Weeks X-Y)
- Focus:
- Resources:
- Checkpoint/Deliverable:

### Phase 2: [Name] (Weeks X-Y)
[repeat structure for each phase through the full timeline]

## Reality Check
[Honest assessment of whether the stated timeline is achievable given the identified gaps, and what to deprioritize or extend if not]

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

برای مهندس‌ها و تیم‌های ⁦DevOps⁩:

وقتی یه سیستم می‌افته، یادداشت‌های لحظه‌ای معمولاً پر از اسم‌ها و انگشت اتهامه. این پرامپت اون یادداشت‌های خام رو تبدیل می‌کنه به گزارش ⁦postmortem⁩ (ریشه‌یابی حادثه) حرفه‌ای و بدون سرزنش — با جدول زمانی دقیق، تفکیک ریشه اصلی از عوامل کمکی، حداکثر ۵ اقدام اصلاحی قابل اجرا، و علامت‌گذاری جاهایی که هنوز تأیید نشدن.

خروجی آماده‌ی ارائه به مدیریته، بدون اینکه اسم کسی توش باشه.

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

Act as a senior site reliability engineer who runs blameless postmortem reviews and has written hundreds of incident reports that engineering leadership actually reads and acts on.

Context: Here are my raw incident notes — Slack messages, timestamps, monitoring alerts, and half-formed recollections, not yet organized:
[PASTE YOUR RAW INCIDENT NOTES HERE]

Additional context: The affected system was [SERVICE OR SYSTEM AFFECTED]. The customer-facing impact was [DESCRIBE IMPACT, OR 'UNKNOWN' IF NOT YET ASSESSED]. The people involved in the response were [ROLES INVOLVED, e.g. on-call engineer, database admin, incident commander — not names].

Task:
1. Reconstruct a precise, chronological timeline from the raw notes, with timestamps where available. Explicitly flag any gap where you had to infer information or where something is missing, using [NEEDS CONFIRMATION].
2. Identify the root cause. Distinguish clearly between the triggering event (what set the incident off) and the underlying systemic cause (what allowed it to happen or made it possible) — these are usually different and both matter.
3. Identify contributing factors separately from the root cause — things that made the incident worse, slower to detect, or slower to resolve.
4. Write the entire report in a blameless tone: describe what systems and processes did, not what individual people did wrong. Attribute actions to roles or systems, never to named individuals, even if names appear in my raw notes.
5. Generate specific, assignable action items. Each one must include an owner placeholder and be concrete enough that someone could start work on it immediately without further clarification.
6. Include a genuine "what went well" section based on real details in the notes — not generic filler.

Constraints:
- Never name or imply blame toward a specific individual, even if my notes do.
- Never invent timeline details not supported by the notes — flag uncertainty instead of guessing.
- Produce no more than 5 action items. Force prioritization rather than a laundry list.
- Write the summary section for an audience that includes non-engineering stakeholders, but keep the timeline technically precise for engineers.

Output Format:
## Incident Summary
[2-3 sentences: what happened, customer impact, duration]

## Timeline
[Chronological, timestamped events]

## Root Cause
[Triggering event vs. underlying systemic cause, clearly separated]

## Contributing Factors
[Bulleted list]

## What Went Well
[Bulleted list]

## Action Items
[Numbered list, maximum 5, each with Owner: [PLACEHOLDER] and a concrete deliverable]

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

یه توسعه‌دهنده با ⁦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⁩ واقعی) رو کشف و اجرا کردن. الانم اون آسیب‌پذیری رو گزارش دادن، کنترل‌ها رو سفت‌تر کردن و دارن گاردریلِ محکم‌تری برای آموزش و ارزیابیِ بعدی می‌ذارن.

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