بازگشت به مهندسی مدرن و کار با هوش مصنوعی · فصل صفر — جای خودت را در مسیر پیدا کن · 5

چطور مسیر یادگیری برنامه‌نویسی را بر اساس سطح خودمان شخصی کنیم؟

مسیر یکسان را برای همه مناسب می‌داند و تفاوت بین scaffolding و استاندارد خروجی را تفکیک نمی‌کند. می‌تواند بین مسیر پایه، repair و fast path انتخاب کند و بداند همه به یک evidence bar می‌رسند.

خلاصهٔ درس

مسیر یکسان را برای همه مناسب می‌داند و تفاوت بین scaffolding و استاندارد خروجی را تفکیک نمی‌کند.

می‌تواند بین مسیر پایه، repair و fast path انتخاب کند و بداند همه به یک evidence bar می‌رسند.

خروجی این درس

می‌تواند بین مسیر پایه، repair و fast path انتخاب کند و بداند همه به یک evidence bar می‌رسند.

پیش‌نیازها

ORI-001

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

هدف این درس رتبه‌بندی شما نیست. قرار است برای یک مهارت یا خروجی محدود، با شواهد قابل‌بررسی تصمیم بگیرید کدام مسیر آموزشی مناسب‌تر است: Foundation، Repair یا Experienced/Fast Path. چیزی که تغییر می‌کند مقدار و نوع حمایت است؛ چیزی که تغییر نمی‌کند معیار نهایی evidence است.

در پایان یک Route Selection Card می‌سازید و از تصمیم خود دفاع می‌کنید. این کارت باید نشان دهد چه شواهدی دارید، چه چیزی هنوز نامطمئن است، چرا یک مسیر را انتخاب کرده‌اید، چه چیزی می‌تواند تصمیم را عوض کند، و این تصمیم چه چیزی را اثبات نمی‌کند.

این درس تسلط فنی برنامه‌نویسی، آمادگی شغلی یا «سطح کلی» شما را اثبات نمی‌کند. فقط توانایی انتخاب یک مسیر یادگیری محدود بر اساس evidence را تمرین می‌کند.

اصل مرکزی: مسیر با استاندارد خروجی یکی نیست

سه مسیر را مثل سه روش رسیدن به یک مقصد ببینید، نه سه مقصد با کیفیت متفاوت.

Foundation زمانی مناسب است که شواهد کافی برای انجام مستقلِ خروجی محدود ندارید یا مدل ذهنی پایه هنوز شکننده است. توضیح، مثال حل‌شده و تمرین هدایت‌شده بیشتر می‌شود.
Repair زمانی مناسب است که بخش عمده خروجی را می‌توانید انجام دهید، اما یک شکاف یا برداشت نادرست مشخص مانع شماست. به‌جای تکرار کل درس، فقط همان نقطه هدف قرار می‌گیرد.
Experienced/Fast Path زمانی مناسب است که برای همان خروجی محدود evidence قوی دارید. توضیح فشرده‌تر می‌شود و زودتر وارد ابهام، تصمیم و انتقال می‌شوید. اما evidence و ارزیابی حذف نمی‌شود.

مسیر	چه چیزی تغییر می‌کند؟	چه چیزی ثابت می‌ماند؟
Foundation	واژگان صریح، مثال حل‌شده، راهنمایی بیشتر	همان خروجی محدود و همان معیار نهایی evidence
Repair	ترمیم هدفمند یک برداشت نادرست یا شکاف	همان خروجی محدود و همان معیار نهایی evidence
Experienced/Fast Path	توضیح کمتر، ابهام و انتقال بیشتر	همان خروجی محدود و همان معیار نهایی evidence

اگر دو نفر مسیر متفاوت دارند، این به معنی آسان‌تر بودن استاندارد برای یکی از آن‌ها نیست. تفاوت در حمایت آموزشی است، نه در کیفیت evidence نهایی.

به‌جای «من چه سطحی هستم؟» این سؤال را بپرسید

سؤال ضعیف:

«من مبتدی‌ام یا حرفه‌ای؟»

سؤال بهتر:

«برای این مهارت مشخص، الان چه evidence قابل‌بررسی دارم و کدام نوع حمایت باعث می‌شود با کمترین اتلاف به همان معیار نهایی evidence برسم؟»

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

قبل از انتخاب مسیر، evidence پیش‌نیاز را بررسی کنید

یک ایدهٔ جهت‌دهنده از قبل برای این تصمیم لازم است: ادعای یادگیری باید به چیزی وصل باشد که بتوان آن را دید، بررسی کرد یا انجام داد؛ صرفِ ترتیب درس‌ها evidence نیست. رسیدن به این درس، آشنا بودن با موضوع یا به‌یاد آوردن یک توضیح قبلی به‌تنهایی پیش‌نیاز را نمی‌بندد.

قبل از نهایی‌کردن route این probe کوتاه را انجام دهید:

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

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

اگر شکننده است، به‌جای حدس‌زدن route یک bridge هدفمند انجام دهید: یک خروجی کوچک در اندازهٔ پروژه انتخاب کنید، یک artifact یا تصمیم حل‌شده را بررسی کنید، سپس برای همان خروجی یک artifact فعلیِ معادل بسازید یا بررسی کنید و probe را دوباره اجرا کنید. evidence معادل و فعلی می‌تواند بدون تکرار کامل درس قبلی پیش‌نیاز را ببندد. اگر هنوز evidence برای دفاع از یک route کافی نیست، از defer محدود استفاده کنید.

دروازهٔ آمادگی برای مبتدی مطلق — قبل از اولین Lab کدنویسی

Foundation به معنی «کمک بیشتر برای همان مهارت» است، اما به‌تنهایی تضمین نمی‌کند که syntax پایهٔ برنامه‌نویسی را از صفر بلد هستید. بنابراین اگر هنوز هیچ برنامهٔ کوچکی را نخوانده، اجرا نکرده و تغییر نداده‌اید، این probe را قبل از نهایی‌کردن route انجام دهید. این probe آزمون رتبه‌بندی نیست؛ فقط مشخص می‌کند آیا قبل از اولین Lab اجرایی به یک bridge کوتاه نیاز دارید یا نه.

کد زیر را فقط بخوانید؛ لازم نیست syntax را از قبل حفظ باشید:

def open_tasks(tasks):
    result = []
    for task in tasks:
        if task["completed"] is False:
            result.append(task)
    return result

پنج سؤال آمادگی:

آیا می‌توانید توضیح دهید tasks ورودی تابع است و result یک نام محلی برای نگه‌داشتن نتیجه است؟
آیا می‌توانید حدس بزنید شرط completed is False کدام رکوردها را نگه می‌دارد؟
آیا تفاوت «فایل کد»، «فایل داده» و «مقداری که هنگام اجرا در حافظه است» را در حد یک جمله می‌دانید؟
آیا می‌توانید یک command آماده را در پوشهٔ درست اجرا کنید و خروجی PASS/FAIL یا traceback را پیدا کنید؟
اگر یک test بگوید expected [1, 3] ولی actual [1, 2, 3]، آیا می‌توانید بگویید رفتار فعلی با انتظار تست فرق دارد، حتی اگر هنوز repair را بلد نباشید؟

اگر ۴ یا ۵ مورد برایتان روشن است: route را با evidence همان مهارت انتخاب کنید؛ این gate مانع Fast Path یا Repair نیست.

اگر ۲ یا ۳ مورد روشن است: برای مهارت‌های کدنویسی اولیه Foundation مناسب‌تر است. قبل از اولین اجرای مستقل، bridge داخل FND-003 را بخوانید و probe آن را انجام دهید.

اگر ۰ یا ۱ مورد روشن است: این یک شکست نیست و استاندارد نهایی را پایین نمی‌آورد. شما در وضعیت Absolute-Beginner Bridge Required هستید: هنگام رسیدن به FND-003، بخش «پل خواندن و اجرای برنامه» را کامل انجام دهید، سپس همین پنج توانایی را دوباره بررسی کنید. بعد از bridge همان evidence bar عادی دوره برقرار است.

این readiness gate دربارهٔ «استعداد»، آمادگی شغلی یا سطح کلی شما ادعا نمی‌کند. فقط یک hidden prerequisite را آشکار می‌کند: قبل از Lab کدنویسی باید بتوانید یک برنامهٔ کوچک را بخوانید، اجرا کنید، failure را پیدا کنید و یک تغییر محدود را دوباره آزمایش کنید.

وقتی evidence کافی نیست: defer محدود

Defer مسیر چهارم نیست. یک خروج موقت است برای زمانی که evidence لازم برای تمایز بین Foundation، Repair و Experienced/Fast Path وجود ندارد، با هم تناقض دارد یا آن‌قدر قدیمی است که تصمیم قابل دفاع نمی‌سازد.

یک defer قابل دفاع باید ثبت کند:

دقیقاً کدام evidence گم یا نامطمئن است؛
کوچک‌ترین probe، artifact یا تلاش در context تغییر‌یافته‌ای که آن را فراهم می‌کند؛
چه evidenceای تصمیم route را دوباره باز می‌کند و می‌بندد؛
یک non-claim درباره چیزی که defer اثبات نمی‌کند.

وقتی این evidence فراهم شد، یکی از سه route را انتخاب کنید. defer نباید برای حذف evidence، عقب‌انداختن نامحدود تصمیم یا پایین‌آوردن evidence bar نهایی استفاده شود.

Route Selection Card

برای هر مهارت یا خروجی مهم، یک کارت جدا بسازید:

مهارت / خروجی محدود — دقیقاً چه چیزی قرار است انجام شود؟
Evidence فعلی — چه خروجی قابل‌بررسی، توضیح، تصمیم یا اجرای مستقلی نشان می‌دهد اکنون چه می‌توانید بکنید؟
شکنندگی / محدودیت — کجا evidence ضعیف، قدیمی، ناقص یا وابسته به راهنمایی است؟
تصمیم route — Foundation، Repair یا Experienced/Fast Path؟
حمایت موردنیاز — چه نوع حمایتی لازم است و چه حمایتی اضافی است؟
معیار نهایی evidence — در پایان چه evidenceای برای همه مسیرها لازم است؟
چه چیزی route را تغییر می‌دهد؟ — چه evidence جدیدی تصمیم شما را عوض می‌کند؟
Non-claim — این تصمیم چه چیزی را درباره شما یا مهارتتان اثبات نمی‌کند؟

قالب کوتاه کارت

مهارت / خروجی محدود:
Evidence فعلی:
شکنندگی / محدودیت:
Route انتخاب‌شده:
حمایت موردنیاز:
معیار نهایی evidence:
Evidenceای که route را تغییر می‌دهد:
Non-claim:

مثال حل‌شده: یک مهارت، سه وضعیت evidence

فرض کنید خروجی محدود این است: «در یک تمرین برنامه‌نویسی، راه‌حل مستقل بساز، تصمیم اصلی را توضیح بده و آن را در یک صورت‌مسئله تغییر‌یافته تطبیق بده.» خود این درس درباره درست یا غلط بودن راه‌حل فنی حکم نمی‌دهد؛ تمرکز ما فقط روی انتخاب مسیر است.

وضعیت A — Foundation

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

تصمیم: Foundation.

دلیل: evidence استقلال هنوز کافی نیست. حمایت مناسب شامل مدل روشن، یک مثال حل‌شده و سپس تمرین هدایت‌شده است.

چیزی که مسیر را تغییر می‌دهد: اگر یادگیرنده در یک مسئله جدید، بدون راهنمای مرحله‌ای خروجی قابل‌بررسی کامل بسازد و دلیل تصمیمش را توضیح دهد، دیگر Foundation لزوماً بهترین مسیر نیست.

Non-claim: این انتخاب نمی‌گوید یادگیرنده «ضعیف» است یا در همه موضوعات مبتدی است.

وضعیت B — Repair

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

تصمیم: Repair.

دلیل: تکرار کامل درس هزینه اضافی دارد؛ مسئله، یک شکاف محدود و تشخیص‌پذیر است.

چیزی که مسیر را تغییر می‌دهد: وقتی همان محدودیت در دو موقعیت متفاوت درست مدیریت شود و توضیح تصمیم مستقل باشد، Repair می‌تواند بسته شود.

Non-claim: Repair به معنی پایین‌تر بودن استاندارد نیست؛ فقط نقطه مداخله باریک‌تر است.

وضعیت C — Experienced/Fast Path

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

تصمیم: Experienced/Fast Path.

دلیل: توضیح مقدماتی بیشتر ارزش کمی دارد؛ بهتر است سریع‌تر وارد حالت مرزی، موازنه و انتقال شود.

چیزی که مسیر را تغییر می‌دهد: اگر evidence جدید نشان دهد بخشی از خروجی به الگو یا حفظ‌کردن وابسته است، مسیر باید به Repair یا Foundation برگردد.

Non-claim: سابقه یا یک اجرای موفق مجوز حذف evidence نهایی نیست.

یک تصمیم ظاهراً منطقی که غلط است

«من سه سال سابقه برنامه‌نویسی دارم، پس برای همه درس‌ها Fast Path مناسب است.»

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

نسخه ترمیم‌شده:

«برای این خروجی محدود، دو خروجی قابل‌بررسی مستقل و یک انتقال موفق دارم. بنابراین Experienced/Fast Path را انتخاب می‌کنم. اگر در انتقال بعدی مشخص شود راه‌حل من به الگو وابسته است، مسیر را به Repair تغییر می‌دهم. این تصمیم درباره کل توانایی برنامه‌نویسی من ادعایی نمی‌کند.»

سه برداشت نادرست که باید متوقف شوند

1) «مبتدی باید استاندارد ساده‌تری داشته باشد»

خیر. Foundation حمایت بیشتری می‌دهد، اما مقصد را پایین نمی‌آورد. اگر معیار نهایی evidence برای یک خروجی محدود مشخص است، همه مسیرها باید به همان معیار برسند.

2) «باتجربه می‌تواند ارزیابی را رد کند»

خیر. Experienced/Fast Path می‌تواند توضیح و تمرین تکراری را فشرده کند، اما evidence نهایی را حذف نمی‌کند. تجربه زمانی ارزش مسیردهی دارد که به evidence مرتبط با همان خروجی محدود وصل باشد.

3) «یک سطح برای کل فرد کافی است»

خیر. مسیردهی باید محلی باشد. ممکن است برای یک مهارت Experienced/Fast Path، برای مهارت دوم Repair و برای مهارت سوم Foundation باشید. این تناقض نیست؛ نتیجه اندازه‌گیری دقیق‌تر است.

چه evidenceای برای مسیردهی مفید است؟

Evidence خوب باید به همان ادعایی وصل باشد که می‌خواهید درباره‌اش تصمیم بگیرید. مثال‌ها:

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

Evidence ضعیف برای تصمیم نهایی:

«قبلاً این درس را دیده‌ام»؛
«این عنوان برایم آشناست»؛
«چند سال سابقه دارم»؛
«AI گفت جوابم درست است» بدون یک مرجع مستقل برای بررسی صحت یا قضاوت انسانی لازم.

نقش AI در این تصمیم

AI می‌تواند گزینه‌ها را پیشنهاد کند، از شما مثال نقض بخواهد، evidence داده‌شده را خلاصه کند یا استدلالتان را نقد کند. اما نباید:

تصمیم نهایی مسیر را به‌جای شما بگیرد؛
خودش هم پاسخ را تولید کند و هم تنها مرجع تشخیص درستی همان پاسخ باشد؛
سابقه، خروجی قابل‌بررسی یا evidenceای را که ارائه نکرده‌اید اختراع کند.

حداقل یک تصمیم مهم در Route Selection Card باید بدون اینکه AI جواب را انتخاب کند، قابل دفاع باشد.

تمرین هدایت‌شده

خروجی محدود زیر را در نظر بگیرید:

«یک راه‌حل مستقل تولید کن، تصمیم اصلی را توضیح بده و در یک تغییر کوچکِ صورت‌مسئله همان روش را تطبیق بده.»

Evidence فرضی:

خروجی قابل‌بررسی اصلی مستقل ساخته شده است؛
توضیح تصمیم قابل‌فهم است؛
در تغییر صورت‌مسئله، یادگیرنده دوباره به الگو قبلی برمی‌گردد و تطبیق انجام نمی‌دهد.

Route مناسب چیست؟

پاسخ خوب فقط نام route را نمی‌گوید. باید مشخص کند کدام evidence تصمیم را پشتیبانی می‌کند و چه evidence جدیدی مسیر را تغییر می‌دهد.

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

تمرین مستقل: سه وضعیت evidence بساز

یک مهارت برنامه‌نویسی انتخاب کن. برای همان مهارت سه وضعیت متفاوت بساز:

یک وضعیت که Foundation را توجیه کند؛
یک وضعیت که Repair را توجیه کند؛
یک وضعیت که Experienced/Fast Path را توجیه کند.

برای هر سه وضعیت، معیار نهایی evidence را یکسان نگه دار. سپس برای هر وضعیت این چهار مورد را بنویس:

evidence فعلی؛
route و دلیل؛
evidenceای که route را تغییر می‌دهد؛
یک non-claim.

اگر فقط نام routeها عوض شده ولی evidence و آستانه‌ها تغییر نکرده‌اند، تمرین کامل نشده است.

خودآزمایی قبل از تصمیم نهایی

Route Selection Card شما زمانی قابل دفاع‌تر است که بتوانید به این سؤال‌ها پاسخ روشن بدهید:

آیا مهارت/خروجی محدود به‌اندازه کافی محدود شده است؟
آیا تصمیم از evidence می‌آید یا از برچسب شخصی و سابقه؟
آیا دقیقاً می‌دانید چه چیزی route را عوض می‌کند؟
آیا حمایت را با معیار نهایی evidence اشتباه نگرفته‌اید؟
آیا حداقل یک محدودیت یا non-claim نوشته‌اید؟
آیا می‌توانید همین منطق را در یک موقعیت جدید بدون کپی‌کردن مثال اجرا کنید؟

جمع‌بندی تصمیمی

شخصی‌سازی مسیر یعنی کم یا زیاد کردن هوشمند حمایت بر اساس evidence یک مهارت محدود. Foundation، Repair و Experienced/Fast Path سه کیفیت متفاوت نیستند؛ سه راه برای رسیدن به یک معیار نهایی evidence مشترک‌اند. اگر تصمیم شما فقط به «من مبتدی‌ام»، «من باتجربه‌ام» یا «قبلاً این را دیده‌ام» تکیه دارد، هنوز مبتنی بر evidence نیست.

خروجی این درس باید یک Route Selection Card باشد که تصمیم، evidence، محدودیت، شرط تغییر مسیر و non-claim را شفاف کند. همین ساختار است که اجازه می‌دهد مسیر سریع‌تر یا حمایتی‌تر شود بدون اینکه استاندارد نهایی پایین بیاید.

ارزیابی

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

Q1 retrieval

lesson ✗AI ✗notes ✗

Q2 application

lesson ✗AI ✗notes ✗

Q3 diagnosis

lesson ✗AI ✗notes ✗

Q4 decision

lesson ✗AI ✗notes ✗

Q5 transfer

lesson ✗AI ✗notes ✗

ملاک‌های ارزیابی (rubric)

Critical dimensions

1. Decision/scope correctness — critical

Decision matches a bounded outcome and does not become a global learner label.

2. Evidence adequacy — critical

Evidence or constraint supporting/changing the route is explicit.

3. Non-claim honesty — critical

At least one thing the decision does not prove is explicit.

4. Transfer — critical

Method is adapted in a changed context rather than copied.

Blocking failure conditions

decision without evidence
global self-label replaces skill evidence
final evidence bar changes by route
non-claim missing
transfer is surface-copy
complete artifact missing support_to_use
complete artifact missing final_evidence_bar
defer treated as a fourth route

Human decision policy

AI may suggest options, counterexamples, or critique; it may not make the final route decision, act as the sole judge of its own answer, or invent learner evidence.