กำกับวอร์กเกอร์พื้นหลัง

คู่มือนี้แสดงวิธีดำเนินบทสนทนาในบทบาท ผู้กำกับ แทนที่จะเป็นผู้ลงมือทำเอง โดยเซสชันจะเป็นฝ่ายอ่านและตรวจสอบ ส่วนเอเจนต์พื้นหลังเป็นฝ่ายลงมือแก้ไข

เกิดอะไรขึ้นเมื่อคุณพิมพ์ /vibe

มีสองอย่างเกิดขึ้น และมีเพียงอย่างแรกที่กลไกบังคับใช้จริง:

1. เครื่องมือของเซสชันเองลดลงเหลือแบบอ่านอย่างเดียว บวกกับคำสั่งของวอร์กเกอร์อีกห้าคำสั่ง ทางเดียวที่มันจะส่งผลต่อรีโปได้คือผ่านวอร์กเกอร์ และทางเดียวที่มันจะรู้ว่าเกิดอะไรขึ้นคืออ่านไฟล์ที่วอร์กเกอร์แตะ
2. มันถูกสั่งให้ตรวจสอบด้วยการอ่าน ไม่ใช่ด้วยการเชื่อ รายงานของวอร์กเกอร์เป็นเพียงคำกล่าวอ้างว่ามันทำอะไร ไม่ใช่หลักฐานว่ามันได้ผล

อย่างแรกคือข้อที่รับน้ำหนักทั้งหมด ผู้กำกับที่ยัง 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 เปลี่ยนเพียงว่าใครเป็นคนขับพวกมัน ไม่ได้เปลี่ยนว่าพวกมันได้รับอนุญาตให้ทำอะไร — พรอมต์ขออนุมัติจึงยังคงปรากฏสำหรับการเรียกเขียนและการเรียก exec ของวอร์กเกอร์

เมื่อใดไม่ควรใช้

โหมด vibe เหมาะกับงานที่แยกออกเป็นบรีฟอิสระได้ หากขั้นถัดไปขึ้นอยู่กับเอาต์พุตของขั้นก่อนหน้า สิ่งที่คุณกำลังพูดถึงคือไปป์ไลน์ หรือการประสานงาน และทั้งสองอย่างแสดงความสัมพันธ์แบบพึ่งพากันได้อย่างถูกต้อง แทนที่จะให้ผู้กำกับจำลองมันขึ้นมาด้วย vibe_wait

ที่เกี่ยวข้อง

• รันเอเจนต์แบบขนาน — วิธีอื่น ๆ ในการกระจายงาน
• การประสานงาน — เมื่องานมีโครงสร้างที่ชัดเจน
• เครื่องมือเอเจนต์ในตัว — คำสั่งและอาร์กิวเมนต์ของมัน