بازگشت به مهندسی مدرن و کار با هوش مصنوعی · فصل صفر — جای خودت را در مسیر پیدا کن · 6
چطور بفهمیم یک آموزش فنی به‌روز و قابل اعتماد است؟
نمی‌تواند بین منبع معتبر، ادعای پایدار، ادعای متغیر و توضیح قدیمی تفاوت عملی بگذارد. می‌تواند برای یک ادعای فنی منبع مناسب، تاریخ بررسی و محدوده‌ی اعتبار ثبت کند.
How Do You Tell Whether Technical Training Is Current and Trustworthy? — en-US
خلاصهٔ درس
نمی‌تواند بین منبع معتبر، ادعای پایدار، ادعای متغیر و توضیح قدیمی تفاوت عملی بگذارد.
می‌تواند برای یک ادعای فنی منبع مناسب، تاریخ بررسی و محدوده‌ی اعتبار ثبت کند.
خروجی این درس
می‌تواند برای یک ادعای فنی منبع مناسب، تاریخ بررسی و محدوده‌ی اعتبار ثبت کند.
پیش‌نیازها
دو آموزش درباره یک موضوع فنی به شما دو توصیه متفاوت می‌دهند. یکی دیروز منتشر شده و با اطمینان حرف می‌زند؛ دیگری به مستندات رسمی و نسخه مشخص ارجاع می‌دهد اما قدیمی‌تر است. اگر فقط از روی تاریخ انتشار، ظاهر سایت یا قطعیت لحن تصمیم بگیرید، هنوز نمی‌دانید کدام ادعا واقعاً پشتیبانی شده و تا چه زمانی می‌توان به آن تکیه کرد.
هدف این درس ساختن یک فهرست از «سایت‌های همیشه معتبر» نیست. قرار است برای یک ادعای فنی محدود مشخص کنید منبع مناسب چیست، منبع دقیقاً چه چیزی را پشتیبانی می‌کند، اطلاعات چه زمانی بررسی شده، چه اتفاقی باید باعث بازبینی شود و در پایان آیا ادعا را ACCEPT، MODIFY یا DEFER می‌کنید.
خروجی شما یک Technical Claim Trust Card است. این کارت باید تصمیم را قابل‌بررسی کند؛ نه اینکه فقط بگوید «به نظرم معتبر است».
این درس تسلط فنی، آمادگی شغلی یا درست‌بودن همه مطالب یک آموزش را اثبات نمی‌کند. فقط قضاوت شما درباره یک claim محدود و evidence مربوط به همان claim را تمرین می‌کند.
قبل از شروع: یک بررسی کوتاه پیش‌نیاز
یک جمله فنی دلخواه بردارید و دو خط بنویسید:
- Claim: دقیقاً چه چیزی ادعا شده است؟
- Evidence/Source: چه مدرک یا منبعی می‌تواند همین ادعا را پشتیبانی کند؟
اگر این دو را نمی‌توانید از هم جدا کنید، ابتدا همین bridge کوتاه را انجام دهید: یک جمله خبری ساده انتخاب کنید، بخش «ادعا» را از «دلیل یا منبعی که برای دفاع از آن آورده شده» جدا کنید و فقط بعد وارد کارت اعتماد شوید. پیش‌نیاز این درس نرم است؛ نبودن evidence کافی باید به ترمیم هدفمند منجر شود، نه عبور بی‌دلیل.
مسیر پشتیبانی را از روی evidence فعلی انتخاب کنید
مقصد برای همه یکی است: هر مسیر باید به یک Technical Claim Trust Card کامل با همان evidence bar برسد. تفاوت مسیر فقط در مقدار و نوع support قبل از رسیدن به آن evidence است.
- Foundation — وقتی authority، provenance، claim boundary، freshness یا سه تصمیم هنوز برایتان ناآشناست، این مسیر را بروید. مدل مرکزی را کامل بخوانید، کارت را با template بسازید، worked caseها را بررسی کنید و بعد از تمرین هدایت‌شده وارد transfer مستقل شوید.
- Repair — وقتی مشکل مشخص و محدود است، کل درس را دوباره اجرا نکنید. اگر claim و evidence را قاطی می‌کنید، فقط bridge پیش‌نیاز را تکرار کنید. اگر source را از روی شهرت یا تاریخ انتشار انتخاب می‌کنید، فقط authority + boundary و مثال shortcut را بازبینی کنید. اگر ضعف شما provenance است، بخش provenance و خطای AI-citation را ترمیم کنید. اگر freshness یا زمان بازبینی مشکل دارد، فقط بررسی‌های ۵ و ۶ و جدول source class را دوباره انجام دهید. سپس یک کارت را اصلاح کنید و ادامه دهید.
- Experienced / Fast Path — اگر claim را از evidence جدا می‌کنید و می‌توانید هر دوازده فیلد کارت را با boundary قابل‌دفاع بسازید، مدل مرکزی و جدول source class را سریع مرور کنید، worked caseها را مگر در صورت شکست یک فیلد کنار بگذارید و مستقیم سراغ تمرینِ sourceهای حل‌نشده و transfer با context تغییرکرده بروید. این مسیر توضیح را فشرده می‌کند؛ ambiguity یا evidence requirement را حذف نمی‌کند.
اگر route دیگر با evidence شما جور نیست، support را عوض کنید. شکست در یک فیلد یا rationale ضعیف می‌تواند Fast Path را به Repair هدفمند ببرد؛ یک Repair موفق می‌تواند شما را دوباره به transfer مستقل برگرداند. route بر اساس وضعیت evidence فعلی انتخاب می‌شود، نه برچسب‌زدن به فرد.
Evidence bar مشترک همه مسیرها: یک کارت کامل با authority متناسب با claim، provenance قابل‌ردگیری، boundary صریح، freshness/retrieval handling در موارد لازم، تصمیم ACCEPT/MODIFY/DEFER همراه rationale، evidence تغییر‌دهنده تصمیم، non-claim و یک transfer در context متفاوت که worked example را کپی نکند.
اصل مرکزی: «منبع معتبر» بدون محدوده معنا ندارد
هیچ منبعی برای همه نوع claim بهترین authority نیست. باید اول claim را محدود کنید و بعد ببینید کدام source class برای همان claim مناسب است.
برای مثال:
- برای وضعیت پشتیبانی یک نسخه، release schedule یا documentation رسمی همان پروژه معمولاً authority مستقیم‌تری از یک مقاله آموزشی است.
- برای رفتار یک API در یک نسخه مشخص، مستندات versioned و release notes به claim نزدیک‌ترند.
- برای یک workaround تجربی، issue tracker و reproduction می‌تواند evidence مفید بدهد، اما معمولاً claim باید باریک‌تر از «این روش همیشه درست است» نوشته شود.
- برای توصیه امنیتی، صرف اینکه یک tutorial هنوز اجرا می‌شود نشان نمی‌دهد توصیه آن هنوز امن یا پشتیبانی‌شده است.
بنابراین سؤال درست این نیست که «این سایت معتبر است؟» سؤال بهتر این است:
«این منبع، برای این claim مشخص، در این محدوده و در این زمان، چه چیزی را واقعاً پشتیبانی می‌کند؟»
مدل تصمیم: هفت بررسی قبل از ACCEPT
1. Claim را دقیق بنویس
جمله‌ای مثل «Node جدیدتر بهتر است» بیش از حد مبهم است. «نسخه X در تاریخ Y چه release statusی دارد؟» claim محدودتری است و می‌توان برای آن source مناسب پیدا کرد.
2. Authority را با نوع claim تطبیق بده
Authority وابسته به موضوع claim است. یک مقاله خوب ممکن است برای توضیح مفهوم عالی باشد، ولی برای وضعیت پشتیبانی امروز یک runtime، release page رسمی معمولاً منبع مستقیم‌تری است.
3. Provenance را قابل‌ردگیری کن
اگر یک آموزش می‌گوید «طبق مستندات رسمی»، باید بتوانید به منبع اصلی برسید. screenshot بدون تاریخ، نقل‌قول بی‌لینک یا خلاصه AI provenance ضعیف‌تری دارد.
4. Claim Boundary را بنویس
منبع ممکن است فقط بخشی از ادعا را پشتیبانی کند. اگر source می‌گوید «نسخه X اکنون Current است»، از آن نمی‌توان خودکار نتیجه گرفت «پس بهترین گزینه برای production است».
5. Freshness را متناسب با claim ارزیابی کن
همه claimها با یک سرعت کهنه نمی‌شوند. یک تعریف پایه ممکن است مدت طولانی پایدار باشد؛ وضعیت پشتیبانی یک نسخه، قابلیت یک سرویس یا توصیه امنیتی می‌تواند سریع تغییر کند. به‌جای یک عدد ثابت برای همه چیز، trigger بازبینی را ثبت کنید.
6. retrieved_at و review trigger را ثبت کن
برای claim متغیر، فقط لینک کافی نیست. بنویسید چه زمانی منبع را دیده‌اید و چه زمانی یا با چه اتفاقی باید دوباره بررسی شود: release جدید، تغییر status، advisory امنیتی، تغییر نسخه هدف یا تناقض جدید.
7. تصمیم را ببند: ACCEPT، MODIFY یا DEFER
- ACCEPT: evidence فعلی، همان claim محدود را در همان boundary پشتیبانی می‌کند.
- MODIFY: منبع مفید است، اما claim بیش از حد گسترده، قدیمی یا بدصورت‌بندی شده؛ claim را محدود یا به‌روز کنید.
- DEFER: evidence کافی یا قابل‌ردگیری ندارید، یا منابع مناسب هنوز تناقض حل‌نشده دارند. فعلاً نتیجه قطعی ندهید.
DEFER یک شکست نیست؛ یک خروجی صادقانه برای زمانی است که evidence اجازه تصمیم معتبر نمی‌دهد.
Technical Claim Trust Card
برای هر claim مهم یک کارت جدا بسازید:
- Technical claim — جمله‌ای که واقعاً می‌خواهید ارزیابی کنید.
- Claim type — پایدار، version-specific، security-sensitive، provider/tool capability یا experimental/community.
- Authority/source — کدام منبع برای همین claim مناسب است؟
- Provenance — منبع اصلی کجاست و آیا قابل‌ردگیری است؟
- Claim boundary — source دقیقاً چه بخش از claim را پشتیبانی می‌کند؟
- Freshness state — پایدارتر است یا متغیر؟
- Retrieved at — چه زمانی بررسی شد؟
- Review due/trigger — چه زمان یا اتفاقی بازبینی لازم می‌کند؟
- Decision — ACCEPT / MODIFY / DEFER.
- Rationale — evidence و constraint اصلی چیست؟
- What would change the decision? — چه evidence جدیدی تصمیم را عوض می‌کند؟
- Non-claim — این کارت چه چیزی را اثبات نمی‌کند؟
Technical claim:
Claim type:
Authority/source:
Provenance:
Claim boundary:
Freshness state:
Retrieved at:
Review due/trigger:
Decision: ACCEPT / MODIFY / DEFER
Rationale:
Evidence that would change the decision:
Non-claim:چه source classی برای چه claimی؟
| نوع claim | منبع شروع مناسب | freshness check | خطر رایج |
|---|---|---|---|
| قاعده یا تعریف پایدار | spec یا مستندات رسمیِ versioned | وقتی target/spec عوض می‌شود یا تناقض معتبر پیدا می‌شود | تبدیل توضیح یک نسخه به قانون همیشگی |
| وضعیت نسخه / runtime / API | release page، versioned docs، changelog | retrieved_at را ثبت کن؛ قبل از استفاده مهم و بعد از تغییر release/status بازبینی کن | اعتماد به tutorial قدیمی چون هنوز اجرا می‌شود |
| توصیه امنیتی | advisory یا راهنمای امنیتیِ نگه‌داری‌شده برای همان محصول/نسخه | قبل از استفاده حساس و بعد از advisory/نسخه جدید | یکی‌گرفتن «کار می‌کند» با «هنوز امن است» |
| قابلیت یک ابزار یا سرویس | documentation/changelog رسمی همان provider | قبل از تصمیم وابسته به capability و بعد از update | استفاده از خلاصه AI یا پست ثانویه به‌عنوان authority نهایی |
| workaround جامعه | issue/reproduction + cross-check با منبع مستقیم‌تر | تا وقتی reproduction و boundary روشن است؛ در تغییر نسخه بازبینی | تعمیم یک workaround محلی به قاعده عمومی |
این جدول cadence ثابت جهانی نمی‌دهد. هدف این است که freshness را به نوع claim و trigger تغییر وصل کند.
مثال واقعی ۱: «جدیدترین نسخه پس بهترین production choice است»
فرض کنید یک آموزش می‌گوید:
Claim: «Node.js 26 چون جدیدترین major است، بهترین انتخاب برای production است.»
در بررسی منبع رسمی Node.js در 2026-09-05، v26 در وضعیت Current است، درحالی‌که v24 و v22 به‌عنوان LTS نمایش داده می‌شوند. همان release page می‌گوید production applicationها باید از releaseهای Active LTS یا Maintenance LTS استفاده کنند.
کارت مناسب:
- Authority/source: release page رسمی Node.js.
- Provenance: صفحه رسمی release status.
- Claim boundary: source از status نسخه‌ها و policy پشتیبانی می‌کند؛ «بهترین» بودن عمومی را ثابت نمی‌کند.
- Freshness: متغیر.
- Retrieved at: 2026-09-05.
- Review trigger: با تغییر release status، ورود major جدید به LTS یا قبل از انتخاب runtime برای production.
- Decision: MODIFY.
- نسخه محدودتر claim: «در 2026-09-05، v26 Current است؛ برای production باید وضعیت LTS را از release page رسمی بررسی کرد.»
- Non-claim: این کارت درباره performance یا suitability همه پروژه‌ها حکم کلی نمی‌دهد.
نکته مهم: «جدیدترین» یک fact ممکن است باشد، اما خودبه‌خود authority برای «بهترین production choice» نمی‌سازد.
مثال واقعی ۲: tutorialی که هنوز اجرا می‌شود ولی claim پشتیبانی‌اش قدیمی است
فرض کنید یک tutorial قدیمی می‌گوید:
Claim: «Node.js 20 یک خط پشتیبانی‌شده برای deployment جدید است.»
صفحه رسمی End-of-Life پروژه در بررسی 2026-09-05، Node.js 20 را EOL با آخرین به‌روزرسانی در 2026-03-24 نشان می‌دهد و توضیح می‌دهد که release line پس از EOL دیگر updateهای پروژه، از جمله security patchها، دریافت نمی‌کند.
Decision برای claim فعلی: MODIFY. ممکن است بخش‌هایی از tutorial هنوز برای syntax یا مفهوم مفید باشند، اما claim مربوط به پشتیبانی امروز باید به منبع جاری وصل و بازنویسی شود.
این مثال نشان می‌دهد «کد اجرا شد» evidence کافی برای «آموزش هنوز current است» نیست.
مثال ۳: claim بیش از حد گسترده درباره Python
فرض کنید یک آموزش می‌گوید:
Claim: «این رفتار در Python 3 وجود دارد.»
اما feature یا تغییر موردنظر version-specific است. مستندات رسمی Python مجموعه جداگانه‌ای از “What’s New” برای نسخه‌های مختلف دارد و تغییرات، deprecationها و removals را به تفکیک نسخه ثبت می‌کند.
اگر tutorial نسخه هدف را مشخص نکرده باشد، تصمیم خوب می‌تواند DEFER باشد تا target version روشن شود. سپس claim را به نسخه‌ای که source واقعاً پوشش می‌دهد محدود کنید.
یک shortcut که باید متوقف شود
«این مقاله دیروز منتشر شده، پس از مستندات دو سال قبل معتبرتر است.»
مشکل: publication date جای authority و claim match را گرفته است. یک مقاله تازه می‌تواند منبع قدیمی را تکرار کند یا claim را فراتر از source گسترش دهد. در مقابل، یک spec یا documentation versioned ممکن است دقیقاً authority همان claim باشد.
نسخه بهتر:
«اول claim را محدود می‌کنم، منبع مستقیم مناسب را پیدا می‌کنم، boundary را می‌نویسم، تاریخ بررسی و trigger بازبینی را ثبت می‌کنم؛ بعد تصمیم می‌گیرم.»
سه خطای رایج دیگر
«Official یعنی برای هر claim کافی است»
خیر. official بودن مهم است اما claim-specific بودن هم لازم است. release note برای release behavior عالی است؛ ممکن است برای benchmark مستقل یا trade-off پروژه شما کافی نباشد.
«AI citation داد، پس claim تأیید شده است»
خیر. AI می‌تواند source پیدا کند یا خلاصه کند، اما citation باید به منبع قابل‌بررسی برسد و claim boundary را خودتان با source تطبیق دهید.
«اگر آموزش هنوز کار می‌کند، پس current است»
خیر. بخشی از آموزش می‌تواند پایدار باشد و بخش دیگر، مخصوصاً version status یا security advice، قدیمی شده باشد. Trust Card باید claim را خرد کند تا این تفاوت دیده شود.
نقش AI در این کار
AI می‌تواند:
- claim را باریک‌تر پیشنهاد کند؛
- sourceهای متناقض را کنار هم بگذارد؛
- evidence ارائه‌شده را خلاصه کند؛
- از شما بپرسد چه چیزی تصمیم را تغییر می‌دهد.
اما AI نباید:
- تصمیم نهایی ACCEPT/MODIFY/DEFER را بدون دفاع شما ببندد؛
- پاسخ خودش را تنها مرجع صحت همان پاسخ قرار دهد؛
- source، تاریخ بازیابی یا تجربه‌ای را که وجود ندارد اختراع کند.
حداقل یک تصمیم مهم کارت باید بدون اینکه AI جواب را انتخاب کند، با source و boundary قابل دفاع باشد.
تمرین هدایت‌شده
این claim را بررسی کنید:
«یک blog جدید می‌گوید option مشخصی در نسخه فعلی یک ابزار default شده است؛ اما documentation versioned که برای نسخه هدف پیدا کرده‌اید چنین چیزی را نشان نمی‌دهد.»
پاسخ ضعیف: «blog جدیدتر است، پس ACCEPT.»
پاسخ قابل‌دفاع‌تر: DEFER تا زمانی که release notes یا documentation رسمی همان version روشن کند default واقعاً تغییر کرده یا نه. در کارت باید target version، sourceها، retrieved_at و evidence لازم برای تغییر تصمیم ثبت شود.
تمرین مستقل: یک claim واقعی را ارزیابی کن
یک claim فنی واقعی از یک tutorial، ویدئو، documentation، پاسخ forum یا پاسخ AI انتخاب کنید. claim باید آن‌قدر محدود باشد که بتوان آن را با source بررسی کرد.
یک Technical Claim Trust Card کامل بسازید و سپس:
- source class انتخابی را توجیه کنید؛
- claim boundary را در یک جمله بنویسید؛
- retrieved_at و review trigger را ثبت کنید؛
- ACCEPT، MODIFY یا DEFER را انتخاب کنید؛
- یک evidence مشخص بنویسید که می‌تواند تصمیم را عوض کند؛
- یک non-claim بنویسید؛
- همان روش را روی claim دوم با context متفاوت و scaffold کمتر اجرا کنید.
اگر فقط «معتبر/نامعتبر» نوشته‌اید یا لینک را بدون boundary و freshness ثبت کرده‌اید، evidence کامل نیست.
چک نهایی کارت
- آیا claim دقیق و محدود است؟
- آیا source برای همان نوع claim authority مناسبی دارد؟
- آیا provenance تا منبع اصلی قابل‌ردگیری است؟
- آیا boundary دقیقاً می‌گوید source چه چیزی را پشتیبانی نمی‌کند؟
- آیا claim متغیر retrieved_at دارد؟
- آیا review trigger واقعی و مرتبط با تغییر claim است؟
- آیا ACCEPT/MODIFY/DEFER از evidence می‌آید؟
- آیا می‌دانید چه evidenceای تصمیم را عوض می‌کند؟
- آیا یک non-claim دارید؟
- آیا می‌توانید روش را در context دوم بدون کپی example اجرا کنید؟
جمع‌بندی
قابل‌اعتماد بودن آموزش فنی یک ویژگی مطلق برای کل سایت یا کل آموزش نیست. Claim را محدود کنید، authority مناسب همان claim را پیدا کنید، provenance و boundary را ثبت کنید، freshness را با retrieved_at و review trigger کنترل کنید و بعد تصمیم ACCEPT/MODIFY/DEFER بگیرید.
خروجی این درس Technical Claim Trust Card است؛ یک artifact کوچک که نشان می‌دهد چرا امروز به یک claim تکیه می‌کنید، چه چیزی را هنوز نمی‌دانید و چه اتفاقی باید شما را وادار به بازبینی کند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
Q2 application
Q3 diagnosis
Q4 decision
Q5 transfer
ملاک‌های ارزیابی (rubric)
All critical dimensions must be satisfied for blocking assessment acceptance.
Decision/scope correctness
- Critical: YES
- Sufficient evidence: Decision matches one bounded technical claim and does not become a verdict on an entire website/course.
Evidence adequacy
- Critical: YES
- Sufficient evidence: Authority, provenance, boundary, freshness and constraints are inspectable enough to support/change the decision.
Non-claim honesty
- Critical: YES
- Sufficient evidence: The learner states what the card does not prove.
Transfer
- Critical: YES
- Sufficient evidence: The method is adapted to a changed claim/source context rather than copied.
Global failure conditions
- required decision without evidence
- scope inflation
- volatile claim without retrieval/review handling
- non-goal erased
- transfer is surface-copy
AI boundary
AI may suggest narrower claims, surface contradictions, summarize provided evidence, or critique. It may not choose the final ACCEPT/MODIFY/DEFER result for the learner, serve as the sole judge of its own answer, or invent sources/retrieval dates/evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)