ทุกครั้งที่ coding agent ทำงานหนึ่งชิ้นเสร็จ ช่องว่างเดิมก็เปิดขึ้นมาอีกครั้ง คุณได้ diff มาพร้อมกับคำว่า "done" ที่ดูสดใส แต่ไม่ได้รู้ว่า อะไรเปลี่ยนไป อะไรถูกข้าม อะไรถูกทดสอบ หรือ agent ยังไม่แน่ใจเรื่องอะไรบ้าง ดังนั้นคุณจึงต้องอ่าน diff ใหม่ รันเทสต์เองอีกครั้ง และถามคำถามที่ agent น่าจะตอบได้ตั้งแต่ตอนส่งงานคืน ใช้ agent สองตัว ต้นทุนก็เพิ่มเป็นเท่าตัว ปัญหาไม่ใช่ตัวงาน แต่คือการส่งต่อ (handoff) ต่างหาก: อะไรที่ส่งต่อระหว่างคนที่สั่งงานกับ agent ที่ลงมือทำ และอะไรที่ส่งกลับคืนมา
เทมเพลตการส่งต่องานของ coding agent คือโครงสร้างตายตัวที่กำหนดว่าอะไรบ้างที่งานหนึ่งต้องพกติดตัวเมื่อเปลี่ยนมือ: จากคนไปยัง agent ตอนมอบหมายงาน และจาก agent กลับมาหาคนตอนรีวิว แทนที่จะคิดรูปแบบการส่งต่อขึ้นมาใหม่ทุกครั้ง คุณก็กรอกฟิลด์เดิมทุกครั้ง agent รู้ว่า "เสร็จ" หมายถึงอะไรตั้งแต่ก่อนเริ่ม และคุณก็ได้สรุป หลักฐาน และคำถามค้างคาแบบเดียวกันทุกครั้งที่มันหยุด
บทความนี้จะพาไปดูเทมเพลตสองแบบที่ใช้งานได้จริง โดยใช้ Sharkly เป็นเวิร์กโฟลว์: เลเยอร์ที่อยู่เหนือ coding agent ของคุณ ซึ่งทำให้ context ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ มองเห็นได้ตลอดตั้งแต่คำขอจนถึงการปล่อยงาน คุณมี coding agent อยู่แล้ว Sharkly เปลี่ยนพวกมันให้เป็นทีม และเทมเพลตการส่งต่อคือสิ่งที่ทำให้ทุกการส่งต่อกลายเป็นบันทึก ไม่ใช่การเดา
เทมเพลตการส่งต่องานของ coding agent คืออะไร
เทมเพลตการส่งต่อคือเช็กลิสต์ที่ถูกทำให้เป็นโครงสร้าง มันตอบคำถามสามข้อที่ diff เปล่าๆ ไม่มีวันตอบได้: มีการสั่งอะไรไป เกิดอะไรขึ้น และตอนนี้ถึงตาของใคร เมื่อสามสิ่งนี้เดินทางไปด้วยกัน คนทำงานคนถัดไปก็อ่านบันทึกชุดเดียว แทนที่จะต้องประกอบขึ้นใหม่จากสามที่
มีการส่งต่อสองแบบที่ควรทำเป็นเทมเพลต เพราะมันไหลไปคนละทิศและพกของคนละอย่าง:
- การส่งต่อตอนมอบหมายงาน (จากคนหรือ Agent หัวหน้าถึง Agent): เป้าหมาย ขอบเขต และนิยามของคำว่าเสร็จ ที่ส่งต่อลงมาก่อนงานจะเริ่ม
- การส่งต่อตอนรีวิว (จาก Agent กลับมาหาคน): สิ่งที่เปลี่ยนแปลง หลักฐานว่ามันใช้ได้ และส่วนที่มนุษย์ยังต้องตัดสิน ที่ส่งขึ้นมาเมื่ืองานหยุด
การทำเทมเพลตทั้งสองแบบนี่แหละคือประเด็น ทีมส่วนใหญ่เขียนตั๋วงานแบบคร่าวๆ และไม่ทำเทมเพลตอะไรเลยตอนขากลับ การรีวิวทุกครั้งจึงเริ่มต้นเหมือนการสอบสวน การแก้ขากลับคือจุดที่ประหยัดเวลาได้จริง
โมเดลการดำเนินงานที่แฝงอยู่ในเทมเพลต
เทมเพลตจะดีได้เท่ากับโมเดลการดำเนินงานที่รองรับมัน คำกริยาสี่คำเป็นตัวกำหนดว่าใครเป็นเจ้าของแต่ละรอยต่อ: ใครมอบหมาย ใครลงมือ ใครรีวิว ใครอนุมัติ Agent ค้นคว้า ลงมือ ทดสอบ และรายงาน คนเป็นผู้กำหนดทิศทาง ให้อำนาจ และอนุมัติผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลพินิจของทีม
สัญญานี้เองที่ทำให้เทมเพลตสองแบบมีฟิลด์ต่างกัน Agent ไม่ควรต้องเดาว่าการอนุมัติหน้าตาเป็นอย่างไร เทมเพลตการมอบหมายงานจึงบังคับให้คนสั่งงานเขียนมันออกมา คนไม่ควรต้องเดาว่าไฟเขียวหมายถึงปลอดภัยหรือไม่ เทมเพลตการรีวิวจึงบังคับให้ Agent แสดงงานของตัวเอง นี่คือการส่งต่อตอนมอบหมายงานในรูปแบบที่คัดลอกวางได้:
## Assignment handoff
Task ID: SH-###
Goal: one sentence, in plain language
In scope: the specific files, endpoints, or behaviors to touch
Out of scope: what to leave alone (auth, billing, public contracts)
Definition of done:
- [ ] observable acceptance criterion 1
- [ ] observable acceptance criterion 2
Constraints: frameworks, patterns, or limits to respect
Assignee: the exact Agent that owns this
บรรทัด "out of scope" กับ "definition of done" นี่แหละที่ทำงานหนัก ถ้าไม่มี agent ก็จะปรับแต่งไปเพื่อให้ได้ diff ที่ผ่านการตรวจ ไม่ใช่เพื่อผลลัพธ์ที่คุณตั้งใจ ถ้ามี การตรวจรับก็ถูกเขียนไว้ก่อนที่โค้ดจะถูกเขียนขึ้นแม้แต่บรรทัดเดียว
การส่งต่อตอนรีวิว: อะไรที่ส่งกลับคืนมา
เทมเพลตขากลับคือสิ่งที่เวิร์กโฟลว์ส่วนใหญ่ข้ามไป และเป็นสิ่งที่ช่วยเซฟบ่ายของคุณไว้ เมื่อ Agent ทำงานเสร็จ มันไม่ควรทักคุณด้วยคำว่า "ready" พร้อมลิงก์หนึ่งอัน แต่ควรส่งคืนโครงสร้างที่กรอกครบแล้วกลับมา:
## Review handoff
Task ID: SH-###
Summary: what changed, in 2-3 sentences
Acceptance: each definition-of-done item, checked with how it was verified
Tests: typecheck / unit / build results, pasted or linked
Diff: the PR or worktree branch
Known limits: what this does NOT cover, and any risky assumption
Open questions: decisions left for a human
ฟิลด์ "known limits" กับ "open questions" คือสิ่งที่แยกการส่งต่อของจริงออกจากกำแพงเครื่องหมายถูกสีเขียว ข้อจำกัดที่ซื่อตรง ("ตัวนับ Redis สมมติว่าใช้โซนเดียว") เปลี่ยนการ merge แบบเดาสุ่มให้กลายเป็นการ merge ที่รู้ข้อมูลครบ นี่คือหลักการเดียวกับการรีวิวโค้ดที่ AI สร้างขึ้นด้วยหลักฐานระดับงาน: ผู้รีวิวอ่านคำกล่าวอ้างพร้อมหลักฐาน ไม่ใช่ diff พร้อมความหวัง
ขอบเขตหนึ่งที่ควรพูดให้ชัด: การส่งต่อตอนรีวิวไม่ใช่คำขอให้ merge แต่เป็นคำขอให้รีวิว Agent นำเสนอ คนเป็นคนตัดสิน การแยกสองการกระทำนี้ออกจากกันคือสิ่งที่หยุดไม่ให้งานที่ยังไม่ได้รีวิวถูกปล่อยออกไป
สถานะและด่านรีวิว: เทมเพลตอยู่ตรงไหน
เทมเพลตที่อยู่ในบัฟเฟอร์ scrollback คือเทมเพลตที่ไม่มีใครอ่าน การส่งต่อต้องถูกแนบไว้กับอะไรก็ตามที่แชร์กัน และสถานะก็เป็นที่อยู่ตามธรรมชาติของมัน ทุก Task เคลื่อนผ่านเลนเดียว และการเปลี่ยนสถานะแต่ละครั้งคือการส่งต่อที่แนบเทมเพลตไว้:
| สถานะ | เจ้าของ | เทมเพลตที่แนบไว้ |
|---|---|---|
| Todo | คนหรือ Agent หัวหน้า | การส่งต่อตอนมอบหมายงาน |
| In progress | Agent | (ทำงานอยู่ใน worktree ที่แยกจากกัน) |
| Ready for review | Agent | การส่งต่อตอนรีวิว |
| Done | คน | บันทึกการอนุมัติ + การตัดสินใจ merge |
กฎที่ทำให้ทั้งหมดนี้อ่านเข้าใจง่าย: Agent ย้าย Task ไปที่ Ready for review; คนย้ายไปที่ Done Agent ไม่มีวันทำเครื่องหมายว่างานของตัวเองเสร็จ และคนก็ไม่ต้องประกอบขึ้นใหม่ว่าเกิดอะไรขึ้น เพราะการส่งต่อตอนรีวิวอยู่บน Task แล้ว ใน Sharkly การลงมือ อุปสรรค ผลลัพธ์ และการพูดคุยติดตามผลจะกลับไปอยู่ในไทม์ไลน์ของ Task ดังนั้นเมื่อมี agent สิบตัวทำงานอยู่ คุณก็อ่านบอร์ด ไม่ใช่เทอร์มินัลสิบอัน นั่นคือความแตกต่างระหว่างการติดตามว่าที่ agent ทำเสร็จแล้ว กับการหวังว่า commit log จะอธิบายได้ทีหลัง ตรงไหนที่งานอัตโนมัติต้องหยุดนั้น本身就是การตัดสินใจเชิงออกแบบ ซึ่งครอบคลุมในการวางด่านอนุมัติ
ตัวอย่างจริง: จากตั๋วงานถึง PR ที่ merge แล้ว
ลองดู Task ที่มีหน้าตาเหมือนงานจริง SH-441: "เพิ่มการส่งออก CSV ให้หน้ารายงาน" ให้ดูว่าเทมเพลตถูกกรอกอย่างไร ไม่ใช่ตัวโค้ด
คนคนหนึ่งเปิด SH-441 แล้ว Agent หัวหน้ากรอกการส่งต่อตอนมอบหมายงานให้ครบ: เป้าหมาย ("ให้ผู้ใช้ดาวน์โหลดรายงานปัจจุบันเป็น CSV ได้") ขอบเขตที่แตะ (reports controller กับโมดูลส่งออกใหม่หนึ่งโมดูล) สิ่งที่อยู่นอกขอบเขต (auth, query รายงานที่มีอยู่เดิม) และ definition of done ที่มีสามข้อตรวจสอบได้ (ปุ่มดาวน์โหลด การ escape เครื่องหมายจุลภาคและอัญประกาศอย่างถูกต้อง และเทสต์กับ fixture 10,000 แถว) ผู้รับผิดชอบคือ backend Agent ไม่มีอะไรกำกวม เพราะเทมเพลตไม่ยอมให้มันกำกวม
backend Agent รับ Task ไป ทำงานในworktree แยกต่างหาก เพื่อไม่ให้ชนกับงานอื่น แล้วรันรายการ definition-of-done เป็นเช็กลิสต์ของตัวเอง เมื่อ typecheck, unit test และ build ผ่านหมด มันก็ย้าย SH-441 ไปที่ Ready for review พร้อมกรอกเทมเพลตขากลับ: สรุปสั้นๆ ข้อตรวจรับแต่ละข้อที่ถูกกา พร้อมวิธีที่ใช้ตรวจสอบ diff และข้อจำกัดที่รู้อยู่หนึ่งข้อ ("การส่งออกเกิน 100,000 แถวจะ buffer ในหน่วยความจำ ยังไม่ได้ทำ streaming")
ตอนนี้การส่งต่อพลิกทิศทาง คนอ่านบันทึกชุดเดียว ไม่ใช่ scrollback พวกเขายืนยันเทสต์การ escape ชั่งน้ำหนักข้อจำกัดเรื่องหน่วยความจำกับขนาดรายงานจริง ยอมรับมันไว้ก่อน แล้วย้าย SH-441 ไปที่ Done ซึ่งทริกเกอร์การ merge จากตั๋วงานถึง PR ที่ merge แล้ว พร้อมเทมเพลตที่กรอกครบทั้งสองรอยต่อ และบันทึกว่าใครเป็นเจ้าของส่วนไหน นี่คือเส้นทางจากความต้องการสู่โค้ดที่ตรวจสอบย้อนกลับได้ตั้งแต่ต้นจนจบ
เมื่อไหร่ที่เทมเพลตเป็นเรื่องเกินจำเป็น
เทมเพลตมีต้นทุน ดังนั้นนี่คือคู่การตัดสินใจแบบตรงไปตรงมา ข้ามเทมเพลตเต็มรูปแบบไปได้เลยสำหรับงานเล็กๆ ที่นิยามไว้ดี และ Agent ตัวเดียวทำจบในรอบเดียว ซึ่งเป้าหมายและการตรวจรับชัดเจนอยู่แล้วจากชื่อ Task ให้หยิบมาใช้ทันทีเมื่องานข้ามรอยต่อที่สำคัญ: agent หลายตัวทำงานเป้าหมายเดียวกัน การเปลี่ยนแปลงสัญญาสาธารณะ หรืออะไรก็ตามที่แตะ auth, billing หรือข้อมูลที่คุณถอนคืนได้ยาก เทมเพลตคือประกันภัยต่อการสูญหายของ context และคุณซื้อประกันในจุดที่ความเสียหายจะเจ็บจริง
คุณทำทั้งหมดนี้ด้วยมือได้ ด้วยบอร์ดที่แชร์กันและวินัย วิธีนั้นใช้ได้จนกว่าจำนวน agent, task และ repository จะเพิ่มสูงขึ้น และวินัยก็เป็นสิ่งแรกที่หายไป ถ้าคุณใช้ agent หลายตัวอยู่แล้ว Sharkly ให้คุณมีที่เดียวสำหรับจัดการงานและผลลัพธ์ของพวกมัน: Task ที่แชร์กันซึ่งพกการส่งต่อตอนมอบหมายและตอนรีวิว ผู้รับผิดชอบต่อ Task, worktree ที่แยกจากกัน และเลนสถานะที่ Agent ไปถึง Ready for review แล้วคนตัดสิน Done ใช้ coding agent ที่คุณมีอยู่แล้วต่อไป ดาวน์โหลด Sharkly เมื่อรอยต่อระหว่างพวกมันเริ่มมีต้นทุนสูงกว่าตัวงานเอง
คำถามที่พบบ่อย
เทมเพลตการส่งต่องานของ coding agent คืออะไร? มันคือโครงสร้างตายตัวของสิ่งที่งานหนึ่งพกติดตัวเมื่อเปลี่ยนมือ มีสองแบบ: การส่งต่อตอนมอบหมายงาน (เป้าหมาย ขอบเขต และ definition of done จากคนไปยัง Agent) และการส่งต่อตอนรีวิว (สรุป หลักฐาน และข้อจำกัดที่รู้อยู่ จาก Agent กลับมาหาคน) การกรอกฟิลด์เดิมทุกครั้งคือสิ่งที่กันไม่ให้ context ระเหยหายไประหว่างคนทำงาน
ทำไมต้องทำเทมเพลตขากลับ ไม่ใช่แค่ตั๋วงาน? ทีมส่วนใหญ่เขียนตั๋วงานแล้วไม่ทำเทมเพลตอะไรเลยตอนขากลับ การรีวิวทุกครั้งจึงเริ่มต้นเหมือนการสอบสวน การส่งต่อตอนรีวิว ที่มีสรุป ข้อตรวจรับที่กาแล้ว และข้อจำกัดที่รู้อยู่ คือจุดที่เทมเพลตประหยัดเวลามากที่สุด ดูcoding agent แบบ human-in-the-loop
agent ควรทำเครื่องหมายว่างานตัวเองเสร็จไหม? ไม่ควร ให้ Agent ย้าย Task ไปที่ Ready for review พร้อมกรอกเทมเพลตขากลับ แล้วปล่อยการย้ายไป Done กับการตัดสินใจ merge ไว้ให้คน การแยก "นำเสนอแล้ว" ออกจาก "อนุมัติแล้ว" คือสิ่งที่หยุดไม่ให้โค้ดที่ยังไม่ได้รีวิวถูกปล่อยออกไป
เทมเพลตควรอยู่ตรงไหน? บน Task ที่แชร์กัน แนบไว้กับการเปลี่ยนสถานะ ไม่ใช่ในเทอร์มินัลที่มีแค่ agent ตัวเดียวเห็น เมื่อการส่งต่อคือสถานะที่แนบเทมเพลตไว้ คนทำงานคนถัดไปก็เห็นชัดว่ามีอะไรกำลังรออยู่ นี่ยังช่วยไม่ให้การรีวิวกลายเป็นคอขวดเมื่อ agent หลายตัวทำงานเสร็จพร้อมกัน
ต้องใช้เครื่องมือไหม หรือทำด้วยมือได้? คุณทำได้ด้วยบอร์ดที่แชร์กันและวินัย เลเยอร์เฉพาะทางจะคุ้มค่าก็ต่อเมื่อคุณต้องประสานงาน agent หลายตัวข้ามหลาย repository และการติดตามด้วยมือกลายเป็นตัวงานไปเอง ลองเทียบกับAI task manager อเนกประสงค์สำหรับงานของ agent
