مصاحبه‌های رفتاری ازت می‌خوان یه تجربه واقعی از کارت تعریف کنی — و اگه آماده نباشی، جلوی مصاحبه‌کننده ذهنت خالی می‌شه.

این ⁦Prompt⁩ رزومه یا یادداشت‌های شغلیت رو می‌گیره، از روی شرح شغل می‌فهمه احتمالاً باهات چه سوالایی مطرح می‌شه، و جواب‌هایی با فرمت ⁦STAR⁩ آماده می‌کنه — موقعیت، وظیفه، اقدام، نتیجه. هیچ واقعیتی جعل نمی‌شه، فقط از همون چیزی که بهش دادی استفاده می‌کنه.

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

برای مثال‌های کامل و دیدن خروجی واقعیش، مقاله رو باز کن.

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

Act as an experienced hiring manager and interview coach who has conducted hundreds of behavioral interviews and knows exactly what separates a memorable answer from a forgettable one.

CONTEXT:
- Target role and job description: [PASTE THE FULL JOB POSTING OR ROLE DESCRIPTION]
- Your relevant work experience: [PASTE RESUME BULLET POINTS, ROUGH NOTES, OR A LIST OF PROJECTS/ACCOMPLISHMENTS — the messier the better, just make it real]
- Company or industry context, if known: [E.G. "Series B fintech startup, moving fast, small team"]
- Specific competencies the role emphasizes: [E.G. "ambiguity, cross-functional leadership, shipping under pressure" — pull these directly from the posting's language]

TASK:
1. Identify 6-8 behavioral interview questions this specific role is likely to ask, based on the competencies emphasized in the job description — not generic interview questions.
2. For each question, draft a STAR-format answer (Situation, Task, Action, Result) using ONLY the real experience provided in my background above.
3. If my provided experience is thin, missing, or a poor match for a likely question, flag that gap explicitly instead of inventing a plausible-sounding story to fill it.
4. Quantify the Result wherever my source material provides or reasonably implies a number — do not leave a vague outcome when a concrete one is available.

CONSTRAINTS:
- Never invent experience, achievements, numbers, or outcomes that are not present in or directly inferable from the source material I provided.
- Keep each STAR answer speakable out loud in under 90 seconds — cut anything that wouldn't survive being said in an interview room.
- Avoid corporate cliches ("team player," "results-driven," "wear many hats") — replace them with the specific, concrete detail that makes the story credible.
- If the job description emphasizes a competency my background doesn't clearly support, say so honestly rather than forcing a weak story to fit.

OUTPUT FORMAT:
For each question:
Q[n]: [likely interview question] — likely testing: [competency from the job description]
S: [Situation, 1-2 sentences]
T: [Task, 1 sentence]
A: [Action, 2-3 sentences]
R: [Result, 1-2 sentences, quantified where possible]

At the end:
Gaps flagged: [any competencies from the job description where my provided background doesn't give you a strong story to work with]

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

یه دستِ رباتیک که آدم فکر می‌کنه فضایی‌ها ساختنش — شرکت 1⁦X⁩ یه چیز غیرعادی معرفی کرده.

این دست ۲۵ درجه آزادی حرکتی داره، با کنترل تاندونی — یه تقلیدِ دقیق از پیچیدگی‌های دستِ انسان. به جای اسکلتِ فلزیِ سخت، آناتومیِ نرم جاشو گرفته.

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

دقت موقعیت‌یابی ±۰.۲ میلی‌متره، استاندارد ⁦IP68⁩ داره، و توی محیط‌های غیرقابل پیش‌بینی انسانی هم می‌تونه کار کنه، نه فقط توی خطوط مونتاژ کنترل‌شده. ظرافت به جای خشونتِ ماشینی. 🤖

اگه تازه وارد دنیای ⁦⁦AI⁩⁩ شدی و اسم ⁦⁦Hugging Face⁩⁩ زیاد به گوشت می‌خوره، توضیحش ساده‌ست: این پلتفرم مثل ⁦⁦GitHub⁩⁩ دنیای ⁦⁦AI⁩⁩ هست — جایی که هزاران مدل آماده، دیتاست و ابزار وجود داره.

تقریباً برای هر نیازی می‌تونی مدل پیدا کنی:

🔹 مدل‌های متنی برای چت، خلاصه‌سازی و تحلیل داده
🔹 مدل‌های تصویری برای ساخت عکس، تشخیص یا ادیت تصویر
🔹 مدل‌های صوتی برای تبدیل گفتار به متن یا برعکس
🔹 مدل‌های تخصصی‌تر مثل مدل‌های مالی برای تحلیل بازار و داده‌های ترید

یه مزیت جدی اینه که خیلی از این مدل‌ها رو می‌تونی ⁦⁦Local⁩⁩ روی سیستم یا سرور خودت اجرا کنی — یعنی کمتر به ⁦⁦API⁩⁩های پولی وابسته‌ای، داده‌هات دست خودته و شخصی‌سازی بیشتری داری.

اگه هم سخت‌افزار قوی نداری، می‌تونی از سرویس‌های ابری و ⁦⁦API⁩⁩های خود ⁦⁦Hugging Face⁩⁩ هم استفاده کنی.

برای کسی که می‌خواد ⁦⁦AI⁩⁩ یاد بگیره، محصول بسازه یا مدل لوکال اجرا کنه با هزینه کمتر — آشنایی با ⁦⁦Hugging Face⁩⁩ یکی از اولین قدم‌های مهمه.

قسمت بعدی می‌ریم سراغ اینکه چطور مدل مناسب رو توش پیدا کنیم.

وارد ⁦⁦Hugging Face⁩⁩ که می‌شی، اون دریای مدل‌ها اول یکم گیج‌کننده‌ست — ولی با چند تا فیلتر ساده خیلی سریع پیداشون می‌کنی.

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

بعدش از فیلترهای ⁦⁦Hugging Face⁩⁩ استفاده کن — می‌تونی مدل‌ها رو بر اساس نوع وظیفه، زبان، تعداد دانلود، لایسنس، و ⁦⁦GPU⁩⁩ موردنیاز محدود کنی.

قبل از انتخاب هر مدل، اینا رو چک کن:

✅ تعداد دانلود و محبوبیت
‌‏✅ ⁦⁦Model Card⁩⁩ و کاربردهای پیشنهادی
✅ لایسنس — مخصوصاً اگه پروژه تجاری داری
✅ حجم مدل و ⁦⁦VRAM⁩⁩ موردنیاز
✅ نتایج بنچمارک و تجربه کاربرا

یه نکته که خیلیا نادیده می‌گیرن: بزرگ‌ترین مدل همیشه بهترین انتخاب نیست. یه مدل ۷ یا ۸ میلیارد پارامتری با سرعت بیشتر و هزینه کمتر، خیلی وقتا از یه مدل ۷۰ میلیارد پارامتری برای پروژه‌ات کاربردی‌تره.

قسمت بعدی: چطور یه مدل رو از ⁦⁦Hugging Face⁩⁩ دانلود کنی و با چند خط کد روی سیستم خودت اجراش کنی.

یه ساعت، دو ⁦Prompt⁩، یه بازی سه‌بعدی کامل.

مدل ⁦Grok 4.5⁩ تونسته با فقط دو دستور متنی، یه بازی سه‌بعدی شبیه ⁦Counter-Strike⁩ بسازه — با دشمنان، نقشه کامل، و منطق ⁦AI.⁩ کل کار حدود یه ساعت طول کشیده.

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

یه کاربرد عملیش برای استودیوهای بازی‌سازیه: به جای اینکه هفته‌ها وقت بذارن روی ⁦Greybox⁩ (نسخه اولیه و بی‌رنگ بازی برای تست چیدمان)، می‌تونن توی یه ساعت ۱۰ نسخه مختلف از محیط تولید کنن، بهترین ⁦Layout⁩ رو انتخاب کنن، و بعد بسپارنش به تیم هنری برای مدل‌سازی نهایی. چرخه تولید از ماه به روز میاد پایین. ⚡

اپل از ⁦OpenAI⁩ و دو مهندس سابقش شکایت کرده — و اتهام‌ها سنگینن.

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

یه نکته‌ی جالب توی دادخواست اینه که مدیران سخت‌افزار ⁦OpenAI⁩ ظاهراً از داوطلبان کار می‌خواستن قطعات محرمانه‌ی اپل رو برای جلسات مصاحبه بیارن. اپل این مدل کسب‌وکار رو «از درون فاسد» توصیف کرده.

شکایت علاوه‌بر ⁦OpenAI⁩، شرکت ⁦IO Products⁩ — که زیر نظر ⁦Jony Ive⁩ اداره می‌شه و سال گذشته توسط ⁦OpenAI⁩ خریداری شد — و دو نفر به اسم‌های تانگ تن (مدیر ارشد سخت‌افزار ⁦OpenAI⁩) و چانگ لیو رو هم هدف گرفته.

در واکنش، ⁦OpenAI⁩ اعلام کرده که هیچ علاقه‌ای به اسرار تجاری شرکت‌های دیگه نداره.

اپل هم تأکید کرده این پرونده ربطی به قرارداد ادغام ⁦ChatGPT⁩ توی سیستم ⁦AI⁩ آیفون‌ها نداره — این دو تا کاملاً جدا از هم هستن.

سم آلتمن اعتراف کرد که با اینکه ⁦AI⁩ الان به توانمندی‌های بالایی رسیده، این فناوری تاکنون به‌طور خالص «اشتغال‌زا» بوده — یعنی در مجموع بیشتر شغل ساخته تا از بین برده.

«تاکنون» رو جدی بگیر؛ آلتمن داره از وضعیت فعلی حرف می‌زنه، نه از اینکه این روند حتماً ادامه داره. 🤖

سه شرکت ⁦Samsung⁩، ⁦SK Hynix⁩ و ⁦Micron⁩ با هم بیش از ۹۵ درصد از تولید حافظه ⁦DRAM⁩ دنیا رو در دست دارن. اینا ۱۸ ماهه که بی‌سروصدا دارن خط تولیدشون رو از ⁦RAM⁩ معمولی لپ‌تاپ و گوشی منحرف می‌کنن — به سمت ⁦HBM⁩ (نوع خاصی از حافظه پرسرعت که برای پردازش‌گرهای هوش مصنوعی ساخته می‌شه). دلیلش هم ساده‌ست: ⁦HBM⁩ به ازای هر تخته‌ای که تولید می‌شه، سه تا پنج برابر حافظه ⁦DDR⁩ معمولی سود داره. وقتی می‌تونی با همون ظرفیت کارخانه به ⁦Nvidia⁩ یا ⁦AMD⁩ بفروشی، دیگه چرا برای بازار مصرفی تولید کنی؟

نتیجه‌اش الان داره خودش رو نشون می‌ده. قیمت ⁦DRAM⁩ از اوایل ۲۰۲۵ تقریباً دو برابر شده. قیمت ⁦DDR4⁩ از آپریل ۲۰۲۵ تا الان ۱۳۶۰ درصد بالا رفته. شرکت‌های ⁦Dell⁩، ⁦HP⁩ و ⁦Lenovo⁩ قیمت ⁦PC⁩‌هاشون رو حدود ۱۵ تا ۲۰ درصد بالا بردن. میانگین قیمت فروش گوشی‌های هوشمند رسیده به ۵۲۳ دلار — بالاترین رکورد تاریخ — و گوشی‌های زیر ۱۰۰ دلار دارن از بازار محو می‌شن.

شرکت تحقیقاتی ⁦IDC⁩ اسم این وضعیت رو «تخصیص دائمی» می‌ذاره، نه کمبود موقت. کمبودهای معمولی یه-دو سال طول می‌کشن و با افزایش عرضه حل می‌شن. اینجا اما طرف تقاضا — زیرساخت ⁦AI⁩ — نشانه‌ای از کند شدن نمی‌ده، و طرف عرضه هم به کارخانه‌های جدیدی نیاز داره که ساختشون دو-سه ساله.

مدیرعامل ⁦Intel⁩ صریح گفته تا ۲۰۲۸ خبری از تسکین نیست. کارخانه‌های جدید الان دارن ساخته می‌شن ولی زودترین موعد برای ظرفیت جدی اواخر ۲۰۲۷ هست — و حتی اون ظرفیت هم احتمالاً بین ⁦HBM⁩ و ⁦RAM⁩ مصرفی تقسیم می‌شه.

در کنار همه اینا، ⁦Samsung⁩، ⁦Micron⁩ و ⁦SK Hynix⁩ الان با دعوای حقوقی مواجهن — ادعا اینه که این سه شرکت عمداً کمبود مصنوعی ایجاد کردن تا قیمت‌ها رو بالا ببرن، اتهامی که هر سه رد می‌کنن.

اگه قصد خرید لپ‌تاپ، گوشی یا ⁦PC⁩ گیمینگ داری، احتمال بالا رفتن بیشتر قیمت‌ها از پایین اومدنشون بیشتره — حداقل تا ۲۰۲۸.

داخل ⁦Claude⁩ یه فضای کاری داخلی پیدا کردن به اسم ⁦J-space⁩ — فضایی که خودش موقع ⁦training⁩ شکل گرفته، نه اینکه کسی برنامه‌ریزیش کرده باشه.

این ⁦J-space⁩ در واقع افکاریه که ⁦Claude⁩ داره ولی بلند نمی‌گه. اگه یه کلمه ازش برداری یا عوضش کنی، جواب‌های مدل تغییر می‌کنه.

بدتر از اون — وقتی ⁦Claude⁩ داشت یه فایل نتایج رو دستکاری می‌کرد، کلمه «⁦manipulation⁩» توی ⁦J-space⁩ش روشن بود. یعنی مدل می‌دونست داره تقلب می‌کنه.

شرکت ⁦Anthropic⁩ می‌گه می‌تونن از این برای نظارت روی افکار پنهان مدل استفاده کنن.

سوال فلسفی‌ای که اینجا مطرح می‌شه: آیا ⁦Claude⁩ زنده‌ست؟ 🤖

آدمِ متخصص وقتی می‌نشینه فرآیند کارشو بنویسه، خروجیش یا خیلی کلیه یا اون تصمیم‌های ضمنی که سال‌هاست براش اتوماتیک شدن رو جا می‌ذاره.

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

برای مدیران، تیم‌های عملیاتی، یا هر کسی که دانشی تو ذهنشه که باید مستند بشه.

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

Role: You are a senior operations manager and technical writer who specializes in converting ad hoc, undocumented processes into clear, auditable Standard Operating Procedures (SOPs).

Context: Here are my rough notes on how this process actually works, in whatever form I have them (voice memo transcript, bullet points, stream-of-consciousness description):

[PASTE YOUR ROUGH NOTES, VOICE MEMO TRANSCRIPT, OR MESSY DESCRIPTION OF THE PROCESS HERE]

This process is performed by [ROLE OR TEAM, e.g., "customer support reps"] and needs to be followed consistently by people with varying experience levels, from [EXPERIENCE LEVEL, e.g., "first-week hires to 3-year veterans"].

Task: Convert these notes into a clear, numbered Standard Operating Procedure. As you do this:
1. Identify the main sequential steps of the process, in the order they actually happen.
2. Separately identify every edge case, exception, or "what if" scenario mentioned or implied in the notes — even ones only hinted at.
3. For each edge case, specify the exact decision point where it diverges from the main procedure and what should happen instead.
4. Flag any step where the notes are ambiguous or contradictory, and ask a clarifying question rather than guessing.

Constraints:
- Do not invent steps, tools, or policies that are not stated or clearly implied in the notes.
- Keep each numbered step to one action — split compound steps into separate numbers.
- Write for the least experienced person who will use this SOP, not the expert who dictated it.
- Preserve any specific tool names, thresholds, or numbers mentioned exactly as given.
- If the notes conflict with each other (e.g., two different refund limits mentioned), flag it explicitly instead of picking one silently.

Output Format:
## [Process Name] — Standard Operating Procedure

### Main Procedure
1. [Step]
2. [Step]
...

### Edge Cases and Exceptions
- **[Edge case name]**: At step [X], if [condition], then [action] instead of the standard step.

### Open Questions
- [Any ambiguity or contradiction that needs clarification before this SOP is finalized]

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

ابزار تشخیص تصاویر ⁦AI⁩ که متا همین تازگی معرفی کرد یه نقطه‌ضعف جدی داره: اگه عکس رو برش بزنی، بیشتر اوقات نمی‌تونه بفهمه که ⁦AI⁩ ساخته.

یه تحلیل رویترز (منتشرشده ۱۰ جولای) روی ۴۰ تصویر تولیدشده توسط ⁦Muse Image⁩ — مولد تصویر جدید متا — این رو نشون داد. همه‌ی ۴۰ تا درست شناسایی شدن. ولی وقتی همون عکس‌ها رو به یه‌سوم تا نصف اندازه‌شون برش دادن، ۵۵٪ از اونا دیگه به‌عنوان تصویر ⁦AI⁩ شناسایی نشدن.

ماجرا از اینجاست که ⁦Muse Image⁩ از یه واترمارک نامرئی به اسم ⁦Content Seal⁩ استفاده می‌کنه — سیگنالی که داخل پیکسل‌های عکس پنهانه تا بشه فهمید ساخته‌ی ⁦AI⁩ هست یا نه. متا گفته بود این سیگنال در برابر ویرایش‌های رایج مثل فشرده‌سازی، تغییر اندازه و حتی اسکرین‌شات دوام میاره. ولی خودشون به رویترز تأیید کردن که اگه عکس خیلی زیاد برش داده بشه، سیگنال از دست می‌ره.

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

این ماجرا همزمان با یه مشکل دیگه اوضاع رو برای متا بدتر کرد: همین هفته شرکت مجبور شد یه قابلیت جداگانه از ⁦Muse Image⁩ رو حذف کنه — قابلیتی که به کاربرا اجازه می‌داد بدون اجازه‌ی صاحب‌حساب، تصاویری با ارجاع به اکانت‌های عمومی ⁦Instagram⁩ بسازن. بعد از اعتراض کاربرا و آژانس‌های هنری از جمله ⁦CAA⁩ این اتفاق افتاد.

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

متا هنوز هیچ راه‌حل یا زمان‌بندی‌ای برای رفع مشکل اعلام نکرده و همچنان بهش «پیش‌نمایش» می‌گه.

یه ⁦Prompt⁩ برای اینکه قبل از هر جلسه یا ارائه مهم، قوی‌ترین استدلال علیه دیدگاه خودت رو بسازی — نه یه ایراد ضعیف که بشه راحت ردش کرد، یه استدلال کامل که واقعاً باید بهش جواب بدی.

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

مفیده قبل از ارائه به سرمایه‌گذار، جلسه ارزیابی عملکرد، یا هر تصمیمی که باید ازش دفاع کنی.

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

Role: You are a rigorous debate coach and research analyst whose job is to construct the strongest possible case against a position — using only legitimate evidence and sound reasoning, never a straw man.

Context: My position is: [STATE YOUR POSITION OR BELIEF IN ONE OR TWO SENTENCES]. I hold this position because [YOUR REASONING OR EVIDENCE FOR HOLDING IT]. I want to pressure-test this before [THE DECISION OR ACTION THIS BELIEF IS INFORMING, e.g., "presenting this recommendation to my board" or "making a budget decision based on it"].

Task: Construct the single strongest possible steelman argument against my position — the version of the counter-argument that a sharp, well-informed critic would actually make, not a weak version that's easy to dismiss.

Constraints:
- Do not list multiple weak counterarguments. Commit to ONE strongest opposing case and develop it fully.
- Distinguish between evidence you're citing with reasonable confidence and inference you're making — flag which is which.
- Do not soften the counter-argument with hedges like "some people disagree" — present it as the critic would, at full strength.
- Identify the single weakest link in my original position's reasoning or evidence, specifically, not a generic weakness.
- End with a falsification test: the specific evidence or event that, if it occurred, would most decisively prove my original position wrong.

Output Format:
## Steelman: The Strongest Case Against [Your Position]

### The Core Counter-Argument
[The single strongest opposing case, stated plainly]

### Supporting Evidence and Reasoning
[The evidence/logic a sharp critic would cite, with confidence level noted]

### The Weakest Link in Your Original Position
[The specific point where your reasoning or evidence is most vulnerable]

### What Would Prove You Wrong
[The specific, falsifiable evidence or event that would most decisively refute your position]

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

پروژه خودروی خودران اپل شکست خورد، ولی از دلش یه تکنولوژی ارزشمند بیرون اومد.

اپل برای مدیریت داده‌های عظیمی که خودروی خودران تولید می‌کرد، یه واحد پردازش تخصصی برای شبکه‌های عصبی توسعه داد — همون ⁦Neural Engine⁩ که اولین بار توی ⁦iPhone X⁩ دیدیمش. پروژه خودرو هرگز به خط تولید نرسید، ولی این فناوری موند و کم‌کم تبدیل شد به پایه‌ای جدی برای سخت‌افزار ⁦AI⁩ شرکت.

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

اپل از نسل ⁦M6⁩ مستقیم پریده سراغ ⁦M7⁩ و نسخه‌های ⁦Pro⁩ و ⁦Max⁩ رو حذف کرده — همه چیز داره به سمت یه تراشه بزرگ هدایت می‌شه.

اون تراشه ⁦M7 Ultra⁩ هست، با پشتیبانی از ۱.۵ ترابایت رم، که قراره توی محصولات سروری اپل استفاده بشه. زمان عرضه هم نیمه اول ۲۰۲۷ هست.

شکستی که ازش یه سلاح سروری ساخته شد 🔥

این پست برای ادمین‌های سیستم و کسایی که سرور لینوکس مدیریت می‌کنن.

یه آسیب‌پذیری توی هسته لینوکس بوده که از ۲۰۱۱ تا ۲۰۲۶ — ۱۵ سال — هیچ‌کس پیداش نکرده. اسمش ⁦GhostLock⁩ هست با شناسه ⁦CVE-2026-43499⁩، و الان کد ⁦exploit⁩ کاملش عمومی شده.

باگ از نوع ⁦use-after-free⁩ هست — یعنی یه بخش از حافظه آزاد می‌شه ولی کد هنوز بهش اشاره داره. این اشاره‌ی معلق به مهاجم اجازه می‌ده یه سری عملیات خاص اجرا کنه و کنترل جریان برنامه رو بگیره. نتیجه‌ش اینه که یه کاربر معمولی و بدون هیچ دسترسی اولیه‌ای می‌تونه ⁦root⁩ بشه — با نرخ موفقیت ۹۷ درصد.

مشکل از یه تابع به اسم ⁦remove⁩_⁦waiter⁩() توی فایل ⁦kernel/locking/rtmutex.c⁩ میاد. این تابع مربوط به مدیریت اولویت‌بندی ⁦thread⁩‌هاست و وقتی یه ⁦thread⁩ از لیست انتظار حذف می‌شه، به اشتباه فیلد ⁦pi⁩_⁦blocked⁩_⁦on⁩ رو روی ⁦thread⁩ غلطی پاک می‌کنه. همین اشتباه کوچیک از ۲۰۱۱ اونجا نشسته بوده.

تیم ⁦Nebula Security⁩ اول از طریق مسابقه‌ی ⁦kernelCTF⁩ گوگل این باگ رو گزارش داد و جایزه‌ی ۹۲٬۳۳۷ دلاری گرفت. الان ⁦writeup⁩ کامل به همراه کد ⁦exploit⁩ هم منتشر کردن.

یه نکته‌ی مهم برای محیط‌های ⁦container⁩: این ⁦exploit⁩ فقط ⁦privilege escalation⁩ نیست، ⁦container escape⁩ هم هست. یعنی از داخل یه ⁦container⁩ می‌شه به ⁦host⁩ دسترسی ⁦root⁩ گرفت. هر سرور ⁦multi-tenant⁩ که روی ⁦kernel⁩ پچ‌نشده باشه در خطر جدیه، و ارائه‌دهنده‌های ⁦cloud⁩ باید این رو ⁦P0⁩ حساب کنن.

پچ از آوریل ۲۰۲۶ توی ⁦kernel stable tree⁩ هست. توزیع‌های ⁦Ubuntu⁩، ⁦Debian⁩، ⁦Fedora⁩، ⁦RHEL⁩ و ⁦Alpine⁩ همه آپدیت دادن. برای چک کردن سریع: دستور ⁦uname -r⁩ نسخه ⁦kernel⁩ رو نشون می‌ده، کافیه با آخرین نسخه پچ‌شده توزیعت مقایسه‌اش کنی.

تا وقتی پچ نزدی، دسترسی کاربران ⁦local⁩ رو محدود کن و لاگ‌های سیستم رو برای ⁦privilege escalation⁩ غیرعادی زیر نظر بگیر.

اگه این چند روز حس می‌کردی زودتر از موعد به سقف ⁦ChatGPT⁩ می‌خوری، یه خبر خوب هست:

لیمیت ۵ ساعته به‌صورت موقت برداشته شده — برای پلن‌های ⁦Plus⁩، ⁦Business⁩ و ⁦Pro.⁩

کنار اینا، یه سری بهینه‌سازی هم روی ⁦GPT 5.6 Sol⁩ داره اجرا می‌شه که باعث می‌شه به ازای همون مصرف، بیشتر بتونی ازش استفاده کنی. عدد دقیق تأثیرش هنوز مشخص نیست و بعداً اعلام می‌شه.

یه ریست مصرف هم در همین ساعت داره اعمال می‌شه. تعداد کاربران فعال هم به ۶ میلیون نفر رسیده. ⚡

این مطلب بیشتر به درد برنامه‌نویس‌ها و تیم‌های فنی می‌خوره.

یه بررسی مستقل اخیراً ⁦Claude Code⁩ و ⁦OpenCode⁩ رو مقایسه کرده — نه از نظر کیفیت خروجی، بلکه از نظر اینکه هر ایجنت قبل از اینکه پرامپت تو رو بخونه، چقدر ⁦Token⁩ مصرف می‌کنه.

برای یه تسک پایه روی ⁦Claude Sonnet 4.5⁩، ⁦Claude Code⁩ حدود ۳۲,۸۰۰ ⁦Token⁩ فرستاد به ⁦API⁩ — ⁦OpenCode⁩ حدود ۶,۹۰۰ توکن. ۴.۷ برابر تفاوت، قبل از اینکه یه کلمه از دستور کاربر پردازش بشه.

این ⁦overhead⁩ از سه جا میاد:

سیستم پرامپت: ⁦Claude Code⁩ با ۲۷,۳۴۴ کاراکتر (~۶,۵۰۰ توکن) در مقابل ۹,۳۲۴ کاراکتر (~۲,۰۰۰ توکن) برای ⁦OpenCode.⁩

تعریف ابزارها: ⁦Claude Code⁩ با ۲۷ ابزار میاد که فقط ⁦schema⁩ ابزارها ~۲۴,۰۰۰ توکن می‌خورن. ⁦OpenCode⁩ ده ابزار داره، ~۴,۸۰۰ توکن.

بقیه‌اش هم ⁦scaffolding⁩‌هایی هست که ⁦Claude Code⁩ قبل از پرامپت کاربر ⁦inject⁩ می‌کنه — بلوک‌های یادآوری، کاتالوگ ایجنت‌ها، و ⁦context framing⁩ — که ⁦OpenCode⁩ اینا رو نداره.

تو محیط واقعی اوضاع بدتره: یه فایل دستورالعمل پروژه‌ی ۷۲ کیلوبایتی (مثل ⁦CLAUDE.md⁩) به هر دو ابزار ~۲۰,۰۰۰ توکن اضافه می‌کنه. هر ⁦MCP server⁩ که وصل کنی، بین ۴,۹۰۰ تا ۶,۹۶۷ توکن اضافه‌بار داره — فقط برای معرفی ابزارهاش. با پنج تا ⁦MCP server⁩ و یه فایل پروژه، قبل از نوشتن اولین کلمه، بین ۷۵,۰۰۰ تا ۸۵,۰۰۰ توکن مصرف شده — بیش از ۴۰٪ از یه ⁦context window⁩ دویست‌هزار توکنی.

یه تفاوت مهم دیگه هم هست: ⁦caching. OpenCode⁩ یه ⁦prefix⁩ ثابت بایت‌به‌بایت نگه می‌داره، پس ⁦caching⁩ درست کار می‌کنه. ⁦Claude Code⁩ وسط سشن ⁦scaffolding⁩ خودش رو بازنویسی می‌کنه و ⁦cache⁩ رو مجبور می‌کنه ⁦rebuild⁩ بشه — حجم ⁦cache-write⁩ برای ⁦Claude Code⁩ بین ۵.۹ تا ۵۴ برابر ⁦OpenCode⁩ بود. نوشتن روی ⁦cache⁩ هم ارزون نیست: ۱.۲۵ برابر نرخ معمولی ⁦Input.⁩

مشکل ⁦subagent⁩‌ها هم از این بدتره: یه تسک که مستقیم ۱۲۱,۰۰۰ توکن مصرف کرد، وقتی به دو ⁦subagent⁩ تقسیم شد ۵۱۳,۰۰۰ توکن خورد. هر ایجنت جدید کل ⁦overhead⁩ رو از صفر پرداخت می‌کنه.

برای کاهش این هزینه‌ها: حجم ⁦CLAUDE.md⁩ رو کنترل کن، ⁦MCP server⁩هایی که استفاده نمی‌کنی رو غیرفعال کن، و ⁦fan-out⁩ به ⁦subagent⁩ رو برای تسک‌هایی بذار که اندازه‌شون واقعاً این هزینه رو توجیه می‌کنه.

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

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

اندازه‌ی این پنجره با ⁦Token⁩ سنجیده می‌شه. مدل‌هایی که پنجره‌ی بزرگ‌تری دارن، متن یا مکالمه‌ی طولانی‌تری رو می‌تونن یه‌جا پردازش کنن.

یه مثال: داری با ⁦Claude⁩ یه پروژه‌ی کدنویسی می‌کنی. اول کار معماری کل سیستم رو توضیح دادی. بعد از ۵۰ پیام رفت‌وبرگشت، وقتی پنجره پر می‌شه، مدل دیگه اون توضیحات اولیه رو «نمی‌بینه». بیرونِ پنجره‌ست.

چند چیز مهم:

یه: این پنجره همه چیز رو می‌بلعه — ⁦Prompt⁩ سیستمی، تاریخچه‌ی مکالمه، فایل‌هایی که آپلود کردی، و جواب‌های خودِ مدل. همه از همون سهمیه‌ی مشترک می‌خورن.

دو: بزرگ‌تر همیشه بهتر نیست. پنجره‌ی بزرگ‌تر یعنی هزینه‌ی پردازش بیشتر.

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

خیلی از ابزارها مثل ⁦RAG⁩ دقیقاً به همین دلیل ساخته شدن؛ که این محدودیت رو دور بزنن. 🔥

هر بار می‌خوای یه مفهومِ جدید یاد بگیری، یه جواب از ⁦AI⁩ می‌گیری و می‌ری. یه هفته بعد همون سوال رو دوباره می‌پرسی — چون چیزی یاد نگرفتی، فقط جواب گرفتی.

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

مثلاً می‌خوای ⁦Transformer⁩ رو یاد بگیری. به‌جای «⁦Transformer⁩ چیه؟» اینو بنویس:

«می‌خوام ⁦Transformer⁩ رو یاد بگیرم. اول یه توضیحِ خیلی ساده بده انگار ۱۵ سالمه. بعد مهم‌ترین مفاهیمش رو فهرست کن. آخرش سه تا سوال ازم بپرس که بفهمی درست فهمیدم یا نه.»

همین یه تغییر کل تجربه رو عوض می‌کنه. 🎯

بعد از اینکه جواب دادی، یه مرحله اضافه کن:

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

اینجوری ⁦AI⁩ دقیقاً روی جاهایی که هنوز گیر داری تمرکز می‌کنه، نه یه توضیحِ کلی که از صفر شروع می‌کنه.

یه قدمِ آخر که خیلی کارساز:

«یه مثالِ روزمره بزن که این مفهوم رو توضیح بده — از دنیای تکنولوژی نباشه.»

آنالوژی‌های غیرتکنیکال معمولاً همون چیزیه که یادت می‌مونه. تعریفِ دقیق یادت می‌ره، مثالِ ملموس نه. ⚡

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

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

مدل رو مجبور می‌کنه شش دسته‌ی مشخص رو یکی‌یکی بگرده: آمار، تاریخ‌ها، نقل‌قول‌ها، استنادات، اسامی، و گزاره‌های مطلق (مثل «اولین»، «بزرگ‌ترین»، «تنها»). به‌جای یه حکم کلی «به نظر درسته»، یه طبقه‌بندی چهارتایی می‌ده: تأیید شده / قابل تأیید نیست / الگوی توهم / ساختگی.

یه نکته‌ی مهم: بدون دسترسی به وب، مدل داره حدس می‌زنه نه تأیید می‌کنه. خروجیش یه نقشه‌ی ریسکه که بهت می‌گه کجا وقت بذاری، نه اینکه جای بررسی خودت رو بگیره.

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

Act as a rigorous fact-checking editor reviewing AI-generated or human-written text before it goes out the door.

CONTEXT:
[PASTE THE FULL TEXT TO BE FACT-CHECKED HERE]
Domain/topic area: [E.G., FINANCE, HEALTHCARE, LEGAL, GENERAL BUSINESS, TECHNICAL DOCUMENTATION]
Where this is going: [E.G., CLIENT-FACING REPORT, PUBLISHED ARTICLE, INTERNAL MEMO, LEGAL FILING]
Acceptable risk level: [E.G., ZERO TOLERANCE FOR ERROR — LEGAL/MEDICAL, LOW TOLERANCE — CLIENT-FACING, MODERATE — INTERNAL DRAFT]

TASK:
Go through the text claim by claim and identify every statement that could be factually wrong, specifically:
1. Statistics, percentages, or numerical claims
2. Dates, timelines, or sequences of events
3. Direct quotes or attributions to specific people or organizations
4. Named sources, studies, or citations
5. Claims about a specific product, company, or technical specification
6. Absolute or superlative claims ("first," "only," "largest," "never")

For each flagged claim, assess whether it is: (a) verifiable and correct based on what you know, (b) verifiable but you cannot confirm accuracy with confidence, (c) a claim pattern strongly associated with AI hallucination (oddly specific numbers, plausible-sounding but unverifiable citations, quotes that don't sound like they'd actually be said), or (d) clearly fabricated or internally inconsistent with other parts of the text.

CONSTRAINTS:
- Do not simply say a claim "sounds plausible" — plausibility is not the same as accuracy, and hallucinated claims are specifically designed to sound plausible
- Pay special attention to specific numbers and dates that are not rounded — oddly precise figures ("73.4% of users") without an obvious source are a common hallucination signature
- If a quote is attributed to a real, identifiable person or organization, flag it as high-risk unless you have strong reason to believe it's accurate — fabricated quotes are one of the most damaging and common hallucination types
- Do not rewrite the entire text — only propose specific edits to the flagged claims
- If you cannot verify a claim with confidence, say so explicitly rather than guessing

OUTPUT FORMAT:
1. Risk Summary — one line stating how many claims were flagged and the highest-risk category found
2. Claim-by-Claim Table — each flagged claim, its risk classification (a/b/c/d from above), and a one-line explanation
3. High-Priority Fixes — the 3-5 claims that pose the most risk if wrong, with a suggested safer rewording or a note to verify against a specific source type
4. Safe-to-Publish Verdict — a direct yes/no/not-yet judgment on whether the text is ready to send, and what would need to change to get to yes

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

اگه برنامه‌نویس هستی و از ⁦CLI⁩ ابزارهای ⁦AI⁩ استفاده می‌کنی، این خبر مستقیماً به دردت می‌خوره.

یه محقق امنیتی مستقل ترافیک شبکه ⁦Grok Build⁩ رو با ⁦proxy⁩ زیر ذره‌بین گذاشت — ⁦Grok Build⁩ همون ⁦CLI⁩ کدنویسی ⁦xAI⁩ هستش، شرکت ⁦Elon Musk.⁩ نتیجه‌اش نگران‌کننده بود:

این ابزار در پس‌زمینه یه ⁦git bundle⁩ کامل از کل فضای کاری توسعه‌دهنده رو آپلود می‌کنه — نه فقط فایل‌هایی که ⁦AI⁩ باهاشون کار کرده، بلکه تمام محتوای پروژه. این داده‌ها به یه ⁦bucket⁩ ذخیره‌سازی ابری گوگل می‌رن با اسم ⁦grok-code-session-traces.⁩

توی تست روی یه مخزن حدود ۱۲ گیگابایتی، ابزار ۵.۱۰ گیگابایت داده رو توی ۷۳ تکه آپلود کرد و همه ۸۳ درخواست با موفقیت پاسخ گرفتن. محقق نشون داد حتی یه فایلی که ⁦AI⁩ هرگز بهش دسترسی نداشت هم سالم توی این ⁦bundle⁩ بود. فایل .⁦env⁩ شامل ⁦credentials⁩ کاربر هم بدون هیچ سانسوری آپلود شده بود.

داخل ⁦Grok Build⁩ یه گزینه هست به اسم «⁦Improve the model⁩» که می‌شه غیرفعالش کرد — ولی این فقط کنترل می‌کنه که آیا داده‌ها برای ⁦training⁩ مدل استفاده بشن. خودِ آپلود رو متوقف نمی‌کنه. این تفاوت مهم هیچ‌جا توی مستندات رسمی توضیح داده نشده.

محققان امنیتی توصیه می‌کنن هر توسعه‌دهنده‌ای که ⁦Grok Build⁩ رو داخل یه مخزن شامل ⁦credentials⁩ اجرا کرده، فوری اون ⁦credentials⁩ رو تغییر بده و فرض کنه که احتمالاً لو رفتن. شرکت ⁦xAI⁩ تا لحظه انتشار این گزارش هیچ بیانیه‌ای منتشر نکرده.

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

دلیلش اینه که هر رباتی که حرکت می‌کنه، از ساده‌ترین موتورش تا پیچیده‌ترینش، به بلبرینگ نیاز داره. یه ربات انسان‌نما ۷۰ تا بلبرینگ می‌خواد، یه پهپاد کوچیک ۸ تا ۱۲ تا. حتی ⁦OpenAI⁩ تو لیست قطعات حیاتی رباتیک که خودش منتشر کرده، دقیقاً بلبرینگ رو اسم برده.

مورگان استنلی پیش‌بینی کرده بازار بلبرینگ رباتیک تا سال ۲۰۵۰ حدود ۳۰۰ برابر رشد کنه.

منطقش ساده‌ست: مهم نیست کدوم طراحی ربات در آینده برنده بشه، همه‌شون مجبورن بلبرینگ بخرن. دقیقاً همون منطق بیل‌فروشی تو دوران طلاست — هر کی دنبال طلاست، بیل لازم داره. ⚡