در مورد system prompt

یه مدل llm که باهاش چت می‌کنیم دو تا پرامپت داره. یکی همون که کاربر می‌نویسه که باهاش آشنا هستیم ولی چیزی که اغلب نمی‌بینیم system promptئه که قبل از پرامپت شما میاد و چیزای کلی بهش گفته می‌شه. شامل تاریخ و ساعت، اسم مدلش احتمالا و یه سری باید و نباید. حتما دیدین که یه سری سوال ها رو LLMها جواب نمی‌دن قاعدتا به خاطر همین system promptشونه.

حالا چرا ما باید برامون مهم باشه؟ ممکنه بخواید یه مدل خام رو اجرا کنید (مثلا با API بهش وصل بشید و چت کنید) یا اصلا خودتون مدل رو لوکال آوردید بالا. بدون system prompt خوب ممکنه نتیجه چت ایده‌آل نباشه در حالی که مدل لزوما مدل بدی نیست. من یه مساله ساده که داشتم این بود که با chatbox به api openrouter وصل شدم ولی خروجی ها کمی به هم ریخته می‌شد. اومدم با یه system prompt ساده مشکل رو حل کردم.
یا ممکنه بخواید یه agent برای یه موضوع و کاربرد خاص بسازید، اون طوری پرامپتی که میدین بهش قبل از پرامپت کاربر میاد و به نوعی system prompt حساب می‌شه.

چطور system prompt خوب ینویسیم؟
https://towardsdev.com/the-art-of-writing-great-system-prompts-abb22f8b8f37

تحلیل system prompt مدل gpt5
https://medium.com/data-science-in-your-pocket/gpt-5-system-prompt-leaked-7-prompt-engineering-tricks-to-learn-85532a647cdf


سیستم پرامپت‌های لیک شده مدل‌های مختلف
https://github.com/jujumilk3/leaked-system-prompts

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

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


راهنمایی و فکرهای خودم:
این مدل لود قاعدتا حالت bursty داره و تعداد کاربر خیلی زیاد رو شامل میشه. تو این مسأله هم فرض کنیم هدف اینه که واقعا به مشتری سرویس بدیم نه این که throttle کنیم و لود رو کم کنیم.

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

چیزایی که به ذهنم میرسه:
+ لود تست
+ پیدا کردن و حل گلوگاه ها و تغییر معماری در صورت نیاز
+ آماده باش نیروها
+ افزایش منابع
+ داشتن جایگزین برای زیرساخت های مهم مثل برق و اینترنت

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

https://www.sobyte.net/post/2022-03/go-escape/

این هم مطلب خوبیه:
https://golang.howtos.io/go-s-escape-analysis-a-practical-guide/
و این ویدیو:
https://youtu.be/ZMZpH4yT7M0

تولید کد با AI: آیا واقعا بهبود قابل توجهی حاصل شده؟
مطلب طولانی‌‌ایه و سعی میکنم خلاصه‌ش رو براتون بنویسم:
سرعت تولید کد بالا رفته. درستی کد اومده پایین. اکثر برنامه‌نویس‌ها ازش استفاده میکنن ولی اعتماد کمتری بهش دارن از سال های پیش. سرعتی که حاصل شده چند برابر نیست و نهایتا در حد ۲۰-۳۰ درصده، حتی در کدهای پیچیده کاهش سرعت ۲۰ درصدی هم داشتیم چون کدی که به نظر درست میاد خیلی زمان می‌بره تا تبدیل به کدی بشه که واقعا درسته. مثلا زمان کد ریویو تا ۹۱ درصد افزایش داشته. همه‌جا هه طبیعتا کارکردش شبیه هم نیست مثلاً توی کدهای ساده و آموزشی عالیه ولی توی کدهای پیچیده خوب نیست.
برای این که سازمان بتونه از AI واقعا درست و خوب استفاده کنه نیاز داره فلوهاشو رو تغییر بده و تغییر یکهو و یک شبه نیست.


https://addyo.substack.com/p/the-reality-of-ai-assisted-software

اگه چند وقت هست با گولنگ کار می‌کنید شاید بد نباشه که یه مروری روی ریزه کاری‌هاش داشته باشید.
من این کتاب ۱۰۰ اشتباه در گولنگ رو خیلی وقت پیش دیده بودم و امروز یه نگاهی انداختم بهش و به نظر برای این منظور کاربردی میاد.
https://100go.co/

برای این که بیش‌تر تشویقتون کنم یک نمونه هم می‌گذارم:

فرض کنید ۱ ملیون ایتم به مپ اضافه میکنیم در این مرحله برنامه ۱۰۰ مگابایت مموری مصرف می‌کنه. حالا هر ۱ ملیون تا رو حذف می‌کنیم و گاربیج کالکتور رو هم صدا می‌کنیم. در این مرحله برنامه چقدر مموری مصرف میکنه؟ نزدیک به صفر؟ پاسخ اینه که نه. چون تعداد bucket های مپ فقط زیاد میشن و کم نمیشن در نتیجه خود مپ همچنان مموری نسبتا زیادی مصرف می‌کنه.
https://100go.co/28-maps-memory-leaks/

آسیب پذیری جدید روی react باعث دسترسی remote code execution میشه! اسمش react2shellئه و میتونید اینجا ازش بخونید.

https://www.rapid7.com/blog/post/etr-react2shell-cve-2025-55182-critical-unauthenticated-rce-affecting-react-server-components/

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

در مورد estimate دادن روی تسک و ارتباط تک و پروداکت ویدیوی بامزه‌ای بود.
https://www.youtube.com/watch?v=yNtJP6EHBik

در مورد حافظه محدود LLM ها و contest window و چرایی نیاز به RAG این مطلب خیلی خوبی بود.

به طور خلاصه، LLM هیچ چیزی از ما یادش نگه نمی‌داره که به نحوه پیاده‌سازیش برمی‌گرده. حالا برای این که یه توهمی از حافظه و ادامه پیدا کردن چت به ما بده، به ازای هر پیامی که بهش می‌دیم، همه‌ی تاریخچه رو دوباره میخونه. برای همین چت که طولانی میشه هم دیرتر جواب میده هم دقتش کم میشه.
برای حلش تا یه جایی می‌شه context رو بزرگ تر کرد ولی یادمون نره که از order N^2 زمان و توان پردازشی مصرف می‌کنه. راه دیگه آوردن چیزهای مرتبط به کانتکسته که همون RAG می‌شه.


https://blog.bytebytego.com/p/the-memory-problem-why-llms-sometimes

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

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

لطفا هرچنلی که معرفی میکنید در یک پیام باشه ولی هر تعداد پیام خواستید بدید. ✌️

اگه دوست دارید با agentic ai توی ترمینال کار کنید، ابزارهای مختلفی هستن. من با چند تاشون کار کردم و نظرم رو می‌نویسم:

بین اونایی که شرکت‌های بزرگ ارائه کردن، من با Gemini و Claude Code کار کردم. Gemini اصلا خوب نیست و با این که اشتراک Ai Proش رو گرفتم نه جواب‌های خوبی می‌ده نه سرعت خوبی داره نه دقت خوبی داره. البته من با Gemini-2.5-pro تست کردم ولی جدا از دقت مدل، تجربه کاربری خیلی بدی هم داشت.
اما Claude Code بهترین تجربه‌ای بود که داشتم و هم سرعت نسبتا خوب هم دقت خیلی خوبی داشت و هم خودش todo درست می‌کرد از کارهایی که باید انجام می‌داد و تجربه کاربری خیلی خوبی هم داشت.

بین اونایی که provider قابل تنظیم داشتن، من چون اکانت openrouter داشتم محدودیتم این بود که حتما با api key اون کار کنه. با aider و opencode و vibe و goose کار کردم.

از همه بهتر opencode بود. رابط کاربری تمیزی داره، تجربه کاربری خوبی هم داره هرچند عالی نیست. مثلا این که full-screen بود یه مقدار منو اذیت می‌کرد ولی خب سلیقه‌ایه. نکته‌ی جالبش اینه که خودشون هم مدل ارائه می‌دن که هم کیفیت خوبی داره (مثلا grok 4.1 fast) و هم فعلا بدون لاگین و رایگان در دسترسه. البته قاعدتا نمی‌شه بلند‌مدت به این ویژگی اعتماد کرد ولی برای تست خوبه.
اینجا خوبه به crush هم اشاره کنم. نسخه‌ایه که تیم charm خریده/گرفته و توسعه رو ادامه می‌ده. من یکسری فیچر بیش‌تر دیدم ولی تفاوت خاصی قابل ملاحظه نبود هنوز.

بعد از اون vibe بود که به تازگی معرفی شده توسط mistral. برای من به عنوان ابزاری که تازه معرفی شده دوست داشتنی بود. نکته بارزش اینه که اگرچه امکان اتصال به openrouter (در واقع بک‌اند های openai) رو داره ولی تنظیم کردنش از عمد سخته. وقتی بازش می‌کنید ازتون api key خود mitral رو می‌خواد که با شماره ایران و بدون هزینه هم ساختش امکان‌پذیر نیست. بعد از چند تا ادیت کانفیگ بالاخره موفق شدم از این مرحله رد بشم. همچنان کانفیگش یه مقدار اذیت کننده‌ست و باید لیست مدل‌ها رو خودتون به همراه قیمت هر توکن وارد کنید و بعدا هم آپدیت کنید. بعد از انجام این کارها، من تجربه نسبتا خوبی باهاش داشتم.

در مرحله بعدی goose بود که ابزار پرامکاناتیه، رابط کاربری قشنگی هم داره ولی خیلی سخته. من موفق نشدم خیلی باهاش دوست بشم. امکانات automation هم به نظر داره ولی من تست نکردم. خوندم که اخیرا به linux foundation اهدا شده و به نظر آینده‌دار میاد.

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

سلام به شما دوستان قوی و عزیز 🙂
امیدوارم حالتون خوب باشه

توی این پست ارجاع دادم به آخرین کیس‌استادی‌ای که برای یک چالش دیزاین تقریبا ۵ روزه نوشتم.

خوشحال می‌شم که بخونیدش:
لینک پست

ایده هایی برای استفاده از Claude code
و با استفاده فقط منظورم برنامه نویسی نیست، بلکه سریع و خودکار کردن کارهای روزمره. توصیه میکنم یه نگاهی به مثال هاش بندازید‌.

https://www.lennysnewsletter.com/p/everyone-should-be-using-claude-code

چطوری code review رو سرعت ببخشیم:

https://leaddev.com/culture/4-steps-speed-up-code-reviews

کد ریویو اجباری خوبه یا بد؟ خلاصه اینکه توسعه رو کند می‌کنه ولی باگ ها رو هم کم میکنه!

نکته ها:
+ یا کد ریویو نکنید یا اگه میکنید سریع و دقیق باشه. :))
+ میشه به جای اجبار همیشگی، هوشمندانه استفاده کرد، مثلا اگه کد حیاتی نوشته شده، یا ریویوی کد کسی که به کد مسلط نیست.

https://newsletter.manager.dev/p/the-price-of-mandatory-code-reviews

چطور از اجزایی که ممکنه دچار خطا بشن، یک سیستم قابل اتکا بسازیم؟
این مطلب به نظرم خیلی جالب و عمیق بود. مثال هایی از سیستم های سیاسی تا زیستی میزنه ولی به نظرم روح system design جذابی داشت و توصیه می‌کنم حتما بخونید.

https://medium.com/@alireza_norouzi/build-reliable-systems-from-unrealiable-parts-bd921be088c5

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

https://mikefisher.substack.com/p/imposter-syndrome


نظر خودم هم بخوام بگم، ما معمولا خودمون رو با چیزهایی مقایسه می‌کنیم که نباید.

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

۲- نتیجه کار خودمون در چند ساعت یا چند روز رو با نتیجه کار یه تیم بزرگ و با بودجه زیاد که ماه ها روش کار کردن مقایسه می‌کنیم. مثلا من چرا نمیتونم تو خونه تلگرام رو بنویسم. در بهترین حالت من مثل یه برنامه نویس تلگرامم که روز اوله داره می‌ره وارد تیم میشه. و یادمون نره هرچیزی روز اول MVP بوده تا این که کم کم بالغ شده یا اکثرا رها شده.

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

هزینه ثبت‌نام ۲۰۰ هزار تومنه، ولی با کد تخفیف dorsa سی درصد هم کم می‌شه.
زمان برگزاری هم چهارشنبه ۱۰ دیه، ساعت ۱۳.

لینک ثبت‌نام:
https://evand.com/events/ai4se

آیا در یک تیم نرم‌افزاری، همه‌ی کار قابل مشاهده است؟ نه!
کارهایی مثل کد ریویو، تغییرات سریع روی پروداکشن و ... معمولا به شکل تسک و روی جیرا قرار نمی‌گیرن، در نتیجه قابل ارزیابی و پایش (مثلا برای ترفیع هم نیستن)

این مطلب علاوه بر توضیح مساله، یه سری راهکار هم بررسی کرده ولی مهم تر از راهکار به نظرم اینه که همه این حقیقت رو بپذیریم!

https://newsletter.manager.dev/p/the-shadow-work-in-engineering-teams

نشانه های یک کاربر با تجربه در لینوکس!
خلاصه: استفاده درست از ترمینال. :)))

https://itsfoss.com/linux-power-user-signs/