เลือกวิธีแตกงาน chaining ตายตัว หรือปรับตามที่ค้นพบ

แนวคิด

การแตกงานซับซ้อนมีสองกลยุทธ์หลัก แบบแรกคือ pipeline ตายตัวหรือ prompt chaining ที่แบ่งงานเป็นขั้นตอนลำดับแน่นอนไว้ล่วงหน้า แบบที่สองคือ dynamic decomposition ที่สร้างงานย่อยขึ้นตามสิ่งที่ค้นพบในแต่ละก้าว การเลือกให้ถูกกลยุทธ์ขึ้นกับว่างานคาดเดาได้แค่ไหน

prompt chaining เหมาะกับงานหลายแง่มุมที่คาดเดาได้ ตัวอย่างชัดคือการรีวิวโค้ดที่แบ่งเป็นขั้น เช่น วิเคราะห์แต่ละไฟล์แยกกันก่อน แล้วค่อยรันรอบตรวจการเชื่อมข้ามไฟล์ ขั้นตอนเหล่านี้รู้ล่วงหน้าและเรียงลำดับได้เลย

dynamic decomposition เหมาะกับงานปลายเปิดที่ไม่รู้ล่วงหน้าว่าจะเจออะไร เช่น "เพิ่มเทสต์ครอบคลุมให้ codebase เก่า" วิธีคือแมปโครงสร้างก่อน ระบุจุดที่ผลกระทบสูง แล้วสร้างแผนที่จัดลำดับความสำคัญซึ่งปรับตัวไปเรื่อยเมื่อค้นพบ dependency ใหม่ แผนจึงงอกงานย่อยตามความจริงที่เผยออกมาทีละก้าว

ทำไมสำคัญ

การเลือกกลยุทธ์ผิดทำให้งานพัง พิจารณ Sample Question ข้อ 12 pull request แก้ 14 ไฟล์ในโมดูลติดตามสต็อก การรีวิวแบบผ่านเดียวที่วิเคราะห์ทุกไฟล์พร้อมกันให้ผลไม่สม่ำเสมอ บางไฟล์ได้ feedback ละเอียด บางไฟล์ผิวเผิน พลาดบั๊กชัด ๆ และให้ feedback ขัดกันเอง คือ flag รูปแบบหนึ่งว่าเป็นปัญหาในไฟล์หนึ่ง แต่อนุมัติโค้ดเหมือนกันในอีกไฟล์

คำตอบที่ดีที่สุดคือแยกเป็นหลายรอบที่โฟกัส วิเคราะห์แต่ละไฟล์เพื่อหาปัญหาเฉพาะที่ก่อน แล้วรันรอบแยกที่โฟกัสการเชื่อมข้ามไฟล์ตรวจการไหลของข้อมูล นี่คือ prompt chaining ที่เหมาะกับงานรีวิวหลายแง่มุมที่คาดเดาได้ เพราะมันหลีกเลี่ยงการเจือจางความสนใจเมื่อยัดทุกไฟล์เข้ารอบเดียว

ทางเลือกที่ด้อยกว่าคือบังคับให้ผู้พัฒนาแยก PR เล็กลงก่อนรีวิว ซึ่งผลักภาระไปที่คน หรือเปลี่ยนไปใช้โมเดลที่ context ใหญ่ขึ้นเพื่อยัดทุกไฟล์ในรอบเดียว ซึ่งไม่แก้ปัญหาการเจือจางความสนใจที่ต้นเหตุ

ตัวอย่าง

# Prompt chaining — งานคาดเดาได้ (รีวิว PR หลายไฟล์)
รอบ 1: วิเคราะห์ไฟล์ A แยก
รอบ 2: วิเคราะห์ไฟล์ B แยก
รอบ 3: ตรวจการเชื่อมข้ามไฟล์รวม

# Dynamic decomposition — งานปลายเปิด (เพิ่มเทสต์ให้ legacy)
ก้าว 1: แมปโครงสร้าง
ก้าว 2: หาจุดผลกระทบสูง
ก้าว 3: สร้างแผนจัดลำดับ แล้วปรับเมื่อเจอ dependency ใหม่

เช็คความเข้าใจ

อ่านต่อ

• Subagents and dynamic workflows
• How tool use works