چطور پروژه را برای ایجنت برش بزنیم؟ راهنمای عملی برش تسک

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

واکنش طبیعی این است: «مدل ضعیف است، مدل بهتری بگیرم.» مدل بهتر را می‌گیری و همان اتفاق دوباره می‌افتد.

مشکل از هوشش نیست. مشکل از اندازهٔ کاری است که جلویش گذاشته‌ای.

چرا کانتکست بزرگ‌تر جواب بهتر نمی‌دهد

این بخش خلاف انتظار است، چون تبلیغ‌ها همیشه روی بزرگ‌شدن پنجرهٔ کانتکست مانور می‌دهند. اما بین «چقدر می‌تواند بخواند» و «چقدر خوب کار می‌کند» رابطهٔ مستقیمی نیست.

سه دلیل مشخص دارد:

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

۲. مسیرهای غلطِ باورپذیر زیاد می‌شوند. پروژهٔ بزرگ یعنی ده راه‌حل ممکن که همه‌شان منطقی به نظر می‌رسند. مدل یکی را انتخاب می‌کند — نه لزوماً آن یکی که تو در ذهن داشتی.

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

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

برش خوب سه چیز دارد

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

۱. همین چند فایل — مرز بسته

فهرست فایل‌هایی که ایجنت اجازهٔ تغییرشان را دارد باید بسته باشد، نه باز. فرق «به این پوشه نگاه کن» با «این چهار فایل را عوض کن» فرق شب و روز است.

یک قاعدهٔ سرانگشتی: اگر فهرست فایل‌های قابل‌تغییر از حدود پنج‌تا بیشتر شد، برش را اشتباه زده‌ای. برگرد و کوچک‌ترش کن.

دقت کن که مرزِ خواندن با مرزِ نوشتن یکی نیست. ایجنت معمولاً باید چیزهای بیشتری بخواند تا چیز کمی بنویسد:

۲. همین یک هدف — یک نتیجهٔ قابل‌آزمون

اگر در توصیف تسک از کلمهٔ «و» استفاده کردی، احتمالاً دو تسک داری.

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

هدف باید طوری نوشته شود که بشود درست یا غلط بودنش را نشان داد، نه دربارهٔ آن بحث کرد. «کد را تمیزتر کن» هدف نیست. «این تابع را طوری بازنویسی کن که تست‌های موجود سبز بمانند و طول تابع زیر بیست خط برود» هدف است.

۳. همین‌جا تمام — شرط پایان اجراشدنی

هر برش باید یک شرط پایان داشته باشد که بشود اجرایش کرد، نه اینکه فقط ادعا شود.

بهترین شکلش یک دستور است:

npm test -- auth/login

وقتی شرط پایان یک دستور اجراشدنی است، سه چیز هم‌زمان درست می‌شود: ایجنت می‌داند کِی بایستد، خودش می‌تواند نتیجه‌اش را بررسی کند، و «انجام شد» دیگر یک جملهٔ مؤدبانه نیست بلکه یک مدرک است.

اگر برای برشی نمی‌توانی شرط پایان بنویسی، آن برش هنوز آماده نیست.

برش عمودی بزن، نه افقی

این تفکیک بیشترین تفاوت را در عمل ایجاد می‌کند.

برش افقی یعنی یک لایه را کامل بدهی: «همهٔ مدل‌های دیتابیس را بساز.» برش عمودی یعنی یک قابلیت باریک را از بالا تا پایین ببری: «فقط ثبت‌نام با ایمیل، از فرم تا دیتابیس، با یک تست.»

برش عمودی برای ایجنت بهتر است چون قابل‌تأیید است. وقتی یک قابلیت سرتاسر کار می‌کند، می‌شود اجرایش کرد و دید. برش افقی هیچ‌وقت به نقطه‌ای نمی‌رسد که بتوانی بگویی کار کرد یا نه — تا وقتی همهٔ لایه‌های دیگر هم ساخته نشوند.

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

دستور کار: یک تسک واقعی را چطور برش بزنیم

پنج قدم، به همین ترتیب:

۱. اول جملهٔ پایان را بنویس. قبل از هر چیز این جمله را کامل کن: «وقتی تمام شد، اگر ‪___‬ را اجرا کنم، ‪___‬ می‌بینم.» اگر نتوانستی پرش کنی، هنوز نمی‌دانی چه می‌خواهی.

۲. درز را پیدا کن. باریک‌ترین جایی که این تغییر در آن قابل‌مشاهده است کجاست؟ یک تست، یک اندپوینت، یک کامپوننت. آن نقطه، مرکز برش توست.

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

۴. قراردادها را اضافه کن، پیاده‌سازی‌ها را نه. هر تایپ، اینترفیس یا امضایی که برای درست‌نوشتن لازم است بده. کدِ داخل بقیهٔ توابع را نده — همان است که نویز می‌سازد.

۵. شرط پایان را به‌صورت دستور بنویس. همان چیزی که ایجنت باید اجرا کند تا ثابت کند کار تمام است.

پنج برشی که همیشه شکست می‌خورند

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

این کار را باید دستی انجام داد؟

بخشی‌اش نه. بخشی‌اش بله.

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

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

آیراکد همین مجموعه را برای پروژه‌های فارسی فراهم می‌کند — با حافظهٔ پایدار CogX که مرزها و تصمیم‌های پروژه را بین نشست‌ها نگه می‌دارد، و ابزارهایی که برش را از حدس‌زدن به یک کار تکرارپذیر تبدیل می‌کنند.

چک‌لیست برش

قبل از فرستادن تسک بعدی:

• فهرست فایل‌های قابل‌تغییر را نوشته‌ام و کمتر از پنج‌تاست؟
• هدف یک جمله است، بدون «و»؟
• شرط پایان یک دستور اجراشدنی است؟
• قراردادهای لازم را داده‌ام ولی پیاده‌سازی‌های بی‌ربط را نه؟
• برش عمودی است، یعنی سرتاسر قابل‌اجراست؟

هر «نه» یک برش نیمه‌کاره است.

جمع‌بندی

پروژه که بزرگ شد، ایجنت گم می‌شود — نه چون کم‌هوش است، چون مرز ندارد. کل پروژه را نده؛ برش بزن: همین چند فایل، همین یک هدف، همین‌جا تمام.

برشِ درست، جوابِ درست. همان ایجنت، این بار درون یک مرز.

---

شروع کن

آیراکد را نصب کن · مستندات شروع سریع · تعرفه‌ها

بیشتر بخوان

• هارنس چیست و بهترین هارنس‌های برنامه‌نویسی با هوش مصنوعی کدام‌اند؟
• ایجنت هوش مصنوعی چیست
• کدنویسی با هوش مصنوعی
• حافظهٔ بلندمدت هوش مصنوعی