Skip to content
Tayakorn

Context Engineering Handbook

LEVEL 3 · ระดับสูง

หลายหน้าต่างดีกว่าหน้าต่างเดียว — แยกบริบทกับค่าส่งต่อ

มีงานประเภทหนึ่งที่ทำในหน้าต่างเดียวไม่ไหวเลย: งานที่ต้องอ่านเยอะแต่ใช้จริงนิดเดียว — สำรวจสิบไฟล์เพื่อหาคำตอบสามบรรทัด · อ่านห้าแหล่งเพื่อสรุปหนึ่งย่อหน้า

ปัญหาไม่ใช่ว่าอ่านไม่ทัน แต่คือ ทุกอย่างที่อ่านไปค้างอยู่ในหน้าต่างตลอดกาล ตามบทที่ 2 — แล้วก็เกิดอาการเสียสมาธิตามบทที่ 10 ตามมา

11.1 เหตุผลจริงที่การแตกงานเวิร์ก

คนส่วนใหญ่เข้าใจว่าการแตกงานให้ตัวช่วยหลายตัวดีเพราะ ทำพร้อมกันได้เร็วกว่า — ความเร็วเป็นของแถมครับ

เหตุผลจริงที่มันเวิร์ก คือแต่ละตัวได้หน้าต่างสะอาดของตัวเอง แล้วส่งกลับมาแค่ข้อสรุป

ตัวลูกอ่านไฟล์เป็นหมื่นโทเคนในหน้าต่างของมันเอง แล้วส่งกลับมาสามบรรทัด · หน้าต่างของตัวแม่โตขึ้นแค่สามบรรทัดนั้น ไม่ใช่หมื่นโทเคน

11.2 ราคาที่ต้องจ่าย — ค่าบรีฟ

ตัวลูก ไม่เห็นบทสนทนาของตัวแม่เลยสักตัวอักษร — มันเกิดมาพร้อมหน้าต่างเปล่า

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

เมื่อไหร่ไม่ควรแตก: งานที่ทำเองจบใน 3–4 ก้าว · ค่าบรีฟกับค่าอ่านรายงานกลับ แพงกว่าตัวงาน

11.3 บทเรียนจากการรันหลายสายจริง

ตอนที่เว็บนี้ถูกพัฒนาหลายสายพร้อมกัน กติกาที่รอดมาเหลือสองข้อ และทั้งสองข้อเป็นเรื่องบริบททั้งคู่:

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

ข้อสองคือรูปหนึ่งของอาการ "ขัดกันเอง" ในบทที่ 10 — บริบทที่ถูกต้อง ณ วันที่เริ่ม อาจผิดแล้ว ณ วันที่จบ

Read the full book