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

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

عینک هوشمند ⁦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

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