هدایت کارگران پس‌زمینه

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

هنگام تایپ /vibe چه چیزی تغییر می‌کند

دو چیز، و فقط اولی را سازوکار اعمال می‌کند:

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

مورد اول همان است که بار را بر دوش می‌کشد. هدایتگری که هنوز می‌تواند grep کند و ویرایش کند، زیر فشار خودش کار را انجام می‌دهد و این همان حالت شکستی است که این ویژگی برای جلوگیری از آن وجود دارد.

/vibe migrate the auth module to the new session API

کارگرها خالی شروع می‌کنند

یک کارگر هرگز گفتگوی شما را ندیده است و نخواهد دید. بریف تمام بافت اوست.

همین است که این الگو را ارزان نگه می‌دارد — بیست کارگر که هرکدام تاریخچهٔ هدایتگر را نگه دارند، بیست برابر بافت هدایتگر هزینه می‌داشت — و همچنین همان چیزی است که نوشتن بریف را دشوار می‌کند. «حالا آن یکی را هم انجام بده» برای هدایتگر یک دستور کامل خوانده می‌شود و برای یک نشست تازه هیچ.

یک بریف خوب فایل‌ها، فرمان‌ها و تعریف «تمام‌شده» را نام می‌برد:

در lib/features/auth/، هر فراخوانی SessionStore.read(key) را با SessionStore.get(key) جایگزین کن. متد جدید Future<String?> برمی‌گرداند در حالی که متد قدیمی String? برمی‌گرداند، پس فراخوان‌ها به await نیاز دارند. وقتی کارت تمام شد fvm flutter analyze lib/features/auth را اجرا کن و هر خطایی را که نتوانستی رفع کنی گزارش بده.

پنج فعل

فعل	کار آن
vibe_spawn	یک کارگر را روی یک بریف راه‌اندازی می‌کند. بی‌درنگ برمی‌گردد.
vibe_list	رده، وضعیت، زمان سپری‌شده و آخرین نتیجه برای همه
vibe_send	یک نوبت پیگیری برای کارگری که کارش تمام شده است
vibe_wait	تا پایان یافتن یک کارگر مسدود می‌ماند
vibe_kill	یکی را متوقف می‌کند

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

دو رده

رده	برای
fast	کار مکانیکی با مشخصات روشن — ویرایش‌ها، تغییر نام‌ها، پیش‌نویس‌ها، اجرای فرمان‌ها
good	طراحی، قضاوت، یا بازبینی چیزی که یک کارگر fast تولید کرده است

شکل رایج این است که کارگرهای fast را روی فایل‌های مستقل پخش کنید و سپس یک کارگر good راه‌اندازی کنید تا کاری را که مجموعاً کرده‌اند بازبینی کند.

راستی‌آزمایی

این همان بخشی است که تعیین می‌کند این الگو به چه کاری می‌آید یا نه.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

سپس فایل‌هایی را که نام برده است بخوانید. هدایتگر read، search، lsp و ast_grep را دارد؛ همین کل دلیل نگه‌داشتن آن‌هاست. هدایتگری که گزارش را بی‌چون‌وچرا بپذیرد، خلاصه‌کنندهٔ خوش‌بینی سایر عامل‌هاست.

lsp(action: "diagnostics", file: "*") پس از یک دور کارگرها معمولاً سریع‌ترین بررسی تک‌گامی است.

وقتی کارگری رشتهٔ کار را از دست می‌دهد

بکشیدش و از نو بریف بدهید. یک بریف تازه و اصلاح‌شده از یک جدل ارزان‌تر است و vibe_send فقط روی کارگری کار می‌کند که نوبتش را تمام کرده باشد.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

محدودیت‌ها

• هشت کارگر هم‌زمان. سقفی بر هزینه، نه یک محدودیت فنی: هرکدام یک نشست کامل مدل است و هدایتگری که بیست کارگر پخش کند، دیگر رد کار همهٔ آن‌ها را دنبال نمی‌کند.
• هیچ کارگری از حالت بیشتر زنده نمی‌ماند. وقتی اجرا تمام می‌شود، همهٔ آن‌ها متوقف می‌شوند و رونوشت می‌گوید چند تا بودند. عاملی پس‌زمینه‌ای که پس از گذشتن گفتگو هنوز در حال ویرایش فایل‌ها باشد، همان شکستی است که این ویژگی نمی‌تواند داشته باشد.
• کارگرها در زیر پوست، زیرعامل‌های معمولی‌اند. همان سقف عمق، همان سیاست گاردریل، همان فرزندِ لاگ اجرا. Vibe عوض می‌کند چه کسی آن‌ها را می‌راند، نه اینکه مجاز به چه کاری‌اند — پس پرامپت‌های تأیید همچنان برای فراخوانی‌های نوشتن و اجرای یک کارگر ظاهر می‌شوند.

چه زمانی از آن استفاده نکنید

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

مرتبط

• اجرای موازی عامل‌ها — دیگر راه‌های پخش کردن
• ارکستراسیون — وقتی کار شکل دارد
• ابزارهای داخلی عامل — فعل‌ها و آرگومان‌هایشان