Mohammad (@M_Khani65) header
Mohammad (@M_Khani65) profile picture

آمدم دیدم فتح کردم

United Kingdom
Joined October 2008
Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)Photo by Mohammad (@M_Khani65)
گویند اگر می بخوری عرش بلرزد عرشی که به یک باده بلرزد به چه ارزد؟ در خانهٔ ما زیر زمینی‌ست که در آن یک خم بخوری خشتی از آن نیز نلرزد خیام
7
195
🚀 یه خبر درباره Translate It! اکستنشن ترجمه‌ای که روش کار میکردیم، حالا فراتر از یک ابزار ساده ترجمه رفته. کاربردی بودنش باعث شده توجه و حمایت چند شرکت و مجموعه بزرگ رو هم به دست بیاره؛ اتفاقی که برای ادامه توسعه و بزرگ‌تر شدن این پروژه متن‌باز خیلی ارزشمنده. @M_Khani65
23
24
554
14,586
موکلم امیرحسین‌ موسوی بابت اتهام افساد فی‌الارض از طریق فعالیت مجازی در اکانت توییتری جیمز بی‌دین به اعدام محکوم شد. #امیرحسین_موسوی
947
4,772
469
18,477
710,806
به یاد پدرم که ایران را عاشقانه دوست داشت و بهترینها را برای ایرانیان می‌خواست.
9,732
50,018
2,171
111,636
2,997,369
این پرامپتی که آقای کشاورز نوشتند رو در هوش مصنوعی که بیشترین استفاده روزانه رو ازش دارید، امتحان کنید. پاسخ‌هاش ممکنه سرنخ‌هایی بهتون بده که در برخیش احساس مقاومت کنید که صد البته همون‌ها، نقطه درستی هستند برای تامل بیشتر.
این پرامپت رو به چت جی‌پی‌تی بدین. نتایجش جالبه (و البته ممکنه ترسناک باشه): تو من را می‌شناسی. کاملا بی‌طرف و صادق باش. به من بگو چه موانعی بر سر راه رسیدن من به آزادی شخصی وجود دارد؟ چه چیزی مانع آن می‌شود که اصیل (Authentic) باشم؟ شاید چیزهایی هست که به تو نگفته باشم اما تو بتوانی حدس‌ها و تخمین‌هایی درباره آن‌ها بزنی. به تمام صحبت‌هایمان رجوع کن و به من سرنخ‌هایی بده. این هم پرامپت انگلیسی‌اش: You know me. Be completely objective and honest. Tell me what barriers I have in reaching my freedom. What prevents me from being authentic? There may be things you do not know for certain, but please make educated guesses. Give me clues. You can access all our past discussions.
1
4
128
من جدیدا این ترکیب رو استفاده می‌کنم، گفتم بگم ببینم شما چه مدلی کار می‌کنید و ماهی چقدر براتون هزینه داره. ۲۰ دلار ChatGPT به اضافه ۱۰ دلار OpenCode Go؛ یعنی در مجموع ۳۰ دلار. چون از oh-my-opencode-slim استفاده می‌کنم، می‌تونم برای هر بخش از کار مشخص کنم کدوم مدل استفاده بشه. اینطوری هم هزینه دستمه، هم لازم نیست برای همه‌چیز سراغ مدل گرون‌تر برم. تعامل من با Web Chat هم خیلی بیشتر شده. تقریبا همه تصمیم‌ها، طراحی و بررسی‌ها رو با Sol 5.6 اونجا انجام می‌دم. کدهای پروژه رو وصل کردم تا وبچت دسترسی داشته باشه، بخش زیادی از بررسی ریپو و کد عملا همون‌جا انجام میشه. چیزی که می‌مونه بیشتر پیاده‌سازیه که شاید حدود ۶۰٪ کار باشه. با OMOS، یه Agent با Terra 5.6 تسک‌ها رو می‌سازه و حواسش هست درست اجرا بشن؛ خود پیاده‌سازی رو هم میشه بسته به تسک داد به Luna 5.6، DeepSeek، MiMo 5.6 یا حتی مدل‌های دیگه. تنها ایرادش اینه که یکم به OpenCode وابسته می‌شی. ولی تا اینجا واقعا از نتیجه و هزینه‌اش راضی‌ام. فکر کنم ارزش داشته باشه یکی دو توییت دیگه هم درباره‌ش بزنم و با آمار واقعی ببینیم مصرف و هزینه دقیقا چقدر میشه. بعدا هم می‌خوام همین ترکیب رو با Astra و Claude امتحان کنم و تفاوتشون رو ببینم. #ارکسترـomos لینک omos 👇
4
3
45
3,010
توی شرکت یه مدیر اداری داشتیم که هر چند وقت یه بار می‌گفت: «مامور مالیات اومده.» بعد یه سکه از گاوصندوق شرکت برمی‌داشت و می‌گفت: «حلش کردم.» سال‌ها همین روال ادامه داشت تا بازنشسته شد. از همون روز، دیگه هیچ مامور مالیاتی پیداش نشد. بعدا فهمیدیم «مامورهای مالیات» رفیق‌های خودش بودن؛ می‌اومدن یه چایی می‌خوردن و می‌رفتن، سکه هم می‌موند برای خودش : )
9
2
2
705
54,523
یکی از جاهایی که Coding Agentها بی‌دلیل Token می‌سوزونن، انتخاب Model برای sub-agentهاست. مثلا شما برای Plan یک مدل قوی مثل Sol یا Fable انتخاب می‌کنید، ولی همان مدل ممکنه برای کارهای ساده‌ای مثل جستجو در Codebase، پیدا کردن فایل یا تحقیق اولیه هم استفاده بشه. پلاگین oh-my-opencode-slim این مشکل رو خیلی خوب حل کرده. با اضافه کردن ۶ تا Agent: ؜- Orchestrator = مغز اصلی و تصمیم گیرنده برای تقسیم و مدیریت کار ؜- Explorer = پیدا کردن و بررسی Codebase ؜- Librarian = تحقیق و جمع‌آوری اطلاعات ؜- Oracle = تحلیل، reasoning و تصمیم‌گیری ؜- Designer = کارهای UI ؜- Fixer = پیاده‌سازی ؜- YOUR_AGENT = می‌تونید agentهای شخصی اضافه کنید برای هر Agent یک Model و سطح کیفیت مشخص می‌کنید. بعد فقط Prompt را به Orchestrator می‌دهید؛ خودش تصمیم می‌گیره هر بخش را به کدام Agent بسپارد. همچنین Taskها می‌توانند Parallel اجرا شوند. نتیجه: مدل قوی فقط جایی مصرف می‌شود که واقعا لازم است؛ هزینه کمتر، Token کمتر و اجرای سریع‌تر.
3
1
72
4,351
شرکت Uber داره توسعه نرم‌افزار رو به یک Software Factory مبتنی بر Agent تبدیل می‌کنه. بیش از ۷۰٪ PRهای این شرکت به Agentها نسبت داده شده‌اند. چند نکته جالب از تجربه‌شون: • فقط مدل ارزان‌تر انتخاب نمی‌کنن؛ Turn، Request و Token اضافی رو کم می‌کنن. • سطح فکر کردن Model برای Planning و ارزیابی، بصورت پیش‌فرض روی Medium است. • حتی Context رو برای Modelهای یک‌میلیون‌ توکنی رو هم از حدود 400K به بعد Compact می‌کنن. • کارهای تکراری رو داخل Script می‌برن و خروجی اسکریپت رو به AI میدن؛ تا AI تعداد درخواست‌های کمتری بزنه، این کار ۵۰ تا بیش از ۹۰٪ مصرف Token رو کاهش داده. • با استفاده از درخت دانش، اطلاعات پروژه‌ها، سرویس‌ها و سیستم‌ها رو به هم وصل کردن. (AI Context Graph) در یک نمونه، کاری که بعد از ۲۰ دقیقه هنوز جواب درستی نداشت، با Context Graph در حدود ۳۸ ثانیه انجام شد. نتیجه: همیشه مدل قوی‌تر راه‌حل نیست؛ Context بهتر و مسیر کوتاه‌تر گاهی مهم‌تره.
1
1
92
7,511
با دیدن این توییت یه نکته به ذهنم رسید. از AI بخواه Ownership فایل‌ها رو هم بررسی کنه. یکی از رایج‌ترین خروجی‌های Vibe Coding، ساختن God Objectهاست؛ فایل‌های بزرگی که هر تغییر کوچیک، AI رو مجبور می‌کنه کل فایل رو دوباره بخونه و در نتیجه مصرف توکن بی‌دلیل بالا می‌ره. از همون اول به AI بگو «Ownership خط قرمز پروژه است و نباید با شکستن مرز مسئولیت‌ها فایل‌های حجیم و همه‌کاره تولید کنه.»
تازه متوجه شدم Gemini Pro این روزا خیلی سریع‌تر لیمیت می‌کنه! 😅 قبلاً کلی فایل می‌دادم و یکی‌دو ساعت باهاش پرامپت می‌زدم، اما الان فقط حدود ۵۰ تا فایل دادم و کمتر از نیم ساعت لیمیت شدم. حاجی ۶۸۰ هزار پول گرفتی، یه کم بیشتر دوام بیار دیگه! 😂
1
1
45
4,336
داشتم یه پروژه رو با Vibe Coding جلو می‌بردم و هر پیشنهاد AI رو قبول می‌کردم. وسطش دیدم خیلی داره پیچیده‌اش می‌کنه، بهش گفتم: - «مطمئنی؟» همون کافی بود؛ شروع کرد تمام پیشنهادهایی که خودش داده بود رو یکی‌یکی رد کردن. ظاهرا بهترین Prompt، همون «مطمئنی؟» بود : )
16
1
222
11,843
حالا که وایب‌کدینگ این‌قدر ترند شده، حداقل ورژن‌بندی رو هم بسپرید به AI. قاعده‌ی Semantic Versioning خیلی ساده‌ست: فقط یه باگ رو درست کردی؟ 1.2.3 ← 1.2.4 عملکرد رو بهتر کردی ولی تغییری برای کاربر ایجاد نشده؟ 1.2.3 ← 1.2.4 یه قابلیت جدید اضافه کردی که با نسخه‌های قبلی سازگاره؟ 1.2.3 ← 1.3.0 چند قابلیت جدید اضافه کردی؟ 1.2.3 ← 1.3.0 توی API یا تنظیمات قبلی تغییر دادی و ممکنه نخسه‌های قبلی از کار بیفتن؟ 1.2.3 ← 2.0.0 فرمت فایل یا دیتابیس رو طوری تغییر دادی که نسخه‌های قبلی دیگه سازگار نیستن؟ 1.2.3 ← 2.0.0 نه اینکه رنگ دکمه رو عوض کنی و پروژه از v1.0 برسه به v3.0. ورژن‌بندی حرمت داره، نه لذت.
11
15
1
416
21,549
پلتفرم چینی Astraflow تا ۱۰۰ دلار اعتبار رایگان برای استفاده از مدل‌های مختلف میده. از Claude Opus 4.5 و Gemini 3.5 Flash گرفته تا کلی مدل دیگه، همراه با API Key برای استفاده مستقیم. تا وقتی رایگانه، بد نیست ثبت‌نام کنید و سوی استفاده کنید: 🔗 astraflow.ucloud-global.com/…
5
6
2
195
20,288
اصطلاح Impact Analysis هم یکی از اون کلماتیه که کیفیت خروجی AI رو خیلی تغییر می‌ده. مثلا به جای اینکه بپرسم: «اگه این فرم ثبت‌نام رو ساده‌تر کنیم چی میشه؟» «اگه ساعت شروع کار شرکت رو یک ساعت جابه‌جا کنیم چی میشه؟» می‌گم: «یه Impact Analysis برای این تغییر انجام بده.» وقتی این عبارت رو می‌بینه، فقط خود تغییر رو بررسی نمی‌کنه؛ اثرش روی کاربران، داده‌ها، فرآیندها، تیم پشتیبانی، گزارش‌ها و بخش‌های مرتبط رو هم تحلیل می‌کنه. خیلی وقت‌ها مشکل اصلی خودِ تغییر نیست؛ زنجیره‌ای از اثراتیه که بعد از تغییر ایجاد می‌شه و کسی از قبل بهش فکر نکرده.
وقتی یه مشکل تکرار می‌شه، بیشتر ما دنبال راهی برای رفع علائمش هستیم. سایت کند شده؟ سرور قوی‌تر. فروش کم شده؟ تبلیغات بیشتر. مشتری ناراضیه؟ تخفیف بده. اما وقتی به AI می‌گی: «یه Root Cause Analysis انجام بده.» دیگه روی خودِ مشکل تمرکز نمی‌کنه؛ دنبال این می‌گرده که چرا این مشکل اصلا به وجود اومده. بعضی وقت‌ها چیزی که داریم حل می‌کنیم، مشکل اصلی نیست؛ فقط نشانه‌ای از یک مشکل عمیق‌تره. AI با دیدن اصطلاح Root Cause Analysis می‌فهمه که باید عمیقر بررسی کنه تا مشکل رو پیدا کنه بجای رفع موردی.
3
43
2,777
وقتی یه مشکل تکرار می‌شه، بیشتر ما دنبال راهی برای رفع علائمش هستیم. سایت کند شده؟ سرور قوی‌تر. فروش کم شده؟ تبلیغات بیشتر. مشتری ناراضیه؟ تخفیف بده. اما وقتی به AI می‌گی: «یه Root Cause Analysis انجام بده.» دیگه روی خودِ مشکل تمرکز نمی‌کنه؛ دنبال این می‌گرده که چرا این مشکل اصلا به وجود اومده. بعضی وقت‌ها چیزی که داریم حل می‌کنیم، مشکل اصلی نیست؛ فقط نشانه‌ای از یک مشکل عمیق‌تره. AI با دیدن اصطلاح Root Cause Analysis می‌فهمه که باید عمیقر بررسی کنه تا مشکل رو پیدا کنه بجای رفع موردی.
یکی دیگه از اصطلاحاتی که کیفیت خروجی AI رو خیلی تغییر می‌ده، Trade-off Analysis هست. مثلا به جای اینکه بپرسم: «ماشین بخرم یا از حمل‌ونقل عمومی استفاده کنم؟» می‌گم: «یه Trade-off Analysis بین خرید ماشین و استفاده از حمل‌ونقل عمومی انجام بده.» وقتی این عبارت رو می‌بینه، دیگه دنبال یک جواب قطعی نیست؛ هزینه، زمان، راحتی، انعطاف‌پذیری، دردسرهای نگهداری و محدودیت‌های هر گزینه رو کنار هم می‌ذاره. خیلی وقت‌ها بهترین تصمیم این نیست که کدوم گزینه "بهتره"؛ اینه که بدونیم با انتخاب هر گزینه، داریم چه چیزی به دست میاریم و از چه چیزی صرف‌نظر می‌کنیم.
1
43
5,447
دیدم بعضی‌ها از AI می‌پرسن: «چطور فروش سایت رو بیشتر کنیم؟» و یه لیست بلند از ایده‌ها تحویلت می‌ده. اما وقتی بگی: «برای فروش فعلی سایت من یک Gap Analysis انجام بده.» اونقت AI اول دنبال این می‌گرده که چه چیزی کم است. شاید مشکل تبلیغات نباشه. شاید نرخ تبدیل پایینه. شاید صفحه قیمت‌گذاری ضعیفه. شاید مشتری‌ها وسط فرآیند خرید رها می‌کنن. اصطلاح Gap Analysis قبل از اینکه بگه چه کاری انجام بده، مشخص می‌کنه چه چیزی وجود نداره. خیلی از وقت‌ها مشکل، نداشتن راه‌حل نیست؛ اشتباه تشخیص دادن شکاف اصلیه. با این اصطلاح میشه این شکاف رو بهتر تشخیص داد.
یکی دیگه از اصطلاحاتی که کیفیت خروجی AI رو خیلی تغییر می‌ده، Trade-off Analysis هست. مثلا به جای اینکه بپرسم: «ماشین بخرم یا از حمل‌ونقل عمومی استفاده کنم؟» می‌گم: «یه Trade-off Analysis بین خرید ماشین و استفاده از حمل‌ونقل عمومی انجام بده.» وقتی این عبارت رو می‌بینه، دیگه دنبال یک جواب قطعی نیست؛ هزینه، زمان، راحتی، انعطاف‌پذیری، دردسرهای نگهداری و محدودیت‌های هر گزینه رو کنار هم می‌ذاره. خیلی وقت‌ها بهترین تصمیم این نیست که کدوم گزینه "بهتره"؛ اینه که بدونیم با انتخاب هر گزینه، داریم چه چیزی به دست میاریم و از چه چیزی صرف‌نظر می‌کنیم.
1
10
630
یکی دیگه از اصطلاحاتی که کیفیت خروجی AI رو خیلی تغییر می‌ده، Trade-off Analysis هست. مثلا به جای اینکه بپرسم: «ماشین بخرم یا از حمل‌ونقل عمومی استفاده کنم؟» می‌گم: «یه Trade-off Analysis بین خرید ماشین و استفاده از حمل‌ونقل عمومی انجام بده.» وقتی این عبارت رو می‌بینه، دیگه دنبال یک جواب قطعی نیست؛ هزینه، زمان، راحتی، انعطاف‌پذیری، دردسرهای نگهداری و محدودیت‌های هر گزینه رو کنار هم می‌ذاره. خیلی وقت‌ها بهترین تصمیم این نیست که کدوم گزینه "بهتره"؛ اینه که بدونیم با انتخاب هر گزینه، داریم چه چیزی به دست میاریم و از چه چیزی صرف‌نظر می‌کنیم.
کیفیت خروجی AI فقط به مدل بستگی نداره؛ به واژه‌هایی که برای تعریف تسک استفاده می‌کنیم هم بستگی داره. مثلا قبل از هر تغییری توی پروژه، بهش می‌گم: «یه Audit از بخش گزارش‌گیری بگیر.» وقتی کلمه Audit رو می‌بینه، می‌فهمه قرار نیست کد بزنه؛ باید ساختار، جریان داده و نحوه کار سیستم رو بررسی کنه. خروجی هم معمولا خیلی دقیق‌تر می‌شه. بعد می‌گم: - یه Audit برای تغییرات لازم برای اضافه کردن مثلا فیلد تاریخ - یه Audit برای ریسک‌ها و چالش‌هاش - یه Audit برای نقاطی که تحت تاثیر قرار می‌گیرن تا اینجا نه کدی نوشته شده، نه تغییری اعمال شده؛ فقط مسئله کامل فهمیده شده. وقتی به مرحله اجرا می‌رسیم، AI هم ساختار پروژه رو می‌شناسه، هم نیازمندی رو؛ دیگه نمی‌ره برای خودش ریفکتور کنه یا کد تکراری یا موازی تولید کنه.
1
3
1
61
6,537