.NET | دات نت
377 subscribers
129 photos
8 videos
36 files
202 links
دوران برنامه‌نویسی سنتی به پایان رسیده؛ یا با هوش مصنوعی هم‌مسیر می‌شی یا جا می‌مونی. اینجا یاد می‌گیریم چطور با اهرمِ AI، ده برابر سریع‌تر کد بزنیم و مهندسِ آینده باشیم.

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


گروه: https://t.me/dndevelopchat
Download Telegram
چرا ReadOnly برای امنیت داده‌های شما کافی نیست؟

همیشه فکر می‌کردم اگر لیستم رو AsReadOnly() کنم، دیگه خیالم راحته و هیچ‌کس نمی‌تونه خرابش کنه.
اما یه روز فهمیدم که ReadOnly فقط یه پنجره شیشه‌ای به لیست اصلیه!
اگه یکی از اون پشت لیست اصلی رو تغییر بده، لیستِ فقط خواندنی من هم تغییر می‌کنه!

راه حل واقعی:
Immutable Collections
اگه می‌خواید داده‌هاتون مثل سنگ نوشته ثابت بمونن و با هیچ طوفانی (حتی توی Multi-threading) تکون نخورن، باید برید سراغ System.Collections.Immutable.

فرقش چیه؟
۱.ء ReadOnly: اگه مرجع اصلی عوض بشه، اینم عوض میشه. (وابسته)
۲.ء Immutable: یه کپی کاملاً مستقل و ثابت. (مستقل)

جادوی Immutable:
وقتی می‌خواید به لیست Immutable آیتم اضافه کنید (Add)، اون لیست قبلی رو دستکاری نمی‌کنه! بلکه یه لیست جدید با اون آیتم اضافه شده بهتون میده.
این یعنی History یا تاریخچه داده‌هاتون همیشه حفظ میشه و هیچ باگ همزمانی (Concurrency) نمی‌تونه سیستم رو کرش کنه.

شما برای داده‌های حساس و ثابت (مثل کانفیگ‌ها) از کدوم استفاده می‌کنید؟

🔗 اطلاعات بیشتر
👍81
خداحافظی با کندی جستجو در داده‌های ثابت! سلام بر FrozenDictionary

تا دیروز وقتی یک لیست ثابت (مثل کانفیگ‌ها یا داده‌های مرجع) داشتیم، فکر می‌کردیم ImmutableDictionary بهترین گزینه است. امن بود، ترد-سیف بود، ولی... سریع‌ترین نبود!
دات‌نت ۸ با معرفی Frozen Collections بازی رو عوض کرد.

تفاوت کجاست؟

وقتی شما از ToFrozenDictionary() استفاده می‌کنید، دات‌نت وقت بیشتری می‌ذاره تا داده‌ها رو آنالیز کنه و بهترین ساختار هَش (Hash) رو برای اون داده‌های خاص بسازه.
این سرمایه‌گذاری اولیه باعث میشه که بعداً سرعت خواندن (Read) به طرز وحشتناکی بالا بره.

قانون انتخاب:

۱. اگه داده‌هاتون مدام تغییر می‌کنه - Dictionary (معمولی)
۲. اگه امنیت و ترد-سیف بودن مهمه ولی آپدیت هم دارید - ImmutableDictionary
۳. اگه داده‌ها یک بار لود میشن و دیگه تکون نمی‌خورن و سرعت جستجو حیاتیه - FrozenDictionary

پ.ن: بهینه‌سازی همیشه به معنی بازنویسی کد نیست؛ گاهی فقط انتخابِ ظرفِ درست برای داده‌هاست.
شما تو پروژه‌هاتون برای داده‌های ثابت (Static Data) از چی استفاده می‌کنید؟

🔗 اطلاعات بیشتر
4👍2👨‍💻1
اگه هنوز دو تا foreach تو در تو می‌نویسی، این پست مال توئه!

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

روش سخت - The Hard Way:
ساختن یه لیست خالی، نوشتن حلقه روی فاکتورها، نوشتن حلقه روی محصولات، و Add کردن دونه دونه...

روش هوشمندانه - The Smart Way:
استفاده از متد قدرتمند SelectMany.
این متد کارش صاف کردن (Flattening) ساختارهای درختیه.
var allProducts = orders.SelectMany(o => o.Products);

این دستور میگه: برو تو دلِ هر سفارش، محصولاتش رو بردار و همه رو بریز رو هم، یه لیست صاف بهم بده.

نکته کنکوری:
فرق Select و SelectMany دقیقا همینجاست:
ءSelect: لیستی از لیست‌ها میده (List<List<Product>>)
ءSelectMany: یک لیست واحد میده (List<Product>)
کد تمیزتر = باگ کمتر + نگهداری راحت‌تر.

شما کجاها از SelectMany استفاده کردید که نجاتتون داده؟
👍105
می‌خواهی یک برنامه‌نویس حرفه‌ای باشی یا فقط کد می‌زنی؟

شاید فکر کنیم حرفه‌ای بودن یعنی داشتنِ عنوان Senior یا Lead در لینکدین، یا تسلط بر ۱۰ زبان برنامه‌نویسی!
اما رابرت سی. مارتین - Uncle Bob در کتاب شاهکارش The Clean Coder نظر متفاوتی دارد.
او می‌گوید: حرفه‌ای‌گری یعنی پذیرفتن مسئولیت.


من قبلاً این کتاب ارزشمند را به فارسی ترجمه کردم و حالا تصمیم گرفتم فصل‌به‌فصل نکات کلیدی‌اش را با شما به اشتراک بگذارم. پست امروز، عصاره‌ی فصل اول: حرفه‌ای‌گری (Professionalism) است. فصلی که مثل یک سیلی محکم به صورت ما توسعه‌دهندگان است!
خلاصه این فصل در ۴ اصل کلیدی:

1️⃣ اول، آسیب نزن:
درست مثل پزشکان، اولین وظیفه ما این است که به نرم‌افزار آسیب نزنیم. فرستادن کدی که می‌دانی (یا شک داری) ناقص است به واحد QA، نهایت غیرحرفه‌ای بودن است. QA نباید باگ پیدا کند؛ آن‌ها برای اطمینان نهایی هستند، نه برای پیدا کردن اشتباهاتِ بدیهی ما.

2️⃣ تست‌نویسی یک وظیفه است، نه پیشنهاد:
چطور مطمئن می‌شوی کدت کار می‌کند؟ تستش کن! تست‌های خودکار باید ۱۰۰٪ کد تو را پوشش دهند. این تنها راهیه که شب‌ها راحت بخوابی و از تغییر دادن کد نترسی.

3️⃣ قانون ۶۰ ساعت کار:
عمو باب معتقد است برنامه‌نویس حرفه‌ای هفته‌ای ۶۰ ساعت کار می‌کند: ۴۰ ساعت برای کارفرما و ۲۰ ساعت برای خودش! این ۲۰ ساعت باید صرف مطالعه، تمرین (Kata) و یادگیری شود. کارفرما مسئول آموزش تو نیست؛ حرفه‌ی تو، مسئولیت توست.

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

این کتاب فقط درباره کدنویسی نیست؛ درباره‌ی شخصیت ما به عنوان یک مهندس نرم‌افزار است.

فصل اول، کلین کدر
9🔥2👏2👎1💯1
تا حالا چند بار برای راضی نگه‌داشتن مدیرت، به یک ددلاین غیرممکن گفتی چشم، سعی‌ام رو می‌کنم؟


در ادامه ترجمه کتاب بی‌نظیر The Clean Coder (اثر رابرت سی. مارتین)، به فصل دوم یعنی نه گفتن (Saying No) رسیدیم. فصلی که احتمالاً خیلی از ما با خوندنش یاد خاطرات تلخ اضافه‌کاری‌های بی‌نتیجه و کدهای کثیف می‌افتیم!
عمو باب در این فصل یک خط قرمز پررنگ می‌کشه: حرفه‌ای‌ها جرئت دارند حقیقت را به قدرت بگویند.

خلاصه این فصل جنجالی در ۴ نکته طلایی:

1️⃣ چیزی به نام سعی کردن وجود ندارد! (قانون یودا): وقتی مدیرت یک کار غیرممکن می‌خواد و تو می‌گویی سعی می‌کنم، در واقع داری دروغ می‌گویی. قول دادن به تلاش، یعنی اعتراف به اینکه تا الان کم‌کاری می‌کردی و حالا می‌خواهی انرژی ذخیره‌ات را آزاد کنی. اگر برنامه جدیدی برای حل مشکل نداری، گفتن سعی می‌کنم فقط آماده شدن برای یک شکست قطعی است.
2️⃣ تضاد منافع، سالم و ضروری است: مدیران وظیفه دارند اهداف کسب‌وکار را با شدت دنبال کنند (مثل تحویل سریع‌تر). برنامه‌نویس‌ها هم وظیفه دارند از کیفیت و واقعیت دفاع کنند. اگر مدیرت می‌گوید فیچر X باید تا فردا آماده شود و تو می‌دانی غیرممکن است، تنها جواب حرفه‌ای یک کلمه است: نه.
3️⃣ آدمِ تیمی بودن به معنی بله‌قربان‌گو بودن نیست: آدم تیمی کسی نیست که برای خوشایند بقیه، قول‌های غیرمنطقی بدهد. تیمی بودن یعنی صادقانه و با شجاعت نشان دهی چه چیزی شدنی است و چه چیزی نیست، حتی اگر به قیمت یک جلسه پرتنش تمام شود.
4️⃣ هزینه وحشتناکِ بله گفتن: وقتی از روی ترس یا برای قهرمان‌بازی ددلاین‌های غیرمنطقی را می‌پذیریم، چه اتفاقی می‌افتد؟ تست‌نویسی فراموش می‌شود، معماری نابود می‌شود، کدهای کثیف (Spaghetti Code) متولد می‌شوند و در نهایت هم خودمان فرسوده می‌شویم و هم پروژه شکست می‌خورد.

کسی که نمی‌تواند نه بگوید، نمی‌تواند کد تمیز بنویسد.

فصل دوم، کلین کدر
🔥31🆒1
گوگل Gemini 3.1 Pro را معرفی کرد
مدل هم‌اکنون در حالت پیش‌نمایش از طریق API، Google AI Studio و Vertex AI در دسترس است. در سرویس NotebookLM دسترسی به‌طور انحصاری برای مشترکین طرح‌های Pro و Ultra باز است.

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/
👍21🔥1
#استخدام

شرکت مبتکر وصال (واقع در محدوده خیابان حافظ تهران) جهت تکمیل تیم فنی خود از برنامهنویسان توانمند .NET دعوت به همکاری مینماید.
🎯 مهارتهای مورد انتظار:
تسلط کامل به C# و .NET
تجربه کار با ASP .NET Core (Web API یا MVC)
آشنایی با SQL Server و طراحی دیتابیس
تسلط نسبی به Git
توانایی کار تیمی و حل مسئله
🌟 مزایا:
محیط کاری حرفهای و دوستانه
فرصت رشد فنی و شغلی
مشارکت در پروژههای واقعی و مقیاسپذیر
📩 ارسال رزومه:
رزومه خود را به ایمیل زیر ارسال کنید:
jobs@timoco.ir
👍32
فصل پیش یاد گرفتیم به ددلاین‌های فضایی و غیرممکن نه بگوییم؛ اما آیا بله گفتن هم مهارت می‌خواهد؟


در ادامه ترجمه کتاب بی‌نظیر The Clean Coder (عمو باب)، رسیدیم به فصل سوم: بله گفتن (Saying Yes). فصلی که نشان می‌دهد
چطور قول بدهیم که هم مدیرمان راضی باشد، هم کد تمیز بماند و هم خودمان زیر فشار له نشویم!
اکثر ما برنامه‌نویس‌ها وقتی تحت فشار قرار می‌گیریم، از کلماتی استفاده می‌کنیم که راه فرار داشته باشند. اما یک بله حرفه‌ای این‌طور کار نمی‌کند.
خلاصه این فصل در ۴ اصل کاربردی:

1️⃣ زبان تعهد (The Language of Commitment): تعهد واقعی ۳ مرحله دارد: بگویی که انجامش می‌دهی، واقعاً منظورت همان باشد، و در نهایت انجامش دهی. یک برنامه‌نویس حرفه‌ای می‌گوید: «من این کار را تا روز سه‌شنبه تمام می‌کنم.» (بدون اما و اگر!)
2️⃣ کلماتِ ممنوعه و غیرحرفه‌ای: واژه‌هایی مثل باید، سعی می‌کنم، امیدوارم یا کاش، نشان‌دهنده نبودِ تعهد هستند. شما را شبیه قربانی شرایط نشان می‌دهند، نه کسی که کنترل اوضاع را در دست دارد.
3️⃣ خط قرمزهای غیرقابل‌مذاکره: وقتی مدیرت می‌پرسد نمی‌شود این فیچر را تا فردا برسانی؟، وسوسه می‌شوی که نوشتن Unit Testها یا ریفکتور کردن (Refactoring) را فدای سرعت کنی. عمو باب می‌گوید این کار خط قرمز یک حرفه‌ای است! پایین آوردن کیفیت کد، شما را سریع‌تر نمی‌کند، بلکه پروژه را به باتلاق می‌کشاند.
4️⃣ بله‌ی خلاقانه (هنر مذاکره): اگر قرار است برای رساندن پروژه اضافه‌کاری کنید، باید حد و مرزتان را بشناسید. یک بله‌ی حرفه‌ای یعنی: من آخر هفته اضافه‌کاری می‌کنم تا فیچر تا دوشنبه آماده شود، اما در عوض سه‌شنبه و چهارشنبه را مرخصی می‌گیرم تا ریکاوری شوم.

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

فصل سوم، کلین کدر
2👏2❤‍🔥1
تا حالا به کدهایی که ساعت ۳ صبح زدی افتخار کردی؟
اگر جوابت مثبته، عمو باب توی فصل چهارم کتاب The Clean Coder قراره حسابی غافلگیرت کنه!


فصل چهارم (کدنویسی) به جای اینکه درباره سینتکس‌ها حرف بزنه، درباره آمادگی ذهنی و روانی یک مهندس نرم‌افزار حرفه‌ای صحبت می‌کنه.
کد زدن یک کار به‌شدت فرساینده و نیازمند تمرکز بالاست و اگر اصول روانی‌اش رو رعایت نکنیم، فاجعه به بار میاد.


خلاصه ۵ قانون طلایی عمو باب برای زمان کدنویسی:

1️⃣ افسانه کد ساعت ۳ صبح: بیدار موندن و کد زدن در حالت خستگی نشانه تعهد نیست، نشانه بی‌انضباطی است! کدی که با ذهن خسته نوشته بشه، پر از باگ و طراحی‌های فاجعه‌بار خواهد بود که ماه‌ها وقت تیم رو برای دور زدنش می‌گیره. وقتی خسته‌ای، کُد نزن!

2️⃣ فرار از ناحیه جریان (The Flow Zone):
خیلی از ما عاشق اون حالت خلسه و تمرکز تونلی موقع کد زدن هستیم (زون). اما عمو باب می‌گه در این حالت، تصویر بزرگ پروژه رو از دست می‌دی و کدهایی می‌زنی که بعداً باید پاک بشن. برنامه‌نویسی دونفره (Pair Programming) بهترین پادزهر برای نیفتادن تو این تله است.

3️⃣ امید، قاتل پروژه‌هاست:
وقتی می‌فهمی به ددلاین نمی‌رسی، به معجزه و اضافه‌کاری امیدوار نباش. یک حرفه‌ای فوراً پرچم قرمز رو بالا می‌بره، واقعیت رو به ذی‌نفعان می‌گه و با کاهش دامنه (Scope) کار رو مدیریت می‌کنه.

4️⃣ توهم تمام شد (False Delivery):
بدترین رفتار غیرحرفه‌ای اینه که بگیم کار تموم شده در حالی که فقط کدش رو نوشتیم و تست نشده. تعریف تمام‌شده (Done) یعنی پاس شدن تمام تست‌های پذیرش خودکار.

5️⃣ دیباگ کردن جزو زمان توسعه نیست، یک خطاست:
زمان دیباگ همون‌قدر برای شرکت هزینه داره که زمان توسعه! یک حرفه‌ای با استفاده از توسعه مبتنی بر تست (TDD) زمان دیباگ رو به سمت صفر میل می‌ده.

فصل چهارم، کلین کدر
❤‍🔥83🔥1
#استخدام

ما در تیممون به دنبال یک توسعه دهنده بکند (.NET Core) هستیم

اگر حداقل ۲ سال سابقه کار دارید، از چالشهای فنی لذت میبرید و دوست دارید روی یک محصول بزرگ (سیستم ERP) با چشمانداز حرکت به سمت معماری میکروسرویس کار کنید، جای شما در تیم ما خالیه.

مهارتهای اصلی که از شما انتظار داریم:
تسلط خوب (متوسط به بالا) بر C#, .NET / .NET Core, ASP.NET
تسلط بر EF Core و SQL Server
تجربه کار با Redis, Docker, Git و Unit Testing
تسلط بر اصول Clean Code و توانایی درک منطقهای پیچیده تجاری (Business Logic)

امتیازات ویژه (داشتن این موارد مزیت بزرگیه):
آشنایی با مفاهیم حسابداری و مالی (به دلیل ماهیت سیستم ERP)
آشنایی با معماری میکروسرویس و Message Brokering (مثل RabbitMQ)
آشنایی با CI/CD، دیتابیسهای NoSQL (مثل MongoDB) و gRPC / SignalR

از طریق ایمیل زیر یا بله میتونید رزومهتون رو برامون ارسال کنید.
Mohamadrezakiani8565@gmail.com
👍5
#استخدام

ما در جستجوی یک برنامهنویس .NET توانمند و علاقهمند به توسعه نرمافزارهای حرفهای هستیم؛ فردی که به کدنویسی تمیز، حل مسائل چالشی و یادگیری مستمر اهمیت میدهد. اگر به طراحی معماریهای اصولی، توسعه APIهای مقیاسپذیر، طراحی بهینه پایگاه داده و همکاری در یک تیم فنی پویا علاقهمند هستید، خوشحال میشویم با شما آشنا شویم.
ما یک شرکت دانشبنیان فعال در پروژههای واقعی و بلندمدت هستیم و امکان همکاری بهصورت حضوری، دورکاری یا ترکیبی را فراهم کردهایم. همچنین، برای افراد مشمول، امکان جذب بهصورت امریه نیز وجود دارد.
🛠️ مهارتها و توانمندیهای موردنیاز:
• تسلط بر C# و ASP.NET Core
• تجربه کار با SQL Server، کوئرینویسی پیشرفته و طراحی Index
• آشنایی با Dapper (تجربه کار با Entity Framework مزیت محسوب میشود)
• توانایی توسعه RESTful API
• درک مفاهیم معماری نرمافزار مانند Clean Architecture و Microservices
• تسلط بر ابزارهایی مانند Git، Postman و Swagger
• آشنایی با اصول تستنویسی (xUnit / NUnit) و امنیت API
📩 جهت ارسال رزومه یا دریافت اطلاعات بیشتر، لطفاً از طریق راههای زیر با ما در ارتباط باشید:
✉️ hr@behinehsazan.ir
🌐 behinehsazan.ir
4👍2
#استخدام

Back-End Developer (.NET Core)
تماموقت | حضوری
امید بانک سپه جهت تکمیل تیم فنی خود از متخصصین Back-End .NET Core مسلط به معماری Microservices دعوت به همکاری مینماید.
شرایط احراز:
تسلط به C# و ASP.NET Core
تجربه عملی در Microservices Architecture
تسلط به دیتابیس SQL Server
آشنایی با MongoDB و Redis
آشنایی با RabbitMQ و Message Brokerها
آشنایی با Elasticsearch
آشنایی با Git و مفاهیم CI/CD

📩 ارسال رزومه:
09120847018 (پلتفرم بله)
👍5
پرامپت بد یعنی هدررفت هزینه و توکن؛ در وبینار «پرامپت نویسی» با ارائه سجاد تهامی، تفاوت پرامپت های خوب و بد را بررسی میکنیم و یاد میگیریم چطور با نوشتن پرامپت بهتر، خروجیهای باکیفیت بگیریم و هزینه های هوش مصنوعی را بهینه کنیم.


https://digiform.ir/wb11331162
👍31
#استخدام

برای گسترش تیم IT در شرکت هواپیمایی پارسیانا ، به دنبال #جذب همکاران متخصص در دو #موقعیت_شغلی هستیم: 👨💻 👩💻

Full Stack Developer

شرایط احراز:
حداقل ۵ سال سابقه #توسعه_نرمافزار
تسلط به C#، ASP.NET Core، Web API، EF Core و Blazor
آشنایی با SPA و یکی از Angular / React / Vue
تسلط به Git و فرآیند Agile / Scrum
توانایی حل مسئله و کار تیمی
حداکثر سن: ۳۵ سال
وظایف و مسئولیتها:
توسعه #Backend و Web API با ASP.NET Core
پیادهسازی Frontend با #Blazor
مشارکت در طراحی معماری و بهبود سیستمها
همکاری با تیم توسعه در فرآیند Agile
بهینهسازی کیفیت، امنیت و کارایی سامانهها
صلاحیتهای حرفهای:
توانایی طراحی و توسعه سیستمهای مقیاسپذیر
مهارت در کار تیمی، Code Review و ارائه راهکار فنی
یادگیری مستمر و رشد حرفهای

UI/UX

وظایف و مسئولیتها:
#طراحی_رابط_کاربری وبسایت و اپلیکیشنهای خدمات پرواز و رزرو بلیت
طراحی Design System، وایرفریم، ماکاپ و پروتوتایپ
همکاری با تیم UX، توسعه و محصول
بهبود مستمر UI بر اساس تست و رفتار کاربران
حفظ یکپارچگی بصری محصولات دیجیتال
شرایط احراز:
حداقل ۲ تا ۳ سال تجربه طراحی UI
تسلط به Figma، Adobe XD یا Sketch
آشنایی با Design System، Responsive و Mobile-first Design
درک اصول UX و Usability
توانایی کار تیمی و ارتباط موثر
داشتن Portfolio الزامی است
صلاحیتهای حرفهای:
تجربه طراحی در حوزه سفر، گردشگری یا ایرلاین مزیت محسوب میشود
آشنایی با HTML/CSS و محدودیتهای فرانتاند
تجربه طراحی داشبورد و سیستمهای رزرو

📌 محل کار: غرب تهران (پونک)
🗓️ روزهای کاری: شنبه تا چهارشنبه

منتظر دریافت رزومه شما در ایمیل aneseh.jebeli@flyxpro.com یا DM و آشنایی بیشتر با شما هستیم.
2👍2
Gemini 3.5 Flash
🔥7🤣2👍1
4
چرا از کلود جواب‌های بیخود می‌گیریم؟

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

۱. با «هدف» شروع کنید
دقیقاً چه خروجی‌ای می‌خواهید؟ یک پست لینکدین؟ یک استراتژی بازاریابی؟ آنالیز داده یا کدنویسی؟ از ابتدا برای هوش مصنوعی مشخص کنید.

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

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

۴. روی جزئیات خروجی وسواس داشته باشید.لحن، فرمت و سبک نگارش را دقیقاً مشخص کنید. مثلاً: «لحن کاربردی و بیزینسی، پاراگراف‌های کوتاه، بدون زیاده‌گویی و کلمات کلیشه‌ای.»

۵. گام‌به‌گام پیش بروید
بهترین نتایج زمانی به دست می‌آیند که شما در چند مرحله با AI گفتگو کنید و خروجی را صیقل دهید، نه اینکه توقع داشته باشید با یک پرامپتِ واحد، یک شاهکار تحویلتان دهد.
یک تغییر زاویه دید کوچک، معجزه می‌کند:
به جای اینکه با هوش مصنوعی مثل موتور جستجو (گوگل) رفتار کنید، با آن مثل یک همکار تخصصی برخورد کنید.

اینجاست که کیفیت خروجی‌ها زمین تا آسمان فرق خواهد کرد.
کاربران معمولی: از AI می‌خواهند که به جای آن‌ها فکر کند.
کاربران هوشمند: طراحی می‌کنند که AI چگونه باید فکر کند.تفاوت یک پرامپت معمولی با یک سیستم قدرتمند دقیقاً در همین نکته است.
5👏2👍1🆒1
لینکدین کاغذی ☺️

پرامپت:

Recreate this image in a paper craft style, simplifying the details to make them suitable for paper craft artwork. Arrange the overall composition to feel visually pleasing, soft, and cute. You may add charming decorative elements such as birds, butterflies, flowers, etc., to enhance the adorable atmosphere while still matching the original image.
1👍1🥰1
تجربه‌ی من از کار با تیم‌های چینی تا الان یه تصویر جالب ساخته

به نظرم برتری‌شون از طرز فکر و سبک کارشونه. دو تا نکته خیلی برام پررنگ بود:

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

دوم، سطح کار کردنشونه. مثلا این آخر هفته، از سرمایه‌گذار گرفته تا مدیرعامل و تیم فنی، همه تا ۱۰ شب توی آفیس بودیم. نه از جنس فشار، بلکه از جنس درگیر بودن واقعی. مدیرها هم به‌طرز عجیبی در جریان جزئیات پروژه‌ان—نه فقط در حد گزارش.
خیلی ساده‌زیست. اینجوری که حتی قهوه نمیخورن فقط آب جوش همیشه کنار دستشونه.

Farhan Kardan
👍8🤓1
۳ نکته تکان‌دهنده از تحقیق ۲۰۲۶ دانشگاه MIT درباره آینده مشاغل و AI

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

1️⃣ ء(Task Chaining): به جای سپردن کارهای تکی به AI، باید تسک‌های همسایه و مشابه را در یک بسته (Cluster) قرار داد تا هوش مصنوعی بتواند آن‌ها را پشت‌سرهم جلو ببرد.

2️⃣ ء(Handoffs): هر بار کار برای تایید از AI به انسان منتقل می‌شود، سرعت کل فرآیند افت می‌کند. زنجیره کاملی که تماماً توسط AI انجام شود (حتی با کیفیت کمی پایین‌تر) به دلیل حذف زمان بررسی انسان، بازدهی بسیار بالاتری دارد.

3️⃣ تغییر تعریف پوزیشن‌های شغلی: مشاغل دیگر بر اساس کارهای روتین تعریف نمی‌شوند، بلکه به سمت کارهای مبتنی بر قضاوت (Judgment-based) و تفکر استراتژیک تغییر جهت می‌دهند.

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

🔗 منبع: MIT Sloan (2026)
👍31🔥1