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

توسعه‌دهنده‌ای که با Cursor یا Claude Code کار می‌کند، معمولاً مستقیم شروع به نوشتن کد می‌کند — بدون اینکه اول بگوید دقیقاً روی کدام تسک کار می‌کند. نتیجه قابل پیش‌بینی است: دستیار زمینهٔ درست را نمی‌بیند، معیار پذیرش را حدس می‌زند، و بعد از یک ساعت کار معلوم می‌شود مسیر اشتباه رفته. مشکل ابزار AI نیست؛ مشکل نبودِ یک نقطهٔ شروع و پایان روشن برای هر واحد کار است.

start_work و end_work دقیقاً همین نقطه‌ها را در WKFGo تعریف می‌کنند. این دو ابزار MCP، کار روی یک تسک را با یک شروع مشخص (بارگذاری زمینه) و یک پایان مشخص (ثبت ساعت و آمادگی برای بازبینی) کادربندی می‌کنند — چه کار را یک انسان انجام دهد و چه یک دستیار متصل از طریق IDE.

علائم نبود این حلقه

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

حلقهٔ عملی: شش قدم از انتخاب تا بازبینی

یک تسک را از صف انتخاب کنید. چه از my_queue در بوردِ WKFGo و چه از داخل IDE، تمرکز روی یک واحد کار فعال است — نه چند تسک باز همزمان.
کار را با start_work(taskId) شروع کنید. این ابزار وضعیت تسک را به «در حال انجام» می‌برد و از طریق get_context_pack معیار پذیرش، وابستگی‌ها و صفحات ویکی مرتبط را در یک پاسخ برمی‌گرداند — دستیار AI به‌جای حدس‌زدن، همان زمینه‌ای را می‌بیند که یک همکار انسانی در ابتدای کار می‌بیند.
کامیت را به شناسهٔ تسک وصل کنید. پیام کامیت با الگوی TASK-<id> باعث می‌شود گزارش تحویل خودش پر شود و بعداً بتوان هر تغییر کد را به تسک اصلی برگرداند (این همان رویکردی است که در شاخه به ازای هر تسک و وصل کردن کامیت گیت به تسک توضیح داده شده).
اگر کار نیاز به دروازهٔ کیفیت دارد، submit_for_review را صدا بزنید. این مرحله اختیاری است اما برای تغییرات حساس، مسئولیت بازبینی را از حدس‌وگمان چت خارج می‌کند و در صف تأیید رسمی ثبت می‌کند.
کار را با end_work ببندید و log_time را بزنید. ساعت واقعی کار — نه ساعت برنامه‌ریزی‌شده — ثبت می‌شود؛ همین عدد صادقانه است که برآورد اسپرینت بعدی را می‌سازد.
در بازبینی هفتگی، اختلاف برنامه و واقعیت را نگاه کنید. اگر یک تسک همیشه دو برابر زمان تخمینی طول می‌کشد، مشکل از فرد نیست؛ برآورد باید کالیبره شود.

اشتباهات رایج

باز گذاشتن چند تسک همزمان بدون start_work — دستیار AI و انسان هر دو زمینهٔ اشتباه می‌گیرند.
کامیت بدون شناسهٔ تسک — گزارش تحویل بعداً باید دستی بازسازی شود.
رد شدن از submit_for_review برای «صرفه‌جویی در وقت» — همان جایی است که خطاهای پرهزینه دیر کشف می‌شوند.
ثبت ساعت گرد‌شده به‌جای واقعی — برآورد بعدی روی داده غلط بنا می‌شود.
استفاده از گزارش ساعت برای قضاوت فردی — هدف کالیبراسیون برنامه‌ریزی است، نه امتیازدهی به افراد.

نقش WKFGo، صادقانه

این حلقه با یا بدون دستیار AI کار می‌کند — start_work و end_work برای هر عضو تیم که از رابط وب استفاده می‌کند هم در دسترس است. تفاوت وقتی برجسته می‌شود که یک IDE یا CLI متصل به MCP وارد می‌شود: چون get_context_pack همان زمینه‌ای را که یک انسان از ویکی و تسک می‌خواند، در یک فراخوانی به دستیار می‌دهد، نیازی نیست کسی دستی توضیح تسک را کپی‌پیست کند. اگر تیم شما اصلاً از دستیار AI متصل استفاده نمی‌کند، همین شش قدم فقط با ثبت ساعت و انضباط کامیت هم ارزش خودش را دارد.

پرسش‌های متداول

اگر کار وسط راه با یک درخواست فوری قطع شود چه؟ end_work را با یادداشت جزئی بزنید و روی تسک فوری start_work جدید را شروع کنید — ساعت هرکدام جدا ثبت می‌شود، نه ترکیبی و گمراه‌کننده.

در برنامه‌نویسی زوجی چطور ثبت کنیم؟ هر دو نفر می‌توانند جدا ثبت کنند یا ساعت را طبق سیاست تیم تقسیم کنند؛ نکتهٔ مهم این است که قاعده از قبل روشن باشد، نه ابداع لحظه‌ای.

آیا این یعنی مدیر روی هر کلیک نظارت می‌کند؟ نه — ثبت ساعت در سطح تسک است، نه ردیابی کیبورد. هدف برآورد بهتر است، نه نظارت لحظه‌ای.

برای تیم دورکار و ناهم‌زمان هم کار می‌کند؟ بله — چون حلقه بر پایهٔ وضعیت تسک است نه حضور همزمان، برای تیم‌های ناهم‌زمان با کمی انضباط ثبت به همان اندازه قابل اجراست.