Pedi | پِدی

فایل‌های متنی Markdown مثل AGENTS.md و CLAUDE.md به روش جدیدی برای فریب ایجنت‌های هوش مصنوعی تبدیل شدن. طبق گزارش شرکت امنیتی Forever Security، هکرها می‌تونن دستورهای مخرب رو داخل این فایل‌ها پنهان کنن و ابزارهایی مثل Codex و Claude Code رو به نصب بدافزار یا افشای اطلاعات کاربر وادار کنن. برای جلوگیری از این حملات، بهتره فایل‌های دستورالعمل ناشناس رو بررسی کنین، ایجنت‌ها رو از داخل پوشه دانلودها یا پروژه‌های مشکوک اجرا نکنین و تأیید امنیتی اجرای دستورات رو غیرفعال نکنین. 🔗 ᴡᴇʙꜱɪᴛᴇ • ᴠᴘɴʜᴜʙ • ɢɪᴛʜᴜʙᴍɪʀʀᴏʀ @ircfspace

توضیح رفتار سیستم با sequence diagram به نظر من، sequence diagram بهترین راه برای توضیح رفتار یه سیستمه، مخصوصاً وقتی می‌خوای ترتیب اتفاق‌ها رو روشن کنی. کی به کی request می‌فرسته و چه responseی برمی‌گرده؟ می‌تونی شرط‌ها، loopها و noteهای لازم رو هم نشون بدی، نه فقط مسیر «همه‌چی خوب پیش رفت». مثلاً توی شکل، اپ وضعیت سفارش رو می‌پرسه. تا آماده‌شدن سفارش، با فاصله ۵ ثانیه دوباره چکش می‌کنه، در مجموع حداکثر ۳ بار. برای ساختنش لازم نیست فلش‌ها رو دستی بکشی. توی Mermaid Chart که حالا با اسم Mermaid AI باز می‌شه، با چند خط کد Mermaid نمودار می‌سازی. آدرس: https://mermaid.ai یه گزینه دیگه هم PlantUMLه که با متن و کد نمودار می‌سازه. آدرس: https://plantuml.com به نظرم نمودار یا کدش می‌تونه ورودی خوبی برای prompt به AI باشه: کنار توضیحت نشون می‌دی دقیقاً چه رفتاری از سیستم می‌خوای. ازش بخواه قبل از کدنویسی، برداشتش و جاهای مبهم رو بگه. احتمالاً این‌طوری راحت‌تر می‌فهمی منظورت رو گرفته یا نه.

قسمت ۸ از ۸ | اگه نیاز عوض بشه چی؟ یه برنامه یادداشت فقط روی گوشی کار می‌کنه. ذخیره روی همون گوشی می‌تونه کافی باشه. حالا می‌خوای یادداشت‌ها رو روی لپ‌تاپ هم ببینی. درباره محل ذخیره، sync و دسترسی باید دوباره فکر کنی. من این روزها توی مصاحبه‌هام دیگه سؤال کدنویسی نمی‌پرسم. با سؤال‌های سیستمی و طراحی بررسی می‌کنم طرف مقابل واقعا حرفش رو می‌فهمه یا نه: چرا این راه؟ گزینه دیگه چی بود؟ اگه نیاز عوض بشه یا یه بخش خراب بشه چی؟ این روش مصاحبه منه، نه همه شرکت‌ها. توی یادگیری هم از AI برای توضیح و نقد کمک بگیر، ولی خودت دلیل انتخابت و اثرش روی بقیه سیستم رو بفهم و بررسی کن.

قسمت ۷ از ۸ | حدس بزن، ولی تستش کن فرض کن برنامه کند شده و فکر می‌کنی مشکل از database باشه. قبل از عوض‌کردنش، زمان هر بخش رو اندازه بگیر. شاید برنامه منتظر یه سرویس دیگه مونده. وقتی علت رو پیدا کردی، همون بخش رو درست کن و دوباره تست بگیر. هم سرعت مهمه، هم اینکه نتیجه درست باشه. ورودی اشتباه، دسترسی بدون اجازه و قطع ارتباط رو هم توی محیط تست امتحان کن. قرار نیست همه این درس‌ها رو تمام کنی و بعد پروژه بسازی. از اول یه چیز کوچیک بساز و هر جا به سؤال تازه رسیدی، برگرد و مبانی رو بهتر یاد بگیر.

قسمت ۶ از ۸ | اگه کارها بیشتر بشن چی؟ موقع ساختن به scale هم فکر کن. اگه کاربر و داده بیشتر بشه، کدوم بخش زودتر کم می‌آره؟ اون بخش می‌تونه bottleneck باشه. توی مثال ساده شکل، هر ثانیه ۱۰ کار وارد می‌شه ولی فقط ۶ کار انجام می‌شه. اگه همین وضعیت ادامه پیدا کنه و کاری حذف نشه، هر ثانیه ۴ کار به صف اضافه می‌شه. اضافه‌کردن queue به‌تنهایی مشکل سرعت رو حل نمی‌کنه. انتخاب‌هات رو بررسی کن: query و indexهای database مناسبن؟ اطلاعات cache تا کی معتبره؟ اگه سرویس بیرونی کند بشه چی؟ فایل بزرگ رو یک‌جا توی حافظه می‌ریزی؟ اول راه سخته. ساده شروع کن، ولی دلیل انتخابت رو بدون و با تست بررسی کن حدست درباره bottleneck درست بوده یا نه.

قسمت ۵ از ۸ | اول نیاز، بعد ابزار قبل از اضافه‌کردن cache بپرس: اینجا اطلاعات چقدر باید به‌روز باشه؟ مثلا شاید برای توضیح یک محصول، کمی تأخیر مشکلی نداشته باشه. ولی موقع خرید، باید موجودی رو درست بررسی و کم کنی، حتی وقتی چند نفر با هم خرید می‌کنن. فقط به اطلاعات قدیمی cache تکیه نکن. این سؤال کمک می‌کنه تصمیم بگیری، ولی به‌تنهایی دلیل اضافه‌کردن cache نیست. هزینه و پیچیدگی‌ش رو هم بسنج. به نظرم مهم‌تر از بلدبودن رسم دیاگرام اینه که بدونی چی رو کجا و چرا استفاده می‌کنی و انتخابت چه اثری روی کل سیستم می‌ذاره.

قسمت ۴ از ۸ | ذخیره شد یا نشد؟ وقتی روی ذخیره می‌زنی، درخواست می‌ره به API و بعد داده توی database ذخیره می‌شه. ورودی و اجازه دسترسی هم باید بررسی بشن. حالا فرض کن ذخیره انجام شده، ولی جوابش به گوشی تو نرسیده. نمی‌تونی فقط از روی جواب‌نگرفتن بگی ذخیره نشده. مسیر داده رو دنبال کن. اگه دوباره دکمه رو بزنی، چطور جلوی ثبت دوباره رو می‌گیری؟ اگه چند تغییر باید با هم انجام بشن، transaction چه کمکی می‌کنه؟ شبکه و database رو با همین سؤال‌ها یاد بگیر و قطع ارتباط رو توی محیط تست امتحان کن.

قسمت ۳ از ۸ | کدت روی ماشین چه کار می‌کنه؟ کم‌کم با CPU، حافظه، فایل و سیستم‌عامل آشنا شو. وقتی برنامه کند می‌شه، ببین داره کار می‌کنه یا منتظر شبکه و دیسک مونده. موضوع concurrency رو هم یاد بگیر. توی مثال شکل، دو درخواست عدد صفر رو می‌خونن. هر کدوم یکی بهش اضافه می‌کنه و عدد یک رو ذخیره می‌کنه. آخر کار عدد یکه، نه دو. این یکی از حالت‌هاییه که ممکنه پیش بیاد. برای همین، درست‌بودن هر درخواست به‌تنهایی کافی نیست. باید بفهمی وقتی چند کار به یک داده دست می‌زنن، چطور جلوی خراب‌شدن نتیجه رو بگیری.

قسمت ۲ از ۸ | چرا این راه رو انتخاب کردی؟ توی برنامه هزینه‌ها می‌خوای یه مورد رو با ID پیدا کنی. می‌تونی لیست رو یکی‌یکی بگردی، یا از dictionary استفاده کنی و با ID سراغش بری. برای انتخاب، فقط نپرس کدوم سریع‌تره. چقدر داده داری؟ چند بار دنبالش می‌گردی؟ آماده‌کردن و نگه‌داشتن dictionary چقدر وقت و حافظه می‌خواد؟ الگوریتم و ساختمان داده رو با همین سؤال‌ها یاد بگیر. بعد هر دو راه رو امتحان کن و با داده بیشتر مقایسه‌شون کن. شکل فقط روش‌ها رو نشون می‌ده، نه نتیجه تست سرعت.

قسمت ۱ از ۸ | اول زبان رو یاد بگیر به نظر من، با وجود AI هنوز باید بتونی کد رو بخونی، بنویسی و بفهمی. سینتکس، الگوریتم و شناخت ماشین رو کنار نذار. با متغیر، شرط، حلقه و تابع شروع کن و همون موقع یه پروژه کوچیک بساز. مثلا برنامه ثبت هزینه. فرض کن فقط مبلغ مثبت قبول می‌کنی. برای صفر و عدد منفی چه اتفاقی باید بیفته؟ همین تصمیم ساده رو خودت بنویس و امتحان کن. از AI کمک بگیر، ولی قبل از قبول‌کردن کدش، مطمئن شو می‌فهمی چه کاری می‌کنه. این مسیر پیشنهادی منه، نه تنها راه یادگیری.

شبکه بسته بود، اما پیام رد شد در یک آزمایش هدایت‌شده OpenAI، دو عامل در ماشین‌های مجازی جدا اما روی سخت‌افزار میزبان مشترک، با تغییر وضعیت حافظه سریع پردازنده (cache) و اندازه‌گیری زمان خواندن داده، اطلاعات محرمانه ساختگی ردوبدل کردند. نه اتصال شبکه لازم شد، نه فایل مشترکِ قابل‌نوشتن. بیشتر این آزمایش‌ها با راهنمایی درباره مسیر ارتباط یا شیوه رمزگذاری انجام شدند. پس این را «کشف کاملا خودجوش» نخوانیم. شرکت بررسی‌هایی برای تشخیص تلاش‌های مشابه به نظارتش اضافه کرده است. اضافه‌شدن این بررسی‌ها به معنی بسته‌شدن همه این مسیرهای ارتباطی نیست. منبع: بخش ارتباط بین محیط‌های جدا

گفتند: این بار خودتان راه خروج را پیدا کنید تیم‌هایی از عامل‌های هوش مصنوعی، با دسترسی به کد و تنظیمات، دفاع‌ها را روی نسخه‌های آزمایشی و جداشده از زیرساخت OpenAI امتحان کردند. نمودار، مجموع یافته‌های احتمالی با اولویت بالا را پس از حذف موارد تکراری نشان می‌دهد: در حدود ۳۸۰ میلیارد توکن، به ۲۷۶ مورد می‌رسد. این عدد، تعداد آسیب‌پذیری‌های تاییدشده نیست. مدل‌ها و بخش‌های آزمایش‌شده عوض شده‌اند. پس کم‌شدن شیب، مدرک قطعی امن‌شدن سیستم نیست. شرکت می‌گوید یافته‌ها به اصلاح نرم‌افزار، محدودیت شبکه و نظارت بهتر منجر شدند. بعد از اصلاحات، آموزش با یادگیری تقویتی (RL) و اجرای داخلی مدل‌های پیشرفته از ۱ اکتبر ۲۰۲۶ از سر گرفته شد. منبع: گزارش و داده نمودار

چطور وب‌گردی را بدون اینترنت تمرین می‌دهند؟ طبق گزارش OpenAI، همه اجراهای یادگیری تقویتی (RL) مدل‌های پیشرفته‌اش از جست‌وجو و نسخه‌های ذخیره‌شده وب استفاده می‌کنند، نه وب زنده. اگر صفحه‌ای در کش نباشد، آن را از اینترنت زنده دریافت نمی‌کنند. عامل‌هایی هم که اجازه همکاری دارند، مسیر ارتباطی مشخص دارند. این «جهان آفلاین» به معنی قطع فیزیکی کل زیرساخت از شبکه نیست. اتصال‌های لازم برای اداره آزمایش‌ها باقی مانده‌اند و باید جداگانه محدود شوند. منبع: گزارش امنیت محیط آموزش

وقتی هشدار آمد، چرا اجرا متوقف نشد؟ در ۲۰ سپتامبر ۲۰۲۶، یک مدل پژوهشی OpenAI دنبال نویسنده یک مطلب می‌گشت. جست‌وجوها جواب نداد. مدل از شکاف تنظیمات DNS، سرویس پیدا کردن آدرس دامنه‌ها، به یک چت‌بات بیرونی وصل شد. این کار جزو ماموریتش نبود. سیستم نظارت در کمتر از ۱۵ دقیقه هشدار داد و یک نفر سه دقیقه بعد بررسی را شروع کرد. اما توقف خودکار عمل نکرد. اجرا حدود دو ساعت‌ونیم بعد از تایید دریافت هشدار، دستی متوقف شد. طبق گزارش شرکت، محدودیت‌های DNS در دو لایه مستقل اضافه شد. آموزش همان مدل ادامه پیدا نمی‌کند. اما آموزش تقویتی مدل‌های پیشرفته و اجرای داخلی آن‌ها از ۱ اکتبر ۲۰۲۶ از سر گرفته شد. نکته برای ما: تست هشدار کافی نیست. تست کنید بعد از هشدار، سیستم واقعا چه کاری انجام می‌دهد. منابع: گزارش رخداد · گزارش بازگشت به آموزش

آرشیو کانال فقط برای اسکرول نیست از کل پست‌های کانال @whitedns یک حافظه در Hindsight ساختم. تصویر، گراف همین حافظه‌ست. ایده این اتصال ساده‌ست: محتوای کانال تلگرام از طریق Hermes وارد حافظه می‌شه. بعد، Hermes می‌تونه اطلاعات مرتبط رو از Hindsight پیدا کنه و موقع انجام کار ازشون کمک بگیره. حالا این حافظه کمکم می‌کنه: • برای پست‌ها تگ مرتبط پیدا کنم. • موقع پشتیبانی، جواب رو با آموزش‌های قبلی کانال کامل کنم. • از این به بعد، پایین هر پست لینک آموزش‌ها و مطالب مرتبط رو اضافه کنم. مثلاً به‌جای اینکه برای هر سؤال دوباره توی آرشیو بگردم، از Hermes می‌خوام آموزش مرتبط رو پیدا کنه و لینک پست اصلی رو پیشنهاد بده. البته مرتبط‌بودن مطلب و درستی لینک باید بررسی بشه. این یک کاربرد عملی از اتصال تلگرام، Hermes و Hindsight است: استفاده دوباره از دانشی که قبلاً منتشر کردیم. برای شروع: اتصال Hermes به Hindsight | شیوه بازیابی حافظه

اگه تازه‌کاری، «چرا» رو کنار «چطور» یاد بگیر من توی مصاحبه‌ها کمتر سؤال کدنویسی می‌پرسم. بیشتر می‌خوام بدونم چرا این طراحی رو انتخاب کردی و کجا ممکنه جواب نده. منظورم حذف کدنویسی نیست. مبانی یک زبان، ساختار داده، الگوریتم، تست و اشکال‌زدایی (debugging) رو کنار طراحی یاد بگیر. [۱] مثلاً برای اپ یادداشت، ذخیره روی یک دستگاه با دسترسی از گوشی و لپ‌تاپ دو نیاز متفاوتن. قبل از انتخاب ابزار بپرس: داده کجاست، چه کسی می‌بینه و اگر ذخیره نشد چه می‌شه؟ تمرین پیشنهادی من: یک قابلیت کوچک بساز. یک راه جایگزین و دلیل انتخابت رو بنویس، تستش کن، بعد بدون دستیار هوش مصنوعی (AI) یک نیاز کوچک رو تغییر بده و کد رو اصلاح کن. توضیح دادن کد در یک مطالعه، فهم فوری رو بهتر کرد. [۲] درباره AI، یک آزمایش روی توسعه‌دهندگان افت نمره آزمون فوری رو دید. [۳] مطالعه دیگه روی نوجوانان تفاوت معناداری در آزمون‌های بدون AI پیدا نکرد. [۴] پس آماده شدن پروژه رو با یادگیری یکی نگیریم. این مسیر پیشنهاد منه، نه اثبات برتری مصاحبه طراحی.

با شرایط اینترنت یکم تمرکز رو ازینجا باید کم کنم و برگردیم بیشتر روی WhiteDNS کار بکنیم. بچه های تیم کارای خیلی خوبی انجام دادن. پیشنهاد میکنم پروژه های CottenDNS & Soar-server رو ببینید و استفاده کنید.